Re: Snot/state

From: Greg Shipley (gshipley@neohapsis.com)
Date: 03/18/02 

Date: Mon, 18 Mar 2002 08:56:35 -0600 (CST)
From: Greg Shipley <gshipley@neohapsis.com>
To: focus-ids@securityfocus.com

On Sun, 17 Mar 2002, John S Flowers wrote:

> Turning on the state engine on most Intrusion Detection Systems will
> prevent them from detection some false alarms. It will not prevent them
> from seeing others. As stated below (and within this thread), you'll
> minimize, but not eliminate false positives by enabling this feature.

Less important, but my "turn on state" comment is in reference to
combating snot, not as a general "state will save you from the world of
false positives."

BIG difference.

> While programs like Stick and Snot don't do a very good job of
> maintaining what the IDS considers state, it is none-the-less still very
> easy to fool one of these so called "state engines" by doing little more
> than sending a false protocol handshake.

...assuming that your infrastructure allows one to spoof using internal
addresses originating from external interfaces....

And if that's the case, you've got other problems.....

-----------------

Perhaps I'm getting grumpy in my old age *grin*, but I don't understand
how people aren't growing weary of the false positive debates. False
positives are going to happen. IMHO, deal with it and move on.

Unfortunately, it appears we're still stuck in the "deal with it" phase.
What I don't understand is why vendors don't provide more options for
sifting through alert data. Give me, the operator, some information so
that *I* can measure relevancy. Give me secondary signatures (Did attack
X generate return traffic Y?). Give me the ability to have watch lists.
(Which of my internal machines are most critical, and can I identify/
weight them accordingly?) Give me the ability to weight signatures. (If
sig Z falses a lot, can I lower it's reliability weighting?) More
importantly, give me the option to enable or disable things, and let me
make the call. Instead, we're given "low, medium, and high" as our
metrics and forced to swallow them. No wonder everyone's arguing about
false positives - our options for dealing with them suck!

[Random thought: Maybe the focus shouldn't be so much on reducing the
number of alerts, but providing the ability to classify and sift through
them? I know some of the Enterasys folks started talking about this a
while back....]

As a side note, I find it interesting (and perhaps a bit ironic) that
members from the vendor community are dictating what an IDS should and
should not be doing, yet some of the corporate users (read: consumers) are
disagreeing. Huh, what does THAT tell us? :)

Sure, maybe the ultimate IDS is only going to alert me to things that I
care about. However, what I care about should be defined by me, not the
IDS, or the vendor. So if I say "Only alert me to remote admin/root-level
compromises that are succesfull against the hosts on my network," sure, it
would be great if the IDS could do that accurately. But if I say "please
alert me to all things attacking me, succesfull or unsuccessful" I should
be able to have my IDS do that, too.

In short, I think part of the IDS problem is the disconnect between what
the technology COULD do, what it SHOULD do (again, according to who?), and
what people are actually using it for in the real world. I will humbly
suggest that some people today use IDS as a low-level, minorly effective
burglar alarm and trending/reporting tool...and little more.

And that's FINE.

-----------------

IMHO, less important, but I wanted to point out:

> How can you know if you're being attacked if you don't even know what
> you're protecting?

Er, um, I can certainly know that I'm being attacked without knowing what
I've got. That's pretty easy, actually. Would it be MORE helpful if I
knew what I was defending? Sure, but that doesn't limit me from observing
the obvious. But don't take my word for it. Talk to any Fortune100
(500?) admin that's involved in perimeter security. Most wish they knew
what they were protecting....but don't. However, I can guarantee you that
they handle quite a few attacks - attacks that they are well aware of.

-Greg

Relevant Pages

  • RE: On the definition of false positive - was: Re: location of an IPS
    ... You define false positive as an alert on something that was not actually an ... My issue is with the use of the word "attack". ... IDS are used to alert on network ... attack - you could test for false positives with false negatives ...
    (Focus-IDS)
  • False positives, negatives and dont cares
    ... Just following up the "IDS is dead, etc" thread, I thought I'd lay out ... False positives happen when the IDS ... attacks heading to targets that aren't vulnerable to them. ... that Snort generates "tons of false positives". ...
    (Focus-IDS)
  • RE: "false positive" inanity
    ... are we concerned about IDS ... finding all possible attacks better or do we just care about the attacks ... Using this type of technologies, ... truly cut down false positives without increasing false negatives ...
    (Focus-IDS)
  • Re: Signature and Traffic generation
    ... > actually benchmarking an IDS' ability to detect false positives, ... Many of the low-end packet grepping IDS fall prey to this ... handful of these attacks would be false positives, ... > rather than simulated pseudorandom packets like a smartbits - so that's ...
    (Focus-IDS)
  • Re: RE: Tuning false positives - SIM is not the answer
    ... SIM *can* help with false positives. ... let's say we have an IDS alert that we suspect ... Will SIM eliminate *all* false positives and totally replace IDS ...
    (Focus-IDS)