Lukning af detection-huller og målinger

Dækningsprocenter kan være misvisende. Hvis du kun tæller teknikker med, som du valgte at teste, bliver tallet kunstigt højt, og hvis du tæller en skrøbelig regel som »dækket«, overvurderer du det reelle forsvar.

• Dækning bør måles i forhold til et trusselsrelevant udvalg af teknikker, ikke et udvalg, der er håndplukket efter forgodtbefindende
• Et »detekteret«-resultat skal komme fra en robust, adfærdsbaseret regel
• Udfald, der kun er logget, er ikke dækning; de er potentiel dækning

Angiv altid procentdelen sammen med nævneren: »80 % af FIN7's teknikker« siger langt mere end et ubetinget »80 %«.

Hastighed er lige så vigtig som synlighed. To tidsmålinger beskriver, hvor hurtigt forsvaret reagerer:

• MTTD — gennemsnitlig tid til detektion: fra handlingens tidsstempel til alarmens tidsstempel
• MTTR — gennemsnitlig tid til reaktion: fra alarmen til den begrænsende handling

Fordi purple teaming registrerer det præcise tidspunkt, hvor hver teknik køres, kan du måle disse værdier nøjagtigt i stedet for at vurdere dem ud fra uoverskuelige hændelsesdata.

Ikke alle huller kræver samme hast. Rangordn huller efter risiko ved at kombinere, hvor sandsynlig teknikken er, med hvor skadelig den ville være.

• Høj sandsynlighed + stor påvirkning (f.eks. dumpning af LSASS) = udbedres først
• Lav sandsynlighed + lille påvirkning = opgaveliste
• Vægt efter, om teknikken optræder i dine trusselsoplysninger

En enkel score baseret på sandsynlighed gange påvirkning giver en ordnet liste over udbedringer, som fokuserer indsatsen dér, hvor den mindsker den største reelle risiko.

Før du skriver en regel, skal du undersøge, hvorfor hullet findes. Løsningen afhænger af rodårsagen:

• Ingen telemetri — aktivér den manglende datakilde (f.eks. Sysmon-konfiguration eller logning af scriptblokke)
• Telemetri, men ingen regel — skriv en detektion
• Reglen findes, men blev ikke udløst — ret den logik eller det filter, der undertrykte den
• Alarmen blev udløst, men ignoreret — et problem med processen eller den indledende vurdering, ikke et indholdshul

Det er spild af kræfter at rette en logikfejl, hvis den underliggende log aldrig blev indsamlet.

Det mest grundlæggende hul er manglende data. For eksempel aktiveres PowerShell-scriptbloklogning via Group Policy eller registreringsdatabasen, så Event ID 4104 bliver tilgængeligt.

Når telemetrien er på plads, skal du skrive detektionen og justere den, så den giver et tydeligt signal. Ujusterede regler drukner analytikere i falske positiver og bliver ignoreret.

• Start bredt for at bekræfte, at artefakten vises
• Tilføj undtagelser for kendt legitim normalaktivitet
• Mål frekvensen af falske positiver i forhold til normal trafik
• Kør emuleringen igen for at bekræfte, at den stadig fanger angrebet

En detektion er først »færdig«, når den pålideligt udløses ved angrebet og forbliver tavs ved legitim aktivitet.

Tal fra en enkelt øvelse er et øjebliksbillede; tendenser fortæller den egentlige historie. Følg dækning og MTTD på tværs af kvartaler.

• 1. kvartal: 45 % dækning, MTTD 22 min.
• 2. kvartal: 62 % dækning, MTTD 14 min.
• 3. kvartal: 71 % dækning, MTTD 9 min.

En forbedrende tendens viser, at purple teaming giver udbytte. En uændret eller faldende tendens signalerer forringelse af detektioner eller, at rettelserne ikke bliver gennemført.

Detektioner kan gå ubemærket i stykker, når miljøer ændrer sig. Behandl dem som kode, og kontrollér for regressioner.

• Kør teknikker, der tidligere virkede, igen i hver cyklus
• Automatiser løbende validering, så defekte detektioner udløser en alarm
• Versionsstyr detektionsindhold, og gennemgå ændringer

En detektion, der ubemærket er holdt op med at blive udløst, er muligvis værre end aldrig at have haft den, fordi teamet tror, at de er dækket, selv om de ikke er det.

Tilpas rapporteringen til målgruppen. Teknikere har brug for detaljer på teknikniveau; ledelsen har brug for resultater og risiko.

• Til teknikere: resultater for hver teknik, oprettede regler, noter om justeringer
• Til ledelsen: udvikling i dækning, udvikling i MTTD, største lukkede og resterende risici
• Visuelt: et varmekort i ATT&CK Navigator, der viser fremskridt over tid

Det er præsentationen af resultaterne som risikoreduktion, ikke som rå tekniske data, der fastholder støtten og finansieringen af programmet.

Du kan nu måle og forbedre detektionsdækningen systematisk:

• Brug dækning, MTTD og MTTR som centrale målinger, altid sammen med deres nævner
• Undgå illusioner om dækning fra håndplukkede eller skrøbelige detektioner
• Find rodårsagen til hvert hul, før du løser det: telemetri, regel, logik eller indledende vurdering
• Aktivér manglende data, og juster derefter reglerne for at opnå få falske positiver
• Følg tendenser, og beskyt mod ubemærket forringelse af detektioner
• Rapportér som risikoreduktion med ATT&CK-varmekort for at fastholde programmet

Du har gennemført kurset i Purple Teaming: Du har forbundet red og blue i en kontinuerlig, målbar løkke, der gør forsvaret dokumenterbart bedre.