AnsweredAssumed Answered

Optimizing Alert Reports

Question asked by Renato Abreu on Sep 29, 2016
Latest reply on Sep 29, 2016 by John Snider

Like • Show 0 Likes0
Comment • 2

Hello all,

I am working with custom reports containing alert.id metakey so I can summarize the alerts generated for some time range.

However I am experiencing a high number of false positives in these reports.

I would like to know if there is a way to use the RSA NetWitness intelligence to optimize these reports and reduce the number of false positives.

I am starting to use the solution recently so I don't know the best practices and the better way to create more efficient reports.

Could any one help me with this? Is there some tips to get better reports or some document of best practices for it?

Thanks in advance.

No one else has this question

Outcomes

2 Replies

David Waugh Sep 29, 2016 10:38 AM
Mark Correct
Correct Answer
Hi Renato,

Have a look at the post I made here: Whitelisting a false positive
Once you have a meta key to store the reason that you consider the traffic safe, you can then use && !exists safe.traffic in your report rules to exclude any traffic you consider safe.
Like • Show 1 Like1
Actions
John Snider Sep 29, 2016 7:00 PM
Mark Correct
Correct Answer
First you need to understand what the "alert.id" metakey is used for and then stop using it. "alert.id" is a holding key for meta values created by App rules, parsers, and feeds, when a value is created in alert.id, it is then processed by 3 feeds:
alertids_info.feed
alertids_suspicious.feed
alertids_warning.feed

Each feed processes the value of the "alert.id" key and populates multiple metakeys from that 1 alert.id
risk.info
risk.suspicious
risk.warning
threat.source
threat.category

These in turn can be used by other application rules to generate "alert" meta in the system.

alert.id was never meant to used as a catch-all for customer data, in fact, customers that are sending data to this key should change where they send that data, so as to not cause false positives within the other categories. alert.id's are NOT alerts, some of them just generate "information" (risk.info) that is useful when determining what traffic in a session is doing, or things that are of a suspicious nature ("protocol not over a standard port" or "non-standard traffic over a standard port") .

I generally configure 2 additional meta keys for customers for "customer.alert" and "customer.info", so as they develop rules or feeds that are tagging data (informational) that they use to BUILD an alert, they have a place to put it (customer.info) without using Built-in NetWitness keys, same for their alerts, they put them in "customer.alert" so they know what alerts are generated from home grown intelligence and what alerts are generated by the NetWitness content.
1 person found this helpful
Like • Show 1 Like1
Actions

Optimizing Alert Reports

Outcomes

Related Content

Recommended Content