I’ve been a long time reader but this is the first time I’ve sent in a question. I keep hearing from our SOC manager that her analysts need to contextualize their notable events to MITRE ATT&CK tactics and techniques. She also told me that leadership wants to see their reporting with ATT&CK referenced as well so now I am freaking out because this has high-level visibility. I’ve read the blogs about customizing Incident Review in Splunk Enterprise Security. I understand how that works well enough, but how can I bridge the gap?
With Great Concern,
Sheila in the SOC
It’s great to hear from you and thank you for being a loyal reader of this series, we appreciate both of you! You are correct, we have talked a few times about customizing the Incident Review page, first with additional fields being added to a correlation search and more recently in the context of Asset & Identity attributes. The good news is that if you understand this concept, contextualizing notable events with MITRE ATT&CK is very straightforward.
MITRE ATT&CK, what difference does it make? Contrary to what a certain singer from Manchester says, it makes a great deal. ATT&CK is a taxonomy of tactics and techniques built upon open-source threat intelligence reporting. Its primary focus is nation-state adversary activity but additional threat actors are continually being added and the taxonomy is continually being broadened. While it is not a perfect model (as there really is no such thing!) it serves as an excellent way to contextualize techniques and tactics and map them to adversaries in your own data! For additional information on MITRE ATT&CK, you can check out the blog post, "ATT&CK-ing the Adversary: Episode 1 - A New Hope," as well as MITRE’s site.
While ATT&CK was initially focused on threat intelligence analysts as their primary consumer, like other happy accidents, it turns out that many other security folks can also be consumers of ATT&CK. Threat hunters and security operations analysts have found the ATT&CK framework helpful to contextualize activities they were observing and using a standard taxonomy across different groups allows the broader security team to communicate with ATT&CK as the lingua franca.
Okay, Buttercup – we know that this is a good thing, but how can we make this happen?
We could take endpoint logging that has been tagged with ATT&CK tactics and techniques and incorporate these mappings directly into ES and report on them. With the release of Sysmon 8.0, Olaf Hartong created a Sysmon configuration he hosts on GitHub that maps process creations of various binaries to ATT&CK techniques and this is very helpful when observing specific binaries running and understanding which techniques they map to. However, it is important to note that just because a technique is referenced, it doesn’t mean it is malicious. The mapping at the endpoint can be useful for isolating data belonging to a specific technique but just the fact that a tag exists doesn’t make it malicious. Further, this is only focused on endpoint data. While endpoint data is important, there are tactics and techniques in ATT&CK that benefit from network data so visibility across all datasets is important to contextualize techniques.
Another approach is to use the SIEM and correlation searches to map detections to a specific technique. This gives your organization the ability to use both network and endpoint events and map specific analytics to techniques as you define them or you could even extend ATT&CK beyond the defined matrix. ATT&CK is great but it does rely on open source intelligence so attacks that are not public are not identified in the matrix. Therefore, certain techniques that non-public attacks used may not exist today.
Another challenge is that because ATT&CK is qualitative, you and I could both look at the same attack and we might identify the same attack as different techniques. We all have our own biases so we see things a little bit differently, and that’s fine, but by mapping these techniques at an organizational level, your team will be working off the same sheet of music, so to speak.
There are different ways to associate analytics with ATT&CK techniques but for simplicity’s sake, we will do this by using the eval and lookup commands along with a lookup called mitreattack to demonstrate this.
Here is a correlation search with MITRE ATT&CK mapped to it and its results:
sourcetype=XmlWinEventLog:Microsoft-Windows-Sysmon/Operational process_name=net.exe (localgroup OR /add OR user) | search cmdline=*localgroup* OR cmdline=*/add* OR cmdline=*user* | stats count values(cmdline) as cmdlines, min(_time) as firstTime, max(_time) as lastTime by dest, user, parent_process | `ctime(firstTime)` | `ctime(lastTime)` | eval techID="T1136" | lookup mitreattack ID as techID OUTPUT Tactic Technique Description | table firstTime lastTime count dest user cmdlines Tactic Technique Description
The first part of the analytic can be an SPL structured or unstructured search or it could be a tstats search using accelerated data models. But when we get to the section in bold above, this is where MITRE ATT&CK mapping comes into play. The eval command is used to define the technique associated with the analytic by using the MITRE ATT&CK identifier, in this case T1136, and then we can use the lookup command to get the tactic, technique, and description from the mitreattack reference table that I loaded onto my system. There are additional values from ATT&CK that could be added as well but you get the idea. Finally, using the table command, we specify the fields that we want written to the notable index since we are creating a notable event with this correlation search.
Once these values are in the notable event, they will be available for viewing in Incident Review, provided the fields are listed in the Incident Review Settings. This was discussed in the earlier blog assets and identities, but here is what my config looks like for ATT&CK.
With the fields Description, Technique, and Tactic added, when I can expand my notable event, I can see the additional context in my notable.
Sheila, this should address your analysts’ needs when it comes to contextualizing their analytics in Splunk Enterprise Security. In regard to your management, the good news is that you have already done the heavy lifting of associating the analytics to the tactics and techniques, so now we can build dashboards and reporting to provide them visibility into the specific tactics and techniques that your organization is seeing.
This reporting can be useful in a few different ways. It isn’t realistic to expect full coverage of ATT&CK, but it does allow us to see which techniques we are most frequently seeing. We can also use this to prioritize our focus on where we should be developing additional analytics to address potential blind spots. For example, if you find yourself being a victim of PowerShell attacks, spending some time developing analytics to detect malicious or at least anomalous PowerShell might be a good step forward.
Well, Sheila, I hope you have a better understanding of how ATT&CK can be used by the SOC and its management to better understand the tactics and techniques of the adversaries they are seeing. With what I just shared you will be mapping your correlation searches in ES to MITRE ATT&CK in no time. For that, Shelia, take a bow.