I want to clear up a common misconception. Intrusion detection and intrusion prevention aren’t different names for the same market segment—they’re different names for two distinct categories of security products.

Intrusion prevention is an outgrowth of intrusion detection, and intrusion prevention products offer different functionality from intrusion detection products. IT decision makers need to understand the differences so that they can determine which type of product will provide the best safeguards for their systems.

Understand the IDS challenge
Intrusion detection systems (IDSs) are surveillance products. Using an IDS is somewhat like putting an x-ray machine on your network so that you can examine your packets to see what’s inside. IDSs are really more similar to protocol analyzers or smart sniffers than they are to intrusion prevention systems (IPSs). IDSs look at the patterns of the traffic going through your networks and try to make intelligent decisions regarding their findings.

IDSs can be set up to log information continuously or to log information and then effect a response from the information they collect. In most cases, IDSs are installed on network segments in strategic locations (say, between your border router and your internal mission-critical application servers).

There are a few fundamental problems with how some IDSs work today. First, as more and more network traffic becomes encrypted, IDSs become useless because they can’t parse encrypted traffic. Second, as networks become more heavily switched, they typically see only a small amount of the traffic on your network. On a switched network, you need to greatly increase the number of intrusion detection sensors to monitor traffic on all the network segments. On large networks, this means that the total cost of ownership of IDSs can be very high. Third, IDSs generate a huge number of false positives, telling you that your network is being attacked when it’s not. These three problems are leading many companies to switch to IPSs.

Leading vendors in the intrusion detection market include Cisco, ISS, and NFR. Some IDSs are sold as software packages you install on top of a leading operating system. Others are sold as turnkey appliances, commonly called “sensors” by the companies that make them. Typically, these devices work by monitoring the traffic on the network, noting which devices they are communicating with and categorizing the types of traffic interacting with the devices. Traffic patterns are compared against known attack signatures, and alarms are typically set to go off according to certain thresholds and severity levels. For example, a syn-flood attack might be set to a severity level of high, and an ICMP flood might be set to medium.

IDSs typically use known signatures to recognize traffic patterns, similar to the way antivirus products use known signatures to recognize viruses. As with an antivirus system, it’s important to keep the signatures up to date. The signatures are often based on malicious TCP/IP packets, since cybercriminals commonly try to manipulate those packets to perform a malicious action. Therefore, the types of information that IDSs usually record are source address, destination address, port numbers, encryption keys, MAC addresses, and whether packets are formatted correctly.

Some IDSs monitor what services are being used, which can be compared against what services are currently not allowed by the organization’s security policy. However, if your firewall rules are properly configured, no services should be passing through to your internal network unless they are expressly allowed (although it would be naive to assume that all firewalls have properly configured rule-sets). It is truly important to tune an IDS to report only the minimum data needed to detect an attack. Storing information on every packet header and payload is not useful, and in the long run, it will just create more work and overhead by taking up valuable disk space, requiring additional backups, and increasing storage requirements.

Preventing intrusions
IPSs are like deadbolts. They simply stop the attack. They do not analyze it and then effect a response—which could, in fact, be the wrong response, as we have seen with false positives generated by IDSs. Where IDSs generally monitor network segments, IPSs are typically host-based products that get installed on the actual servers and desktops they are slated to protect.

Leading vendors in the intrusion prevention market include OKENA, SecureWave, and Entercept. These products typically work at the application level by analyzing a proposed user action before it accesses and/or modifies any mission-critical files. The requested behavior of the application must match the desired behavior that has been previously defined by a standard set of rules. If the proposed action is unusual, the rules that govern the application’s behavior will prevent the action from executing. Some IPSs compare a checksum of the executable with a known good checksum list. If the proposed execution is legitimate, the application is allowed to execute. If there is a mismatch in the checksum hash, the application is not allowed to execute. Unlike IDSs, with IPSs, the logic is applied before the application is executed in memory. Other IPSs work by intercepting systems calls.

An IDS still has its place
Although IDSs have their problems, they can still offer value to an organization or law enforcement agency under the right circumstances. For example, if your network is under attack and there has been a large loss of valuable assets such as credit card numbers or if money has illegally been transferred to the wrong accounts, using an IDS is a smart way to try to catch the perpetrator. Of course, if you install an IDS after a malicious cybercrime has been committed, you may miss picking up the necessary network traffic information you need to solve the crime. However, if the attack is still taking place, installing an IDS may help you quickly solve the mystery surrounding the attack.

Because IDSs need to collect a large array of traffic to understand anomalous patterns, they typically require a lot of massaging by a security engineer or network administrator to tune them, interpret the information, and identify false positives. In fact, monitoring IDSs can be a full-time job. We have seen instances where a hacker has actually exploited an IDS, causing it to create a denial of service attack against the organization it’s in place to protect.

Bottom line
So what can we take away from all of this? There is still a need for IDSs, but IT decision makers should understand how to use these types of systems in a smarter way. A lot of thought and planning must go in to whether an organization truly needs an IDS, an IPS, or both. It’s important to figure out your IT goals before making procurement decisions.

If you work for a financial institution, you should probably deploy both an IDS and an IPS. If your systems contain medical records that include detailed patient information that doctors use to make treatment decisions, you should probably deploy an IDS and an IPS. I am making these recommendations based on the assumption that the loss of large amounts of money or the loss of life have high-risk implications that require the utmost safeguards.

However, if losing your data would, at worst, create a big inconvenience while your operations team secured the perimeter and the hosts and restored the data, it might be more worthwhile for your organization to install only an IPS. Certainly, if there are no staff resources dedicated to tuning an IDS or providing the ongoing expert analysis required to get the value out of it, there is no point in installing one.

In implementing either an intrusion detection or intrusion prevention system, the risks being analyzed or prevented should always align with business risks—an important point that many IT decision makers fail to address.

The following are some of the important points to remember:

  • IDSs are installed on network segments.
  • IPSs are installed on servers and desktops.
  • IDSs require expert tuning to be truly useful.
  • IDSs require more administrative overhead.
  • IDSs can’t parse encrypted traffic.
  • IDSs and IPSs should both have a central management console.
  • IDSs have more potential for identifying hackers.
  • IPSs can better protect applications.
  • Intrusion prevention products are ideal for blocking Web defacement.
  • Neither an IDS nor an IPS is a replacement for firewalls.