Why ITIL, COBIT and Other Non-Infosec Based Frameworks Are Infosec’s Best Friends
As a current or aspiring security professional, you will know of a range of information security frameworks and enablers. These might include standards, e.g. ISO 27001, PCI DSS; risk management methodologies, e.g. Octave, IRAM 2, and security specific guidelines, e.g. the NIST Special Publications (SP) 800 series and Federal Information Processing Standards (FIPS). The list is dynamic and growing, and security frameworks continue to be produced for specific market sectors (e.g. financial institutions have the FFIEC Cybersecurity Assessment Tool; healthcare providers have the SRA Tool).
All such guidelines and standards have the common purpose of improving InfoSec. As InfoSec experts, many of them are our tools of choice, and our knowledge of them is highly respected across all industries (and very much sought after: in 2015 there were over 200,000 cybersecurity vacancies in the US alone).
Even so, throughout the 30 years I have been in the security field I have faced repeated difficulty getting traction for security inside of a business. This is sometimes a side-effect of security being a specialism that must be purchased, either from contractors or by specialized training of corporate staff. The problem is this expertise can become - through faults on both sides – a 'black art', properly understood only by a few security wizards. So instead of integrating our security expertise within a business, there is a risk that it appears like a 'black box', the inside workings of which are obscure to non-security initiates. This naturally perpetuates suspicion, distrust and misunderstanding of the security profession, and can lead to an adversarial, 'them versus us' relationship between senior managers and security advisers. Repeated flashpoints in my experience have included the need to tamper heightened expectations about new technology with the security risks of deploying it, and the need to spend more on security versus the need for savings. Any security expert who has had to brief managers about their security recommendations will know what these sorts of conversations feel like.
In spite of this, I believe the battle to convince businesses of the necessity of security is largely won. The two biggest reasons for this are the cumulative evidence of financial damage caused by security flaws (with ubiquitous news headlines about cyber breaches) and the adoption of 'soft' skills - like people management, good presentation, simplification, and persuasion - by influential security professionals. Yet there remain significant gaps between security practitioners and security consumers.
Continued effort is needed to limit the chances of misunderstandings between security people and C-suite executives. This can be tackled through better integration of security within business processes so that security can be seen in the light of recognizable procedures. I'm certainly not arguing for us to risk our job security through knowledge transfer – the above figure for cyber vacancies clearly shows there will be a market for our specialism for the foreseeable future. But I think we can always improve on advocating security as a business process, if only for the sake of our transparency and accountability as security professionals.
To help with this are some mature business process frameworks that also incorporate those security voices which still might not be heard outside the more familiar security-centered frameworks. In particular, I can recommend any cyber security expert get acquainted with ISACA's COBIT 5. Sold as a framework for the governance and management of IT, adopting COBIT will also ensure that a range of topics fundamental to InfoSec will be addressed, including Audit and Assurance, Risk Management, Regulations and Compliance, Enterprise IT and, of course, Information Security. COBIT's particular strength is its creation of a practical roadmap of practices to fulfill a wide range of business needs. It has been adopted by a variety of institutions across the world. In the US notable recognitions include its use by the U.S. Postal Service (USPS) to assess IT policies, processes and controls, and significant references within the NIST Cyber Security Framework: the many organizations who use the NIST framework will, therefore, feel the benefits of COBIT 5 too.
So if you are ever stuck with an organization whose security is a victim of the wider malaise of poor governance, COBIT might just be the answer to a lot of its problems. ISACA provide plenty of free tools for introducing the guidelines to C-suite executives, and (as I learned) it can be very useful for security professionals to be able to describe security in terms of the overall business, rather than as a niche.
COBIT 5's concentration is compliance and audit. A complementary framework that goes deep with design practices and processes through service management is ITIL. This
came into being in the 1980s, when a UK government office identified the need for universal practices, instead of allowing every department to create its own. This collection was gathered into an 'IT Infrastructure Library' (hence the acronym). ITIL took up the same 'plan, do, check, act' approach to service management that had been adopted for the ISO 27001 security management standard (which also grew up inside of the UK government community).
ITIL has long broken free of any restrictions as a British civil service tool and has evolved into an internationally recognized standard for IT services management. It continuously adapts best practices worldwide. Organizations that faithfully follow ITIL principles should already have a good basis for the management of security incidents (i.e. through effective service desk support). The integration of security in its requirements for configuration and change management are also useful meeting points for security inputs, and ITIL's emphasis on continuity of services is a useful entry point for contingency planning arrangements. In my view, ITIL has considerably enhanced the acoustics for security voices raised on the services management stage.
I'll briefly mention another framework useful to security and which also originated inside the machinery of British government: PRINCE 2 ( an acronym for PRojects IN Controlled Environments). In the USA, PRINCE 2 has been eclipsed by PMBOK (i.e. Project Management Body of Knowledge). It does cover quality management, control and organization of a project/program to ensure alignment with objectives. It is, therefore, a useful roadmap for security staff who want to see their processes built inside of a coherent project and program management structure.
(The number of successful management frameworks with UK government ancestry is interesting. Even so, their loss of that branding is likely to their advantage, as each has evolved successfully on the world stage way outside of their public sector cocoons).
It might be too much of a challenge for a security professional to introduce these frameworks to organizations that really need them. But if they can (or if any of these frameworks are already in place) each can provide a valuable piece of the patchwork that makes up good governance. By extension, that means good security too.