Detection engineering is geen SIEM-configuratie — een volwassenheidsmodel voor de moderne SOC

Drie stukken vormen samen één scherp volwassenheidsmodel voor SOC-modernisering. De rode draad: detection is geen SIEM-configuratie, maar een engineering discipline. En AI in de SOC is een versterker, wie slechte input automatiseert, produceert operationele schuld, geen volwassenheid.

---

De herdefinitie: detection als contract

In 2012 schreef InfoSec Nirvana al dat een SIEM-usecase een "logical, actionable and reportable" component is met acht fasen: requirements, scope, event sources, validation, logic, implementation/testing, response en maintenance. Het moeilijkste deel was toen al niet SIEM-administratie, maar het vertalen van threat landscape naar SIEM-content.

In 2026 maakt detection engineering die lifecycle technisch afdwingbaar. Een detection is geen SPL, KQL, Sigma of YARA-L query, het is een versieerbaar, peer-reviewed engineering-object met metadata, dependencies, tests, runbookkoppeling, eigenaar, reviewer en lifecycle.

De AI-SOC-post trekt daar de bestuurlijke conclusie uit: AI in de SOC is een versterker. Als de input bestaat uit slechte logging, noisy rules, verouderde runbooks en onvoldoende analyst capability, dan automatiseer je geen volwassenheid maar operationele schuld. Vijf fundamentproblemen: alert fatigue, telemetry gaps, zwakke detection engineering, gebrekkige runbooks en onvoldoende analyst development.

De juiste volgorde is: telemetry → detection discipline → runbooks → metrics → analyst capability → daarna pas AI. Dit is een correctie op de vendor-gedreven aanname dat AI, XDR of SOAR de SOC vanzelf volwassen maakt.

Wat "detection als contract" concreet betekent

Een goede detection zegt niet alleen "waarop match ik?", maar ook:

• Waarom bestaat deze detection, voor welke dreiging en assetklasse?
• Met welke logbronnen, events, velden, parsers, normalisatie, retentie en latency?
• Met welke verwachte false-positive rate en testdata?
• Met welk responsproces, runbook, triage, escalatie, containment?
• Onder welk eigenaarschap, owner, reviewer, next_review, retirement criteria?

Dat maakt de detection auditbaar, testbaar en overdraagbaar. Zonder datacontract ontstaat een stille detection outage: de regel staat nog "aan", maar de onderliggende data is weg, vertraagd of semantisch veranderd.

Dit sluit aan op moderne Detection-as-Code-praktijken. De officiële Sigma-specificatie gebruikt YAML met metadata zoals title, id, status, description, author, date, modified, logsource, detection, condition, falsepositives, level en tags. Een enterprise-grade artifact voegt daar aanvullende velden aan toe: prerequisites, tuning_history, response, tests en owner.

Drie kritische correcties op de standaardpraktijk

1. ATT&CK-mapping is geen checkbox. Een veelgemaakte fout is T1027 (Obfuscated Files or Information) als sub-technique onder T1059.001 (PowerShell) plaatsen. Dat klopt niet. MITRE ATT&CK classificeert T1059.001 als sub-technique van T1059 (Command and Scripting Interpreter) onder tactic Execution. T1027 is een aparte technique onder tactic Stealth, met eigen sub-techniques zoals T1027.010 (Command Obfuscation) en T1027.013 (Encrypted/Encoded File). Een detection die "PowerShell encoded command execution" claimt maar vooral naar FromBase64String en Invoke-Expression-patronen in ScriptBlockText zoekt, detecteert eerder suspicious decoded script behavior dan het procesargument -EncodedCommand. In productie splits je dit: één process_creation-detection op powershell.exe -enc -encodedcommand en één script block detection op decoded gedrag.

2. Allowlists zijn bypass-vectoren als ze niet contextueel zijn. Hard-coded filters op accountnaam (svc-sccm, svc-ansible) zijn realistisch maar riskant, service accounts zijn aantrekkelijke abuse targets. Een volwassen artifact filtert niet alleen op accountnaam, maar ook op signed script identity, expected parent process, source path, script hash, deployment host, privileged access context en maintenance window. Anders bouw je precies de bypass die een actor nodig heeft.

3. ATT&CK coverage als management-KPI is gevaarlijk. MITRE waarschuwt expliciet dat organisaties niet naar 100% coverage moeten streven en dat één groene techniek niet betekent dat je die techniek echt dekt. Coverage moet gewogen worden naar dreigingsmodel, asset criticality, telemetrykwaliteit en validatiebewijs. De SANS/Anvilogic 2025-survey (67% vindt behavior-based detections effectief, 42% van detections is custom-derived) moet als survey-data worden gelezen, organisaties zonder serieuze detection engineering zijn ondervertegenwoordigd in de respondenten.

Volwassenheidsmodel: L0 tot L5

