This is the first post in a series on SecOps Alert Enrichment.
The premise of this series is that, although many SecOps teams have implemented basic alert enrichment, I submit that there are a lot of other niche, high-value enrichment use cases that teams out there may have not considered yet.
I am not saying any of these ideas are novel, but if you look at any blog post or canned SOAR playbooks related to alert enrichment, there is a very good chance it is just another re-hashed example of looking up an IP or a hash from an alert in VirusTotal.
Example
This is an example of an enriched alert where the enriched data is prepended to the alert using the AbuseIPDB/VirusTotal example:
=== START - ALERT ENRICHMENT v1.23 ===
AbuseIPDB IP Lookup
- - - - - - - - - - - - - - - - - - -
IP: 1.2.3.4
Abuse Confidence Score: 0
Total Reports: 0
VirusTotal IP Lookup
- - - - - - - - - - - - - - - - - - -
IP: 1.2.3.4
ASN: America Online
Country: US
VirusTotal Reputation: 0
Combined Malicious/Suspicious Score: 0
=== END - ALERT ENRICHMENT ===
[...original alert data...]And now... onto the main content of this post!
Recent Related Alerts Enrichment
The idea behind this enrichment is that you take various IOCs from the alert (IPs, hashes, usernames, etc.) and then make an API call to your alert platform to return the last 5 alerts where those IOCs were mentioned.
This can help answer the following questions:
- Have we seen this indicator before and why?
- When was the last time we saw this indicator?
- What did the last person who triaged an alert with this indicator say about it?
Atlassian OpsGenie is one platform that is capable of providing this data back via API. You can make a GET request to the OpsGenie Alerts API with these parameters:
{
"limit": "5",
"query": "description: \"1.2.3.4\" NOT alertId: [current alert ID]"
}If 1.2.3.4 is found within the body of any alert (except the current alert), OpsGenie will return the last 5 alerts where this is the case.
There are a number of different IOCs you can try to search for related alerts for:
- a username
- a public IP
- a private IP
- a SHA256 hash
- other types of hashes
- instance names
- serial numbers
- AWS account names
- and more!
When the alert is enriched with this information, it may look something like this:
=== START - ALERT ENRICHMENT v1.23 ===
Recent related alerts for SHA256 hashes
- - - - - - - - - - - -
b4e9653300309bf2218e5f6e4061c16c8569751fc90444f95f35409c18052cf1
- - -
#54321: Execution:Runtime/NewBinaryExecuted (1 month ago)
=== END - ALERT ENRICHMENT ===
[...original alert data...]Scenario
Let's say that we received the GuardDuty alert Execution:Runtime/NewBinaryExecuted, and it is enriched with the alert enrichment shown above.
Looking at the alert enrichment we can see that the SHA256 hash found in our current Execution:Runtime/NewBinaryExecuted alert exists in another Execution:Runtime/NewBinaryExecuted alert from a month ago.
We can quickly pop into the old alert using the link in the enrichment and see from the analyst's notes that the binary was completely harmless. Additionally, we have verbal confirmation from the person who executed it that it was benign and what activity it was related to.
Instead of having very little context on what the binary was, and waiting around for a response from someone for 30-45 minutes, we have an immediate thread to pull on that leads us to the answer that lets us close the alert in a matter of seconds.
Summary
This is a great enrichment to add to your alerts because it harnesses the information of your past investigations. Every time you add notes to an alert on what happened and why, this enrichment becomes even more useful since it can potentially use that information in the future.
Stay tuned for more parts in this series!
Discussion