I have spent much of my career exploring various security frameworks, compliance regimens and standards. I have dabbled in most of them, primarily because I am curious to see what value can be derived, what benefit they bring, and why someone believes that a certain approach is the best. I will be honest. After thirty years of exploring, I’ve formed some opinions. This blog is about one of them.
What is Security Maturity
Security maturity grew out of the CMMI model. The CMMI model was an effort (by my alma mater) to define process maturity. It specified five tiers of maturity: incomplete (unaware or undefined), initial (awareness but reactive), managed, defined, quantitatively managed, optimizing. The intent was to measure the process of discovery, growth, and improvement. It manifests as a measure of how well an organization executes a program of continuous improvement. A low level of maturity indicates that the organization has not implemented or operated a plan for continuous improvement. A high level maturity indicates that they have iterated continuously to identify methods of optimization and improvement. Demming’s Plan-Do-Check-Act (PDCA) is a great illustration of a program of continuous improvement. A maturity model would reflect how frequently and with how much rigor the PDCA cycle is operated. The PDCA cycle may focus on a the continuous improvement of a domain such as software development, a specific mitigation or control such as malware prevention, or even the organizational operations as a whole. The key is that maturity is designed as a measure of how the organization has progressed in the maturity of operating that cycle.
There is one weakness in this approach. How do you know what you are supposed to do. CMMI and Plan-Do-Check-Act are methods of refinement and improvement (which could also be phrased as capability and maturity), but refinement, improvement, and maturity of what?
I have had far too many conversations with people who insist that a security maturity model is the way out of their poor security posture, and that security maturity is a model of security practices and mitigations. Security maturity in their mind is a series of every increasing mitigation techniques that are in some cases loosely defined, and in others very rigidly defined. To them maturity is a representation of what a good organization does to mitigate threats.
There is however a fallacy in this belief. If we look at the purpose and definition of a capability maturity model, its intent is to mature the process of continuous improvement. In fact CMMI website states:
“Capability levels apply to an organization’s performance and process improvement achievements in individual practice areas.”
https://cmmiinstitute.com/learning/appraisals/levels
Maturity was never intended, and should never be used to define what practice areas are, and yet many people write or describe maturity as a sequence of technical mitigations or capabilities instead of process improvement maturity. Why have they done this? It is likely the case that because CMMI uses the word capability (capability maturity model) and people have latched onto the word and used it to define “what you should do”. It has become a proxy for their beliefs of what good or necessary security controls are. Yet CMMI and maturity was never intended, nor should it be used to define what security mitigations you should chose, nor the risk mitigation levels required to adequately protect your organization. Its intent was to be process improvement capability – how far you had advanced in the direction of continuous improvement.
Transposing process improvement for technical or mitigation expectations as the definition of maturity perverts the intent of maturity. Maturity (as defined in CMMI) is measuring the maturity of the process you use to derive what optimal means for your security program. Maturity should represent your end state of mitigations. Perverting maturity in this way makes maturity a representation of ideal controls and mitigations across every possible security domain, and can demand mitigations and technology that impose costs and effort that vastly exceeds the protections the asset needs. Applying maturity as a measure of “have you done this mitigation or applied that technology” is optimizing for a single view of what good security looks like. It assumes that security controls and mitigations are one-size-fits-all. I wish you well if you believe one standard set of mitigations can universally fit all organizations. Such an assumption becomes dogmatic about how organizations should secure themselves regardless of the threats to those organizations, the value they are protecting, their budget constraints, and their risk tolerance. And yet there are multiple resources on the Internet that focus on “what mitigations you should have at each maturity level.”
If you think I am crazy, see what the NCSC had to say about this and their own IAMM here: https://www.ncsc.gov.uk/blog-post/maturity-models-cyber-security-whats-happening-iamm
Bottom line for security maturity: use it as a tool to measure how well you are managing your process to define good security at your organization, not as a measure of what good security is.
What is Risk Based Security
Risk based security has several roots with various compliance programs that require a “risk assessment”, and the rise of risk ontologies such as FAIR. Risk based security is probably best defined as a program that identifies the greatest security risks to the organization based on impact and probability of occurrence, and focuses security efforts on those areas by prioritizing spend and levels of control. To me, Risk based security focuses me on the assets I need to protect, and what are the most likely threats against them. It tells me that I should spend more time, money, and effort on protecting certain assets and less on others. It does not however, necessarily tell me I should use processes of continuous improvement to measure the success and failure of those efforts. (Humor me here, I’m trying to be reductionist to illustrate a dichotomy.) Risk based security does provide a few clues however. Risk based security traditionally does focus on “how much do I want to reduce the risk” so it does help to define outcomes, such as how many threats we want to prevent against or how much impact do we want to prevent against. These are important points as they hint at the idea that measuring the result can indicate whether we have reduced the risk to the tolerances we can accept. What Risk based security still does not point to however is the process of this continuous improvement.
Do you see a pattern here? Maybe a hint at a good path forward?
If you think I am going to leave you here with a scathing critique, but no path forward, you do not know me well. I am too kind for that, and to me teaching means I give you a push in the right direction.
The Approach I Like – ISO 27001
ISO 27001 is the path that I love the most because it marries Security Risk Management for the definition of “what should we do”, with Security Maturity as the method of managing and continuously improving the “what should we do”.
I had the great pleasure about 14 years ago to meet Angelika Plate, one of the authors of ISO 27001, and one of the people in the industry I truly admire. The part of the conversation that stuck out for me was the very balanced way she presented the intent of ISO 27001, and in particular its relationship to ISO 27002. I had commented that people obsessed over ISO 27002 and that it was misleading because it gave people the impression that they had to do all the things in ISO 27002. Her reply was that the real two goals of ISO 27001 was to first identify the risks to the organizations that were relevant to the company, and second was to manage the security through a Plan-Do-Check-Act process. ISO 27002 was a guideline (not a standard!) that provided a broad menu of security mitigation control options, and that it was up to the organization to find which controls derived the best mitigation through continuous improvement, even quantitative measurement, and optimization. Her answer was that the two approaches – risk management, and maturity – are not mutually exclusive, and should be used together. Her answer also points to the parallels with maturity and CMMI. ISO 27001 uses Plan-Do-Check-Act. CMMI measures the organization’s maturity in developing processes of continuous improvement through awareness of the need for controls, operating those controls, managing them, quantifying measurement, and optimizing them. The parallels should be obvious, each with their own purpose.
Then of course you are going to next ask me “how do you choose the right controls that are effective?” That answer is well outside the scope of this blog, but suffice to say Maturity will give you a path to choose, observe, test, and optimize what you do. There is no one solution for mitigating risk. Use your best judgement, avoid the pressure of FUD that vendors give you, and think practically. If you know what is important to do (your risk assessment) then you know where to do more research and choices, and you know roughly where to monitor for its success or failures. You also know that being mature will include monitoring and improving on the choices you made. Turning your back on the problem after your first try is not a good path to maturity.
So think about your programs. Are you heavily biased toward Security Maturity? Step back and assess your risks. Are you heavily focused only on Security Risk Management? Then I would suggest you look at your process of continuous improvement that moves your security program forward and builds on your Security Risk Management. Both are useful, both are necessarily, and both will create an appropriate security program that is mature, because even a risk management program can be continuously improved.
