Re: Statistical Anomaly Analysis? (was: a bunch of things)

From: John S Flowers (jflowers@well.com)
Date: 03/18/02 

Date: Mon, 18 Mar 2002 00:16:26 -0800
To: Josh Gray <grayjr@cerias.purdue.edu>
From: John S Flowers <jflowers@well.com>

Inline, again...

On Sunday, March 17, 2002, at 10:29 PM, Josh Gray wrote:

>
>
> John S Flowers wrote:
>
> > You said, " Basically my point is that your IDS is what you make of it.
> > If you're tired of seeing the same alerts every day then disable them."
> >
> > The stated purpose of an Intrusion Detection System is to detect an
> > intrusion on your network environment. If any IDS cannot do this - the
> > task it was specifically designed to perform - I would say it is both
> > incorrectly named and also totally useless.
>
> Thanks for the definition...so you're saying that if someone never
> updates their signatures then they aren't using an IDS?

Actually, I would personally say this is true. Yes.

Security is a dynamic problem. The landscape changes because attacks are
created, uncovered, discovered and so forth. If you're not putting a
dynamic solution against the problem of security, the solution will fail.

This also means that I do not believe in the magic bullet -- that mythical
security solution that uses some new technology that does not require
updates of any kind. I believe this is also an impossibility in our
lifetime.

>
> >
> >
> > The notion of disabling attacks just because they annoy someone is
> > completely ridiculous. It's like poking your head in the sand and saying
> > "no one can see me, since I can't see them!" If someone actually cares
> > about the network they're protecting, this kind of approach to security
> > should be unconscionable.
> >
>
> What is the point of detecting an AIX attack when you have nothing but
> windows machines on your network? Sure some people care that the attack
> was
> attempted, but those aren't the people complaining about too many alerts.
> What do
> you do when you see an attack for an OS that isn't on your network? Do
> you
> respond? If you have no intention of responding then why do you care?
> If you
> want to keep it for whatever reason thats fine, but once again those aren'
> t the
> people complaining about too many alerts.
>

I may be missing your point, but it seems like we're agreeing on this
issue. I've said before that I _don't_ want to be alerted when an attack
is destined for a host that isn't up or doesn't exist. That's my policy.

>
> >
> > Unfortunately, I see this attitude manifest itself every day when a
> > network administrator gets a page, looks at the pager, then cradles it
> in
> > the holster again and looks up, saying, "Just our IDS going off again..
> ."
> >
>
> You need to get a new admin. You might want to consider some dedicated
> analysts that won't just brush things off.
>

Believe me, it's not OUR administrator who has done this. Our Network
Admin is amazing. ;)

>
>
> >
> > And then said, "If you know your network really well then you can tune
> > your IDS to look for things that shouldn't be happening."
> >
> > This, on the other hand, I completely agree with. You should be familiar
> > enough with your network to tune your IDS to alert on anything that
> > violates your network policy. This might be a port scan or or access to
> a
> > sensitive server or someone using hotmail or an actual attack. In any
> case,
> > detecting _everything_ that could be considered an intrusion is
> exactly
> > the point of an intrusion detection system.
> >
>
> If you disagree with my suggestion about disabling alerts then how do
> you expect to tune your IDS for your network? If you don't prioritize
> them or
> disable them then how do you tune your IDS?
>

This is clearly an issue of degree and/or semantics. I am a true believer
in tuning an IDS to only look for events and exposures that are violations
of network policy. I guess I'm just used to having an IDS that tunes
itself based on the current network environment. Think of it as
dynamically loading the "rules" for the IDS with some frequency, but the
rules are dynamically generated for the current environment.

The idea of a static IDS posture is completely foreign to me.

Because of this, you are probably thinking of a subtractive method of
updating the IDS, where I am thinking of the IDS functionality in terms of
being additive, starting with no rules and moving to a state of rules
based on the policy of the network. In this way, I'm not disabling
anything, I'm simply creating rules as they are needed for the _current_
network exposure map.

A quick example;
  If a Solaris host comes online, it is noticed by a policy management
system (in our case, the IP360 Exposure Management software). This policy
manager then takes the information from the network -- as discovered --
and passes relevant information to the IDS, saying; "IP address n is
Solaris with ports x-z open and running services s1,s2,s3... Corporate
policy forbids t and g events to occur." Then, a custom state is generated
on the IDS to keep track of these possible events.

I apologize for the slight misunderstanding. Sometimes I'm too far into
how things work in my world to think about how everyone else looks at this
problem space or how other technologies work.

I'll shake my head a bit and snap back to everyone else's reality before I
post again. Thanks for putting up with me not seeing the big picture back
there...

/jsf

>
> Josh
>

Relevant Pages

  • RE: IDS that retaliates.
    ... launches an attack and suddenly he looses his connection .. ... a genius to work out an IDS is in play... ... Using RST packets - be careful with things like SYN floods as sending a ... "Perfecting the Art of Network Security" ...
    (Focus-IDS)
  • RE: IDS that retaliates.
    ... launches an attack and suddenly he looses his connection .. ... a genius to work out an IDS is in play... ... Using RST packets - be careful with things like SYN floods as sending a ... "Perfecting the Art of Network Security" ...
    (Security-Basics)
  • RE: Announcement: Alert Verification for Snort
    ... I think what you are really after is to be found in a good security ... combining VA and IDS will ... 100% accurate across your network. ... accuracy to determine if an "event" is really an attack likely to cause ...
    (Focus-IDS)
  • RE: Signature and Traffic generation
    ... I'm curious about this statement- why don't I want to know about network ... attack tool behavior and potentially finding an attacker before they get ... > IDS we tested failed to properly categorize the attacks as ... Basing detection on potentially out of date vulnerability information seems ...
    (Focus-IDS)
  • Re: IDS and NMS
    ... Start by designing and installing a network. ... Next, a more detailed view of the network is required, so a NMS is ... the network administrator wants to see what ... This is where integrating the IDS console into the NMS makes sense. ...
    (Focus-IDS)