Niveau	Kenmerk	Typisch risico	Doelstatus
L0, Ad hoc	Vendor rules in SIEM UI	Geen ownership, geen rollback, hoge noise	Niet acceptabel voor kritieke detecties
L1, Gedocumenteerd	Usecases met beschrijving en response	Documentatie drift van SIEM-config	Minimaal voor basis-SOC
L2, Version-controlled	Rules en metadata in Git	Tests en deployment nog handmatig	Goede start
L3, Detection-as-Code	PR's, peer review, CI/CD, unit tests	Telemetry health nog apart of onvolledig	Sterke operationele basis
L4, Threat-informed	ATT&CK, threat model, validation, purple teaming	Coverage kan cosmetisch worden	Volwassen SOC
L5, AI-assisted	AI voor triage, rule variants, test generation, enrichment	Automatisering van verkeerde aannames	Alleen met guardrails en bewijsvoering

De sprong van L3 naar L4 is de moeilijkste: het vereist niet alleen tooling, maar een culturele verschuiving van "rules bouwen" naar "detection hypotheses valideren." L5 is expliciet conditioneel: AI-assisted SOC is alleen zinvol als L4 bewezen is.

90-dagen aanpak voor SOC-modernisering

Dag 0-30: Inventaris en baseline. Kies de tien belangrijkste detections op basis van business impact en relevante adversary behavior, niet op alertvolume. Leg per detection vast: eigenaar, doel, datavereisten, runbook, huidige false-positive rate, laatste validatie en ATT&CK mapping. Bouw een Git-repository met een minimale artifact-template. Maak de SIEM niet langer de enige bron van waarheid.

Dag 31-60: Engineering discipline. Zet de tien detections om naar version-controlled artifacts. Voeg unit tests en sample events toe. Definieer telemetry health checks per required log source. Corrigeer ATT&CK-mappings, verwijder cosmetische coverage, en leg uitzonderingen expliciet vast. Start peer review op elke wijziging.

Dag 61-90: Validatie en rationalisatie. Valideer met Atomic Red Team, log replay of purple-teamscenario's. Maak een dashboard met true-positive rate, false-positive rate, time since last validation, telemetry health score en detection-to-runbook ratio. Archiveer of retire detections zonder eigenaar, zonder datacontract of zonder werkend responsepad.

Pas daarna is een gecontroleerde AI-pilot zinvol: summarization, enrichment, draft rule reviews en test-case generation, niet voor autonome containment.

Risicoregister

Risico	Impact	Mitigatie	Bewijs
SIEM UI als bron van waarheid	Hoog	Git als system of record, protected branches, PR-review	Commit history, release tags
Logbron verdwijnt stil	Hoog	Telemetry health monitoring per detection	Health score, missing event alerts
Noisy rules blijven bestaan	Hoog	FP-budget per rule, review cadence, retirement criteria	Rolling 90-day SNR
ATT&CK als checkbox	Middel	Threat-model-weighted coverage, validatiebewijs verplicht	Coverage + validation status
Verouderde runbooks	Hoog	Runbook owner, last-tested date, tabletop tests	Test evidence
Onveilige allowlists	Hoog	Contextuele allowlisting, signed scripts, hash/path/parent validation	Exception register
AI bovenop slechte data	Hoog	AI alleen na evidence gating, human-in-loop, audit trail	AI evaluation logs
Privacy-overcollectie in telemetry	Middel	Data minimization, role-based access, retention control	DPIA, access logs

NIST CSF 2.0 als bestuurlijk kader

NIST CSF 2.0 is opgebouwd rond Govern, Identify, Protect, Detect, Respond en Recover. Detection engineering raakt vooral Govern (beleid, rollen, lifecycle), Detect (continuous monitoring, adverse event analysis) en Respond (incident management, response planning). De onderliggende telemetry en asset alignment raken ook Identify en Protect.

Voor BIO2 en NIS2-compliance is dit direct relevant: beide normenkaders eisen aantoonbare detectiecapaciteit, niet alleen aanwezigheid van een SIEM. Een detection artifact met owner, test, runbook en validatiedatum is audit-proof bewijs dat je Detect-functie operationeel is, niet alleen gedocumenteerd.

Strategische conclusie

De drie artikelen zijn vooral waardevol omdat ze SOC-modernisering ontdoen van tooling-hype. De echte boodschap is niet "koop Detection-as-Code" of "koop geen AI". De boodschap is: behandel detection als een engineering discipline met product ownership, lifecyclebeheer, testbaarheid, metrics en response-integratie.

Voor een CISO vertaalt dit zich naar één bestuurlijke eis: geen AI-SOC businesscase zonder aantoonbare detection maturity baseline. Minimale gate: de top tien kritieke detections staan in Git, hebben owners, telemetry contracts, tests, runbooks, laatste validatiedatum, FP/TP-metrics en een expliciet retirementproces. Zonder die basis koop je geen SOC-transformatie, maar een snellere manier om bestaande chaos te verwerken.

---

Cross-references: Defender zero-days, telecom-APT's en autonome AI-aanvallen, wat ik deze week in de SOC-logbooks zag, NSA publiceert Zero Trust audit voor BIO2, NSA ZIG: Zero Trust + BIO2 audit in één framework, Het glazen doos-mandaat: agentic AI governance