Buying an IPS: Decide which applications and protocols your IPS will protect

Application and protocol coverage varies in signature-, rate- and behavior-based intrusion prevention systems. Understanding the differences is crucial to your IPS investments. This is the third in a seven-part series.

Once you've decided which type of intrusion prevention system (signature-, rate-, or behavior-based) offers you

the best capabilities for your requirements, a second decision comes into play: what application and protocol coverage do you want?

For signature-based IPS, the quality (much more than the quantity) of the signatures and the underlying detection engine determines whether a product meets your needs. Even in signature-less systems, such as rate-based or behavioral IPS, coverage of applications and protocols will vary from product to product.

In evaluating IPS products, you may run into ones with literally thousands of signatures, a sign of an IDS that has been repurposed as an IPS. 
,

Some IPS products have evolved from intrusion detection engines, and are sometimes glibly referred to as "IDS with the IPS bit turned on". In evaluating IPS products, you may run into ones with literally thousands of signatures, a sign of an IDS that has been repurposed as an IPS. An IPS's job is not to detect every possible attack or reconnaissance attempt; an IPS only has the job of preventing intrusions. That job takes considerable smarts. The signature count of a well-designed IPS engine will number in the hundreds, not thousands. This doesn't mean that an IPS cannot have additional signatures and also serve as an IDS, as long as the IPS function is primary and the IDS function is secondary.

However, an IDS which has simply been put into inline mode with its thousands of signatures will offer a lower degree of security against serious attackers than an IPS designed from the ground up as a prevention, rather than as a detection, system. For example, because the IDS signatures are designed to detect attacks, even attacks that might never succeed, they will have a higher false positive rate than IPS signatures that are designed to identify and block working attacks. At the same time, the burden of having thousands of signatures to inspect traffic across many ports and in many directions will cause performance issues (such as high latency or lost packets) that might be acceptable in an IDS, but would never be allowed in an IPS.

Buying an IPS series

Determine why you need intrusion prevention: Learn how to develop the right IPS strategy for your network by first asking why your organization needs intrusion prevention.
Determine the approach you require: Signature-, rate- and behavior-based intrusion prevention systems each offer different network security capabilities. Understand each before investing in IPS.
Decide which applications and protocols your IPS will protect: Application and protocol coverage varies in signature-, rate- and behavior-based intrusion prevention systems. Understanding the differences is crucial to your IPS investments.
Determine your performance requirements: Intrusion prevention system performance is dependant on many variables and how it is configured. Test with your network traffic before investing in an IPS.
Determine your form factor requirements: Your choice of either a standalone IPS appliance, or one integrated in a firewall, gives your different levels of functionality to consider as well.
Determine your management requirements: Be sure to match your IPS management requirements to the product you choose, otherwise your deployment will fail.
Test using your network and traffic: Testing an intrusion prevention system is the critical final piece of an IPS purchase.  
 

Merely taking an IDS device from a monitoring port and moving it directly into an in-line IPS position without significantly re-engineering the system is a recipe for failure.

Neither the IDS detection engine nor the IDS signature set is very appropriate for an IPS deployment for two reasons: First, there are fundamental differences in design philosophy between IDS detection engines and IPS detection engines; Secondly, simply repurposing IDS signatures into an IPS will create a fairly inaccurate IPS. For example, an IDS should behave differently when it alerts depending on the susceptibility of a destination system. That is, an IDS might handle a Code Red attack on a Unix server (which is not vulnerable) differently from a Code Red attack on a Windows IIS server (which is vulnerable). However, the IPS doesn't need to make any of those judgment calls. It simply has to block Code Red attacks altogether, a significantly easier job.

On the other hand, an IPS doesn't always have the simpler job. Fundamentally, the penalty for a false positive in an IDS scenario is low, which means that there is an incentive to err on the side of producing false positives. Conversely, the penalty for a false positive detection in an IPS deployment is huge, which means that the IPS designer must have a significantly different mindset.

For example, when the team at Oulu University in Finland discovered widespread security vulnerabilities in common SNMP implementations, IDS vendors created signatures that quickly matched the exploits used by the Oulu PROTOS project. However, detecting an exploit is not the same as detecting vulnerability. Our testing has shown that these SNMP signatures both have a high false positive rate in that they detect valid uses of the protocol and mark them as exploit attempts, as well as a high false negative rate in that they fail to detect very simple and slight variations that a moderately skilled attacker might use to evade an IDS.

In this situation, an IPS has the more difficult job because it must not block valid SNMP calls, yet it should detect attempts to exploit these vulnerabilities. Here, the IPS must combine the use of protocol analysis with signature detection. Protocol analysis is also invaluable in providing zero-day coverage to help catch exploits against previously undiscovered vulnerabilities.

Finally, when considering security and coverage, you should look at the potential IPS actions. A simple IPS can only drop offending packets, but more sophisticated actions are also available with more advanced products. These actions include resetting connections (in one or both directions), sending alerts, capturing packets, blocking future traffic, and even changing configuration of other network devices, such as firewalls. While the more advanced actions, such as blocking future traffic (sometimes called "shunning" after Cisco's terminology) or changing firewall access control lists, may seem attractive, our experience is that these cause more problems than they solve. Thus, making these capabilities a requirement in picking your IPS could be overkill, and could force you to disregard perfectly capable devices.

Joel Snyder is a senior partner at Opus One, an IT consulting firm specializing in security and messaging.

This was first published in June 2010

Dig deeper on Detecting and preventing network intrusions

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

SearchSecurity

SearchCloudSecurity

SearchNetworking

SearchCIO

SearchConsumerization

SearchEnterpriseDesktop

ComputerWeekly

Close