@blamejs/exceptd-skills 0.9.1

package/data/d3fend-catalog.json

@@ -0,0 +1,738 @@
+{
+  "_meta": {
+    "schema_version": "1.0.0",
+    "last_updated": "2026-05-11",
+    "d3fend_version": "1.0.0",
+    "d3fend_release_date": "2024-06-01",
+    "source": "https://d3fend.mitre.org",
+    "skill_refs_field": "d3fend_refs",
+    "complement_to": "atlas-ttps.json (offensive); D3FEND covers defensive countermeasures",
+    "root_tactics": [
+      "Model",
+      "Harden",
+      "Detect",
+      "Isolate",
+      "Deceive",
+      "Evict",
+      "Restore"
+    ],
+    "note": "Curated subset of D3FEND 1.0 techniques mapped to the offensive coverage in atlas-ttps.json and cve-catalog.json. Per AGENTS.md rule #10, only D3FEND IDs verified against the canonical ontology are included; uncertain IDs were omitted rather than fabricated. Per rule #9, every entry declares ai_pipeline_applicability — defenses architecturally impossible in ephemeral/serverless/AI pipeline contexts state an explicit alternative. Per rule #2 (framework lag), lag_notes capture the delta between framework-prescribed control behavior and the D3FEND-defined defensive behavior.",
+    "tlp": "CLEAR",
+    "source_confidence": {
+      "scheme": "Admiralty (A-F + 1-6)",
+      "default": "A1",
+      "note": "B = usually reliable; 2 = probably true. Per-entry overrides via entry-level source_confidence field. Public-record catalogs (NVD, ATLAS, CWE, RFC, framework publishers) get A1 (completely reliable, confirmed). Project-curated catalogs (zeroday-lessons, exploit-availability) default to B2 with source citations."
+    },
+    "freshness_policy": {
+      "default_review_cadence_days": 90,
+      "stale_after_days": 180,
+      "rebuild_after_days": 365,
+      "note": "Per-entry last_verified governs decay. Skills depending on this catalog must check entry freshness before high-stakes use."
+    }
+  },
+  "D3-EAL": {
+    "id": "D3-EAL",
+    "name": "Executable Allowlisting",
+    "tactic": "Harden",
+    "subtactic": "Application Hardening",
+    "description": "Using a digital signature or other artifact-identifying property to restrict process execution to a pre-approved set of executables, blocking arbitrary binaries from running regardless of file path or user privilege.",
+    "counters_attack_techniques": [
+      "T1068",
+      "T1059",
+      "T1204",
+      "AML.T0010",
+      "AML.T0010.003"
+    ],
+    "digital_artifacts_addressed": [
+      "Process",
+      "Executable Binary",
+      "Executable Script"
+    ],
+    "skills_referencing": [
+      "kernel-lpe-triage",
+      "mcp-agent-trust"
+    ],
+    "implementation_examples": [
+      "AppLocker (Windows)",
+      "Windows Defender Application Control (WDAC)",
+      "fapolicyd (Linux)",
+      "SELinux/AppArmor application profiles",
+      "Santa (macOS)"
+    ],
+    "framework_controls_partially_mapped": [
+      "NIST-800-53-CM-7(1)",
+      "NIST-800-53-CM-7(2)",
+      "NIST-800-53-CM-8(3)",
+      "ISO-27001-2022-A.8.19",
+      "PCI-DSS-v4-2.2.4"
+    ],
+    "ai_pipeline_applicability": "Partially applicable. In serverless and ephemeral container runtimes the OS-level allowlister cannot be installed; equivalent control is achieved by signed-image policy at the registry admission controller (Sigstore/cosign verification, Kyverno/OPA Gatekeeper image-signature rules) plus immutable rootfs. For MCP server runtimes the equivalent is binary-hash pinning per D3-EHB.",
+    "lag_notes": "NIST CM-7(1) prescribes 'least functionality' and CM-7(2) 'authorized software' but does not require cryptographic verification; many auditors accept inventory-only implementations. D3-EAL requires the runtime to actively block non-listed binaries — a behavior gap that paper-compliant CM-7 implementations routinely fail.",
+    "last_verified": "2026-05-11"
+  },
+  "D3-EHB": {
+    "id": "D3-EHB",
+    "name": "Executable Hashbased Allowlist",
+    "tactic": "Harden",
+    "subtactic": "Application Hardening",
+    "description": "Restricting execution to binaries whose cryptographic hash matches a pre-approved allowlist entry, providing stronger identity guarantees than path- or signer-based allowlisting because hashes change on any binary modification.",
+    "counters_attack_techniques": [
+      "T1195.001",
+      "T1195.002",
+      "AML.T0010",
+      "AML.T0010.001",
+      "AML.T0010.002",
+      "AML.T0010.003"
+    ],
+    "digital_artifacts_addressed": [
+      "Executable Binary",
+      "File Hash"
+    ],
+    "skills_referencing": [
+      "mcp-agent-trust",
+      "kernel-lpe-triage"
+    ],
+    "implementation_examples": [
+      "WDAC hash rules",
+      "fapolicyd hash trust database",
+      "MCP server binary hash pinning in client config",
+      "in-toto / SLSA Level 3 attestation for ML model and tool binaries"
+    ],
+    "framework_controls_partially_mapped": [
+      "NIST-800-53-SA-12",
+      "NIST-800-53-CM-7(5)",
+      "ISO-27001-2022-A.8.30",
+      "SOC2-CC9.2"
+    ],
+    "ai_pipeline_applicability": "Highly applicable to AI pipelines — directly addresses HuggingFace typosquat, malicious model weight files, and MCP server supply chain compromise (CVE-2026-30615 class). For ephemeral inference containers the hash check moves from runtime to admission control (registry signature plus model weight SHA-256 verification at load time).",
+    "lag_notes": "SA-12 supply-chain controls do not specify cryptographic hash verification at load time, and no framework yet requires hash pinning of pretrained model weights or MCP server binaries. Auditors accept SBOM presence as SA-12 evidence; D3-EHB requires the runtime to actively reject unpinned binaries, which most SBOM programs do not implement.",
+    "last_verified": "2026-05-11"
+  },
+  "D3-PSEP": {
+    "id": "D3-PSEP",
+    "name": "Process Segment Execution Prevention",
+    "tactic": "Harden",
+    "subtactic": "Platform Hardening",
+    "description": "Marking memory regions as non-executable so injected shellcode or data written to data segments cannot be executed by the CPU. Implemented as DEP / NX bit on x86_64 and PXN/UXN on ARM.",
+    "counters_attack_techniques": [
+      "T1068",
+      "T1055",
+      "T1203"
+    ],
+    "digital_artifacts_addressed": [
+      "Process Memory",
+      "Process Segment"
+    ],
+    "skills_referencing": [
+      "kernel-lpe-triage"
+    ],
+    "implementation_examples": [
+      "NX bit (x86_64)",
+      "PXN/UXN (ARM64)",
+      "W^X memory mappings (OpenBSD, hardened Linux)",
+      "SMEP / SMAP (kernel-mode counterpart)"
+    ],
+    "framework_controls_partially_mapped": [
+      "NIST-800-53-SI-16",
+      "ISO-27001-2022-A.8.9"
+    ],
+    "ai_pipeline_applicability": "Inherited from the underlying kernel; container and serverless workloads receive DEP/NX automatically. Not a workload-configurable control in ephemeral environments — verify only that the host kernel has SMEP/SMAP enabled and that JIT runtimes (Python ML stacks with native extensions) do not disable W^X for performance.",
+    "lag_notes": "SI-16 (memory protection) is present in nearly all compliance baselines but never specifies SMEP/SMAP/PXN enforcement at the kernel level. For Copy Fail class LPEs (CVE-2026-49105) DEP is a prerequisite, not a sufficient defense — the exploit operates inside the kernel's executable mapping where SMEP/SMAP applies but is bypassable via the underlying class flaw.",
+    "last_verified": "2026-05-11"
+  },
+  "D3-ASLR": {
+    "id": "D3-ASLR",
+    "name": "Address Space Layout Randomization",
+    "tactic": "Harden",
+    "subtactic": "Platform Hardening",
+    "description": "Randomizing the base addresses of executable, stack, heap, and library memory regions to prevent attackers from reliably hard-coding addresses in exploit payloads.",
+    "counters_attack_techniques": [
+      "T1068",
+      "T1055",
+      "T1203"
+    ],
+    "digital_artifacts_addressed": [
+      "Process Memory",
+      "Process Segment"
+    ],
+    "skills_referencing": [
+      "kernel-lpe-triage"
+    ],
+    "implementation_examples": [
+      "KASLR (Linux kernel)",
+      "Windows kernel ASLR",
+      "PIE binaries with full ASLR (Linux userland)",
+      "FG-KASLR (function-granular KASLR)"
+    ],
+    "framework_controls_partially_mapped": [
+      "NIST-800-53-SI-16",
+      "ISO-27001-2022-A.8.9"
+    ],
+    "ai_pipeline_applicability": "Inherited at host kernel level; not workload-configurable in containers or serverless. For confidential-compute AI pipelines (TEE-enclosed inference), ASLR is provided by the TEE runtime but with smaller entropy budgets — treat as defense-in-depth, not primary control.",
+    "lag_notes": "ASLR is universally assumed by SI-16 evidence but framework controls never specify the entropy budget required. Modern info-leak primitives (KASLR-defeating side channels, deterministic-allocator LPEs like Copy Fail) trivially bypass standard KASLR; lag is in framework's failure to require FG-KASLR or equivalent.",
+    "last_verified": "2026-05-11"
+  },
+  "D3-SCP": {
+    "id": "D3-SCP",
+    "name": "System Call Filtering",
+    "tactic": "Isolate",
+    "subtactic": "Execution Isolation",
+    "description": "Restricting the set of system calls a process can invoke, reducing the kernel attack surface available from a compromised userland process. Implemented as seccomp-bpf on Linux, syscall filters on Windows.",
+    "counters_attack_techniques": [
+      "T1068",
+      "T1611",
+      "T1059"
+    ],
+    "digital_artifacts_addressed": [
+      "Process",
+      "System Call"
+    ],
+    "skills_referencing": [
+      "kernel-lpe-triage",
+      "mcp-agent-trust"
+    ],
+    "implementation_examples": [
+      "seccomp-bpf profiles (Docker default, gVisor)",
+      "Windows Process Mitigation Policy syscall filters",
+      "OpenBSD pledge(2) / unveil(2)",
+      "Kubernetes RuntimeDefault and Localhost seccomp profiles"
+    ],
+    "framework_controls_partially_mapped": [
+      "NIST-800-53-SC-39",
+      "NIST-800-53-SI-10",
+      "ISO-27001-2022-A.8.20"
+    ],
+    "ai_pipeline_applicability": "Directly applicable and recommended for AI inference workloads. Default seccomp profile blocks the syscall surface most kernel-LPE PoCs depend on (e.g., io_uring entry points for Copy Fail class). MCP server processes should run under a RuntimeDefault profile at minimum; tighter Localhost profiles recommended for code-execution MCP tools.",
+    "lag_notes": "No major framework requires seccomp profiles or equivalent syscall filtering. SC-39 (process isolation) is satisfied by namespaces alone in most audits, leaving the kernel surface fully exposed. Compliance theater: 'we use containers' is accepted as SC-39 evidence even when containers run with --privileged or no seccomp profile.",
+    "last_verified": "2026-05-11"
+  },
+  "D3-PHRA": {
+    "id": "D3-PHRA",
+    "name": "Process Hardware Resource Access",
+    "tactic": "Isolate",
+    "subtactic": "Execution Isolation",
+    "description": "Controlling and restricting the hardware resources (CPU features, devices, IOMMU mappings, performance counters) that a process can access, limiting both side-channel attacks and direct hardware abuse paths.",
+    "counters_attack_techniques": [
+      "T1068",
+      "T1212",
+      "T1614.001"
+    ],
+    "digital_artifacts_addressed": [
+      "Process",
+      "Hardware Device",
+      "Hardware Performance Counter"
+    ],
+    "skills_referencing": [
+      "kernel-lpe-triage"
+    ],
+    "implementation_examples": [
+      "IOMMU groups and VT-d/AMD-Vi enforcement",
+      "cgroups v2 device controllers",
+      "GPU access scoping for ML workloads (NVIDIA MIG, MPS isolation)",
+      "perf_event_paranoid kernel parameter"
+    ],
+    "framework_controls_partially_mapped": [
+      "NIST-800-53-SC-39",
+      "NIST-800-53-AC-6(10)",
+      "ISO-27001-2022-A.8.20"
+    ],
+    "ai_pipeline_applicability": "Critical for multi-tenant GPU inference platforms — without MIG/MPS isolation a tenant can side-channel adjacent tenants' models. Standard container runtimes do not enforce GPU isolation by default. For confidential AI pipelines, IOMMU enforcement on accelerator passthrough is the equivalent control.",
+    "lag_notes": "No framework prescribes GPU or accelerator isolation requirements. SC-39 is interpreted as CPU-process isolation; the AI accelerator side-channel surface is invisible to compliance audits. NIST AI RMF MEASURE-2.7 mentions infrastructure security but does not require hardware-level tenant isolation.",
+    "last_verified": "2026-05-11"
+  },
+  "D3-MENCR": {
+    "id": "D3-MENCR",
+    "name": "Message Encryption",
+    "tactic": "Harden",
+    "subtactic": "Message Hardening",
+    "description": "Encrypting messages in transit between two parties to preserve confidentiality and, when authenticated encryption is used, integrity. Includes transport-layer (TLS) and application-layer (S/MIME, signed-and-encrypted JWT, MLS) approaches.",
+    "counters_attack_techniques": [
+      "T1040",
+      "T1557",
+      "T1565.002"
+    ],
+    "digital_artifacts_addressed": [
+      "Network Traffic",
+      "Message"
+    ],
+    "skills_referencing": [
+      "pqc-first",
+      "mcp-agent-trust"
+    ],
+    "implementation_examples": [
+      "TLS 1.3 with hybrid X25519MLKEM768 key exchange (RFC 9794-class drafts)",
+      "MLS for group messaging",
+      "Signed and encrypted JWTs for service-to-service auth",
+      "S/MIME for email"
+    ],
+    "framework_controls_partially_mapped": [
+      "NIST-800-53-SC-8",
+      "NIST-800-53-SC-13",
+      "ISO-27001-2022-A.8.24",
+      "PCI-DSS-v4-4.2.1"
+    ],
+    "ai_pipeline_applicability": "Universally applicable; AI API traffic should use TLS 1.3 with PQC-hybrid key exchange per CNSA 2.0 timelines. Note: encrypted AI API traffic remains a covert C2 channel (AML.T0096) — D3-MENCR protects confidentiality but does not address content-layer abuse; pair with D3-CSPP and D3-NTA.",
+    "lag_notes": "SC-8 / SC-13 require 'approved cryptography' but neither NIST 800-53 Rev 5 nor ISO 27001:2022 yet mandates PQC migration. CNSA 2.0 sets a 2030-2033 NSS deadline; commercial frameworks have not adopted equivalent timelines. Hybrid KEM deployment (ML-KEM + X25519) is current best practice and exceeds compliance requirements at every major framework.",
+    "last_verified": "2026-05-11"
+  },
+  "D3-FE": {
+    "id": "D3-FE",
+    "name": "File Encryption",
+    "tactic": "Harden",
+    "subtactic": "Credential Hardening",
+    "description": "Encrypting files at rest so their contents cannot be read without the decryption key, protecting against offline attacks on stolen storage media or unauthorized filesystem access.",
+    "counters_attack_techniques": [
+      "T1005",
+      "T1083",
+      "T1565.001"
+    ],
+    "digital_artifacts_addressed": [
+      "File",
+      "Encrypted File"
+    ],
+    "skills_referencing": [
+      "pqc-first"
+    ],
+    "implementation_examples": [
+      "LUKS / dm-crypt (Linux full-disk)",
+      "BitLocker (Windows)",
+      "FileVault (macOS)",
+      "age / rage (file-level)",
+      "envelope encryption with KMS-managed DEKs (AWS KMS, GCP KMS)"
+    ],
+    "framework_controls_partially_mapped": [
+      "NIST-800-53-SC-28",
+      "ISO-27001-2022-A.8.24",
+      "PCI-DSS-v4-3.5.1"
+    ],
+    "ai_pipeline_applicability": "Applies to model weight files, training datasets, and embedding stores at rest. For ephemeral inference workloads the practical control shifts to encrypted-at-rest object storage (S3 SSE-KMS) with the AI pipeline never persisting state locally. Note: harvest-now-decrypt-later means data encrypted today under RSA-2048 wrapping is exposed to post-2030 quantum decryption — pair with PQC roadmap.",
+    "lag_notes": "SC-28 is universally implemented but rarely specifies algorithm strength or post-quantum readiness. Compliance audits accept AES-256 at-rest as sufficient; D3-FE has no opinion on long-tail confidentiality requirements where HNDL adversaries are active.",
+    "last_verified": "2026-05-11"
+  },
+  "D3-CBAN": {
+    "id": "D3-CBAN",
+    "name": "Certificate-based Authentication",
+    "tactic": "Harden",
+    "subtactic": "Credential Hardening",
+    "description": "Authenticating a party using a digital certificate that binds an identity to a public key, where possession of the corresponding private key proves identity. Stronger than password authentication because secrets are not transmitted.",
+    "counters_attack_techniques": [
+      "T1078",
+      "T1110",
+      "T1556",
+      "T1606"
+    ],
+    "digital_artifacts_addressed": [
+      "Certificate",
+      "Authentication Service"
+    ],
+    "skills_referencing": [
+      "mcp-agent-trust",
+      "pqc-first"
+    ],
+    "implementation_examples": [
+      "mTLS for service-to-service auth",
+      "SPIFFE / SPIRE workload identities",
+      "WebAuthn / FIDO2 hardware authenticators",
+      "client certificates for MCP server authentication"
+    ],
+    "framework_controls_partially_mapped": [
+      "NIST-800-53-IA-2(11)",
+      "NIST-800-53-IA-5(2)",
+      "ISO-27001-2022-A.5.17",
+      "NIST-800-63B-AAL3"
+    ],
+    "ai_pipeline_applicability": "Recommended for service-to-service AI infrastructure (model registry, inference gateway, MCP server-client). Workload identity via SPIFFE is the standard pattern for ephemeral AI workloads where long-lived secrets are not viable.",
+    "lag_notes": "IA-2 requires multi-factor but accepts SMS / TOTP as 'something you have' — both phishable. D3-CBAN with hardware-bound private keys (FIDO2, TPM-resident mTLS) is materially stronger but not required by any framework below AAL3 / PCI-MFA-CDE-only contexts. Certificate algorithm agility for PQC migration (ML-DSA, SLH-DSA) is not yet a compliance requirement.",
+    "last_verified": "2026-05-11"
+  },
+  "D3-MFA": {
+    "id": "D3-MFA",
+    "name": "Multi-factor Authentication",
+    "tactic": "Harden",
+    "subtactic": "Credential Hardening",
+    "description": "Requiring two or more distinct authentication factors (knowledge, possession, inherence) to verify identity, raising the cost of credential-based intrusion.",
+    "counters_attack_techniques": [
+      "T1078",
+      "T1110",
+      "T1078.004",
+      "T1621"
+    ],
+    "digital_artifacts_addressed": [
+      "User Account",
+      "Authentication Service"
+    ],
+    "skills_referencing": [
+      "mcp-agent-trust"
+    ],
+    "implementation_examples": [
+      "FIDO2 / WebAuthn (phishing-resistant)",
+      "TOTP authenticator apps",
+      "Push-with-number-match (mitigates MFA fatigue)",
+      "Hardware security keys (YubiKey, Titan)"
+    ],
+    "framework_controls_partially_mapped": [
+      "NIST-800-53-IA-2(1)",
+      "NIST-800-53-IA-2(2)",
+      "ISO-27001-2022-A.8.5",
+      "PCI-DSS-v4-8.4",
+      "NIST-800-63B-AAL2"
+    ],
+    "ai_pipeline_applicability": "Applies to human access to AI control planes (model registry, fine-tuning consoles, MCP client configuration). Does not apply to machine-to-machine AI calls — use D3-CBAN there. Phishable MFA (SMS, basic push) is bypassed by AI-assisted phishing at industrial scale; FIDO2 is the only durable form.",
+    "lag_notes": "Every framework requires MFA but most accept any second factor as sufficient. CISA, NIST 800-63B-rev4, and OMB M-22-09 require phishing-resistant MFA for federal systems; most commercial frameworks (PCI, SOC 2) still accept SMS. The lag is in factor quality, not factor count.",
+    "last_verified": "2026-05-11"
+  },
+  "D3-CA": {
+    "id": "D3-CA",
+    "name": "Certificate Analysis",
+    "tactic": "Detect",
+    "subtactic": "Identifier Analysis",
+    "description": "Analyzing certificates observed in network traffic or installed on systems for indicators of malicious use: typosquatted CNs, anomalous issuers, short-lived certs to suspicious domains, or unexpected SANs.",
+    "counters_attack_techniques": [
+      "T1573",
+      "T1071.001",
+      "T1583.003",
+      "AML.T0096"
+    ],
+    "digital_artifacts_addressed": [
+      "Certificate",
+      "Network Traffic"
+    ],
+    "skills_referencing": [
+      "mcp-agent-trust",
+      "ai-c2-detection"
+    ],
+    "implementation_examples": [
+      "Certificate Transparency log monitoring (Sigsum, CT Watch)",
+      "JA3/JA4 TLS fingerprinting",
+      "MCP server TLS certificate pinning and rotation audit",
+      "issuer reputation enrichment in SIEM"
+    ],
+    "framework_controls_partially_mapped": [
+      "NIST-800-53-SI-4",
+      "NIST-800-53-SC-17",
+      "ISO-27001-2022-A.8.16"
+    ],
+    "ai_pipeline_applicability": "Applicable to outbound AI API traffic and MCP server endpoints. For AI-API C2 detection (AML.T0096), certificate analysis alone is insufficient because legitimate AI provider certificates are used — pair with D3-CSPP and D3-NTA.",
+    "lag_notes": "SI-4 / SC-17 do not require Certificate Transparency monitoring or JA4 fingerprinting. Most SOCs do not enrich TLS connections with certificate metadata at all; lag is in operational implementation, not control text.",
+    "last_verified": "2026-05-11"
+  },
+  "D3-DA": {
+    "id": "D3-DA",
+    "name": "Domain Analysis",
+    "tactic": "Detect",
+    "subtactic": "Identifier Analysis",
+    "description": "Analyzing domain names observed in traffic or configurations for indicators of malicious activity: newly registered domains, DGA patterns, homoglyph or typosquat similarity to known-good domains, lookalike domains for AI providers.",
+    "counters_attack_techniques": [
+      "T1071",
+      "T1568.002",
+      "T1583.001",
+      "AML.T0010.002",
+      "AML.T0010.003"
+    ],
+    "digital_artifacts_addressed": [
+      "Domain Name",
+      "DNS Query",
+      "Network Traffic"
+    ],
+    "skills_referencing": [
+      "mcp-agent-trust",
+      "ai-c2-detection"
+    ],
+    "implementation_examples": [
+      "Newly Observed Domain (NOD) blocking",
+      "DGA classifiers in DNS firewall",
+      "Lookalike-domain monitoring for AI provider hostnames (api.openai.com, claude.ai)",
+      "Passive DNS enrichment in SIEM"
+    ],
+    "framework_controls_partially_mapped": [
+      "NIST-800-53-SC-7(8)",
+      "NIST-800-53-SI-4(4)",
+      "ISO-27001-2022-A.8.16"
+    ],
+    "ai_pipeline_applicability": "Highly applicable to MCP supply chain attacks where typosquatted package or domain names install rogue MCP servers (CVE-2026-30615 vector). For AI-API C2, less effective because attackers use legitimate AI provider domains — domain analysis must combine with traffic content analysis (D3-CSPP).",
+    "lag_notes": "Compliance frameworks do not specify NOD blocking or DGA detection. SI-4(4) requires 'inbound and outbound communications traffic monitoring' but does not prescribe domain reputation enrichment. The lookalike-AI-domain detection class is novel and absent from all standard control sets.",
+    "last_verified": "2026-05-11"
+  },
+  "D3-NTA": {
+    "id": "D3-NTA",
+    "name": "Network Traffic Analysis",
+    "tactic": "Detect",
+    "subtactic": "Network Traffic Analysis",
+    "description": "Analyzing network traffic communication characteristics — volumes, timing, periodicity, packet sizes, entropy — to identify malicious activity that may be invisible to content inspection (e.g., encrypted C2 channels).",
+    "counters_attack_techniques": [
+      "T1071",
+      "T1573",
+      "T1041",
+      "T1095",
+      "AML.T0096"
+    ],
+    "digital_artifacts_addressed": [
+      "Network Traffic",
+      "Network Flow"
+    ],
+    "skills_referencing": [
+      "ai-c2-detection"
+    ],
+    "implementation_examples": [
+      "Zeek / Suricata flow analysis",
+      "Encrypted traffic analysis via metadata (Cisco ETA, JA4)",
+      "AI-API beacon detection (periodicity + payload-size clustering)",
+      "Statistical entropy scoring on prompt payloads"
+    ],
+    "framework_controls_partially_mapped": [
+      "NIST-800-53-SI-4",
+      "NIST-800-53-SC-7",
+      "ISO-27001-2022-A.8.16"
+    ],
+    "ai_pipeline_applicability": "Primary control for AML.T0096 (AI-API C2). Because the AI provider endpoint is allowlisted by SC-7 in nearly all enterprises, the entire C2 lifecycle is inside the trust boundary; NTA on AI-API flows is the only practical detection. Requires per-process attribution — flow-only analysis at the network boundary cannot distinguish legitimate from malicious AI use.",
+    "lag_notes": "No framework requires NTA on AI-API traffic specifically. SI-4 is interpreted as IDS at the perimeter; AI-API egress is categorically allowed and unmonitored. SesameOp and PROMPTFLUX operate entirely within compliance-accepted egress patterns.",
+    "last_verified": "2026-05-11"
+  },
+  "D3-NTPM": {
+    "id": "D3-NTPM",
+    "name": "Network Traffic Policy Mapping",
+    "tactic": "Model",
+    "subtactic": "Network Mapping",
+    "description": "Establishing and maintaining a baseline of permitted network communication patterns — who talks to whom, on which ports, with what protocols — so deviations can be detected by other techniques.",
+    "counters_attack_techniques": [
+      "T1071",
+      "T1090",
+      "T1571",
+      "AML.T0096"
+    ],
+    "digital_artifacts_addressed": [
+      "Network Traffic Policy",
+      "Network Flow"
+    ],
+    "skills_referencing": [
+      "ai-c2-detection"
+    ],
+    "implementation_examples": [
+      "Service mesh allow-policies (Istio AuthorizationPolicy, Linkerd)",
+      "Kubernetes NetworkPolicy",
+      "AWS VPC flow log baselining",
+      "Per-process AI API egress allowlist (only build agents may reach api.anthropic.com)"
+    ],
+    "framework_controls_partially_mapped": [
+      "NIST-800-53-SC-7",
+      "NIST-800-53-AC-4",
+      "ISO-27001-2022-A.8.22"
+    ],
+    "ai_pipeline_applicability": "Critical for AI-pipeline security. Without per-process AI-API egress policy, AML.T0096 detection is structurally impossible — every workload becomes a potential C2 endpoint. In serverless contexts, NTPM is enforced at the egress VPC endpoint or service mesh sidecar layer.",
+    "lag_notes": "SC-7 is implemented as boundary firewall in almost all environments; per-process or per-workload egress allowlists are rare. AC-4 (information flow enforcement) is satisfied by network segmentation evidence even when intra-zone egress is unrestricted — exactly the lag AI-API C2 exploits.",
+    "last_verified": "2026-05-11"
+  },
+  "D3-CSPP": {
+    "id": "D3-CSPP",
+    "name": "Client-server Payload Profiling",
+    "tactic": "Detect",
+    "subtactic": "Message Analysis",
+    "description": "Analyzing the payloads exchanged between clients and servers for indicators of malicious use — anomalous sizes, encodings, command-like structures, or content that diverges from expected application semantics.",
+    "counters_attack_techniques": [
+      "T1071.001",
+      "T1041",
+      "AML.T0096",
+      "AML.T0096.000",
+      "AML.T0051.001"
+    ],
+    "digital_artifacts_addressed": [
+      "Network Traffic",
+      "Application Payload"
+    ],
+    "skills_referencing": [
+      "ai-c2-detection",
+      "mcp-agent-trust"
+    ],
+    "implementation_examples": [
+      "AI-API request body inspection at egress proxy (CloudFlare AI Gateway, LiteLLM proxy)",
+      "Steganographic-encoding entropy scoring on prompt content",
+      "MCP tool-call argument schema validation and anomaly scoring",
+      "Prompt-payload classifier for indirect-injection patterns"
+    ],
+    "framework_controls_partially_mapped": [
+      "NIST-800-53-SI-4(11)",
+      "NIST-800-53-SC-7(10)",
+      "ISO-27001-2022-A.8.16"
+    ],
+    "ai_pipeline_applicability": "Most directly applicable defense against AML.T0096. Requires terminating-proxy architecture for AI API traffic (egress gateway with TLS interception or sanctioned SDK that logs structured payloads). Architecturally impossible when applications call AI APIs directly with org-managed TLS to the provider — alternative is mandated SDK with logging hooks.",
+    "lag_notes": "SI-4(11) (analyze communications traffic anomalies) was written for traditional protocols; no framework guidance exists for AI-prompt content inspection. The prompt-as-payload analysis class did not exist when control catalogs were last revised. Compliance-driven SOCs are not equipped to ingest or analyze prompt traffic.",
+    "last_verified": "2026-05-11"
+  },
+  "D3-IOPR": {
+    "id": "D3-IOPR",
+    "name": "Input/Output Profiling Resource",
+    "tactic": "Detect",
+    "subtactic": "Process Analysis",
+    "description": "Profiling the input and output behavior of a process or resource to establish a baseline and detect anomalies, including unexpected I/O patterns, unusual data flows, or access to unexpected resources.",
+    "counters_attack_techniques": [
+      "T1005",
+      "T1041",
+      "AML.T0051",
+      "AML.T0017",
+      "AML.T0017.001"
+    ],
+    "digital_artifacts_addressed": [
+      "Process",
+      "Resource Access"
+    ],
+    "skills_referencing": [
+      "ai-attack-surface",
+      "rag-pipeline-security"
+    ],
+    "implementation_examples": [
+      "LLM output classifier for safety-bypass content (Llama Guard, Granite Guardian)",
+      "Semantic divergence scoring (user intent vs. AI action)",
+      "RAG retrieval-pattern anomaly detection",
+      "AI API query rate / similarity clustering for probe detection"
+    ],
+    "framework_controls_partially_mapped": [
+      "NIST-800-53-SI-4",
+      "NIST-AI-RMF-MEASURE-2.5",
+      "ISO-27001-2022-A.8.16"
+    ],
+    "ai_pipeline_applicability": "Primary detection control for prompt injection (AML.T0051) and model ontology discovery (AML.T0017). Applies natively to AI pipelines — operates at the application layer where ephemeral runtime is irrelevant. Output-side IOPR (classifying AI responses) is more reliable than input-side (prompt classification) given the variety of injection encodings.",
+    "lag_notes": "NIST AI RMF MEASURE-2.5 recommends 'measurement of AI system trustworthiness characteristics' but is non-prescriptive. No framework requires runtime output safety scoring or input adversarial classification. OWASP LLM Top 10 documents the need; compliance frameworks have not incorporated it.",
+    "last_verified": "2026-05-11"
+  },
+  "D3-RPA": {
+    "id": "D3-RPA",
+    "name": "Remote Process Analysis",
+    "tactic": "Detect",
+    "subtactic": "Process Analysis",
+    "description": "Analyzing processes running on remote hosts via agent-based or agentless telemetry to detect malicious behaviors — unexpected child processes, anomalous network behavior by identity, or process-resource correlations indicating compromise.",
+    "counters_attack_techniques": [
+      "T1057",
+      "T1071",
+      "T1059",
+      "AML.T0096"
+    ],
+    "digital_artifacts_addressed": [
+      "Process",
+      "Process Tree"
+    ],
+    "skills_referencing": [
+      "ai-c2-detection"
+    ],
+    "implementation_examples": [
+      "EDR with process-network correlation (CrowdStrike, SentinelOne, Defender for Endpoint)",
+      "Sysmon + Sigma rules for AI-API egress by unexpected process",
+      "eBPF-based runtime monitors (Falco, Tetragon)",
+      "Process identity attribution on AI API outbound flows"
+    ],
+    "framework_controls_partially_mapped": [
+      "NIST-800-53-SI-4(2)",
+      "NIST-800-53-SI-4(4)",
+      "ISO-27001-2022-A.8.16"
+    ],
+    "ai_pipeline_applicability": "Applies to traditional workloads. Serverless and FaaS contexts have no persistent process to analyze — alternative is invocation-level telemetry from the platform (CloudWatch Lambda Insights, GCP Cloud Run audit logs) correlated with AI-API egress flow records.",
+    "lag_notes": "Process-to-AI-API correlation is not part of any standard EDR ruleset. SI-4(2) (automated tools and mechanisms) requires SIEM/EDR presence but not the specific correlation rule. Most SOCs lack the process-identity attribution needed to distinguish legitimate from malicious AI-API use at the host.",
+    "last_verified": "2026-05-11"
+  },
+  "D3-FAPA": {
+    "id": "D3-FAPA",
+    "name": "File Access Pattern Analysis",
+    "tactic": "Detect",
+    "subtactic": "File Analysis",
+    "description": "Analyzing patterns of file access — which files, by which processes, in which sequence — to detect anomalies suggesting credential theft, staging, or unauthorized data access.",
+    "counters_attack_techniques": [
+      "T1005",
+      "T1083",
+      "T1552.001",
+      "AML.T0010.002"
+    ],
+    "digital_artifacts_addressed": [
+      "File",
+      "File Access"
+    ],
+    "skills_referencing": [
+      "kernel-lpe-triage",
+      "mcp-agent-trust"
+    ],
+    "implementation_examples": [
+      "auditd FIM with behavioral rules",
+      "EDR file-access timeline analysis",
+      "MCP tool-call file-system access logging",
+      "model weight file access monitoring (who reads .safetensors at unusual hours)"
+    ],
+    "framework_controls_partially_mapped": [
+      "NIST-800-53-AU-2",
+      "NIST-800-53-AU-6",
+      "ISO-27001-2022-A.8.15"
+    ],
+    "ai_pipeline_applicability": "Applies to persistent inference and training infrastructure. For serverless inference the alternative is object-storage access logging (S3 server access logs, GCS audit logs) with anomaly analysis on model-weight object reads.",
+    "lag_notes": "AU-2 / AU-6 require auditing and review but do not require behavioral analytics on file access. UEBA on file access is a SIEM-vendor feature, not a compliance requirement. Lag is between control text ('audit appropriate events') and operational behavior detection.",
+    "last_verified": "2026-05-11"
+  },
+  "D3-NI": {
+    "id": "D3-NI",
+    "name": "Network Isolation",
+    "tactic": "Isolate",
+    "subtactic": "Network Isolation",
+    "description": "Restricting which hosts and networks a system can communicate with, reducing both inbound attack surface and outbound exfiltration / C2 opportunity.",
+    "counters_attack_techniques": [
+      "T1090",
+      "T1071",
+      "T1041",
+      "AML.T0096"
+    ],
+    "digital_artifacts_addressed": [
+      "Network",
+      "Network Traffic"
+    ],
+    "skills_referencing": [
+      "ai-c2-detection",
+      "kernel-lpe-triage"
+    ],
+    "implementation_examples": [
+      "VPC egress allowlists with no default internet route",
+      "Per-namespace Kubernetes NetworkPolicy (deny-all default)",
+      "AI API egress proxy as sole route to provider endpoints",
+      "Microsegmentation (Illumio, Cisco Secure Workload)"
+    ],
+    "framework_controls_partially_mapped": [
+      "NIST-800-53-SC-7",
+      "NIST-800-53-AC-4",
+      "ISO-27001-2022-A.8.22",
+      "PCI-DSS-v4-1.4"
+    ],
+    "ai_pipeline_applicability": "Highly applicable: AI workloads should route to AI providers only through a sanctioned egress proxy that enforces per-workload identity, logs payloads (D3-CSPP), and applies traffic policy (D3-NTPM). Default-deny egress is the only structural defense against AML.T0096 — direct AI-API egress from arbitrary workloads makes C2 detection unreliable.",
+    "lag_notes": "SC-7 boundary-protection language is satisfied by perimeter firewalls; default-deny egress at workload granularity is not required by any framework. AC-4 information-flow enforcement is satisfied by network zoning; per-process or per-pod egress policy is rare in audited environments.",
+    "last_verified": "2026-05-11"
+  },
+  "D3-PA": {
+    "id": "D3-PA",
+    "name": "Process Analysis",
+    "tactic": "Detect",
+    "subtactic": "Process Analysis",
+    "description": "Analyzing the properties and behavior of processes (parent-child relationships, command-line arguments, loaded modules, system call patterns) to identify malicious activity.",
+    "counters_attack_techniques": [
+      "T1055",
+      "T1059",
+      "T1068",
+      "T1106",
+      "AML.T0010.003"
+    ],
+    "digital_artifacts_addressed": [
+      "Process",
+      "Process Tree"
+    ],
+    "skills_referencing": [
+      "kernel-lpe-triage",
+      "mcp-agent-trust"
+    ],
+    "implementation_examples": [
+      "Sysmon process-creation events with parent-child Sigma rules",
+      "EDR behavioral detections (suspicious process trees)",
+      "Linux audit / ausearch on execve with command-line capture",
+      "MCP server process-tree anomaly detection (unexpected spawn of shell from MCP host)"
+    ],
+    "framework_controls_partially_mapped": [
+      "NIST-800-53-SI-4",
+      "NIST-800-53-AU-2",
+      "ISO-27001-2022-A.8.16"
+    ],
+    "ai_pipeline_applicability": "Applies to persistent hosts running MCP servers, AI coding assistants, or AI build agents. For serverless invocations, equivalent is per-invocation runtime telemetry (Lambda extension hooks, Cloud Run service workload identity logs) correlated with the AI-API call graph.",
+    "lag_notes": "SI-4 / AU-2 require monitoring but do not require parent-child process-tree analytics. Most enterprise audits accept 'we have EDR' as evidence regardless of whether behavioral rules are tuned. Lag is in operationalization — control existence vs. detection quality.",
+    "last_verified": "2026-05-11"
+  }
+}