I get it. You dread going into the office sometimes. It isn’t that you don’t like the people or the location. It’s that beast, waiting for you when you arrive, and it never seems to go away. You work hard at it, but you never seem to get ahead.
You are responsible for the vulnerability management program within your organization. Either as part of a formal program or on an ad-hoc basis, it’s your baby. Except that it isn’t a baby, it is more of an untameable monster, a minotaur in the labyrinth, waiting to surprise you as you turn the corner.
You are not alone. Trust me. There are many people in many organizations that feel this way about their program.
When I was working as the security operations prime, I helped to implement the first vulnerability scanner there. I can assure you that there were days when I felt I would have more success pushing water uphill.
Teaching for SANS over the past ten years has let me talk with a lot of students from a lot of organizations. And for the past few years, vulnerability management has been the main focus of those discussions. Based on my experience and these conversations, I have developed the following axiom:
You cannot win at vulnerability management. You can only mature and get better at it.
No, I am not kidding.
You cannot win.
Ever.
Repeat after me. (yes, say it out loud right now)
I cannot win.
Again. (Say it in your best Gandalf voice, when he is on the bridge with the demon in Lord of the Rings: The Fellowship of the Ring)
I cannot win. (Bonus points to you if you used something as a staff to hit the floor)
There. That wasn’t so hard, was it?
Why do I believe that? Vulnerability management is a continuous activity. It will never end, how can you win at it?
Just when you think you have gotten rid of all the problems in your environment, new ones appear. Just when you think you have resolved the process problems, new processes come along. There are always new people coming into the organization that need guidance on the policy suite. New technologies and software are continually released/updated. And don’t even get me going on the speed of changes in the cloud.
Vulnerabilities are like rabbits. You never have just two for long.
This leads us nicely to the main topic for today, the SANS Vulnerability Management Maturity Model (say VMMM three times fast and not feel the urge to eat something).
The model was released in poster form in May and has generated a bunch of interest. Yes, the poster does have a CISO mind map on the other side, but that is the back. (Really, it is. But don’t tell the management and cloud curriculum lead Frank Kim (@fykim).
You can download a copy of the poster HERE. You can also request your own 21” x 30” copy HERE ( you will need to log into your SANS account for that request). It does make a great decoration for your office walls.
David Hazar (@hazardsec) and I spent the time and effort to put together a roadmap that people could use as a reference for their organization based on our experiences and the material in our course, MGT516: Managing Security Vulnerabilities: Enterprise and Cloud. This roadmap, guidance document, model, whatever you wish to call it, is a reference guide with each focus area (more on those up next) having five steps/levels, with each level defining the activities that occur within each, to help grow, expand and improve your vulnerability management program.
Getting into the meat of the model, it is broken down into five focus areas. They are PREPARE, IDENTIFY, ANALYZE, COMMUNICATE, and TREAT. These are the five areas of the PIACT process from the course. Tasks and activities that are part of a vulnerability management program fit across these five sections.
Now stay with me as we make our way through these focus areas. They are:
Prepare:
This focus area is dedicated to what we need to make sure is in place for a successful vulnerability management program. In this section, we have two sub-areas: Policy & Standards, and Context.
Identify:
This focus area comes down to how do we find the vulnerabilities within our organizations. We have three sub-groupings in this section: Automated, Manual, and External.
Analyze:
This section is all about the data: how to look at, categorize, and prioritize the identified vulnerabilities. This section has two sub-areas: Prioritization and Root Cause Analysis (can you tell we have done project management before?).
Communicate:
Once we have the information in hand, this focus area comes into play. We take all the data we have and pass it along to others that need it, in a useable format. There are two sub-groups here: Metrics & Reporting, and Alerting.
Treat:
Finally, the part where all the work gets done to fix the problems we have. The three sub-areas are Change Management, Patch Management, and Configuration Management.
Below you will find a visual summary these five parts of the process.
For those wanting more information on PIACT, I have discussed it in a previous SANS webcast Managing Vulnerabilities with the PIACT Process if you wish to dig deeper.
Now, if you are still reading this, I know you’ve had your caffeine fix. Or are you trying to avoid answering those emails? But I digress.
We have these focus areas built around the PIACT process that are fine and great but where are these different maturity levels you ask (yes, it was your outside voice).
Each of the focus sub-areas has a description for each of the five levels in the model. The levels of maturity that we defined are:
- Level 1 – Initial
- Level 2 – Managed
- Level 3 – Defined
- Level 4 – Quantitatively Managed
- Level 5 – Optimizing
Now that’s all well and good, but what does that mean for you is what you want to know I’m sure. To be honest, the labels don’t matter. Call them A through E or Bob through George. What matters is that organizations tend to start at the lowest levels and move upward (or on the left and move to the right in the poster) as they increase in their program maturity. Let’s walk through the policy sub-area for an example. The different levels are:
Level 1 – Initial
Policy and standards are undocumented or in a state of change.
Level 2 – Managed
Policy and standards are defined in specific areas as a result of a negative impact on the program rather than based on a deliberate selection of best practices or standards from recognized frameworks.
Level 3 – Defined
Policy and standards have been carefully selected based on best practices and recognized security frameworks and are updated as needed to fulfill the program’s mission. Employees are made aware of standards and training on requirements is available.
Level 4 – Quantitatively Managed
Adherence to defined policies and standards is tracked and deviations are highlighted. Training of personnel on requirements is required at least annually.
Level 5 – Optimizing
Automated, proactive controls enforce policy and standards and provide input to regular updates and training requirements.
Ok. That’s a start, but let’s look at these with examples to highlight how an organization would progress through these phases.
Level 1 is where most organizations end up when they first start a vulnerability management program. Simple really. And the reason is that a lot of organizations go out and get a vulnerability scanner, as they need it, for example, for compliance. The program starts without a lot of planning. And in the policy space, this is reflected as well. If you happen to have some policies in place that are relevant for vulnerability management, you’re lucky. But it is just that. Luck. An example of where you’re lucky is a change management process and the policy that goes with it. It may be documented, or it may just be a standard operating procedure that the maintenance window is every second Sunday from 2-4 am. Everyone just LOVES those windows. Vulnerability management can leverage this but we didn’t put it there. Welcome to level 1!
As the organization continues to dive deeper into vulnerability management, and often this is just due to time spent running the program, the need for some specific policies to help with the vulnerability management program comes to light for whatever reason. Often this is due to an audit, and well, the auditors say you don’t have something. So, what happens? You are directed to fix the problem and address the audit item pronto. Policy approved! Congratulations, you’ve stumbled into Level 2.
After you find yourself reacting all the time and fighting fires, you normally want to get ahead of the curve. You start to look into what is needed for a good vulnerability management program. You research online. You also took the MGT516 class. Wow. Lots of missing policies for the beast. And you start writing the required policy documents and have them approved (always easy, right?). Your team is also letting everyone know by helping the teams understand through awareness and training. Since you are switching from a more reactive mode to being proactive on the policy front, you’ve also just switched over to being in Level 3.
Level 4 takes us to where we start to track against the policies that are in place within the organization for vulnerability management. Since the needed policies are in place, we can keep tabs on if things comply. If an item falls outside the ‘norms’, either by accident or exception, they are identified and tracked. Everyone is provided with the vulnerability management training they require on an annual basis.
Finally, it’s level 5. Here we continue to push the program forward by automation of the policies and enforcement when possible. When exceptions are found, they generate alerts and are remediated through this automation. These nonconforming items feed into the training to highlight examples and how these deviations are an issue.
Wow. That was a lot to walk through the policy levels. By now, some of you are thinking, “Sure, this works for some small organizations that have several hundred or even a few thousand vulnerabilities and hundreds of people. I have millions of problems to deal with here. MILLIONS! And we are 50k+ people. It’s not that easy!“
And you are right. It isn’t easy. But it isn’t easy for anyone, be it dealing with 500 or 5 million vulnerabilities. Join me next time as I show you how you can use the maturity model regardless of your organization’s size. I will walk through several examples of how to leverage the maturity model to help advance your program. Until then, you probably should go and get a haircut, as your hair is REALLY starting to look like Gandalf’s.
A quick way to see where the organization is at, and where we have been over the past 4 quarters.
Hopefully, this has given some useful insights into the maturity model. The goal was to show how you can leverage the information to gather ideas on how to advance your own program and I hope I have been a useful guide/mentor for the voyage.
Like Hans Solo.
I guess that would make you Chewie.
And since you didn’t get that haircut I mentioned last time, you REALLY do look like a walking carpet.
RRWWWGG.
FIND Vulnerability Management Maturity Model Part II here.
About The Author
With a career spanning over 20 years that has included working in network design, IP telephony, service development, security and project management, Jonathan has a deep technical background that provides a wealth of information he draws upon when teaching. Currently, Jonathan works for the Canadian Government conducting cyber security research in the areas of vulnerability management and automated remediation. He is also an independent security consultant. Jonathan is a co-author and instructor for SANS MGT516: Building and Leading Vulnerability Management Programs. He can be found online on Twitter (@jonathanristo) and Linkedin. Read more about Jonathan here.
