Inflated Image

Will intrusion prevention ever live up to its promise?

Original Article on Information Security Web Site

Intrusion prevention systems (IPSes) are being touted as the latest, greatest savior of the network. And why not? Unlike signature-based intrusion detection systems (IDSes), which passively examine traffic and trigger alerts based on suspicious packets, IPSes perform intense application-layer inspection and actively block identified attacks. Where IDSes are good for after-you've-been-hacked forensic analysis, IPSes protect your digital backside while an attack is in progress.

That's what the marketing brochures say, anyway. The reality, unfortunately, isn't quite so rosy. The state of the art in IPS is promising but immature and incomplete. Characteristic of many emerging markets, there's little vendor agreement about what IPSes are, what they should do and where they should live in the network. Some vendors pitch IPSes as perimeter-based devices intended to replace firewalls. Others position them in front of or behind firewalls in a belt-and-suspenders topology. Still others say IPSes should reside closer to or on the host itself, preventing execution of anomalous kernel commands.

On the enterprise front, the potential usefulness of IPSes is diluted by infrastructure complexity and the impracticality of deploying them deep into the network core. IPSes work as advertised when placed inline on a network segment in which access control, authentication and authorization are already carefully monitored and controlled. On large-scale, cross-platform networks where this isn't the case, an IPS approach to security is less useful.

Given these realities, what's the future of IPS? In a word: hazy. Before I explore what that may mean to you, let's look a closer look at where we are today.

Slice and Dice

For the purposes of this article, I'll focus my analysis on network-based IPSes. Host-based IPSes from vendors such as Cisco Systems, Network Associates, Sana Security and ForeScout Technologies have their own set of benefits and problems, but that's a subject for another time.

What do network IPSes have in common? They're mostly inline devices aimed at responding to anomalous traffic (malicious or not). They block, quarantine or otherwise impede the transmission of this traffic, which, in effect, prevents the execution of "suspicious" code on a target host.

However, while most IPSes sit inline, not every device is truly an inline IPS. Some devices, such as StillSecure's Border Guard, combine firewalling and a reactive IDS to provide quick response but don't evaluate every packet before passing it. Inline is critical in environments where a "single packet kill"--an attack that starts and finishes in a single message--is expected. The Witty, SQL Slammer and Code Red worms all demonstrated what can happen without this capability.

The form and function of IPSes differ in many ways. IPSes can be divided into two broad form-factor categories: stand-alone products, such as those from Tipping-Point Technologies, Network Associates and Top Layer Networks; and integrated products, such as those from Check Point Software Technologies and Secure Computing.

Stand-alone devices are comparatively easy to identify and compare. They are almost always appliance-based, with a custom, hardened OS, application-specific processing and plug-and-play installation.

Integrated devices aren't easily compared, since they combine IPS with other filtering or access control functions in devices such as firewalls, switches and routers. For example, the latest versions of Check Point's FireWall-1 and Juniper Networks' NetScreen-5GT use a combination of firewall and IPS technology. (Both Check Point and Juniper also offer stand-alone IPS devices.)

In today's market, stand-alone devices have greater IPS capabilities and features and better performance optimization to handle high loads. However, the jury is still out on whether these additional features are used by or are useful to enterprise security managers.

From a functionality perspective, IPSes are either rate-based or content-based. Rate-based products block traffic based on load. Top Layer's Attack Mitigator IPS, for example, selectively blocks traffic based on connect rate, connection count and bandwidth consumption. Such devices are useful for stopping DoS attacks and detecting worm-infected hosts searching for more victims.

Content-based IPSes block traffic using IDS-like signatures and anomaly detection. Some content-based devices use or integrate with vulnerability scanners to identify targets, tuning the signature base accordingly. For example, TippingPoint's UnityOne primarily uses a signature database and content-based anomaly detection to identify and drop malicious traffic. UnityOne can also rate-limit the bandwidth allocated to some types of malicious traffic. This feature, which is also present in Inter-net Security Systems' Proventia appliance, gives these devices some hybrid content/rate-based characteristics.

Flawed Approach?

To stop all potential attacks, IPSes must inspect every packet before it reaches the core network. Hence, we see many products that boast some form of "deep packet inspection"--high-end processing capabilities to maintain wire speed, load balancing and high availability (to avoid becoming a single point of failure).

Fundamentally, the argument for inline IPSes is also their undoing: If IPSes must be inline, they must be inline everywhere throughout the network. But, organizations have heavily invested in switched and decentralized networks, and vendors aren't prepared to replace network infrastructure or integrate with it. Even the most ambitious IPS products don't have the port density or backplane performance to economically replace a switching infrastructure.

For complex infrastructures, vendors encourage you to place both internal firewalls and IPS appliances on select network segments. But this is only a partial solution. An inline IPS strategy requires too many boxes and generates too many false positives without justifying the cost or the complexity of distributing IPS throughout your network.

As a perimeter solution, IPSes might be suitable for highly constrained networks, such as an ISP or small business, but are of marginal benefit to large-scale enterprises. For example, an inline IPS placed outside a firewall is useful for dropping attacks, something a well- designed firewall would have done anyway. If, on the other hand, the IPS is placed inside the firewall, it can backstop the firewall and protect application servers. However, neither placement will help against a worm or insider compromise, nor will the IPSes detect threats in encrypted traffic.

