As Incident Responders or even as simple malicious activity hunters one of the key sources of data we rely on daily is the ability to track all command execution and endpoint activity. Here at RSA we use NWE’s Behavioral Tracking to give the level of visibility that is comparable to what Sysmon is doing. Due to the importance of this type of visibility and the buzz that Sysmon is generating in having this data on your SIEM/Log solution, I felt that it is important to provide some guidance on how you can accomplish the same thing using NWE.

If you already have NWE deployed to your endpoints there is no need to configure or manage another solution. The question that needs to be answered is how to retrieve this data from NWE to feed your SIEM/Log solution. This is indeed possible, and with a little help from colleagues and peers (I can name you if you want) I started to play with an SQL query to retrieve such data from the NWE database. The following query is suitable to import NWE data into a SIEM/Log Management solution:

In this query the question mark “?” at the end of the last line needs to be automatically replaced by the previous highest entry already collected with the previous query execution. Each solution will have its own way of tracking and processing this query. In some solutions you may only need the portion between the main ()s group as they will build the rest automatically. Other solutions will probably require more work/tweaking.

For Netwitness for Logs, Chris Thomas created a post here with all the details needed to accomplish this integration. I'm sure the same can be done with Splunk, ArcSight, Elastic, <insert your favorite solution here> so please feel free to post your experience to the comments section of this post.

Here's a configuration example for use with Logstash on an ELK stack. Please follow your Logstash/ELK documentation on how to deploy the JDBC plug-in and other configurations, the MSSQL JDBC drivers will need to be installed. The main point the query needed a bit of tweaking in terms of the hash fields.

Next up, some details on how to do this with Splunk. You will need to follow Splunk documentation on how to install Splunk DB Connect and the MSSQL JDBC Drivers for it. Their latest documentation is here.

Once that is installed and running you will need to create an identity (username & password - don't forget to create an SQL User on the NWE DB for this first) to connect to the NWE DB and a connection (DB details) as shown below:

Once the connection is setup you can create your DB Input for data collection. The screenshot is just too big to be of any use so the resulting inputs.conf is shown below instead.

The field names are not currently Splunk CIM compliant but I'm happy to adjust them in the query if someone wants to send me the appropriate mappings. Also please adjust your source, sourcetype and index accordingly, this is all much easier to do via the Splunk DB Connect App UI.

Here's an example of how your data would look and what you can do with it.

edit: oh I haven't read that part carefully : The database structure used by NWE may change at any time. No testing has been done to measure the impact on performance for a production NWE Server. [I suppose the latter depends on poll intervals for ODBC and general server load]

a) package it via live and make it supported.

=) any plans?

b) we were previously told there were some limitations to NWE tracking NOT showing all equivalent parent/target combos.

The answer was complicated but basically it sounded like 'only some important and unique events are shown' . Can you confirm the status for that in 4.2.0.4 and 4.3.0.1?

c) fix NWE for logs being able to do its own collation of Process parent and target info.

d) are there unexpected side effects from collapsing the Tracking event flags into the action column (Pretty sure they're unique per tracking event so probably ok?). Is there any way to more generically collapse it to prevent reviewing the 'interesting flags'?

e) expose the checksums (though correlating if you pipe all the hash types into CHECKSUM) is a pain . EDIT: ah ok, nevermind : HashSHA256_Target.MO.HashSHA256,

A few of your items are about the NWE product itself and/or a possible official integration, with that in mind can I kindly ask you that if you haven't already done this that you please submit these via RSA support so you can have an official answer from our Product Management team and they can also effectively track your needs!