Adam Shostack writes: > I believe intrusion detection to be a misnomer, and that the >really useful class of software is attack detection. Attacks (land, >teardrop, phf, password file sucking) are relatively easy to detect >with network sniffing software. Adam, To me the big open question in ID is "why?" not "what?" If you have a network you believe to be vulnerable to the attacks listed above - FIX THEM. If you've fixed them, then why do you care if someone uses them against you? Are you actually going to backtrack and try to prosecute? Good luck! Back when I was a firewall vendor (yes, none of this stuff is new!) I built a firewall that alerted the system manager whenever certain classes of weirdness occurred. That was always Very Cool and it was the first thing they turned off after it began pestering them constantly. As the vendor, I wished I'd never put it in because I kept getting calls that went something like: C: "Hi - my firewall is saying it's getting spoofed packets! Help!" V: "What am I supposed to do about it?" C: "Well, can you make it stop? Can I call the police?" V: "No, and No. It's just informational, really." C: "Does this indicate that someone's likely to break through the firewall?" V: "No, it indicates that we thought ahead, blocked that avenue of attack, and it doesn't represent a problem at all. I guess you now know that your firewall works, or something." C: "Uh, uh, uh..." The whole problem with ID (*ESPECIALLY* what Adam calls "attack detection") is that it detects something basically useless. So you're under attack. Big deal. Your defenses can either handle it, or they can't. If they can, then relax, have a homebrew, and don't get pestered about land, teardrop, etc. If they can't, you'll know right away anyhow when your system slags. There are really only 2 good reasons I can think of for ID systems: 1) To develop a threat level model as to how often you are attacked 2) To detect clueless people inside your organization who are attacking outside sites The first one is kind of silly but I suppose it makes people happy to know that they were SATAN scanned 2,102 times last year and that their firewall blocked 1292 clueless twinks who tried using the "same old stuff" as the previous 1291 clueless twinks. The second one is valuable if you actually are going to do something about clueless twinks inside your network. I suspect this must put university network managers in a real quandary. In short, my views are exactly, precisely 180 degrees the opposite of Adam's. I don't have TIME to be notified about the clueless twinks. What I want is fallback defenses that will detect when my first line has failed. This is what I am calling "policy based intrusion detection" and I'll probably wind up explaining it here in a white paper or long posting some night. :) It's the "SOMETHING HAS GONE TERRIBLY WRONG. WARNING WILL ROBINSON!" mechanism. I care a lot about that, and the "why?" for such a system is obvious. The second part is, of course, what NFRs are for. Once you've found that something's happened, then how do you figure out what it was? mjr. -- Marcus J. Ranum, CEO, Network Flight Recorder, Inc. work - http://www.nfr.net home - http://www.clark.net/pub/mjr
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 12:54:17 PDT