"30 Days" seems to be the default amount of time organizations look for vulnerabilities to be patched by. Version 1.1 of the Payment Card Industry standard specifically states a 30 day time period. Of course the actual age of a vulnerability has nothing to do with how easy it may or may not be to exploit, but politically, old vulnerabilities can indicate broken policies, bad IT processes and lapses in compliance.
This blog entry discusses how networks can be monitored for vulnerabilities with Nessus, the Passive Vulnerability Scanner and the Security Center in such a way, that vulnerabilities older than 30 days can be easily identified.
The Vulnerability and Patch Life Cycle
IT organizations that "get it" run their networks with the expectation that there are vulnerabilities in their required technology that have not been found or publicized yet. As such they use compensating controls such as firewalls, auditing, system hardening and intrusion prevention to mitigate these risks.
When a specific vulnerability is discovered and a patch has been published, a political "clock" can start ticking which measure how long it takes to get this security patch applied.
In some organizations, all security patches are required, even if there are other mitigating controls. I've seen organizations require applying a patch for Apache on a production Red Hat server, even though the system wasn't actually running the web server. The idea is that if a web server is enabled one day, it should be patched ahead of time. Other organizations only require security patches for technologies they are exposed to.
Ensuring Nessus has the Most Recent Checks and Credentials
If you are scanning with Nessus to look for out-of-date vulnerabilities, you should realize two major concepts:
- If you are using the registered feed, your checks are already 7 days old
- If you are not using credentials you won't be able to do a patch audit
If you are measuring the age of your vulnerabilities, you should be doing this with the most recent plugins available to you. I've spoken with customers who only update their plugins once a month or even less often. They take comfort in that Nessus gives them very useful data without being updated. This is sort of like getting your car's brakes checked, but then telling the mechanic not to check the oil.
Just because Nessus is finding very useful information, doesn't mean that it is testing for everything that it could. Regardless if you are using the real-time Direct Feed or the seven-day delayed registered feed, updating your Nessus plugins before a scan will always provide a more complete audit than not doing so.
If you are updating your plugins and using the registered feed, all of your checks are one week old. There is great value in the more than 15,000 plugin checks Tenable provides for free to the Nessus community, consultants and MSPs, but if you are using it to find vulnerabilities older than 30 days, you need to actually look for vulnerabilities older than 23 days.
And lastly, when you use Nessus to audit a host or network, unless you give it credentials of the target systems, it won't perform a full security patch audit. Depending on the vulnerability, Nessus may identify a specific missing patch, but it is not performing a full audit. Other security patches may only be found with credentials, especially client-side applications such as Internet Explorer or Thunderbird.
Using Nessus to audit missing patches is a great way to see if your patch management system is working, to perform a more complete vulnerability audit and to also gather many configuration parameters which also impact security.
Manually Finding 30-day Old Vulnerabilities With Nessus
There are many manual methods for using Nessus to find vulnerabilities older than 30 days.
Determining this strictly from one single scan is doable but difficult. Technically, someone can take the results of a scan and check when each plugin ID was first released. This can be manually intensive and actually tests when Tenable releases a plugin and not when a vulnerability was first discovered. Consider a situation where someone enables an older Apache 1.3 server for which has vulnerabilities that are several years old. Your organization may still allow this system to be patched within 30 days. If you are being governed by PCI, compliance requires all security patches to be installed based on patch availability, not on discovery of vulnerabilities.
A more common technique is to look at how a network's discovered vulnerabilities changes over time. Differential analysis from two or more scans measures what has been fixed (patched), what vulnerabilities are still present and which are new.
If you are performing these types of scans, remember to scan often. If your scan period is once a week, and you are looking for 30-day old vulnerabilities, a new vulnerability may have been discoverable the day after your last scan.
On larger networks, which have many different types of assets, manually keeping track of which scan policies go with which targets, which credentials go with which targets and how often each target can be scanned can be difficult. I've spoken with several organizations who've developed their own scan tracking and management solutions, and I've also worked with many Tenable customers who use the Security Center to tackle this problem.
Some Nessus clients support some level of scan differential reporting. This process takes the results of two scans and shows what is different about them. This is helpful if you are scanning the same target, with the same plugins. If you are not performing the same type of scan (such as performing a basic OS fingerprint scan as compared to a full patch audit), then your results will certainly be different.
Below is a screen shot of the Nessus 3.0 scanner for Windows:
|
Multiple reports can be selected and a differential report produced.
When differences are found, the systems with older vulnerabilities or missing patches should be tracked in a report, spreadsheet, ticketing system or some other method.
Manually Finding 30-day Old Vulnerabilities With the Passive Vulnerability Scanner
The Passive Vulnerability Scanner (PVS) can also be used to monitor networks for 30-day old vulnerabilities. Compared to active scanning with Nessus, the PVS has very little configuration or on-going management and it does not require credentials or scan management. Once set up, it continuously sniffs vulnerabilities in your servers, applications and clients.
The Windows version of this tool can be used to take a "snapshot" of the existing vulnerability report. Any two reports can be "diffed" to see what has changed. Choosing two reports that are 30 days apart can easily show which vulnerabilities have not been addressed.
Below is a screen shot of the Windows PVS report differential options:
|
Automatically finding and reporting 30-day Old Vulnerabilities with the Security Center
Performing this process of discovery on the Security Center (SC3) is very easy. SC3 can be used for automated scan scheduling. Multiple scan policies, scan targets (networks or assets) and scan schedules can be configured and automatically spread across multiple Nessus scanners. The results of these scans are always automatically "diffed" with the current cumulative set of discovered vulnerabilities.
The "cumulative database" inside SC3 is its key to making vulnerability discovery, trending and reporting very simple. It uses the results of different types of one-time and ongoing scans to build up an accurate model of the entire set of vulnerabilities on the network.
When analyzing this set of vulnerabilities under SC3, there are simple filters which can be used to display when a vulnerability was first discovered. Since only "live" vulnerabilities are stored in the cumulative database, this filter is an easy way to show which vulnerabilities are 30 days old. Below is a screen shot all existing vulnerabilties which were discovered on a live SC3 system more than 30 days ago:
|
Also in the above screen shot that the [CVS] link can be used to get a list of all vulnerabilities older than 30 days into a convenient spreadsheet.
This sort of filtering can show which assets are out of date, can be used to download a list of hosts as a spread sheet, and can be combined with other filters such as Nessus plugin family or vulnerability severity. If your assets are aligned with your political organizations, this can also show which groups aren't patching on time. And lastly, SC3 can be used to automatically email reports of this type to one or more recipients and asset owners.
If multiple Nessus scanners or multiple Passive Vulnerability Scanners are used, SC3 automatically combines the results of these into one cumulative view. This can help compensate if network monitoring or network scanning isn't as comprehensive as it could be.
The ability to find systems with vulnerabilities discovered within a certain set number of days can also be used to create a Dynamic Asset List. These lists can be used for reporting, filtering vulnerabilities and also scan scheduling. Having SC3 perform full daily scans of just the systems with older vulnerabilities is a good way to automatically clean up older vulnerabilties. With this sort of asset list, automatic ticketing or even re-casting of existing vulnerabilities can be accomplished.
For More Information
If you felt the content of this blog was useful, please consider these other blog entries:
