Signature-based NIP products run the gamut from purpose-built systems, like NetScreen's IDP or Network Associates' IntruShield appliances, to integration between IDSs and firewalls, like the pairing of Internet Security Systems' RealSecure with Check Point's FireWall-1 or Cisco's IDS with PIX. At a high level, these systems work the same: The NIP device monitors traffic flowing past the wire; attempts to match the traffic--packets or flows--to known signatures; and when there is a match, takes some action. Often, the action is just an alert, but traffic can be blocked, too. NIP vendors typically issue signatures quickly after a vulnerability is publicized, so it's wise to keep current.

Several methods are used to detect malicious activity using signatures designed to send alerts on specific attacks and mutations of attacks. Signatures are difficult to create at the best of times, however, and without a thorough understanding of the vulnerability, signature creation is less effective. Signatures also can be based on common attack indicators. For example, they may search for binary traffic where only ASCII traffic should be; look for anomalous packets, such as telnet traffic on a high-number port; or target malformed packets. Of course, packets that match these fuzzier signatures don't always indicate an attack: For instance, the AOL Instant Messenger client for Mac OS X doesn't send a host: header on its HTTP/1.1 requests, which may trigger a protocol-anomaly alert.

There are many other examples of legitimate anomalous traffic that might trigger alerts, all of which reinforce our contention that before you enable intrusion prevention, you have to be confident that no legitimate traffic will be blocked. Though interesting, protocol-anomaly detection is still too immature for us to place much trust in its ability to accurately differentiate between legitimate and illegitimate traffic.

DoS (denial of service) alerts are generated by traffic that violates an adjustable but predetermined traffic rate, such as 100 unacknowledged TCP sessions in one second. Detailed knowledge of what constitutes normal traffic on your network is essential to define thresholds properly. Alternatively, DoS, or distributed DoS, detection is based on statistical analysis of common types of traffic. After a learning period, the NIP has a picture of "normal" traffic. Bursts that are statistically significant may indicate a DoS or DDoS attack. Or, they may just indicate an abnormal spike in traffic, as when a Web site is "Slashdotted."

Traffic-analysis intrusion-prevention products, like those from Arbor Networks, Lancope and Mazu Networks, monitor traffic patterns and capture snapshots of what constitutes normal traffic--traffic rates, which computers make connections to other computers, and so on--creating a picture of network behavior.

Normal traffic also can be defined as part of policy enforcement. If your organization's policy is to disallow telnet anywhere on the network, instances of telnet being used constitute, at minimum, a breach of policy.

The Bottom Line

You do need NIP systems, but not because they're going to solve your security problems. They won't. You need them because you most likely have inadequate desktop and server controls. You probably don't have the resources to maintain application patches. And way too many network applications are poorly designed and/or improperly installed, leaving security holes.

During briefings with TippingPoint Technologies, the company told us its UnityOne product "patches the network." This is an absurd statement because while the UnityOne appliance may block attacks, that is not a patch--the end system is still vulnerable.

Remember, attacks don't always come through the perimeter. Recently, SQL Slammer ravaged networks when remote users connected to the network with infected laptops. To effectively stop attacks, you need to focus on the ultimate targets: your servers and desktops. And that means desktop and server management.

But organizations don't embark on desktop- and server-management projects for security reasons. Even though a well-planned strategy can spawn tons of benefits, including centralized control, updates and software distribution, these projects are complex and costly, and often don't provide the specific security features necessary to minimize risk. This has given rise to a host of cottage industries--for example, patch management (see "PatchLink Helps Keep Windows Closed,") and security-policy monitoring (see "Policy Enforcers,"), two key areas underserved by desktop management. Those two product areas focus on where the problem is--at the endpoint. Keep your Internet Information Systems Web servers patched, and who cares if someone attempts a Unicode directory traversal? The attack will fail, and that's the point, right?

A wise woman (my wife) said recently that we don't need electric fences if we lock our doors. Intrusion prevention is the necessary fence because we don't, can't or won't lock our desktop and server doors.

Mike Fratto is a senior technology editor based in Network Computing's Syracuse University Real-World Labs®; he covers all security-related topics. Prior to joining Network Computing, Mike worked as an independent consultant in central New York. Write to him at mfratto@ nwc.com.