Republished with permission of WatchGuard Technologies . Originally published February 1, 2002.

WatchGuard


Foundations: What Are Intrusion Detection Systems (IDS)?

by Fred Avolio, Avolio Consulting, Inc.

“Just a moment… just a moment… I’ve just picked up a fault in the AE-35 unit. It’s going to go one hundred percent failure within seventy-two hours.” Science fiction buffs (and only old ones at that, as I’ve discovered) will remember this quote uttered by “the sixth member of the crew” of spaceship Discovery in the 1968 movie, 2001: A Space Odyssey. The speaker was, of course, the HAL 9000 computer, a self-described “conscious entity.”

First, the bad news: IDS products are not that smart. They do not employ artificial intelligence. They do not provide an impenetrable barrier, nor can they read user motivation. Now, the good news: IDS can be useful additions to security defenses, anyway. In an article published in Internet World, March 22, 1999, Dave Piscitello and I wrote, “When mainframes were the mainstay of computing, we encased them in glass houses. Locked doors and security badges were sufficient … In a world where the network is more relevant than any single computer, locked doors simply don’t do the job.” Flawed or not, an IDS is nearly essential for any network where superior availability is expected. This article provides an overview of intrusion detection systems, so you can consider whether you want to use IDS as a tool for protecting your network.

The Basics

Security devices can be categorized into three areas. These areas are:

  1. defensive (or preventive),
  2. detective, or
  3. responsive.

Some security devices combine all three. For example, your Firebox or SOHO firewall is primarily a defensive mechanism, but it also does some detecting (via the log files). Desktop antivirus software primarily detects (“notices” a virus), and responds (removes it). Yes, it also prevents, but that is a by-product of the other two functions. IDS primarily detect, and sometimes respond .

Traditionally, the IDS space has been broken down into two areas: vulnerability checking, and monitoring. These two areas are further broken down into two more categories: activity at the network level, and activity at the server/host level. Vulnerability checkers — also called scanners — test systems, or network interfaces to systems, for known vulnerabilities based on bug reports, or common configuration mistakes. While scanners can be very useful (as described in ” Introducing nmap, Scanner of Choice “),  they are usually no longer categorized as part of IDS.

The area that is left — network- and system-level monitoring — is the focus of this article. Network-based intrusion detection systems examine the traffic on a network for signs of intrusion, while host-based systems look at processes running on a local machine for similar bad-guy activity. What does “bad guy activity” look like? An example: if your company uses a range of Internet addresses, and during one or two seconds dozens of those addresses are sequentially pinged by some machine out on the Internet, an IDS would alert you. That pattern of traffic usually indicates someone scanning to learn which machines in your network are turned on, prelude to a more focused attack. This is a fairly clear-cut example. Other traffic patterns may require more subtle interpreting. The IDS can report that a pattern occurred, but it does not know what motive lay behind that traffic.

Okay, so if an IDS is not discerning user intent (and I hope we all understand that it cannot),  how does it decide what to report on?   It depends. Most IDS systems use a combination of techniques.

Statistical Analysis

In past government-sponsored IDS research, statistical analysis has gotten a good deal of attention and research dollar. The idea is the IDS system “learns” what normal traffic looks like by gathering statistics of normal use. For example, a host might learn how individual users interact with the system by means of a network monitor set to “learn” what “usual activity” is on a network. Set in “learn” mode, it can notice that only certain packet types are ever seen in the inside network, only specific ports are ever used, or only particular sources addresses ever show up in an IP packet header. Then when the monitor is set to “alert” mode, if something outside of the ordinary shows up, it alerts you.

Burglar Alarms

A burglar alarm IDS watches for events the administrator has told it: a) should never happen, or b) are significant security events. These descriptions, called “attack signatures,” may be simple — “Traffic through this point should only have source host addresses from our local network, never from outside addresses.” A host-based IDS on a Web server might be told to squawk if it gets a request for something other than HTTP or SSL, or if any of the Web pages are modified.

