Red Canary ATT&CKs (Part 3): Mapping Our Detectors to ATT&CK Techniques

As discussed in Part 1 of this series, we decided that using the MITRE ATT&CK framework would give us a common language to describe adversary tactics and techniques. This would help us to effectively share information amongst our internal teams, our customers, and the community at large. In this post, we will walk through the process of mapping our 800+ behavioral detectors to the MITRE ATT&CK framework and share key lessons we learned along the way.

But first, some background information…

Before we dive into our discoveries from mapping detectors to ATT&CK, it will be helpful to understand how Red Canary receives and processes the data that we use to provide customers with visibility and threat detection.

The general process Red Canary follows is:

• Endpoint telemetry is collected using third-party products and converted into a standardized format.
• Standardized data flows into our threat detection engine, where it is inspected by a number of subsystems aimed at identifying potentially threatening activity. The bulk of the work takes place within our behavioral detection system, which is built around our Detectors. Detectors use a domain specific language to describe patterns of behavior that might be associated with threatening activity.
• Detector matches result in “tipoffs” that are subjected to additional logic and sent to the Red Canary Security Operations Center for investigation.
• Confirmed threats are published as Detections and sent to our customers via any number of integrations or notification mechanisms.

For the purposes of this discussion, we’re going to focus on Detectors.

What’s a Detector?

Detectors can range from being relatively simple to very complex. Here’s a simple Detector that looks for the Microsoft C# Compiler making a network connection.

Because we know from observation and work on behalf of our applied research team that csc.exe rarely makes legitimate network connections, we want our engine to raise these events to detection engineers.

The Great Detector Review of 2017

Armed with our evaluation criteria and chosen framework, we began the process of reviewing all Detectors and mapping them to the ATT&CK framework. The mapping process is straightforward, but we’ll walk through one Detector for illustrative purposes. The following Detector identifies misuse of regsvr32.exe, a well-known Windows utility that is used to bypass application whitelisting controls.

This Detector is assigned to technique T1117. Cross-referencing this with the ATT&CK matrix, it maps to both the Defense Evasion and Execution tactics.

Once we had all 800+ detectors mapped to ATT&CK, we were able to clearly understand our gaps and identify where we should focus priorities for detection research. When we identify a coverage gap, we assess the technique and determine whether coverage may be achieved by answering the following questions:

• Do the data sources we have allow for detection?
• Does it make sense to create a Detector for the technique? Some techniques map to activity that may only be malicious if observed alongside other suspicious behaviors, or when associated with specific user accounts.
• If a Detector is not appropriate, what other mechanism(s) can we use to make the data available to customers?

Prioritization is a function of coverage, prevalence, and the impact associated with a given technique. The latter two are dependent on access to data and intelligence, whereas the former is helped greatly by ATT&CK, as we can opt to defer adding depth to a technique that we already cover in favor of creating new coverage for a technique that we’re missing.

Building on the Framework: What Lies Ahead?

Now that we finished our initial mapping, we’re looking forward to evolving the concept in a few specific ways:

• Working with the ATT&CK team to create new techniques or expand upon existing techniques to add the various classes of behavior we detect that aren’t reflected in the matrix today.
• Taking advantage of the many improvements that the MITRE team has planned for 2018 and beyond.
• Identifying how best to share even more data and intelligence with customers and the community. Being able to use this shared language to discuss the details of an attack without having to reveal potentially sensitive indicators should result in a significant increase in sharing and collaboration.

We hope that walking through our mapping process helps other security teams  to leverage ATT&CK (or any model) as a way to identify strengths and weaknesses in detection and response capabilities. To receive new articles and techniques from our security team, subscribe to our blog using the form below.