Joshua Randall

v11.3 Changes to ESA Script Outputs

Blog Post created by Joshua Randall Employee on Apr 12, 2019

In RSA NetWitness 11.3, one of the behind-the-scenes changes to the platform was moving the script notification server from ESA onto the Admin Server.

 

This change opens up a number of possibilities for scripting and automating processes within the NetWitness environment, but also requires a few changes to existing, pre-11.3 scripts.

 

Prior to 11.3, the raw alert data would be passed to the ESA script server as a single argument which could then be read, written to disk, parsed, etc. e.g.:

 

#!/usr/bin/env python 
import json
import sys

def dispatch(alert):
   with open("/tmp/esa_alert.json", mode='w') as alert_file:
      alert_file.write(json.dumps(alert, indent=True))

def myFunction():
   esa_alert = json.loads(open('/tmp/esa_alert.json').read())
   .....etc.....
   .....etc.....

if __name__ == "__main__":
   dispatch(json.loads(sys.argv[1]))
   myFunction()
   sys.exit(0)

 

 

But in 11.3, the raw alert gets broken up into multiple arguments that need to be joined together.  One possible solution to this change could be something like this:

 

#!/usr/bin/env python
import sys
import json

def dispatch():
   with open("/tmp/esa_alert.json", mode='w') as alert_file:
      a = sys.argv
      del a[0]
      alert_file.write(' '.join(a))

def myFunction():
   esa_alert = json.loads(open("/tmp/esa_alert.json").read())
   .....etc.....
   .....etc.....

if __name__ == "__main__":
   dispatch()
   myFunction()
   sys.exit(0)

 

...or this:

 

#!/bin/bash
OUT=()
for a in "$@"
do
    OUT += "$a "
done
echo -e "$OUT" > /tmp/esa_alert.json

 

As I mentioned above, moving the script server onto the Admin Server opens up a number of possibilities for certain queries and tasks within the NW architecture.  Some that come to mind:

  • automating backups
  • pulling host stats and ingesting them as syslog events
  • better ESA Alert <--> Custom Feed <--> Context-Hub List <-- > ESA Alert enrichment loops

 

However, one restriction I've been trying to figure out a good solution for is that the Admin Server will run these scripts as the "netwitness" user, and this user has fairly limited access.

 

I've been kicking around the possibility of adding this user to the sudoers group, possibly adding read/write/execute permissions for this user to specific directories and/or files depending on the use case, or sudo-ing to a different user within the script.

 

Each of these options present certain risks, so I'd be interested in hearing what other folks might think about these or other possible solutions to run scripts with elevated permissions in as secure a manner as possible.

Outcomes