During the last 3 months I got more times than expected in discussions about patch and vulnerability management. I need to say, there is much misunderstanding going around about these two processes; so much that I could argue that several organizations are exposing themselves significantly, just because the touch points and (lack of) dependencies in these two processes are not clear.

Patch management

Software vendors release patches to address known flaws in their software. When we are talking about "security patches", we refer to patches that fix security flaws. It goes without saying, these need to be evaluated. The evaluation in this case must be among the lines of "we patch unless there is a known and documented reason not to". Practically, the trigger for the evaluation and application of security patches must be the release of the patch by the vendor, and not some vulnerability scan.

Of course there are cases that a security patch will not be applied; but these cases have to be linked to an evaluation that highlights which specific problems may be caused by the application of the patch. This evaluation is an input to the Vulnerability Management process.

Vulnerability scanning

Many companies use vulnerability scanning as the first step of their Vulnerability management process. Even worse, some take it as the first step of the Patch Management, using the results of the Vulnerability scan as an input to patch management. This could not be more wrong! A vulnerability scan will find known published vulnerabilities; and these should be kept to the minimum. This is not the only way to find vulnerabilities. One may subscribe to vulnerability reporting services, but this is not much different to what a vulnerability scan does.

Vulnerability disclosure

Although there is no established and agreed standard, most vulnerability researchers try to perform "responsible vulnerability disclosure". The rule is simple: Vulnerabilities become public knowledge 90 days after they are reported to the vendor, or after the vendor makes them public. This usually comes with the patch release. If that is not clear, when your vulnerability scan finds and reports a vulnerability, it is already public knowledge, people (and that means: attackers) already know about it and a corrective patch, may already exist. This corrective patch (if it exists of course), should have already been applied to your systems!

Vulnerability management

Vulnerability scanning is the easy part. It is the easiest because it is largely automated. Most of the existing solutions are agent based, cross-checking the applications installed on the system to vulnerability databases, such as the National Vulnerability Database or several other OVAL repositories.

A vulnerability identified by such a scan, can only be one of these three cases:

• A known vulnerability, for which a patch exists and should have been applied. If you find your vulnerability scanning reporting more than a couple of vulnerabilities per system, then you need to fix your patch management process before anything else.
• A known vulnerability, for which a patch exists and has not been applied intentionally. This is usually the case when a patch can not be applied, due to incompatibilities or other problems that it may cause to a business application / process.
• A known vulnerability, for which a patch does not exist.

The last two cases are exactly where the difficult parts of the vulnerability management process must kick in; the evaluation and the decision.

Risk management concepts in vulnerability management

Most vulnerability scanning solutions use CVSS for the rating of the vulnerabilities. This is a good rating model, that also has provisions for risk management concepts. The "Environmental Metric Group" takes into account the Security Requirements of the affected assets. This can be used to describe the "impact", in case the vulnerability is exploited. The "Temporal Metric Group" takes into account the exploitability of the vulnerability. This can be used to estimate the "likelihood" of the vulnerability exploited. With this approach, you can follow any risk management method you wish, even without moving away from the CVSS concepts and rating at all if you prefer.

Regardless if you decide to use a different risk management approach, you need to finally decide what to do with the vulnerability that you cannot patch. Will you accept the risk and do nothing? Will you avoid the risk by removing the vulnerable elements from your environment, thus modifying the attack surface? Will you mitigate the risk by other means?

These other means usually come in the shape of network modifications. Sometimes it may be as easy as adding some rules in your WAF or IPS. Some other times you may consider to fully isolate the vulnerable application or system from the rest of teh environment, a method usually called ringfencing.

Are there any touch points between Patch management and Vulnerability management?

Yes, but they are well defined. Patch management is an independent process. It needs to be established when systems go live, regardless of vulnerability management. Patch evaluation is an input to the vulnerability management process. Ideally you would execute the vulnerability management process before a vulnerability scan finds any vulnerabilities.

Managing the vulnerability does not always remove it. Your vulnerability scan will find this, and other vulnerabilities for which patches do not exist yet. You have to exercise risk management to handle these vulnerabilities, taking into account the risk appetite and the capabilities of the organization.

In the end, do not wait for your scan to find vulnerabilities. This will become unmanageable in no time. Focus on proper patch management and that would streamline the operations significantly.