Tripwire has been in the business of providing vulnerability management solutions with IP360 for about 20 years. With over 20,000 vulnerabilities discovered last year alone, vulnerability management continues to be an important part of most security plans. And most organizations agree. In a recent survey, 89 percent of respondents said that their organizations runs vulnerability scans. About 60 percent said they run those scans daily or weekly, while 40 percent said they scan monthly, quarterly or less often. What was interesting was that only half of the respondents said they were doing authenticated scans.
Regardless if done using a remote scan or an agent, an authenticated scan gives you substantially more visibility than port or non-credentialed scans. This means that roughly half of organizations are not harnessing the power that a fully mature VM program can give them. Without visibility into what’s in their environment, organizations leave themselves open to substantially more risk. In order to better understand why, we developed a Vulnerability Management Maturity Model to help us understand where organizations are with their vulnerability management programs and where they want to be. Then maybe we can find ways to help organizations get to where they want to be.
What is the Vulnerability Management Maturity Model?
The first maturity level is called “Undeveloped.” An organization at this level is either not doing any vulnerability scanning or is doing ad-hoc testing, usually some kind of penetration testing done by a third-party vendor where a report of vulnerabilities are found. Any critical vulnerabilities are probably remediated. Based on our survey, around 11 percent of organizations are at this level. The second maturity level is called “Checkbox.” Vulnerability scanning is brought in-house and done on some kind of regular cadence. At this level, the driver behind the vulnerability program is usually some kind of regulatory requirement. This means that the information security teams will perform what is required by the regulations but do no more. That’s dangerous, as most regulations already constitute the lowest common denominator for a large number of organizations to mitigate risk and receive a certificate. Complying with such a regulation, therefore, doesn’t necessarily mean an organization will meaningfully improve their security, notes Edd Hardy. This possibility points to how compliance isn’t the same as security. Overall, compliance standards are one-size-fits-all and can’t possibly lay out how security teams can secure their organization’s specific environment. The third maturity level is called “Constrained.” Procedures and processes are well-defined and understood by the organization. There is some level of executive management support. Scans are run more frequently, and audience-specific reports are created; system admins receive vulnerability reports, and management receives risk trending reports. The fourth maturity level is called “VM Program.” At this level, formal and quantifiable metrics are reported and tracked by management. Acceptable levels of risk are defined, and mitigations processes are put into place. The fifth and most mature level is called “Risk Management.” At this level, VM is part of an overall Risk Management processes. VM data is gathered alongside secure configuration data to offer an overall risk assessment. In our experience, most organizations are at the Checkbox or Constrained level, but they really want to be at the VM Program or Risk Management level. What is stopping them? Usually, it’s the lack of resources whether it be time, money or people. So, how do you convince the powers that be, usually non-infosec leadership, of the value in a mature VM program? https://www.slideshare.net/Tripwire/vulnerability-management-myths-misconceptions-and-mitigating-risk-part-i
3 things you can do to get your organization to the level it needs to be at.
First, speak with your leadership team about what the organization’s tolerance for risk is. Present a few risks to leadership with some trade-offs in terms of mitigation costs and resource constraints and listen to how they want to address those risks. In order to gauge the risk threshold, translate the potential consequences into something meaningful to the executives themselves. For example, if a risk were likely to cause an outage of a major service for up to four hours in the next year, would it need to be escalated to the executive level or not? How about if it caused just 30 minutes of disruption? Would this type of risk warrant escalation? Second, align your vulnerability management program with the goals of the business. Instead of being the group that says “no,” find out how you can enable your organization to meet its annual business objectives. Finally, create business-oriented metrics that demonstrate the need for and value of a vulnerability management program. For example, providing a ratio of business-critical assets to total assets gives an idea of the total risk that the organization is exposed to. Also, use performance metrics to convey the value you are delivering. A metric like Mitigation Time Half Life, which describes the amount of time required to remediate half the vulnerabilities that require action, shows the velocity at which the organization can reduce risk and become more secure.
