@blamejs/exceptd-skills 0.15.0 → 0.15.2
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +12 -0
- package/data/_indexes/_meta.json +44 -44
- package/data/_indexes/section-offsets.json +804 -795
- package/data/_indexes/summary-cards.json +3 -3
- package/data/_indexes/token-budget.json +506 -501
- package/data/cve-catalog.json +629 -51
- package/manifest.json +84 -84
- package/package.json +1 -1
- package/sbom.cdx.json +94 -94
- package/skills/age-gates-child-safety/skill.md +7 -7
- package/skills/ai-attack-surface/skill.md +1 -1
- package/skills/ai-c2-detection/skill.md +3 -3
- package/skills/ai-risk-management/skill.md +9 -9
- package/skills/api-security/skill.md +4 -4
- package/skills/cloud-security/skill.md +7 -7
- package/skills/compliance-theater/skill.md +4 -4
- package/skills/container-runtime-security/skill.md +6 -6
- package/skills/coordinated-vuln-disclosure/skill.md +12 -12
- package/skills/defensive-countermeasure-mapping/skill.md +14 -10
- package/skills/dlp-gap-analysis/skill.md +3 -3
- package/skills/email-security-anti-phishing/skill.md +6 -6
- package/skills/exploit-scoring/skill.md +2 -2
- package/skills/framework-gap-analysis/skill.md +6 -6
- package/skills/fuzz-testing-strategy/skill.md +1 -1
- package/skills/global-grc/skill.md +2 -2
- package/skills/identity-assurance/skill.md +5 -5
- package/skills/idp-incident-response/skill.md +5 -5
- package/skills/incident-response-playbook/skill.md +8 -8
- package/skills/kernel-lpe-triage/skill.md +4 -4
- package/skills/mcp-agent-trust/skill.md +3 -3
- package/skills/mlops-security/skill.md +5 -5
- package/skills/ot-ics-security/skill.md +7 -7
- package/skills/policy-exception-gen/skill.md +2 -2
- package/skills/pqc-first/skill.md +2 -2
- package/skills/rag-pipeline-security/skill.md +2 -2
- package/skills/ransomware-response/skill.md +9 -9
- package/skills/researcher/skill.md +11 -11
- package/skills/sector-energy/skill.md +6 -6
- package/skills/sector-federal-government/skill.md +2 -2
- package/skills/sector-financial/skill.md +4 -4
- package/skills/sector-healthcare/skill.md +6 -6
- package/skills/sector-telecom/skill.md +1 -1
- package/skills/security-maturity-tiers/skill.md +4 -4
- package/skills/skill-update-loop/skill.md +6 -6
- package/skills/supply-chain-integrity/skill.md +1 -1
- package/skills/threat-model-currency/skill.md +3 -3
- package/skills/threat-modeling-methodology/skill.md +9 -9
- package/skills/webapp-security/skill.md +7 -7
- package/skills/zeroday-gap-learn/skill.md +8 -8
|
@@ -48,13 +48,17 @@ d3fend_refs:
|
|
|
48
48
|
- D3-RPA
|
|
49
49
|
- D3-SCP
|
|
50
50
|
last_threat_review: "2026-05-11"
|
|
51
|
-
discovery_mode: "standalone" #
|
|
51
|
+
discovery_mode: "standalone" # operator-reached via `exceptd brief defensive-countermeasure-mapping` or `exceptd ask`; not chained into any playbook's direct.skill_chain by design
|
|
52
52
|
---
|
|
53
53
|
|
|
54
54
|
# Defensive Countermeasure Mapping — D3FEND as the Blue-Team Counterpart to ATT&CK / ATLAS
|
|
55
55
|
|
|
56
56
|
ATT&CK and ATLAS catalog what attackers do. D3FEND catalogs what defenders do, in the same technique-grain taxonomy. Most SOCs in mid-2026 maintain an ATT&CK heatmap of detection coverage; far fewer maintain a D3FEND coverage map of the controls that actually counter those techniques. Operators can articulate attacker behavior with technique-level precision but can only articulate their own defenses at framework-control granularity ("we have SI-2"), which is a category mismatch. This skill closes that mismatch. Inputs are offensive findings — a CVE, an ATT&CK or ATLAS technique, a framework control gap. Outputs are layered defensive-countermeasure maps grounded in `data/d3fend-catalog.json` and explicitly threaded through defense-in-depth, least-privilege, and zero-trust principles.
|
|
57
57
|
|
|
58
|
+
## Frontmatter Scope
|
|
59
|
+
|
|
60
|
+
The `atlas_refs`, `attack_refs`, and `framework_gaps` arrays are intentionally empty. This skill maps defensive countermeasures (MITRE D3FEND) rather than owning a native set of offensive techniques — its subject is the blue-team control taxonomy, not adversary TTPs. The offensive techniques it counters come from whatever finding the operator supplies at invocation time; that input domain is the union of every ATLAS/ATT&CK technique in the catalog, so pinning a fixed subset here would falsely narrow it. The authoritative technique attachment lives in the offensive skill that produced the finding.
|
|
61
|
+
|
|
58
62
|
---
|
|
59
63
|
|
|
60
64
|
## Threat Context (mid-2026)
|
|
@@ -100,13 +104,13 @@ No major compliance framework requires technique-grained defensive mapping. Each
|
|
|
100
104
|
| Industry | PCI DSS v4.0 | Twelve requirements for cardholder data environments | Control-level. The closest technique-grain language is in 5.x (malware protection) — does not require D3FEND mapping. |
|
|
101
105
|
| Industry | SOC 2 TSC | Trust Services Criteria outcome categories | Outcome-level. Auditor discretion on implementation. |
|
|
102
106
|
|
|
103
|
-
The cross-framework pattern is uniform: every framework operates at control or outcome grain. D3FEND operates at technique grain. The translation layer — which technique counters which attack technique, in which D3FEND tactic, at which trust posture, at which privilege scope — is the gap this skill fills. The framework controls themselves are not wrong; they are coarser than the threat.
|
|
107
|
+
The cross-framework pattern is uniform: every framework operates at control or outcome grain. D3FEND operates at technique grain. The translation layer — which technique counters which attack technique, in which D3FEND tactic, at which trust posture, at which privilege scope — is the gap this skill fills. The framework controls themselves are not wrong; they are coarser than the threat. The framework lag is structural and first-class: no framework yet operationalizes the defensive technique taxonomy.
|
|
104
108
|
|
|
105
109
|
---
|
|
106
110
|
|
|
107
111
|
## TTP Mapping
|
|
108
112
|
|
|
109
|
-
This is a meta-mapping skill. Its TTP coverage equals the union of: every ATLAS technique in `data/atlas-ttps.json`, every ATT&CK technique appearing in any `attack_refs` field across the skill library, and every offensive technique referenced in any `counters_attack_techniques` array inside `data/d3fend-catalog.json`.
|
|
113
|
+
This is a meta-mapping skill. Its TTP coverage equals the union of: every ATLAS technique in `data/atlas-ttps.json`, every ATT&CK technique appearing in any `attack_refs` field across the skill library, and every offensive technique referenced in any `counters_attack_techniques` array inside `data/d3fend-catalog.json`. Every D3FEND ID in the catalog is mapped to at least one offensive technique — there are no orphan defensive entries (no orphaned controls).
|
|
110
114
|
|
|
111
115
|
The skill consumes offensive findings from these inputs and produces defensive mappings. It does not author new offensive technique entries; that is the job of the catalogs upstream and the `zeroday-gap-learn` and `threat-model-currency` skills. The cross-walk surfaces:
|
|
112
116
|
|
|
@@ -133,14 +137,14 @@ For each D3FEND ID surfaced by Analysis Procedure Step 3, the matrix records:
|
|
|
133
137
|
|---|---|---|
|
|
134
138
|
| Deployed in the org's stack? | operator input, verified against asset inventory | Is the control actually running, or only purchased / specified? |
|
|
135
139
|
| Tunable per environment? | `data/d3fend-catalog.json` `implementation_examples` | Can the control be tuned for serverless vs. monolith vs. ephemeral container, or is it host-only? |
|
|
136
|
-
| AI-pipeline applicable? | `data/d3fend-catalog.json` `ai_pipeline_applicability` (mandatory
|
|
140
|
+
| AI-pipeline applicable? | `data/d3fend-catalog.json` `ai_pipeline_applicability` (mandatory field) | If the control is architecturally impossible in serverless / container / AI pipeline contexts, the catalog declares an explicit alternative (e.g., admission-controller signature verification as the D3-EAL surrogate for serverless). The matrix surfaces that alternative. |
|
|
137
141
|
| Defense-in-depth layer | computed from `data/d3fend-catalog.json` `tactic` (Model / Harden / Detect / Isolate / Deceive / Evict / Restore) | Which DiD layer the control occupies for this finding. A finding defended only in one layer is under-defended. |
|
|
138
142
|
| Privilege scope | computed from `data/d3fend-catalog.json` description and from the operator's deployment context | Per-process (D3-EAL, D3-EHB), per-segment (D3-NTA, D3-NI), per-request (D3-CBAN, D3-MFA when continuously verified), or blanket (D3-PSEP / D3-ASLR — kernel-wide). |
|
|
139
143
|
| Zero-trust posture | computed from D3FEND description; verifies-per-request vs. trusts-after-perimeter | A control that verifies on every request (D3-MFA continuous reauth, D3-CBAN per-call) is zero-trust. A control that authenticates once and trusts thereafter (vanilla session cookies, perimeter-only D3-NI) is implicit-trust. |
|
|
140
144
|
| Framework controls partially mapped | `data/d3fend-catalog.json` `framework_controls_partially_mapped` | The framework controls that nominally cover this technique but, per `lag_notes`, fail to operationalize it at D3FEND grain. |
|
|
141
145
|
| Live-tunable vs. requires deploy | operator input, joined with `implementation_examples` | Can the control be tuned without a rolling deploy (e.g., updating a Kyverno policy) or does it require image rebuilds and reboots? |
|
|
142
146
|
|
|
143
|
-
If the operator cannot supply deployment-status data, the matrix surfaces "unknown deployment status — must verify against asset inventory before claiming coverage" and the skill flags the finding as undefended for reporting purposes.
|
|
147
|
+
If the operator cannot supply deployment-status data, the matrix surfaces "unknown deployment status — must verify against asset inventory before claiming coverage" and the skill flags the finding as undefended for reporting purposes. No fabricated deployment data.
|
|
144
148
|
|
|
145
149
|
---
|
|
146
150
|
|
|
@@ -171,7 +175,7 @@ Every D3FEND mapping must carry a **trust-posture classification**:
|
|
|
171
175
|
- **Verifies on session establishment, trusts thereafter.** Examples: vanilla TLS session resumption, perimeter D3-NI without internal traffic analysis.
|
|
172
176
|
- **Assumes implicit trust on a segment.** Examples: bare D3-NI without D3-NTA inside the segment.
|
|
173
177
|
|
|
174
|
-
Zero-trust-compliant defense maps to controls that verify per request. Implicit-trust controls are not invalid — they are layer-1 — but the output must label them so the operator can see the trust assumption a given control is making.
|
|
178
|
+
Zero-trust-compliant defense maps to controls that verify per request. Implicit-trust controls are not invalid — they are layer-1 — but the output must label them so the operator can see the trust assumption a given control is making. Never imply a framework control is adequate when current TTPs bypass it; the trust-posture column is the explicit corrective.
|
|
175
179
|
|
|
176
180
|
### Steps
|
|
177
181
|
|
|
@@ -183,7 +187,7 @@ Zero-trust-compliant defense maps to controls that verify per request. Implicit-
|
|
|
183
187
|
|
|
184
188
|
**Step 4 — Score each candidate countermeasure.** For each D3FEND ID surfaced in Step 3, record:
|
|
185
189
|
(a) Deployment status. Operator answers: deployed / partially deployed / not deployed / unknown.
|
|
186
|
-
(b) AI-pipeline applicability
|
|
190
|
+
(b) AI-pipeline applicability. Read `ai_pipeline_applicability` directly from `data/d3fend-catalog.json`. If the catalog states the control is architecturally impossible in the operator's environment, capture the explicit alternative the catalog provides.
|
|
187
191
|
(c) Defense-in-depth layer position — the D3FEND tactic the technique belongs to.
|
|
188
192
|
(d) Least-privilege scope — per-process / per-segment / per-request / blanket, per the principle 2 classification.
|
|
189
193
|
(e) Zero-trust posture — verifies-per-request / verifies-on-session / implicit-trust-on-segment, per the principle 3 classification.
|
|
@@ -274,9 +278,9 @@ The theater test for this skill is direct: the operator's defensive program is i
|
|
|
274
278
|
|
|
275
279
|
A second, complementary test:
|
|
276
280
|
|
|
277
|
-
> "Show your D3FEND coverage heatmap alongside your ATT&CK heatmap. If you have an ATT&CK heatmap (offensive coverage) but no D3FEND heatmap (defensive coverage at the same grain), your blue-team articulation is one-sided. The most common shape: ATT&CK heatmap exists, populated by EDR alerts; D3FEND heatmap does not exist; Harden, Isolate, Evict, and Restore tactics have no operator-known content. The org has bought defensive products and deployed framework controls, but cannot list which D3FEND technique each product implements.
|
|
281
|
+
> "Show your D3FEND coverage heatmap alongside your ATT&CK heatmap. If you have an ATT&CK heatmap (offensive coverage) but no D3FEND heatmap (defensive coverage at the same grain), your blue-team articulation is one-sided. The most common shape: ATT&CK heatmap exists, populated by EDR alerts; D3FEND heatmap does not exist; Harden, Isolate, Evict, and Restore tactics have no operator-known content. The org has bought defensive products and deployed framework controls, but cannot list which D3FEND technique each product implements. The framework controls are being treated as truth at a grain they do not address."
|
|
278
282
|
|
|
279
|
-
A third test, specific to AI-pipeline environments
|
|
283
|
+
A third test, specific to AI-pipeline environments:
|
|
280
284
|
|
|
281
285
|
> "Pick any AI / LLM / RAG / MCP workload in your environment. List the D3FEND controls you would deploy on an on-prem monolith for the equivalent attack surface. Now, for each, state whether the control is architecturally possible in your ephemeral/serverless/AI pipeline runtime, and if not, what the explicit alternative is per `data/d3fend-catalog.json`'s `ai_pipeline_applicability` field. If the answer is 'the framework control exists, so we are covered', the program is in theater — the framework control is architecturally impossible in the workload's runtime and the alternative was never scoped. The audit passes; the workload is undefended."
|
|
282
286
|
|
|
@@ -300,4 +304,4 @@ The cross-walks the skill maintains:
|
|
|
300
304
|
|
|
301
305
|
- **DLP / exfil → D3FEND.** Sourced from `data/dlp-controls.json`, whose entries carry a `d3fend_refs` field linking each DLP technique to the D3FEND countermeasures that detect or isolate the corresponding exfil pattern. The DLP catalog is the dedicated link for the Detect and Isolate tactics in data-loss scenarios.
|
|
302
306
|
|
|
303
|
-
When a new offensive technique is added to `data/atlas-ttps.json` or referenced in a new CVE in `data/cve-catalog.json`, the catalog steward must ensure at least one D3FEND entry covers it via `counters_attack_techniques`, or open a gap entry in `data/d3fend-catalog.json`
|
|
307
|
+
When a new offensive technique is added to `data/atlas-ttps.json` or referenced in a new CVE in `data/cve-catalog.json`, the catalog steward must ensure at least one D3FEND entry covers it via `counters_attack_techniques`, or open a gap entry in `data/d3fend-catalog.json` (no orphaned controls — by inversion, no orphaned attack techniques). This skill is the consumer that surfaces the inversion failure if the catalog drifts.
|
|
@@ -86,7 +86,7 @@ The dominant real-world exfil pattern: an engineer pastes proprietary code, cust
|
|
|
86
86
|
| NIST AI RMF MAP-4.1 / MEASURE-2.10 (referenced from `DLP-CHAN-LLM-PROMPT`, `DLP-CHAN-LLM-CONTEXT`) | AI risk identification and measurement | Identifies AI system risks and measurement criteria. | Voluntary, not auditable. Does not operationalise DLP at the prompt or retrieval boundary. |
|
|
87
87
|
| ISO 27001:2022 A.8.16 | Monitoring Activities | Monitoring of networks, systems, and applications. | Channel-agnostic in language; every implementation guide cites email/web/endpoint. No guidance for SDK-level prompt logging, MCP tool-call argument capture, or RAG retrieval audit. |
|
|
88
88
|
| ISO 27001:2022 A.5.34 (referenced from `DLP-CHAN-LLM-CONTEXT`, `DLP-CHAN-IDE-TELEMETRY`) | Privacy and Protection of PII | PII handling. | Does not address retrieval-time classification of PII in RAG corpora. |
|
|
89
|
-
| ISO/IEC 42001:2023 clause 6.1.2 | AI Risk Treatment Planning | Requires the org to plan treatments for AI risks. | Non-prescriptive on prompt-egress DLP. Auditors accept policy documents in lieu of control evidence —
|
|
89
|
+
| ISO/IEC 42001:2023 clause 6.1.2 | AI Risk Treatment Planning | Requires the org to plan treatments for AI risks. | Non-prescriptive on prompt-egress DLP. Auditors accept policy documents in lieu of control evidence — a compliance-theater risk. The real_requirement is recorded under `ISO-IEC-42001-2023-clause-6.1.2` in `data/framework-control-gaps.json`. |
|
|
90
90
|
| EU AI Act (Reg. 2024/1689) Art 10 / Art 15 | Data governance and accuracy/robustness/cybersecurity for high-risk AI | Training data governance, robustness, and cybersecurity for high-risk AI systems. | Inference-time prompt data flows are not enumerated. Cross-border transfer of prompt content interacting with EU-resident personal data is governed by GDPR Art 44, not by AI Act technical controls. |
|
|
91
91
|
| EU GDPR Art 44 | International transfers | Cross-border personal-data transfers require adequacy, SCCs, or BCRs. | Operationalised in DPIAs as "transfers to processors" — engineer-pastes-into-LLM is treated as an unsanctioned use, not as a measurable DLP event. Without prompt-egress evidence the org cannot answer a Subject Access Request asking "has my data been processed by AI." |
|
|
92
92
|
| UK Data Protection Act 2018 / UK GDPR + ICO AI guidance (Oct 2023, updated 2025) | UK transfers and AI accountability | Equivalent to EU GDPR; ICO has issued AI-specific guidance. | Same blind spot as GDPR Art 44; ICO guidance is non-statutory. |
|
|
@@ -101,7 +101,7 @@ The dominant real-world exfil pattern: an engineer pastes proprietary code, cust
|
|
|
101
101
|
| PCI-DSS 4.0 §3.4 | Cardholder-data rendering | PAN must be rendered unreadable. | Silent on PAN appearing in LLM prompts; payment org operational reality is that engineers paste prod queries containing PAN-shaped data into AI tools for debugging. |
|
|
102
102
|
| US DTSA / EU Trade Secrets Directive 2016/943 | Trade secret protection | Misappropriation remedies. | "Reasonable measures to keep secret" is the eligibility test. Pasting trade secrets into a third-party LLM that retains them for abuse monitoring can disqualify trade-secret status in subsequent litigation. No technical control named — purely a downstream legal-eligibility risk. |
|
|
103
103
|
|
|
104
|
-
**Bottom line:** no compliance framework operationalises LLM-prompt, MCP-tool-arg, RAG-retrieval, embedding-store, or code-completion-context DLP as a required, auditable, technically prescriptive control. Compliance evidence based purely on legacy SC-7, AC-2, A.8.16, or §164.312 for AI-era DLP is theater
|
|
104
|
+
**Bottom line:** no compliance framework operationalises LLM-prompt, MCP-tool-arg, RAG-retrieval, embedding-store, or code-completion-context DLP as a required, auditable, technically prescriptive control. Compliance evidence based purely on legacy SC-7, AC-2, A.8.16, or §164.312 for AI-era DLP is theater.
|
|
105
105
|
|
|
106
106
|
### Expanded jurisdictional coverage (per `data/global-frameworks.json`)
|
|
107
107
|
|
|
@@ -210,7 +210,7 @@ A gap exists where:
|
|
|
210
210
|
- A control depends on SDK-level prompt logging that is not enabled (cascading dependency failure).
|
|
211
211
|
- A control depends on retrieval-time classification on a RAG corpus where labels have not propagated (cascading dependency failure).
|
|
212
212
|
|
|
213
|
-
Score each gap using the RWEP model in `lib/scoring.js`. Inputs: KEV / known-exploitation evidence (use the Exploit Availability Matrix above), AI-acceleration flag (yes for every modern channel), blast radius (per-identity vs. enterprise-wide), patch availability (architectural — not patchable, only mitigable). Output RWEP per gap. Never report a gap with CVSS alone
|
|
213
|
+
Score each gap using the RWEP model in `lib/scoring.js`. Inputs: KEV / known-exploitation evidence (use the Exploit Availability Matrix above), AI-acceleration flag (yes for every modern channel), blast radius (per-identity vs. enterprise-wide), patch availability (architectural — not patchable, only mitigable). Output RWEP per gap. Never report a gap with CVSS alone — RWEP is the prioritization signal, with CVSS reported alongside but never as the sole input.
|
|
214
214
|
|
|
215
215
|
**Step 6 — Propose layered controls per the defense-in-depth ladder.**
|
|
216
216
|
|
|
@@ -54,7 +54,7 @@ d3fend_refs:
|
|
|
54
54
|
- D3-IOPR
|
|
55
55
|
- D3-MFA
|
|
56
56
|
last_threat_review: "2026-05-18"
|
|
57
|
-
discovery_mode: "standalone" #
|
|
57
|
+
discovery_mode: "standalone" # operator-reached via `exceptd brief email-security-anti-phishing` or `exceptd ask`; not chained into any playbook's direct.skill_chain by design
|
|
58
58
|
---
|
|
59
59
|
|
|
60
60
|
# Email Security and Anti-Phishing Assessment
|
|
@@ -95,7 +95,7 @@ Phishing remained the #1 initial-access vector through 2025 (Verizon DBIR 2025)
|
|
|
95
95
|
| IN CERT-In | Phishing guidance and 6-hour incident reporting rule | Reporting requirement is firm; control specifications lag. |
|
|
96
96
|
| NYDFS | 23 NYCRR 500.14 (training and monitoring) | Annual phishing-aware training required; does not specify FIDO2, DMARC `p=reject`, or deepfake-aware procedures. |
|
|
97
97
|
|
|
98
|
-
|
|
98
|
+
This analysis spans EU + UK + AU + JP + IL + SG + IN + NYDFS alongside NIST and ISO, because a US-only email-security posture is incomplete for any multi-jurisdiction sender. Each framework-gap ID in `framework_gaps` (`NIST-800-53-SI-3`, `ISO-27001-2022-A.8.16`, `SOC2-CC7-anomaly-detection`, `NIS2-Art21-incident-handling`, `UK-CAF-C1`, `AU-Essential-8-App-Hardening`) resolves against `data/framework-control-gaps.json` — operators producing a per-control evidence pack should pull the canonical lag rationale from that catalog rather than transcribing the table above.
|
|
99
99
|
|
|
100
100
|
---
|
|
101
101
|
|
|
@@ -122,7 +122,7 @@ Note: `atlas_refs` is intentionally empty — these are ATT&CK Enterprise TTPs a
|
|
|
122
122
|
| Voice cloning | Commodity | ElevenLabs and similar have anti-abuse, but underground forks and self-hosted open-weights models remove the guardrails. ~3 seconds of audio suffices. |
|
|
123
123
|
| Real-time deepfake video | Live | DeepFaceLab plus real-time variants; single-GPU; demonstrated at scale by the Arup 2024 incident. |
|
|
124
124
|
| LLM-generated hyperpersonalized email | Live | All major LLM providers run abuse-detection on the email-generation surface; jailbreak-augmented intermediaries route around it. |
|
|
125
|
-
| AI-discovered novel evasion | Active |
|
|
125
|
+
| AI-discovered novel evasion | Active | AI acceleration of attacker tooling is current operational reality, not future-watch. |
|
|
126
126
|
| Phishing-resistant defense | Available now | FIDO2 / WebAuthn synced passkeys = the only authenticator class that survives 2026 phishing kits. CISA Phishing-Resistant MFA guidance + NIST 800-63B rev 4 codify this. |
|
|
127
127
|
| DMARC `p=reject` adoption | Universal at large senders, ~60% enforced | Adoption metric is misleading; enforcement metric is the real KPI. |
|
|
128
128
|
| ARC for forwarders | Maturing across major providers | Closes the mailing-list-breaks-DMARC objection that kept many domains at `p=none`. |
|
|
@@ -134,7 +134,7 @@ No CVE entries are claimed for this skill — email-channel social engineering i
|
|
|
134
134
|
|
|
135
135
|
## Analysis Procedure
|
|
136
136
|
|
|
137
|
-
The procedure threads three foundational principles
|
|
137
|
+
The procedure threads three foundational principles:
|
|
138
138
|
|
|
139
139
|
**Defense in depth** — inbound: DMARC enforcement (`p=reject`) + ARC for forwarders + secure email gateway (Proofpoint, Mimecast, Microsoft Defender for Office 365, Google Workspace Gmail Advanced Protection) + URL rewriting + sandbox detonation + DLP egress. Outbound: DKIM signing on all sending sources + BIMI registration + SPF maintenance with SPF-record-flattening discipline (10-DNS-lookup ceiling). User layer: phishing-resistant MFA (passkeys), simulated phishing program including AI-augmented lures, deepfake-aware policies for video and voice. Vendor layer: fourth-party email risk — supplier DMARC posture monitored as a vendor-risk attribute. Incident layer: BEC IR playbook with explicit hand-off to `incident-response-playbook`.
|
|
140
140
|
|
|
@@ -142,7 +142,7 @@ The procedure threads three foundational principles per AGENTS.md:
|
|
|
142
142
|
|
|
143
143
|
**Zero trust** — every email is hostile until verified (DMARC pass + sender reputation + intent classification at gateway). Every video call requesting a financial action requires a live verification challenge (callback to a known number; pre-arranged challenge phrase; in-person or known-good-channel confirmation for high-value transactions). Every voice call from a "known" executive requesting an out-of-policy action gets multi-channel verification before action.
|
|
144
144
|
|
|
145
|
-
**Cloud-email canonical, on-prem exception
|
|
145
|
+
**Cloud-email canonical, on-prem exception:** default scoping assumes Microsoft 365 Exchange Online or Google Workspace Gmail. On-prem Exchange (legacy, regulated enclave, air-gapped) gets an explicit exception path noting which controls (cloud-native sandbox detonation, Microsoft Defender XDR signals, Google Workspace Security Sandbox) have on-prem equivalents and which require compensating controls.
|
|
146
146
|
|
|
147
147
|
Email-authentication RFCs cited throughout the procedure (`RFC-7489` DMARC, `RFC-6376` DKIM, `RFC-7208` SPF, `RFC-8616` BIMI/AuthIndicators DNS encoding, `RFC-8461` MTA-STS, `RFC-8617` ARC, `RFC-8460` TLSRPT) resolve against `data/rfc-references.json`. The DLP exfil-channel mappings invoked by the gateway-and-egress sub-procedures (`DLP-CHAN-EMAIL-OUT` for outbound message exfil, `DLP-CHAN-LLM-PROMPT` for LLM-prompt-as-egress when users paste mailbox content into AI assistants, `DLP-ENFORCE-BLOCK` for hard-block enforcement on confirmed PHI/PCI patterns) resolve against `data/dlp-controls.json` — these are the canonical IDs to cite when handing off to `dlp-gap-analysis`.
|
|
148
148
|
|
|
@@ -191,7 +191,7 @@ Four concrete tests distinguish paper compliance from real anti-phishing posture
|
|
|
191
191
|
|
|
192
192
|
## Defensive Countermeasure Mapping
|
|
193
193
|
|
|
194
|
-
|
|
194
|
+
This section maps offensive findings to MITRE D3FEND defensive techniques.
|
|
195
195
|
|
|
196
196
|
| D3FEND ID | Defense | Defense-in-Depth Layer | Least-Privilege Scope | Zero-Trust Posture | AI-Pipeline Applicability |
|
|
197
197
|
|---|---|---|---|---|---|
|
|
@@ -42,7 +42,7 @@ The `atlas_refs` and `attack_refs` arrays are intentionally empty. This skill is
|
|
|
42
42
|
|
|
43
43
|
RWEP exists because the exploit development cycle has compressed. The factors that CVSS does not model are now the dominant signal in real-world prioritization.
|
|
44
44
|
|
|
45
|
-
- **AI-accelerated exploit development is current operational reality, not emerging.** 41% of 2025 zero-days were discovered or weaponized with AI-assisted tooling (
|
|
45
|
+
- **AI-accelerated exploit development is current operational reality, not emerging.** 41% of 2025 zero-days were discovered or weaponized with AI-assisted tooling (GTIG 2025). Copy Fail (CVE-2026-31431) was discovered by an AI system in approximately one hour; Fragnesia (CVE-2026-46300, 2026-05-13) is the 2026 anchor case for autonomous agentic-AI discovery — Zellic's agentic auditor surfaced an 18-year-old Linux kernel primitive. The first documented AI-built in-the-wild zero-day landed 2026-05-11 (GTIG AI 2FA-bypass). CVSS scoring assumes a human-speed gap between disclosure and reliable exploitation — that gap is gone for AI-capable threat actors. RWEP's `ai_factor` weight is calibrated to this reality; align downstream scoring narratives to CTID Secure AI v2 (2026-05-06, replaces v1).
|
|
46
46
|
- **CVSS undercounts AI-discovered + KEV-listed bugs.** CVE-2026-31431 scores CVSS 7.8 (High). Treated as a CVSS-band-7 item, it lands in a 30-day remediation queue. Treated honestly — CISA KEV listed, 732-byte deterministic public PoC, all Linux ≥ 4.14, AI-discovered — it is a 4-hour incident. CVSS misses every one of those amplifiers.
|
|
47
47
|
- **CVSS local-vector blindness vs. RWEP exploitation reality.** CVE-2026-30615 (Windsurf MCP) scores CVSS 8.0 with AV:L (the NVD-authoritative corrected score; the initial CVSS 9.8 was withdrawn after attack-vector analysis confirmed the local-vector reality — the attacker must control HTML content that the Windsurf MCP client processes). RWEP rates it 35, lower than Copy Fail at 90: the supply-chain prerequisite (a victim first installs a malicious MCP server) plus the local attack vector throttle real exploitation rate. This pair is the canonical example of CVSS-vector-only scoring losing to RWEP's exploitation-evidence weighting.
|
|
48
48
|
- **Compliance frameworks anchor SLAs on CVSS bands.** NIST 800-53 SI-2, PCI DSS 6.3.3, ISO 27001:2022 A.8.8, and most internal vuln-management policies translate CVSS High/Critical into 30-day/7-day windows. For AI-discovered KEV-listed LPEs with public PoCs, these windows are exploitation windows. RWEP is the layer that lets an org prioritize honestly without re-writing every framework control.
|
|
@@ -387,4 +387,4 @@ RWEP scores priority; this section maps the priority bands to the D3FEND defensi
|
|
|
387
387
|
|
|
388
388
|
**Zero-trust posture:** an RWEP score is not a remediation; it is a triage signal. The remediation closes only when the cited D3FEND technique is verified in production for the affected asset class. RWEP 90 with no deployed `D3-KBPI` instrumentation is an unmitigated finding regardless of patch SLA. Auditors converting RWEP findings into corrective actions must verify both the patch deployment and the compensating-technique deployment.
|
|
389
389
|
|
|
390
|
-
**AI-pipeline applicability
|
|
390
|
+
**AI-pipeline applicability:** for AI-pipeline CVEs (model-serving runtime, MCP server, inference gateway), `D3-KBPI` and `D3-EAL` do not apply to serverless inference endpoints. The scoped alternative is `D3-CSPP` at the gateway plus signed-image attestation at the provider. RWEP bands are unchanged; the technique selection shifts to the gateway tier. `D3-FAPA` over training-data corpora is the additional technique for any AML.T0020 (Poison Training Data) finding above RWEP 50.
|
|
@@ -47,7 +47,7 @@ This skill's entire purpose is to declare framework lag per analysis. The pre-an
|
|
|
47
47
|
|
|
48
48
|
### Expanded jurisdictional cross-walk requirement (per `data/global-frameworks.json`)
|
|
49
49
|
|
|
50
|
-
|
|
50
|
+
The global-first requirement binds against the full expanded catalog, not the EU+UK+AU+ISO baseline. Every gap declaration produced by this skill must cross-walk the cited control against the equivalent obligations in the expanded jurisdiction set tracked in `data/global-frameworks.json`. The cross-walk set as of mid-2026:
|
|
51
51
|
|
|
52
52
|
- **EU:** GDPR, NIS2 (Directive 2022/2555), DORA (Regulation 2022/2554), EU AI Act (Regulation 2024/1689), EU CRA (Regulation 2024/2847).
|
|
53
53
|
- **UK:** UK GDPR / DPA 2018, NCSC CAF, Cyber Essentials / CE+.
|
|
@@ -69,7 +69,7 @@ AGENTS.md hard rule #5 (global-first) now binds against the full expanded catalo
|
|
|
69
69
|
- **Global standards:** ISO 27001:2022 / 27002:2022, ISO/IEC 42001:2023, CSA CCM v4, CIS Controls v8, MITRE ATLAS v5.6.0.
|
|
70
70
|
- **US sub-national:** NYDFS 23 NYCRR 500 (amended Nov 2023, phased through Nov 2025); state privacy laws (CA CCPA/CPRA, CO CPA, CT CTDPA, IL BIPA, NY SHIELD, TX DPSA, VA CDPA).
|
|
71
71
|
|
|
72
|
-
A gap declaration that closes section 6 (Global coverage check) without referencing at least the EU, UK, AU, ISO, and a representative selection from {IL, CH, HK, TW, ID, VN, JP-expanded, KR, CN, BR, NYDFS} for any org operating in those jurisdictions
|
|
72
|
+
A gap declaration that closes section 6 (Global coverage check) without referencing at least the EU, UK, AU, ISO, and a representative selection from {IL, CH, HK, TW, ID, VN, JP-expanded, KR, CN, BR, NYDFS} for any org operating in those jurisdictions is incomplete: a global-first analysis must cover every applicable jurisdiction, not a US-centric subset. The exact set required depends on the org's footprint — but the analyst must consult `data/global-frameworks.json` to enumerate it rather than defaulting to the legacy four-jurisdiction shorthand.
|
|
73
73
|
|
|
74
74
|
## TTP Mapping (MITRE ATLAS v5.6.0 and ATT&CK)
|
|
75
75
|
|
|
@@ -88,7 +88,7 @@ This skill maps framework controls to attacker TTPs on demand rather than static
|
|
|
88
88
|
| NIS2 Art. 21 vs. AI pipeline integrity | AML.T0020 (Poison Training Data), AML.T0010 | No AI-specific control surface |
|
|
89
89
|
| All frameworks vs. ephemeral inventory | T1610, T1525 | Asset-inventory assumption invalid on serverless/container |
|
|
90
90
|
|
|
91
|
-
For any gap analysis this skill produces, every cited control must be paired with at least one ATLAS or ATT&CK ID drawn from `data/atlas-ttps.json`. Controls without a mapped TTP
|
|
91
|
+
For any gap analysis this skill produces, every cited control must be paired with at least one ATLAS or ATT&CK ID drawn from `data/atlas-ttps.json`. Controls without a mapped TTP are orphaned controls and are rejected — every control recommendation must map to a real ATLAS or ATT&CK TTP.
|
|
92
92
|
|
|
93
93
|
## Exploit Availability Matrix
|
|
94
94
|
|
|
@@ -316,7 +316,7 @@ These universal gaps should be surfaced in every framework gap analysis and expl
|
|
|
316
316
|
|
|
317
317
|
## Output Format
|
|
318
318
|
|
|
319
|
-
Every framework gap analysis this skill produces uses the following literal template. Sections are mandatory; empty sections
|
|
319
|
+
Every framework gap analysis this skill produces uses the following literal template. Sections are mandatory; empty sections are not acceptable — every section must be populated.
|
|
320
320
|
|
|
321
321
|
```
|
|
322
322
|
## Framework Lag Declaration
|
|
@@ -350,7 +350,7 @@ finding and should be surfaced to the compliance-theater skill.]
|
|
|
350
350
|
|
|
351
351
|
### 6. Global coverage check
|
|
352
352
|
[EU (NIS2/DORA/EU AI Act), UK (CAF), AU (ISM/Essential 8), ISO 27001:2022, and
|
|
353
|
-
NIST equivalents for the same lag.
|
|
353
|
+
NIST equivalents for the same lag. US-only output is incomplete.]
|
|
354
354
|
```
|
|
355
355
|
|
|
356
356
|
The output is consumed by: compliance-theater (theater scoring), policy-exception-gen (compensating-control justification), and global-grc (cross-jurisdictional rollup).
|
|
@@ -406,4 +406,4 @@ Every Framework Lag Declaration this skill produces names the missing control. T
|
|
|
406
406
|
|
|
407
407
|
**Zero-trust posture:** no control is claimed as compensating without verification that the defensive technique is deployed, monitored, and tested against the cited offensive TTP. "We have SC-8 IPsec" is not a compensating control for Dirty Frag — `D3-NI` over a non-IPsec data path is. The Framework Lag Declaration's "What a real control requires" field must name the D3FEND technique by ID.
|
|
408
408
|
|
|
409
|
-
**AI-pipeline applicability
|
|
409
|
+
**AI-pipeline applicability:** `D3-EAL` does not apply to serverless inference endpoints; the scoped alternative is `D3-CSPP` at the gateway plus signed-image attestation at the provider. `D3-FAPA` on ephemeral RAG indices degrades to per-query retrieval logging via `D3-IOPR` plus index-build provenance signed at construction. These degradations must be named explicitly in the declaration when the gap concerns an AI pipeline.
|
|
@@ -45,7 +45,7 @@ d3fend_refs:
|
|
|
45
45
|
- D3-IOPR
|
|
46
46
|
- D3-PSEP
|
|
47
47
|
last_threat_review: "2026-05-11"
|
|
48
|
-
discovery_mode: "standalone" #
|
|
48
|
+
discovery_mode: "standalone" # operator-reached via `exceptd brief fuzz-testing-strategy` or `exceptd ask`; not chained into any playbook's direct.skill_chain by design
|
|
49
49
|
---
|
|
50
50
|
|
|
51
51
|
# Fuzz Testing Strategy
|
|
@@ -442,7 +442,7 @@ Universal lag: every jurisdiction except Australia (ISM-1623) lacks an operation
|
|
|
442
442
|
- **Brazil (LGPD Art. 33-35):** Cross-border transfer requires adequacy decision, SCCs, BCRs, or specific consent; ANPD has signalled AI-tool enforcement interest under LGPD Art. 33.
|
|
443
443
|
- **US sub-national — NYDFS 23 NYCRR 500 (amended Nov 2023, phased through Nov 2025):** 72-hour cyber-event notification to DFS, CISO accountability, MFA mandate, annual independent audit for Class A companies, Third-Party Service Provider Security Policy at 500.11. NYDFS is the strictest US sub-national financial-sector regime and operationally exceeds most state-level analogues.
|
|
444
444
|
|
|
445
|
-
|
|
445
|
+
The global-grc analysis must cross-walk against the full catalog above, not just EU/UK/AU/ISO — a global-first rollup covers every applicable jurisdiction, not a US-centric subset. A jurisdictional rollup that omits CN, VN, IL, CH, HK, TW, ID, JP-expanded, KR, BR, or NYDFS for an in-scope org is structurally incomplete.
|
|
446
446
|
|
|
447
447
|
---
|
|
448
448
|
|
|
@@ -542,7 +542,7 @@ Produce a matrix of: threat class × jurisdiction framework × requirement adequ
|
|
|
542
542
|
|
|
543
543
|
## Output Format
|
|
544
544
|
|
|
545
|
-
The skill produces a structured Global GRC Assessment that rolls compliance findings across the org's jurisdictional footprint — EU (NIS2, DORA, EU AI Act, CRA), UK (CAF, Cyber Essentials), AU (ISM, Essential 8, APRA CPS 234), ISO 27001:2022 / 42001:2023, NIST, and the expanded set tracked in `data/global-frameworks.json`. The shape below is consumed downstream by `framework-gap-analysis` (which produces per-jurisdiction Framework Lag Declarations), by `policy-exception-gen` (for cross-jurisdictional exception language), and by CSAF-style auditor evidence bundles. Preserve the per-jurisdiction control-mapping rows verbatim — they are the load-bearing cross-walk
|
|
545
|
+
The skill produces a structured Global GRC Assessment that rolls compliance findings across the org's jurisdictional footprint — EU (NIS2, DORA, EU AI Act, CRA), UK (CAF, Cyber Essentials), AU (ISM, Essential 8, APRA CPS 234), ISO 27001:2022 / 42001:2023, NIST, and the expanded set tracked in `data/global-frameworks.json`. The shape below is consumed downstream by `framework-gap-analysis` (which produces per-jurisdiction Framework Lag Declarations), by `policy-exception-gen` (for cross-jurisdictional exception language), and by CSAF-style auditor evidence bundles. Preserve the per-jurisdiction control-mapping rows verbatim — they are the load-bearing global-first cross-walk.
|
|
546
546
|
|
|
547
547
|
```
|
|
548
548
|
## Global GRC Assessment
|
|
@@ -67,7 +67,7 @@ Identity is the new perimeter, and the perimeter expanded. The 2026 principal po
|
|
|
67
67
|
|
|
68
68
|
**Agent-as-principal is operational reality.** When an AI coding assistant calls an MCP tool, it does so under the IDE user's OAuth session by default. The agent inherits the user's scopes wholesale — not because anyone designed it that way, but because no current identity standard defines an agent-as-principal model. CVE-2026-30615 (Windsurf MCP local-vector RCE, CVSS 8.0 / AV:L) hinged in part on this implicit inheritance: tool calls executed under the IDE user's privileges with no separate authentication challenge for the agent's actions. The principal who authenticated (the human) is not the principal who took the action (the agent), and the audit trail does not distinguish them.
|
|
69
69
|
|
|
70
|
-
**Phishing-resistant authentication is now table-stakes.** FIDO2 / WebAuthn synced passkeys are the only widely deployed authenticator class that survives credential phishing, AiTM proxy phishing (evilginx-class), and push-notification fatigue attacks. Orgs still standing on TOTP / SMS / push-MFA in 2026 are shipping password-equivalent risk forward, and the framework gap analysis must say so. AI-assisted phishing kit development means the time-to-weaponize a new bypass technique is hours, not weeks
|
|
70
|
+
**Phishing-resistant authentication is now table-stakes.** FIDO2 / WebAuthn synced passkeys are the only widely deployed authenticator class that survives credential phishing, AiTM proxy phishing (evilginx-class), and push-notification fatigue attacks. Orgs still standing on TOTP / SMS / push-MFA in 2026 are shipping password-equivalent risk forward, and the framework gap analysis must say so. AI-assisted phishing kit development means the time-to-weaponize a new bypass technique is hours, not weeks — AI acceleration is current operational reality, not a future consideration.
|
|
71
71
|
|
|
72
72
|
**Workload identity is short-lived or it is broken.** Static service-account keys and long-lived OAuth refresh tokens are credential-theft jackpots. RFC 9700 (OAuth 2.0 Security Best Current Practice, January 2025) replaces the original RFC 6749 threat model and assumes short-lived access tokens, sender-constrained tokens (DPoP / mTLS), and rotated refresh tokens. Skills that cite RFC 6749 without RFC 9700 are citing the wrong threat model.
|
|
73
73
|
|
|
@@ -135,7 +135,7 @@ Sourced from `data/cve-catalog.json` and `data/exploit-availability.json` as of
|
|
|
135
135
|
|
|
136
136
|
## Analysis Procedure
|
|
137
137
|
|
|
138
|
-
This procedure threads the three foundational principles explicitly
|
|
138
|
+
This procedure threads the three foundational principles explicitly.
|
|
139
139
|
|
|
140
140
|
### Defense in Depth (multi-layer identity controls)
|
|
141
141
|
|
|
@@ -247,13 +247,13 @@ Four specific tests distinguish paper compliance from real posture:
|
|
|
247
247
|
|
|
248
248
|
3. **MCP / agent access token TTL.** "Show me the access-token TTL configured for your MCP server fleet and AI-agent integrations. Show me the refresh-token rotation policy." If access-token TTLs are measured in weeks, or are unconfigured / default-1-year-from-the-SDK, or refresh tokens are never rotated, this is theater against RFC 9700 BCP. The credential-theft blast radius is multiplied by the TTL.
|
|
249
249
|
|
|
250
|
-
4. **Cross-jurisdiction evidence.** "Show me your jurisdiction-specific identity-control evidence for every jurisdiction you operate in: EU NIS2 Art 21 transposition, DORA RTS, UK CAF B2, AU ISM 0974+, ISO 27001 A.5.16; plus IL INCD Doctrine 2.0 / Cyber Defense Methodology 2024, CH FINMA Circ. 2023/1, JP FISC v9, SG MAS TRM §11/§14.2, IN CERT-In Directions, NY DFS 23 NYCRR 500.12." US-only evidence (or worse, NIST-only evidence) for a multi-jurisdictional org is theater
|
|
250
|
+
4. **Cross-jurisdiction evidence.** "Show me your jurisdiction-specific identity-control evidence for every jurisdiction you operate in: EU NIS2 Art 21 transposition, DORA RTS, UK CAF B2, AU ISM 0974+, ISO 27001 A.5.16; plus IL INCD Doctrine 2.0 / Cyber Defense Methodology 2024, CH FINMA Circ. 2023/1, JP FISC v9, SG MAS TRM §11/§14.2, IN CERT-In Directions, NY DFS 23 NYCRR 500.12." US-only evidence (or worse, NIST-only evidence) for a multi-jurisdictional org is theater — global-first coverage is required, and identity evidence must be jurisdiction-specific rather than US-centric.
|
|
251
251
|
|
|
252
252
|
---
|
|
253
253
|
|
|
254
254
|
## Defensive Countermeasure Mapping
|
|
255
255
|
|
|
256
|
-
Maps the identity-assurance gaps above to MITRE D3FEND techniques with explicit defense-in-depth layer position, least-privilege scope, zero-trust posture, and AI-pipeline applicability
|
|
256
|
+
Maps the identity-assurance gaps above to MITRE D3FEND techniques with explicit defense-in-depth layer position, least-privilege scope, zero-trust posture, and AI-pipeline applicability.
|
|
257
257
|
|
|
258
258
|
| D3FEND Technique | Mapping | Defense-in-Depth Layer | Least-Privilege Scope | Zero-Trust Posture | AI-Pipeline Applicability |
|
|
259
259
|
|---|---|---|---|---|---|
|
|
@@ -274,4 +274,4 @@ After producing the identity assurance assessment output, chain into the followi
|
|
|
274
274
|
- **`supply-chain-integrity`** — signed identity artefacts. Federation assertion signing keys, OIDC discovery documents, JWKS endpoints, agent SDK binaries, and MCP server packages are all supply-chain artefacts. Run supply-chain-integrity to produce SLSA-level attestation, Sigstore signature verification, and in-toto provenance for the identity artefacts in this skill's federation-surface inventory.
|
|
275
275
|
- **`compliance-theater`** — paper-MFA theater. If the phishing-resistant coverage matrix in this skill's output shows < 100% phishing-resistant coverage for privileged users while the org's compliance attestations claim MFA-for-all, run compliance-theater for the full structured theater-vs-real-posture report tied to the specific audit reports (SOC 2, ISO, NIS2 conformity) being misrepresented.
|
|
276
276
|
|
|
277
|
-
For ephemeral / serverless / AI-pipeline contexts
|
|
277
|
+
For ephemeral / serverless / AI-pipeline contexts: interactive AAL3 authentication is architecturally impossible inside a serverless function or short-lived container. The scoped alternative is workload-identity-federation (SPIFFE/SPIRE, AWS IAM Roles Anywhere, GCP WIF, Azure Workload Identity) with sender-constrained short-lived tokens (DPoP per RFC 9449 or mTLS per RFC 8705), build-time agent-binary allowlisting baked into the function image, and per-invocation cryptographic device attestation where the platform supports it.
|
|
@@ -118,7 +118,7 @@ Agentic AI is the emerging structural problem on top. AI agents operating on beh
|
|
|
118
118
|
| US Treasury OFAC + EU + UK sanctions | Cyber-Related Sanctions program (EO 13694 + 13757 + EU Reg.269/2014 + UK OFSI) | Prohibits transactions with designated cyber-actors | Captured in `data/framework-control-gaps.json#OFAC-Sanctions-Threat-Actor-Negotiation`. IdP-incident-response that escalates to ransomware faces ransom-payment-vs-sanctions screening under time pressure; attribution-to-designated-entity is rarely deterministic during an active incident. |
|
|
119
119
|
| HIPAA | 164.308(a)(4) (Information Access Management) + 164.312(d) (Person or Entity Authentication) | Access-authorisation policies + entity authentication | Treats the authenticated session as the access boundary; OAuth-consent-mediated scope grant to a third-party app processing PHI is invisible. |
|
|
120
120
|
|
|
121
|
-
**Cross-jurisdiction posture
|
|
121
|
+
**Cross-jurisdiction posture.** Any IdP-incident-response analysis for a multi-jurisdiction tenant must cite at minimum: EU NIS2 + DORA + GDPR (Art.33 and Art.34) + national overlays, UK GDPR + NCSC CAF, AU Privacy Act NDB + APRA CPS 234 (where applicable) + Essential 8 + ISM, US NYDFS 500 + state breach-notification laws + sector-specific (HIPAA for healthcare, GLBA + NYDFS for financial), Canada PIPEDA + OSFI B-13 (where applicable), Singapore PDPA + MAS Notice 655, Hong Kong PDPO + HKMA guidance, ISO/IEC 27001:2022, SOC 2, and the OFAC + EU + UK sanctions overlay for any ransomware-bridging incident. US-only (NIST + NYDFS + state laws) is incomplete.
|
|
122
122
|
|
|
123
123
|
---
|
|
124
124
|
|
|
@@ -153,13 +153,13 @@ Agentic AI is the emerging structural problem on top. AI agents operating on beh
|
|
|
153
153
|
| CVE-2023-3519 Citrix NetScaler RCE | 9.8 | 92 | Yes | Yes | No | Confirmed exploitation 2023-2024 (financial-sector and federal targets) | Yes | Limited — appliance reboot | Network telemetry + IdP-tenant access-pattern alerting |
|
|
154
154
|
| CVE-2026-30615 Windsurf MCP — adjacent identity surface | 8.6 | 88 | Forward-watched | Yes | Yes | Suspected | Mitigation + vendor patch | n/a | MCP-tool-trust telemetry |
|
|
155
155
|
|
|
156
|
-
**Honest gap statement
|
|
156
|
+
**Honest gap statement.** IdP-specific CVEs (Okta Auth0 Workforce CVEs, Entra ID Graph CVEs, Auth0 platform CVEs, Ping platform CVEs, OneLogin platform CVEs) are not exhaustively inventoried in `data/cve-catalog.json`. Authoritative sources: vendor advisories (Okta Security, Microsoft MSRC + Security Update Guide, Auth0 Security Advisories, Ping Identity Security Notices, One Identity Customer Advisory), CISA KEV for cross-sector exposure, CISA AA24 series for federal-targeting advisories, and sector intel feeds. Forward-watched.
|
|
157
157
|
|
|
158
158
|
---
|
|
159
159
|
|
|
160
160
|
## Analysis Procedure
|
|
161
161
|
|
|
162
|
-
This procedure threads the three foundational design principles
|
|
162
|
+
This procedure threads the three foundational design principles (defense in depth, least privilege, zero trust) through the seven-phase loop.
|
|
163
163
|
|
|
164
164
|
**Defense in depth.** Multi-layer authentication for tenant-admin operations: phishing-resistant FIDO2 device-bound passkey at the human layer (skill `identity-assurance`); paired-admin (4-eyes) on federated-trust modification, signing-key rotation, and tenant-wide application permission grants; conditional access requiring known-device + corporate-network + step-up on privileged-role assignment; out-of-band notification on every consent grant for high-risk scope; continuous audit-log alerting on every IdP control-plane operation; downstream-SaaS telemetry for token-use anomalies.
|
|
165
165
|
|
|
@@ -316,7 +316,7 @@ Pull the conditional-access policy targeting admin roles and list every IP range
|
|
|
316
316
|
|
|
317
317
|
## Defensive Countermeasure Mapping
|
|
318
318
|
|
|
319
|
-
|
|
319
|
+
Maps IdP-tenant compromise findings to MITRE D3FEND IDs from `data/d3fend-catalog.json`, with explicit defense-in-depth layer position, least-privilege scope, zero-trust posture, and AI-pipeline applicability.
|
|
320
320
|
|
|
321
321
|
| D3FEND ID | Technique | Layer Position | Least-Privilege Scope | Zero-Trust Posture | AI-Pipeline Applicability |
|
|
322
322
|
|---|---|---|---|---|---|
|
|
@@ -325,7 +325,7 @@ Per AGENTS.md optional 8th section (required for skills shipped on or after 2026
|
|
|
325
325
|
| D3-NTA | Network Traffic Analysis | IdP audit-log telemetry as authoritative source of control-plane operations; downstream-SaaS audit-log telemetry as primary detection when IdP itself is suspect; help-desk-system audit telemetry; IaC + CI configuration scanning for embedded management-API tokens | SOC-aggregated visibility; per-tenant alerting on consent-grant + federation-modification + privileged-role-assignment + break-glass-authentication events | Audit-log alerting continuous, not periodic; SLA on every IdP control-plane operation; downstream-SaaS audit logs treated as primary when IdP is compromised | Applicable. AI-agent traffic monitoring is the specific gap: AI-channel egress (LLM API egress with embedded tenant credentials) is a separate exfiltration path. |
|
|
326
326
|
| D3-IOPR | Input / Output Pattern Recognition | Authentication-event pattern analysis (impossible-travel, anomalous source-IP, anomalous user-agent); OAuth-app behavioural baseline (typical scope use, typical request pattern); session-token behavioural baseline | Per-user authentication-pattern detection; per-app OAuth-behavioural baseline; per-service-account authentication-pattern baseline | Every authentication outcome verified against historical norm; OAuth-app behavioural drift treated as compromise signal; help-desk-mediated factor swap requires out-of-band identity verification | Critical. AI-agent authentication patterns (sustained API token use, broad scope queries, high-velocity calls) are themselves a detection signal; OAuth grants to AI agents require per-grant behavioural baselining. |
|
|
327
327
|
|
|
328
|
-
**AI-pipeline-specific posture
|
|
328
|
+
**AI-pipeline-specific posture.** Conventional D3-MFA cannot apply to AI agents holding session credentials on behalf of users — there is no agent-side biometric inherence factor, and possession factors reduce to API-key custody. The AI-pipeline-appropriate construct is: scoped delegated-authority attestation + per-grant business-purpose attestation + continuous behavioural baselining (D3-IOPR) + out-of-band confirmation for any tenant-control-plane operation requested by an AI agent. Skill `identity-assurance` covers AAL/IAL/FAL constructs for human-side authentication; this skill covers the IdP-tenant-control-plane framing of the agent-side gap.
|
|
329
329
|
|
|
330
330
|
---
|
|
331
331
|
|
|
@@ -128,7 +128,7 @@ This skill is response-shaped — the TTPs below name the incident classes the p
|
|
|
128
128
|
| **AML.T0017** | Discover ML Model Ontology | Adversary mapping of deployed model family, system-prompt structure, guardrails, and training-data signal — precursor to extraction and adversarial-input crafting | Identification: anomalous inference-API usage patterns (high-volume queries, structured probing, membership-inference signatures, repeated training-data extraction prompts). Containment: rate-limit + API-key revocation + IP block. Eradication: identify attacker access surface; assess what model-ontology data was exposed. Recovery: re-key, consider model-rotation if proprietary weights are at risk; for training-data exfiltration consider differential-privacy retraining. | No standardized detection signatures; org must build custom telemetry over AI inference APIs. |
|
|
129
129
|
| **AML.T0051** | LLM Prompt Injection | Prompt-injection breach as incident trigger | Identification: AI-assistant or agentic-system anomalous action (unauthorized data access, anomalous tool invocation, identity-context confusion). Containment: revoke AI-system tool scopes, disable agent autonomy, isolate affected RAG corpus. Eradication: identify injection vector (web content, email signature, document metadata, RAG corpus poisoning) and remove. Recovery: re-deploy with hardened system prompt + tool-scoping per `mcp-agent-trust`. | Detection lags; most orgs discover the incident from downstream effect (unauthorized action) rather than detection at the prompt boundary. |
|
|
130
130
|
|
|
131
|
-
ATLAS pinned to v5.6.0 (May 2026)
|
|
131
|
+
ATLAS pinned to v5.6.0 (May 2026). ATT&CK pinned to v19.0 (April 2026); the Defense Evasion (TA0005) split into Stealth (TA0005) and Defense Impairment (TA0112) is traced via `tactic_moved_from` on affected `data/attack-techniques.json` entries and does not introduce breaking changes for the T-IDs cited above.
|
|
132
132
|
|
|
133
133
|
---
|
|
134
134
|
|
|
@@ -158,7 +158,7 @@ Detection-tool maturity (mid-2026):
|
|
|
158
158
|
|
|
159
159
|
## Analysis Procedure
|
|
160
160
|
|
|
161
|
-
Before stepping through the IR program assessment, thread the three foundational design principles
|
|
161
|
+
Before stepping through the IR program assessment, thread the three foundational design principles.
|
|
162
162
|
|
|
163
163
|
**Defense in depth — IR as a multi-layer pipeline.** A real IR program is not the playbook document; it is the stack that produces the conditions for the playbook to fire and the conditions for it to succeed:
|
|
164
164
|
- **Layer 1 — Preparation.** Playbook library (by ATT&CK technique + incident class + sector + jurisdiction), tabletop exercises (at least quarterly, scenarios drawn from current threat-intel feed), runbook tooling (SOAR + ticketing + comms), redundant logging (SIEM + DLP + identity + EDR + AI-system telemetry shipped to immutable store), legal and PR alignment, executive and board awareness, retainer with external IR firm.
|
|
@@ -255,7 +255,7 @@ Within 14 days of recovery (or sooner for severe incidents):
|
|
|
255
255
|
|
|
256
256
|
### Step 9 — Learning-loop feedback (cross-skill hand-offs)
|
|
257
257
|
|
|
258
|
-
Per
|
|
258
|
+
Per the zero-day learning loop and the skill graph:
|
|
259
259
|
- File `data/zeroday-lessons.json` entry per `zeroday-gap-learn` if a zero-day or new attack class was involved.
|
|
260
260
|
- File `data/framework-control-gaps.json` entry per `framework-gap-analysis` if a control-class gap was exposed.
|
|
261
261
|
- Trigger `threat-model-currency` refresh — the incident is a real-world signal that the threat model may be stale.
|
|
@@ -272,7 +272,7 @@ Per ISO 27035-1:2023 §6 and NIST 800-61r3 post-incident activity:
|
|
|
272
272
|
- Playbook coverage percentage (incident classes with playbook vs. total observed in 24-month window).
|
|
273
273
|
- AI-class incident detection latency vs. conventional-class incident detection latency — the operationally-relevant gap metric for mid-2026.
|
|
274
274
|
|
|
275
|
-
**Ephemeral / serverless / AI-pipeline reality
|
|
275
|
+
**Ephemeral / serverless / AI-pipeline reality:** Evidence preservation in serverless and container environments is the new hard problem of mid-2026 IR. NIST 800-86 forensic procedures assume the workload still exists at acquisition time. For Lambda / Cloud Run / Azure Functions / Knative / Kubernetes pods scaled to zero, the workload is gone before the SOC opens the ticket. The architecturally honest recommendation: configure continuous forensic-grade telemetry shipping pre-incident (process trees, syscall traces, network flows, container-layer diffs, AI-system prompt / response / tool-invocation logs) to an external immutable store. Treat the absence of this pipeline as a precondition for incident-evidence-loss and document it as a control gap per `framework-gap-analysis` before the first incident, not after.
|
|
276
276
|
|
|
277
277
|
---
|
|
278
278
|
|
|
@@ -510,7 +510,7 @@ A program passing all four tests is operating IR as infrastructure. A program fa
|
|
|
510
510
|
|
|
511
511
|
## Defensive Countermeasure Mapping
|
|
512
512
|
|
|
513
|
-
|
|
513
|
+
This section maps this skill's findings to MITRE D3FEND IDs from `data/d3fend-catalog.json` with explicit defense-in-depth layer position, least-privilege scope, zero-trust posture, and AI-pipeline applicability.
|
|
514
514
|
|
|
515
515
|
IR consumes defensive controls across multiple D3FEND categories; the four cited below are the highest-leverage during active incident handling.
|
|
516
516
|
|
|
@@ -521,9 +521,9 @@ IR consumes defensive controls across multiple D3FEND categories; the four cited
|
|
|
521
521
|
| **D3-IOPR** (Input/Output Profiling) | AI-API egress correlation and SaaS-egress anomaly detection. For AI-system incidents, profiling the input (prompt) and output (response) distribution is the defensive surface that can detect AML.T0051 (anomalous prompt patterns), AML.T0017 (extraction-pattern queries), and AML.T0096 (C2-channel encoded payloads). | Identification layer (primary for AI-system incidents). | Scoped to the AI-incident specialist role; raw prompts and responses may contain confidential data and must be access-controlled per data-classification policy. | Default-suspect for prompt distributions outside the baseline; do not whitelist by source identity alone — verify per request. | High applicability — D3-IOPR is the highest-leverage D3FEND technique for AI-system incident detection and is the operational complement to D3-NTA when the egress is to a legitimate AI provider. |
|
|
522
522
|
| **D3-CSPP** (Client-Server Payload Profiling) | C2 protocol detection during identification; AI-API content-layer detection for AML.T0096. Where the C2 channel is HTTPS to a legitimate service (Box, OneDrive, S3, AI provider), CSPP is the content-shape detection surface that catches the abuse pattern. | Identification layer. | Scoped to the detection-engineering and IR analyst roles; payload-content access controlled. | Default-suspect for novel payload shapes against baseline; verify-not-assume that previously-good clients have not been compromised. | Applies — particularly for AI-API C2 detection where TLS termination at an enterprise proxy enables payload-shape analysis of prompts and responses. |
|
|
523
523
|
|
|
524
|
-
**
|
|
524
|
+
**No orphaned controls**: each D3FEND technique above maps to one or more incident classes in the TTP Mapping section (T1486 / T1041 / T1567 / T1078, AML.T0096 / T0017 / T0051). The defensive cross-walk in `defensive-countermeasure-mapping` covers the broader D3FEND ontology; this section names only the techniques operationally invoked during IR.
|
|
525
525
|
|
|
526
|
-
**AI-pipeline statement
|
|
526
|
+
**AI-pipeline statement**: D3FEND coverage of AI-incident defense is concentrated in D3-IOPR (input/output profiling) and the content-layer subset of D3-CSPP. The ephemeral-compute evidence-preservation problem is largely outside the D3FEND ontology as of mid-2026; the operational fix (continuous forensic-grade telemetry shipping to immutable store) is documented in `attack-surface-pentest` and `defensive-countermeasure-mapping` as a control gap pending ontology coverage.
|
|
527
527
|
|
|
528
528
|
---
|
|
529
529
|
|
|
@@ -532,7 +532,7 @@ IR consumes defensive controls across multiple D3FEND categories; the four cited
|
|
|
532
532
|
IR sits downstream of detection and upstream of organizational learning. Route to the following on the indicated trigger:
|
|
533
533
|
|
|
534
534
|
- **`coordinated-vuln-disclosure`** — *upstream input.* When IR identification surfaces a vulnerability against an org product (received via researcher report, bug-bounty queue, or customer escalation), hand off to the CVD intake pipeline. Conversely, when CVD output identifies a vulnerability that is being actively exploited, the resulting EU CRA Art. 11 24h clock is run by the IR team using this skill's regulator-notification matrix.
|
|
535
|
-
- **`zeroday-gap-learn`** — *downstream learning loop.* Every incident with a novel attack class or a zero-day vector triggers a learning-loop entry
|
|
535
|
+
- **`zeroday-gap-learn`** — *downstream learning loop.* Every incident with a novel attack class or a zero-day vector triggers a learning-loop entry. If IR is operating but `data/zeroday-lessons.json` entries are not being filed, the hand-off is broken.
|
|
536
536
|
- **`threat-model-currency`** — *downstream refresh trigger.* An incident is the strongest real-world signal that the threat model may be stale; trigger the currency refresh routine.
|
|
537
537
|
- **`compliance-theater`** — *paper-IR detection.* The four compliance theater tests in this skill compose with the broader theater detection across frameworks; run `compliance-theater` after this skill when the org is claiming SOC 2 / ISO 27001 / NIST CSF / HIPAA maturity that the IR test results contradict.
|
|
538
538
|
- **`framework-gap-analysis`** — *control-gap filing.* When an incident exposes that an existing control was insufficient to detect, prevent, or contain, file the gap under the appropriate framework entry per `data/framework-control-gaps.json`.
|
|
@@ -370,18 +370,18 @@ vm.unprivileged_userfaultfd = 0
|
|
|
370
370
|
|
|
371
371
|
## Defensive Countermeasure Mapping
|
|
372
372
|
|
|
373
|
-
Maps the kernel LPE findings above to MITRE D3FEND techniques with explicit defense-in-depth layer position, least-privilege scope, and zero-trust posture
|
|
373
|
+
Maps the kernel LPE findings above to MITRE D3FEND techniques with explicit defense-in-depth layer position, least-privilege scope, and zero-trust posture. Source: `data/d3fend-catalog.json`.
|
|
374
374
|
|
|
375
375
|
| D3FEND Technique | Mapping | Defense-in-Depth Layer | Least-Privilege Scope | Zero-Trust Posture |
|
|
376
376
|
|---|---|---|---|---|
|
|
377
377
|
| **D3-PSEP** (Process Segment Execution Prevention) | Counters T1068 page-cache CoW write primitives (Copy Fail) and adjacent kernel write-where exploits by enforcing NX / W^X on user-mapped segments and rejecting writeable-and-executable kernel mappings. | Layer 1 (Harden — kernel build flags + runtime mitigations: SMEP, SMAP, KPTI, KRG). | Per-system — the entire kernel image is the principal scope. | Treat every userspace write to a kernel-shared mapping as untrusted until verified by an immutable mapping policy; auditd / eBPF rules emit a tamper signal on any anomalous write path. |
|
|
378
378
|
| **D3-ASLR** (Address Space Layout Randomization) | Raises the cost of reliable kernel LPE exploitation by randomising kernel base and module load addresses; Copy Fail is deterministic without an info-leak primitive, so KASLR alone is not sufficient but is the first-floor mitigation against the broader class. | Layer 1 (Harden). | Per-boot — randomisation applies system-wide each boot. | Combine with `kernel.kptr_restrict=2` (already in the sysctl block above) so unprivileged processes cannot read kernel pointers that would defeat KASLR. |
|
|
379
|
-
| **D3-EAL** (Executable Allowlisting) | Restricts which userspace executables can run on the host. A Copy Fail PoC is a 732-byte binary; allowlisting denies unauthorised execution of any binary not on the allowlist, raising the cost of post-exploit shell payloads even when the in-kernel write itself succeeds. | Layer 2 (Harden — execve gate). | Per-system / per-workload — fleet baselines (gold images) define the allowlist; SOC / EDR enforces it. | Verify the binary identity on every `execve`; reject on hash mismatch.
|
|
379
|
+
| **D3-EAL** (Executable Allowlisting) | Restricts which userspace executables can run on the host. A Copy Fail PoC is a 732-byte binary; allowlisting denies unauthorised execution of any binary not on the allowlist, raising the cost of post-exploit shell payloads even when the in-kernel write itself succeeds. | Layer 2 (Harden — execve gate). | Per-system / per-workload — fleet baselines (gold images) define the allowlist; SOC / EDR enforces it. | Verify the binary identity on every `execve`; reject on hash mismatch. In ephemeral / serverless contexts bake the allowlist into the function image at build-time. |
|
|
380
380
|
| **D3-PHRA** (Process Hardware Resource Access) | Constrains hardware-resource access from userspace (page table writes via `/proc/self/mem`, `userfaultfd`, `process_vm_writev`) that the Copy Fail PoC relies on. The sysctl hardening above (`vm.unprivileged_userfaultfd=0`, `kernel.unprivileged_userns_clone=0`) is the D3-PHRA enforcement layer. | Layer 1 (Isolate — kernel-syscall surface). | Per-process — capability set + namespace + seccomp filter define the syscall allowlist. | Default-deny: an unprivileged process gets the minimum syscall surface and is denied `userfaultfd`, `unshare(CLONE_NEWUSER)`, and `process_vm_writev` unless explicitly required. |
|
|
381
381
|
| **D3-SCP** (System Call Filtering) | Per-container / per-workload seccomp profile blocks the syscalls Copy Fail abuses (`userfaultfd`, `process_vm_writev`, `pwritev2`) without requiring kernel patch. For container-escape variants (T1611 — Copy Fail in a privileged container), this is the only viable runtime mitigation between KEV-listing and the next reboot window. | Layer 2 (Isolate — runtime syscall gate). | Per-container — runtime profile is the principal scope. | Define a default-deny seccomp baseline; the host kernel patch is necessary but seccomp is the per-workload extension that survives an unpatched kernel during the live-patch deployment window. |
|
|
382
382
|
| **D3-PA** (Process Analysis) | Detects post-exploit anomalies — root shell spawned by previously-unprivileged process, suid-binary creation, capability escalation — that follow a Copy Fail-class write. The auditd and Falco / Tetragon rules in the Detection Rules section above are the D3-PA enforcement layer. | Layer 5 (Detect). | Per-host — SOC / EDR ingest the audit stream. | Continuously evaluate process lineage; alert on uid transitions, capability gains, or suid mounts that don't appear in the baseline. |
|
|
383
383
|
|
|
384
|
-
**Defense-in-depth posture:** the live-patch is the closure; the five D3FEND techniques above are the layers that must remain active *during* the live-patch deployment window. A SOC claiming "we have EDR" is at one D3FEND layer (D3-PA) for a six-layer-deep finding — the harden / isolate / detect stack collapses to a detect-only posture, and a kernel-write primitive that succeeds before EDR fires is unrecoverable.
|
|
384
|
+
**Defense-in-depth posture:** the live-patch is the closure; the five D3FEND techniques above are the layers that must remain active *during* the live-patch deployment window. A SOC claiming "we have EDR" is at one D3FEND layer (D3-PA) for a six-layer-deep finding — the harden / isolate / detect stack collapses to a detect-only posture, and a kernel-write primitive that succeeds before EDR fires is unrecoverable. In ephemeral / serverless contexts, D3-PSEP / D3-EAL / D3-SCP / D3-PHRA are configured at image build time; the host-kernel layer remains the CSP's responsibility for managed runtimes, with the consumer responsible for the guest-OS posture on IaaS workloads.
|
|
385
385
|
|
|
386
386
|
---
|
|
387
387
|
|
|
@@ -393,4 +393,4 @@ After producing the kernel LPE triage output, the operator should chain into the
|
|
|
393
393
|
- **`defensive-countermeasure-mapping`** — map each kernel LPE finding to D3FEND counters (D3-EAL for executable allowlisting at the kernel-module layer, D3-ASLR for address-space layout randomisation hardening, D3-PSEP for process self-modification prevention, D3-PHRA for process hardening / runtime attestation) and produce the defence-in-depth, least-privilege, zero-trust layered remediation plan rather than a single-control patch ticket.
|
|
394
394
|
- **`attack-surface-pentest`** — verify that the kernel LPE class is in the organisation's pen-test scope (TIBER-EU / DORA TLPT for EU financial-sector orgs, CBEST for UK financial, or the equivalent red-team programme). Most 2025-vintage pen-test scopes are perimeter / web-app focused and do not exercise local LPE primitives against the patched-kernel claim.
|
|
395
395
|
- **`compliance-theater`** — test whether the org's SI-2 / A.8.8 / PCI 6.3.3 patch-management evidence is CVSS-anchored theater for a KEV-listed, AI-discovered, 732-byte deterministic LPE. The 30-day window is the exploitation window; if the org cannot show live-patch-within-4-hours capability or documented compensating controls, the patch-management control is theater for this CVE class.
|
|
396
|
-
- **`policy-exception-gen`** — generate a defensible exception for ephemeral container workloads where the 30-day patch window is architecturally impossible
|
|
396
|
+
- **`policy-exception-gen`** — generate a defensible exception for ephemeral container workloads where the 30-day patch window is architecturally impossible: immutable image fleets, short-lived serverless functions, and Knative-style scale-to-zero workloads cannot accept a runtime patch and must instead document the compensating controls (host-kernel patched, seccomp profile, namespace isolation, unprivileged-userns disabled) as the exception evidence.
|
|
@@ -345,9 +345,9 @@ After producing the MCP trust assessment output, the operator should chain into
|
|
|
345
345
|
- **`defensive-countermeasure-mapping`** — map MCP trust failures to D3FEND counters: D3-EHB (hash-based executable allowlisting for the MCP server binary), D3-CBAN (certificate-based authentication between client and server), D3-MFA (multi-factor authentication on the MCP control plane where remote), D3-CSPP (client-server payload profiling on tool call / tool response shapes). The trust-tier model in Step 5 above is operationalised through these counters.
|
|
346
346
|
- **`attack-surface-pentest`** — explicitly include each installed MCP server in the in-scope target list for pen-testing and adversary emulation. 2025-vintage pen-test scopes overwhelmingly omit MCP servers; this is the single biggest assumed-out-of-scope gap discovered during this skill's analysis.
|
|
347
347
|
- **`dlp-gap-analysis`** — MCP tool arguments are a DLP egress channel. Verify that SDK-level prompt logging captures tool-arg egress (filenames, file contents, credential strings passed as arguments) and that DLP classifiers run on the tool-call payload, not just on file/email egress. Without this, an MCP server with filesystem read access is a fully invisible exfiltration path.
|
|
348
|
-
- **`framework-gap-analysis`** — when the MCP trust gap fails a specific framework control (NIST-800-53-CM-7 / ISO-27001-2022-A.8.30 / SOC2-CC9 vendor management), invoke this skill to produce the formal gap declaration tied to the organisation's compliance scope and jurisdiction, including the EU NIS2 / DORA / AU Essential 8 mappings
|
|
348
|
+
- **`framework-gap-analysis`** — when the MCP trust gap fails a specific framework control (NIST-800-53-CM-7 / ISO-27001-2022-A.8.30 / SOC2-CC9 vendor management), invoke this skill to produce the formal gap declaration tied to the organisation's compliance scope and jurisdiction, including the EU NIS2 / DORA / AU Essential 8 mappings (global-first coverage, not US-only).
|
|
349
349
|
|
|
350
|
-
For ephemeral / serverless AI-pipeline contexts (
|
|
350
|
+
For ephemeral / serverless AI-pipeline contexts (where some controls are architecturally impossible): live SLSA-attestation verification at runtime is architecturally impossible for inline-pulled MCP servers in serverless functions. The scoped alternative is build-time attestation pinning baked into the function image, with the runtime fetch path disabled at the network layer.
|
|
351
351
|
|
|
352
352
|
---
|
|
353
353
|
|
|
@@ -370,7 +370,7 @@ D3FEND v1.3.0+ references from `data/d3fend-catalog.json`. MCP trust failures la
|
|
|
370
370
|
|
|
371
371
|
**Zero-trust posture:** every MCP server is treated as an untrusted third party regardless of vendor reputation — `D3-EHB` pin on registration, `D3-CBAN` cert verification on every connection, `D3-CSPP` payload inspection on every tool call. No "first-party vendor" exemption; the Cursor / Windsurf / VS Code first-party plugins ship through the same supply-chain (`npm` / `pip` / VS Code marketplace) that AML.T0010 targets.
|
|
372
372
|
|
|
373
|
-
**AI-pipeline applicability (
|
|
373
|
+
**AI-pipeline applicability (some controls are architecturally impossible in ephemeral / hosted contexts):** `D3-EAL` and `D3-EHB` apply only when the MCP server runs as a local executable. For hosted / remote MCP servers (the Claude Code, Cursor, and Windsurf hosted-tool pattern), the scoped alternative is `D3-CBAN` (pinned server identity) + `D3-CSPP` at the egress gateway + `D3-CAA` against the hosted-server provider's audit log feed. The endpoint controls (`D3-EAL`/`D3-EHB`) move from "verify locally before run" to "verify provider attestation before connect."
|
|
374
374
|
|
|
375
375
|
---
|
|
376
376
|
|