The AWS Threat Technique Catalog tells you what attackers do. It does not tell you what defenders should do about it. D3FEND-AWS fills that gap — a structured, open-source dataset that maps every AWS TTC attack technique to specific AWS-native defensive countermeasures, modelled on the MITRE D3FEND framework.

The project is live now: GitHub repository and interactive matrix.

The AWS Threat Technique Catalog

In 2024, AWS published the Threat Technique Catalog — an open-source catalogue of attack techniques specific to AWS, organised by MITRE ATT&CK tactics. It documents how adversaries operate in AWS: how they gain initial access through overly permissive security groups, escalate privileges by creating additional cloud credentials, evade defences by disabling GuardDuty or CloudTrail, hijack compute for cryptomining, and encrypt S3 buckets for ransom.

The TTC is valuable because it narrows the scope. MITRE ATT&CK documents hundreds of techniques across every platform. The TTC filters that to the approximately fifty techniques that matter specifically in AWS, with AWS-specific sub-technique IDs (like T1078.A001 for IAM user credential abuse or T1496.A007 for Bedrock LLM hijacking) and direct links to the AWS services involved.

But the TTC describes one side of the problem. It catalogues the offensive techniques — the attack surface. What it does not provide is the defensive counterpart: which AWS-native controls detect, prevent, or contain each of those techniques. That mapping is what security teams need when they sit down to answer the question are we covered?

The missing defensive layer

MITRE D3FEND exists to answer that question at the framework level. Where ATT&CK catalogues offensive techniques, D3FEND catalogues defensive ones — a knowledge graph of countermeasures organised into seven tactics: Model, Harden, Detect, Isolate, Deceive, Evict, and Restore.

D3FEND is platform-agnostic by design. It tells you that Platform Monitoring is a valid detection technique and that Credential Revocation is a valid eviction technique. It does not tell you that Platform Monitoring in AWS means analysing CloudTrail management events, or that Credential Revocation means attaching a deny-all inline policy with an aws:TokenIssueTime condition to invalidate active role sessions.

The gap is clear: the TTC gives you AWS-specific attacks without defences. D3FEND gives you platform-agnostic defences without AWS specifics. Neither gives you the mapping between the two.

What D3FEND-AWS is

D3FEND-AWS bridges that gap. It is a curated dataset — not a tool, not a platform — that maps every technique in the AWS TTC to specific defensive techniques expressed as structured YAML, each one scoped entirely to AWS-native services.

The current release covers three D3FEND tactics, chosen for immediate operational value:

  • Detect (20 techniques) — CloudTrail management event analysis, GuardDuty threat detection, VPC Flow Log analysis, S3 data event monitoring, IAM Access Analyzer, billing anomaly detection, and more.
  • Harden (17 techniques) — SCP preventive controls, Resource Control Policies, MFA enforcement, IMDSv2, S3 Block Public Access, Object Lock, Lambda code signing, Config Rules compliance, and more.
  • Evict (11 techniques) — IAM credential revocation, role session invalidation, EC2 instance isolation, S3 bucket policy lockdown, account quarantine, compute resource termination, and more.

Every one of the 51 attack technique IDs in the AWS TTC is countered by at least one defensive technique. Full coverage across detect, harden, and evict.

Structured content, not prose

The design decision that matters most: D3FEND-AWS is structured data, not documentation. Each defensive technique is a single YAML file with a defined schema:

id: D3FA-DT-0001
name: CloudTrail Management Event Analysis
tactic: detect
category: Platform Monitoring
description: >
  Analyze CloudTrail management events to detect unauthorized
  API activity such as credential abuse, privilege escalation,
  or attempts to disable security controls.
aws_services:
  - AWS CloudTrail
  - Amazon CloudWatch Logs
counters:
  - T1078.A001
  - T1078.A002
  - T1098.001
  - T1562.008
d3fend_ref: d3f:PlatformMonitoring
attack_tactics:
  - TA0003
  - TA0005

Every file validates against a JSON Schema. A CI pipeline runs schema validation on every push and pull request. The counters field links directly to AWS TTC technique IDs. The d3fend_ref field links back to the canonical D3FEND ontology. The aws_services field tells you exactly which AWS services are involved.

