SIEM-validatie

SIEM-validatie is het doorlopend toetsen of de detectie-regels die je hebt geconfigureerd ook daadwerkelijk de aanvalstechnieken pakken die ze moeten pakken. Niet of het systeem draait, niet of er logs binnenkomen, niet of het dashboard kleurt: of een gesimuleerde aanvalstechniek tegen jouw eigen omgeving een alarm oplevert dat een analist kan opvolgen. Je voert een techniek uit, je kijkt of de regel afgaat, en als hij niet afgaat weet je waar het gat zit. Dat is de hele kern. Wat eromheen hangt, raamwerken, scenario's, cadans, rapportage, is alleen relevant zolang die kern overeind blijft.

Dit stuk gaat over een term die in de praktijk twee dingen tegelijk betekent, en daardoor verwarring veroorzaakt. Voor de een is SIEM-validatie een eenmalige tuning-exercitie na de implementatie van een nieuwe regelset. Voor de ander is het een doorlopende discipline die net zo gewoon is als het patchproces. Die twee zijn niet hetzelfde, en het verschil bepaalt of je op het moment van een echte aanval ook echt iets ziet.

Wat is SIEM-validatie eigenlijk?

Een SIEM is een platform dat logs en gebeurtenissen uit je omgeving verzamelt en er regels op toepast die alarmen genereren als een patroon overeenkomt met iets verdachts. Of die regels het juiste patroon herkennen is geen kwestie van geloof, het is een kwestie van toetsen. SIEM-validatie is de praktijk waarin je die toets structureel uitvoert: je laat een aanvalstechniek los op je eigen omgeving, je registreert wat de SIEM ervan ziet, en je vergelijkt dat met wat hij had moeten zien.

De aanleiding voor dit onderscheid is bekend voor wie het werk dichtbij meemaakt. Een SIEM-implementatie wordt opgeleverd, de leverancier toont een set use-cases die "uit de doos" werken, het team ziet alarmen verschijnen, en daarmee geldt het systeem als operationeel. Wat in die opzet ontbreekt is de vraag of de alarmen die je ziet ook de alarmen zijn die je nodig hebt. De afwezigheid van een alarm wordt stilzwijgend uitgelegd als de afwezigheid van een aanval, terwijl het ook de afwezigheid van een werkende regel kan betekenen. Validatie haalt dat onderscheid uit de aanname-sfeer en brengt het terug naar de toets.

Een gangbare taal om aanvalstechnieken systematisch te beschrijven is het MITRE ATT&CK-raamwerk. Het catalogiseert technieken die aanvallers in de praktijk gebruiken, geordend per fase van een aanval, en geeft de detectie-engineer een vocabulaire om zijn dekking in uit te drukken. Een open project als Atomic Red Team levert daarbij kant-en-klare scenario's: kleine, reproduceerbare scripts die een specifieke ATT&CK-techniek nabootsen, bedoeld om in een gecontroleerde omgeving op je eigen telemetrie los te laten. De combinatie van die twee, een taxonomie en uitvoerbare scenario's, is wat validatie van een goed bedoeld voornemen tot een werkbaar proces maakt.

De vraag die SIEM-validatie beantwoordt is daarmee scherper dan "draait onze SIEM". Het is: voor welke aanvalstechnieken hebben we een regel die hem aantoonbaar oppikt, voor welke hebben we geen regel, en voor welke hebben we een regel die niet afgaat als je de techniek uitvoert. Pas met die drie kolommen op tafel weet je waar je staat.

Waarom is "het draait dus het werkt" niet hetzelfde als detectie?

In veel organisaties wordt de gezondheid van het detectieplatform gemeten aan de hand van wat het systeem zelf laat zien: het aantal events per seconde, de retentie van de logs, de uptime van de collectoren, de hoeveelheid alarmen per week. Dat zijn nuttige operationele indicatoren, maar ze meten het verkeerde ding. Ze meten of het platform werkt, niet of de detectie werkt. Het verschil is groot genoeg om er een hele discipline omheen te bouwen.

Een SIEM kan technisch perfect functioneren en tegelijk blind zijn voor de technieken die er feitelijk toe doen in jouw omgeving. Dat gebeurt vaker dan het zou moeten. Een regel die ooit goed werkte breekt na een upgrade van het brononderdeel waar hij op steunt, een log-bron stopt onopgemerkt met aanleveren omdat een inloggegevens is verlopen, een ATT&CK-techniek wordt door aanvallers aangepast en de regel die hem ving pakt de nieuwe variant niet meer. In al die gevallen ziet het dashboard er prima uit. De gezondheid van het platform wordt gerapporteerd als groen, de gezondheid van de detectie is dat niet.

Het Nationaal Cyber Security Centrum benadrukt in zijn handreikingen voor detectie en respons dat detectiecapaciteit een ingerichte functie is, geen bijproduct van een tool-aanschaf. Het NIST Cybersecurity Framework plaatst Detect en Respond als eigen functies naast Protect, met expliciete eisen aan het continu verbeteren en testen van detectiemechanismen. Beide leggen het accent waar het hoort: niet bij de aanwezigheid van een SIEM, maar bij de aantoonbare werking van wat er in detecteert. Een organisatie die uitsluitend platformmetrics rapporteert, beantwoordt geen van beide raamwerken op het punt waar het hen werkelijk om gaat.

