Grondbeginselen van red team-methodologie

Wat AI-redteaming is, hoe het verschilt van traditioneel beveiligingstesten en de volledige levenscyclus van een opdracht, van scoping tot rapportage.

Wat is AI-redteaming?

AI-redteaming is de praktijk waarbij je AI-systemen systematisch onderzoekt om te ontdekken hoe je ze kunt aanzetten tot onbedoeld, schadelijk of misbruikbaar gedrag. Anders dan bij traditioneel softwaretesten, waarbij je controleert of een systeem doet wat het moet doen, stelt redteaming de vraag: wat kun je dit systeem laten doen wat het níet zou mogen doen?

De term "red team" komt uit militaire oefeningen tijdens de Koude Oorlog, waarbij een aangewezen tegenstander (het red team) de plannen en aannames van de eigen partij (het blue team) op de proef stelde. In de cyberbeveiliging groeide dit uit tot penetratietesten. AI-redteaming trekt deze traditie door naar de unieke uitdagingen van het testen van systemen die probabilistisch en ondoorzichtig zijn en in staat zijn om nieuwe uitvoer te genereren.

Hoe AI-redteaming verschilt van traditioneel beveiligingstesten

Traditionele penetratietesten en AI-redteaming delen dezelfde mindset, maar lopen sterk uiteen qua methodologie, tooling en succescriteria.

De probabilistische uitdaging

Als je een SQL-injectiekwetsbaarheid vindt, werkt die elke keer. Als je een jailbreak vindt, werkt die misschien 30% van de tijd bij temperatuur 0.7 en 5% bij temperatuur 0.3. Dit probabilistische karakter verandert alles aan de manier waarop je opdrachten scopet, succes definieert en bevindingen rapporteert.

De interface op basis van natuurlijke taal

Traditioneel beveiligingstesten draait om het misbruiken van rigide parsers: een SQL-engine, een HTTP-server, een binair formaat. AI-systemen accepteren natuurlijke taal, wat betekent dat de "parser" het model zelf is. Er is geen specificatie om te schenden, geen RFC om te misbruiken. In plaats daarvan manipuleer je het aangeleerde gedrag van een statistisch systeem.

De levenscyclus van een opdracht

Een AI-red team-opdracht volgt een gestructureerde levenscyclus. Fasen overslaan leidt tot onvolledige dekking, verspilde moeite of bevindingen waar niets mee gedaan kan worden.

1. 1

   Scoping en planning

   Bepaal wat er getest wordt, wat binnen de scope valt en hoe succes eruitziet. Dit omvat het in kaart brengen van het doel van het AI-systeem, het risicoprofiel ervan en de threat actors die je nabootst. Belangrijkste op te leveren product: een scopingdocument met overeengekomen rules of engagement.

2. 2

   Reconnaissance

   Doorgrond het doelsysteem. Welk model gebruikt het? Welke guardrails zijn er ingebouwd? Hoe werkt de API? Wat staat er in de system prompt? Deze fase combineert traditionele OSINT met AI-specifieke technieken zoals modelfingerprinting en het extraheren van de system prompt.

3. 3

   Dreigingsmodellering

   Stel op basis van de reconnaissance vast welke aanvalsvectoren het meest waarschijnlijk en het meest impactvol zijn. Geef testinspanningen prioriteit met behulp van een dreigingsmodel dat rekening houdt met de specifieke architectuur, implementatie en use case van het AI-systeem. Zie Grondbeginselen van dreigingsmodellering.

4. 4

   Uitvoeren van aanvallen

   Voer systematisch aanvallen uit op de geïdentificeerde vectoren. Dit omvat zowel creatieve handmatige aanvallen als geautomatiseerd scannen met tools als promptfoo of garak. Documenteer elke poging, ook de mislukkingen, want die zeggen iets over het robuustheidsprofiel van het systeem.

5. 5

   Analyse en validatie

   Valideer bevindingen, beoordeel de severity ervan, bepaal de grondoorzaken en classificeer ze binnen de aanvalstaxonomie. Maak onderscheid tussen nieuwe kwetsbaarheden en bekende zwaktes die niet gemitigeerd zijn.

