Triage af alarmer

I rammeværkerne ligger triage på grænsen mellem detektion og respons. NIST CSF 2.0 adskiller analysen af uønskede hændelser i Detect-funktionen (DE.AE, herunder DE.AE-08, hvor en hændelse erklæres, når hændelserne opfylder fastsatte kriterier) fra hændelseshåndtering i Respond, hvor RS.MA-02 kræver, at hændelsesrapporter triageres og valideres, og RS.MA-03, at hændelser kategoriseres og prioriteres. NIST SP 800-61 Rev. 3 (2025) knytter sin vejledning om hændelseshåndtering til disse CSF-resultater i stedet for den ældre livscyklus i fire faser. I praksis arbejder en SOC efter en lagdelt model: analytikere på Tier 1 foretager den første triage efter en runbook, Tier 2 undersøger eskalerede sager, og Tier 3 eller incident response-teamet håndterer bekræftede kompromitteringer.

En triagebeslutning følger typisk en fast rækkefølge. Analytikeren kontrollerer, at alarmen er udløst af reel telemetri, beriger den med kontekst (aktivets kritikalitet og ejer, brugerens rolle, nylig login-historik, threat intelligence om hashes, IP-adresser og domæner, relaterede alarmer på samme maskine eller identitet), fastlægger en disposition og tildeler en alvorlighed. Brugbare dispositioner skelner mellem sande positiver (ondsindet aktivitet), godartede sande positiver (reglen ramte den tilsigtede adfærd, men den var godkendt, fx en penetrationstest eller en administrators legitime PowerShell), falske positiver (reglen ramte noget, den ikke burde) og uafklarede. Det er vigtigt at registrere dispositionen præcist, for den er feedbacksignalet til justering af detektionsregler; blandes godartede sande positiver sammen med falske positiver, bliver regler svækket af de forkerte grunde.

Prioritering kombinerer normalt alarmens alvorlighed med forretningspåvirkningen af det berørte aktiv, så resultatet er en matrix frem for en enkelt score. Samling af relaterede alarmer i én sag, deduplikering og korrelation pr. entitet mindsker mængden, før et menneske ser den; SOAR-playbooks automatiserer ofte berigelsen og lukningen af velkendte godartede mønstre. Nøgletal omfatter gennemsnitlig tid til kvittering, gennemsnitlig tid til triage, antal alarmer pr. analytiker og andelen af sande positiver pr. regel. Det kroniske problem er alarmtræthed: når de fleste alarmer er støj, lukker analytikerne dem efter mønster og overser den sjældne ægte, og derfor kan detection engineering og triagekvalitet ikke adskilles.

Triage sætter også lovpligtige frister i gang. Efter NIS2 art. 23 skal en væsentlig eller vigtig enhed sende en tidlig varsling inden for 24 timer efter at have fået kendskab til en væsentlig hændelse og en hændelsesunderretning inden for 72 timer; efter databeskyttelsesforordningens art. 33, stk. 1, skal et brud på persondatasikkerheden anmeldes til tilsynsmyndigheden, i Danmark Datatilsynet, inden for 72 timer efter, at den dataansvarlige er blevet opmærksom på det. Det tidspunkt, hvor triagen skaber kendskab, skal derfor tidsstemples og dokumenteres. Triage adskiller sig fra trusselsjagt, der tager udgangspunkt i en hypotese frem for en alarm, og fra den egentlige undersøgelse, der rekonstruerer omfang og grundårsag, efter at sagen er eskaleret.