Validatie is de manier waarop je dat verschil zichtbaar maakt. Het is geen audit-instrument om iets aan een derde te bewijzen, het is een werkmethode voor de detectie-engineer en de SOC-lead om zelf te zien waar hun systeem stiltes vertoont die niet door afwezigheid van dreiging te verklaren zijn. Stilte zegt op zichzelf niets. Stilte plus een uitgevoerde techniek die geen alarm gaf, zegt alles.

Hoe organiseer je validatie zonder een tweede SIEM te kopen?

De praktische zorg die hier vaak achteraan komt is voorspelbaar: dit klinkt als nóg een tool, nóg een project, nóg een budgetregel. Dat hoeft het niet te zijn. Validatie is een gewoonte, geen platform. Wat het wel vraagt is dat een paar dingen op hun plek staan en dat ze in een vaste cadans terugkeren.

Een werkbare opzet bestaat uit vier onderdelen:

Een afgesproken dekkingslijst. Welke ATT&CK-technieken zijn voor jouw omgeving relevant, op basis van je dreigingsbeeld, je bedrijfsmodel en de logbronnen die je hebt. Niet de volledige catalogus, dat is een illusie. Een afgebakende lijst die je expliciet onderhoudt, met een reden per techniek waarom hij er wel of niet op staat.

Reproduceerbare scenario's. Voor elke techniek op de lijst een uitvoerbaar scenario dat hem nabootst in een gecontroleerde testopstelling of, met afspraken, in productie. Open materiaal als Atomic Red Team biedt een startpunt; eigen scenario's vullen aan waar je omgeving afwijkt.

Een vaste cadans. Validatie die alleen plaatsvindt na incidenten of voor een audit is geen validatie, het is brandblussen. Een maandelijks of kwartaaltempo waarin een vast deel van de dekkingslijst wordt nagelopen, levert vergelijkbare meetpunten op en maakt achteruitgang zichtbaar voor hij pijn doet.

Een terugkoppeling naar detectie-engineering. Elke gemiste techniek leidt tot een concrete actie: regel aanpassen, log-bron toevoegen, scenario aanscherpen, of bewust accepteren met een beargumenteerde reden. Een validatie zonder terugkoppeling produceert lijstjes; een validatie mét terugkoppeling produceert betere detectie.

Wat hier niet bij zit is een tweede SIEM, een breach-and-attack-simulation-platform of een aparte testomgeving die een kopie is van productie. Die dingen kunnen waarde toevoegen, maar zijn niet de voorwaarde. De voorwaarde is dat iemand verantwoordelijk is, dat de cadans staat, en dat de uitkomsten landen waar ze landen moeten. Zonder die drie helpt het duurste platform niet, mét die drie levert een eenvoudige opzet al binnen een kwartaal zichtbaar resultaat.

Wat dit betekent voor de keuze die jij maakt

Voor de CISO die hiermee intern het gesprek opent, is de bruikbare samenvatting dat SIEM-validatie geen nieuw aankoop-onderwerp is maar een werkgewoonte. De vraag aan je detectie-team is niet "draait de SIEM" maar "wanneer hebben we voor het laatst aantoonbaar getoetst of techniek X tot een alarm leidt, en wat was de uitkomst". De vraag aan je leverancier is niet "welke use-cases zitten erin" maar "hoe weet ik volgend kwartaal nog steeds dat ze werken". De vraag aan je board, als die er ooit naar vraagt, is niet "hebben we een SIEM" maar "welke aanvalstechnieken hebben we aantoonbaar in beeld, welke niet, en hoe verandert dat over tijd".

Dat is een ander gesprek dan het gesprek dat in de meeste organisaties gevoerd wordt. Het verschuift de meting van platformgezondheid naar detectiegezondheid, en het maakt de afwezigheid van een alarm tot een vraag in plaats van een geruststelling. Daar hoort ook een toets bij die zelden hardop wordt gesteld: van wie blijft de uitkomst. Een validatie die de regels, de scenario's en de rapportage impliciet bij de leverancier laat, levert minder op dan een validatie waarvan de dekkingslijst, de meetpunten en de vervolgkeuzes van jou blijven. Een partij die toevallig altijd uitkomt bij het uitbreiden van haar eigen platform, voert geen onafhankelijke validatie uit. Zij voert een verkoopgesprek met een rapport eromheen.

De logische volgende stap is dan ook niet een aanvraag voor een validatie-product, maar een eerlijke inventarisatie van waar je nu staat: heb je een afgesproken dekkingslijst, heb je een cadans, heb je een terugkoppeling naar detectie-engineering. Als een van die drie ontbreekt, is dat het gesprek dat eerst gevoerd moet worden, intern en eventueel met iemand die er naar kijkt. Pas als die drie staan, is het zinvol om over scenario's, tooling en rapportage te praten. Wie die volgorde omdraait, koopt een dashboard en houdt een blinde vlek.