DE1.5 Severity Classification and MITRE ATT&CK Mapping

Severity is not subjective

Severity determines SOC behavior. The analyst’s triage process is severity-driven: Critical alerts are investigated immediately — the analyst stops their current work. High alerts are triaged within 15 minutes during business hours. Medium alerts are triaged when the queue permits — typically within 1-2 hours. Low alerts are batch-reviewed in the daily security summary.

If every alert is Medium, the analyst treats them all with the same urgency — which means none of them receive the urgency that actual high-priority threats deserve. If Critical is over-assigned (more than 3-5 rules), the analyst experiences alert fatigue specifically on Critical alerts, which is the most dangerous form of desensitization.

Severity is determined by two dimensions: detection confidence (how likely is this alert a true positive?) and business impact (if this is a true positive and goes unaddressed, how bad is the outcome?).

Figure DE1.5 — Severity assignment matrix. Two dimensions determine severity: how confident is the detection (TP rate), and how bad is the outcome if it is real and missed. NE-specific examples at each intersection.

Applying the matrix to Northgate Engineering

Critical (reserve for 3-5 rules): vssadmin shadow copy deletion from a non-admin process (high confidence — almost always malicious; catastrophic impact — ransomware encryption in progress). LSASS memory access by a non-system process (high confidence — known credential dump technique; catastrophic impact — attacker gains domain credentials). These rules justify NRT deployment (DE1.6) and automated response (DE1.10).

High (10-15 rules): AiTM session token theft (high confidence once the session anomaly pattern is confirmed; significant impact — attacker has full mailbox and app access). RDP to a domain controller from a non-admin user (high confidence — field engineers do not RDP to DCs; significant impact — potential domain compromise). PIM Global Admin activation outside business hours (medium confidence — could be legitimate emergency; catastrophic impact — Global Admin can do anything).

Medium (15-25 rules): Suspicious inbox rule creation from a risky session (high confidence if correlated with identity risk; moderate impact — persistence, not immediate damage). Bulk SharePoint file download by a user who normally downloads fewer than 10 files per day (medium confidence — could be a legitimate project; significant impact if exfiltration). New conditional access policy modification (medium confidence — could be authorized IT change; significant impact if it creates an exposure window like CHAIN-DRIFT).

Low (10-15 rules): First-time access to a sensitive SharePoint site (low confidence — likely legitimate; moderate impact). New Entra ID app registration (low confidence — developers register apps routinely; moderate impact if malicious permissions). Anomalous sign-in properties without additional risk signals (low confidence — travel, VPN, device change all produce this).

MITRE ATT&CK mapping at sub-technique level

Every detection rule must map to at least one ATT&CK technique. The mapping serves two critical purposes: it connects the rule to the coverage assessment (DE2 measures coverage as distinct techniques detected / total relevant techniques), and it provides the SOC analyst with kill-chain context during triage.

Map at the sub-technique level when possible. The difference matters for coverage measurement. If you have 5 rules all mapped to T1059 (Command and Scripting Interpreter), your coverage assessment shows 1 technique covered. If those 5 rules are mapped to T1059.001 (PowerShell), T1059.003 (Windows Command Shell), T1059.005 (Visual Basic), T1059.006 (Python), and T1059.007 (JavaScript), your coverage shows 5 sub-techniques covered — a more accurate representation of your detection breadth.

In the Sentinel analytics rule configuration, MITRE ATT&CK mapping is set under the “Tactics and Techniques” section. Select the tactic first (e.g., Initial Access), then the technique (e.g., T1566 Phishing), then the sub-technique if applicable (e.g., T1566.002 Spearphishing Link). Multiple mappings are supported — a rule that detects inbox rule creation from a compromised session maps to both T1137.005 (Outlook Rules — Persistence) and the initial credential access technique that enabled the session compromise.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

// COVERAGE VERIFICATION: List all rules with ATT&CK mappings
SecurityAlert
| where TimeGenerated > ago(90d)
| where ProviderName == "ASI Scheduled Alerts"
| extend Techniques = tostring(parse_json(ExtendedProperties).["Techniques"])
| extend Tactics = tostring(parse_json(ExtendedProperties).["Tactics"])
| summarize
    AlertCount = count(),
    LatestAlert = max(TimeGenerated)
    by AlertName, Techniques, Tactics
| where isnotempty(Techniques)
| sort by Tactics asc, Techniques asc
// Rules with empty Techniques field are unmapped — detection coverage blind spots

The ATT&CK Navigator (attack.mitre.org/matrices/enterprise/) accepts JSON layer files that visualize your coverage. DE10 teaches how to generate Navigator layers automatically from your Sentinel analytics rules — producing the heatmap visualization for the quarterly report.

The severity-frequency connection

Severity and query frequency should align. A Critical severity rule should run at NRT or 5-minute frequency — if the alert is critical enough to interrupt the analyst immediately, it should be detected as fast as possible. A Low severity rule that runs at 5-minute frequency wastes compute on detections that will not be triaged for hours regardless of when they fire.

Northgate Engineering’s current state: all 23 rules run at default frequency (mostly 5 hours for templates) with mostly Medium severity. The detection engineering program will redistribute: Critical and High rules get faster frequencies, Low rules get slower frequencies, and the total compute budget stays approximately constant while detection latency improves for the rules that matter most.

Troubleshooting: Severity and mapping issues

“All our rules are Medium severity.” This is the most common severity anti-pattern. It means severity was defaulted during creation and never reassessed. Conduct a one-time severity audit: for each rule, apply the confidence × impact matrix. Reassign severities. Then establish the practice: every new rule’s severity is justified in the specification (section 8 — Severity + Rationale). No rule ships at Medium without an explicit rationale.

“Our rules have ATT&CK tactic mappings but not technique mappings.” Tactic-only mapping (e.g., “Initial Access” without specifying T1566.002) is too coarse for coverage measurement. Two rules both mapped to “Initial Access” could detect the same technique or different techniques — you cannot tell without technique-level mapping. Open each rule and add the specific technique ID. The Sentinel UI provides a searchable technique picker.

“We mapped techniques but the coverage report shows lower coverage than expected.” Check for duplicate technique coverage — multiple rules detecting the same technique count as coverage for ONE technique. The coverage metric is distinct techniques, not rule count. Also verify that the technique is relevant to your environment. Covering T1200 (Hardware Additions) is not meaningful if your threat model does not include physical access attacks.

References used in this subsection

• MITRE ATT&CK Enterprise Matrix v15 (attack.mitre.org)
• Course cross-references: DE1.3 (frequency selection by severity), DE1.6 (NRT for Critical detections), DE2 (coverage assessment using ATT&CK mapping), DE10 (ATT&CK Navigator layer generation)