6. 6

   Rapportage en remediëring

   Lever bruikbare rapporten op met severity-classificaties, reproductiestappen, bewijs (screenshots, logs, API-calls), analyse van de grondoorzaak en aanbevelingen voor remediëring. Het rapport moet het ontwikkelteam in staat stellen problemen op te lossen zonder dat het red team daarbij aanwezig hoeft te zijn.

7. 7

   Hertest en verificatie

   Nadat de remediëringen zijn doorgevoerd, hertest je om te verifiëren dat de fixes effectief zijn en geen nieuwe kwetsbaarheden hebben geïntroduceerd. Deze fase legt vaak bloot dat een patch de specifieke aanval wel verhelpt, maar niet de onderliggende klasse van kwetsbaarheden.

Rollen in een AI-red team

Effectief AI-redteaming vraagt om een mix van vaardigheden die zelden in één persoon verenigd zijn.

Een AI-red team-opdracht scopen

Scoping is de plek waar de meeste opdrachten slagen of mislukken. Een te krap gescopte opdracht levert oppervlakkige bevindingen op; een te ruim gescopte opdracht verspilt middelen.

Belangrijke scopingvragen

1. Wat is het doel van het AI-systeem? Een klantenservicechatbot heeft een ander risicoprofiel dan een tool voor codegeneratie of een assistent voor medische diagnoses.
2. Wat is het dreigingsmodel? Boots je een gewone gebruiker na, een vastberaden aanvaller of een tegenstander op natiestaatniveau? De geavanceerdheid van de aanvallen moet daarop aansluiten.
3. Wat valt binnen de scope? Het model zelf? De API? De omringende applicatie? De trainingsdata? De deployment-infrastructuur?
4. Wat zijn de rules of engagement? Rate limits op API-calls? Een budget voor rekenkracht? Aanvallen die buiten beschouwing blijven (bijvoorbeeld geen echte data-exfiltratie van echte gebruikersdata)?
5. Wat telt als een bevinding? Is een jailbreak die 100 pogingen vergt een geldige bevinding? En een uitvoer die op het randje van schadelijk zit?
6. Wat is de rapportagetijdlijn? Worden kritieke bevindingen meteen gemeld? Wekelijkse samenvattingen? Een eindrapport aan het eind?

Risicogebaseerde prioritering

Niet elke aanvalsvector verdient evenveel aandacht. Geef prioriteit op basis van het snijvlak van waarschijnlijkheid en impact:

Frameworks voor AI-redteaming

Verschillende frameworks bieden structuur voor AI-red team-opdrachten:

• MITRE ATLAS (Adversarial Threat Landscape for AI Systems) biedt een kennisbank van adversarial technieken, geordend per tactiek, vergelijkbaar met ATT&CK voor traditionele cyberbeveiliging
• OWASP Top 10 for LLM Applications brengt de meest kritieke beveiligingsrisico's in kaart die specifiek zijn voor LLM-gebaseerde applicaties
• NIST AI Risk Management Framework biedt een breder governanceframework voor AI-risico's dat redteaming plaatst binnen het organisatorische risicobeheer
• Microsoft AI Red Team Framework beschrijft de interne aanpak van Microsoft voor het redteamen van AI-systemen, met lessen uit het testen van Copilot en andere producten

Gerelateerde onderwerpen

• Taxonomie van AI-aanvallen — aanvallen categoriseren naar doelwit, techniek en impact
• Dreigingsmodellering voor AI — assets, dreigingen en aanvalsvectoren in kaart brengen
• Ethiek van AI-redteaming — verantwoorde testpraktijken
• Juridisch landschap — autorisatie en juridische overwegingen

Referenties

• "MITRE ATLAS: Adversarial Threat Landscape for Artificial-Intelligence Systems" - MITRE Corporation (2023) - Uitgebreide kennisbank van adversarial tactieken en technieken voor AI-systemen, gemodelleerd naar het ATT&CK-framework
• "OWASP Top 10 for LLM Applications" - OWASP (2025) - Industriestandaard voor de classificatie van de meest kritieke beveiligingsrisico's in LLM-gebaseerde applicaties
• "AI Risk Management Framework" - NIST (2024) - Federaal framework voor het beheren van risico's die samenhangen met AI-systemen gedurende hun hele levenscyclus
• "Microsoft AI Red Team" - Microsoft (2024) - Lessen uit het redteamen van grootschalige AI-systemen, waaronder GPT-4 en Copilot