And I’m talking real smoking guns, not crappy anomaly alerts.
From my experience, the most effective use cases for threat detection are those which simply:
- Provide a list of detections which have a high confidence of threat
- Look for validations which follow the detection.
So:
Here’s an example for logic that would provide good use cases involving malicious intent:
- First create a list of detections that provide very high confidence of a threat.
- This is easier than you think if you’ve been using a SIEM for some time.
- Just look back at both rules that have fired and those which have not.
- The ‘have not fired’ rules like ‘Hafnium detected’ are likely very fined rules so when they do alert it’s likely for good reason.
- The rules that have fired, are consistently a true positive, and identify as a threat, is likely a very short list.
- Follow that with evidence from 1 or more additional alerts to ‘validate’ the first alert.
The ‘direction’ of the action might also be important, eg:
Inbound > outbound detection with validation of sustained activity.
Here’s a couple of specific examples:
- Detection: EDR callback
- Relevant entities: src_ip and dest_ip
- Validation1: EDR detection fires a 2nd distinct threat alert at src_ip
- Validation2:Firewall traffic continues for 15 min to dest_ip
- Email Malware ‘onclick=true’ (user clicked on a malicious link)
- Then followed by logic from rule #1 above.
Additional thoughts:
Validations do not have to be part of the SIEM threat detection. They can be added from SOAR playbook(s) and apply ‘tags’ to the alert, which can in turn be used by other correlations or SOAR playbooks. Eg. tag: EDR_distinct_threats=2, callback_distinct_count=2
This means the correlations become VERY simple and the validation or ‘recorrelations’ steps are done by the SOAR action.
By using SOAR you can provide full automation of an action by isolating a machine, disabling a user etc.
There should be pressure put on vendors to provide a ‘metric of confidence’ on specific detections. i.e. does ‘High’ really mean High? This makes it easier to create use cases with clear malicious intent since you wouldn’t have to manually compile a list of high confidence detections.
Some thoughts on high confidence alerts:
- Most Sentinel analytic rules with a value of High are high confidence.
- Deception related alerts – this is a new term for many, but it’s catching on.
- Callbacks – Fireeye first made these famous and they’re still a good example of a reliable alert.
2 thoughts on “SIEM Use Case Guide – Part 2”