DE1.4 Severity, MITRE Mapping, and Documentation

Severity, ATT&CK mapping, and documentation are configured on the General tab of the analytics rule wizard. They're the first things you see when creating a rule, and the last things most people think carefully about. That's a mistake. These three metadata decisions control how the SOC prioritizes your rule's alerts, how your detection program measures coverage, and whether anyone can maintain the rule after you wrote it. A rule with excellent KQL but wrong severity, missing technique mapping, and no documentation is a rule that misleads the SOC, doesn't register in coverage metrics, and becomes unmaintainable.

Estimated time: 40 minutes.

Severity classification

Sentinel provides four severity levels. Each has a specific architectural meaning defined by Microsoft — not a subjective "how bad does this feel" assessment.

Informational — the activity does not directly impact the environment, but may indicate planning or reconnaissance by a threat actor. Use this for rules that detect activity that isn't threatening by itself but provides context: enumeration of directory objects, first-time access to a resource, geographic anomalies that match travel patterns. Informational alerts are typically consumed by other rules (two-stage detection) or reviewed during proactive hunts rather than triaged by the SOC.

Low — the immediate impact is minimal. The threat actor would need multiple additional steps before achieving meaningful impact on the environment. Use this for rules that detect early kill chain activity that is often benign: a single failed MFA challenge, PowerShell execution by a known admin, an external email forwarding rule created by a user who regularly does so. Low severity alerts are triaged but not with the urgency of Medium or High.

Medium — the threat actor could have some impact on the environment, but the impact would be limited in scope or require additional activity. Use this for rules that detect activity with moderate confidence of malicious intent: a brute force pattern followed by a successful sign-in, an inbox rule creation after a medium-risk sign-in, a service principal granted unusual permissions. Most detection rules fall here — the activity is suspicious enough to investigate but not confirmed malicious.

High — the activity provides the threat actor with wide-ranging access or is triggered by confirmed impact on the environment. Use this for rules that detect late kill chain activity or high-confidence indicators: ransomware pre-encryption (shadow copy deletion), credential dumping from LSASS, mass data exfiltration, C2 communication to known infrastructure, lateral movement to domain controllers. High severity incidents get immediate SOC response.

Why most template severities are wrong for your environment

Template rules ship with severity values chosen by the template author for a generic environment. The author doesn't know your organization's crown jewels, your threat landscape, your SOC's capacity, or your incident response SLAs. A template rule for "suspicious PowerShell execution" set to Medium severity might be correct in an environment where PowerShell is rare, but it's wrong in an environment where 40% of admin workflows use encoded PowerShell — that rule will flood the Medium queue with false positives and desensitize analysts to real threats.

The detection engineer's job is to calibrate severity based on three factors specific to their environment:

