Detecting Recurring Vulnerabilities
One of the advantages of Tenable’s suite of Unified Security Monitoring products is that continuous vulnerability monitoring can be used to find reintroduced security issues. Vulnerabilities that were once mitigated but are now back again represent process and organizational issues that must be handled differently. Simply reporting the vulnerability again and waiting for it to be patched does not address the fundamental flaw in the process. This blog entry discusses how recurring vulnerabilities are detected, some of the reasons why they may be recurring and how you can track and report on them with Tenable’s SecurityCenter.
Reoccurring Vulnerabilities
Any vulnerability that was once detected, remediated and then rediscovered represents a problem with how system configurations are being managed. Vulnerabilities result from insecure software or insecure configurations. Your IT staff is probably not going around to your desktops and installing software that is purposely vulnerable, so how do these situations happen? There are many potential reasons, including:
- Restarting a service that was vulnerable and disabled. In this case, it is possible that a vulnerable service, such as a web server, was found vulnerable and not needed so it was turned off. Perhaps it was disabled incorrectly and restarted after a system reboot. Perhaps it was disabled because it was not needed, but is needed now and was never patched.
- A new firewall rule may open access to a vulnerable system. Some vulnerabilities can be “virtually” patched by blocking access to them from the Internet and other external networks. If a change to a firewall rule opens a port that was blocking access to a vulnerable service, the vulnerability can reappear on your network and in your scans.
- Software patches can install vulnerabilities. Many software updates include libraries such as .Net, Flash and Java. If these software installations are performed in a manner that downgrades a library that is on a desktop or server, this may reintroduce a vulnerability.
- Virtual appliances based on snapshots and gold builds may go unpatched. The prevalence of VMware and other forms of virtualization makes it possible that a base image for a virtual server or appliance may be out of date and include vulnerabilities. In addition, vulnerabilities can be reintroduced if an appliance is reverted to an earlier state that was not patched.
- Automated software fetching. Some organizations automatically build systems with downloads from the Internet or saved copies of software installation executables. If the software being installed has not been updated in some time, it’s possible that there have been vulnerabilities discovered in it and updates need to be applied.
The “fix” for each of these types of issues goes beyond remediating the specific vulnerability or vulnerabilities found. It involves fixing the process that is re-introducing the vulnerabilities. Before this can be done, you must first be able to identify vulnerabilities that are recurring.
Continuous Vulnerability Monitoring
To keep track of the state of a vulnerability, you have to have relevant and timely data. A vulnerability scanning program that does patch auditing once every 30 days won’t be able to discriminate between a system that has been missing a patch for 29 days and a system that was patched for 1 day, but had some other process overwrite that patch.
With Tenable’s Unified Security Monitoring products, multiple Nessus scanners and multiple Passive Vulnerability Scanners (PVS) can be deployed and managed by SecurityCenter. This allows large and small organizations to tailor a balanced set of active scans, credentialed scans and 24x7 passive monitoring for daily trending of all vulnerabilities. A daily snapshot of changing vulnerabilities allows for high-fidelity graphs of vulnerability trends. For example, this screen capture is from SecurityCenter’s dashboard and shows trends of active, passive and patch audits for a large network:
There is a lot of fidelity in these graphs that show the last 25 days of patch, scanning and passive network monitoring. For example, in the bottom left graph, you can see that there were a larger number of client-side “High” vulnerabilities detected between 5/30/10 and 6/13/10.
Identifying Reoccurring Vulnerabilities
Each time SecurityCenter processes results from a vulnerability import from Nessus or the PVS, it maintains a model if the vulnerabilities for that host have been seen before. Patched vulnerabilities, or at least those no longer detected, are moved to the “Mitigated” database. If a vulnerability has been mitigated in the past but is now active, it can be flagged with a “Was Mitigated” tag that can be used to filter just for these vulnerabilities. An example SecurityCenter filter for this is shown below:
SecurityCenter users can use this filter to create trend charts by asset group, IP range or vulnerabilities. For example, if your organization had five different Active Directory domains, you could create five different vulnerability trends (one for each of your groups) and then create a second trend line of vulnerabilities that have recurred.
The SecurityCenter screen capture below was created by copying the Passive Server, Passive Client and Nessus Scanning dashboard elements and then turning on the “Was Mitigated” filter:
It can be seen that there are different types of vulnerabilities that may have been recurring over the past 25 days. For more detail, SecurityCenter users can drill into this data to create lists of IP addresses, network assets and vulnerabilities to identify patterns or commonalities in these recurring vulnerabilities.
For More Information
If this type of vulnerability trending is interesting to you, Tenable has two recorded webinars that are related to this topic:
Both webinars go much deeper into the issues surrounding these topics. If you would like more information about SecurityCenter or any of Tenable’s Unified Security Monitoring products, please feel free to watch any of our demonstration videos or contact our sales team.