When Explanations Help or Harm Network Intrusion Alert Triage: A Distribution-Conditional Benchmark

In de hooggestoken wereld van computerbeveiliging stroomt er elke seconde een constante stroom digitaal verkeer door netwerken. Het grootste deel van dit verkeer is onschadelijk, maar verborgen binnenin zijn pogingen om in te breken, gegevens te stelen of diensten te verstoren. Om deze indringers te vangen, gebruiken organisaties geautomatiseerde systemen die fungeren als digitale wachters. Deze systemen scannen voortdurend de datastroom op zoek naar patronen die verdacht lijken. Wanneer ze iets ongewoons opmerken, slaan ze alarm. Deze systemen zijn echter niet perfect; ze genereren vaak duizenden valse alarmen, waarbij normale activiteit als een bedreiging wordt gemarkeerd. Dit creëert een enorme achterstand voor menselijke beveiligingsanalisten, die door de ruis moeten zeven om het echte gevaar te vinden. De cruciale vraag voor deze teams is niet alleen of het systeem een aanval kan detecteren, maar of de lijst met alarmen die het produceert de meest gevaarlijke dreigingen helemaal bovenaan zet, waar een vermoeide analist ze als eerste kan zien.

Jarenlang was een populair idee in het vakgebied van kunstmatige intelligentie om "uitleg" te gebruiken om dit probleem op te lossen. De logica is simpel: als een computer een mens kan vertellen waarom het een specifiek alarm heeft afgegeven, kan de mens het meer vertrouwen en beter prioriteren. Stel je een beveiligingsbeambte voor die niet alleen naar een verdachte persoon wijst, maar ook uitlegt: "Ik houd hem in de gaten omdat hij een grote tas vasthoudt en snel beweegt." De hoop is dat het toevoegen van deze redenering aan de alarmenlijst analisten helpt om echte aanvallen sneller te vinden. Maar deze aanname is nooit rigoureus getest in de chaotische realiteit van netwerkbeveiliging. Helpt het toevoegen van een uitleg daadwerkelijk, of verwart het het systeem en duwt het de echte dreigingen verder naar beneden in de lijst?

Een team van onderzoekers van universiteiten in Turkije zette zich af om deze vraag te beantwoorden met een zorgvuldig gecontroleerd experiment. Ze vroegen niet simpelweg of uitleg "goed" of "slecht" was. In plaats daarvan bouwden ze een testomgeving om precies te zien wanneer uitleg helpt, wanneer het niets doet en wanneer het de boel juist verslechtert. Ze begonnen met drie verschillende soorten geautomatiseerde detectoren, die elk getraind waren om ongebruikelijke netwerkactiviteit te herkennen zonder te worden verteld naar welke specifieke aanvallen ze moesten zoeken. Deze detectoren genereerden een lijst met alarmen gebaseerd puur op hoe vreemd de gegevens eruitzagen. De onderzoekers namen deze lijst vervolgens en pasten een specifieke regel toe: ze voegden een "handtekening" toe aan de uitleg. Deze handtekening was een vooraf gedefinieerde set kenmerken die overeenkwamen met een specifiek type aanval, zoals een Denial of Service-aanval, die wordt gekenmerkt door een enorme vloed aan gegevens.

De onderzoekers testten vervolgens of het verhogen van de prioriteit van alarmen die overeenkwamen met deze handtekening de volgorde van de lijst daadwerkelijk verbeterde. Ze gebruikten een methode genaamd SHAP, die een beslissing van een computer ontleedt in de bijdrage van elk datapunt, om te zien of de computer zich op de juiste zaken concentreerde. Ze vergeleken de oorspronkelijke lijst, geordend enkel op hoe vreemd de gegevens waren, met een nieuwe lijst waarbij alarmen die overeenkwamen met de aanvals-handtekening een lichte boost kregen. Ze voerden deze test uit over duizenden scenario's, waarbij ze verschillende typen aanvallen, verschillende detectoren en verschillende groottes van lijsten gebruikten om te zien of de resultaten standhielden.

