icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons_061

Good and Bad uses of Vulnerability Data for IDS Event Correlation

‹ Previous Post
Using PVS to detect Corporate policy violations
Blog Home
Next Post ›
CVSS Scores in Nessus Plugins

About once a month, Tenable gets a call from an MSP, IDS vendor or SIM vendor that wants to take the output of a Nessus scan and do "correlation". The concept is to do something more intelligent with the IDS events with the knowledge of what is actually on your network.

Tenable has several products in this space and has also written several whitepapers on this topic. Over the past few years, we've also seen several approaches in SIMs and IDS/IPS solutions that have used techniques which can very misleading. This blog entry discusses some of the issues we've seen and how we've overcome them in Tenable solutions.

Correlating based on the Target OS

One of the easiest concepts to understand is to use the idea of the detected operating system of a target to "throw away" or "decrease the severity" of IDS events which won't have any effect. For example, if you have a "UNIX" attack heading to a "Windows" server, the attack is less likely to succeed.

Although, easy to understand, this can be very misleading. Consider the following implementation details:

  • How accurate is the OS detection? We don't want to mis-classify IDS events because our Solaris server was misclassified as a Linux server. This occurs more often than people realize because there aren't enough ports open to identify an OS or there are true "proxies" in place.
  • What do you do with cross-platform applications such as Apache, MySQL or even iTunes?
  • If I am running a 100% UNIX network, or 100% Windows, .etc, this technique may help throw away some IDS events, but, a good NIDS administrator would have disabled the attack rules for the OSes not running on their network.

Perhaps the most misleading implementation of OS detection is to derive the vulnerabilities associated with the OS purely based on its signature. For example, one could actively or passively fingerprint an OS X server and then associate all vulnerabilities ever released for that OS as being "live". If someone patches these vulnerabilities, the OS fingerprint never changes and IDS events could be incorrectly elevated or de-emphasized.

Correlating based on the Application version and/or known Service

I feel very comfortable with solutions that accurately measure the presence of specific applications and then associate their known vulnerabilities. The key here is how accurate these applications can be determined. Consider the following technical implementation issues:

  • How often is the system being assessed for the presence of an application? Using an out of date list can incorrectly effect the severity of a correlated IDS event.
  • If the solution is scanning based, how does it handle applications from vendors such as Red Hat which provide patches to services without revising the revision level?
  • Also if the solution is scanning based, does it find off-port services such as SSH running on port 2200 or web servers running on port 8000?

This last issue is very important. We've seen some correlation systems that even throw all IDS events to these ports because they were not in the scanner results. If your correlation system believes that what your vulnerability scanner gives to it is an accurate representation of the network, you should make sure to scan all ports, scan often, and to make sure you are using the latest vulnerability checks.

If you are using Nessus, this means that users should update their Nessus plugins very often and consider using the Direct Feed. If you are using a product other than Nessus, don't assume it is self-updating. make sure you perform an update of the vulnerability checks before performing and inputing a scan into your IDS or SIM solution.

De-emphasizing critical events with old vulnerability data

One theme we've seen in the past two examples is the de-emphasis of IDS events in an incorrect manner. What we would hope for is to correlate accurate vulnerability information with accurate IDS event data.

Consider a typical NIDS solution. It gets updated almost daily with new signatures based on the latest public vulnerability information. If it detects an attack that involves a vulnerability disclosed in the last few days, this could be quite serious. But what happens if the correlation system doesn't have evidence of the corresponding "serious" vulnerability from a network scanner?

A well made correlation system should leave the IDS event as-is since it doesn't have any information to raise or lower its severity level. A correlation system which removed the IDS completely could have very misleading results.

Not using Patch audit data

Something that surprises us at Tenable is the lack of interest in third parties to correlate patch audit data with IDS events. Patch audit data gives some unique types of vulnerability data as compared with a traditional scan. This includes:

  • Extremely accurate vulnerability information, sometimes much more accurate than can be determined with a remote network scan.
  • Client side vulnerabilities, such as security issues with Outlook, Mozilla and Eudora.

More and more IDS/IPS solutions are performing network monitoring for client-side exploits. Using a correlation system which doesn't accept or consider client-side vulnerabilities won't be able to help mitigate "false positives" IDS events or correctly identify serious compromise events.

Not using "Passive" Vulnerability Data

The last technique that many IDS/VA correlation implementations are missing is to make use of passively obtained vulnerability data. By "passive" we mean the process of monitoring the network traffic to accurately conclude vulnerability data. Passive monitoring has several advantages over network scanning and credentialed auditing when it comes to VA/IDS correlations.

Passive scanning is "always on" and sees all network traffic. Often a passive monitor will be exposed to the same traffic an IDS/IPS sees. This means at worse, a passive solution sees vulnerability information as soon as it is discovered by a remote hacker. If this data is fed into a correlation system, then the vulnerability data will always be current.

Passive scanning will see all traffic, including activity on ports not normally scanned for. If a server runs a web administration interface on a high port, a passive scanner will learn about this and report on it over time.

Lastly, passive scanning will also see client information which is in use on the network. When network users surf the web, check email or even use P2P software, all of this activity can be identified, usually down to the specific applications and their associated vulnerabilities being used.

IDS/IPS and SIM solutions which overlook the rich data obtained by passive network monitoring miss out on using valuable data for more accurate IDS event correlation.

VA/IDS Correlation with Tenable Solutions

Tenable's Security Center can accept vulnerability data from:

This allows many forms of vulnerability detection to be used for accurate detection of all network vulnerabilities. It can also accept realtime IDS events from Snort, Tipping Point, Dragon, the Cisco IDS/IPS, NFR's Sentevist and IntruSheild. When these events are received, they are correlated in realtime with any relevant vulnerability on the target port or client of the attacked system.  A video demo of this process can be seen here.

If your organization is running Snort IDS sensors, the Security Center can also be used to push signatures from the Sourcefire VRT signature set and/or the Bleeding Snort signature set. The Security Center can push either the latest available signatures, or only push the Snort rules for which you network has vulnerabilities. This allows your Snort sensors to run with less rules.

If this was useful to you ....

Tenable has several whitepapers and available webinars on this topic.

As always, if there is interest in learning more about Tenable product offerings, please contact us at sales@tenablesecurity.com. Besides VA/IDS correlation in the Security Center, Tenable also offers a variety of correlation solutions for many log and network sources in the Log Correlation Engine.

Filed Under: