A Non-Technical Look at Patch Management (Part 2 of 2) - WST

This is the second part of a 2 part series on understanding patch management and vulnerability scan results.

Last week, we looked at the complexity of patch management. To recap:

Even a small network has a lot of things to patch
Many updates or patches are released monthly if not more frequently
Patches don’t always install correctly and may need to be reapplied

A baseline test to identify if this process is working as expected is an internal vulnerability scan or assessment. This scans each system, what is installed, and then tells you what patches may be missing, as well as other potential security issues.

A good scan will be thorough and return a lot of information. A good report will summarize this information in useful ways and remove anything extra that is not a vulnerability. Even then, the numbers and results can be daunting, how can a non-administrator read this and understand at a high level enough to know what needs to be addressed?

First, know that there will always be missing patches. Remember from last week that even if you get everything 100% patched (hard to achieve in even the smallest networks), there are new patches released all the time. There will never be “0” findings on this type of scan.

The trick is looking at the summary information and identifying a few things:

How many systems do you have and how many were scanned? This helps you know everything is actually being scanned, and the context of the numbers to follow.
Pay the most attention to Critical and High Risk issues. While other issues can pose a problem, these higher risk vulnerabilities are where problems (breaches) generally start and should be your focus.
What is the ratio of issues to systems? A scan of 50 systems with 50 high risk issues is different than a scan of 5 systems with 50 high risk issues.
A good report should include the age of issues. This is important, as a missing patch released in the past 30 days is probably still in the process of being installed...but a missing patch released over 6 months ago is probably falling through the cracks. Look at how many issues are “new” and how many have been out there for a while and need follow up.
Where available, look at trending, look for significant changes in numbers over time. Remember to look at this with the age of the issues noted above. If numbers went up, but the aging summary shows most issues are less than 30 days old, it probably just means that it was just a busy patch release month.
Are the bulk of the issues identified in a particular brand of software (Adobe, Java, etc.)? This can indicate a product that isn’t getting updated the same as the rest and could be a gap needing investigation.

Remember that the biggest value of vulnerability scan results is identifying gaps and trends in your environment, not necessarily getting a “to do” list. Tracking down individual patches is needed if you have older issues needing follow up, but overall, use the results to see what areas need to be shored up or require additional attention.

Lastly, whoever ran the scan should be able to explain the results to you and answer any questions. One benefit of scans from an outside vendor is getting independent context and insight from someone who scans other organizations like yours.

We hope this has helped provide some illumination on this complicated topic!

Authored by: Jeremy Johnson, OSCP, CISSP