Alert fatigue is de afstomping die ontstaat wanneer analisten zoveel meldingen krijgen dat ze echte signalen missen. Wie tweehonderd keer per dienst op “close” klikt, klikt op een dag ook de melding weg die ertoe deed. De stelling die dit artikel draagt: alert fatigue is zelden een mensenprobleem en bijna altijd een datakwaliteitsprobleem.
Waar de ruis vandaan komt
- Regels uit een standaardpakket, nooit aangepast aan de eigen omgeving. De content-packs van je SIEM zijn geschreven voor een gemiddelde organisatie die niet bestaat. Een regel die elders scherp is, loeit bij jou de hele dag.
- Ontbrekende context. Een beheerder die om 02:00 uur inlogt: verdacht, tenzij het de geplande patchronde is. Zonder wijzigingskalender en asseteigenaar in de melding ziet de analist dat verschil niet, dus onderzoekt hij het. Elke keer weer.
- Dubbele detecties op verschillende lagen. EDR, firewall en SIEM melden hetzelfde event, elk in eigen bewoording. Eén gebeurtenis, drie tickets.
- Regels die niemand meer durft uit te zetten. Niemand weet waarom ze bestaan, dus laat iedereen ze staan. Voor de zekerheid. De eerlijkste oorzaak op dit lijstje, en de meest voorkomende.
Wat is detection engineering?
Detection engineering is het behandelen van detectieregels als een product met een levenscyclus, niet als een project dat ooit af is. Elke regel heeft een eigenaar, een doel en een houdbaarheidsdatum. Vijf fasen:
- Ontwerpen. Welke techniek of welk risico wil je zien, en welke data heb je daarvoor nodig? Eigenaar: de detection engineer.
- Bouwen. De regel schrijven, met context (assetwaarde, eigenaar) er meteen bij.
- Testen. Tegen historische data en gesimuleerde aanvallen, voordat de regel live gaat. Eigenaar: engineer plus analist.
- Afstemmen. De false positive ratio per regel volgen en bijsturen. Eigenaar: de analisten die de meldingen zien; doorlopend, met een vast maandelijks moment.
- Uitfaseren. Regels die niets meer opleveren gedocumenteerd uitzetten, elk kwartaal. Vrijwel niemand doet deze fase, en het is precies de fase die oorzaak vier hierboven voorkomt.
Meten voordat je tunet
Vier meetwaarden volstaan om te weten waar je staat:
- Meldingen per analist per dienst. De directe maat voor werkdruk.
- False positive ratio per regel. Niet per omgeving, maar per regel, anders weet je nooit welke regel het probleem is.
- Mean time to triage. Hoe lang duurt het voordat iemand een melding heeft beoordeeld?
- Aandeel meldingen dat tot actie leidt. De hardste maat voor signaalwaarde.
Zonder nulmeting kun je na drie maanden tunen niet aantonen dat het hielp, en dan verdwijnt het budget. Streefcijfers geven we bewust niet: die verschillen per omgeving, en wie je er toch een noemt, kent jouw omgeving niet.
Vier maatregelen die het volume echt verlagen
- Verrijk meldingen met context voordat ze bij een analist landen. Assetwaarde, eigenaar, wijzigingsvenster. De melding “inlog op srv-db-03 (kroonjuweel, eigenaar team Betalingen, geen gepland werk)” triageert zichzelf half.
- Onderdruk meldingen tijdens geplande wijzigingen. Een patchnacht met vierhonderd meldingen leert analisten precies één ding: negeren.
- Groepeer verwante meldingen tot één incident. Tien signalen van één aanvalspad horen in één dossier, niet in tien tickets. Waar AI wel en niet helpt bij ruisreductie, lees je in ons artikel over AIOps.
- Verwijder data zonder detectiewaarde voordat die je SIEM in gaat. Debug-logging en heartbeats voeden geen enkele detectie, maar vervuilen wel elke zoekopdracht. Hoe je data filtert voordat die je SIEM in gaat, lees je in ons artikel over telemetry pipelines.
Een dashboard per component vertelt je hoe de database en de applicatieserver zich voelen, maar niet of de dienst het doet. Groene lampjes en toch klachten, iedereen in operations kent dat gesprek. Service-gebaseerde monitoring draait het om: je koppelt technische signalen aan een bedrijfsproces, zoals “bestelling plaatsen” of “brug bedienen”, en bewaakt dat. In de Splunk-wereld is dit het domein van Splunk Observability Cloud en ITSI.
Dekking meten met MITRE ATT&CK
Als de ruis afneemt, komt de volgende vraag: zien we wel de juiste dingen? Het MITRE ATT&CK-framework beschrijft de technieken die aanvallers daadwerkelijk gebruiken. Koppel je detecties daaraan, en het gesprek verandert van “hoeveel regels hebben we” in “welke technieken zien we, en welke niet”, het enige gesprek dat je risico verkleint.
Eén waarschuwing: dekking najagen om de dekking is de nieuwe valkuil. Dek de technieken die voor jouw omgeving en dreigingsbeeld tellen, en dek die goed.
Detection engineering vraagt om ritme: elke dag kijken, elke maand afstemmen, elk kwartaal opruimen. Dat ritme organiseren wij met 24/7 checks door een team in plaats van een persoon. Speelt de vraag of je dit zelf wilt doen, lees dan ons artikel over welk servicemodel bij je past.
