Detection engineering is de vaardigheid die bepaalt of je SIEM aanvallen opmerkt of alleen ruis doorgeeft. Vrijwel elk securityteam in Nederland heeft een SIEM ingericht, EDR-agents uitgerold en de kant-en-klare regels geactiveerd die bij de licentie zaten. Die basis dekt het bekende werk af. Zodra een aanvaller iets doet wat de leverancier niet heeft voorzien, of iets wat alleen in jouw omgeving afwijkt, valt de dekking weg. Op dat moment heb je iemand nodig die zelf detectielogica kan schrijven.
Waar een standaardregel ophoudt
Leveranciersregels zijn geschreven voor de gemiddelde klant. Ze dekken brede technieken: een nieuw aangemaakte service, een PowerShell-commando met een verdachte parameter, een inlogpoging uit een land waar je geen vestiging hebt. Dat werkt bij duizenden organisaties met exact dezelfde logica, en een aanvaller die zijn huiswerk doet weet dus wat hij kan verwachten.
Het tweede probleem zit in jouw eigen omgeving. Een regel die bij een bank zinvol uitpakt, loopt bij een logistiek bedrijf vol met false positives, omdat planners daar om twee uur ’s nachts inloggen. Teams zetten zulke regels uit of verlagen de prioriteit zo ver dat niemand er nog naar kijkt. Na een jaar bestaat de helft van de regelset uit logica die nooit een alert oplevert, en de andere helft uit alerts die niemand serieus neemt. Dat voedt alert fatigue in het SOC.
Detection engineering begint bij de vraag die geen leverancier kan beantwoorden: welk gedrag is in déze omgeving afwijkend? Dat is waar een SIEM-investering pas gaat renderen, want het platform voert alleen uit wat iemand erin heeft gezet.
Detection engineering begint bij logdekking
Voordat iemand een regel schrijft, moet duidelijk zijn welke gebeurtenissen überhaupt in je SIEM landen. Dat klinkt elementair en gaat geregeld mis. Process creation events staan uit op de helft van de servers. Command-line logging is nooit aangezet. De firewall stuurt verbindingen door zonder DNS-resolutie. Elke ontbrekende logbron is een categorie aanvalsgedrag waarvoor je blind bent, hoe goed je regels ook zijn.
MITRE ATT&CK is het instrument waarmee teams die dekking in kaart brengen. MITRE schrijft dat het framework defenders helpt om “analytics that detect the techniques used by an adversary” te ontwikkelen, en dat het is te gebruiken om “assess your organization’s capabilities”. In de praktijk is dat een matrix waarin je per techniek vastlegt of de logbron binnenkomt, of er een regel op staat en of die regel ooit is getest. De eerste keer dat een team deze oefening doet, is de uitkomst meestal ongemakkelijk.
Detection engineering betekent dus ook dat iemand het gesprek met IT-beheer voert over logging, retentie en kosten. Dat voelt niet als securitywerk, en het is de voorwaarde waarop al het andere rust. Organisaties die hun security maturity stap voor stap opbouwen, zetten logdekking vrijwel altijd voor regelontwikkeling.
Van hypothese naar detectieregel
Een goede detectie begint als een hypothese over gedrag. “Als een aanvaller credentials uit LSASS haalt, zien we een proces dat een handle opent op lsass.exe terwijl het geen bekende beheertool is.” Zo geformuleerd is het idee te testen, te weerleggen en te vertalen naar logica. Teams die al threat hunting hebben opgezet herkennen die denkstap: een hunt levert een eenmalig antwoord, detection engineering levert een regel die blijft kijken.
Sigma is het formaat waarin teams die logica vastleggen zonder zich aan één SIEM te binden. SigmaHQ beschrijft het als “a generic, open, and structured detection format” waarmee je “detect relevant log events in a simple and shareable way”. Je schrijft de regel eenmaal in YAML, met velden voor de logbron en de detectievoorwaarde, en converteert hem via een backend naar de querytaal van je eigen platform. Migreert je SOC over twee jaar naar een ander SIEM, dan migreert de regelset mee.
Converteren is het eenvoudige deel. Het schrijven vraagt iemand die weet hoe de aanvalstechniek werkt, welke sporen die achterlaat en welk legitiem gedrag erop lijkt. Dat is de kennis die een pentester inzet, van de andere kant bekeken. Teams die intern purple teaming doen merken dat hun detectielogica scherper wordt, omdat ze zien welk gedrag ongemerkt doorkomt. Wie geheugenforensiek beheerst, schrijft betere YARA-regels.
Een regel die niet is getest, is een aanname
Hier scheidt detection engineering zich van een goedbedoelde zoekopdracht. Een regel moet aantoonbaar afgaan op het gedrag dat hij hoort te vinden, en stil blijven bij normaal verkeer. Dat vraagt dat je de techniek in een testomgeving uitvoert en observeert wat er in de logs verschijnt.
De volwassen vorm heet detections-as-code. Elastic publiceert zijn regelset als openbare repository met, in eigen woorden, “code for building Detections-as-code pipelines, unit testing in Python and integrating with the Detection Engine in Kibana”, plus commando’s om alle regels tegen een schema te valideren. Zo blijft een regelset beheersbaar: in versiebeheer, met tests, met review voordat iets live gaat.
De meeste Nederlandse SOC’s zitten daar nog ver vandaan, en dat hoeft geen blokkade te zijn. Een realistische eerste stap: elke nieuwe regel krijgt een notitie met de hypothese, de ATT&CK-techniek, de logbron, de testmethode en de datum van de laatste controle. Dat is detection engineering op papier, en het verslaat een regelset waarvan niemand de herkomst kent. Zoals bij SOC-playbooks geldt: zonder vastgelegde aanname is er niets te verbeteren.
Onderhoud is het deel dat wordt overgeslagen
Detectieregels verouderen stil. Een applicatie krijgt een update en genereert andere events. IT migreert van on-premises Exchange naar cloud en de helft van de mailregels verwijst naar een logbron die niets meer stuurt. De regel staat nog aan, het dashboard ziet groen uit, en er komt nooit meer een alert uit. Niemand merkt dat op, want een regel die zwijgt lijkt sprekend op een regel die niets aantreft.
Daarom hoort bij detection engineering een vast onderhoudsritme. Per kwartaal: welke regels hebben nul keer gevuurd, en is dat te verklaren? Welke regels leveren uitsluitend false positives en moeten worden bijgesteld? Welke technieken uit recente incidenten en uit supply chain-dreigingen hebben nog geen dekking? Dat werk landt zelden in een SOC-KPI, en het bepaalt of je detectieset over drie jaar nog iets waard is.
Het NCSC vat het belang samen: “Door detectie kun je eerder ingrijpen, voordat de schade te groot wordt.” Dat ingrijpen hangt volledig aan de regels die op dat moment aanstaan. Automatisering helpt bij triage, maar de verdeling tussen machine en mens verschuift hier niet: de hypothese komt van een analist.
Welke vaardigheden hieronder zitten
Detection engineering is een samenstel van onderdelen die los te leren zijn. Begrip van aanvalstechnieken en hoe ze zich in logs manifesteren. Kennis van je eigen logbronnen en hun eigenaardigheden. Het schrijven van Sigma- en YARA-regels. Genoeg Python om testdata te genereren en resultaten te verwerken. En het analytisch vermogen om een hypothese te formuleren die te weerleggen valt.
Die combinatie zit in de opleiding SOC T3 Analyst, waarvan de eerste module Threat Hunting & Detection Engineering heet en waarin deelnemers eigen detectieregels in YARA en Sigma bouwen. Het programma beslaat 250 academische uren: voltijd ongeveer tien weken, deeltijd vijf tot zes maanden bij zestien uur per week. De lesvorm is online, met een hybride opzet waarin een deel op locatie in Schiphol-Rijk plaatsvindt. Toelating vraagt minimaal één jaar werkervaring als tier 1- of tier 2-analist. De startdata staan in de agenda.
Die instapeis is relevant voor je planning. Detection engineering leer je niet als eerste stap in het vak. Wie aan het begin staat, bouwt eerst de tier 1- en tier 2-basis op. Een overzicht van de niveaus staat bij de opleidingen.
Hoe je dit intern opbouwt
Begin met één persoon. Een tier 2-analist die nieuwsgierig is naar hoe aanvallen werken, krijgt een dag per week vrijgemaakt voor detection engineering en volgt het traject. Welk niveau passend is hangt af van hoe lang iemand al triagewerk doet. Die persoon bouwt in een half jaar de eerste eigen regelset, het testproces en de documentatie. Daarna is er iets concreets om een tweede persoon in op te leiden, en ligt er een doorgroeipad richting security engineering dat mensen bindt.
De fout die het vaakst voorkomt: detection engineering neerleggen bij iemand die al voltijds alerts afhandelt. Dat werk wint altijd, omdat het urgent en zichtbaar is. Zonder beschermde tijd komt er geen regel bij. Een in-company traject voor werkgevers is daarom vaak effectiever dan losse cursussen: het legt de uren vast voordat de operatie ze opeist.
Uitbesteden aan een MSSP lost een deel hiervan op, met één beperking. De detectielogica van je provider is generiek om dezelfde reden als die van je SIEM-leverancier: hij moet bij al zijn klanten werken. Regels die specifiek over jouw omgeving gaan, schrijft alleen iemand die jouw omgeving kent.
Wat detection engineering uiteindelijk oplevert
Een team met deze vaardigheid heeft een detectieset die bij de eigen omgeving past, waarvan de aannames vastliggen en de dekking te verantwoorden is tegenover een auditor of het MT. Nieuwe dreigingsinformatie wordt binnen dagen een werkende regel, en gaat er iets mis, dan is “hadden we dit kunnen zien?” met bewijs te beantwoorden. Dat onderscheidt een SIEM als kostenpost van een SIEM als detectiecapaciteit, en het kost één of twee mensen in plaats van extra licenties. Wil je weten welk traject bij je team past, plan dan een kennismaking.
