En alarm har kun værdi, hvis reglen findes, hvis den bliver udløst af det rigtige, og hvis nogen gør noget, når den går. Gennemgangen læser derfor tre ting: listen over regler, de tærskler, reglerne bruger, og historikken over, hvad der skete med de alarmer, der faktisk kom.
Det kan alt sammen gøres ved at læse. Der skal ikke udføres noget angreb for at se, om reglerne er der, og om alarmerne er blevet behandlet. At teste opdagelsen ved at efterligne et angreb er en anden opgave, som hører til en penetrationstest, og den ligger uden for denne gennemgang.
Hvad målestokken beder om
Det mest konkrete står i bilaget til forordning 2024/2690, som binder de enheder, dens artikel 1 nævner. Punkt 3.2.4 beder om, at logfilerne gennemgås regelmæssigt for usædvanlige eller uønskede tendenser. Hvor det er relevant, fastsættes alarmtærskler, en overskridelse udløser automatisk en alarm, og der sikres rettidigt en kvalificeret reaktion. Punkt 3.2.2 beder om, at overvågningen automatiseres så vidt muligt og minimerer både falske positive og falske negative.
DORA’s tekniske standard, artikel 23, går længere for finansielle enheder. Der skal være værktøjer, der advarer om anormal aktivitet, mindst for de aktiver, der bærer kritiske eller vigtige funktioner. Advarslerne prioriteres, så de kan håndteres inden for den forventede tid både i og uden for arbejdstiden. For hver anormal aktivitet logges, hvornår den fandt sted, hvornår den blev opdaget, og hvilken type den var. Uden for finanssektoren er standarden en målestok, og de tre tidspunkter er en god disposition for alarmhistorikken.
Hvad en god regel er
Microsoft beskriver en god alarmhændelse som en, der har høj sandsynlighed for at skyldes uautoriseret aktivitet, giver få falske positive og fører til en undersøgelse. To af Microsofts eksempler på enkeltstående hændelser er, at en almindelig konto lægges i en privilegeret gruppe, og at en ukendt tjeneste installeres på en domænecontroller.
Eksemplerne kan bruges som kontrolpunkter i gennemgangen. Spørgsmålet er, om der findes en regel for hvert af dem, og hvad den reagerer på. Microsoft beskriver også den anden slags alarm: en ophobning af hændelser ud over det normale, fx mange mislykkede logon på kort tid. Her er tærsklen hele reglen, og den skal kunne begrundes.
Regellisten
Begynd med et udtræk af alle aktive regler fra det system, der laver alarmerne. For hver regel noteres, hvilken hændelse eller tærskel den reagerer på, hvilken kilde den bygger på, hvem der modtager alarmen, og hvornår den sidst blev ændret.
Sammenlign derefter reglerne med de hændelser, I har besluttet at ville opdage. To slags fund er almindelige. Der er hændelser uden regel, og der er regler, der bygger på en kilde, som ikke leverer data. Det sidste opdages ved at sammenholde regellisten med dækningskortet over logkilder. En regel for ændringer i administratorgrupper hjælper ikke, hvis revisionspolitikken på domænecontrollerne ikke skriver de hændelser.
Historikken
Regellisten viser, hvad der er sat op. Historikken viser, om det virker. Træk alarmerne for en afgrænset periode, og se for hver af dem: hvornår den kom, hvem der så den, hvad der blev gjort, og hvornår den blev lukket.
Et tænkt mønster kan fortælle meget. Hvis næsten alle alarmer lukkes uden kommentar inden for få minutter, er der sandsynligvis for mange falske positive, og reglerne skal strammes. Hvis alarmer står åbne i dagevis, mangler der en ejer. Hvis der ingen alarmer har været i en lang periode, er det værd at undersøge, om reglerne overhovedet får data.
Uden for arbejdstiden er et særskilt spørgsmål. Se i historikken, om alarmer, der kom om natten eller i weekenden, blev behandlet, og hvornår.
Tærsklerne
En tærskel er en beslutning. Er den for lav, drukner de vigtige alarmer i støj. Er den for høj, kommer alarmen for sent eller slet ikke. Gennemgangen spørger, hvordan tærsklen blev sat, og hvornår den sidst blev vurderet. Kan ingen forklare tærsklen, noteres det som et fund, også selv om værdien måske er rigtig.
Det hjælper at notere, hvad tærsklen bygger på. Er den sat ud fra en måling af det normale niveau i jeres miljø, kan den justeres, når miljøet ændrer sig. Er den overtaget fra en standardregel uden tilpasning, passer den sjældent til en bestemt virksomheds døgnrytme, og det ses ofte i historikken som mange alarmer på de samme tidspunkter.
Hvad det kræver, og hvad det koster at lade være
Gennemgangen kræver læseadgang til alarmsystemet og dets historik og en samtale med dem, der modtager alarmerne. Rettelserne er justering af regler og tærskler og en klar fordeling af, hvem der reagerer hvornår.
Uden gennemgangen kan I have et alarmsystem, der ser aktivt ud, men som enten er tavst, fordi kilderne mangler, eller larmer så meget, at ingen læser det. Begge dele opdages først, når en alvorlig hændelse har stået ubehandlet.
Det skal I lade være med
- At teste alarmerne ved at efterligne et angreb uden aftale · det hører til en penetrationstest med eget formål og egen aftale.
- At regne en regel for virksom, fordi den står i listen · tjek, at den får data.
- At lukke alarmer uden en kommentar · historikken skal vise, hvad der blev gjort.
Det skal gennemgangen kunne vise
- ☐ Et udtræk af aktive regler med kilde, tærskel og modtager.
- ☐ En sammenligning mellem reglerne og de hændelser, I har besluttet at opdage.
- ☐ Alarmhistorik for en periode med tidspunkt for alarm, behandling og lukning.
- ☐ En begrundelse for tærsklerne og dato for seneste vurdering.
Kilder
- Gennemførelsesforordning (EU) 2024/2690, dansk tekst, bilagets punkt 3.2.2 og 3.2.4, læst 13. november 2026.
- Delegeret forordning (EU) 2024/1774, artikel 23, stk. 2 og 4, læst 13. november 2026.
- Microsoft, System Audit Policy recommendations, læst 13. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Træk alarmhistorikken for den seneste måned, og se, hvor mange alarmer der blev lukket uden en kommentar.
Læs også: Er kontrollen der, eller har den virket? · Overvågningsleverandørens dækning
→ Kontakt · Tlf. 70 13 63 23 · Teknisk sikkerhedsgennemgang hos Nielco IT
