This article can also be found in the Premium Editorial Download "Information Security magazine: Comparing five of the top network-based inline IPS appliances."
Download it now to read this article plus other related content.
It's game day for IPS. See how five appliances match up against attacks.
Are you ready to let an intrusion prevention system (IPS) determine which traffic gets through to your network? Are you calling the plays? Do you trust the guys on the line to make the right decision? E-commerce is blindingly fast. You have to anticipate the attack, recognize the tactics and respond rapidly to keep the bad guys from getting your vital business data.
As the technology matures, IPS has generated a lot of buzz in the infosecurity industry; the IDS vs. IPS debate persists two years after Gartner declared intrusion detection systems (IDS) would be dead by 2005, in favor of IPS. The trick is stopping the attacks without impeding or even limiting legitimate business traffic in the high-speed, high-volume flow of online commerce. An IDS false positive is a nuisance; automatically blocking your 24x7 production app is unacceptable.
We built our test lab (see figure, below) with the attacker network on the outside of the IPS, the protected target network on the inside, and the IPS product right in the middle, controlling the flow of traffic between the networks. We managed the IPS from an out-of-band management network interface, connected to a separate physical network.
The attacker network included a Linux and Windows machine on the same network segment as the IPS; some IPS tools are much more efficient at filtering attacks that come from the same network segment as the IPS, but buckle under the more real-world scenario of attacks that are routed from other networks. To model this situation, we introduced a dual-interface machine that focused on routing attack packets from an outside attacker network. This routing system also offered an ideal platform for fragmenting the attack packets in an attempt to evade detection.
Our attack tools included the open-source Metasploit Framework (versions 1.0, 2.0, 2.2, 2.3 and 2.4, to see how products detected exploits that have evolved over time), commercial exploitation tool Core IMPACT, Fragrouter and Toast.
We evaluated and graded each appliance in several categories: response to common attacks, popular evasion strategies, and denial-of-service attempts; how well the user interface mapped into and supported the daily workflow of network management and security personnel; and overall management capabilities. Here's what happened when they took the field.
Of course, the purpose of an IPS is to detect threatening traffic, alert the security team and, if they have sufficient confidence in the detection signature, automatically block the attack. Therefore, a critical evaluation question is, "Which is better: to alert but allow an attack, or to block it silently?"
Our conversations with a number of security experts yielded a clear consensus: It's better for the tool to alert and pass the traffic than to block and not alert.
The problem of blocking without alerting is that the organization has no data to figure out what traffic is being blocked and why. If the device alerts but does not block, the signature can still be adjusted to block that traffic, albeit after the initial attack.
This question is fundamental in the ongoing debate about the role of IDS and IPS, their capabilities and approaches to defending the network (see "Why IDS is Still in the Game," next page).
Our testing of Sourcefire, for example, underscores this.
The recommended initial IPS configuration detected most of our at-tacks and alerted us that exploits were being attempted, but only blocked a few of them. This is a likely indication of the underlying "detection first" philosophy behind the Sourcefire product. In a real-world environment, organizations would need to tune their IPS signatures, starting with alert-centric rules that are gradually ramped up to blocking rules as a given network's traffic is better understood.
This was first published in October 2005