Mapping Sentinel Rules to MITRE ATT&CK

The MITRE ATT&CK (Adversarial Tactics, Techniques, and Common Knowledge) framework is a globally accessible knowledge base of adversary tactics and techniques based on real-world observations. It is used by security operations centers (SOCs) to classify attacks, communicate threat intelligence, and assess defensive coverage. The framework is organized into a matrix with tactics (the 'why'—the goal of an attack, like Initial Access or Exfiltration) and techniques (the 'how'—the specific method, like T1078 Valid Accounts or T1041 Exfiltration Over C2 Channel). Sub-techniques provide finer granularity (e.g., T1078.001 for Default Accounts).

Mapping Sentinel analytics rules to MITRE ATT&CK means associating each rule with one or more tactics and techniques that the rule is designed to detect. This allows Sentinel to generate a unified view of your detection coverage across the kill chain. For the SC-200 exam, you must understand how to perform this mapping in the Azure portal and via KQL, and how to interpret the MITRE ATT&CK coverage dashboard.

When you create or edit an analytics rule in Sentinel, you have the option to specify MITRE ATT&CK tactics and techniques. This is stored as metadata within the rule definition. The mapping can be done at two levels:

Internally, Sentinel stores this mapping as a JSON array in the rule's properties. For example, a rule that detects a user logging in from an unusual location might be mapped to:

{
  "tactics": ["InitialAccess", "Persistence"],
  "techniques": ["T1078", "T1098"]
}

When an alert is generated by a mapped rule, the alert inherits the MITRE tags. These tags are then used by the incident creation pipeline to populate the MITRE ATT&CK fields in the incident. The coverage dashboard queries these fields to produce a heatmap showing which techniques your rules cover.

The SC-200 exam expects you to know the 14 tactics in the enterprise matrix: Reconnaissance, Resource Development, Initial Access, Execution, Persistence, Privilege Escalation, Defense Evasion, Credential Access, Discovery, Lateral Movement, Collection, Command and Control, Exfiltration, Impact. Each tactic has a unique ID (e.g., TA0001 for Initial Access).

Techniques are identified by IDs like T1078 (Valid Accounts). Sub-techniques use a decimal notation (T1078.001). The exam may ask you to identify the correct tactic or technique for a given scenario. For example, 'Spearphishing Attachment' is T1566.001 under Initial Access.

To map a rule to MITRE ATT&CK:

Note: Not all rule types support MITRE mapping. Scheduled query rules, NRT rules, and Microsoft Security rules support mapping. Anomaly rules and Fusion rules do not support manual mapping (Fusion uses built-in ML models).

You can also set MITRE tags programmatically using the Azure Resource Manager (ARM) API or via KQL in Log Analytics workspaces (though rare). For the exam, you should know that the mapping is stored as part of the rule's properties. An example ARM template snippet:

{
  "type": "Microsoft.OperationalInsights/workspaces/providers/alertRules",
  "name": "[parameters('ruleName')]",
  "properties": {
    "displayName": "My Rule",
    "query": "...",
    "tactics": ["InitialAccess", "Persistence"],
    "techniques": ["T1078", "T1098"],
    ...
  }
}

When a rule fires, the resulting alert includes the MITRE tags. When the alert is turned into an incident (if enabled), the incident's 'MITRE ATT&CK' field is populated. This field is visible in the incident details pane. The exam may ask you to identify where to find the MITRE ATT&CK information in an incident: it is under the 'Tags' section or in the 'MITRE ATT&CK' field on the incident blade.

Sentinel provides a built-in workbook called 'MITRE ATT&CK Coverage' under the 'Threat management' section. This dashboard visualizes your detection coverage as a heatmap of the MITRE matrix. Each cell represents a technique; the color intensity indicates how many rules cover that technique. You can filter by tactic, technique, or rule. The dashboard uses data from the 'SecurityAlert' table, which includes the MITRE tags. The exam expects you to know how to access this dashboard and interpret it.

To verify mapping via KQL:

SecurityAlert
| where TimeGenerated > ago(7d)
| extend Tactics = parse_json(tostring(parse_json(ExtendedProperties).["MitreTechniques"]))
| mv-expand Tactics
| summarize count() by tostring(Tactics)

This query extracts MITRE techniques from the ExtendedProperties field (which stores them as JSON). Note that the exact field may vary; the exam may test the field name 'MitreTechniques' or 'Techniques'.

A financial services company must comply with PCI DSS, which requires monitoring for unauthorized access to cardholder data. The SOC team creates a Sentinel rule that detects when a user accesses a database containing credit card numbers outside business hours. They map this rule to MITRE technique T1530 (Data from Information Repositories) under Collection (TA0009). The mapping allows them to generate compliance reports showing coverage for data theft techniques. However, they initially mapped only the parent technique T1530, missing the sub-technique T1530.001 (Data from Network Shared Drive). After a penetration test revealed that attackers exfiltrated data via network shares, they updated the mapping to include T1530.001. The coverage dashboard now shows two techniques covered, and the compliance report passes audit.

Two companies merge, each with its own SIEM. The combined SOC adopts Sentinel and needs to consolidate detection rules. One company had mapped all rules to MITRE; the other had not. The team uses the MITRE coverage dashboard to identify overlapping rules (e.g., both had rules for T1078 Valid Accounts) and gaps (e.g., no coverage for T1059 Command and Scripting Interpreter). They prioritize creating new rules for uncovered techniques. They also discover that some rules were mapped incorrectly—a rule detecting brute force was mapped to T1110 (Brute Force) under Credential Access, but the actual attack used password spraying, which is T1110.003. They correct the mapping. The dashboard now provides a single pane of glass for detection coverage across the merged entity.

A startup uses Sentinel to monitor its Azure environment. They have only 10 analytics rules. They want to ensure they cover the most critical techniques for Initial Access and Execution. They map each rule to the most relevant technique. For example, a rule detecting suspicious sign-ins from unfamiliar locations is mapped to T1078 (Valid Accounts) under Initial Access. They also use the MITRE dashboard to identify that they have no coverage for Persistence (TA0003). They prioritize creating a rule for T1098 (Account Manipulation) to detect when an adversary adds a new admin account. The mapping helps them allocate their limited resources effectively, focusing on the techniques most likely to be used against their cloud infrastructure. They also use the dashboard to track improvements over time.