Davide Veneziano

Customizing the platform: ingest ESA alerts back to SA

Discussion created by Davide Veneziano Employee on Sep 4, 2014
Latest reply on Jun 2, 2015 by hubba900

With this third article regarding custmizations of the platform I want to discuss a simple but interesting scenario.The Event Stream Analysis module, responsible in Security Analytics to correlate logs and packets meta to identify potentially malicious or anomalous activities, can be configured to send its alerts via syslog, email or SNMP traps. This notification becomes then the last link of the chain which is transfering somehow the elaboration outside the platform (to the analyst, to a ticketing system, etc.).


There are however many relevant use cases that can be accomplished by feeding this information back into the product to, just to name a few, provide additional context during an investigatin making available all the alerts triggered by a specific user/endopoint or implement a sort of multi-step correlation scenario.


The attached prototype parser "rsasa_esa"  can be used as a starting point to develop a more complex way to ingest ESA Alerts back to Security Analytics. It is not intended to work on all Security Analytics releases and should be considered as a sort of proof of concept and a starting point for future development. As such. feel free to adapt it based on your needs.


The parser leverages the CEF template built into ESA to send out a syslog alert back to the Log Decoder. The parser works on the dvc, dvchost, src, shost, dst, dhost and duid keys at the beginning of the template. Other information are available within the message but since the presence and order is not easily predictable and the aim was to create a generic parser, are not taken into consideration.


The parser performs the following mapping between the CEF key, the envision variable and the netwitness meta keys:

  • dvc -> device.ip -> device.ip
  • dvchost -> device.host -> device.host
  • src -> saddr -> ip.src
  • shost -> shost -> host.src
  • dst -> daddr -> ip.dst
  • dhost -> hostname -> aliast.host
  • duid -> username -> user.dst

Of course, this mapping can be customized within the parser. For your convenience, screenshots for the configuration are attached as well.

Disclaimer: please DO NOT consider what is described and attached to this post as RSA official content. As any other unofficial material, it has to be tested in a controlled environment first and impacts have to be evaluated carefully before being promoted in production. Also note the content I publish is usually intended to prove a concept rather than being fully working in any environments. As such, handle it with care.