“Not another maturity model…”
Probably the most frequent statement I hear from people evaluating a tool like Nucleus is “we don’t know where to start.” The second most frequent problem I’ve encountered across all of vulnerability management, no matter where I’ve been, has been “we’ve hit a wall and don’t know what to do next.”
That’s where a good maturity model can help you.
Several years ago, I was interviewing with a very experienced VM professional. The toughest question he asked me was “how do you implement a VM program?” I said if you ask the right questions, you can get a good picture of where they’re at now, map out what they’re missing, and work with them on building those missing pieces. If they don’t have a policy, work with them on building a policy. If they have a policy but it’s not working, ask to see it and look for places to make improvements.
He accepted my answer and I got the job, but his question haunted me since. Which questions do you ask? I only gave him two.
Then last month we found ourselves staring down someone else’s maturity model and dreading our next evaluation (I may have made a sarcastic comment about long-form taxes.) That was the Eureka moment. Lose the wall of boxes. Write a series of multiple-choice questions, then grade it. None of the answers on this test are wrong, and each of the five answers are sequential steps to full capabilities. Of course, it would be great for everyone to pick the best answer, but that simply isn’t reality. Some of these Level 4 and Level 5 capabilities are very new developments that even sophisticated enterprises have yet to reach.
We ended up building two versions of this model. One is just 10 questions, which you can fill out online to self-evaluate, completing it in less than 15 minutes. Our more comprehensive version takes a deeper dive and gives a more complete picture and recommendations, but most people will probably feel uncomfortable giving those answers to a stranger without an NDA. The longer model, therefore, is available to our customers and prospects upon request.
After answering the questions, the model grades your program on a scale of 1 to 5, where one is just getting started with basics, and five is the most advanced with full capabilities. To figure out which projects to take on next, prioritize balance across your VM program as you level up. If you grade out a 2.5, look for the questions you answered A and B. Move those up to a C level and get your total score to 3 before you move Cs to Ds. You ideally want a balanced portfolio. It’s more than math – straight Cs grade out the same in the end as a mix of As, Bs, and Ds, but the results of a balanced program are more consistent and probably cost less.
A Tale of Two VM Programs
I used to know two VM directors who worked in adjacent suburbs in the same metro area. When I met them, they had very similar programs in terms of maturity. The difference is one of them was spending about half a point below their maturity level, and the other was spending about half a point above. Needless to say, the one who was spending below their maturity level was much happier. So was the boss.
It may sound strange for a vendor to say this, but I can’t sell you everything to move you from Level 2 to Level 3. I can sell you the part that involves technology, but at least half of it involves people or processes – those, I can’t sell you. I also know from experience that if you buy the technology when your people and processes aren’t ready, you’re not going to be very happy with the outcome. I’d rather sell you the technology when you’re ready to use it.
Let’s take authentication and threat intelligence, and why I want you to build authentication before buying threat intelligence.
Working with authentication is like being an MD; working without it is like being a veterinarian. You both have patients needing treatment, but the MD can ask questions of their patient to refine reported symptoms and narrow a diagnosis. An MD can be much more prescriptive in treatment, while the veterinarian must rely on observation and then infer the best course of treatment.
This illustrates why it’s better to have authentication in place first; like the MD, you can get information directly from the patient in relation to the vulnerability, instead of limiting your data to mere observations. Once in place, you can mix in threat intelligence to prioritize data that is more actionable and accurate.
Vulnerability Maturity Levels
Most vulnerability management maturity models grade on a scale of 1 to 5, and since we’re not in the business of re-inventing the wheel, we did the same. Here’s a quick overview of each level.
This is generally a newer organization who’s just getting serious about security, taking the necessary steps to begin protecting their infrastructure. They may have a few scanners running, although much of what’s happening is still in the reactionary stage.
At this point you can say you have a functioning VM program, but the results may be inconsistent. There are some bright spots at this stage, yet some parts of the organization aren’t as far along as others. It is very difficult to get much beyond Level 2 if all you have is a vulnerability scanner. A good scanner has adequate tools for Level 2, but only some of the tools needed for Level 3. Many organizations start to feel they’ve hit a ceiling here.
At this stage you can officially say you have a mature VM program. You’re seeking out best practices and following them, rather than simply reacting. You’re prioritizing results and slicing-and-dicing data to report out, making it useful to various groups based on their specific needs – not just distributing scan findings. Another hallmark of this level is connectors. At Level 3, you have integrations with ticketing and alerting systems, so you’re able to communicate vulnerabilities to your stakeholders in the way they like to receive them. The better vulnerability scanners have some capabilities here, but the easiest way to reach this level is with a tool like Nucleus. Although we’re only halfway there, this is a level of maturity that many organizations struggle to reach.
At Level 4 you can call yourself quantitatively managed. At this stage, pretty much everything works exactly as intended, and you can measure and report on vulnerability data almost any way imaginable. The hallmarks here are customizability and contextualization. Level 4 pushes the limits of all available tools, and implementation will almost certainly require mixing-and-matching tools from multiple vendors. This level is rarified air for most organizations.
At lower levels, vulnerability management can exist in its own silo, separate from the rest of the security program. At the highest level, this is no longer possible – Level 5 breaks the traditional boundaries of vulnerability management. Operating at this level requires the capability to ingest data from various teams and tools spanning several security disciplines inside the enterprise. One hallmark of this level is the ability to recognize an attempted exploitation of a vulnerability in your environment, while increasing the priority on that vulnerability on all affected devices. This is the future, but few organizations are in position to reach it today.