Last reviewed:
How Azure security teams can turn Microsoft Defender for Cloud recommendations and alerts into risk, coverage and MITRE ATT&CK language without treating every posture issue as attacker behaviour.
Defender for Cloud produces more than one kind of security signal. Recommendations describe posture: configuration, exposure, plan coverage, agent state, identity hardening or control adoption. Security alerts describe detected activity or a suspicious sequence. Mixing those two classes is how a coverage report ends up claiming an ATT&CK detection where the source only proved that a control was missing.
Treat a recommendation as risk context unless it contains reviewed runtime evidence. A recommendation that a subscription lacks Defender plan coverage can raise priority for onboarding work, but it does not prove T1078 Valid Accounts activity. An alert about suspicious role assignment, credential access or command execution may support an ATT&CK mapping, provided the underlying alert fields and linked Azure evidence are preserved for review.
The practical split is simple. Posture findings answer 'what is exposed or under-protected?' Detection findings answer 'what behaviour was observed?' A useful guide, ticket or board report keeps those questions apart and then shows where they meet. When a posture issue and an alert involve the same asset, record both records in the case notes rather than merging them into one broad label. That extra line saves arguments later, especially when audit, platform and SOC owners read the same evidence pack during quarterly review.
Defender for Cloud recommendations are often written as control statements. SOC and engineering teams need a second layer that explains risk in operational terms: which resource is affected, which control is absent, what an attacker could do next and which team owns the fix. That translation should not inflate the evidence. A missing agent is an observability gap. It is not proof that an attacker disabled monitoring.
Start by recording the source object: subscription, resource group, resource id, recommendation id, assessment state, severity, policy initiative and affected asset class. Then add a short risk sentence. For example: 'Public management access on this virtual machine increases exposure to credential-stuffing and remote-access attempts.' That sentence gives a backlog owner something to act on without inventing an incident.
Security alerts need a different shape. Preserve alert id, alert type, product component, entities, affected resource, first activity time, severity and investigation links. Then decide whether the alert is direct detection evidence or a lead that needs Azure Activity Log, Entra ID, endpoint or workload logs before the SOC can count it as coverage.
ATT&CK mapping works best when the evidence names behaviour. A Defender for Cloud alert about suspicious Azure role assignment may support T1098 Account Manipulation or T1078.004 Valid Accounts: Cloud Accounts when the alert and supporting logs show who changed access, where the change landed and why it looked abnormal. A recommendation to enable a plan, install an extension or fix policy drift usually belongs in posture context instead.
Avoid one-to-one mapping tables that turn every Defender category into a technique. Those tables look tidy but fail during review. The same recommendation can support different risks across tenants, and the same alert can need different supporting logs before it becomes direct coverage. A role assignment in a lab subscription is not the same finding as a subscription-scope owner assignment after a risky sign-in.
Use evidence labels beside each mapping. Direct detection evidence can support a coverage claim. Correlation context means the finding helps explain another signal. Posture context means the finding affects priority or readiness. No mapping means the finding is still useful, but ATT&CK language would mislead the reader.
def defender_finding_evidence_kind(finding):
if finding.kind == 'security_alert' and finding.alert_type == 'suspicious_role_assignment':
return 'direct-detection:T1098'
if finding.kind == 'security_alert' and finding.has_identity_context:
return 'correlation-context:T1078.004'
if finding.kind == 'recommendation' and finding.category in {'coverage', 'configuration'}:
return 'posture-context'
return 'no-attack-mapping'
A repeatable review should handle Defender for Cloud findings in three passes. First, normalise the source class: recommendation, regulatory compliance item, secure score control or security alert. Second, attach ownership and business context. Third, decide whether the finding affects risk, detection coverage or both. This prevents posture backlog work from being counted as live detection coverage before a rule, alert or query exists.
Export and retention matter. Defender for Cloud can route data into Azure Monitor, Event Hub or a SIEM path depending on tenant setup and licensing. The mapping is only reviewable if the SOC can still see the fields that supported it. If the alert lands in Sentinel without the entity detail or the resource id is rewritten by a parser, the coverage claim should stay in review until the field map is fixed.
The review workflow also needs an honest no-map outcome. Some findings deserve remediation but not ATT&CK language. Examples include plan enablement, benchmark control drift, missing vulnerability assessment, weak backup configuration or compliance evidence gaps. Marking them as no-map protects the credibility of the ATT&CK register.
The useful output is not a huge spreadsheet of technique labels. It is a backlog that says what to fix next. A high-priority posture item may call for plan enablement, policy assignment, asset tagging or ownership clean-up. A detection item may need a Sentinel analytics rule, parser fix, alert-routing change or investigation note. A correlation item may need Entra ID, Azure Activity Log or endpoint evidence added before it can be promoted.
DCV records the source, evidence label and ATT&CK mapping beside the guide or control being reviewed. That gives leaders a clearer story: which Defender for Cloud findings reduce exposure, which ones create detection coverage and which ones are review leads. It also makes inflated claims easier to spot because every mapped technique has to point back to the finding class and source fields that support it.
Review the mapping after major Defender plan changes, Sentinel connector changes, policy initiative updates or incidents where a Defender finding was available but did not reach the right queue. The aim is boring but valuable: fewer vague high-severity tickets, fewer fake ATT&CK matches and a coverage register that a SOC lead can defend when asked what evidence sits behind it.