Vulnerability Process Management: Top 7 Takeaways for a Successful Program

Digest of the most important factors to consider when designing and managing your Vulnerability Management Process

This article provides a concise overview of the key factors to consider when managing a VM program. A robust initiative can not only reduce significant risk but also deliver benefits across the IT organization. These takeaways address common misconceptions and myths surrounding VM. Buckle up.

1. Managing vulnerabilities is about robust ITSM processes and data management – NOT cybersecurity.

To ensure we’re on the same page, vulnerability management addresses weaknesses in third-party hardware and software, as well as in the tools and data required to manage those IT assets robustly. For a more detailed definition, please refer to this link.

Every vulnerability belongs to a single instance of hardware or software – e.g., Adobe Reader missing patches on PC 0001, Java end-of-life on Server 0002, unable to locate PC 0003, no ownership information on Server 0004, malfunctioning management agent on Server 0005, and end-of-life OS on PC 0006.

In nearly every case, the vulnerability resolution maps directly back to an ITSM process, such as patching, IT Asset Management, CMDB completeness/accuracy, and server management teams. Vulnerabilities are NOT viruses or parasites that randomly “appear”, and in 99%+ cases, scanners do not even seek vulnerabilities until AFTER the resolution (patches, upgrades, configuration changes, etc.) has been published. Hence, there’s little value in non-security companies “analyzing” vulnerabilities; the focus should be on improving the ITSM processes required to deploy necessary resolutions and to address point 2.

2. VM risk is proportional to the size and diversity of the infrastructure estate, or “Attack Surface”

There are two basic levers IT teams have at their disposal to throttle vulnerability risk: ITSM Process Rigor (point 1), and Attack Surface Minimization (this point).

Every hardware asset and software package removed from a business’s ecosystem delivers a step-change improvement in both current and future vulnerabilities. Over time, more vulnerabilities are found, more solutions are published, users make bad installation or configuration choices, and so on. Vulnerability Management will never be “done”.

Case in point: An unpatched installation of Java on a server that has not been patched in 10 years will have around 500 vulnerabilities (at the CVE level). Furthermore, every additional year that the installation remains unrepaired will generate an additional 25–50 vulnerabilities. This is on one machine. If we are reasonably confident that it is not necessary for that particular hardware (or virtual/cloud) asset, removing Java cleans up all existing vulnerabilities. It prevents the acquisition of any future vulnerabilities.

Therefore, the most effective approach to VM is to eliminate and prevent unnecessary additions to the attack surface, in the form of:

• Minimizing standard software loads on new servers and PCs – if 5% or fewer owners/users require a specific software package, either create separate core loads or enable those individuals to request it after the initial installation. This way its dissemination is minimized, and all additional installations are known and can be managed more easily.

• Enforcing software standards and requiring approvals (or at least auditing/tracking) for any additional software installations.

• Running campaigns to track down and retire or consolidate un(der) used assets.

• Running campaigns to uninstall unused software.

3. VM remediation is achieved through an astonishingly small number of distinct solutions.

It’s pretty simple. This addresses the “how do I fix it”, and “it’s too complicated” concerns that are so often heard.

Following takeaway 2, the number of distinct solutions required is proportional to the diversity of the attack surface, rather than its size. Each software package and OS variation – e.g. MS Office, Adobe Flash, Wireshark, 7-Zip, SUSE Linux, Windows OS – may require individual solutions or automated scripts to remove, update, upgrade, or fix misconfigurations, but I’ve not seen an environment where 95%+ of vulnerabilities can’t be addressed with 50 or fewer distinct solutions.

Reducing the attack surface should include the elimination of non-necessary and non-standard software, which will reduce the diversity of the attack surface, making this point even more pronounced.

Again, virtually all remediations involve the upgrade, update, configuration/fixing or removal of software, or CMDB data enrichment. Therefore, whether solutions are deployed centrally or federally, the solution creation should certainly be centralized to a large degree.

4. In cases where there is a significant vulnerability backlog or “debt”, campaigns should be leveraged with a transparent risk decision process.

Click here to read more about running VM campaigns. Campaigns are time-bound, intensive efforts to address vulnerabilities across a defined scope of the attack surface. For example, a campaign can address issues such as Java, obsolete Windows OS, CMDB inaccuracy/incompleteness, and even specific sets of assets, e.g., Americas PCs, Business Unit 3 Servers, etc.

The goals of any campaign are:

1. Minimize the current & future attack surface

2. Identify and monitor all risks where the cost of remediation exceeds the benefit of remediation.

3. Implement or improve the process (service) of maintaining the remaining attack surface.