Security managers worry about their motley stacks of network devices, with problems ranging from kicked-out power cords and failing network cables to out-of-sync policies and incomplete coverage. The oft-constructed "firewall sandwich"--load balancers, firewalls and multiple switches--is common in large networks. Is it wise, then, to add another box into the mix, increasing the fragility and complexity of the security barrier? How will these new products integrate with or replace the traditional switched Ethernet fabric of business networks when IPS vendors don't have the experience or breadth of product line to replace networking hardware?

Integrated IPSes, such as those from Juniper Networks (NetScreen) and SonicWALL also have little to boast about. For example, firewalls with IPS features defend against threats that the firewall should independently block; their IPS functionality covers only a narrow set of protocols and problems compared to stand-alone inline IPSes. As firewall vendors develop more sophisticated IPS techniques, they cover more threats and also produce more false positives.

Making IPSes More Useful

There are two main trends towards building better IPSes. The first involves their continued integration into the core networking infrastructure, and their mastery of a wider variety of threat management techniques (see "IPS Technology: What's Next?").

In the next 12 to 24 months, expect to see powerhouse vendors, such as ISS, Symantec, Check Point and Juniper, and smaller players, such as Sourcefire and Tenable Network Security, advance IPSes' effectiveness through these trends.

Intelligent integration with existing infrastructure. Today's IPS products can't be integrated throughout large, heavily switched network infrastructures. Even if major vendors add IPS functions to data center-sized switches, the heavy processing demands and the need to inspect all traffic would slow them to a fraction of their current performance. At the same time, integrating IPS functions into switches would require a complete replacement of devices--a prohibitively expensive proposition.

Given the cost, performance and management requirements, we're not going to see inline IPS incorporated directly into the infrastructure over the next five years. This doesn't mean that inline IPS is inappropriate--simply that it's inappropriate for the vast majority of network ports.

No single technology is sufficient to solve the problem of blocking malicious traffic. Given that reality, IPSes need to move toward a systems-oriented approach that combines individual inline IPS devices with passive scanning and sensing devices, an extremely intelligent inference engine and the ability to use the IPS console to tune policies on existing network devices.

Evolution of hybrid technologies. Future IPSes will incorporate a wider set of capabilities, such as rate- and content-based analysis, and other threat recognition technologies, such as vulnerability scanning, heuristic virus scanning and statistical modeling of network flows.

In a young market such as IPS, vendors are eager to play up their differences to build brand recognition and distinguish their offering from all others. Today's debates about "content vs. rate" IPSes are eerily similar to the early 1990's proxy vs. packet-filtering firewall war. The IPS market will eventually learn the same lesson the firewall vendors did: Both approaches have merit, but the best general-purpose solutions take a blended approach.

Time will tell exactly which combination of blended threat management technologies will form future IPSes. Blending will result in a combination of tools and techniques that security managers can use to push IPSes deep into the network. It may become easy to add protocol anomaly- and rate-based IPSes into infrastructure components such as switches and routers, while signature-based and statistical IPSes might be combined in devices that passively monitor network traffic.

Although blended IPSes will make inline products stronger, they are simply extensions of the systemic approach to intrusion prevention. Better inline IPSes may not improve defense in depth, but better performance (both in speed and coverage) at perimeter choke points will be welcomed by security managers who are already dependent on inline IPSes.

Proceed With Caution

The path from point solution to network-integrated IPSes is a difficult one, and security managers should proceed cautiously. Vendors will have to execute, scale and interoperate before their solutions instill confidence.

In theory, Cisco could throw IPS technology into all of its switching and routing products and render this whole argument moot. But, that's just in theory.

Historically, infrastructure vendors simply don't do security that well. While we can expect Cisco, Juniper, Hewlett-Packard and Enterasys Networks to incorporate IPS into infrastructure devices, it's unlikely any will match the security offered by ISS, Symantec, Network Associates and Check Point.

On the other hand, security-focused vendors don't have the engineering resources to compete in the infrastructure space, and history has shown that when an infrastructure company buys a security company, you end up with a bigger infrastructure company--such as when Avaya bought VPNet Technologies. Thus, effective IPSes will require that multiple vendors cooperate to provide comprehensive, interoperable solutions.

A future IPS solution might combine passive network scanning from one vendor, IDS/IPS sensors from a second and an inference engine and management system from a third--all controlling disparate firewalls and switches. But, that's a hazy future; there are no standards for how these products would interoperate. The trend, rather, has been for small vendors to cozy up to market-dominators. Thus, IDS vendors tend to support Cisco's PIX, Juniper's Net-Screen and Check Point's FW-1 when they tweak firewall rules, but each relationship is driven by the size of the vendor, not by industry standards.

The alternative to interoperability and multivendor support is vendor or platform lock-in. In other words: what we have today. We risk leaving the market to companies with baroque IDS/IPS product architectures that can scale up but not down, or highly proprietary black magic solutions.

IPS technology is in its infancy, and we can expect it to evolve and mature. But IPSes will always be constrained by a fundamental limitation: Inline products can only block traffic they can see, and they can't see all network traffic. This means that IPSes must have coverage over an entire network, and that won't happen until--and if--network infrastructure vendors are able to cost-effectively replace conventional switches with combination switch-IPS products.