ESA False-Positive Suppression on Known Authorized Scanners

[RSAAdmin]

I am interested to hear how other people are suppressing ESA alerts from authorized vulnerability scanners.  It would be nice to have a global configuration so we don't to modify every alert rule.

We are tinkering with feeds, and adding meta data to exclude in rules, but are not having much luck.

Thanks.

[RSAAdmin]

Hi Tom,

If you are using SA 10.4 you could suppress quite easily with the new Incident Management feature. You'd basically write a simple rule to suppress what ESA alert (or alerts) is triggering.

If you can tell me what version of SA you are using and what type of decoders that will help me fine tune some suggestions for you.

-Scott Shreve (PM ESA)

[RSAAdmin]

10.3. We are getting ready to test 10.4 in development, and most likely will not move to platform for a couple of months.

Regards,

Tom

[RSAAdmin]

Gotcha. What kind of decoders (i.e. logs or packets, or both?)

[RSAAdmin]

We will have both but for now logs.

[RSAAdmin]

What I would suggest is to identify a sample session or (sessions) triggering the particular ESA alerts. Once you can see what is occurring to trigger the ESA rules you could write a  a filtering application rule and apply to the packet decoders so that meta doesn't get passed to the concentrator to be forwarded of to the ESA.

This is one of the reasons why we created the easy suppression in 10.4.

[RSAAdmin]

Sorry, meant logs and edited the post. How would you suggest that for logs? Since our scanners will be tripping 90% of the alerts configured in logs, this seems not to be a valid approach.

[Anonymous]

What is causing the alert to trip from a meta perspective?  If it is the source IP?  We personally have an app rule that will catch most of our scanner activity and I just tell it not to look at the logs if it contains that meta value.  We also did this for users that we don't care about alerting on for other rules.  We  did that through a feed though.