En teknisk gennemgang viser opsætningen, som den var på gennemgangsdagen. Dagen efter kan en ændring have bragt den væk fra baselinen igen. Løbende kontrol betyder, at driften gør de vigtigste udtræk fra gennemgangen til faste kontroller, der kører af sig selv og siger til, når opsætningen afviger.
Gennemgangen er stadig nyttig, fordi den ser bredt og med friske øjne. Men det er den løbende kontrol, der holder resultatet.
Hvad målestokkene beder om
For de omfattede enheder har bilaget til forordning 2024/2690 tre punkter, der passer. Efter punkt 6.3.1 skal sikre indstillinger for udstyr, programmer, tjenester og net fastlægges, skrives ned, tages i brug og overvåges. Efter punkt 6.3.2, litra b, skal der være processer og værktøjer, som holder de sikre indstillinger på plads, både på nye systemer og på dem, der allerede kører, så længe de lever. Punkt 6.3.3 kræver, at konfigurationerne gennemgås efter en plan. Punkt 7 beder om politik og procedurer til at vurdere, om foranstaltningerne gennemføres og opretholdes effektivt.
DORA’s tekniske standard, artikel 11, kræver for finansielle enheder, at der identificeres en sikker konfigurationsstandard for IKT-aktiver, og at der er foranstaltninger til regelmæssig kontrol af, at standarden anvendes effektivt. Standarden skal tage hensyn til førende praksis og standarder.
Begge peger samme vej: en skrevet baseline, en måde at håndhæve den på og en løbende kontrol af, at den holder. For virksomheder uden for de to ordninger er det en målestok.
Hvilke kontroller der egner sig
Ikke alt fra en gennemgang kan automatiseres, og ikke alt behøver det. Hvilke kontroller der vælges, er praksis. De, der egner sig bedst, har tre træk: de kan læses med en kommando eller et API, resultatet kan sammenlignes med en fast værdi, og en afvigelse betyder noget.
Tænkte eksempler fra andre artikler på sitet:
- Revisionspolitikken på servere, læst med auditpol /get /category:* /r og sammenlignet med baselinen.
- Tidskilde og tidszone, læst med w32tm /query /source og w32tm /tz.
- Auditloggens status i lejeren, læst med Get-AdminAuditLogConfig.
- Medlemmer af privilegerede grupper, sammenlignet med en godkendt liste.
- Opdateringsniveau målt på maskinerne og sammenlignet med fristerne.
Hver kontrol får en fast værdi, en kørselsplan og en modtager af afvigelser.
Fra udtræk til kontrol
En kontrol bygges i fire trin.
Skriv den forventede værdi ned. Den kommer fra baselinen og fra rettelserne efter gennemgangen.
Gør udtrækket automatisk. En planlagt opgave eller et script, der kører med en konto med læseret, gemmer resultatet med dato.
Sammenlign. Resultatet holdes op mod den forventede værdi, og forskellene skrives ud.
Send afvigelser til en, der læser dem. En kontrol, hvis resultat ingen ser, er ingen kontrol.
Håndhævelse og kontrol er to ting
Bilaget skelner mellem at håndhæve konfigurationen og at overvåge den. Håndhævelse sker typisk med gruppepolitikker, styringsværktøjer eller skabeloner, der sætter indstillingen. Kontrol læser, om indstillingen faktisk står, som den skal. Begge er nødvendige, fordi håndhævelsen ikke rammer alt. Maskiner uden for styringen, lokale ændringer og udstyr uden for domænet bliver ikke rettet af gruppepolitikken, men kontrollen kan se dem.
Ændringer, der er godkendt
En løbende kontrol vil også se de ændringer, der er lavet bevidst og godkendt. Når baselinen ændres, skal den forventede værdi i kontrollen ændres samtidig. Ellers giver kontrollen falske afvigelser, og efter nogle uger holder folk op med at læse dem. Det er almindelig praksis at lade ændringsprocessen have et punkt om, hvilke kontroller en ændring berører, så de forventede værdier følger med.
Hvem læser afvigelserne
Afvigelserne skal ende hos en person, der kan vurdere dem og har mandat til at rette. I en lille drift kan det være den samme tekniker, der har bygget kontrollen. Det er bedre end ingen, men det er en god idé, at en anden ser listen igennem med faste mellemrum, så en afvigelse ikke bliver forklaret væk af den, der lavede ændringen.
Undtagelserne
Løbende kontrol finder også det, der bevidst er anderledes. Derfor skal undtagelseslisten kobles på kontrollerne. En afvigelse, der står på listen med gyldig begrundelse og udløb, skal ikke give alarm. En afvigelse, der ikke står der, eller hvis undtagelse er udløbet, skal.
Gennemgangen bagefter
Med løbende kontrol bliver den næste gennemgang anderledes. Den kan bruge kontrollernes historik som bevis for, at opsætningen har holdt, og bruge sin tid på det, kontrollerne ikke dækker. Punkt 6.3.3’s gennemgang med planlagte mellemrum bliver så en gennemgang af både opsætningen og kontrollerne selv.
Hvad det kræver, og hvad det koster at lade være
Det kræver tid at gøre udtrækkene automatiske og en konto med læseret, der kan køre dem. De første kontroller kan ofte bygges på de kommandoer, gennemgangen allerede brugte.
Uden løbende kontrol glider opsætningen langsomt væk fra baselinen. Ved næste gennemgang står mange af de samme fund igen, og det er svært at sige, hvornår de opstod.
Det skal I lade være med
- At regne håndhævelse for kontrol · gruppepolitikken rammer ikke alt.
- At bygge kontroller, hvis resultat ingen læser · giv hver kontrol en modtager.
- At lade bevidste undtagelser give alarm hver dag · kobl undtagelseslisten på.
Det skal gennemgangen kunne vise
- ☐ En skrevet baseline med forventede værdier for de udvalgte kontroller.
- ☐ Planlagte kontroller med kørselshistorik.
- ☐ Afvigelser med modtager, behandling og dato.
- ☐ Kobling mellem kontrollerne og undtagelseslisten.
Kilder
- Gennemførelsesforordning (EU) 2024/2690, dansk tekst, bilagets punkt 6.3.1, 6.3.2, 6.3.3 og 7, læst 13. november 2026.
- Delegeret forordning (EU) 2024/1774, artikel 11, stk. 2, litra b, læst 13. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Vælg ét udtræk fra jeres seneste gennemgang, og lad det køre som planlagt opgave hver uge med besked ved afvigelse.
Læs også: Opfølgende gennemgang · Undtagelseslisten
→ Kontakt · Tlf. 70 13 63 23 · Teknisk sikkerhedsgennemgang hos Nielco IT
