Utilizing Conditional Logic to Differentiate between High Fidelity Alarms & Low Fidelity Alerts
Overview
For anyone who has created or written SIEM alerts/alarms you’re all to familiar with the balancing act between developing signatures that a Security Operations Center (SOC) analyst can investigate or will find useful to start an investigation. A long time ago there was a time, right after taking SANS 508, that I was so excited to go back to work to start writing detection logic that looked at rouge windows processes based on the “Find Evil — Know Normal” poster only to be smacked in the face with a cold dose of reality when I started developing content and realized my corporate environment wasn’t all pretty and neat as a SANS poster would make it seem.
The issue wasn’t the fact that the logic was incorrect — some of it was pretty rudimentary; stuff like, svchost.exe should only have services.exe as its parent — the issue was the volume of alerts was unmanageable by our SOC and not to mention…just a small, often times obscure, indicator that something bad might be happening. So, to solve that type of issue, we decided to break down our detection logic into two types: High Fidelity (HF), and Low Fidelity (LF).
In a sea of weeds…
The key difference between the two types of signatures was HF sigs are sigs which detect malicious behavior more than 50% of the time OR are so bad that the alarm requires a SOC analyst to determine whether its a false positive (FP) or not. HF would be things like Mimikatz detected through host detection tools (AV, HIDS, HIPS, EDR, etc.), while LF would be things like the previously mentioned svchost spawned by a process other than services.exe.
Other factors can be utilized when determining whether something should be HF/LF. You can create a threshold standard based on your own organization’s requirements or manpower, change the percentage that a signature detections actual malicious behavior to suit your risk appetite, and many other things. The point isn’t how you make that determination as it will undoubtedly change over time, rather, develop a means in detect both types so nothing is missed.
A tale of two alerts
The title of the article includes the word “conditional” aka dynamic logic. Why cant a HF alert also be LF alert or visa versa? Say we develop a HF AV alert, and in order to get it to HF we implemented an exclusion to filter out blocked events (why worry about stuff the AV took care of right). Those blocked events might not be useful by themselves, but, rather than ignore those blocked events all together, we instead told our SIEM to turn blocked events into a LF alert while allowed events bubble up to a SOC analyst as a HF alarm.
Example:
index=av sourcetype=defender priority=critical
| eval alert_type = if(match(action,”allowed”),”HF”,”LF”)
| appendpipe
[ | where match(alert_type,“LF”)
| stats values(*) as * by host,user,action
| addinfo
| collect index=low_fidelity]
| where match(alert_type,“HF”)
| stats values(*) as * by host,user,action
The above example is pretty simple but it demonstrates what I’m talking about. Basically, we’re assigning a dynamic value to the alert_type field depending on the action field value (if not allowed then LF). Then we’re using the Splunk appendpipe command to send (via the collect command) the events to a different index. This would be the correlation search within Splunk Enterprise Security with the adaptive response action as notable which would mean that when the alert_type field value equals “HF” a notable (alarm) would be displayed to a SOC analyst. This type of “conditional” detection logic can be applied in a variety of ways. Previously, I wrote an article, Detecting Cobalt Strike by Fingerprinting Imageload Events which attempts to detect CS beacon activity by checking for specific DLLs and a few other things. The detection excludes processes from specific file paths because without those exclusions this signature would generate a high number of alerts. However, by implementing this conditional logic, I can now take that one signature (use case/correlation search) and have any events which are a result of detections within those file paths sent to the “low_fidelity” index for later.
What happens to LF?
An important consideration is what you will do with those LF alerts. Splunk Enterprise Security has a nifty (yet underwhelming) framework called the Risk Analysis Framework which, long story short, lets content developers assign risk scores to risk objects (usernames, hostnames, IP addresses, etc.). This can be utilized to basically start assigning risk scores to objects associated with your LF alerts. For example: svchost.exe spawned by a process other than services.exe could result in the username and hostname associated with that event having a risk score assigned to them. Add a few more LF alerts to the mix and all of a sudden that hostname/username might end up with a high enough score to warrant further investigation. At least, in theory ;) But this isn’t an article about how to establish and implement a risk based alerting framework. There are some good .conf slide decks that go over that and I plan on writing an in-depth article here soon!