Impact if true. What can the attacker do if this detection is a true positive? Shadow copy deletion preceding ransomware = High (the attacker is minutes from encrypting). An inbox rule after a risky sign-in = Medium (persistence established, but exfiltration hasn't started). A geographic sign-in anomaly = Low or Informational (could be travel, could be a proxy, needs context).

Confidence of malicious intent. How likely is the detected activity to be actually malicious versus a false positive? A brute force with 50 failures from a Tor exit node = High confidence. A brute force with 6 failures from a corporate VPN IP = Low confidence. Higher confidence can justify higher severity.

SOC capacity. A small SOC that triages 50 incidents per day cannot sustain 30 High severity incidents. If everything is High, nothing is — analysts stop trusting severity and develop their own informal triage heuristics, defeating the purpose of the classification. Calibrate severity so that High means "drop what you're doing" and that happens 2 to 5 times per week, not 30 times per day.

Dynamic severity

In Section 1.3, you saw how alert details override lets you template severity dynamically using a query result column. This is the production approach for rules where the severity depends on the specific finding. A brute force with 6 failures gets Low. The same rule detecting 50 failures from 8 countries gets High. One rule, one query, calibrated severity per alert based on the actual evidence.

The case() expression in your query evaluates the finding and outputs a severity string. The alert details override maps that string to the severity field. Every alert from the rule gets individually calibrated severity instead of a static default.

MITRE ATT&CK technique mapping

When you create or edit a rule, the General tab includes a MITRE ATT&CK section where you select the tactics and techniques the rule detects. This mapping serves three purposes that make it non-optional for every rule you build.

Purpose 1 — Coverage measurement

Sentinel's MITRE ATT&CK page (Threat Management → MITRE ATT&CK) shows a coverage matrix. Each cell represents a technique. Active rules with that technique mapped appear as active coverage. Template rules that you haven't enabled appear as simulated coverage. The matrix answers the CISO's question — "what percentage of relevant techniques do we detect?" — but only if your rules are mapped. An unmapped rule is invisible to the coverage matrix. It fires, it produces alerts, the SOC triages them — but the coverage metric doesn't know it exists.

Sentinel is currently aligned to ATT&CK framework version 18. The coverage matrix distinguishes between active detections (rules you've enabled) and simulated detections (templates available but not configured). The gap between active and simulated is the engineering backlog — the techniques you could detect if you enabled or built rules for them.

Purpose 2 — Incident context

When a rule fires and creates an incident, the ATT&CK techniques you mapped appear on the incident card. The analyst sees "Credential Access → T1110 Brute Force" and immediately understands where this activity sits in the kill chain. If the same incident contains alerts from multiple rules with different technique mappings — a brute force alert (Credential Access) and an inbox rule alert (Persistence) — the analyst sees both tactics represented and recognizes a multi-stage attack without having to infer it from the raw data.

Purpose 3 — Fusion integration

Fusion's ML correlation engine uses ATT&CK tactics and techniques to detect multi-stage attacks. The Fusion documentation states explicitly: "Fusion calculations might be affected if incoming alerts are missing tactic information." If your custom scheduled rule has entity mapping but no ATT&CK mapping, Fusion can't incorporate its alerts into multi-stage correlation. You've built the detection but prevented it from participating in the correlation layer.

How to map correctly

The brute force test rule maps to: Credential Access (tactic) → T1110 Brute Force (technique). This is straightforward — the rule detects brute force, and T1110 is the corresponding ATT&CK technique.

For rules that detect multi-phase activity, you can map multiple tactics and techniques. The CHAIN-HARVEST inbox rule detection from Section 1.1 maps to both Credential Access (the risky sign-in) and Persistence (the inbox rule creation). The rule detects activity that spans two kill chain phases, and the mapping reflects both.

Common mapping errors to avoid:

Mapping too broadly. A rule that detects inbox rule creation is T1564.008 (Email Hiding Rules), not the entire T1564 (Hide Artifacts) technique. Sub-technique precision matters for coverage measurement — the matrix counts sub-techniques separately.

Mapping the wrong tactic. An inbox rule after a compromised sign-in is Persistence (the attacker is establishing continued access), not Collection (the attacker is not yet gathering data). The tactic reflects what the attacker is achieving at this stage of the kill chain, not what they'll do later.

Not mapping at all. The template rule came without technique mapping, and you deployed it as-is. The rule works — it fires, it produces alerts — but it's invisible to coverage measurement and Fusion. Mapping takes 30 seconds per rule.

View your current coverage

Open the MITRE ATT&CK page in your Sentinel workspace. The matrix shows your active coverage. Look for techniques with zero active detections but multiple simulated ones — those are coverage gaps where templates exist but haven't been enabled or customized. Look for techniques with zero coverage in both active and simulated — those are gaps where you need to build custom rules. This matrix is the starting point for the detection backlog you'll build in DE2 (threat modeling and prioritization).

Run this query to see which of your active rules have ATT&CK mapping and which don't:

// ATT&CK mapping audit — which rules are mapped, which are not?
SecurityAlert
| where TimeGenerated > ago(30d)
| where ProviderName startswith "ASI"
| extend Tactics = tostring(parse_json(ExtendedProperties)["Tactics"])
| summarize AlertCount = count(),
    HasTactics = count(iff(isnotempty(Tactics), 1, int(null)))
    by AlertName
| extend MappingStatus = iff(HasTactics > 0, "Mapped", "UNMAPPED")
| sort by MappingStatus asc, AlertCount desc

This query examines every Sentinel-generated alert from the last 30 days, extracts the Tactics field from ExtendedProperties, and classifies each rule as Mapped or UNMAPPED. If a rule has produced alerts without any ATT&CK technique information, it appears as UNMAPPED. Those are the rules you need to edit and classify. Every unmapped rule is a detection that doesn't register in your coverage metrics.

Rule documentation — the specification

A detection rule without documentation is a query that only the author understands. When the author leaves, changes roles, or simply forgets the design reasoning six months later, the rule becomes an opaque configuration that nobody can confidently modify, tune, or decommission.

The rule specification is the engineering document that captures every design decision. You'll build a complete specification template in Section 1.7 — this section introduces the concept and explains why each field exists.

A rule specification answers six questions:

What does this rule detect? The detection hypothesis in plain language. Not "detects brute force" — that's a label, not a hypothesis. "Detects 5 or more failed authentication attempts followed by a successful sign-in for the same user account within a 20-minute window, indicating a credential compromise where the attacker eventually obtained the correct password." The hypothesis is specific enough to evaluate — you can test whether the rule actually detects what it claims.

Why does this technique matter here? The threat context. Why is brute force relevant to this organization? What threat actors use this technique against this industry? What assets are at risk if the technique succeeds? This context justifies the rule's existence in the detection backlog and its priority relative to other rules.

What data does the rule need? The data source, the specific table, the specific fields, and the ingestion latency characteristics. "SigninLogs, fields UserPrincipalName, ResultType, IPAddress. Average ingestion latency 2-3 minutes. Rule lookback extended to 20 minutes (vs 15-minute frequency) to compensate."

What does the rule produce? The entity mapping, custom details, dynamic alert content, and severity classification. Documented so that anyone reviewing the rule's output knows what each field means and where each value comes from.

What false positives should the SOC expect? The expected false positive sources and the analyst response procedure for each. "Service accounts with recurring password rotation may trigger the threshold. Verify against the service account watchlist before escalating. If the account is on the watchlist and the source IP is internal, close as benign positive."

How is the rule maintained? The tuning cadence, the metrics to review, and the criteria for modifying the threshold, severity, or logic. "Review false positive rate monthly. If FP rate exceeds 20%, investigate the top FP source and add to the exclusion watchlist. If FP rate drops below 2%, consider lowering the threshold to catch lower-volume attacks."

Update your test rule

Open your test rule. Edit the General tab:

1. Severity: Evaluate using the three-factor model. A brute force with a successful sign-in is a confirmed credential compromise with moderate impact potential — Medium is appropriate. If your environment has no MFA enforcement, consider High (the compromised credential grants full access). If MFA is enforced and the success was MFA-verified, consider Low (the attacker may have obtained the password but can't use it).

1. MITRE ATT&CK: Select Credential Access → T1110 (Brute Force). If your query also detects password spraying patterns (many users, few attempts each), add T1110.003 (Password Spraying) as a sub-technique.

1. Description: Replace the placeholder with a specification summary — the detection hypothesis, the data source, the expected false positives, and the analyst response procedure. This description is what the SOC analyst reads when investigating the incident. Make it actionable.