De bevindingen waren verrassend en genuanceerd. De onderzoekers ontdekten dat het toevoegen van uitleg de lijst niet automatisch verbeterde. Sterker nog, voor sommige van de meest voorkomende typen aanvallen, specifiek de Denial of Service-floods, maakte de uitleg de situatie zelfs slechter. Wanneer de onderzoekers de regel van de uitleg toepasten op deze aanvallen, werden de echte dreigingen dieper in de lijst geduwd, waardoor ze moeilijker te vinden waren voor een analist. Dit gebeurde omdat de geautomatiseerde detectoren al zeer goed waren in het opsporen van deze floods op eigen kracht, waardoor ze bovenaan de lijst stonden. De regel van de uitleg, die probeerde behulpzaam te zijn, verstoorde onbedoeld de lijst en verplaatste de meest urgente alarmen naar beneden.

Echter, het verhaal was niet geheel negatief. In een paar specifieke gevallen hielp de uitleg wel. Voor bepaalde typen aanvallen en met specifieke detectoren slaagde de uitleg erin om de juiste alarmen bovenaan te houden. Maar deze successen waren zeldzaam en fragiel. De onderzoekers ontdekten dat de uitkomst volledig afhing van de specifieke combinatie van de gebruikte detector, het type aanval en het exacte moment waarop de gegevens werden verzameld. Wat werkte voor het ene type aanval, faalde voor een ander. Wat werkte op de ene dag met de data, werkte niet op de volgende dag.

De studie onderzocht ook of deze resultaten stand zouden houden in de echte wereld, waar gegevens rommelig en onvoorspelbaar zijn. Ze testten hun methoden op verschillende datasets, waaronder enkele die veel groter en complexer waren dan de initiële test. Ze kwamen tot de conclusie dat het patroon consistent bleef: de regel van de uitleg was geen universele oplossing. In sommige moderne datasets hielp het enigszins, maar in andere veroorzaakte het schade. Cruciaal was dat ze probeerden een "selector" te bouwen die automatisch kon beslissen wanneer de uitleg te gebruiken en wanneer vast te houden aan de eenvoudige lijst. Ze ontdekten dat er geen dergelijke selector gebouwd kon worden die veilig genoeg was om te gebruiken zonder constante menselijke supervisie. De regel die werkte in de trainingsdata, faalde vaak wanneer deze werd toegepast op nieuwe, ongeziene data.

De onderzoekers concludeerden dat het idee om simpelweg uitleg toe te voegen aan beveiligingsmeldingen geen wondermiddel is. Hoewel uitleg nuttig kan zijn om te begrijpen waarom een computer een beslissing heeft genomen, is het riskant om uitleg te gebruiken om automatisch een lijst met alarmen te herordenen. De studie toonde aan dat in veel gevallen de eenvoudige lijst gebaseerd op de ruwe "vreemdheidsscore" eigenlijk beter was dan de door uitleg gemodificeerde lijst. De beste aanpak, suggereren de onderzoekers, is om de uitleg als een secundair hulpmiddel te behandelen. Beveiligingsteams zouden de oorspronkelijke lijst als de primaire manier moeten gebruiken om werk te prioriteren, en de uitleg alleen te gebruiken als een manier om een specifiek alarm te controleren of te begrijpen, in plaats van de uitleg de volledige volgorde van de lijst te laten veranderen.

Dit werk biedt een heldere, op bewijs gebaseerde kaart voor de toekomst van beveiligingsoperaties. Het vertelt ons dat we er niet vanuit kunnen gaan dat meer informatie altijd leidt tot betere beslissingen. Soms kan de extra laag van uitleg de belangrijkste signalen vertroebelen. De onderzoekers hebben aangetoond dat we, voordat we een systeem adopteren dat alarmen opnieuw rangschikt op basis van uitleg, dit rigoureus in onze eigen omgeving moeten testen. We moeten verifiëren of de uitleg daadwerkelijk helpt om onze specifieke detectoren onze specifieke dreigingen te laten vinden. Zonder deze lokale validatie kan de poging om beveiliging slimmer te maken met uitleg, het juist trager en minder effectief maken. De weg vooruit is niet om blindelings het redeneren van de computer te vertrouwen, maar om het voorzichtig te gebruiken, wetende wanneer het helpt en wanneer het schaadt.