Looking for Trouble: Intrusion Detection Systems

An intrusion detection system watches over the network, looking for traffic flow that matches the system’s signatures for network misuse, such as a port scan, virus, SQL injection attempt or unauthorized access.

Most IDSes have thousands of signatures, organized by category and level of severity. When an IDS has a reduced set of signatures with higher fidelity and is placed in-line, it is often called an intrusion prevention system (IPS). IDSes are among the most misunderstood security technologies because the moniker is misleading. The systems are not really necessary for detecting intrusions. If your firewall is properly configured and your patch management discipline is good, you are unlikely to find a network intrusion with your IDS.

But many IT managers find IDSes indispensable for discovering security policy violations, infected systems, misconfigured applications and firewalls, information leakage, and unauthorized servers and clients.

Here are five tips for deploying these tools to their full potential.

1. Don’t mistake an IDS for an IPS. An intrusion prevention system drops packets; it looks for known bad traffic and otherwise allows good. Think of an IPS as a firewall with a default allow policy. By contrast, an intrusion detection system looks for anomalies, traffic violations, malicious traffic and funny packets. And IDS is a visibility tool, not an enforcement tool.

2. Don’t focus on how well an IDS catches intruders but on how easy the device is to manage. Install the product and its management console and ask yourself: Am I getting useful information? Am I gaining visibility into my security posture? Are there network security issues I am identifying that need to be fixed? With a well-designed management interface, you should be able to find the answers quickly.

3. Place sensors in the proper location, inside the firewall and close to strategic assets such as servers. While IDSes aimed at user systems can help identify malware infections, it’s the application servers that represent value to your organization. These are the assets worth spending time and money to protect.

4. No IDS will work out of the box. Allocate some time to customize the IDS to your environment or you’ll never get anything useful out of it. The IDS must be linked to your existing knowledge about networks, applications and security. For example, be prepared with a list of servers, their operating systems and responsible managers, and identify which are most critical to your organization. Otherwise, you won’t be able to prioritize the IDS alerts you receive.

5. Listen to the device. If you don’t intend to use the console to review errors at least once a month, an IDS is not a wise investment for your organization. Once you fine-tune your IDS, you will need only a few hours a week to evaluate alerts and resolve issues. It’s also a good idea to delegate some responsibilities. For example, you might ask your e-mail team to look at all alerts related to mail servers. This will ensure that the raw IDS data is viewed in its proper organizational context.

Joel Snyder is a senior partner with Opus One, a consulting firm in Tucson, Ariz.