Goal 1 is addressed by takeaways 1 & 2 above, and Goal 3 will be addressed by takeaway 5. So, I’ll focus on goal 2, as this is critical. VM initiatives are never all or nothing, yet that is a misconception often espoused by non-cyber stakeholders. “You can’t just blast out upgrades to…”.

VM campaigns must have as little negative impact on the business as possible – ideally, none at all. One critical application outage, and the whole initiative could be doomed, as well as the company's risk disposition. Before embarking on any VM campaign, a risk assessment process must be established. I’ll say again – forcing remediation on an environment that presents an operational risk can be the death knell of a VM program.

I implore my clients to accept people’s concerns at face value initially and to set a realistic timeline for those concerns to be tested, vetted, and either confirmed or dismissed. As a VM program matures, the threshold for exceptions will become increasingly stringent. In the meantime, there should be plenty of lower-operational-risk areas to focus on.

The most important outcome is that all “accepted” risks are quantifiable and time-bound. This enables point 6 – embracing business cases to compare remediation vs. risk acceptance.

5. The ultimate goal of mature VM organizations is to manage a limited set of services that address all future vulnerabilities.

This is the essence of Service-Oriented Vulnerability Management. Hopefully, at this point, I’ve demonstrated that attacking existing vulnerabilities is significantly less effective than managing an efficient attack surface and a robust IT service portfolio.

Every campaign should transition to an ongoing process or service that ensures the scope of the attack surface remains well-configured, patched, and governed. This can range from enforcing auto-updates on Chrome to an SLA-driven infrastructure agreement with internal or third-party groups.

Most companies already have standards in place for OS patching. Whether monthly for Windows or quarterly for flavors of Linux, asset management teams are aware of when new patches are scheduled for release and have a process in place to deploy these security updates safely and efficiently.

There is no reason a similar service cannot be implemented for any area of VM, once a campaign has been run to find, test, and vet those assets that should be excluded from such a regular service.

6. Like any investment in a well-run business, all Cybersecurity efforts (including VM, of course) should require a beneficial business case.

Monetarily quantifying risk is hardly an exact science. While this is achievable mainly at the macro level, it becomes more challenging when drilling down to specific areas of the attack surface or individual vulnerabilities. For example, an incredibly exploitable vulnerability within a locked-down subnet is generally less risky than a difficult-to-exploit RCE vulnerability in the DMZ.

That said, business decisions are far more coherent when they are presented at the campaign or service level. A campaign should have a risk reduction target, as well as a budget, and a service should have a reasonably accurate ongoing cost estimate.

As mentioned above, VM campaigns and services should never be “all or nothing”. There will always be legitimate business cases for exceptions – e.g., the critical business application that must remain on a deprecated (and thus vulnerable) version of an application server. Remediation may entail a significant cost, and thus not pass the cost-benefit test. In most organizations, there are segments of the attack surface that should not be remediated due to operational risk or technology cost. What is essential is that these areas are known, tracked, and ultimately, risk accepted.

7. A comprehensive VM program will yield tremendous ancillary benefits across cybersecurity, infrastructure, and beyond.

If VM is driven by cybersecurity, throwing tranches of prioritized, risk-based vulnerabilities over to infrastructure and application teams, the problem will never be solved. As noted in points 1 and 2, VM is fundamentally an ITSM challenge. It will be addressed far more efficiently and cost-effectively when led with an infrastructure focus, rather than a cyber focus.

Excellence in vulnerability management will yield benefits throughout the infrastructure and application ecosystem. It provides an exquisite opportunity for the odd couple of CISO and CTO to lobby for executive support jointly. The investment in ITSM improvements will yield savings in support and licensing, better infrastructure health and hygiene, and a more complete and accurate CMDB.

The cybersecurity risk involved in VM supercharges the justification for infrastructure to achieve goals that may never have been funded and/or accepted by stakeholders when lobbied from an infrastructure-only perspective.

Furthermore, the benefits extend across many areas of cybersecurity. The table below how the different areas of a robust VM program (X-Axis) positively impact the major areas of the NIST control framework (Y-Axis).

*Numbers indicate relative impact

Vulnerability management is both the most straightforward and most complex area of cybersecurity. This is mainly because cyber has virtually no control over the remediation of risk, as that falls primarily to infrastructure, and to a lesser extent, application teams and other stakeholders. Risk-based remediation should be replaced with risk-based, longer-term investment, as vulnerabilities (and solutions) are continuously published across all operating systems and widely used software packages. By cleaning up the infrastructure estate through targeted campaigns and establishing ongoing services with acceptable SLAs, nearly all potential VM risk can be addressed proactively… and when the following celebrity vulnerability is announced, the response will be much closer to a “push of the button” scenario vs. an “all-hands-on-deck” scramble.