Don’t Hold Back, Insights Unpacked From Your Data Stack With MITRE ATT&CK
Getting started with the MITRE ATT&CK Framework can seem a little intimidating at first, especially when implementing it in an existing enterprise with established IT/Security systems and processes.
I’m going to walk you through why and how you should be looking to ATT&CK to help you articulate detection and response with a well-documented, evolving taxonomy. I’ll also be providing some tips and tricks specifically relating to data sources, how they align with the ATT&CK Framework and how you can best ensure that you aren’t missing out on maximum security visibility.
What is MITRE ATT&CK and why should I be interested?
ATT&CK is an acronym for “Adversarial Tactics, Techniques & Common Knowledge”, it was first introduced by MITRE in 2013 as a methodology for describing and categorising adversarial behaviours within an enterprise network based on actual real-world, “seen in the wild” observations.
From my perspective, I have found it invaluable - an open, constantly growing framework that provides a common set of definitions and language to describe attacker actions that can sometimes be obscured by differing, muddled terms or descriptions.
MITRE ATT&CK is broken down into techniques that are arranged into categories by tactic. These tactics, in turn, align with the later stages of the Lockheed Martin Cyber Kill Chain®. Tactics and techniques then lead to procedures, or how attackers have been known to execute a given technique. In this way ATT&CK provides coverage for the lofty peak of the “Pyramid of Pain”.
At present, there is Pre-ATT&CK, for reconnaissance and staging, and then the main Enterprise ATT&CK for the later phases, though Pre-ATT&CK is going to be folded into the main enterprise matrix this year. Techniques themselves are going to be broken down further into sub-techniques to provide greater granularity as some techniques, like “scripting” for instance, are currently overly broad in scope.
Show me the data!
Now that we understand what ATT&CK is in a general sense and how it can help us to evaluate attacker behaviours, we’re going to take a look at how it can be used to assist in evaluating the security posture of an existing network.
For each technique definition within ATT&CK, there is a sidebar as pictured below. For the purposes of this piece, we are looking at the section marked “Data Sources”, these being the types of logs that can be used to detect activity associated with a given technique. In this case, we are looking for indicators that could show the presence of a web shell on an enterprise network.
Looking above we have anti-virus logs (to potentially detect the web shell files themselves), authentication logs (some web shells, for instance, including admin portal brute-forcing functionality which can be detected), file monitoring (for the addition of suspicious files in high-risk web-accessible directories), Netflow logs (to monitor for web shells through the analysis of network traffic) or process monitoring (looking for suspicious processes spawned on exploited web servers). Are you currently examining these logs from hosts on your network?
Roberto Rodriguez has a list of the various ATT&CK datasource categories and some information defining each one from ATT&CKcon 2018, well worth checking out if you want to learn a little more about how MITRE defines them.
What we can extrapolate from the data sources listed above is not an exact science, you could find ways to detect web shells with a single one of the sources listed or by combining and correlating data from across multiple sources. The key takeaway though is that it would be difficult to detect this particular technique without any of the types of data listed. We can then start to use this same logic across all techniques and tactics within the framework.
Not all datasources are created equal though, some have way more technique detections associated with them, so you also have to ask yourself are you collecting the right data to effectively respond to threats on your network? If you take the time to see which datasources are associated with which techniques then you can start to see datasources you could begin to prioritise, for instance currently Process Monitoring is one of the most prevalent when mapped to ATT&CK techniques observable.
Simply deciding which logs to onboard is not the only consideration when thinking about your data though: there has also been some great work around scoring the data sources themselves based upon metrics such as completeness, timeliness and availability by Olaf Hartong, among others. You can find Olaf discussing this work here. This kind of datasource grading adds a valuable set of metrics to consider, after all, if your logs are incomplete or hard to access then you are only ever seeing part of the full picture.
Bringing this all together
When you look at a framework for defining adversarial behaviours like ATT&CK it is important to consider the projects that have developed alongside it and the added value that these other connected projects can bring. It is also a good indication of the efficacy of the model if industry professionals are interested in contributing work to enhance it.
There are several really useful open source projects that build off of ATT&CK’s model, one that does an especially good job of showing data source coverage and visibility is DeTT&CT (Detect Tactics, Techniques & Combat Threats).
DeTT&CT gives you the ability to score your datasources and map your current coverage, as well as using your available datasources to highlight gaps that could be filled with currently available data or show the need for ingestion of further data sources. All of this can be presented using heatmaps in ATT&CK Navigator which can also provide an extra, useful visual aid for presentations, report writing or to show an increase or decrease in technique coverage over time.
In conclusion
Diving into any one aspect of ATT&CK can provide inspiration for further research or development. Even when it comes to something like data sources it should be clear that there is still a lot of ground that can be covered. We could delve further into endpoint vs network coverage, break down datasources by OS or prioritise techniques (and therefore the ingestion of datasources to observe those techniques) to detect for based on threat intelligence, the rabbit hole goes deep!
If you found this article interesting but are still feeling a little overwhelmed then why not consider contacting Adarma for a consultation? As one of the largest independent security services companies in the UK, we bring with us our extensive in-house knowledge and substantial experience. In the field of blue teaming, we can assist companies big and small in analysing and implementing improvements to their existing cybersecurity posture.
