how to do intrusion detection right

["Marcus J. Ranum" <mjr () nfr net>]

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