In practice, threat detection is not a binary – it is a process. An organization’s coverage depends on where they are within that process. By measuring that process across the Tactics, Techniques and Procedures (TTPs) of the MITRE ATT&CK framework you can paint a realistic picture of your detection landscape.
Detection is generally carried out in the following consecutive steps: Logging, Detection, Alerting, and Response. Each step in the pipeline is a piece of metadata that should be tracked alongside procedures to paint our landscape. This data tells us where we do or do not have visibility and where our technology, people, and processes (TPPs) fail or are incomplete.
|Logging||Generally, logs must be collected and aggregated to identify malicious activity. This is not only important from a forensic perspective, but also for creating, validating, and updating baselines.|
|Detection||Detection can then be derived from the log aggregations. Detections are typically separated by fidelity levels, which then feed alerts.|
|Alerting||Alerts are any event, detection, or correlation that requires triage and may warrant a more in-depth response action. Events at this level can still be somewhat voluminous but are typically deemed impactful enough to require some human triage and response.|
|Response||Response is where technology is handed off to people and processes. Triage, investigation, escalation, and eviction of the adversary occur within a response. Response is usually executed by a security operations or incident response team. The response actions vary depending on the internal playbooks of the company.|
|Prevention||This sits somewhat outside the threat detection pipeline. Activities can, and often are, prevented without further alerting or response. Prevention may occur without events being logged. Ideally, preventions should be logged to feed into the detection and alert steps of the pipeline.|
By assembling these individual data points for several procedures, we can confidently approximate a coverage level for an individual technique. We can also identify commonalities and create categories of detection to cover as much or as many of the base conditions as our visibility allows.
Once many techniques are aggregated in this way, you can begin to confidently understand your threat detection landscape with all the nuance observed at the tactical level. A great man (Robert M. Lee) once said “We derive much value by putting data into buckets,” and it is no different here.
By looking at what data sources provide logging, detection, and prevention we can get a true sense of detective control efficacy. By looking at coverage over the different phases of the kill chain, we can start to prioritize choke points, detective efforts, emulation, deception, and research. By cataloging areas where prevention or detection are not carried forward to the alerting or response phases, we can better evaluate gaps, more accurately evaluate security products, and more efficiently spend budget or hours fixing those gaps with breach and attack simulation or similar tests.
The data derived here is also useful in countless other ways. Purple and red teams can plan more effective tests or focus on known or suspected gaps. Threat intelligence teams can focus collection efforts on problematic TTPs. SOC analysts gain better situational awareness and have documentation to validate assumptions against. CISOs have confidence in their detection coverage and investments and can plan for product/resource changes more effectively.
The pipeline that turns an activity on a system into an event that is responded to by the security team can be long and complicated. Knowledge of your coverage is your map of the battlefield and influences your decisions and directives and thus the activity that occurs at the strategic, operational, and tactical level.
If you are relying on vendor coverage without further extension or customization, then you are susceptible to anyone who can defeat that vendor’s security product. By having a map, performing analysis, and designing behavior-based threat detections you are creating a delta that will ensure you’re not the slowest man running from the bear.
Looking for a more in-depth analysis of MITRE ATT&CK Evaluations and how to improve your detective controls? Read my detailed analysis on the NetSPI technical blog.Ready to get started? Collaborate with NetSPI’s Breach and Attack Simulation experts.