NewsMITRE ATT&CK

    What Comes After Detection Rules? Smarter Detection Strategies in ATT&CK

    By Lex Crumpton Updated: October 22, 2025 Key updates: - Website example images added - No more Log Source SDO → log sources now live as a x_mitre_log_sources field on the Data Components SDO. - No more <detects> SRO between Data Components and Techniques → Techniques now map to Detection Strategy SDOs. Defenders have often used the information in ATT&CK Detections to help build useful analytics. But as detection engineering has matured, the current format hasn’t always scaled well. The text in ATT&CK’s Detections often packed too many behaviors into a single block of text, making them hard to interpret or apply. Important platform differences were sometimes lost, and mapping from an adversary behavior to log telemetry, especially in complex environments, was more art than science. Prepare to scale your mappings. We’re rolling out a significant adjustment to the ATT&CK STIX format and ATT&CK Workbench in the v18 release, with the introduction of two brand new STIX Domain Objects (SDOs) and a structured relationship model. This 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. Why Change at All? 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. 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. Image: T1027 Obfuscated Files or Information v10 We later moved to what’s currently in ATT&CK, with detection logic structured into detects relationships between data components and techniques. This helped highlight the connection between telemetry and detecting specific techniques, but the relationships typically lived in unstructured description fields that lacked visibility and can’t be versioned on their own. This has led to a key challenge as ATT&CK has matured: some of our most valuable detection insights are being buried. Image: T1027 Obfuscated Files or Information v17 The x_mitre_detection_strategy 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. 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. 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. 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. It doesn’t tell you exactly how to write a SIEM rule tailored to your environment, but they give you: · What behavior to observe · What log data you need · What parameters are tunable · What parts are fixed and ATT&CK technique-defining Table 1: New ATT&CK STIX Objects Key Detection Architecture Changes The detection strategies model introduces three major changes: 1. Detection Strategies Link to Techniques Each x_mitre_detection_strategy object corresponds to one ATT&CK technique or sub-technique and defines what adversary behavior it’s intended to detect. It does not contain all the detection logic itself, instead, it references one or more Analytics that describe how to detect the behavior in different environments. 2. Analytics Are Platform-Specific and Actionable Previously, detection notes tried to explain Linux and Windows behavior in a single field. Now, each Analytic is platform-specific, with direct references to required Log Sources, Data Components, and tunable detection thresholds. That means one Detection Strategy for T1048.001: Exfiltration Over Symmetric Encrypted Protocol might include: · AN-2301 : Detect encrypted file transfer over SFTP on Linux · AN-2302 : Detect non-C2 TLS exfiltration from PowerShell on Windows 3. Data Components are Explicit and Reusable Instead of saying “use Sysmon,” ATT&CK will now tie Data Components to Log Source name and description that contain Data Component specific permutations: Table 2: Data Component Example Image: File Creation Data Component Permutation Example These log sources are then tied to Data Components through formal STIX relationships, creating a clear chain from behavior to telemetry. Each new STIX object plays a precise role: Table 3: New ATT&CK STIX Fields These fields allow ATT&CK to define multi-event, platform-specific detection logic that is abstract enough to be reused and specific enough to be actionable. Here’s how the new detection strategy model works in practice, moving from high-level strategy to low-level detection components: 1. Each detection strategy includes three key elements: a Detection Strategy ID, a Detection Strategy Name, and one or more associated Analytic IDs. Table 4: Detection Strategy Elements Image: T1560.002 Technique Example of Detection Strategies Image: Detection Strategy DET0119 Example 2. Each analytic includes five key elements: its ID, Platform, Detection Statement, Log Source, and Mutable Elements, capturing platform-specific logic, relevant telemetry, and tuning options. Table 5: Analytic Elements 3. At the next level, each Data Component will have a list of Log Source permutations that defines a Log Source Name and Channel . Mutable Elements outline fields and descriptions that help you tune the detection logic to fit your environment. At its core, a Log Source Name is broken down into two parts: PRE represents where the telemetry originates. This includes the platform , environment , or context of collection — for example, Windows, Linux, macOS, cloud environments, or containers. POST represents what specific data stream or feed is being collected from that source, such as the channel , component , or feed within that platform. Together, the PRE and POST form a structured name such as: wineventlog:security — Windows Event Log Security Channel auditd:SYSCALL — Linux auditd system call events macOS:unifiedlog — macOS unified logging stream Each log source also defines a Channel , which identifies how to interpret or filter the telemetry. This includes: Event IDs — numerical identifiers such as 4624, 4625, or 4688 for specific Windows events. Operations — API-level actions, such as execve or CreateProcess. Match strings — descriptive identifiers or patterns found within telemetry, such as a “new HID device enumeration with type keyboard.” When combined, these fields (EVENT, OPS, MATCH) define the detection context that analysts and tools can use to correlate behaviors across systems. In short, the PRE:POST naming convention ensures that each log source is both platform-aware and data component–specific , while the Channel and Event/Operation/Match fields enable flexible, detailed mapping of behavioral evidence across diverse telemetry sources. Table 6: Data Component and Mutable Elements Image: Detection Strategy DET0119 Analytics Each analytic includes tunable thresholds, suspicious tool lists, or time windows to tailor detection logic without changing core behaviors. Example: T1027: Obfuscated Files or Information Table 7: T1027 Obfuscated Files or Information Example Detection Strategies Use Case Let’s say your team wants to detect T1053.002: Scheduled Task/Job: At execution on Windows, Linux, and macOS: 1. Retrieve DET-0084 , which links to: · AN-3121 for Windows ( EventID 4698 + file write to %SystemRoot%\Tasks ) · AN-3122 for Linux ( cron log + /var/spool/cron/ file write) · AN-3123 for macOS ( launchd with file drop in ~/Library/LaunchAgents ) 2. Confirm that relevant Data Components ( DC-0033 , DC-0037 , DC-0039 ) are collected in. 3. Adapt thresholds, as needed: · Extends TimeWindow to 30 mins · Flags execution outside of working hours ( UserContext: !System ) 4. Test the detections using an adversary emulation tool or ATT&CK Workbench scenario runner. What You’re Probably Also Wondering: How Will This Affect Me? We know change can be disruptive, but 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. Will this break my existing ATT&CK integrations? If you rely on x_mitre_detection , descriptions with a relationship_type:”detects” , or x_mitre_data_sources , yes. Are data sources going away? Not fully. They will be there in older versions of ATT&CK, but after October 2025 we will be moving to Log Sources instead. What if I don’t have the log sources listed? That’s okay. Each detection strategy includes tunable fields and platform-specific options so you can adapt the logic to what you do have. How does this impact ATT&CK Workbench? Workbench will support authoring and visualizing x_mitre_detection_strategy objects out of the box. You’ll be able to map detection strategy coverage across tactics, platforms, and data collection. When do I get sample STIX to test against? Please visit our Github for the STIX example to test against. These will align with the same version of Workbench. Where/when can I see the full schema? Please visit our Github for the STIX Schemas ( Detection Strategy , Analytics , and Data Component ). For instructions on how to install our TypeScript parser library please visit the Attack Data Model . For insight into our compatibility document , please visit our Github. Final Thoughts We’ve learned a lot from how the community, and our own teams, approach detection, and this update reflects that learning. 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. The new model is a work in progress, and 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. How You Can Contribute This isn’t a closed-door update, we want your input! Whether you’re spotting gaps, have great ideas, or just curious how others are thinking through this update, your perspective helps shape where we go next. We’d be happy to hear from you at attack@mitre.org, in our Slack , or stop by ATT&CKing Mondays there for help, demos, or migration guidance. © 2025 The MITRE Corporation. ALL RIGHTS RESERVED. Approved for public release. Distribution unlimited. 25–01296–1. What Comes After Detection Rules? Smarter Detection Strategies in ATT&CK was originally published in MITRE ATT&CK® on Medium, where people are continuing the conversation by highlighting and responding to this story.

    More on Strategies

    Other advisories

    Other news entries

    Source: https://medium.com/mitre-attack/smarter-detection-strategies-in-attack-7e6738fec31f?source=rss----6da19bd08fba---4

    ID