Skip navigation
All Places > Products > RSA NetWitness Platform > Blog > 2016 > April > 01

It is a surprise to me how many people do not know all the operators available to them in the query language for investigations. Hence why it made sense to through some of the lesser known ones here.

 

To start, the group NOT statement which effectively does the same thing as the ! when attempting to negate an entire statement. For example can easily execute the query username !='monkey' but does not work when attempt to do

!(username='monkey'). Instead the proper syntax is ~(username='monkey') or alternatively NOT(username='monkey'). This works for all functions such as NOT(username contains 'monkey') or ~(username ends 'monkey').

 

Another one that is useful is <= which along with >= can be used on numerical values. For example if wanted to find all sessions with TCP destination ports less then or equal to 1024 can execute: tcp.dstport <='1024'

 

These can be utilized in execution of a report using the where clause as well as investigation queries.

 

Further details on these as well as other syntax specifics can be found in the online Security Analytics documentation:

Queries - RSA Security Analytics Documentation

William Hart

How to Filter Feeds

Posted by William Hart Employee Mar 31, 2016

Do you have a feed that is valuable but causes some false positives occasionally? Then this post is for you! The capability exists to filter out specific values from feeds without modifying the original data set. Why would you want such a thing? Well in some cases maybe the feed is generated from RSA or another entity in your organization that limits your ability to manipulate it before ingested in the Security Analytics decoders. In general the Intelligence is worth keeping the feed but there are some values that you wish could be ignored.

 

How do we achieve this? Simple, follow the steps below:

 

1) Determine the feed that is generating the errant value(s).

 

In Security Analytics investigation focus on the threat source meta key to determine what feed(s) generated the alert or meta for the IP, domain, or other value you want to whitelist or filter out.

 

feed_source2_hl.png

In the example above at the time of this old sample data the domain was listed as suspicious by various threat sources highlighted. If it was decided that this determination was incorrect a filter file with the hostname alias could be added for each feed listed in the threat source.

 

2) Create a filter file and add the errant value(s) to it.

 

To pick one as an example the malwaredomainlist-domain.feed is generating meta that the purehtc.com domain is malicious. In the feed file named malwaredomainlist-domain.filter add the purehtc.com domain on a single line. If additional values generated by this feed are incorrect can add subsequent rows of those domains as well to the same file.

 

3) Deploy the filter file in the same directory on the decoder(s) that the feed has been applied.

 

To get the filter file in the appropriate location on the decoder (e.g. /etc/netwitness/ng/feeds) either secure copy the file to the system or use the feed upload option on the feed tab located on the decoder configuration page.

 

feed-filter_upload.png

Unfortunately that page does not allow you to view the filter files loaded once they have been uploaded. You can however view the feed filter in the file tab located on the decoder configuration page.

 

feed-filter_view.png

 

 

4) Disable and enable the feed so decoder realizes filter file exists.

 

5) That is it. Enjoy!

 

Please let me know if there are any additional questions or improvement suggestions in this area.

Filter Blog

By date: By tag: