Detectiegaten dichten en metrieken

Dekkingspercentages kunnen misleidend zijn. Alleen de technieken tellen die je hebt gekozen om te testen, verhoogt het getal kunstmatig. Een kwetsbare regel als 'afgedekt' tellen overschat bovendien de werkelijke verdediging.

• Dekking moet worden gemeten tegen een dreigingsrelevante verzameling technieken, niet tegen een selectief gekozen verzameling
• Een resultaat 'gedetecteerd' moet afkomstig zijn van een robuuste, gedragsgebaseerde regel
• Uitkomsten die alleen zijn vastgelegd, zijn geen dekking; het zijn potentiële dekkingen

Vermeld altijd de noemer bij het percentage: '80% van de FIN7-technieken' zegt veel meer dan alleen '80%'.

Snelheid is net zo belangrijk als zichtbaarheid. Twee tijdsmetingen brengen de reactiesnelheid van de verdediging in kaart:

• MTTD — gemiddelde tijd tot detectie: van tijdstempel van de actie tot tijdstempel van de waarschuwing
• MTTR — gemiddelde tijd tot respons: van de waarschuwing tot de indammingsactie

Omdat purple teaming het exacte moment vastlegt waarop elke techniek wordt uitgevoerd, kun je deze waarden nauwkeurig meten in plaats van ze te schatten op basis van rommelige incidentgegevens.

Niet elk hiaat vereist dezelfde urgentie. Rangschik hiaten op basis van risico door te combineren hoe waarschijnlijk de techniek is en hoe schadelijk die zou zijn.

• Hoge waarschijnlijkheid + hoge impact (bijvoorbeeld LSASS-dumping) = eerst oplossen
• Lage waarschijnlijkheid + lage impact = op de takenlijst
• Weeg mee of de techniek in je dreigingsinformatie voorkomt

Een eenvoudige score van waarschijnlijkheid maal impact levert een geordende lijst met herstelacties op, zodat je inspanning richt op de grootste vermindering van het werkelijke risico.

Stel voordat je een regel schrijft vast waarom het hiaat bestaat. De oplossing verschilt afhankelijk van de hoofdoorzaak:

• Geen telemetrie — schakel de ontbrekende gegevensbron in (bijvoorbeeld Sysmon-configuratie of logboekregistratie van scriptblokken)
• Wel telemetrie, maar geen regel — schrijf een detectie
• De regel bestaat, maar werd niet geactiveerd — herstel de logica of het filter dat de regel onderdrukte
• De waarschuwing werd geactiveerd, maar genegeerd — dit is een proces- of prioriteringsprobleem, geen inhoudelijk hiaat

Een logische fout herstellen is verspilde moeite als het onderliggende logboek nooit is verzameld.

Het meest fundamentele hiaat is ontbrekende gegevens. Zo wordt de logboekregistratie van PowerShell-scriptblokken via Group Policy of het register ingeschakeld om gebeurtenis-ID 4104 beschikbaar te maken.

Wanneer de telemetrie beschikbaar is, schrijf je de detectie en stel je die af voor een bruikbaar signaal. Niet-afgestelde regels overspoelen analisten met onterechte positieven en worden genegeerd.

• Begin breed om te bevestigen dat het artefact verschijnt
• Voeg uitzonderingen toe voor bekende, legitieme basisactiviteit
• Meet het percentage onterechte positieven ten opzichte van normaal verkeer
• Voer de emulatie opnieuw uit om te bevestigen dat de aanval nog steeds wordt gedetecteerd

Een detectie is pas 'klaar' als die de aanval betrouwbaar detecteert en stil blijft bij onschadelijke activiteit.

Cijfers van één oefening zijn een momentopname; trends vertellen het echte verhaal. Volg de dekking en MTTD per kwartaal.

• K1: 45% dekking, MTTD 22 min
• K2: 62% dekking, MTTD 14 min
• K3: 71% dekking, MTTD 9 min

Een stijgende trend toont aan dat purple teaming resultaat oplevert. Een vlakke of dalende trend wijst op teruglopende detectie of op oplossingen die niet worden uitgevoerd.

Detecties kunnen stilzwijgend stukgaan wanneer omgevingen veranderen. Behandel ze als code en test op regressies.

• Voer eerder geslaagde technieken in elke cyclus opnieuw uit
• Automatiseer continue validatie, zodat defecte detecties een waarschuwing genereren
• Beheer detectie-inhoud met versiebeheer en controleer wijzigingen

Een detectie die ongemerkt niet meer wordt geactiveerd, is misschien erger dan een detectie die nooit heeft bestaan, omdat het team denkt dat het beschermd is terwijl dat niet zo is.

Stem de rapportage af op je publiek. Ontwikkelaars hebben details per techniek nodig; leidinggevenden hebben resultaten en risico's nodig.

• Voor ontwikkelaars: resultaten per techniek, aangemaakte regels en notities over het afstellen
• Voor leidinggevenden: dekkingstrend, MTTD-trend, weggenomen en resterende belangrijkste risico's
• Visueel: een warmtekaart in ATT&CK Navigator die de voortgang in de tijd toont

Resultaten presenteren als vermindering van risico's, niet als ruwe technische gegevens, zorgt ervoor dat steun en financiering voor het programma blijven bestaan.

Je kunt de detectiedekking nu grondig meten en verbeteren:

• Gebruik dekking, MTTD en MTTR als kernmeetwaarden en vermeld altijd hun noemer
• Vermijd schijnbare dekking door selectief gekozen of kwetsbare detecties
• Zoek eerst de hoofdoorzaak van elk hiaat: telemetrie, regel, logica of prioritering
• Schakel ontbrekende gegevens in en stel regels vervolgens af voor weinig onterechte positieven
• Volg trends en bescherm tegen stille detectieregressie
• Rapporteer als vermindering van risico's met ATT&CK-warmtekaarten om het programma te ondersteunen

Je hebt de cursus Purple Teaming voltooid: rode en blauwe teams samenbrengen in een continue, meetbare cyclus die aantoonbaar betere verdediging oplevert.