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
Let’s explore each step in more detail.
- 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:
- 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. - 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. - 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.
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