RE: Active response... some thoughts.

["Rob Shein" <shoten () starpower net>]

I think the "all-or-nothing" attitude (well put, btw) comes from experience
with clients, who often take multi-part, comprehensive solutions and merely
implement the one piece that they think will do the job for them.  We've all
seen it...the bean-counters come in and before you know it, you're trying to
explain why they need everything you told them, not just the one thing that
(on the surface, through non-technical eyes that don't know TCP from UDP)
looks like a magic bullet.  Indeed, even with technical eyes, I seem to
remember some posts back during a heated discussion about IPS a few months
back where some seemed to think it was more of a solution than it really is
at this point.

> -----Original Message-----
> From: Frank Knobbe [mailto:fknobbe () knobbeits com] 
> Sent: Saturday, February 08, 2003 7:32 PM
> To: andre
> Cc: Ralph Los; lists () isecom org; 'Focus-IDS'
> Subject: Re: Active response... some thoughts.
>
>
> On Sat, 2003-02-08 at 15:50, andre wrote:
> > What about blocking only a few certain attacks, that could not be 
> > easily spoofed. Such like HTTP vulnerabilities and others 
> that need a 
> > complete handshake to work.
>
> Thank you for bringing this up. I'm a bit angered by 
> all-or-nothing attitude. As you correctly said, active 
> response doesn't need to happen to any and all signatures, or 
> rule violations.
>
> Active response (of any kind) have their risks, but they can 
> be implemented in such a fashion that the risk are bearable, 
> and at a point were they are worthwhile implementing. 
> White-lists are one approach, another is adding 
> 'intelligence' so that the active response can stop by 
> itself. I have tried to implement that in SnortSam by 
> implementation of simple thresholds. Once a threshold (of 
> responses) exceeds a certain level, SnortSam will undo the 
> last blocks (it modifies firewalls and
> routers) and then fall silent, or passive, until the level of 
> requests falls below threshold level, and then some (additional time).
>
> It's all a matter of checks'n'balances. Imho, programs _can_ 
> be written to avoid race conditions or situation where they 
> might get a locked in a loop (like responding to the response 
> of other IDSs.... that was a nice example).
>
> The idea of implementing safety measures and self-destruct 
> levers seems to fall short in the race to market with fancy 
> software these days...
>
> Regards,
> Frank