Patch me if you can: the six steps of vulnerability management

This is the second post in a three-part series on vulnerability management. In this post, elevenM’s Theo Schreuder describes the six steps of a vulnerability management program.

In the first post of this series, we explored why vulnerability management is important and looked at key considerations for setting up a vulnerability management program for success. In this post, we’ll step you through the six steps of vulnerability management.


The six steps of vulnerability management

The six steps of vulnerability management [Source: CDC]

Let’s explore each step in more detail.

  1. Discover vulnerabilities

The most efficient way to discover vulnerabilities is to use a centralised and dedicated tool (for example, Rapid7 InsightVM, Tenable, Qualys) that regularly scans assets (devices, servers, internet connected things) for published vulnerabilities. Information about published vulnerabilities can be obtained from official sources such as the US-based National Vulnerability Database (NVD), via alerts from your Security Operations Centre (SOC) or from external advisories.

Running scans on a regular basis ensures you have continuous visibility of vulnerabilities in your network.

 

2. Prioritise assets

Prioritising assets allows you to determine which remediation actions to focus on first to reduce the greatest amount of risk within the shortest time and with least budget.

Prioritisation of assets relies on having a well-maintained asset inventory (e.g. a Central Management Database or CMDB) and a list of the critical “crown jewel” assets and applications from a business point of view (for example, payroll systems are typically considered critical assets). Another factor to consider in determining prioritisation is the exposure of an asset to the perimeter of the network, and how many “hops” the asset is from an internet-facing device.

 

3. Assess vulnerability severity

After devices are scanned, discovered vulnerabilities are usually be assigned a severity score based on industry standards such as the Common Vulnerability Scoring System (CVSS) as well as custom calculations that — depending on the scanning tool — take into account factors including the ease of exploitability and the number of known exploit kits and plug-and-play malware kits available to exploit that vulnerability. This step can also involve verifying that the discovered vulnerability is not a false positive, and does in fact exist on the asset.

 

4. Reporting

When creating reports on vulnerability risk, it’s important to consider different levels of reporting to suit the needs of different audiences. Your reporting levels could include:

  1. Executive level reporting
    This level of reporting focuses on grand totals of discovered vulnerabilities and vulnerable assets, total critical vulnerabilities, and historical trends over time. The aim is to provide senior executives with a straightforward view of vulnerabilities in the network and trends.
  2. Management level reporting
    For individual managers and teams to manage their remediation work, it helps to provide them with a lower-level summary of only the assets they are responsible for. This report will have more detail than an executive level report, and should provide the ability to drill down and identify the most vulnerable assets and critical vulnerabilities where remediation work should begin.
  3. Support team level reporting
    This is the highest resolution report, providing detail for each vulnerability finding on each asset that a support team is responsible for. Depending on the organisation and the way patching responsibilities are divided, splitting out reporting between operating systems (below base) and application level (above base) can also be advantageous as remediation processes for these levels can differ.
A sample management-level vulnerability report generated using Tableau

 

5. Remediate vulnerabilities

“The easiest way to get rid of all of your vulnerabilities is to simply turn off all of your devices!”

– origin unknown

Remediation can take a variety of forms including but not limited to changing configuration files, applying a suggested patch from the scanning tool or even uninstalling the vulnerable program entirely.

There may be also be legitimate cases where a vulnerability may be exempted from remediation. Factors could include:

  • Is the asset soon to be decommissioned or nearing end-of-life?
  • Is it prohibitively expensive to upgrade to the newest secure version of the software?
  • Are there other mitigating controls in place (e.g. air-gapping, firewall rules)
  • Will the required work impact revenue by reducing service availability?

 

6. Verify remediation

Are we done yet? Not quite.

It doesn’t help if — after your support teams have done all this wonderful work — your vulnerability scanning tool is still reporting that the asset is vulnerable. Therefore, it is very important that once remediation work is complete you verify that the vulnerability is no longer being detected.

Stay tuned for the third and final post in the series, in which we discuss common challenges and considerations for a well-functioning vulnerability management program.


Read all posts in the series:
Patch me if you can: the importance of vulnerability management
Patch me if you can: the six steps of vulnerability management
Patch me if you can: key challenges and considerations

 

Patch me if you can: the importance of vulnerability management

This is the first post in a three-part series on vulnerability management. In this post, elevenM’s Theo Schreuder explains why vulnerability management is so important and outlines some key considerations when establishing a vulnerability management program.

In 2017 the American credit bureau Equifax suffered a breach of its corporate servers leading to customer data being leaked from its credit monitoring databases. The fallout from the breach included the exposure of the personal information of almost 150 million Americans, resignation of the company CEO and a reputation battering that included a scathing report by the US Senate.

The breach occurred due to attackers exploiting a vulnerability in the Apache Struts website framework — a vulnerability that was unpatched for over two months despite a fix being known and available.

With a proper vulnerability management program in place Equifax could have prioritised remediation of the Apache Struts security patch and prevented huge impact on consumers, to its reputation, and saved US$575 million in eventual legal settlement costs.

It’s little wonder that vulnerability management features heavily in well-respected cyber security frameworks and strategies, such as the NIST Cybersecurity Framework and the Australian Government’s Essential Eight. Equifax has also come to the party, putting a program in place: “Since then, Equifax said that it’s implemented a new management system to handle vulnerability updates and to verify that the patch has been issued.”

So what is “vulnerability management”?

Vulnerability management is the end-to-to end process from the identification of vulnerabilities in your network to the verification that they have been remediated.

The first priority in vulnerability management is to scan the network. And by the network we mean everything. Servers, routers, laptops, even that weird voice-controlled air-conditioning system you have in your offices. Having visibility of unpatched vulnerabilities in your network allows you to prioritise patching and prevent potential breaches.

In subsequent posts in this series, we’ll step through the key elements that comprise the vulnerability management process and discuss some key challenges and considerations for a well-functioning program.

For now, here are two key consideration when starting to think about establishing a vulnerability management program:

Firstly, it is important to be clear and transparent about the true state of risk in your environment as nothing will get done if the risk is not pointed out. Even if a vulnerability is “risk accepted”, it needs to be continuously logged and monitored so that if a breach occurs you know where to look. Visibility of where the greatest vulnerabilities lie encourages action. It’s easy to fall into an “out of sight, out of mind” approach when you are not getting clear and regular reporting.

Secondly, In order to get this regular reporting, it is advantageous to automate as much as possible. This reduces the effort required to create reports on a regular basis, freeing up resources to actually investigate and analyse vulnerability data.

Stay tuned for the next post in the series.


Read all posts in the series:
Patch me if you can: the importance of vulnerability management
Patch me if you can: the six steps of vulnerability management
Patch me if you can: key challenges and considerations