The complete overhaul of NW-Endpoint 4.4 into NW-Endpoint 11.3 includes (among many changes) a different method for creating your own, or tuning existing, endpoint alerts. In the old version (4.4), everything was a SQL query, but since we have moved away from Windows and SQL Server in 11.3, I'd like to shed some light on how the new process works, as well as include some tooling intended to assist folks who want to do this themselves.
The RSA NetWitness Endpoint Configuration Guide (https://community.rsa.com/docs/DOC-100160) has a section starting on pg. 12 that covers everything here in greater detail. If you'd like more information on this subject, I recommend taking a look at that document.
At a high level, the process for Endpoint 11.3 to generate alerts and calculate file and host risk scores goes like this:
Let's take a look at a couple of the OOTB examples and see how these different pieces are interacting with each other by examining the process that turns the "runs powershell decoding base64 string" rule into a potential risk score.
If the App Rule's condition statement is met, it creates a meta value of "runs powershell decoding base64 string" in the "boc" meta key:
These are then used in the corresponding ESA Rule "Runs Powershell Decoding Base64 String" contained in the OOTB Endpoint Risk Scoring Rule Bundle (I've attached all of the OOTB ESA Rules contained in the bundle to this blog).
****Take note that the app_rule_meta_value is case sensitive. If you use capital letters in the App Rule Name field, then the "value" field in its companion ESA Rule must also contain capital letters****
Last up in the process is the Risk Scoring Rule. This takes the ESA Alert and produces a score (scaled from 0 - 100) for the host where the alert occurred, and if applicable the module involved in the alert. This last part is where I expect the most potential confusion - determining the host where an alert occurred is straightforward, but the module might not be.
This is because there can potentially be both a source module (filename_src, checksum_src) and a destination module (filename_dst, checksum_dst), or just the module itself without a source or destination (filename, checksum), or for some alerts there might not be a module involved in the alert at all. I've attached all of the OOTB Risk Scoring Rules to this blog, and I'd encourage you to take a look at these variations if you intend to create your own, or tune existing, rules and alerts.
Now then, back to the "Runs Powershell Decoding Base64 String" Rule. This Risk Scoring Rule looks for the ESA Alert and creates a score for the source module (checksum_src, filename_src) in the event, as well as the host where it occurred. Any risk scores that are generated for affected hosts and modules will appear in the Investigate/Hosts and Investigate/Files pages in the UI, and can also appear as Alerts and Incidents in the Respond UI.
And just to be thorough, here are a couple examples of rules with different Risk Scoring.
A rule without a source or destination module --> "Scripting Addition In Process"
A rule without any module and just the Host --> "Windows Firewall Disabled"
Now we have some examples under our belt, and know how the different inputs and options relate to one another and the outcome. The process for adding your own rule is covered in the configuration guide linked above, and this next section aims to assist with some of the manual CLI aspects of that process.
After playing around with the Blocking capabilities in 11.3, I decided I wanted to add a couple custom alerts.
First, I wanted to know when a module I blocked was actively running on an endpoint at the time I blocked it and was subsequently killed. My App Rule to trigger on this activity:
And second, I wanted to know when an attempt was made to access or run a module that I had previously blocked. My App Rule for this activity:
With these App Rules created and Applied, the next steps are to create and apply the corresponding ESA Alert and Risk Scoring Rules from a terminal session in the Admin Server (Node0). The script "endpointCustomRule.sh" attached to this blog can help walk you through these steps, if you choose. It aims to eliminate errors that may occur when completing these steps manually.
Some notes on the script:
- must be run on the Admin Server as root
- must be run only after creating and applying your App Rule(s)
- be sure to make your App Rules unique, otherwise the script might not find the correct one when it is checking for a valid Log Decoder App Rule
- if you have multiple Endpoint Log Hybrids (ELHs), be sure to Push your App Rule(s) to the other ELHs in your environment
- applies some error checking and input validation to ensure valid Rules are created and added to the respective databases successfully
If you find errors or gaps in the script please let me know.
Prompting user for input:
Adding and confirming the ESA and Risk Scoring Rules:
And finally, confirming that we are now successfully creating alerts and re-calculating Risk Scores when the events occur:
