Let me state a few of my assumptions, first. If they don't hold then I'm wrong. :) 1) Administrators don't have time to backtrack and try to shut down attacks. They'd like to but they need to sleep sometimes. 1.2) Administrators will start to ignore their IDs if it pages them more than once a day, maximum. 2) Firewalls and perimeter systems aren't 100% secure. 3) We are concerned about employees that are hacking other sites because of the legal liability. 4) We are concerned about detecting other forms of break-ins that occur on our internal network, possibly via modem or other means (including social engineering). 5) We assume our attackers will be using attacks we don't know about, yet. 6) Our networks are vast, rapidly-growing and completely chaotic and we can't assume that what is going across it today is what will be going across it tomorrow. 7) We have no defined policy, nor do we actually have any control over networking and network growth. So telling a user to "fix it" is a waste of time. I think those are a reasonable set of assumptions. Unfortunately. -> Based on assumption #5, I believe that we have to be skeptical of the usefulness of "network grep" type intrusion detection. -> Based on assumption #1, I believe that even the informational value of "network grep" type intrusion detection will eventually go away, as the administrator tunes it out. After all, we really do NOT have time to backtrack every twink who runs scans against us. -> Based on assumption #4 I question the utility of IDs in the firewall, though it's probably a component of a complete solution. -> Based on assumption #6, I question the utility of AD-IDS that "learn" patterns -- the patterns change too fast or lose resolution. See Vern Paxson's earlier papers for some insights into this. Even if the system learns it'd generate false positives, which applies to assumption #1 and #1.2. -> Lastly, the SNI guys have shown us that "network grep" IDS won't work against attackers who are trying to hire their attacks. I wonder how long it'll be before there are hacker tools for hiding from IDS? This is a cue for one of you grey hats to pipe up and say "but there *are*, daddy-o..." Ok, so I don't think we're left with much. Yes, it is important to know how bad things are. That gets security funded. Yes, it is important to know that the firewall is resisting attack. Which leads me to a point: Point #1: If the firewall/IDS/whatever deflects the attack successfully, then don't bother me with it. Give me a weekly summary of how many times it was attempted and we can have a laugh at the twinks. The main thing I think we have left is a notion of what is permitted by "policy" and a set of tools for looking at events. Here I'm not using "policy" in the usual computer security sense, of an unyielding set of rules; perhaps it's more an intent of what should and shouldn't be going on. That's what to look for. The bad news is that it's site-specific. :( When I was consulting, I'd often be brought in to do analysis of some configuration or network or problem, to rule as to whether it was secure enough or recommend how to improve it. Frequently, during that process, I'd run across things that shouldn't happen. The customer would say something like, "well, nobody should be able to get into the Web server from the outside so we won't see anything like that..." -- That's the key. What you need to do is identify categories of things that shouldn't occur, and set traps to detect when they do. Then scream. Essentially, what you're doing is looking for a policy violation. Example: You have a web server outside a firewall, on a DMZ, protected by a router with screening. The CGI scripts are carefully audited, and so forth. Let's look at our policy: -> Nobody from the outside should be able to get a packet (through the router) to anything but port 80/TCP or 53/UDP. -> The web server should not originate traffic to anything outside the network (heading to the router) except packets from the http server on port 80, and 53/UDP -> The web server should not originate traffic to anything inside the network except the firewall, and then only on let's say SSH and maybe SMTP -> Since there are no other systems on the network we should not see anything coming in to (or going out!) from them. That's a start for building a very strong intrusion detection capability. You know what is allowed to happen, you derive a few basic assumptions about what shouldn't happen, and you look for events that match the "shouldn't happen." You can get much much more detailed than my simple example. I.e.: "the web server should never ping broadcast addresses." or even "nobody on the web server should ever use the 'ls' command as "root"" Next you can start to usefully apply your "network grep" by using it to watch for specific things outside the scope of what should happen. Perhaps you want to watch for basic attack signatures in all traffic going to the ethernet address of the inside of the firewall. Perhaps you want to make a few other assumptions: nobody within the network should try port-scanning sites on the Internet. Or perhaps: nobody within the network should try to FTP password files from other machines. Etc. Etc. Which brings me to another point: Point #2: Intrusion detection is only meaningful if you: - know what you'll do about it - know what constitutes a violation of acceptable access - can usefully reduce the scope of the areas in which you perform broad scanning - can accurately define what "shouldn't happen" After all, if you can't tell me what shouldn't happen on your network, I can't even tell you what an intrusion of such a network *IS*, right? I bet if I asked you "will you react more vigorously to an IDS-generated alert on your internal network, or on your external?" you'd all say "internal!!" Ok, then I ask you, "why bother about your external? You'll barely have time to look at your internal network anyhow!" That's why I call this "policy-based intrusion detection" for lack of a better term. I suppose I am giving potential competitors useful ideas, but I've always been stupid like that. :) Besides, this is 6 year-old-thinking, I have newer, better ideas. ;) Just no time to do them... Don't let any of this stop you. Intrusion Detection is going to be like firewalls. In a few years, EVERYONE is gonna have to have a sucker/sniffer/probe/recorder plugged into their network. Heck, the FBI may even require it (don't laugh!). So, for all the products' technical problems and philosophical design flaws, the ID vendors are going to make a bundle of money. So, let me ask you a few questions: -> Will you actually react to all the "attacks" your IDS finds? -> Will you immediately rush to block land, flounder, blick, and augenblick2 attacks as soon as someone tries to use them on you? -> Will you monitor all the logs? -> Will you ever get any sleep? 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:25 PDT