Red-team-bevindingen → Remediatie
Hoe je offensieve bevindingen koppelt aan defensieve aanbevelingen, severity-scoring voor AI-kwetsbaarheden, bruikbare remediatierichtlijnen en de pijplijn van rapport naar fix.
Kwetsbaarheden vinden is maar de helft van het werk. De andere helft is het vertalen van die bevindingen naar remediatie die verdedigers kunnen begrijpen, prioriteren en implementeren. Deze pagina behandelt de volledige pijplijn van een ruwe bevinding tot een geverifieerde fix.
De pijplijn van bevinding naar fix
Discovery → Classification → Severity Scoring → Remediation Mapping → Report → Fix → Verify
Elke fase vereist gestructureerd denken:
Fase 1: Classificatie
Categoriseer bevindingen met een consistente taxonomie. De OWASP Top 10 voor LLM-applicaties biedt een standaardframework:
| OWASP LLM-categorie | Voorbeeldbevinding | Typische remediatielaag |
|---|---|---|
| LLM01: Prompt Injection | Override van systeemprompt via delimiter-escape | Inputfiltering + instructiehiërarchie |
| LLM02: Insecure Output Handling | XSS via door het model gegenereerde HTML | Output-sanering + CSP |
| LLM03: Training Data Poisoning | Backdoor in fine-tuning-data | Datavalidatiepijplijn |
| LLM04: Model Denial of Service | Uitputting van het contextvenster via grote inputs | Rate limiting + limieten op inputgrootte |
| LLM05: Supply Chain Vulnerabilities | Kwaadaardig model op HuggingFace Hub | Verificatie van modelherkomst |
| LLM06: Sensitive Information Disclosure | Extractie van systeemprompt | Promptontwerp + outputfiltering |
| LLM07: Insecure Plugin Design | SQL-injectie via tool-call-argumenten | Inputvalidatie op toollaag |
| LLM08: Excessive Agency | Model voert onbedoelde tool-calls uit | Least privilege + goedkeuringspoorten |
| LLM09: Overreliance | Gebruikers vertrouwen onjuiste modeloutput | Betrouwbaarheidsindicatoren + disclaimers |
| LLM10: Model Theft | Modelgewichten geëxtraheerd via API | Rate limiting + watermerken |
Fase 2: Severity-scoring
AI-kwetsbaarheden passen niet netjes in traditionele CVSS-scoring. Gebruik een aangepast framework:
| Factor | Gewicht | Laag (1) | Gemiddeld (2) | Hoog (3) | Kritiek (4) |
|---|---|---|---|---|---|
| Exploiteerbaarheid | 30% | Vereist modeltoegang | Vereist insiderkennis | Geautomatiseerd, weinig vaardigheid | Geautomatiseerd, geen vaardigheid |
| Impact | 30% | Kleine beleidsschending | Datalekkage (niet-gevoelig) | Blootstelling van gevoelige data | Veiligheidsschade, juridische aansprakelijkheid |
| Reproduceerbaarheid | 20% | <10% slagingspercentage | 10-50% slagingspercentage | 50-90% slagingspercentage | >90% slagingspercentage |
| Scope | 20% | Eén gebruiker getroffen | Meerdere gebruikers getroffen | Alle gebruikers van één functie | Hele applicatie getroffen |
Samengestelde score = gewogen som, gemapt naar severity:
- 1.0-1.5: Laag
- 1.6-2.5: Gemiddeld
- 2.6-3.5: Hoog
- 3.6-4.0: Kritiek
Remediatie-mapping
Map voor elke bevindingscategorie naar specifieke defensieve controles:
Prompt-injectie-bevindingen
| Bevinding | Aanbevolen remediaties |
|---|---|
| Directe instructie-override | 1. Zet een prompt shield (Azure/Lakera) in op de input 2. Implementeer instructiehiërarchie in de modelconfiguratie 3. Voeg een outputfilter toe voor systeempromptinhoud |
| Delimiter-escape | 1. Gebruik unieke, gerandomiseerde delimiters per sessie 2. Voeg integriteitsvalidatie van delimiters toe 3. Saneer gebruikersinput voor delimiter-tekens |
| Extractie van systeemprompt | 1. Minimaliseer gevoelige inhoud in de systeemprompt 2. Voeg een outputfilter toe voor fragmenten van de systeemprompt 3. Zet canary-tokens in om extractie te detecteren |
Bevindingen over datablootstelling
| Bevinding | Aanbevolen remediaties |
|---|---|
| PII in modeloutput | 1. Zet PII-detectie in op de output (regex + NER) 2. Redigeer vóór levering 3. Audit de trainingsdata op PII |
| Extractie van trainingsdata | 1. Implementeer eisen voor outputdiversiteit 2. Voeg memorisatiedetectie toe 3. Rate-limit herhaalde queries over hetzelfde onderwerp |
| RAG-contextlekkage | 1. Filter opgehaalde documenten vóór opname 2. Voeg toegangscontrole toe op de retrievallaag 3. Valideer dat antwoorden binnen de geautoriseerde context blijven |
Agentic/tool-bevindingen
| Bevinding | Aanbevolen remediaties |
|---|---|
| Ongeautoriseerde tool-uitvoering | 1. Implementeer goedkeuringspoorten voor tool-calls 2. Pas least privilege toe op toegang tot tools 3. Log en monitor alle tool-aanroepen |
| Injectie van tool-argumenten | 1. Valideer tool-argumenten tegen het schema 2. Parametriseer tool-inputs (geen string-concatenatie) 3. Sandbox de uitvoeromgevingen van tools |
| Privilege-escalatie via tools | 1. Forceer permissiegrenzen per tool 2. Valideer de volgorde van tool-ketens 3. Implementeer sessiegebonden tool-permissies |
Effectieve remediatierichtlijnen schrijven
Wees specifiek, niet generiek
Slecht: "Verbeter de inputfiltering." Goed: "Zet Azure Prompt Shield in op het /api/chat-endpoint met de drempel op gemiddelde gevoeligheid. Dit blokkeert de delimiter-escape-techniek die wordt gedemonstreerd in Bevinding #3."
Voeg schattingen van de implementatie-inspanning toe
Tag elke aanbeveling met een geschatte inspanning: Quick Win (uren), Gemiddeld (dagen), Aanzienlijk (weken). Dit helpt verdedigers bij het prioriteren.
Lever verificatiecriteria
Specificeer voor elke fix hoe je verifieert dat hij werkt: "Voer na het inzetten van het prompt shield de testcases F3-1 tot en met F3-7 opnieuw uit. Allemaal zouden ze het geblokkeerde antwoord moeten teruggeven."
Lever aanbevelingen in lagen
Lever kortetermijnmitigaties (zet deze week een filter in) en langetermijnfixes (herontwerp de promptarchitectuur volgend kwartaal).
De remediatie-prioriteitsmatrix
Wanneer verdedigers met 20+ bevindingen geconfronteerd worden, hebben ze een prioriteringsframework nodig:
| Makkelijk te fixen | Moeilijk te fixen | |
|---|---|---|
| Hoge severity | Onmiddellijk fixen (Quick Wins) | Inplannen voor volgende sprint |
| Lage severity | Fixen wanneer het uitkomt | Risico accepteren of uitstellen |
Bevindingen volgen tot aan de oplossing
De pijplijn van rapport naar fix eindigt niet bij de oplevering. Best practices voor het volgen:
- Bevindingenregister -- onderhoud een database van bevindingen met status (open, in uitvoering, gefixt, geverifieerd, geaccepteerd-risico)
- Hertestcycli -- plan hertesten 2-4 weken na gerapporteerde fixes om te verifiëren dat ze werken en geen regressies hebben geïntroduceerd
- Regressiemonitoring -- voeg geslaagde exploit-payloads toe aan continue testsuites zodat regressies automatisch worden opgevangen
- Metrieken -- volg de gemiddelde tijd tot remediatie (MTTR) per severity-niveau; dit laat zien of de defensieve houding van de organisatie verbetert
Verder lezen
- Defense-in-Depth voor LLM-apps -- gelaagde verdedigingsstrategie voor uitgebreide remediatie
- Denken als een verdediger -- de prioriteiten van verdedigers begrijpen voor een betere ontvangst van het rapport
- Rapportschrijven -- het structureren van het algehele red-team-rapport
Gerelateerde onderwerpen
- Defense-in-Depth voor LLM-apps - Gelaagde verdedigingsstrategie voor uitgebreide remediatie
- Denken als een verdediger - De prioriteiten van verdedigers begrijpen voor een betere ontvangst van het rapport
- Guardrails & architectuur van de veiligheidslaag - Architectuurkennis die nodig is voor specifieke remediatieaanbevelingen
- AI-dreigingsmodellen - Context voor dreigingsmodellering bij de severity-beoordeling
Referenties
- "OWASP Top 10 for LLM Applications" - OWASP (2025) - Standard vulnerability taxonomy for classifying AI-specific findings
- "CVSS v4.0 Specification" - FIRST (2023) - Common Vulnerability Scoring System adapted for AI vulnerability severity assessment
- "NIST AI Risk Management Framework (AI RMF 1.0)" - NIST (2023) - Risk framework for prioritizing AI security findings and remediation efforts
- "Penetration Testing Report Writing Guide" - SANS Institute (2023) - Best practices for structuring security findings and remediation guidance
Je vindt een prompt-injectie-bypass met een slagingspercentage van 80% waardoor het model PII uit zijn RAG-context lekt. Welke factoren duwen dit volgens het severity-framework richting Kritieke severity?