Whitelisting a false positive

[JeremyKerwin]

Hey all, this may seem like a simple question.

I'm getting the following alert for a known DNS lookup.

risk.suspisious = dns_extremely_low_ttl

threat.category = suspicious

threat.source = netwitness

Now the alert is being generated when hosts are doing a DNS lookup to our proxy pac file which I do now has a very low TTL because of a round robin approach.

So because I know it's a false positive what would be the best way to 'whitelist' or tell SA 'yep, I know that one, you can ignore it'.

Thanks.

[DavidWaugh1]

Hi Jeremy

This is one approach that I take:

000029487 - How to refine the Investigation view to exclude false positives in RSA Security Analytic...

Basically you can create a new meta key to store the reason that you consider the traffic to be safe and then exclude any known safe traffic from your investigations.

I'm sure there are other ways of doing this too.

[KevinClerks]

David Waugh's approach is absolutely the most concise. In my environment, I have created a meta key called "Whitelist" and populated it with mix of feeds based on org.dst, vulnernability scanners, as well as app rules. When I want omit results that meet any of these conditions in reports/charts/alerts, I include the additional clause of "whitelist !exists".

In your particular case, you might be able to create an app rule that populates a whitelist meta key with a value on the condition "service = 53 && alias.host = (your proxy hostname)"

[JeremyKerwin]

This is good stuff guys, thanks a lot.

Do these app rules have to be replicated across the Decoder/Concentrators and Brokers?

[KevinClerks]

That depends on if your other Decoders capture the same traffic. If they capture something completely different, it may not be necessary. However, I always replicate all my app rules across Decoders. I wouldn't call that a "best practice" because the others might be evaluating traffic it never sees. But it certainly keeps admin and management a lot easier.