Non-profit organization MITRE announced Tuesday that it is preparing to release a significant update to ATT&CK Detection with its upcoming v18, expected in October this year. The update introduces a new approach to modeling how defenders detect adversary behavior across platforms, log sources, and behavioral chains. The update will transform ATT&CK detection guidance into a detection strategy-focused system, with modular, behavior-first blueprints that better address adversary behavior, platform diversity, and scalable detection.
The new version will also feature three new STIX objects and versionable detection strategy blueprints, including Detection Strategies that map ATT&CK techniques to causal behavior chains, Analytics that are platform-specific and telemetry-aware, and Log Sources that are formalized and reusable, eliminating vague references like ‘use Sysmon.’ Each detection strategy is designed to clarify three core aspects: the specific adversary behavior being detected, where it appears in logs, and which elements can be tuned without compromising detection fidelity.
“Detection strategy has always been a core part of ATT&CK, but the way we captured that guidance didn’t always reflect how defenders, including us, work in practice,” Lex Crumpton, MITRE’s principal cybersecurity engineer, wrote in a Medium post. “Earlier versions used the x_mitre_detection STIX field within a technique to describe detection suggestions. This combined platforms, behaviors, and telemetry sources into a single paragraph, which could be challenging to automate or tailor to different environments.”
MITRE later transitioned to the current ATT&CK structure, where detection logic is expressed through relationships between data components and techniques. This approach clarified how specific telemetry supports the detection of adversary behaviors. However, these relationships have typically been embedded in unstructured description fields, reducing visibility and preventing independent versioning. As ATT&CK has evolved, this limitation has become more pressing; some of the most valuable detection insights are getting buried.
“This challenge made us take a step back to consider how to capture detection strategy in a way that actually reflects how intrusions happen, and how defenders think,” Crumpton detailed. “Most detections have also relied on isolated events: one process creation, one file write, one network connection. But adversaries don’t operate in one-liners.”
She added that modern detection strategy isn’t about one-liners, it’s a series of detections. “Real-world intrusions unfold across multiple events: a process writes a file to a temporary directory -> that file is encrypted via a known library -> the file is exfiltrated over a suspicious channel.”
“We knew we needed a better way to capture and express that kind of logic. So, we’re rebuilding the detection model around a simple principle: detection strategy isn’t a sentence, it’s a system,” according to Crumpton. “With this new system, we broke detection logic into modular STIX objects, each with its own lifecycle and version control, tailored to specific platforms, and logically connected to behaviors, telemetry, and analytics. The objects describe what behavior to look for, where to find it in logs, and how to tune the detection to your environment.”
Detection strategies now capture those multi-event, cause-and-effect behavior chains, not just tool-specific signatures. Each strategy acts as a blueprint. While not prescriptive about how to write a SIEM rule tailored to a specific environment, the guidance provides clarity on several fronts: the behavior to observe, the required log data, which parameters are tunable, and which components are fixed and define the ATT&CK technique.
The updated detection strategies model in MITRE ATT&CK introduces three key structural changes that improve clarity, specificity, and practical application across different environments.
First, each ‘x_mitre_detection_strategy’ object is now directly tied to a specific ATT&CK technique or sub-technique. Rather than embedding full detection logic, the strategy defines the adversary behavior it aims to detect and links to one or more Analytics. These Analytics offer concrete detection guidance tailored to different operating environments.
Second, Analytics are now platform-specific and designed to be immediately actionable. Previously, detection content tried to cover behaviors across Linux and Windows in a single field, which led to ambiguity. Under the new structure, each Analytic is aligned to a specific platform, with explicit references to the necessary log sources, data components, and tunable thresholds. For instance, a detection strategy for technique T1048.001 (Exfiltration Over Symmetric Encrypted Protocol) might include distinct analytics such as one for detecting encrypted file transfers over SFTP on Linux, and another for identifying non-command-and-control TLS exfiltration via PowerShell on Windows.
Third, log sources are now explicitly defined and reusable. Instead of broadly suggesting the use of tools like Sysmon, ATT&CK defines formal Log Source objects, each capturing platform-specific variations. These are then linked to Data Components through structured STIX relationships, making the chain from adversary behavior to telemetry traceable and clear.
Together, these changes allow ATT&CK to model detection strategies that support multi-event, platform-aware, and reusable detection logic. The structure strikes a balance between abstract definitions and operational specificity, helping defenders build practical, adaptable detections across diverse systems.
Recognizing that change can be disruptive, Crumpton observed that “it’s also an opportunity to clean up any overlapping detection logic, fine-tune your alerts, and better align your detections to how adversaries move through environments. If you’ve built integrations, dashboards, or automated pipelines on top of ATT&CK data, this update will affect you.”
Data sources are not being completely removed. They will remain available in older versions of ATT&CK, but starting in October this year, the framework will transition to using Log Sources instead. Also, missing log sources are not a blocker. Each detection strategy includes tunable fields and platform-specific options, allowing the logic to be adapted based on available telemetry.
ATT&CK Workbench will include native support for authoring and visualizing ‘x_mitre_detection_strategy’ objects. This will enable mapping of detection strategy coverage across tactics, platforms, and data collection sources.
A sample STIX file will be released early next month, and it will align with the corresponding Workbench version to support testing and evaluation. The full schema will also be made available that week, along with sample code, a TypeScript parser library, and updates to Workbench that support the new detection strategy format.
“We’ve learned a lot from how the community, and our own teams, approach detection, and this update reflects that learning,” according to Crumpton. “By moving from single-sentence guidance to structured, behavior-driven strategies, we’re aiming to make ATT&CK more usable, adaptable, and aligned with how adversaries actually operate.”
Highlighting that the new model is a work in progress, Crumpton said, “We know there will always be room to improve. But we think it’s another step in the right direction, and we’re excited to keep advancing it with your feedback.”
