Using the SANS Vulnerability Management Maturity Model in Your Vulnerability Management Process

Background

The SANS Vulnerability Management Maturity Model is published by the SANS Institute, which provides training, certifications, and resources for cybersecurity professionals. The model is divided up into five levels — initial, managed, defined, quantitatively managed, and optimizing — with the goal being to end up with a fully developed vulnerability management program. Organizations can rate their progress on that scale in several key areas — prepare, identify, analyze, communicate, and treat — which represent stages of a vulnerability management process. These categories allow you to grade yourself in each area, as opposed to a broad assignment of a level for your entire program.

Levels

• Initial: This is the first level in the model and reflects an organization that is just starting to develop their vulnerability management program. They don’t yet have policies documented, their scanning is ad-hoc, and prioritization of vulnerabilities is based solely on CVSS scores. prioritization of vulnerabilities is based solely on CVSS scores.
• Managed: In level two, some policies have been developed but primarily out of necessity from adverse impact, as opposed to strategic selection. Scanning has been implemented for certain divisions, and prioritization includes additional information such as whether or not an exploit exists. Overall, the program has been launched, and progress has been made, but there are still many aspects that are not form but there are still many aspects that are not formalized.
• Defined: In level three, policies have been selected based on recognized frameworks, and training on these policies is provided to employees. Scanning technology is implemented company-wide with minimum thresholds for all divisions. Vulnerabilities are correlated with assets to add additional risk-based evaluation to prioritization. Vulnerabilities are correlated with assets to add additional risk-based evaluation to prioritization.
• Quantitatively Managed: This level adds a layer of tracking to the program, noting deviations from policies and measuring scanning coverage. Technology that might need more investment, such as integrating threat intelligence into your vulnerability management solution for prioritization, is
• Optimizing: Congratulations, your program has reached enlightenment! This is the final level where automated controls enforce policies, scanning occurs automatically and is integrated into the development process, and company-specific threat intelligence from the operating environment is used in prioritization. At the optimizing stage, your program is a well-oiled machine that is learning from the data it collects to improve continuously. -oiled machine that is learning from the data it collects to continuously improve.

Focus Areas

• Prepare: The prepare focus area is broken down into two subcategories, policy & standards and context. This focus area is all about the work that is done behind the scenes to make a vulnerability management program successful. At the initial level, this means policies and standards are not yet documented, and contextual data, such as the details about who owns an asset, are available, but they’re in multiple different data sources and may not be accurate. As you mature through the model, you develop policies based on strategic value to your organization and enforce them, starting to quantify deviation. You begin to require contextual information be tracked on your assets and store that data in a central repository. In the final optimization stage, these processes are automated so that controls are in place to enforce your policies and standards. Automation is applied to your asset inventory, so assets are automatically created and removed, reconciling with other data systems.
• Identify: This focus area is divided into three subcategories, automated, manual, and external, which refers to different methods of detection of vulnerabilities. Automated means your automated scanning, which in level one is ad-hoc, but by level five is integrated into your development process and happens automatically in accordance with requirements. Manual is your manual testing, which might include penetration testing. In level one, this is only done if specifically required or requested. In level five, manual testing is done based on historical data and threat intelligence. External refers to detection that is done outside of your organization, primarily by ethical hackers or third-party vendors. The evolution of this category follows the development of your vulnerability disclosure policy (VDP). Your VDP may start out published with very little backend follow-through support, but by level five, you should aim to have an established program in place that works with specific vendors or researchers to accomplish stated goals. 
• Analyze: Prioritization and root cause analysis make up the analyze focus area. This is where you evaluate the vulnerabilities you’ve discovered and determine which should be prioritized. At level one, prioritization is done solely based on the CVSS score, however, you should be working towards a risk-based prioritization strategy, which adds additional factors such as the business criticality of the asset, the conditions for exploitation, and threat intelligence, to the evaluation of a vulnerability. Root cause analysis is the process of investigating the underlying cause behind something. In the case of vulnerability management, you might have the use of a third-party code library with a known vulnerability. Performing root cause analysis would dig deeper into the processes that allowed a library with a known vulnerability to be used. For example, is there an approved list of code sources? Are vulnerability scans being conducted during development to catch vulnerabilities before they go to production? In the early stages, your root cause analysis is based on out-of-the-box information such as patch reports, but by level five, an executive dashboard should be put in place that identifies root causes along with impediments and project costs.

• Communicate: This focus area is made up of two subcategories, metrics & reporting and alerting. The metrics & reporting category is a little bit meta… assigning a metric to your metrics. The maturity model begins at level one with point-in-time operational metrics that are taken straight out of your tools with little filtering or analysis. In level five, you’ve improved your reporting capabilities to the point where reports are correlated with policies and areas of compliance, and analysis is automated to highlight outliers and systematic issues. On the alerting side, at level one, alerting may not exist outside of the security team. The maturity model works to improve alerting capabilities by integrating them into other departmental technologies, such as the ticketing system your IT department uses. By level five, you should have some automated processes that respond to common alerts.

• Treat: The last focus area is the final step in your vulnerability management process, dealing with the vulnerabilities. This includes change management, patch management, and configuration management. In level one, changes related to vulnerability management activities go through the same workflow as any other change. Patches are applied manually or scheduled by admins. Configuration management is a manual process without well-defined requirements. Remediation can often be a bottleneck for organizations that don’t have the technology to implement fixes seamlessly. Level five of the maturity model focuses on applying automation, creating workflows to launch patch remediation, and detecting and correcting misconfigurations automatically.

Next Steps

To put this into practice, download the full maturity model chart. Go through each focus area, rating your current program for each subcategory. Identify which areas you’re ranking low in and then determine if improving in those areas is a priority for your organization. For example, you may not have a fully developed vulnerability disclosure policy if you’re not a large organization that is getting vulnerabilities reported to you from ethical hackers. Developing that program may not be a priority for you but improving other areas such as your remediation may be.

Are you interested in collaborating with other security professionals to improve your vulnerability management program? RH-ISAC members can join RH-ISAC’s vulnerability management working group to participate in vulnerability management discussions and exchange of best practices. Learn more about RH-ISAC membership.