Last reviewed:
A practical comparison of how the three cloud platforms expose security signals, and what that means for ATT&CK coverage reporting.
ATT&CK gives the shared vocabulary, but it does not make AWS, Azure and GCP emit the same evidence. GuardDuty finding types, Defender for Cloud alerts and Security Command Center findings all look like managed cloud detections at first glance. They differ in scope, source detail and how much extra logging an analyst needs before acting.
A useful coverage report keeps those differences in the model. If a technique is covered only by a posture finding in one cloud and by a runtime alert in another, the heatmap should not colour both cells as equal. The map should say what kind of evidence backs the cell.
AWS coverage often starts with GuardDuty and Security Hub. GuardDuty gives named finding types for behaviours such as credential misuse, reconnaissance, crypto-mining and suspicious API use. Security Hub adds standards and controls that expose risky configuration states.
That is a strong starting point, but it can make coverage look broader than analyst reality. A failed FSBP control may show that logging is missing or a public access block is disabled. It is valuable risk context, not the same thing as detecting an adversary action. DCV treats those as different evidence classes.
Azure coverage leans hard on identity. Entra ID sign-ins, audit logs, conditional access outcomes and service-principal changes often tell the story before a workload alert appears. Defender for Cloud adds alert coverage across resources, but identity logs remain central for cloud-account abuse.
That changes the mapping habit. Role assignments, consent grants and app credential additions should not be rolled into a bland identity anomaly bucket. They are specific attacker moves. Map the operation to the technique and keep the source table visible so the analyst knows whether to query Entra, Activity Log or Sentinel.
GCP coverage depends heavily on which Cloud Audit Logs are collected. Admin Activity logs give a baseline for control-plane changes, while Data Access logs may be disabled or sampled differently because of volume and cost. A map that ignores that setting will overstate coverage for storage, BigQuery and service-account abuse.
Security Command Center gives managed findings and Google SecOps can run rule logic over forwarded events. The best coverage view shows all three layers: managed findings, audit logs and SIEM detections. If one layer is absent, the report should say so plainly.
Do not compress the three clouds into a single percentage without evidence labels. Report direct detections separately from posture signals and correlation-only context. Then rank gaps by the techniques your threat model actually cares about.
This gives executives a clean answer without lying to the SOC. The headline can be simple: which techniques are covered, which clouds have weaker evidence, and which log or rule change would improve the next review.