🥐

Book Review: Practical Vulnerability Management

Vulnerability Scanning

The first step of vulnerability management is getting a view of all your assets.
One way to do this is to use Scanners, or Vulnerability Scanners.
Vulnerability Scanners scan every device on the network to discover OS and services running on the machine.

Setup

We can either have a single scanning, and configure all firewall rules to allow the scanning traffic, or we can have multiple scanners in different segments of the network.
Depending on the complexity of the network, one approach might work better than the other. For example, if you have a large enterprise network with multiple network segments, it will be better to have multiple scanners in each segment, as opposed to configuring a special firewall rule to let a single scanner reach all the networks, which could pose a security vulnerability.
Scanning should also have unfettered access, instead of of trying to emulate an attacker with limited visibility. Always assume the worse case scenario.

Vulnerability Information

Once you have information about your assets, the next step is to get a collection of vulnerabilities. There are two good sources of information for this
  1. CVE database
  1. Exploit DB
Both serve different but important purposes. A CVE database is a collection of vulnerabilities a software has, but not all vulnerabilities have an exploit POC. Exploit DB is a collection of exploits that target a certain CVE.
By collecting CVEs and Exploit Information, you can have a better sense of which vulnerabilities to address first.
  1. Assets with CVE and a corresponding Exploit
  1. Assets with CVE score above X
  1. Assets with CVE score below X
  1. Assets with no CVE but are outdated (more patch management than vulnerability management)
By addressing the list, you ensure that all assets are patched to the latest version, and have their vulnerabilities addressed. But what does addressing a vulnerability mean?

Addressing Vulnerabilities

There are broadly 4 main ways of addressing vulnerabilities
  1. Patching
    1. Updating the software to the latest version that address the vulnerability
  1. Mitigating
    1. Mitigating the impact of the vulnerability. For example if a server was vulnerable and could potentially be exploited, you can limit the network connections it has with other machines so that if the server does get exploited, the blast radius is minimised
  1. Removing
    1. If the vulnerability cannot be patched or mitigated, we can consider remove the component entirely and replace it with something else. For example using a new software from another vendor
  1. Transferring
    1. instead of “rolling your own” implementations and applications, you can outsource services to other companies and transfer the risk to them. For example, instead of hosting server on premise which has the risk of downtime, we could host servers on the cloud instead, the risk of downtime is transferred to the web hosting providers with agreed upon SLAs
  1. Accepting
    1. You accept the risk and do nothing about it. Hopefully not because of incompetence, but because its been evaluated that in the worst case scenario, the damage would not be too bad
    2.