Re: Dream IDS was Q on resources needed to manage IDSes

["Andy Cuff [Talisker]" <lists () securitywizardry com>]

Hi Jimi,
Most of what you require has been available from various commercial IDS for
some time, but it requires you to iron out the false positive manually

> .  I'd like to see an AI engine I can train with a rule
> base that I can modify.

AI can be prone to problems through training it to ignore bad traffic
gradually. Having said that SHADOW is pretty good.
 Better (IMHO) is using plenty of IF ELSE etc like statements within a
protocol decode signature.  I came across an IDS last week that allows the
customer to write protocol decoders with trivial ease, I was completely
blown away! I signed an NDA but I'll ask if I can discuss it on list ASAP.
(I needed a cold shower!) I'm the worlds worst coder and even I could figure
it out ;o)

> I want multiple sensors I can park all over my
> network and tie to a single console.

no problem most will do this with ease.  BUT check out their scaleability
how big does the back end need to be to cope with the quantity of sensors
you're talking about.  If I remember correctly ManHunt does this quite well
by distributing the number crunching across the sensors.

> I want to be able to feed it a
> network diagram so that it "knows" what is authorized to live where.  It
> will know what the OS is supposed to be and what the applications should
> be.  That should tell it what kind of traffic to expect to and from
> every thing on the network.

Perhaps not a diagram but you can do this with a combination of tuning and
fingerprinting, this will also overcome the problem you'll find with the
diagram idea of the information becoming dated overtime.

>  I also want it to alarm if one of my
> Windows file servers starts suddenly serving port 80 traffic.  I want it
> to alarm if it starts being a proxy or a router or something else that
> it's not supposed to be.

This can be achieved through tuning signatures to the hosts, rather than
what you are suggesting I'd suggest reversing it to report on anything
serving 80 traffic except webservers etc.
> If I track something down and find out that it's bogus (for example the
> L3trevier pings on a Windows network) because its actually legitimate
> traffic, I should be able to tell it not to process that any more
> because its actually my Windows hosts talking to the domain
> controllers.  Once I tell it that it's normal Windows traffic, it should
> still alarm if it sees this coming from something that's NOT a Windows
> box or going to something that's not a domain controller.

normal false positive tuning
> I want to be able to feed my SuperWidget 1000A a new rule for the latest
> virus traffic signature/root exploit/IIS bug/root kit/whatever and
> having it adjust my firewall rules and router ACL's to block that
> traffic (and other sufficiently "bad" traffic) when it sees it.   I only
> want to be bothered when it finds something it doesn't understand.

Rather than tune the firewall why not use an IPS and block such traffic
there, alternatively and not quite so effective use the various automated
response features of your IDS.
> When someone makes something that will do these things, I'll buy it.
> Until then, I'm sticking to Snort/ACID/MySQL for IDS and I'll just be
> running myself and my staff ragged while we try to keep up with the
> alerts and keep tweaking the rules.

Try a few commercial IDS/IPS you'll be pleasantly surprised, pit it against
your Snort and run a comparison.  Though I find Snort pretty good these
days,  it has a good breadth of signatures if not the depth of individual
signatures that I'd like to see, it complements the commercial offerings
very well at a fraction of the purchase price though some of this is offset
in the cost of maintaining it..

take care
-andy
Talisker Security Tools Directory
http://www.securitywizardry.com

> Jimi
>
>
>
>
>
> Teicher, Mark (Mark) wrote:
>
> > Anton,
> >
> > I disagree. If the event correlation engine is designed correctly.
> > Human analysts should be rarely introduced into the equation of # of
> > humans/ #of sensors.  It is a big "IF".  Most MSPs didn't understand
> > that designing event correlation engines takes time and money.  If the
> > MSP would have focused more on event correlation then building nice
> > SOC's to impress their potential customer base, this discussion would be
> > irrelevant.  Very few MSP have perfected their event correlation engine
> > in a scaleable sense.  Those who were almost there have been gobbled by
> > much larger companies who just bought into the market or just wanted to
> > eliminate the "barbarians at the gate"
> >
> > Compared to the number of MSP's in the market place over 5 years ago,
> > compared to the number of MSP's left, it is fair to say, either a) Were
> > acquired b) Massive layoffs/management re-organization c) Influenced a
> > couple of analyst panels stating the have better technology, market
> > share and beating their competition d) Have some guy with a pony tail as
> > their CTO writing books and being quoted when a major security related
> > news article is posted to the Internet and get a couple of trial
> > customer e) Out of money
> >
> > Some of the options may apply to the current market..
> >
> > /mark
> >
> > -----Original Message-----
> > From: Anton A. Chuvakin [mailto:anton () chuvakin org]
> > Sent: Friday, December 05, 2003 1:07 PM
> > To: focus-ids () securityfocus com
> > Subject: Re: Question on resources needed to manage IDSes
> >
> >
> >
> >
> > > > > 1-5 IDS sensors - 1 Analyst
> > > > > 5-15 IDS sensors -2 Analysts
> >
> >
> >
> > > being.  It would be generous to assume a human could qualify a
> > > reasonably complex alert in 30 seconds.  After that, it's simply a
> > The above also implies a certain usage scenario. One "complex alert in
> > 30 seconds" implies that the analyst just sits there and stares at the
> > console where alerts pop up - which might be neither the most common nor
> > the most effective way. The tools available to analysts would also
> > matter, namely, how much time it will take to collect the context info
> > and to make a decision.
> >
> > I suspect the specific IDS usage details will heavilly affect the
> > "analyst to sensor" ratios.
>
>
> --------------------------------------------------------------------------
-
> --------------------------------------------------------------------------
-
>


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