Skip to content

Commit 6fb2524

Browse files
emmanuelgjrclaude
emmanuelgjr
and
claude
committed
Add RATIONALE.md — document methodology behind all framework mappings
Explains source list selection, framework-by-framework justification, 8-step mapping methodology, severity rating approach, tier/scope model, design decisions, and maintenance process. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
1 parent 07c810a commit 6fb2524

1 file changed

Lines changed: 250 additions & 0 deletions

File tree

‎RATIONALE.md‎

Lines changed: 250 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,250 @@
1+
<!--
2+
GenAI Security Crosswalk
3+
File : RATIONALE.md
4+
Purpose : Rationale behind all framework mappings — what was included, why, and how
5+
Version : 2026-Q1
6+
License : CC BY-SA 4.0
7+
-->
8+
9+
# Mapping Rationale
10+
11+
This document explains the reasoning behind the GenAI Security Crosswalk: why each framework was selected, how the mappings were constructed, and the methodology that ties it all together.
12+
13+
---
14+
15+
## 1. The Problem This Solves
16+
17+
Organisations deploying GenAI (LLMs, agents, RAG pipelines) face a fragmented control landscape. No single document answered: **"Which controls from framework X address GenAI vulnerability Y?"** Security teams were left cross-referencing dozens of PDFs manually, often missing coverage gaps or duplicating effort across compliance programmes.
18+
19+
The Crosswalk provides a single, structured, machine-readable answer to that question — across 41 OWASP vulnerabilities and 20 industry frameworks.
20+
21+
---
22+
23+
## 2. Source Lists — What We Map From
24+
25+
The Crosswalk maps **from** three OWASP source lists that together cover the full GenAI attack surface:
26+
27+
| Source List | Entries | Scope | Why Included |
28+
|---|---|---|---|
29+
| **OWASP LLM Top 10 2025** | LLM01–LLM10 | Core LLM application risks (prompt injection, data leakage, supply chain, etc.) | The foundational OWASP list for LLM risks; widest industry adoption; the starting point for any GenAI security programme. |
30+
| **OWASP Agentic Top 10 2026** | ASI01–ASI10 | Autonomous agent risks (goal hijack, tool misuse, privilege escalation, cascading failures, etc.) | Agents introduce qualitatively different risks — autonomy, tool access, multi-agent orchestration, persistent memory — that the LLM Top 10 was not designed to cover. |
31+
| **OWASP GenAI Data Security 2026** | DSGAI01–DSGAI21 | Data lifecycle risks (training data poisoning, embedding leakage, model theft, PII in context, etc.) | Data is the through-line of every GenAI system. DSGAI covers the full data lifecycle from ingestion through training, inference, storage, and deletion — filling the gap between the application-level LLM/Agentic lists and data governance requirements. |
32+
33+
**Cross-references** link related entries across all three lists (e.g., LLM01 Prompt Injection ↔ ASI01 Agent Goal Hijack ↔ DSGAI01 Sensitive Data Leakage), so practitioners can trace a single risk across application, agent, and data dimensions.
34+
35+
---
36+
37+
## 3. Frameworks — What We Map To
38+
39+
### 3.1 Selection Criteria
40+
41+
Every framework was selected based on at least two of the following:
42+
43+
1. **Regulatory mandate** — Required by law or industry regulation (EU AI Act, DORA, PCI DSS, FedRAMP)
44+
2. **Certification/audit requirement** — Used in formal audits or certifications (ISO 27001, ISO 42001, SOC 2, AIUC-1)
45+
3. **Industry adoption** — Widely adopted as a voluntary best practice (NIST CSF, CIS Controls, OWASP ASVS)
46+
4. **AI-specific coverage** — Purpose-built for AI or ML security (NIST AI RMF, MITRE ATLAS, MAESTRO, NIST SP 800-218A)
47+
5. **Domain-specific necessity** — Required for specific deployment contexts (ISA/IEC 62443 and NIST SP 800-82 for OT/ICS; DORA for financial sector; NHI Top 10 for non-human identities)
48+
6. **Practitioner demand** — Frequently requested by the OWASP GenAI community
49+
50+
### 3.2 Framework-by-Framework Rationale
51+
52+
#### Threat Modelling & Adversarial Taxonomy
53+
54+
| Framework | Why Included |
55+
|---|---|
56+
| **MITRE ATLAS** | The only structured adversarial technique taxonomy for ML/AI systems. Provides technique IDs (AML.T0051, etc.) that allow defenders to map vulnerabilities to specific adversarial TTPs. Essential for red teams and threat intel. |
57+
| **STRIDE** | Classic Microsoft threat modelling methodology (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege). Applied to LLM and agentic contexts so teams using STRIDE can incorporate GenAI threats into existing threat models without adopting a new framework. |
58+
| **CWE/CVE** | Maps each OWASP entry to its root-cause weakness (CWE) and known confirmed vulnerabilities (CVE). Bridges GenAI risks to the traditional vulnerability management ecosystem — scanners, SIEM rules, and patch management workflows already speak CWE/CVE. |
59+
60+
#### AI Governance & Risk Management
61+
62+
| Framework | Why Included |
63+
|---|---|
64+
| **NIST AI RMF 1.0** | The US federal standard for AI risk management. Its GOVERN/MAP/MEASURE/MANAGE taxonomy structures AI risk from policy through technical controls. Required for US federal AI deployments; widely adopted by enterprises as voluntary best practice. |
65+
| **ISO/IEC 42001:2023** | The first international AI management system standard. Provides certifiable requirements for AI governance, risk, and compliance. Increasingly required in procurement and regulatory contexts (EU AI Act references management system approaches). |
66+
| **AIUC-1** | The first AI agent security, safety, and reliability certification standard. Six domains (Data & Privacy, Security, Safety, Reliability, Accountability, Society) directly address agentic risks that generic frameworks miss. |
67+
68+
#### Regulatory & Compliance
69+
70+
| Framework | Why Included |
71+
|---|---|
72+
| **EU AI Act** | Regulation (EU) 2024/1689 — the world's first comprehensive AI regulation. High-risk AI systems and GPAI models face binding obligations (Articles 6–72). The August 2026 enforcement deadline makes this the most urgent mapping for any EU-market deployment. |
73+
| **DORA (EU 2022/2554)** | The Digital Operational Resilience Act applies to financial entities using AI. Adds ICT risk management, incident reporting, third-party oversight, and resilience testing obligations on top of general AI regulation. Included because financial services is one of the largest GenAI adoption sectors. |
74+
| **FedRAMP** | Federal Risk and Authorization Management Programme. Any AI system operating in US government cloud environments must meet FedRAMP requirements. Maps GenAI risks to the FedRAMP security control baseline (derived from NIST SP 800-53). |
75+
| **PCI DSS v4.0** | Payment Card Industry Data Security Standard. AI systems processing, storing, or transmitting cardholder data must comply. Maps GenAI risks to PCI DSS requirements for organisations deploying AI in payment and financial contexts. |
76+
77+
#### Information Security & Cybersecurity Foundations
78+
79+
| Framework | Why Included |
80+
|---|---|
81+
| **ISO/IEC 27001:2022** | The most widely certified information security standard globally. Maps GenAI risks to Annex A controls so organisations can extend their existing ISMS to cover AI deployments without building a parallel control framework. |
82+
| **NIST CSF 2.0** | The Cybersecurity Framework's Identify/Protect/Detect/Respond/Recover + new Govern function. Provides a common language for cybersecurity risk that most US enterprises already use. GenAI mappings allow integration into existing CSF-based programmes. |
83+
| **CIS Controls v8.1** | Prioritised, actionable security controls with Implementation Groups (IG1/IG2/IG3). Popular with mid-market organisations that need prescriptive guidance. Maps GenAI risks to specific CIS safeguards with IG-level implementation guidance. |
84+
| **SOC 2 Trust Services Criteria** | Required for SaaS and cloud service providers. Maps GenAI risks to Trust Services Criteria (Security, Availability, Confidentiality, Processing Integrity, Privacy) so AI-powered SaaS companies can address GenAI risks within their existing SOC 2 audit scope. |
85+
86+
#### Application Security & Secure Development
87+
88+
| Framework | Why Included |
89+
|---|---|
90+
| **OWASP ASVS 4.0.3** | Application Security Verification Standard with three levels (L1/L2/L3). Maps GenAI risks to specific verification requirements so development teams can test for AI-specific vulnerabilities using the same ASVS methodology they use for traditional web apps. |
91+
| **OWASP SAMM v2.0** | Software Assurance Maturity Model. Maps GenAI risks to maturity practices across Governance, Design, Implementation, Verification, and Operations. Helps organisations measure and improve their AI security programme maturity over time. |
92+
| **NIST SP 800-218A** | Secure Software Development Framework extension for AI. Maps GenAI risks to AI-specific secure development practices (PW/PS/RV). The authoritative US guidance for secure AI SDLC — directly applicable to developer workflows. |
93+
94+
#### OT/ICS Security
95+
96+
| Framework | Why Included |
97+
|---|---|
98+
| **ISA/IEC 62443** | The international standard for industrial automation and control system security. Zone/conduit model, security levels, and foundational requirements (FR/SR). Included because AI is increasingly deployed in OT environments (predictive maintenance, autonomous control) where safety and availability outweigh confidentiality. |
99+
| **NIST SP 800-82 Rev 3** | OT/ICS-specific guidance with SP 800-53 control mappings. Pairs with ISA/IEC 62443 to provide complete OT security coverage. Essential for organisations deploying AI in critical infrastructure. |
100+
101+
#### Architectural & Layered Models
102+
103+
| Framework | Why Included |
104+
|---|---|
105+
| **MAESTRO (CSA)** | Cloud Security Alliance's 7-layer agentic AI threat model. Maps threats to architectural layers (Foundation Models, Data Operations, Agent Frameworks, Tools, Deployment, Orchestration, Interaction). The only framework that provides layer-by-layer threat attribution — critical for understanding where in the stack a vulnerability originates, propagates, and impacts. |
106+
| **ENISA Multilayer Framework** | EU Agency for Cybersecurity's multilayer AI cybersecurity framework (L1/L2/L3). Provides EU-aligned layered security guidance that complements the EU AI Act regulatory requirements with practical technical controls. |
107+
108+
#### Identity & Non-Human Entities
109+
110+
| Framework | Why Included |
111+
|---|---|
112+
| **OWASP NHI Top 10** | Non-Human Identities Top 10. Agents, service accounts, API keys, and machine identities are the dominant identity surface in agentic AI. This mapping addresses the unique risks of non-human identity management — credential sprawl, over-privileged service accounts, secret leakage — that traditional IAM frameworks underserve. |
113+
114+
#### Testing
115+
116+
| Framework | Why Included |
117+
|---|---|
118+
| **OWASP AI Testing Guide (AITG)** | Structured test cases mapped to each OWASP entry. Bridges the gap between "what to protect against" (the vulnerability) and "how to verify it" (the test procedure). |
119+
120+
---
121+
122+
## 4. Mapping Methodology
123+
124+
### 4.1 Unit of Mapping
125+
126+
Each mapping links **one OWASP vulnerability entry** to **one or more framework controls**. The grain is:
127+
128+
```
129+
[Vulnerability ID] → [Framework] → [Control ID] + [Control Name] + [Tier] + [Scope] + [Notes]
130+
```
131+
132+
Example: `LLM01 → NIST AI RMF 1.0 → GV-1.7 (Policies for trustworthy AI) / Foundational / Both`
133+
134+
### 4.2 How Mappings Were Constructed
135+
136+
1. **Vulnerability analysis** — Each OWASP entry was decomposed into its attack vectors, impacts, and required mitigations based on the official OWASP source list definitions.
137+
138+
2. **Control identification** — For each framework, controls were identified that directly address one or more of: the attack vector, the impact, or the required mitigation. The authoritative framework text (standard, regulation, specification) was the source — not secondary summaries.
139+
140+
3. **Relevance filtering** — Only controls with a clear, defensible connection to the vulnerability were included. "Tangentially related" controls were excluded to keep mappings actionable rather than exhaustive.
141+
142+
4. **Tier assignment** — Each control mapping was assigned an implementation tier:
143+
144+
| Tier | Criteria | Typical Timeline |
145+
|---|---|---|
146+
| **Foundational** | Essential baseline — every deployment needs this regardless of maturity | Sprint 0–1 (immediate) |
147+
| **Hardening** | Defence-in-depth for mature security programmes | Quarter 1–2 |
148+
| **Advanced** | Cutting-edge, high-risk, or high-maturity environments only | Quarter 3+ |
149+
150+
Tier assignment is based on: implementation complexity, dependency on other controls, cost, and how commonly the control is already present in production environments.
151+
152+
5. **Scope assignment** — Each mapping was tagged with deployment scope:
153+
154+
| Scope | Meaning |
155+
|---|---|
156+
| **Buy** | Addressed by vendor/platform capability (e.g., cloud provider guardrails) |
157+
| **Build** | Requires internal engineering effort |
158+
| **Both** | Needs vendor capability AND internal implementation |
159+
160+
6. **Cross-referencing** — Each entry was linked to related entries in the other two source lists, enabling practitioners to trace risks across LLM application, agentic, and data security dimensions.
161+
162+
7. **Incident grounding** — Where available, real-world incidents (50 documented in the crosswalk) were linked to entries to validate that the vulnerability and mapped controls are not theoretical.
163+
164+
8. **Tool mapping** — Open-source and commercial tools (70+) were mapped to entries, providing practitioners with immediate actionable testing and mitigation options.
165+
166+
### 4.3 Severity Rating Methodology
167+
168+
Severity ratings follow the unified scale defined in `shared/SEVERITY.md`:
169+
170+
- **Base severity** — drawn directly from the OWASP source list definition or assessed using OWASP AIVSS methodology
171+
- **Agentic amplifiers** — AIVSS adds ten agentic factors (autonomy level, tool access breadth, multi-agent orchestration, memory persistence, human oversight absence, OT/physical access) that can raise effective severity by 1–4 levels
172+
- **No severity change without evidence** — ratings cannot be changed without citing an AIVSS score, a CVSS score from an associated CVE, or the OWASP source list definition
173+
174+
### 4.4 Quality Controls
175+
176+
- **Authoritative sources only** — mappings cite the actual framework text, not secondary interpretations
177+
- **Schema validation** — all machine-readable entries (JSON) are validated against `data/schema.json` using `scripts/validate.js`
178+
- **Source-of-truth model** — Markdown files are authoritative; JSON is derived via `scripts/generate.js`; both must stay in sync
179+
- **Contribution review** — PRs require source/evidence links; severity changes require AIVSS/CVSS/OWASP citation
180+
- **Consistent terminology** — all entries use the unified glossary (`shared/GLOSSARY.md`)
181+
182+
---
183+
184+
## 5. What Was Deliberately Excluded
185+
186+
| Exclusion | Reason |
187+
|---|---|
188+
| **Frameworks with no public specification** | Cannot be independently verified or contributed to |
189+
| **Deprecated framework versions** | Mappings target current versions only (e.g., NIST CSF 2.0 not 1.1, PCI DSS 4.0 not 3.2.1) |
190+
| **Tangential controls** | Controls only loosely related to a vulnerability were excluded to keep mappings actionable |
191+
| **Vendor-specific implementation guides** | The crosswalk maps to framework controls, not to specific vendor products or configurations |
192+
| **Risk ratings without evidence** | No severity or tier assignment was made without a defensible basis in the source material |
193+
194+
---
195+
196+
## 6. How to Read a Mapping Entry
197+
198+
Each mapping file follows the structure defined in `shared/TEMPLATE.md`:
199+
200+
1. **Header** — source list, framework, version, license
201+
2. **Framework overview** — what the framework is and why it matters for this source list
202+
3. **Quick-reference table** — one row per vulnerability with primary controls and tier
203+
4. **Detailed mappings** (one section per vulnerability):
204+
- Severity rating
205+
- 2-sentence description
206+
- Real-world incident reference (where known)
207+
- Control mapping table (Control, ID, Description, Tier, Scope)
208+
- Mitigations by tier (Foundational → Hardening → Advanced)
209+
- Applicable tools
210+
- Cross-references to other source lists and frameworks
211+
5. **Implementation priority table**
212+
6. **References and changelog**
213+
214+
---
215+
216+
## 7. Design Decisions
217+
218+
### Why 20 frameworks and not fewer?
219+
220+
GenAI deployments span multiple compliance domains simultaneously. An AI chatbot processing payments in the EU must satisfy EU AI Act, PCI DSS, ISO 27001, and potentially DORA — all at once. Mapping to only "the top 5" frameworks would leave most practitioners with gaps. The 20-framework set covers the realistic compliance landscape.
221+
222+
### Why three source lists instead of one combined list?
223+
224+
LLM application risks, agentic risks, and data security risks are distinct problem domains with different audiences, threat models, and mitigations. A prompt injection attack on a chatbot (LLM01) is a fundamentally different problem from an agent's tool misuse (ASI05) or training data poisoning (DSGAI04). Keeping them separate preserves clarity; cross-references provide the linkage.
225+
226+
### Why the Foundational/Hardening/Advanced tier model?
227+
228+
Not every organisation can implement every control on day one. The tier model provides a **crawl → walk → run** implementation path that matches how security programmes mature in practice. It answers: "If I can only do three things this sprint, which three?"
229+
230+
### Why Buy/Build/Both scope tags?
231+
232+
Security teams need to know whether a control is something they configure in their vendor platform, something they build internally, or something that requires both. This distinction drives procurement decisions, staffing plans, and implementation timelines.
233+
234+
### Why machine-readable JSON alongside Markdown?
235+
236+
Markdown serves human readers. JSON serves automation — compliance report generation, GRC platform import (OSCAL), SIEM/SOAR integration (STIX 2.1), and programmatic querying. Both are necessary for the crosswalk to be useful across the full range of practitioner workflows.
237+
238+
---
239+
240+
## 8. Maintenance & Evolution
241+
242+
- New framework versions trigger mapping updates (tracked in changelogs at the bottom of each file)
243+
- New OWASP source list entries trigger new mappings across all frameworks
244+
- New real-world incidents are added to `data/incidents.json` and linked to affected entries
245+
- Community contributions follow the process in `CONTRIBUTING.md`
246+
- The crosswalk is versioned (`2026-Q1` currently) and published as an npm package for programmatic consumption
247+
248+
---
249+
250+
*Part of the [GenAI Security Crosswalk](https://github.com/emmanuelgjr/GenAI-Security-Crosswalk) — maintained by the [OWASP GenAI Data Security Initiative](https://genai.owasp.org)*

0 commit comments

Comments
 (0)