AI-dreigingsmodellen: white-box, black-box en grey-box
Toegangsniveaus bij het testen van AI-beveiliging — wat op elk niveau mogelijk is, realistische scenario's en een vergelijking met traditionele dreigingsmodellering in de security.
Waarom dreigingsmodellen ertoe doen
Een dreigingsmodel bepaalt wat een aanvaller kan zien, doen en weten. Zonder een duidelijk dreigingsmodel verspillen red team-opdrachten tijd aan onrealistische aanvallen of missen ze juist kritieke realistische aanvallen.
In AI-beveiliging bepaalt het toegangsniveau het hele aanvalslandschap.
De drie toegangsniveaus
Black-box-toegang
De aanvaller kan alleen via de normale interface met het systeem communiceren — input versturen en output observeren.
| Eigenschap | Details |
|---|---|
| Modelgewichten | Geen toegang |
| Architectuur | Onbekend (mogelijk te raden) |
| Systeemprompt | Verborgen (extractiepogingen mogelijk) |
| API-parameters | Alleen die de interface blootstelt |
| Trainingsdata | Geen toegang |
| Outputdetails | Alleen het uiteindelijke tekstantwoord |
Beschikbare aanvallen:
| Aanvalscategorie | Technieken |
|---|---|
| Prompt injection | Directe injectie, rollenspel, few-shot steering |
| Extractie van de systeemprompt | Het model via social engineering zijn instructies laten onthullen |
| Jailbreaken | Handmatig prompts maken, geautomatiseerd fuzzen |
| Data-extractie | Sonderen naar onthouden trainingsdata |
| Gedragstesten | Testen op bias, beleidsovertredingen, inconsistenties |
| Best-of-N-sampling | Herhaalde queries om stochastische omzeilingen te vinden |
Realistische scenario's: een eindgebruiker die een chatbot aanvalt, externe penetratietesten, het aanvallen van het product van een concurrent.
Grey-box-toegang
De aanvaller heeft gedeeltelijke kennis — misschien de modelnaam, API-documentatie, de systeemprompt of enkele architecturale details — maar niet de volledige modelgewichten.
| Eigenschap | Details |
|---|---|
| Modelgewichten | Geen toegang |
| Architectuur | Bekend (modelnaam, versie) |
| Systeemprompt | Mogelijk bekend (gelekt, gedocumenteerd) |
| API-parameters | Volledige API-documentatie beschikbaar |
| Trainingsdata | Gedeeltelijke kennis (openbare bronnen van trainingsdata) |
| Outputdetails | Kan logprobs en tokentellingen bevatten |
Aanvullende aanvallen (bovenop black-box):
| Aanvalscategorie | Technieken |
|---|---|
| Parametermanipulatie | logit_bias, temperatuur, stopsequenties |
| Logprob-analyse | Extractie van tokenkansen, sonderen van zekerheid |
| Transfer-aanvallen | Aanvallen maken op vergelijkbare open modellen, testen op het doelwit |
| Misbruik van de fine-tuning-API | Fine-tuning-data vergiftigen als er een fine-tuning-API beschikbaar is |
| Misbruik van tool-schema's | Input maken die gericht is op bekende tooldefinities |
Realistische scenario's: een ontwikkelaar die het AI-product van zijn eigen bedrijf aanvalt, een onderzoeker met API-toegang en documentatie, een insider met kennis van de uitrol.
White-box-toegang
Volledige toegang tot modelgewichten, architectuur, trainingsdata en deploymentconfiguratie.
| Eigenschap | Details |
|---|---|
| Modelgewichten | Volledige toegang |
| Architectuur | Volledig bekend |
| Systeemprompt | Bekend |
| API-parameters | Allemaal toegankelijk |
| Trainingsdata | Toegankelijk (voor open modellen) |
| Outputdetails | Volledige logits, activaties, attention-gewichten |
Aanvullende aanvallen (bovenop grey-box):
| Aanvalscategorie | Technieken |
|---|---|
| Gradient-gebaseerde aanvallen | FGSM, PGD, GCG-suffixoptimalisatie |
| Activatie-analyse | Sonderen van interne representaties |
| Gewichtsmanipulatie | Modelgedrag direct wijzigen |
| Extractie van trainingsdata | Membership inference, datareconstructie |
| Mechanistische analyse | Specifieke circuits en features begrijpen |
| Inbouwen van backdoors | Gewichten wijzigen om triggers in te bouwen |
Realistische scenario's: een zelf-gehost open source-model, een AI-beveiligingsonderzoeker, een intern red team met volledige toegang tot de infrastructuur.
Vergelijking van toegangsniveaus
| Mogelijkheid | Black-box | Grey-box | White-box |
|---|---|---|---|
| Prompt injection | Ja | Ja | Ja |
| Jailbreaken | Handmatig | Semi-geautomatiseerd | Volledig geautomatiseerd (GCG) |
| Extractie van de systeemprompt | Poging via prompting | Mogelijk al bekend | Bekend |
| Gradient-gebaseerde aanvallen | Nee | Via overdracht | Direct |
| Activatie-sondering | Nee | Nee | Ja |
| Fine-tuning-aanvallen | Nee | Indien API beschikbaar | Direct |
| Data-extractie | Alleen sonderen | Verbeterd sonderen | Membership inference |
| Toolmanipulatie | Indien tools vindbaar | Bekende tool-schema's | Volledige tooltoegang |
Scenario's koppelen aan dreigingsmodellen
| Factor | Beoordeling |
|---|---|
| Toegangsniveau | Black-box |
| Doel | Jailbreak, data-extractie, misbruik |
| Mogelijkheden | Standaard API-/chattoegang, onbeperkte pogingen |
| Beperkingen | Rate limits, geen interne kennis |
| Primaire aanvallen | Prompt injection, gedragstesten, best-of-N |
| Red team-aanpak | Geautomatiseerd prompt-fuzzen, handmatige creatieve aanvallen |
| Factor | Beoordeling |
|---|---|
| Toegangsniveau | Grey-box tot white-box |
| Doel | Backdoor inbouwen, data-exfiltratie, sabotage |
| Mogelijkheden | Toegang tot code, kennis van de uitrol, toegang tot trainingsdata |
| Beperkingen | Moet detectie vermijden, mogelijk audittrails aanwezig |
| Primaire aanvallen | Poisoning, backdoor-triggers, manipulatie van prompttemplates |
| Red team-aanpak | Code review, audit van trainingsdata, testen op gedragsconsistentie |
| Factor | Beoordeling |
|---|---|
| Toegangsniveau | Wisselend — mogelijk white-box op componenten |
| Doel | Brede compromittering via gedeelde componenten |
| Mogelijkheden | Controle over een model, library of dataset |
| Beperkingen | Moet integratietests doorstaan, kan worden gedetecteerd |
| Primaire aanvallen | Modelpoisoning, manipulatie van dependencies, datacontaminatie |
| Red team-aanpak | Supply chain-audit, verificatie van modelherkomst |
AI- vs. traditionele dreigingsmodellering
AI-dreigingsmodellering bouwt voort op traditionele dreigingsmodellering in de security, maar introduceert unieke overwegingen:
| Dimensie | Traditionele security | AI-beveiliging |
|---|---|---|
| Inputvalidatie | Goed gedefinieerd (types, bereiken) | Slecht gedefinieerd (natuurlijke taal) |
| Aanvalsoppervlak | Code, netwerk, infrastructuur | + modelgedrag, trainingsdata |
| Determinisme | Zelfde input → zelfde output | Stochastische output |
| Vertrouwensgrenzen | Duidelijk (authenticatie, autorisatie) | Vervaagd (model volgt instructies, geen regels) |
| Definitie van kwetsbaarheid | Wijkt af van de specificatie | Specificatie is probabilistisch |
| Patchen | Codewijziging, deployen | Hertrainen, fine-tunen, guardrails toevoegen |
| Testen | Functioneel + penetratie | + gedragsmatig, adversarial, alignment |
STRIDE voor AI-systemen
Het traditionele STRIDE-kader, aangepast voor AI:
| Dreiging | Traditioneel | AI-specifiek |
|---|---|---|
| Spoofing | Omzeilen van authenticatie | Rolimitatie in prompts |
| Tampering | Datawijziging | Datavergiftiging in training, corruptie van geheugen |
| Repudiation | Ontkennen van acties | Stochastische output maakt reproductie lastig |
| Information Disclosure | Datalekken | Lekken via memorisatie, extractie van de systeemprompt |
| Denial of Service | Uitputting van resources | Tokenkostenaanvallen, oneindige lussen |
| Elevation of Privilege | Ongeautoriseerde toegang | Prompt injection → misbruik van tools |
Je AI-dreigingsmodel opbouwen
Identificeer het systeem
Welk deploymentpatroon? Welk model? Welke tools en datatoegang? Zie AI-systeemarchitectuur.
Definieer de tegenstander
Externe gebruiker, insider, supply chain? Welk toegangsniveau sluit aan op de realiteit?
Inventariseer aanvalsvectoren
Welke aanvallen zijn haalbaar gegeven het toegangsniveau? Gebruik de tabellen hierboven als startpunt.
Beoordeel de impact
Wat is voor elke aanvalsvector de slechtst denkbare uitkomst? Datalek, ongeautoriseerde acties, reputatieschade?
Prioriteer
Rangschik vectoren op haalbaarheid x impact. Richt de red team-inspanning op scenario's met hoge haalbaarheid en hoge impact.
Probeer het zelf
Gerelateerde onderwerpen
- Adversarial ML: kernconcepten — de aanvalstaxonomie die op elk dreigingsmodel aansluit
- Gradient-gebaseerde aanvallen uitgelegd — white-box-aanvallen in detail
- Veelvoorkomende AI-deploymentpatronen — de uitrolcontext bepaalt het dreigingsmodel
- Lab: het aanvalsoppervlak van een AI-systeem in kaart brengen — praktische oefening in dreigingsmodellering
Referenties
- "Threat Modeling: Designing for Security" - Shostack, Adam (2014) - Fundamenteel boek dat STRIDE en andere methodologieën voor dreigingsmodellering introduceert, aangepast voor AI-systemen
- "NIST AI Risk Management Framework (AI RMF 1.0)" - NIST (2023) - Federaal kader voor het identificeren, beoordelen en beheersen van AI-risico's over verschillende toegangs- en uitrolcontexten heen
- "MITRE ATLAS: Adversarial Threat Landscape for AI Systems" - MITRE (2025) - Dreigingsmatrix die adversarial technieken tegen ML-systemen catalogiseert, geordend naar toegangsniveau en aanvalsfase
- "OWASP Top 10 for LLM Applications" - OWASP (2025) - Een door de industrie gehanteerde risicoclassificatie die aansluit op verschillende dreigingsmodelscenario's voor LLM-gebaseerde applicaties
Een bedrijf zet GPT-4 via een API in als klantenservice-chatbot. Een externe aanvaller wil klantgegevens via de chatinterface achterhalen. Welk dreigingsmodel is het meest passend?