Effective corporate vulnerability management

Lessons learned when setting up enterprise vulnerability management.

I was lucky enough to get the chance to help define the vulnerability management process at a large insurance company. It has been a challenging journey, but we have managed to revive a state-of-the-art vulnerability management process.

The cornerstones of successful vulnerability management are 3 processes: IT Asset Management, Patch Management and Vulnerability Management.

Now let's look at the individual processes in more depth.

IT Asset Management

Knowing the IT assets we actually defend

In the corporate environment, a constant overview of IT assets and their business relationships determines the efficiency of all IT management processes.

Since this also applies to vulnerability management, we need to know all our IT assets as well as who is responsible for mitigating potentially found vulnerabilities on that asset.

If we do not have an easy way to query the owner (responsible) by IP / Hostname, the introduction of such a database is one of the main priorities of the cybersecurity program.

Patch Management

It is good to adopt existing process guideline and not to reinvent the wheel. In our case, the choice was the NIST Guide to Enterprise Patch Management Planning: Preventive Maintenance for Technology NIST SP 800-40. The guidance consists of these 3 key concepts.

Routine patching

Heavy lifting in vulnerability mitigations

The discovery of new vulnerabilities accelerates with lots of aging and new hastily written software. Suppliers then try to deliver patches at an ever faster pace, and the only way to deal with this is to dapt to their pace.

The cycle of this regular activity should therefore be tied to the patch release plan as defined by SW suppliers. For example, certain vendors aligned on releasing patches each second Tuesday in the month, also known as Patch Tuesday.

Emergency mitigations

For vulnerabilities known from "breaking news" such as was the XZ utils backdoor CVE-2024-3094 or Log4j remote code execution CVE-2021-44228, we cannot wait for routine fixes to happen.

We need to act particularly quickly when an IT Asset is exposed to the public Internet

A very effective procedure is to set scoring for each vulnerability and determine the required speed of patch application.

Attributes to consider:

• Severity by Common Vulnerability Scoring System (CVSS)
• Presence in Known Exploited Vulnerabilities Catalog (KEVC)
• Underlying IT Asset exposure (exposed to internet or not?)

By assessing each vulnerability according to these attributes, it will allow us to precisely target the use of scarce resources intended for mitigation.

Un-patchable assets

In the real world, there will be a significant portion of IT assets that a business needs but is unable to provide the resources needed to mitigate vulnerabilities on those IT assets.

Here we must be fully aware of the risk and apply compensatory measures such as:

• Isolation methods like the Micro-Segmentation in NIST Zero Trus Architecture NIST SP 800-207
• Rapid isolation readiness: documented procedures for mitigations which may require deactivating system functionality or isolating an IT Asset from other IT Assets and having automated mechanisms to apply these changes
• Additional host-based or/and web application firewall, advanced security hardening, logging and monitoring

Vulnerability Management

Without constant monitoring of vulnerabilities in our environment, we can hardly talk about an overview. Regularly searching for vulnerabilities in the environment and tracking this information in the database gives us an intelligence about how well we manage vulnerabilities.

This continuous scanning and prioritization to mitigate vulnerabilities found is critical to initiating an emergency mitigation process.

For example, if we have a vulnerability on a publicly exposed IT asset also nown as "exploited in the wild," it's a matter of days before some evil botnet learns about it. The sooner we find and mitigate the vulnerability, the less space we give to the attacker.

In addition to the emergency trigger, detailed information about vulnerabilities can tell us a lot about how good we are at patching and managing vulnerabilities.

The metrics that tell the most interesting stories are:

• Active vulnerabilities - the current state of vulnerabilities. How big a problem we actually have?
• The ratio between recently discovered versus recently mitigated vulnerabilities. Are we getting rid of them or hoarding them?
• Average age of vulnerabilities. Are the patch cycles in place sufficient or do they need to be changed?
• Type, amount and age of delayed vulnerabilities. What are our pain points for which we need some kind of systemic solution?

If properly interpreted by management, these metrics can guide organizational transformations toward advanced vulnerability management.