Før nogen kan kalde en indstilling forkert, skal der være aftalt, hvad den holdes op imod. Vælg målestokken pr. platform før gennemgangen, skriv valget ind i planen, og hav en fast måde at begrunde de afvigelser på, I har valgt med vilje.
Uden den aftale bliver rapporten en liste over uenigheder. Med den bliver hver afvigelse et spørgsmål, driften kan svare på.
Hvorfor målestokken skal vælges først
NIST beskriver konfigurationsgennemgang som en sammenligning. Opsætningen holdes op mod vejledninger eller tjeklister for sikker konfiguration, og det, der afviger, markeres og rapporteres (NIST’s vejledning SP 800-115 fra 2008, afsnit 3.4). Metoden er altså kun så god som det, der sammenlignes med.
Det har en praktisk følge for driften. Skifter målestokken midt i forløbet, skifter fundene også. En indstilling kan være i orden efter én vejledning og en afvigelse efter en anden. Derfor hører valget hjemme i planen, før det første udtræk trækkes, og ikke i rapporten bagefter.
De målestokke, der typisk er i spil
Ingen af målestokkene nedenfor er bedre end de andre i almindelighed. De er skrevet af forskellige afsendere til forskellige formål, og de dækker forskellige lag.
- CIS Benchmarks · Afsender: Center for Internet Security · Dækker: Styresystemer, programmer og tjenester, udviklet ved konsensus og findes for mere end 100 produkter · Binder: Ingen; frivillig
- Producentens sikkerhedsbaseline · Afsender: Producenten af platformen · Dækker: Producentens egne produkter · Binder: Ingen; frivillig
- De tekniske minimumskrav · Afsender: Styrelsen for Samfundssikkerhed · Dækker: Ti kategorier med konkrete parametre · Binder: Statslige myndigheder
- SCuBA-baselines · Afsender: CISA (USA) · Dækker: Microsoft 365 og Google Workspace · Binder: Amerikanske føderale civile myndigheder
- Bilaget til forordning 2024/2690 · Afsender: EU-Kommissionen · Dækker: Krav i overordnede vendinger, fx konfigurationsstyring i punkt 6.3 · Binder: De digitale tjenesteudbydere i forordningens artikel 1
Microsoft anbefaler selv at tage udgangspunkt i en kendt og afprøvet konfiguration frem for at bygge sin egen. Det samme argument gælder de andre: en målestok, mange har brugt og diskuteret, er lettere at forklare end et hjemmelavet sæt indstillinger.
Sådan vælges pr. platform
Valget er praksis, og der findes ingen regel, der fastlægger det. En rimelig fremgangsmåde kan se sådan ud:
- Lav en liste over de platforme, gennemgangen omfatter: katalog, klienter, servere, netværksudstyr, kontorplatform, cloudmiljø.
- Vælg én primær målestok pr. platform. Findes der en producentbaseline og et benchmark for samme platform, så vælg én af dem som den, fundene måles imod, og brug den anden som opslag.
- Skriv versionen og datoen på målestokken ind i planen. En baseline bliver opdateret, og et fund skal kunne genskabes mod præcis den udgave, der blev brugt.
- Notér, hvor målestokken ikke dækker. Der findes ikke en benchmark for alt, og et fagsystem uden offentlig vejledning måles mod producentens dokumentation eller mod en aftalt intern standard.
Er virksomheden omfattet af regler med konkrete tekniske krav, fx DORA for finansielle enheder, kommer de krav først. Den frivillige målestok udfylder så det, reglerne ikke siger noget om.
Når I vælger at afvige
Ingen virksomhed følger en målestok punkt for punkt. Nogle indstillinger bryder et fagsystem. Andre er overflødige, fordi risikoen håndteres et andet sted. Spørgsmålet er, om afvigelsen er et valg eller et hul.
Microsoft har selv et princip, der kan bruges som rettesnor. En baseline håndhæver en indstilling, hvis den modvirker en aktuel trussel og ikke skaber større gener i driften end den sikkerhed, den giver. Den tanke kan driften vende om: en afvigelse er rimelig, når gevinsten i sikkerhed er mindre end generne, og det kan vises.
Forordning 2024/2690 giver et mønster for selve begrundelsen. Efter artikel 2, stk. 2, skal en omfattet enhed, der vurderer et krav som ikke relevant, give en forståelig skriftlig begrundelse. Det gælder de krav, der er formuleret med forbehold som “hvor det er relevant”. Punkt 6.6.2 siger det samme om en patch, der ikke installeres. Forordningen gælder kun de digitale tjenesteudbydere, den nævner, men måden at dokumentere på kan bruges af alle.
En begrundet afvigelse har fire felter:
- Indstillingen og målestokkens anbefaling (tænkt eksempel: en ældre protokol står åben på to servere).
- Grunden til afvigelsen (et fagsystem understøtter ikke den nyere protokol).
- Hvad der afbøder risikoen i stedet (serverne kan kun nås fra et afgrænset segment).
- Hvem der har godkendt, og hvornår afvigelsen skal ses på igen.
Står de fire felter udfyldt, før gennemgangen begynder, er der ikke længere tale om et fund, men om en kendt og accepteret afvigelse. Gennemgangen kontrollerer så, at begrundelsen stadig holder, og at afbødningen faktisk findes i opsætningen.
Hvad det kræver, og hvad det koster at lade være
Det kræver, at nogen i driften vælger målestok pr. platform og skriver versionen ned. Det kræver også en liste over de afvigelser, I allerede kender, med begrundelse. Arbejdet er størst første gang.
Uden et aftalt valg vælger den, der gennemgår, selv. Så kan I få en lang liste af afvigelser fra en målestok, I aldrig har tænkt på at følge, og fundene bliver svære at prioritere. Uden begrundede afvigelser kommer de samme punkter igen ved hver gennemgang.
Det skal I lade være med
- At blande flere målestokke for samme platform · fundene bliver umulige at sammenligne fra gang til gang.
- At lade versionen af målestokken stå åben · et fund skal kunne genskabes mod den udgave, der blev brugt.
- At kalde en frivillig målestok for et krav · kun regler, I er omfattet af, binder jer.
Det skal gennemgangen kunne vise
- ☐ Én navngiven målestok pr. platform, med version og dato.
- ☐ Platforme eller systemer, som målestokken ikke dækker, og hvad der bruges i stedet.
- ☐ En begrundelse for hver kendt afvigelse med afbødning, godkender og dato for næste vurdering.
- ☐ Rækkefølgen mellem bindende regler og frivillige målestokke.
Kilder
- NIST SP 800-115, Technical Guide to Information Security Testing and Assessment, september 2008, afsnit 3.4, læst 13. november 2026.
- Microsoft Learn, Security baselines guide, opdateret 18. august 2025, læst 13. november 2026.
- CIS, CIS Benchmarks FAQ, læst 13. november 2026.
- Gennemførelsesforordning (EU) 2024/2690, artikel 1, artikel 2, stk. 2, og bilaget, punkt 6.6.2, læst 13. november 2026.
- Styrelsen for Samfundssikkerhed, Vejledning til de tekniske minimumskrav, september 2025, afsnit 1.2 og 3, læst 13. november 2026.
- CISA, Secure Cloud Business Applications (SCuBA), læst 13. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Skriv en linje pr. platform i jeres miljø med den målestok, I vil måles imod, og versionen af den.
Læs også: CIS Benchmarks Level 1 og Level 2 · Microsofts sikkerhedsbaselines
→ Kontakt · Tlf. 70 13 63 23 · Teknisk sikkerhedsgennemgang hos Nielco IT
