IDS: Re: Question on resources needed to manage IDSes

[Jimi Thompson <jimit () myrealbox com>]

All,

As one of the "analysts" in question, I can tell you what I'd like to 
see from my IDS.  I'd like to see an AI engine I can train with a rule 
base that I can modify.  I want multiple sensors I can park all over my 
network and tie to a single console.  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.  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.
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.
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.
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.
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.
>
>  

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