Skip navigation
All Places > Products > RSA NetWitness Platform > Blog > 2016 > July
2016

Report's header and titles can accept variables. This should help easily identify content of the report.

 

The syntax to include variables in the report is,

ReportName ${VARIABLE_NAME}

 

Steps to include variables,

 

1)  Create a list adding some required values.

 

2) Create a rule defining variable as follows and here we have defined a variable ‘VAR’,

 

 

var1.png

 

3) While scheduling report mention the List and Variable used in the defined Rule,

 

var2.png

 

4) Add the same variable name in the report header title as below syntax and schedule,

 

var3.png

 

5) Go to view schedules reports and click this report and we can see VAR name is replaced by its value,

 

var4.png

 

 

 

I'm pleased to announce that we have qualified and now support the ability for our Virtual Log Collector 10.6 to be installed in Amazon's AWS infrastructure.  This will allow customers to deploy VLC in AWS in order to collect logs from currently supported event sources and protocols.  This includes Amazon's CloudTrail as well as other supported event sources, such as operating systems, applications, and other infrastructure sources.  These logs will then be compressed and encrypted to be sent back to a corporate instance of Security Analytics.

 

 

The RSA Security Analytics AWS Configuration Guide can be found here.

A public key infrastructure (PKI) is a set of hardware, software, people, policies, and procedures needed to create, manage, distribute, use, store, and revoke digital certificates and manage public-key encryption. The purpose of a PKI is to facilitate the secure electronic transfer of information. It is required for activities where simple passwords are an inadequate authentication method and more rigorous proof is required to confirm the identity of the parties involved in the communication and to validate the information being transferred.

That is the broader definition of PKI, in SA webserver what it means is to securely authenticate the user using his/her Digital Certificate and establish a secure channel between the user's browser and SA webserver. At the moment SA webserver supports below Authentication/Authorization schemes, PKI is the 4th authentication/authorization scheme.

  1. Username/Password against internal database
  2. Active Directory
  3. PAM

  style="margin-top:auto;margin-bottom:auto"

  • Trusted CA certificates
  • User certificate (issued by CA)

 

When a user connects to SA Server, SA tells browser to provide a certificate to authenticate. Browser then reads the list of trusted entities and prompt user to select one of the applicable certificate that can be used.

  • SA Server then
    • Reads the certificate information
    • Extracts the user information from the certificate
    • Lookup the user in AD
    • Logs the user in
    • No user password required

Under Administration >Security > Settings you can configure it.

 

 

 

Let us know what you think and how it works for you!

 

More information can be found on RSA Security Analytics Documentation under Security Analytics 10.5 > System Security and User Management > Set Up Public Key Infrastructure (PKI) Authentication > Overview

William Hart

Email Parsing Options

Posted by William Hart Employee Jul 1, 2016

We have got several requests to generate additional parser updates to some of the parsers we distribute in Live. One approach we have taken to make these optional changes available for customers is to allow for an external configuration file to be read by the original parser. This provides for some customization depending on environment requirements while eliminating the need for customers to be able to write a parser. The reason for them being optional is some configuration changes may generate more meta requiring further storage or may require additional parsing resources or not be appropriate to an environment.

 

As an example the default email parser, MAIL_Lua, reads email messages regardless of transport protocol (e.g. SMTP, IMAP, POP3) and registers all email addresses into the email meta key. In the options file a user can enable to register the email sender to email.src and the recipient to email.dst instead of registering them all to email. There are additional options available in the attached MAIL_lua_options.lua file that can be enabled/disabled as well.

 

To have these options take effect the following steps are required.

 

1) Upload the MAIL_lua_options.lua file into the /etc/netwitness/ng/parsers folder on the appropriate decoder where the MAIL_Lua parser is applied.

 

2) To enable the source and destination email change mentioned above modify the word false to true on line 24. This is the last line before the end of the function named registerEmailSrcDst

 

3) Validate that the default email source and destination meta keys are included in the appropriate concentrator default index file (e.g. index-concentrator.xml) located in /etc/netwitness/ng on the concentrator.  This file can be viewed by command line after logging in using secure shell or in administration section of the user interface at Administration > Services > <concentrator name> > config > Files tab. The lines that should be in there and that will be populated by this change are:

 

<key description="Source E-mail Address" level="IndexValues" name="email.src" format="Text" valueMax="2500000" />

<key description="Destination E-mail Address" level="IndexValues" name="email.dst" format="Text" valueMax="2500000" />

 

4) For this to take effect, a decoder service restart is required. This will cause a service interruption so recommend making this change during a maintenance window.

 

I welcome any suggestions on importance of these types of options for this scenario as well as others. As well if it would be better to have these options available in the Security Analytics user interface.

 

Note: I am just a conduit for this information and have to give credit for the creation of these parser options to RSA Content Engineers.

Are you looking for a way to trigger those PCAP downloads so they automatically open in a third party tool? There is a way to do this in Security Analytics 10.4 and above. It does require enabling some settings that may not be enabled by default depending on which version of Security Analytics you are running.

 

To make your PCAP extractions more efficient do the following steps.

 

1) Make sure the Download Completed PCAPs setting is enabled. This is available in the Security Analytics interface through the Investigate > Navigate > Settings widget as shown below. The download will still be tracked in the download job queue on the SA server but after completion of the download it will save it to your client machine in your browsers designated download folder.

 

PCAP_Download_Setting_hl.png

 

 

2) Optionally setup file associations on your operating system so that files with a .pcap extension open in your tool of choice, say Wireshark for example.

 

Note: Although you can configure this method for downloading files (other then PCAPs) I do not suggest it unless the system you are running your browser on is a machine you are allowed to download and execute malware on. By that I mean the machine is on a segmented network or is a sandboxed virtual machine or some other endpoint software is in place to limit the effect of malware. The reason I bring up this warning is that typically the files being downloaded from Security Analytics are ones suspected of being malware or related to malware and if they are automatically opened by their native application you could end up infecting your own system.

Filter Blog

By date: By tag: