Re: how to do intrusion detection right

["Paul D. Robertson" <proberts () clark net>]

On Tue, 14 Apr 1998, Marcus J. Ranum wrote:
[various snippage, but I wasn't keeping track]

> 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.

1.3) The more adept ones will filter the alerts through some sort of 
     engine to decide which ones reach their pager.  In some environments
     this could be a very good thing.

1.4) Others will learn which alerts mean "hit erase" and which ones mean 
"grab the Palm Pilot and ssh in".  

> 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.

5.1) But we're not yet ready to assume that this will be the sum
     of an attack, so we haven't completely counted out the usefulness
     of this.

> 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.

8) Systems need to be more aware of what's going on in themselves.
   Better for them to enforce trust boundaries, and I'm still looking
   seriously at the TCB stuff, but we simply need to start raising
   the bar on host security wherever possible.
>       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.

I'm not so sure.  Point #7, and history tends to show us that some people
will continue to run old, buggy, insecure programs long after patches are
available.  There may be some gain to be had overall in enhancing the 
security of such sites if for no other reason than to stop them from 
being launch points and breeding grounds.

>       -> 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.

We can't even make FTP and SNMP go away, I don't see where we can't gain some
benifit from network grep type detection.  Especially if it's integrated
with netflow statistics on the backbone.  Peer pressure is one of the few 
things that will divert resources when it's in the form of a BGP filter.

As we move routing infrastructure inwards, the utility of blackholing some
networks based on activity and follow-up could become good.  I think 
real-time provides too much chance for DoS attacks, but reading the "grep 
report" every Monday to see who to blackhole could bring a certain 
sparkle to the mornings.

>      -> Based on assumption #4 I question the utility of IDs in the
> firewall, though it's probably a component of a complete solution.

I always question the utility of adding to the bastion.  IDS should be a 
part of a firewall solution, but putting it on the same box as network 
access control seems not logical to me.

>       -> 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.

It still could be used to be indicitave of something askew like a 
tunnel.  While the slow methodical attack will bypass this in most cases, 
it's possible that trending data combined with usage and accounting 
information could provide utility to security as well as network management.

>       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. :(

It's worse than that.  It's starting to become user-specific in some 
instances.

>       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?

Assuming you're not always protecting fragile eggs, there seems to 
sometimes be utility in determining what an intrusion of a network *was*.

>       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!"

Internal and External are too artificial to me.  I have zones on both 
sides of my perimeter which I consider absolutely crucial.  I'd want to 
react vigorously to an event on any crucial zone on my network.  Local, 
remote, or inside or outside.  Reacting to the non-crucial zones is where 
you start training your Operations staff, up-and-comming admins, and the 
like.  

>       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...

I think you've thought it out much better than a 6 year-old would have ;)

>       So, let me ask you a few questions:
>       -> Will you actually react to all the "attacks" your IDS finds?

What's an "attack"?  Where is it being done at, from "inside" or 
"outside"?, what's the target?  Do I only get one level of notification?
Does increasing monitoring of certain resources automaticly count as a 
reaction?

>       -> Will you immediately rush to block land, flounder, blick, and
>               augenblick2 attacks as soon as someone tries to use them
>               on you?

That would depend on the pay-off a DoS attack would give someone if I did so.
Hopefully, if I've engineered everything correctly, my critical systems 
have alternate access points and redundancy.  In that case, then yes, for 
the primary resource, I'd probably have it set to auto-block.

>       -> Will you monitor all the logs?

No, I'll find a lackey for that.  I'll trend the logs and someone will 
look at them or a summary of them, or they aren't useful enough to generate.

>       -> Will you ever get any sleep?

Yep.  Once I figure out what's "immediately important", what's 
"mid-term important", what's "long-term important" and what's rm'able. 

Just like with firewall logs.

Paul
-----------------------------------------------------------------------------
Paul D. Robertson      "My statements in this message are personal opinions
proberts () clark net      which may have no basis whatsoever in fact."
                                                                     PSB#9280