Introducing Detection Coverage Validator: Know What You’re Actually Detecting

You’ve deployed GuardDuty. You’ve written CloudWatch alarms. You’ve configured Security Hub standards and sprinkled in some custom Config rules. But can you answer a simple question: which MITRE ATT&CK techniques does your environment actually detect?

Most security teams can’t. And that blind spot is exactly what Detection Coverage Validator (DCV) is built to solve.

The Problem: Detection Sprawl Without Visibility

Cloud environments accumulate detections over time. A new compliance requirement triggers a Config rule. An incident leads to a CloudWatch alarm. A vendor demo gets GuardDuty enabled. Before long, you have dozens—sometimes hundreds—of detection mechanisms scattered across services.

But sprawl isn’t coverage.

The uncomfortable reality is that most security teams operate with significant blind spots they can’t even identify. Without a systematic way to map detections to threats, you’re left with uncomfortable questions:

  • Do your detections actually cover the techniques adversaries use against cloud environments?

  • Are there single points of failure where one disabled rule eliminates coverage for an entire tactic?

  • When AWS deprecates an API or changes a service, which of your detections break silently?

  • Are you paying for overlapping detections that cover the same technique three different ways?

These aren’t hypothetical concerns. They’re daily operational reality for security teams managing cloud infrastructure.

What DCV Does

Detection Coverage Validator connects to your AWS and GCP environments, analyses your deployed detection mechanisms, and maps them to the MITRE ATT&CK framework. The result is a clear picture of what you’re actually detecting—and what you’re not.

MitreCoverage

Multi-Cloud Detection Scanning

DCV pulls configurations from the detection services you’re already using:

AWS:

  • SecurityHub findings and standards

  • GuardDuty detector configurations

  • CloudWatch alarms and metric filters

  • CloudTrail-based detections

  • Config rules (managed and custom)

  • EventBridge rules

GCP:

  • Security Command Center findings

  • Chronicle detection rules

  • Cloud Logging-based alerts

  • Cloud Monitoring policies

The scanners extract not just what’s enabled, but the actual detection logic—event patterns, query syntax, trigger conditions. This is the raw material for meaningful coverage analysis.

MITRE ATT&CK Mapping

Each detection gets mapped to the ATT&CK techniques it can plausibly identify. DCV uses a combination of pattern matching, semantic analysis, and detection signature databases to determine coverage.

The output isn’t a simple checkbox. Each mapping includes a confidence score reflecting how directly the detection addresses the technique. A GuardDuty finding for UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration maps with high confidence to T1552 (Unsecured Credentials). A generic CloudWatch alarm on API error rates might have indirect relevance to multiple techniques with lower confidence.

This nuance matters. A coverage map that treats all detections equally isn’t useful for prioritisation.

Gap Analysis and Prioritisation

Once detections are mapped, DCV identifies coverage gaps—techniques with no detection coverage or inadequate coverage. But not all gaps are equal.

The gap analysis considers:

  • Technique prevalence: How commonly is this technique observed in real-world cloud attacks?

  • Your asset exposure: Which of your deployed services and configurations are vulnerable to this technique?

  • Existing partial coverage: Do you have detections that might catch related activity, even if they don’t directly address the technique?

The result is a prioritised list of gaps with context, not just a red heatmap that tells you everything is broken.

Remediation Guidance

Identifying gaps is only useful if you can close them. DCV provides specific remediation recommendations for each coverage gap:

  • Which AWS or GCP service can detect this technique

  • Sample detection logic (CloudWatch query, EventBridge pattern, Config rule)

  • Implementation complexity and cost implications

  • Links to relevant vendor documentation

The goal is actionable output. A gap report that requires a week of research to act on doesn’t help anyone.

How It Works

DCV operates on a straightforward workflow:

1. Connect Your Cloud Accounts

Grant DCV read-only access to your AWS or GCP environments. For AWS, this means an IAM role with SecurityAudit permissions. For GCP, the Security Center Reader role. No write access, no agent deployment, no infrastructure changes.

2. Run a Scan

