Cloud detection coverage 101
Measure cloud detection coverage by mapping AWS, Azure and GCP controls to the ATT&CK techniques that matter to your team.
Audience: SOC leads and cloud security engineers
Difficulty: Beginner
Last reviewed:
Practical primers on cloud detection engineering. Each guide cites its sources and is dated for last-verified currency.
Foundational primers for teams beginning cloud detection coverage work.
2 guides 02Platform-specific mapping and coverage guides for cloud findings.
10 guides 03Practical guidance for turning advisories, Sigma and SIEM rules into usable detections.
9 guides 04How a13e keeps detection content reviewed, current and verifiable.
4 guides 05Technique-centred guidance for prioritising detection gaps.
1 guidesMeasure cloud detection coverage by mapping AWS, Azure and GCP controls to the ATT&CK techniques that matter to your team.
Audience: SOC leads and cloud security engineers
Difficulty: Beginner
Separate compliance controls from detection evidence so coverage reports show what the SOC can actually see.
Audience: SOC leads, cloud security leads and security reviewers
Difficulty: Beginner
Translate GuardDuty, Security Hub and Config findings into ATT&CK techniques so AWS coverage gaps are visible and reviewable.
Audience: AWS security engineers and detection engineers
Difficulty: Intermediate
Map Defender for Cloud alerts, Entra ID sign-ins and Azure Activity logs to ATT&CK so Azure detection gaps are reviewable.
Audience: Azure security engineers and detection engineers
Difficulty: Intermediate
Map Security Command Center findings, Cloud Audit Logs and Google SecOps detections to ATT&CK without hiding GCP context.
Audience: GCP security engineers and detection engineers
Difficulty: Intermediate
Compare how AWS, Azure and GCP expose security signals so ATT&CK coverage reports do not pretend the platforms work the same way.
Audience: SOC leads comparing cloud detection coverage
Difficulty: Intermediate
Detect role assumption abuse, access key misuse and risky policy changes in AWS IAM without overclaiming absolute coverage.
Audience: AWS security engineers and SOC analysts
Difficulty: Intermediate
Build CloudTrail detections around AWS API activity, identity context and control-plane changes without treating every event name as equal.
Audience: AWS SOC teams and cloud detection engineers
Difficulty: Intermediate
Translate GuardDuty finding types into ATT&CK coverage language without treating a managed finding as a SIEM rule.
Audience: AWS SOC teams and cloud detection engineers
Difficulty: Intermediate
Separate Security Hub control status from SOC detection coverage so AWS posture gaps become useful detection backlog items.
Audience: AWS SOC leads and cloud security engineers
Difficulty: Intermediate
Turn Azure Activity Log records into reviewable SOC detections for control-plane change, role assignment abuse and logging tamper.
Audience: Azure SOC teams and cloud detection engineers
Difficulty: Intermediate
Turn S3 public exposure, object access and exfiltration signals into SOC detection coverage without mixing posture and telemetry.
Audience: AWS SOC teams and cloud security engineers
Difficulty: Intermediate
Pick the right Sigma conversion target for Splunk, Sentinel, Google SecOps, Elastic or OpenSearch without losing cloud field context.
Audience: Detection engineers moving cloud rules into a SIEM
Difficulty: Beginner
Judge whether a Sigma rule is ready for production by checking log source fit, field mapping, false positives and SIEM conversion.
Audience: Detection engineers reviewing Sigma rules
Difficulty: Intermediate
Turn a vulnerability advisory into a useful Sigma rule by separating exploit telemetry from patch priority and product metadata.
Audience: SOC leads and detection engineers handling vulnerability-driven alerts
Difficulty: Intermediate
Tune Sigma rules in the SIEM by suppressing known-good activity while preserving the attacker behaviour the rule was built to catch.
Audience: SIEM engineers tuning cloud and endpoint detections
Difficulty: Intermediate
Use CVSS for patch triage, but rank detection work by exploit telemetry, asset exposure and attacker behaviour.
Audience: SOC leads and vulnerability-driven detection teams
Difficulty: Intermediate
Decide whether a vulnerability advisory needs a Sigma rule, hunt note, patch-priority note or no detection work yet.
Audience: SOC leads and vulnerability-driven detection teams
Difficulty: Beginner
Protect the rule library by declining CVE detections when the advisory lacks observable attacker behaviour.
Audience: Detection engineers reviewing CVE-driven rule candidates
Difficulty: Intermediate
Map CVE exploitation evidence to ATT&CK techniques by following the observable attacker action, not the vulnerability label.
Audience: Detection engineers and ATT&CK coverage reviewers
Difficulty: Intermediate
Check advisory facts, rule specificity, SIEM conversion and public copy before publishing a CVE-led detection.
Audience: SOC content reviewers and detection engineering leads
Difficulty: Advanced
How a13e keeps published detection content tied to reviewed CloudSigma rule output without exposing private review machinery.
Audience: SOC leads, buyers and security reviewers
Difficulty: Beginner
Set a practical review rhythm for cloud detection coverage so ATT&CK mappings stay tied to current evidence and backlog work.
Audience: SOC leads and detection engineering managers
Difficulty: Beginner
Document the evidence behind a coverage claim: technique, telemetry, rule logic, triage path and known limits.
Audience: Detection engineers and SOC content reviewers
Difficulty: Intermediate
Convert ATT&CK coverage gaps into scoped engineering tickets by naming missing evidence, fix type, validation and owner.
Audience: SOC leads, detection engineers and cloud security owners
Difficulty: Intermediate
Turn an ATT&CK heatmap into a ranked cloud detection backlog using exposure, attacker paths and telemetry cost.
Audience: Detection engineering leads and cloud SOC leads
Difficulty: Intermediate