Security Maturity Models (Part 1 of 2)

At the 2018 BSides Miami conference I spoke on the topic of "Security Maturity Models".  In part, due to technical problems with the presentation, am presenting a lot of what I spoke on there.  This is a topic I continue to research and gather information on, so I may do an updated presentation at a future conference or possibly write an article for a journal.  Due to the amount of information, I'll be doing this as 2 postings.

What IS "maturity"?  We aren't talking about individuals (tho that's important), but about organizations.  From Wikipedia: "Maturity is a measurement of the ability of an organization for continuous improvement in a particular discipline."  Thus the higher the maturity, the higher will be the chances that incidents or errors will lead to improvements either in the quality or in the use of the resources of the discipline as implemented by the organization.  An 'immature' organization is often times in 'firefighter mode', they are a re-active organization.  Because they don't do things in a consistent manner, there is no "process", they often times cause many of the problems they later have to fix.  For instance, if an IT organization is building systems such that each is unique, this will make it harder for them to maintain those systems vs if they built systems in a consistent manner.

A mature organization would instead follow a process to build systems that enable them to be maintained.  A mature organization would be proactive.

We can see these principles in security when we build a information security management system or program.  Some security organizations are immature, being reactive.  Others are mature, being proactive.  And hopefully organizations are trying to work toward maturity.  If they understand this.

Many have created a variety of maturity models, in security and elsewhere.  Which is part of the problem.  Some models are focused on particular areas, such as security awareness or secure coding or endpoint protection.  Others are fairly high-level, others more detailed.  Many models are based on a widely used model, the Capability Maturity Model, developed by the Software Engineering Institute at Carnegie Mellon.

Let's start with this one from Blue Lava.  A fairly high level level model, ranging from reactive to proactive.  Immature/reactive organization are in the "blocking & tackling" level.  I think many can relate to that.  I did like how they have the next 2 levels.  Too often some will focus on compliance when the right target is to create a risk-based security program.  Compliance is NOT security.  Compliance should instead be seen as a measurement of security, an outcome of being risk-based, not the goal.

Moving on to another one, a little more complex.  Still 3 levels of organizations.  But here we assess orgs against 4 categories.  3 should be familiar: people, process, and technology.  People is who, both leadership and team members.  Process is how, how do we do what we do.  Technology is the means of doing those things.  I find the last (or is it first) category interesting: philosophy.  The why?  

A more complex model, here going with 5 levels of organization, which is something to be familiar with.  It builds off the 5 level Capability Maturity Model I mentioned.  We'll spend more time at the start of part 2 going into it.  But the names are pretty common to the CMM.  This one looks at the 3 categories of People, Process, and Technology.

And now we get an even more complex model, again using the 5-level maturity levels of the CMM.  But a difference here is the security aspect goes from basic to advanced.

Here is a high-level diagram of the CMMI, the Capability Maturity Model Integrated, which replaced the CMM.  It changed some of the level names.  I should point out that the 5th level is OptimizING. To often those who used the CMM as a basis overlook this and call it Optimized.  But that's wrong.  Its optimizing, as process improvement is ongoing, never stopping.

Now, some further overview of the CMM.  There is more to this model, as in levels 2 thru 5, there are various Key Process Areas that need to be met to be considered at that level.  Organizations usually start at level 1, then by completing these KPA they can move up the levels.  Some may never get past 3 or 4.  I was part of an IT organization that was formally access at Level 3.

So hopefully this has peaked some interest.  In the next part, I'll go into more depth on several maturity models in use:  CMM/CMMI, The Cybermaturity Platform, maturity models built into things like the NIST CSF and FFIEC CAT, and others.