Intrusion Detection: Challenges and Myths

It's 3:00AM on a Saturday night, and the network manager is sleeping comfortably at home. Meanwhile, a stealth program, carefully crafted by a hacker thousands of miles away, is unfolding itself behind the firewall, preparing to open a path into the soon-to-be defenseless network. Silently, unbeknownst to the hacker, the network manager's pager has been activated: "attack in progress! details are available." Within minutes, the network manager has logged in over a secure link, accessed his intrusion detection system, and obtained complete details of the origin and nature of the attack. After a few quick phone calls the penetration is blocked, and law enforcement agents are backtracking the hacker to bring him to justice.

Sounds great, doesn't it? Unfortunately, the reality of intrusion detection and response doesn't even come close to our wishes. Yet, Intrusion Detection Systems (IDS) are a valuable resource, that many network managers are purchasing. Are they getting their money's worth? Are their networks any safer? Let's take a look at some of the capabilities of intrusion detection systems, and their advantages and disadvantages.

Paradigms in Intrusion Detection

Researchers have been working on intrusion detection systems for a long time, without achieving what could be called a major breakthrough. The usual line of research focuses on what are called "Anomaly Detection Intrusion Detection Systems" (AD-IDS). In principle an AD-IDS "learns" what constitutes "normal" network traffic, developing sets of models that are updated over time. These models are then applied against new traffic, and traffic that doesn't match the model of "normal" is flagged as suspicious. AD-IDS are attractive conceptually, but they require training, and the sad reality of networking is that it's very hard to classify "normal" traffic. As networks get sufficiently large, the applications mix they carry becomes so complex that it looks effectively random. An attacker may even generate traffic to generate a distorted model of "normal" so that sooner or later, an attack may look "normal" and get past the IDS. If the IDS is conservative about what may constitute an attack, it will tend to generate large numbers of "false positives" – false alarms – which become the electronic equivalent of the boy who cried "wolf!" Sooner or later the IDS is ignored.

There is still a great deal of research being done in AD-IDS, and promising new avenues include marrying security analysis with data mining and visualization techniques. For the time being, however, it looks like AD-IDS are not a silver bullet. Many commercial firms are producing a simpler, easier to operate form of IDS called "Misuse Detection Intrusion Detection Systems" (MD-IDS).

The MD-IDS closely resembles a virus scanner attached to a network. Usually, it is programmed with signature sets that represent the types of connection and traffic that indicate a particular attack is in progress. Other forms of MD-IDS rely on host platform information, such as C2 audit logs, to detect patterns of suspicious activity.

MD-IDS' strength is immediately apparent: it is fast, and doesn't generate false positives because it "understands" what attacks look like. The weakness of MD-IDS' is that, like virus scanners, they cannot detect something they don't know about. Unfortunately, it is the attack you don't know about that is the one you really, really, truly, wish you could detect. To keep your MD-IDS useful, you'll need constant updates to its signature set from some vendor that keeps and feeds a stable of tame hackers. Even so, you'll still be vulnerable to attacks nobody has seen yet. It's also distressingly easy for an attacker to hide traces of the attack, to fool MD-IDS, by using tricks like inserting whitespace or backspaces in attack data streams. For an excellent paper describing these problems, see Secure Networks Inc.'s paper "Problems with Intrusion Detection Systems" on their Web site, http://www.secnet.com, in the white papers area.

Burglar Alarms

The magic bullet scenario described as the opening of this article is not likely to be real anytime soon, unless IDS are deployed very carefully. Using a technique I call "burglar alarms" an IDS can provide a useful and reliable notification of certain classes of security incident. To understand burglar alarms, consider how they are set up in the "real world." I have an alarm system in my house, which enforces a simple security policy: when I am not home, nobody should be operating entry/exit doors or windows, and nobody should be breaking glass objects. Further, I have several hidden switches in key locations within the residence. When I am not home, nobody should be operating the door to the safe. Based on that descriptive policy, I can design a burglar alarm system based on switches at doors/windows, glass break detectors, and some tamper switches. Note that I might have added that nobody should be moving inside the house when I am not home. In my case, that's inaccurate because my house is home for several cats. Motion detectors would generate too many false positives. Another residence might have a different policy. That's the secret: a burglar alarm is an IDS that relies on an understanding of the network and what should not happen within it.

Surprisingly, one of the best tools for building a burglar alarm intrusion detection system is an MD-IDS. If possible, it should be one that allows you to configure its rules base for where to look and what to look for. The network manager needs to sit down and describe, based on their knowledge of the network, what kind of things to look for, which should not ever happen. Then set the MD-IDS up to detect and alert for them. For example, suppose your network is behind a firewall that blocks Internet IP traffic: look for and trip an alert if Internet IP address ranges are seen on the backbone or inside the firewall. Suppose the firewall does not allow any incoming traffic except for E-mail (SMTP), USENET News (NNTP), and Name Service (DNS) to a central mail hub: set up an MD-IDS that fires an alert if the firewall ever generates any connections to internal systems for other than those services, to other than those servers. Suppose you are concerned that someone inside the organization might try to hack outside sites: set up the MD-IDS to alert you if any of its signature rules apply to traffic going out through the firewall. What the burglar alarm approach does is reduces the likelihood of false positives because its configuration is tied to events you know you want to detect.

