IPS vs. IDS: Similar on the Surface, Polar Opposites Underneath

By Brian Smith, Chief Architect, TippingPoint

A common notion is that an Intrusion Prevention System (IPS) is nothing more than an Intrusion Detection System (IDS) deployed in-line with blocking capabilities. Although IPS and IDS both examine traffic looking for attacks, there are critical differences. IPS and IDS both detect malicious or unwanted traffic. They both do so as completely and accurately as possible, at the speed of the network. But an IPS is an in-line device designed for automatic enforcement of network policy, whereas an IDS is an out-of-band device designed as a forensic tool for security analysts.

This difference in deployment and utility has two direct consequences:

(1) it changes the emphasis on device design requirements, and

(2) the methods hackers use to attack the devices.

Not surprisingly, these changes lead to different engineering designs and technology that may be ideal for IDS but may be sub optimal for IPS, or vice versa. IPS and IDS share four basic requirements:

• Stability
• Deterministic Network Performance
• Minimize False Negatives
• Minimize False Positives

Although these requirements appear to be similar, the differences between IPS and IDS deployment and purpose cause substantial distinctions in prioritizing the requirement, the meaning of the requirement, and implementation options available for meeting the requirement.

Stability: Network Outage vs. Security Analyst Annoyance

Although both an IDS and an IPS should be stable, the effect of an IPS crash is dramatically different from an IDS crash. If an IDS crashes, it is annoying to the security engineer and causes a temporary security blind spot until the device reboots. If an IPS crashes, the network may go down. Consequently, product stability takes on a much higher priority for an IPS than for IDS.

Deterministic Network Performance: Peak vs. Average Throughput Design

Network performance has two dimensions: throughput and latency. Throughput is the processing capacity of the device, measured in packets per second (pps) or bits per seconds (bps). Latency is the amount of time between when a packet is received and when it is processed and released.

For out-of-band IDS, the processing capacity must at least match the average network load. Latency between capture and reporting can range from a few seconds to a few minutes. To meet these requirements, out-of-band devices like IDS’s can absorb temporary bursts in traffic by storing packets in large memory buffers. A buffering implementation reduces the strain on the IDS. With no buffering, the IDS would have to match the network’s peak load, which is typically five to 10 times higher than the average load.

Because an IDS is a logging device – it provides data to humans – the time delay between receiving a packet and logging an alert can be a few seconds without causing any harm. Indeed, in many environments, delays up to several minutes are acceptable. With these latency requirements, large buffers can be used.

For an in-line IPS, the processing capacity must match peak network load and the latency must be on par with that of the fastest connection on that network. In the network core, this typically means one or more Gbps of processing capacity and latency under 200 microseconds. At the network edge, the throughput requirement drops to a few hundred Mbps and latency can be on the order of one to 10 milliseconds. If IPS throughput is less than peak load, the IPS will be a bottleneck in the network. If the IPS adds significant latency, application response time and TCP throughput will suffer.

False Positives: Wasted Time vs. Blocking Legitimate Traffic

All IPS and IDS vendors strive to reduce false positives. But the meaning and importance of “false positive” is different for IPS and IDS. The difference stems from the design goals of IDS and IPS. An IDS is designed to alert a security analyst of suspicious behavior. An IPS is designed to mitigate attacks in real-time.

An IDS false positive is an alert that did not result in an intrusion. It may be that the system under attack was not vulnerable to the attack, or that the detection mechanism may be faulty, or that the IDS detected an anomaly that turned out to be benign. An IDS false positive causes a security analyst to expend unnecessary effort. When an IPS has a false positive, the primary concern is that legitimate traffic will be blocked. Most organizations consider blocking legitimate traffic a much more serious problem than generating a false alarm. Consequently, an IPS false positive is a much more serious matter than an IDS false positive. If an IPS blocks legitimate traffic more than a few times, it will be yanked out of the network.

This difference changes the priority that a vendor places on false positives and puts significant burdens on the filter writing and test teams. The IPS filter teams ask themselves not just “will this filter detect the attack?”, but also “is there any way legitimate traffic could match this attack?” The test team extensively tests the traffic against terabytes of customer traffic, looking for matches of legitimate traffic.

The difference between IDS and IPS false positives also means that some types of filters that are appropriate for IDS are not appropriate for IPS. IDS filters create leads on suspicious activity intended for a human to follow. IPS filters are used for automatic action such as blocking traffic or quarantining an endpoint. The difference is suspicious activity versus actionable intelligence. Any filter that detects suspicious activity, but might trigger a false positive, is appropriate for an IDS but inappropriate for an IPS. This means that most protocol or behavioral anomaly filters that are good for IDS are poorly suited for IPS because the intelligence is not actionable.

Some types of IDS false positives are not IPS false positives. If an IDS alerts on a real attack but the target is not vulnerable, it’s a false positive. But if an IPS blocks that same traffic, it’s not a false positive. In fact, blocking the traffic is beneficial since it reduces network load. Similarly, if an attacker crafts a stream to generate an alert on the IDS, that’s a false positive. But when an IPS blocks the crafted stream, it is not a false positive.

