Optimizing Alert Reports

[RenatoAbreu]

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.

[DavidWaugh1]

Hi Renato,

Have a look at the post I made here: https://community.rsa.com/message/876624 

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.

[JohnSnider]

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.