The problem with network intrusion-detection systems (NIDSes), as any frustrated security manager knows, is they generate a lot of false positives, false alerts, false alarms, etc. It's hard to separate the wheat from the chaff.
Most commercial NIDSes depend on attack signatures to identify malicious or out-of-policy activity. Signature-based NIDS is a very CPU-intensive technology. Before comparing packets against the NIDS database of a thousand or more signatures, the sensors also have to perform a variety of compute-intensive operations such as HTTP normalization, converting URLs in HTTP data streams to a canonical format so that they can be compared against a list of known bad traffic. To keep from losing packets, NIDS signature writers generally only match against the minimum amount of data needed to validate an attack. Until now, the thinking has been that it is better to catch both suspicious and harmless activity than it is to miss something by being too strict on the signature.
Some IDS vendors are working on making their signature and detection engines smarter, but others are taking a different path: target-based IDS. The idea is simple. Take additional information about systems and change the signal-to-noise ratio to increase the signal and decrease the noise. You'd still get an alert for an attack packet, but if the attack were simply noise, the alert would be given a low priority.
Early entries in this field include Tenable Network Security's Lightning Console, Cisco Systems' Cisco Threat Response (CTR) and Internet Security Systems' Fusion. These products combine traditional network scanning and vulnerability analysis with IDS alerting consoles. They all take in the raw alerts from your IDS consoles, but they "qualify" each alert based on whether your system is actually vulnerable. The result: Far fewer alerts and analysis in minutes instead of hours.
Let's take a look at the nature of the beast these new tools are trying to tame.
IDS engineers get very picky about terminology. The term "false positive" is reserved for places where the IDS actually made an error -- where the IDS claimed that an attack attempt occurred, but no such attack really happened.
False positives, though, are not the same as "noise:" false alarms, false alerts, glare -- positive detection of attacks that are contextually irrelevant. Since the NIDS sees all traffic, it would be possible for a signature to be expanded so that it only triggers if, for example, it sees a vulnerable application or OS version. But IDS signatures aren't written that way -- start looking at traffic at that level of detail, and you run out of CPU speed very quickly.
Target-based NIDSes don't depend on expanded signatures, though the early entries we've looked at still have performance issues. All three have the same basic structure:
- A network scanner to collect and manage vulnerability information. The scanner maps hosts on the network, the services each is providing, and their versions and patch levels.
- A network of standard, off-the-shelf IDS sensors.
- A console that matches the alerts from the IDS sensors against the vulnerability information from the network scanners to help qualify alerts for the security analyst.
That said, there are some significant differences, which reflect the immaturity of this technology.
Cisco Threat Response (CTR) was part of Cisco's acquisition of Psionic Software in late 2002, and is in a state of flux. CTR has a major architectural flaw, which Cisco is correcting by pushing CTR technology both into their sensors and their existing management console. CTR's network scanner and vulnerability collection tool and management system all run together in one box. This makes collection of vulnerability information and network scanning difficult in a large network, especially in environments where many LAN segments are linked using both routers and firewalls.
CTR's core behavior is reactive, which is unique among the tested products. In other words, CTR doesn't attempt to determine if a target is vulnerable until it receives an alert. When you set up CTR, you tell it how long to "remember" information it discovers. You don't want to remember things forever because hosts change over time. With CTR, there's a delicate balance between not overwhelming your network with active data gathering and not holding onto old data. You can also periodically launch network and vulnerability scanning to gather information.
ISS' Fusion alert evaluation tool promotes or demotes alerts from its IDS sensor based on information gathered by ISS' Internet Scanner. The solution consolidates management through ISS' Site Protector console, which controls NIDS sensors, host-based IDS sensors, desktop security tools and Internet Scanner. The ISS toolkit was unwieldy to set up, but it has tremendous scalability and flexibility in placing sensors and scanners throughout a large enterprise network.
Tenable's Lightning Console works with third-party IDS sensors as well as open-source Snort and Bro. Lightning Console can work with the open-source Nessus scanner, or its NeWT (Nessus on Windows) or NeVO (its passive scanner). The NeVO passive scanner strongly differentiates Lightning Console from CTR and Fusion. NeVO monitors traffic, discovering operating system and stack information, lists of open ports and application information.
While CTR and Fusion watch alerts and then check for relevant vulnerabilities, Lightning Console starts with vulnerabilities, and watches attacks to see if any match up. Lightning Console classifies each event as either vulnerable or not. It's a very black-and-white definition, based exclusively on known vulnerabilities on the target network.
Lightening Console can't be used to manage your third-party IDS sensors, but it does manage the vulnerability scanners Nessus, NeWT or NeVO.
Target-based IDS is in its infancy. Still, if you want to use the alerting function of your IDS system, target-based IDS has an undeniable benefit. In all cases, we saw a significant decrease in the amount of noise, helping us focus more quickly on the alerts that matter.
About the author
Joel Snyder is a senior partner at Opus One, an IT consulting firm in Tuscon. He can be reached at joel.snyder@opus1.com.
MORE ON THIS TOPIC
- From our sister publication Information Security magazine, Taking Aim, an in-depth analysis and review of target-based IDS.
- Pre-register for our live webcast, Advanced intrusion defense with Joel Snyder on Jan. 28 at Noon ET.
- Author Joel Snyder is also speaking at our conference, Information Security Decisions, on the topic of perimeter defense.
