IDS: Re: Alarm response strategies

["David W. Goodrum" <dgoodrum () nfr com>]

I think the "convergence" you mention below has already happened.  Have 
you seen an IPS device that doesn't do "detection only",  if that's what 
the customer wants?  Most people implement IPS in stages.  They are 
scared of the capability so they let it run in passive (detection only) 
mode for a while to see what it alerts on and to tune it appropriately.  
Then, after some period of time, they trust the detection to be 
accurate, and begin to turn on prevention components.  Sometimes a 
little at a time, sometimes by category... but rarely is it across the 
board.  i.e. they're getting some alerts that may still contain a few 
false positives, but some alerts that are dead on 100% of the time. 

I work for NFR, so I'll give you an NFR example of how we help users 
adjust to using IPS strategies vs IDS strategies.  In NFR's new IPS 
device, we have implemented a new feature called a "confidence level".  
It's how confident we are that what we alerted on was NOT a false 
positive.  So, once users get comfortable, they can say, "block 
everything with a confidence level greater than 90%."  or something like 
that.  And, assuming it was tcp based, they can also choose to blackhole 
those IP addresses.   Not to just pump up NFR's product though;  I have 
seen other company's IPS devices that do similar strategies, such as 
"block everything with a classification of worm". 

Also, I believe most good IPS systems on the market today have a 
whitelist.  Customers should use those whitelists to prevent spoofed TCP 
attacks also (spoofing the 3-way handshake is difficult, but it is not 
impossible).  If you client-side whitelist your critical servers, you 
won't have to worry about somebody spoofing their IP addresses, thus 
removing the risk of a self-inflicted Denial of Service.
So, in short, everybody I've talked to is already looking for an IPS 
that gives them all the benefits of IDS, PLUS the ability to block 
things that they know for sure they want to block, such as worms, viri, 
etc.  Your "convergence" is already here.
-dave


Rob Shein wrote:

> I completely agree that you can have reactive systems.  With regard to how
> this differs from an IPS, however, look at my post to the thread titled "IPS
> Futures".  An IPS is significantly different from an IDS with active
> response enabled, and I feel a lot more comfortable with how they behave.
> But be mindful that even these are largely nascent technologies that even
> now can be a headache.  And I'm not sure quite what your point was about the
> firewall...
>
> As for "smart reactive system," define "smart."  Obviously things can be set
> up incorrectly, but what's the other end of the spectrum?  As far as a true
> IDS, I can't recall one that I've worked with that I would trust with that
> capability as of yet.  What I do see happening is for IPS and IDS to
> converge to some degree, so that we can have the larger alert capability of
> an IDS combined with the proactive (couldn't think of a better word to
> offset reactive...just plain active, perhaps?) capability of an inline IPS.
> This would give variable options for reacting to various types of attacks,
> as well as more flexibility to configure the overall system to meet one's
> needs.
>
>  
>
> > -----Original Message-----
> > From: Frank Knobbe [mailto:frank () knobbe us] 
> > Sent: Monday, July 26, 2004 6:51 PM
> > To: Rob Shein
> > Cc: '(infor) urko zurutuza'; focus-ids () securityfocus com
> > Subject: RE: Alarm response strategies
> >
> >
> > On Sun, 2004-07-25 at 20:35, Rob Shein wrote:
> >    
> >
> > > Given the fact that IDS are prone to false alarms (and easy to make 
> > > trigger with spoofed traffic), it's the general consensus 
> > >      
> > that active 
> >    
> >
> > > responses are a bad idea.  For example, if I were to start scanning 
> > > your network, and find myself suddenly blocked at the router or 
> > > firewall, I would then spoof tons of UDP traffic from DNS 
> > >      
> > servers that 
> >    
> >
> > > I believed you might use.  Your firewall would then block 
> > >      
> > traffic from 
> >    
> >
> > > them, and bingo, I've just shut down your ability to resolve things.
> > >      
> > How does the inline-type IDS differ then? Or are you under 
> > the impression that your spoofed traffic gets blocked both 
> > ways? Why shouldn't a system be able to block unsolicited 
> > inbound packets, but let traffic that initiated from the 
> > inside out through without blocking it? (Oh wait... that's a 
> > normal stateful firewall then, right?)
> > My point is, you can have reactive systems. They just have to 
> > be implemented in a smart fashion so that silly "default 
> > attack scenarios" don't create the DoS of the older days 
> > reactive systems. 
> >
> > Once you have a smart reactive system, it will behave like 
> > the inline IPS. Except that it is reactive (doesn't block 
> > first packet). But the advantage is that you can react from 
> > more than one traffic monitoring point. With inline devices 
> > you are limited to that one choke point. Reactive devices can 
> > be triggered by sensors from all over your network.
> > That should be the main differentiator between those systems, 
> > not the intelligence (or lack of) behind it.
> > Regards,
> > Frank
> >
> >
> >
> >    
>
> --------------------------------------------------------------------------
> Test Your IDS
>
> Is your IDS deployed correctly?
> Find out quickly and easily by testing it with real-world attacks from CORE
> IMPACT.
> Go to http://www.securityfocus.com/sponsor/CoreSecurity_focus-ids_040708 to learn more.
> --------------------------------------------------------------------------
>
>  
--
David W. Goodrum
Senior Systems Engineer
NFR Security
703.731.3765



--------------------------------------------------------------------------
Test Your IDS

Is your IDS deployed correctly?
Find out quickly and easily by testing it with real-world attacks from CORE
IMPACT.
Go to http://www.securityfocus.com/sponsor/CoreSecurity_focus-ids_040708 to learn more.
--------------------------------------------------------------------------