False positives create a potential vulnerability for the IDS. If a hacker can induce a false positive in an IDS, they can launch a “snow blind” attack. In a snow-blind attack, hackers craft traffic that creates confusing alerts on the IDS console. Ideally, they hide both the source, target and type of attack. While lighting up the IDS console, the attacker launches a real attack. The challenge for the security analyst is to somehow see the real attack amidst the chaff caused by the attacker. Alternatively, if a hacker attempts to snow-blind an IPS with a crafted stream, the IPS will block the crafted packets as well as the real attack.

The thrust of this section can be summarized in three rules:

• An IPS must have no false positives; an IDS “minimizes” false positives. This dramatically changes the writing and testing of the filters.
• An IPS false positive blocks legitimate traffic; and IDS false positive alerts on an intrusion that did not – or could not – succeed.
• Anomaly filters cannot be used for blocking, only for alerting.

Minimize False Negatives: Network Performance vs. Decoding Fidelity

A false negative is simply a missed attack. Clearly a false negative is undesirable, and every vendor strives to provide as complete coverage as possible. However, there is no silver bullet: no product detects all attacks. Hence, the goal becomes providing coverage for high priority attacks.

When prioritizing attack coverage, every vendor assesses three things:

• Is the attack important to customers?
• Can the engine do it without adverse impact?
• Is the filter writing team capable of researching and writing the filter?

A useful metric when evaluating IPS protection capabilities is to examine their coverage of important/critical Microsoft Tuesday vulnerabilities. Since these vulnerabilities are important to every vendor’s customers, the vendor will prioritize development of these filters. The only reason not to provide coverage is if the engine is inadequate, or the team is incapable.

Besides lack of coverage, there are several other reasons for a false negative. The attack may incorporate obfuscation techniques in order to evade the IPS or IDS. In the case of IDS, the IDS may be overwhelmed with traffic beyond its processing capacity and drop the packets needed to detect the attack. With an in-line device, overwhelming the device has a different effect: it causes traffic to be dropped. The attack does not succeed, since the attack packets are dropped, but it is also not detected.

IDS: Theory vs. Reality

IDS vendors often confuse the issue of fundamentally different design requirements with theoretical discussions. Examples of this confusion are found in statements like:

• “IDS’s are based on protocol decoders versus IPS’s, which are based on pattern matching,”
• “Whether or not a product can detect a certain anomaly (e.g., HTTP or encrypted traffic on a non-standard port),” or
• “Whether or not a product is resistant to a particular evasion”

They will utilize crafted traffic that causes false alerts and otherwise focus on minutia in order to divert the discussion from the basic mission of each product. These arguments often degenerate into ideological discussions. The “protocol decoders are better” argument is a good example of these tactics. Protocol decoders are simply state machines that decode structured network communication. Knowledge of the protocol’s structure is encoded into a state machine. Alerts are generated by comparing the values output by the decoder to “threshold” values (for anomaly detection), or by comparing them to the combination of values that trigger known vulnerabilities.

Summary

This paper describes many critical differences in the nature and priority of IPS and IDS requirements. For an in-line device, stability and performance are paramount. Even if an IPS had perfect detection capabilities and no false positives, if the latency was too high, throughput too low, or the product was unstable, then it simply doesn’t matter. The device will never be deployed in-line.

Therefore, the prioritization of requirements for an IPS is, and must be:

1) Stability

2) Deterministic Network Performance

3) No False Positives

4) Minimize False Negatives

For an IDS, the prioritization of requirements is:

1) Minimize False Negatives

2) No False Positives

3) Deterministic Network Performance

4) Stability

Note the second list is the exact opposite order of the first. These differences in priority have ripple effects that shape the definition of product requirements; their priority when making tradeoffs in the design of the products; the technology used to engineer products; and the organizations that build, test, and support them. When push comes to shove and engineering tradeoffs must be made, an IDS and an IPS will always be designed differently.

TippingPoint avoids ideological discussions and focuses on the pragmatic issue of building a product to the prioritized requirements of an in-line IPS: stability, performance, no false positives, and minimizing false negatives. It should be understood, however, that TippingPoint uses protocol decoders if absolutely necessary, but leans towards technologies that have as much field experience as possible because they improve product stability and performance. TippingPoint believes this is consistent with the design objectives of a true IPS.

The final decision lies in the hand of the customer and their intended use of the product:

• If the customer desires a product that will provide them with alerts and anomaly information, they should buy an IDS and go in eyes wide-open, realizing that the product was never designed to go in-line, and that there will be significant, show-stopping challenges if in-line deployment is attempted.
• If a customer wants a product that can go in-line and mitigate attacks in real-time, they need to buy a product engineered from the ground up for that purpose and understand that it will not alert them on every bit of suspicious activity.

If they want both, they should buy a purpose-built IPS and place a purpose-built IDS behind it.