This is the first in a series of blog posts about IT Infrastructure Library (ITIL) processes and security.
Its basic premise is that the standard processes of ITIL lack adequate security protection, and organisations relying on them are unlikely to have security practices in place that are adequate for the current threat environment.
Fortunately, it is possible to extend the ITIL environment with six key security services, which in total give a good assurance that operational security is under control.
In this series, I discuss how ITIL misses the mark when it comes to operational security, and then continue to outline the six key security services that every organisation must have in order to properly structure operational security. In the third post I integrate these services into the ITIL framework, and finally I discuss how we have to evolve the service design for these six services to keep our security team focused on the future.
Cybersecurity is not something you want to get wrong. There is now a long list of well-known and not-so well-known names of significant organisations which have been comprehensively compromised.
For large organisations, the consequences can range from a serious case of organisational doxing, to the compromise of intellectual property and financial data, customer data; even the intelligence capabilities of arguably one of the world’s best-protected nations can be compromised. For smaller organisations and individuals, the risks emanating from account compromise and ransomware can similarly be serious to crippling.
ITIL has become the de-facto standard for how many organisations manage their IT infrastructures. As a standard way of organising IT services, it works pretty well. Unfortunately, when it comes to cybersecurity, a reliance on ITIL is going to leave you in serious trouble when the hackers come knocking.
What is the IT Infrastructure Library?
ITIL is essentially a library of processes. Of all the processes that make up ITIL, only one in the ‘Service Design’ area deals explicitly with security. Specifically, it deals with the presence and maintenance of a set of security policies.
Now don’t get me wrong. In an ideal world, the inclusion of security policies in service design should ensure that these policies are defined, documented and implemented. And if they are implemented, the remainder of the processes should ensure that compliance is monitored and exceptions are dealt with. This ‘trickle down’ effect is essentially the stock standard answer you get when ITIL evangelists are challenged on the topic of lack of security in ITIL.
Yet this is what seldom happens in practice. Security people already know the ‘trickle down’ approach doesn’t work. At best, it may only serve to get some security boxes ticked (where the ticks may or may not represent reality).
Most likely, it generates a set of bottom drawer security policies that you’d struggle to locate in the case of an incident (when, according to ITIL, you really need them). At worst, the business will mumble something about “innovation”, “business essentials”, “budget” and “timelines” and continue to ignore security.
Reliance on ITIL will leave you in a bad state
ITIL goes wrong in that it doesn’t specify a complete set of security services as part of the service offering: no operational security, no incident response, no intelligence gathering, and no log collection. During a security incident, if all you’ve got to go on is a set of policies accompanied by a partial implementation of controls and monitoring capability without assigned responsibility, the road to incident response and credible improvement will be hard.
The task of security teams goes way beyond policies – it is to ensure that the software and hardware that the business deploys or puts out to the market is secure by design, secure in deployment, secure in operation and secure in breach. ITIL doesn’t cover any of that.
Security policies are a start, but by no means the whole story. I’ll explain more in my next post.
Original post appeared on LinkedIn
Hinne Hettema is the operational security team leader for the Unitec Institute of Technology at The University of Auckland.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.