Perhaps the most powerful capability of burglar alarm IDS' is that they challenge the attacker with the unexpected. You know your network, and they don't. If they break in, they'll need to learn about your network, to exploit their attack. Just as a burglar may open a few closets looking for guns, or rummage jewelry boxes once they have gotten past the perimeter alarm, a hacker will scan your network for systems that look attack-worthy, or gateways to other networks. Looking for the hacker's internal scans is as effective a way of catching them as a magnetic tamper switch under a money clip on the dresser. Most hackers are not expecting creative defenses – they break in and assume that once they're past the firewall nobody is watching. Burglar alarm IDS' break that assumption and, hopefully, the hacker will be treading a virtual mine-field once they get past the perimeter defenses. Remember: you're always smarter about your network than the hacker can be – that's your home court advantage and you should use it effectively.

Bad Boys: What Ya Gonna Do When They Come For You?

Why do you want an IDS, anyhow? In the idyllic scenario painted at the beginning of this article, there are a number of false assumptions. First, we assumed that the network>

Transfer interrupted!

Perhaps the majority of IDS' these days are being deployed not as Intrusion Detection Systems, but as Attack Detection Systems (ADS). Attack detection presents a paradox: if you know that a particular attack exists, and have blocked it, why do you care if someone attempts to use it against you? If you know that a particular attack exists, and have not blocked it, what are you doing sitting there reading this article? Run, do not walk, and fix your network!!

I believe that the factor driving network managers to deploy MD-IDS' in ADS mode is mostly curiosity. It's interesting, for a short while, to be able to document the frequency and level of attack your network is subjected to. But $10,000 and up is a lot of money to spend for that dubious pleasure. Audit tools also drive the market for MD-IDS – if your network is audited by security analysts, you'll be criticized if their testing passes undetected. Since many auditors use wide-spectrum automated scanning tools like Internet Security Scanner, or Ballista from Secure Networks, there's an immediate emotional payoff if you have an ADS that detects the scan. Pause for a moment and contemplate how ridiculous the situation can be: spend $10,000 for an ADS to detect your $20,000 auditor. Unfortunately, this is becoming expected as "due diligence." The thinking behind this mindset is that at least you are demonstrating a useful degree of readiness because you can detect an attack. In theory, you will be alerted by the ADS and will increase your vigilance for a period of time, increasing your chances of detecting and countering a real attack. It is beneficial as long as your attacker is courteous enough to warn you by running SATAN against your network before launching their real attack.

Keep 'A Knocking - You Can't Come In

I built my first security and mission critical Internet system in 1991, as a part of a major corporation's Internet gateway. The software on the gateway had a number of fairly rudimentary burglar alarms, but even in 1991, the alarms tripped approximately twice a week. The alarms were subtle and only tripped after the system was actually penetrated to a certain degree. I used to backtrack the attacks, and often caught the attackers. The process of running down an attack and documenting the incident took about 4 hours per attack. Of course, the effort had no impact – as the arrival rate of new Internet users increased, so did the attack rate. Finally, I realized that just dealing with the "same old stuff" was taking about 16 hours per week. Since I had built the system, I knew it could resist the attacks it was detecting. Essentially, I was accomplishing nothing with my time other than acting as a kind of surrogate parent to a lot of badly brought up undergraduates. My next generation of burglar alarms were set to trigger when things I thought could never happen occurred. Instead of responding to every probe, I got a weekly summary of the number of times the "same old stuff" was tried against my firewall. That's where I hope IDS will eventually evolve.

Many organizations that do not presently detect and count attacks haven't realized that they are in for an unpleasant surprise if they install IDS or ADS. They will find that even when they know an attack is being launched, there's nothing effective they can do about it. Nowadays, you can't trust the address from which the attack appears to originate. It could be a harmless "fall guy." Even if you know where the attack is coming from, it's almost always from a user's account that has been stolen, or from an ISP account that was purchased with a stolen credit card. To fully backtrack such an attack is a hideously time-and-expertise-intensive task, which amounts to a public service because there is no way it benefits your business. It's still most cost effective to simply chase them away and get back to work. Which brings us back to the question: why bother detecting an attack in the first place, if you know you're not going to do anything about it? Is ignorance bliss?

What Works?

There's no silver bullet, unfortunately. If you understand the limitations and capabilities of IDS, then you can use them effectively. Unfortunately, they are being mismarketed as "feel good" systems more than useful security. To get the best mileage out of your IDS, sit down and draw up a list of the kinds of things that you know mean you have a serious problem, then set the system up to watch for them. If you put your IDS outside your firewall, you've probably put it in the wrong place – move it to the inside. The number of "the usual stuff" attacks seen on the internal network should be very low, and will either represent auditors or hackers that have somehow gotten through your perimeter. In the worst possible case, it may detect employees launching hacks against sites out on the Internet. We'd all like to believe that doesn't happen, but it's best to play it safe.

As with all Internet software, security software is improving at a rapid rate. The current generation of IDS is just the beginning. In the future, we'll see IDS that combine Anomaly Detection with Misuse Detection, and hopefully they will integrate smoothly with firewalls and other security systems. Keep an eye on this hot technology area, and use it wisely today: the network you save may be your own.

About the Author