Sometimes attack signatures are more complex and may be built to detect a particular host or network exploit. For example, a network IDS (or “NID”) might look for the pattern of attack associated with the Nimda worm. Even if hosts on the network are not vulnerable, the NID can alert you of the attempted attack. A host-based burglar alarm might also monitor the process table on a system on which it is deployed and watch audit logs for signs of foul play.

Host-based IDS include the following:

·          Symantec’s Intruder Alert

·          ISS’s RealSecure Host Sensor

·          NFR’s HID (formerly Cybersafe “Centrax”)

·          Tripwire’s Tripwire

Network-based IDS products include:

·          NFR’s NID

·          ISS’s RealSecure Network Sensor

·          ISS’s BlackIce

·          Symantec’s NetProwler

Strengths and Weaknesses

 Because of where they are placed in your network, NIDs and HIDs differ in their strengths and weaknesses.

NIDs

Network IDS are dedicated to the task and can be centrally managed. This is good from a defensive standpoint. All the machines in a network segment benefit from the protection of the NID on that segment.   The servers and desktops need no additional software installed and no change in configuration. NIDs do not negatively impact the network segment, nor do they impact the servers and desktops they protect, as processing is done on the NID device (or central NID server), rather than on the individual protected hosts.

On the other hand, NIDs only protect one network segment at a time. This should be obvious, but in order to protect your entire network, you will have to deploy multiple NIDs — one for each segment. Not a big constraint, but one to consider if your IDS budget has limits.

HIDs

Host-based IDS can track an individual attacker’s actions and commands on individual systems, often providing more granular information for your analysis than NIDs.   HIDs can be deployed on critical servers and can reveal specific detail about the particular uses of the server.

On the down side, HIDs may have a negative impact on the system on which they are running because of the extra logging and host-based processing. This is usually not prohibitive, but it is something to consider when selecting among intrusion detection techniques.

Information Management

The main negative with both types of technologies — again not a showstopper, but something to know going in — is the question of what to do with all of the logging information produced by HIDs and NIDs. Data isn’t always clearly presented. Data isn’t correlated. What do you do with all of this raw stuff? In a November, 2000, Network Computing article entitled “Watching the Watchers: Intrusion Detection,” Greg Shipley wrote, “Running a SYN flood against an OpenView-based Cisco console is analogous to sending The Terminator through an airport metal detector. You get a ton of lights and a lot of pissed-off hardware, but you wind up with little clue as to what is really going on.” The IDS can alert, but today the decision-making still requires human intervention. If you’re not prepared to watch it closely, don’t bother spending money on intrusion detection.

Next Steps

So, what do you do? Well, read this month’s intrusion detection articles, for sure. But — at a very high level — what you should do next is map the network. What are the critical network segments? (Perhaps all of them.) Where are critical servers? What is “outside” and what is “inside?” Break the network down into different areas based on types of users, servers, and data. Where are the routers and firewalls? Where are extranets? This map will show you where the most valuable data resides, and the critical paths into it. This will help you selectively choose where to put the extra attention of IDS.

So, intrusion detection systems are not HAL 9000 (and if you saw the movie you would know that this is probably a good thing). But, what Dave and I wrote in 1999 is still true: intrusion detection systems are “useful and effective additions to security defenses, and they are being used by small and large enterprises today.” They certainly can provide a welcome layer to defense in depth. ##

Pointers

“The HAL Transcripts,” on “Underman’s 2001 .” 

” Watching the Watchers: Intrusion Detection ,” Greg Shipley, Network Computing .

Intrusion and Response for the Enterprise Net ,” Internet World, March 22, 1999. http://www.avolio.com/articles.iw-ids.html

Was this article useful to you? Is there a security topic you want our experts to tackle? Let us know at lsseditor@watchguard.com .

For more helpful articles, log into the LiveSecurity Archive . 

Copyright© 2002, WatchGuard Technologies, Inc. All rights reserved. WatchGuard, LiveSecurity, Firebox and ServerLock are trademarks or registered trademarks of WatchGuard Technologies, Inc. in the United States and other countries.




Copyright © 1996 – 2002 WatchGuard Technologies, Inc. All rights reserved.
Legal Notice/Terms of Use