As we saw in our last post, Threat Intelligence is a huge focus. But what good does intelligence do if we never act on it? If your organization is leveraging a SIEM or XDR, or using tools that allow for custom detection content to be added, then you use detection and analytics. ATT&CK includes data on detection and mitigation techniques, which presents you with sound guidance on where to start detecting each technique’s use in your environments. These underappreciated features of the ATT&CK database are fantastic in guiding all manner of blue team operators, and they provide a jump start to achieving greater security. Detection (or what they now call Data sources) and Mitigations give us homework. Before we can act, we must see – so let’s see how ATT&CK can help with Detection.
The figure below shows an example of these potential detection or data sources for T1111: Multifactor Authentication Interception.
Most organizations see detection value directly in their purchased and implemented tools. EDRs, NDRs, email security, and proxies/firewalls offer significant detection value. Even so, an abundance of data may go unused. Operating system logs provide rich insights into activities, and it is essential that mature organizations collect those logs. These may be Windows Event Logs or Syslog or its alternatives for Linux and infrastructure systems. But where does detection actually occur? Where de we apply analytics?
Are you a fan of The CARs?
Some projects related to ATT&CK go even further to help inform your team’s detection strategy. MITRE created the Cyber Analytics Repository (CAR) as a freely available collection of detection queries for several SIEM tools (e.g. Splunk, EQL), Sigma templates, and pseudo code. CAR helps rapidly bring detections to your security stack. Some analytics approaches for tools like Zeek may even require building with source code. Libraries (e.g. the Bro/Zeek ATT&CK-based Analytics Repository) that closely tie in with CAR provide analytics scripts or ‘recipes’. Import them into the tool to provide these detections.
Analytics stored in CAR contain the following information:
- A hypothesis explaining how the analytic was derived using a data model showing how the observables are addressed
- Where the analytic is designed to operate (host, network user, process, etc.)
- A cross-reference to the ATT&CK Techniques and Tactics that trigger the detection.
- Pseudocode descriptions and possibly sample queries help jumpstart use of the analytic
- Where applicable, CAR provides a unit test to fire a detection and ensure the analytic is operational
Where do we go from here?
Given this boost, your team may decide to leverage a different repository or library of detection analytics than CAR. You may even create or curate your own collection. Either way, ATT&CK can provide an exhaustive way to organize and exchange information. This guides detection engineering efforts and refine analytics tools. CAR can even offer a template for how to use ATT&CK efficiently in your own repository. Maybe we’ll take a deeper look at these in an upcoming post, but I want to tackle our next use case, Adversary Emulation and Red Teaming next 😉