Re: Using Snort & DB to remove false alarms

[Michael Boman <michael () ayeka dyndns org>]

On Tue, 2004-04-06 at 18:16, Sean Wheeler wrote:
[ ... ]
> Imagine a frontend : Show me alerts using "weed out the obvious" Y/N ? Y
> Script does the "weeding" as described above prior to displaying the alerts.
>
> Taking it further :
>
> You could use threshold suppression aswell, so you no longer see alerts from
> Webserver A
>  because "weeding" figured out the Webserver A is not vulnerable to that
> attack sig X.
>
>
> Conclusion:
>
> It would be possible using the above methodogoly abeit 1/2 days work at this
> point, we can use snort itself as one mechanism for identifying "false
> alarms"
>
> Your thoughts ??

I believe this intelligence should sit at the front end (or somewhere
between Snort and front end), and not in Snort. Snort should concentrate
on detecting as much as possible as fast as possible, and let other bits
and pieces do the rest (that's why barnyard was created in the first
place, so Snort doesn't need to worry about talking to databases etc).

Once in the post-processing/front end stage an alert should never be
hidden from an analyst. Just because the attack didn't succeed doesn't
mean it never took place.

But using visual means to describe the outcome of the attack is OK, just
that I am against hiding alerts from the analyst.

-- 
Michael Boman

Attachment: signature.asc
Description: This is a digitally signed message part