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:
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.