DCV inventories your detection configurations across all supported services. This typically takes a few minutes depending on the size of your environment.

3. Review Coverage

The dashboard presents your coverage state: a MITRE ATT&CK matrix showing which techniques you detect, which you don’t, and the confidence levels for each mapping. Drill down into specific techniques to see which detections provide coverage and how.

4. Address Gaps

Export gap reports, prioritise based on your risk appetite, and use the remediation guidance to implement new detections. Re-scan to validate coverage improvements.

5. Monitor Drift

Detection coverage degrades over time. Rules get disabled. APIs change. New services get deployed without corresponding detections. DCV supports scheduled scans to track coverage drift and alert when your posture changes.

Built Secure by Design

As a cloud security professional, I’d be a hypocrite to build a security product that wasn’t itself secure. DCV follows security architecture best practices with defence in depth across every layer.

Infrastructure Security

DCV runs on hardened AWS infrastructure with strict network segmentation. The application operates in private subnets with no direct internet exposure. All ingress flows through a WAF-protected load balancer with rate limiting and bot mitigation. Egress is restricted to known endpoints only—your cloud provider APIs and nothing else.

I use immutable infrastructure patterns. No SSH access to production systems. No persistent shells. Infrastructure changes flow through version-controlled Terraform with mandatory review gates.

Data Protection

Your cloud credentials never touch DCV’s systems. DCV uses cross-account IAM roles (AWS) and workload identity federation (GCP) for access. I request read-only permissions scoped to security services—no access to your actual workloads, data stores, or secrets.

Detection configurations are encrypted at rest (AES-256) and in transit (TLS 1.3). Data retention is minimised by design: DCV stores the analysis results you need, not raw configuration dumps.

Application Security

The application itself follows OWASP guidelines throughout. Input validation on all API endpoints. Parameterised queries preventing injection attacks. Strict Content Security Policy headers. Authentication via industry-standard OAuth 2.0 with short-lived tokens and automatic rotation.

I run continuous dependency scanning and address vulnerabilities before they reach production. The CI/CD pipeline includes SAST, container image scanning, and infrastructure policy checks as hard gates.

Operational Security

Access to production systems follows least-privilege principles with just-in-time elevation for incident response. All administrative actions are logged to an immutable audit trail. DCV monitors for anomalous behaviour patterns and alerts on deviations from baseline.

Regular penetration testing and security assessments validate these controls. I’m not just building detection capabilities for your environment—I’m applying the same rigour to my own.

Compliance Alignment

DCV’s architecture aligns with SOC 2 Type II controls and implements CIS benchmark recommendations for cloud workloads. For customers in regulated industries, I provide detailed security documentation and architecture diagrams on request.

The bottom line: I built DCV the way I’d advise my consulting clients to build their own applications. Security isn’t a feature I added—it’s foundational to how the product operates.

Who This Is For

DCV is built for security practitioners who own detection and response:

  • Detection Engineers building and maintaining cloud detection capabilities

  • Security Architects designing coverage strategies for cloud environments

  • SOC Teams who need to understand what their tooling can and can’t see

  • Compliance Teams mapping detection controls to frameworks like NIST or CIS

If you’ve ever been asked “are we covered for technique X?” and had to guess, DCV gives you the answer.

Why I Built This

I’ve spent years working in cloud security, architecting AWS and GCP environments, building detection capabilities, and consulting on security programs. The same gap kept appearing: organisations invest heavily in security tooling but lack visibility into what that tooling actually covers.

MITRE ATT&CK provides an excellent framework for thinking about threats, but mapping your specific detections to that framework is manual, tedious, and usually incomplete. Security teams deserve better tooling for this problem.

Detection Coverage Validator is the tool I wished existed. Now it does.

Get Started

DCV is available now at a13e.com.

Connect your first cloud account and see your coverage state in minutes. If you have questions or want to discuss detection engineering challenges, reach out, I’m always happy to talk shop.

──────────────────────────────────────────────────

Austin Osuide is a cloud security consultant and the founder of a13e. He writes about cloud infrastructure, threat detection, and security engineering at austinosuide.com.