This structure is deliberate. YAML is human-readable and machine-parseable. A security architect can browse the files in a text editor. An automation pipeline can ingest them programmatically — to generate coverage reports, populate a CMDB, feed a GRC tool, or build custom dashboards. The data is the product; the presentation layer is interchangeable.

Why this matters

Three use cases drove the project:

Coverage gap analysis. A security architect can take their organisation’s deployed controls, compare them against the D3FEND-AWS dataset, and produce a concrete list of AWS TTC techniques they have no defence against. Not a theoretical risk assessment — a direct mapping from attack technique to missing control.

Detection engineering prioritisation. A detection engineer can look up any AWS TTC technique by ID and immediately see which AWS services provide detection signal for it. Instead of starting from “we should probably monitor CloudTrail”, they start from “T1562.A001 (Disable or Modify GuardDuty) is countered by D3FA-DT-0001 (CloudTrail Management Event Analysis) and D3FA-HD-0001 (SCP Preventive Controls) — do we have both?”

Incident response playbook design. The evict tactic maps specific containment actions to the attack techniques they contain. When a responder identifies T1078.A001 (Valid Accounts — IAM Users), the dataset points them to D3FA-EV-0001 (IAM Credential Revocation) as the containment action, with the AWS services involved listed explicitly.

The interactive matrix

The matrix view presents the dataset visually — three columns for Detect, Harden, and Evict, with technique cards showing the ID, name, category, and AWS service tags. Clicking a card opens a detail panel with the full description and the list of countered attack techniques, each linked directly to the corresponding page on the AWS TTC site.

The matrix is generated from the same YAML files that comprise the dataset. A build script reads the data directory and produces a single HTML page. If the YAML changes, the matrix updates on the next build.

Open source, open contribution

The project is MIT-licensed and open for contribution on GitHub. The repository structure is designed so that adding a new defensive technique requires only adding a single YAML file in the correct tactic directory — no structural changes, no code modifications. Schema validation catches errors before they merge.

The repository includes:

  • The complete dataset (48 defensive techniques across 3 tactics)
  • The normalised AWS TTC attack catalog (51 techniques across 11 ATT&CK tactics)
  • JSON Schema for technique validation
  • Build and validation scripts
  • GitHub Actions CI pipeline
  • A steering document outlining project scope, architecture, and conventions

What comes next

The current release is mapping-only — it tells you what to do, not how to do it. Future phases may include:

  • Additional D3FEND tactics — Model, Isolate, Deceive, and Restore are natural extensions.
  • Runbook-level detail — specific AWS CLI commands, CloudFormation and Terraform snippets, and detection query examples for each technique.
  • Coverage reporting tooling — scripts that compare an organisation’s deployed controls against the dataset and output a gap report.

The dataset will also track the AWS TTC as it evolves. New techniques added to the TTC will need corresponding defensive mappings.

Where Threat Composer fits

AWS also open-sources Threat Composer — a threat modelling tool that helps teams compose structured threat statements using a defined grammar. It outputs machine-readable JSON alongside human-readable formats, and ships as a web application, VS Code extension, and AI-powered CLI.

Threat Composer, the TTC, and D3FEND-AWS occupy different stages of the same pipeline. Threat Composer helps a team articulate what could go wrong — structured threat statements scoped to their architecture. The TTC catalogues the specific attack techniques that realise those threats in AWS. D3FEND-AWS maps the defensive countermeasures that detect, prevent, and contain those techniques.

The value of all three being structured data rather than prose is that the pipeline can be automated. A threat model produced in Threat Composer identifies the attack surface. The TTC technique IDs describe how that surface gets exploited. The D3FEND-AWS counters field links those IDs to specific AWS-native controls. An organisation that adopts all three has a traceable path from threat statement to deployed defence — each step machine-readable, each mapping explicit.

The connection to detection and prevention

This project sits at the intersection of themes explored in previous posts on this site. The SCPs and RCPs post examined how preventive controls close gaps before detection is needed. The GuardDuty-CloudTrail correlation post examined how detection signals need enrichment to become actionable. D3FEND-AWS provides the structured reference that connects those discussions — a single dataset that maps from attack technique to the specific detect, harden, and evict controls available in AWS.

Every detection finding is a map of where preventive controls did not reach. Every preventive control is a statement about which attack techniques are structurally impossible. D3FEND-AWS makes those relationships explicit, machine-readable, and open source.

Explore the interactive matrix or browse the GitHub repository.