Generatieve AI-modellen als ondersteuning voor security-analisten
Het belangrijkste in het kort
- Generatieve AI-modellen versnellen het werk van de security-analist het sterkst daar waar het volume groot is en de context saai: logregels, broncode en scanuitvoer
- In ons onderzoek combineerden we LLM's met MobSF en Semgrep om kwetsbaarheden in Android-applicaties te classificeren volgens de OWASP Mobile Top 10
- Bij de analyse van securitylogs uit Suricata en Sysmon daalde de tijd tot een geclassificeerde bevinding fors, maar sterk versluierde aanvallen bleven buiten beeld
- Onterechte meldingen, kosten en gegevensbescherming zijn de drie beperkingen die u vooraf moet beleggen, niet achteraf
- AVG art. 32 lid 1 sub d vraagt om periodiek testen, beoordelen en evalueren van uw maatregelen – een AI-hulpmiddel is geen bewijs van doeltreffendheid, de toetsing wel
- De eindconclusie is onveranderd: AI verschuift het werk van de analist naar boven, maar het oordeel blijft menselijk
Kunstmatige intelligentie verandert het securitylandschap, en een van de meest veelbelovende ontwikkelingen is de inzet van generatieve AI-modellen ter ondersteuning van security-analisten. In ons onderzoek Using Generative AI Models to Support Cybersecurity Analysts hebben we onderzocht hoe grote taalmodellen (LLM’s) in securityprocessen kunnen worden ingebed om dreigingsdetectie, kwetsbaarheidsonderzoek en loganalyse te versterken.
Dit artikel vat de opzet, de uitkomsten en vooral de grenzen van dat onderzoek samen – en plaatst het in de Nederlandse context, waarin toezichthouders en opdrachtgevers steeds vaker willen weten wat er precies met hun gegevens gebeurt zodra er een model bij betrokken raakt.
Waarom generatieve AI voor cybersecurity?
Security-analisten werken met een hoeveelheid gegevens die geen mens in zijn geheel kan overzien: gebeurtenislogs, configuratie-instellingen, rapporten uit een kwetsbaarheidsscan, malware-analyses en de uitvoer van een tiental scanners die elkaar deels overlappen. Traditionele hulpmiddelen zijn goed in verzamelen en normaliseren. Het interpreteren blijft handwerk, en daar gaan de uren zitten.
Generatieve AI verschuift die verhouding op vier punten:
- het analyseren van securitylogs automatiseren, zodat afwijkingen sneller bovenkomen
- kwetsbaarheden in applicaties efficiënter opsporen en beschrijven
- pentestwerk versterken door mogelijke exploitatiepaden vooraf te wegen
- context toevoegen op basis van gevestigde raamwerken zoals de OWASP Mobile Top 10 en MITRE ATT&CK
Het woord dat in die vier punten telkens ontbreekt, is vervangen. Een model dat een logregel classificeert, neemt geen beslissing over een incident. Het levert een voorstel met een onderbouwing, en dat voorstel is precies zo veel waard als de analist die het naast de werkelijke omgeving legt.
Ons onderzoek: twee praktijkcasussen
Het onderzoek richtte zich op twee toepassingen waarin een LLM een specialist meetbaar werk uit handen kan nemen.
1. Kwetsbaarheden opsporen in Android-applicaties
We bouwden een opstelling waarin LLM’s samenwerken met securitytools als MobSF (Mobile Security Framework) en Semgrep om Android-applicaties op kwetsbaarheden te onderzoeken. In plaats van uitsluitend op statische analyse te leunen, gebruikten we AI-gestuurde contextanalyse om:
- de broncode van de applicatie te doorlopen
- beveiligingsfouten te herkennen aan de hand van vooraf gedefinieerde regels
- bevindingen te classificeren volgens de OWASP Mobile Top 10
Belangrijkste bevinding: LLM’s verhoogden zowel de snelheid als de nauwkeurigheid van het opsporen van kwetsbaarheden, maar introduceerden ook onterechte meldingen. Menselijke verificatie bleef in alle gevallen noodzakelijk.
Dat sluit aan bij wat we in de praktijk zien bij een pentest van mobiele applicaties: een scanner die tweehonderd bevindingen oplevert, is minder waard dan een analist die er twaalf overhoudt en van elk kan uitleggen wat een aanvaller ermee bereikt. Onze werkwijze rond de OWASP-methodieken is daar expliciet op ingericht.
2. Analyse van securitylogs voor incidentdetectie
In de tweede casus onderzochten we hoe LLM’s kunnen helpen bij het doorgronden van netwerk- en systeemlogs uit hulpmiddelen als Suricata (IDS/IPS) en Sysmon (monitoring op Windows). Het doel was om securitymeldingen te correleren met werkelijke dreigingen, onterechte meldingen weg te filteren en incidenten te koppelen aan het MITRE ATT&CK-raamwerk.
Belangrijkste bevinding: AI-ondersteunde analyse verkortte de tijd die nodig is om een dreiging te herkennen en te classificeren aanzienlijk, maar de modellen liepen vast op sterk versluierde of samengestelde aanvallen.
Logs uit Sysmon bevatten per definitie herleidbare gegevens: accountnamen, werkstations, tijdstippen. Wie daar een model op loslaat, verwerkt persoonsgegevens. Wij hanteren daarom één vaste lijn, zowel in onderzoek als in opdrachten: resultaten worden uitsluitend geaggregeerd gerapporteerd; individuele medewerkers worden niet beoordeeld of geïdentificeerd. Een loganalyse toetst of uw detectie- en reactiemaatregelen werken, niet of een collega een verkeerde klik heeft gedaan.
Beperkingen en risico’s
Het onderzoek liet ruimte zien, maar geen vrijbrief. Drie beperkingen verdienen het om vóór de eerste pilot te worden belegd.
| Beperking | Wat er misgaat | Wat u ertegen doet |
|---|---|---|
| Onterechte meldingen | Het model interpreteert een logregel of codefragment verkeerd en genereert meldingen die nergens op slaan – of, ernstiger, verklaart een echte melding als ruis | Elke AI-bevinding een menselijke verificatiestap geven en de trefzekerheid per categorie meten in plaats van in het algemeen |
| Kosten | Grote datasets door een LLM halen is duur, en logvolumes groeien harder dan budgetten | Vooraf filteren met klassieke regels, alleen de resterende gevallen aan het model voorleggen |
| Gegevensbescherming en aanvallen op het model zelf | Logs en broncode verlaten uw omgeving; daarnaast zijn prompt injection en datavergiftiging reële aanvalstechnieken tegen het model | Verwerkersafspraken en dataminimalisatie vastleggen, en de AI-koppeling zelf als aanvalsoppervlak testen |
Die laatste rij is geen theorie. Zodra een model toegang krijgt tot uw gegevens of tot een actie in uw omgeving, is het een component met rechten – en dus iets wat getest hoort te worden. Daarvoor bestaat bij ons een aparte dienst: pentest van AI- en LLM-integraties.
Wat het Nederlandse kader hiervan vindt
AI verandert niets aan de verplichtingen die er al liggen. Het verandert wel waar uw gegevens naartoe gaan en wie u daarover bevraagt.
De enige Europese bepaling die periodiek testen met zoveel woorden noemt, is AVG art. 32 lid 1 sub d: waar passend hoort er “een procedure voor het op gezette tijdstippen testen, beoordelen en evalueren van de doeltreffendheid van de technische en organisatorische maatregelen” te zijn. Let op de formulering – het gaat om het aantoonbaar toetsen van de doeltreffendheid van uw maatregelen. Een AI-hulpmiddel inzetten is geen bewijs van doeltreffendheid; het toetsen van de uitkomsten wel. Wie een LLM in de detectieketen zet, breidt daarmee de reikwijdte uit van wat er getoetst moet worden.
De Cyberbeveiligingswet, de Nederlandse omzetting van NIS2, treedt in werking op 15 augustus 2026 en raakt naar schatting 8.000 organisaties. De wet kent een registratieplicht via mijn.ncsc.nl, een zorgplicht, een meldplicht binnen 24 uur en een uitdrukkelijke verantwoordelijkheid van het bestuur, inclusief bestuurderstraining (art. 24 lid 5). Wat de zorgplicht vraagt is een risicoanalyse en daarop passende en evenredige maatregelen – geen pentest. Wie u vertelt dat de Cyberbeveiligingswet of NIS2 een pentest voorschrijft, leest de wet niet. Dat een pentest in de praktijk vaak de meest overtuigende manier is om die maatregelen te onderbouwen, is iets anders dan een wettelijke eis. De RDI houdt toezicht op digitale infrastructuur, het NCSC is het CSIRT. Art. 7 zondert financiële entiteiten uit; voor hen geldt DORA, en daar is testen wél een harde verplichting. Hetzelfde geldt voor leveranciers van de overheid onder de BIO.
Gaat er onverhoopt toch iets mis met persoonsgegevens – bijvoorbeeld doordat logs met herleidbare gegevens bij een externe modelaanbieder terechtkomen – dan meldt u het datalek binnen 72 uur bij de Autoriteit Persoonsgegevens (AVG art. 33).
Tot slot de grondslag onder het testwerk zelf. Ongeautoriseerde toegang tot een systeem is in Nederland strafbaar als computervredebreuk, art. 138ab Wetboek van Strafrecht. Wat een test rechtmatig maakt is een schriftelijke opdracht met een afgebakende scope – niet een keurmerk, niet een register. Voor pentesters bestaat in Nederland geen register en geen vergunning; hoe wij dat organiseren, leest u in wat een pentest precies is.
Dit artikel is informatief van aard en vormt geen juridisch advies. Of en hoe de genoemde verplichtingen op uw organisatie van toepassing zijn, hangt af van uw sector, omvang en rol in de keten.
De toekomst van AI in cybersecurity
Ondanks deze beperkingen ontwikkelt AI-ondersteunde security zich snel. Verfijnde LLM’s, modellen die specifiek op securitydata zijn getraind en vormen van adaptief leren in realtime kunnen de manier waarop we dreigingen detecteren, analyseren en afhandelen ingrijpend veranderen.
De richting die wij aanhouden is nuchter: laat het model het volume doen en de mens het oordeel. Een LLM is uitstekend in het samenvatten van tienduizend logregels tot vijftien kandidaten. Het is slecht in het inschatten wat die vijftien betekenen voor úw omgeving, uw ketenpartners en uw meldplicht. Die weging is precies het werk waarvoor u een ethische hacker inschakelt.
Wilt u het volledige onderzoek lezen, dan vindt u het artikel hier (Engelstalig):
Nu AI een vast hulpmiddel wordt voor securityprofessionals, bepaalt het evenwicht tussen automatisering en menselijke expertise of we zowel efficiënt als accuraat blijven in de verdediging tegen cyberdreigingen.
Wilt u weten wat een LLM-integratie in uw eigen omgeving aan aanvalsoppervlak toevoegt, of wat een pentest daar zou opleveren? Plan dan een gratis adviesgesprek – vrijblijvend, en met een concreet voorstel voor scope en doorlooptijd.
