Re: Intrusion Detection

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

Eric Maiwald writes:
> I think you are missing one important capaiblity of attack
> recognition tools, if I place the tool inside my firewall,
> I can configure it to tell me if my firewall is not behaving correctly.

        Yeah! This is what I'm talking about!

        What's interesting in this example (the firewall) is the
assumption that your IDS can understand what "correct" behavior
of the firewall is. What that means is that you'd be able to
invert the firewall's policy, or somehow have an IDS that was
coupled to your understanding of what should and should not
work through the firewall. That's what I've been calling this
"policy-based IDS" stuff: when you know a priori what should and
shouldn't happen and look for cases where what shouldn't happen
is happening. It could be that someone has gotten behind your
firewall and is attacking out (!) or that someone is attacking
behind your firewall because they got in through it or they
got in some other way -- at that point you don't care because
you know you shouldn't be seeing a high level of attacking
activity on your network behind your f/w.

        It's always dangerous to argue by analogy, especially in
a mailing list, because they get stretched pretty far out of
shape, but let me try because it illustrates how I think of the
problem....

Home Burglar Alarms
        I have a burglar alarm. It triggers an alert when one of
a limited set of conditions occurs:
        1) a door or window into/out of the house is opened
        2) glass is heard to break
        3) certain interior doors/hidden switches are triggered

        This alarm system is tailored to my requirements. I have
cats. A passive infrared or microwave motion detector alarm
would generate zillions of false negatives thanks to the
furfoots. With the current system, I can still be fairly comfortable
with my policy that nobody enters or exits (because the cats can't
operate doors very well, though they could if they tried). They
may periodically knock over something glass and generate a false
positive but that is a low-likelihood event and I can justify
the chance of the false alarm.

        So, my security is entirely based on notifying me when my
perimeter firewalls/doors have been breached. At that point I know
my policy has been violated. Up until that point, I don't care what
happens. So, a burglar could walk up on my porch and case the house.
So could the UPS delivery. If my alarm went off whenever that happened,
I'd very quickly learn to ignore it.
------------------------------------

        I guess I could enhance my household security by adding a
set of video cameras that recorded license plates on the road
in front, and which recorded movement in the yard. That way I
would have valuable forensic information in the event that my
main security system was compromised. But I couldn't slave the
cameras to the alarm: there are deer out here.

        So, the trick is clarifying how your IDS should interact
with your security policy. Out here where I live, maybe it'd
not generate a lot of false positives if the alarm went off
whenever someone touches a window or rattles a doorknob, let
alone succeeds in opening a door. In an urban environment, that
might not work. Succinctly:

        We must balance the irritation of false positives against
the value and significance of a genuine alarm

        I believe that the best way to do that is to be able to
clearly define what should and should not happen, as a
precondition to installing the IDS. An IDS that isn't "tuned"
right is going to be a nuisance or a doorstop. My previous mail
was not intended to be a slap at misuse detection "network grep"
IDS'! After all, I build a product that can do that kind of thing
very well. I just want to see people get the best results possible
out of them. And the best way to do that is to be very cognizant
of the environment into which they are installed, and its operating
principles ("policy").

mjr.
--
Marcus J. Ranum, CEO, Network Flight Recorder, Inc.
work - http://www.nfr.net
home - http://www.clark.net/pub/mjr