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:fknobbeknobbeits.com]
> Sent: Saturday, February 08, 2003 7:32 PM
> To: andre
> Cc: Ralph Los; listsisecom.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
>
>
>
>
>

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]