Er is een rookmelder in je kantoor. Hij gaat drie keer per week af. Soms omdat iemand toast brandt. Soms omdat de stoom van de waterkoker erlangs waait. Soms zonder aanwijsbare reden. Na een maand heeft iedereen geleerd om het geluid te negeren. En als het gebouw dan echt in brand staat, staat iedereen met de armen over elkaar: "Ach, het is vast weer de waterkoker."
Dit is de staat van beveiligingsmonitoring bij de meeste organisaties.
Het probleem met alerts
Een gemiddeld SIEM-systeem (Security Information and Event Management) genereert honderden tot duizenden alerts per dag. Het overgrote deel is false positives: gebeurtenissen die eruitzien als een aanval maar het niet zijn. Een medewerker die vijf keer het verkeerde wachtwoord invoert omdat de Caps Lock aan staat. Een vulnerability scan van het eigen security-team. Een backup-job die ongebruikelijke netwerkpatronen veroorzaakt.
Het resultaat is alert fatigue. Analisten leren om alerts te negeren, te skippen, te sluiten zonder onderzoek. Niet omdat ze lui zijn, maar omdat ze moeten. Er zijn er simpelweg te veel om allemaal serieus te nemen. En het gevolg is dat de ene echte aanval verdwijnt in de ruis.
Wat is detection engineering?
Detection engineering behandelt detectieregels als software. Niet als iets dat je één keer instelt en dan vergeet, maar als iets dat je ontwikkelt, test, versiebeheert, en continu verbetert. Het is de discipline die zegt: "Als onze detectieregel meer dan 5% false positives produceert, is dat een bug. En bugs fixen we."
De principes
- Detectie als code. Detectieregels worden geschreven in een standaardformaat (Sigma, KQL, SPL), opgeslagen in versiebeheer (Git), gereviewed door collega's, en getest voordat ze in productie gaan.
- Testen, testen, testen. Elke detectieregel wordt getest met gesimuleerde aanvallen. Detecteert hij wat hij moet detecteren? Genereert hij false positives op normale activiteit?
- Meten. Hoeveel alerts genereert elke regel? Hoeveel daarvan zijn true positives? Wat is de gemiddelde tijd tot triage? Regels die veel ruis produceren, worden verbeterd of verwijderd.
- ATT&CK-mapping. Elke regel is gekoppeld aan een ATT&CK-techniek, zodat je kunt zien welke aanvalstechnieken je detecteert en welke niet.
Van rule-based naar behavior-based
Traditionele detectie is regelgebaseerd: "Als iemand meer dan vijf keer een verkeerd wachtwoord invoert, genereer een alert." Het probleem: aanvallers weten dit ook. Ze proberen vier keer en wachten dan een uur.
Behavior-based detectie kijkt naar patronen in plaats van drempels. "Deze gebruiker logt normaal in tussen 8 en 18 uur vanaf kantoor. Vandaag logt hij in om 3 uur 's nachts vanaf een IP in een land waar hij nog nooit is geweest. En daarna opent hij bestanden die hij normaal nooit opent." Geen enkele individuele actie is verdacht. Het patroon is dat wel.
De Sigma-standaard
Sigma is voor detectieregels wat YARA is voor malware: een platformonafhankelijk formaat dat je kunt converteren naar het queryformaat van je SIEM. Schrijf de regel één keer in Sigma, converteer naar Splunk SPL, Microsoft KQL, Elastic Query, of wat je ook gebruikt. Het maakt detectieregels deelbaar, herbruikbaar en leveranciersonafhankelijk.
De beste detectie-engineer is niet degene die de meeste regels schrijft. Het is degene die de minste regels nodig heeft om de meeste aanvallen te detecteren, met de minste false positives. Kwaliteit boven kwantiteit. Altijd.