Darwinisme blijkt ook in het digitale domein effectief. De veiligheidsmaatregelen voor AI-gebruik blijken kwetsbaar voor algoritmen die op basis van natuurlijke selectie zichzelf optimaliseren. Onderzoek van Palo Alto Networks’ Unit 42 laat zien dat LLM’s nog een lange weg te gaan hebben om vertrouwd te worden in IT-omgevingen.
Stel dat je een cyberaanvaller bent. AI-modellen zijn een tool voor jou zoals tevens geldt voor legitieme IT-teams en securityexperts. Maar jouw doel is complex, zeker als je een LLM van een organisatie tegen de eigen omgeving kan inzetten. Allerlei AI-agents die klantenservices bijstaan, HR-afdelingen voorzien van informatie en automatisch financiële rapporten opzetten, raken waardevolle informatie. Een aanvaller die uit is op deze data, kan de modellen achter deze agents om de tuin leiden. Normaliter moeten securitytools en AI-‘vangrails’ dit voorkomen. Dat laatste aspect, feitelijk het vertellen aan een LLM dat het zich wenselijk moet gedragen, blijkt uit onderzoek van Unit 42 op verschillende manieren te omzeilen.
Fuzzing 2.0
Vraag ChatGPT, Gemini of Claude om hoe je een bom zou maken en je krijgt (als het goed is) op geen enkele manier nuttige informatie hierover. Sterker nog, deze chatbots hebben instructies ontvangen om schadelijke verzoeken van alle soorten en maten te weigeren. Zelfs slinkse manieren om die instructie te omzeilen, slagen idealiter niet. De fundamentele aard van LLM’s is echter niet deterministisch. Wees onopvallend genoeg met je verzoek, geef misleidende instructies die eerdere veiligheidsregels tegenspreken of exploiteer onverwachte kwetsbaarheden en je kunt alsnog een LLM voor malafide doeleinden inzetten.
Het verwateren of herformuleren van een kwaadaardig verozek heet ‘fuzzing’ en is in feite een woordspelletje. Een bepaalde combinatie van woorden of tekens kan op den duur een zwakke plek onthullen. Naarmate LLM’s robuuster zijn geworden tegen deze kwaadaardige verzoeken, is de slaagkans voor kwaadwillenden kleiner. Maar hoe meet je deze robuustheid? En hoe versterk je deze ‘fuzzing’?
Zoals Unit 42 aangeeft is fuzzing te automatiseren. Het genereren van nieuwe potentieel succesvolle exploitaties is net zo goed door een LLM uit te voeren als de reactie erop. Toch is er een extra stap nodig om fuzzing zeer daadkrachtig te maken. Het is een evolutionaire ontwikkeling; natuurlijke selectie kan securityonderzoekers (en cybercriminelen) assisteren. Wat als de fuzzing-pogingen worden beoordeeld op basis van hun succesvolle pogingen, of succesvolle stappen richting een exploitatie van een LLM?
Genetische manipulatie
Een genetisch algoritme van Unit 42 selecteert prompts die op willekeurige wijze worden aangepast, net als dat het DNA van een organisme afwijkt van de ouders. Op de lange termijn verschijnen bepaalde evolutionair voordelige karaktertrekken automatisch, als de selectieprocedure ze maar eruitpikt. In een genetisch algoritme zijn de ‘chromosomen’ dus willekeurig, maar de selectie van effectieve chromosomen niet. Een volgende generatie muteert op basis van de effectievere fuzzing prompts, maar behoudt de kenmerken ervan grotendeels. Enkele, wellicht vele, generaties verder is een zeer succesvolle kwaadaardige prompt ontstaan die mogelijk totaal niet te herkennen is uit de originele prompts.
De terminologie bij cybersecurity is net wat anders dan binnen de biologie. Bij Unit 42 zijn het niet chromosomen, maar woorden, leestekens en de volgorde hiervan die evolueren in het genetisch algoritme. Elke generatie van een nieuwe prompt kan een extra woord, zinsnede of regel toevoegen of juist elimineren. Hoe hoger de ‘fitness’, ofwel de kans op succesvolle ondermijning van AI-vangrails, hoe dichter de securityonderzoekers bij een krachtige fuzzing prompt komen.
Unit 42 ontdekte dat het schrikbarend snel tot een succesvolle malafide prompt kwam. Slechts 100 generaties waren nodig om enkele exploitaties van populaire LLM’s mogelijk te maken. Die doorbraak wordt ook wel een ‘jailbreak’ genoemd, aangezien het AI-model net als een besturingssysteem op het punt komt waarbij het iets kan uitvoeren waar het expliciet niet voor bedoeld was.
Lees ook: Hoe Nederland binnen 300 dagen digitaal lamgelegd wordt
Bommen, napalm, munitie en torpedo’s
AI vragen om een bom te maken is verre van de enige manier om een LLM te misbruiken. Veel waarschijnlijker is dat een kwaadwillende een AI-agent wil overhalen om gevoelige data door te spelen, te verwijderen of te voorzien van ransomware. Toch gebruikte Unit 42 precies die bom-casus om hun fuzzing-algoritme in extremis te testen. Zowel closed-source als open-source modellen blijken vatbaar te zijn voor de exploitatie. Met andere woorden: alle geteste LLM’s bevatten informatie over explosieven en delen deze onder specifieke omstandigheden.
Zelfs de meest geavanceerde closed-source modellen zijn gevoelig voor fuzzing op basis van evolutie. In het onderzoek van Unit 42 wordt de naam van de geteste modellen niet gedeeld. Toch kunnen we op basis van de methodologie ervan uitgaan dat LLM’s een fundamentele zwakte kennen als ze gevaarlijke informatie ‘kennen’. Met andere woorden: ergens in de trainingsdata van Google, Anthropic en OpenAI zit potentieel schadelijke kennis die via systeeminstructies voor gewone gebruikers onbereikbaar wordt gemaakt. Wees vernuftig genoeg met je prompting en je trekt die data uit het model.
Unit 42 geeft aan dat contentfilters juist gevoelig zijn voor de exploitatie ervan. Omdat de taalpatronen voor schadelijke prompts te variëren zijn, vliegt er altijd wel een input onder de radar. Vangrails moeten daardoor geëvalueerd worden als systemen die door vijanden worden getest, stellen de onderzoekers. We mogen er niet vanuit gaan dat ze effectief zijn omdat klassieke, welbekende voorbeelden geblokkeerd worden.
Robuustheid kent veel kanten
De onderzoekers laten pijnlijk zien dat alle AI-beschermingslagen te omzeilen zijn. Ook is het gebruik van een zakelijke AI-tool misschien beperkt (denk aan het omzetten van spraak naar taal of het invoeren van klantenservice-tickets), maar de exploitatie kan daar voorbij reiken. Denk aan een aanvaller die een chatbot voor klantenservice kan instrueren om gevoelige informatie te delen over de eigen infrastructuur, of door het contact te laten leggen met een API die niet expliciet geblokkeerd is.
Het expliciet inperken van de schaal van een AI-systeem kan helpen, stelt het Palo Alto Networks Unit 42-team. Daarnaast zijn robuuste controlemechanismen nodig die meerdere signalen oppikken, niet alleen bepaalde woorden of zinnen. Allerlei variaties moeten net zo goed van een blokkade worden voorzien, bijvoorbeeld door red teaming los te laten met continu willekeurig aangepaste prompts.
Ander advies van Unit 42 is opvallend traditioneel. Input van eindgebruikers is standaard niet te vertrouwen en moet geïsoleerd zijn. Outputs moeten aan bedrijfsbeleid voldoen net als geldt voor menselijke gebruikers die extern contact hebben. Het monitoren en loggen van misbruik van API’s en AI-systemen dient opgezet te zijn, bijvoorbeeld om te zien of aanvallers hun prompts aan het verfijnen zijn voor kwaadaardige doeleinden. Uiteindelijk begint geavanceerde AI-security bij het simpele feit dat je de basis op orde moet hebben. Denk aan sterke authenticatie, autorisatie, rate limiting en een zero-trust, least-privilege architectuur.