Teknisk Audit

Automatisk måling mod benchmark: hvad rapporten viser, og hvad der stadig skal læses i hånden

Automatisk måling mod benchmark: hvad rapporten viser, og hvad der stadig skal læses i hånden

Har I kørt et værktøj, der måler jeres maskiner mod en benchmark eller baseline, står I med en rapport med mange linjer markeret som bestået eller ikke bestået. Rapporten er hurtig at lave og giver samme resultat hver gang, men den viser ikke, hvilke afvigelser der er bevidste, hvilke der hænger sammen, og hvilke indstillinger værktøjet slet ikke kan se.

Automatisk måling og læsning i hånden er ikke to alternativer. Den første giver bredden, den anden giver forståelsen.

Hvad NIST siger om de to metoder

NIST beskriver konfigurationsgennemgang i vejledningen SP 800-115 fra september 2008. Det centrale afsnit er 3.4. Her er de vigtigste pointer gengivet:

  • Opsætningen kan sammenlignes manuelt med vejledninger eller tjeklister for sikker konfiguration.
  • Den kan også måles automatisk. NIST nævner SCAP som en metode til automatiseret måling.
  • Automatiske gennemgange er hurtigere end manuelle, men der kan stadig være indstillinger, der må kontrolleres manuelt.
  • Begge metoder kræver root- eller administratorrettigheder for at se visse sikkerhedsindstillinger.
  • Som hovedregel bør maskinen måle, når den kan, for så bliver resultatet det samme fra gang til gang.

Den sidste pointe er grunden til, at automatisk måling bør være udgangspunktet. Den anden og tredje pointe er grunden til, at den ikke kan stå alene.

Hvad en automatisk rapport kan vise

En måling mod en benchmark viser for hver regel i målestokken, om den faktiske indstilling svarer til den anbefalede. Gjort rigtigt giver det:

  • En fuldstændig liste over afvigelser på de maskiner, der er målt.
  • Samme resultat, hvis målingen gentages på samme opsætning.
  • Et grundlag for at sammenligne maskiner i samme rolle og finde dem, der skiller sig ud.

Det sidste er værdifuldt. NIST nævner blandt de typiske grundårsager til svagheder mangel på baselines, fx uensartede sikkerhedsindstillinger på ensartede systemer (afsnit 7.3). Den automatiske måling finder netop den slags.

Nogle benchmark-udgivere har deres eget måleværktøj. Hvad rapporterne fra de enkelte værktøjer indeholder, beskriver vi ikke her. Læs værktøjets egen dokumentation, før rapporten bruges som bevis.

Hvad der stadig skal læses i hånden

Det er praksis, ikke regel, men følgende fund kræver typisk, at nogen læser opsætningen i sammenhæng:

  • Bevidste afvigelser · Værktøjet ved ikke, at en indstilling er valgt fra med begrundelse
  • Firewallregler · En regel kan være teknisk korrekt og alligevel unødig eller for bred
  • Gruppemedlemskaber · Værktøjet kan tælle medlemmer, men ikke vurdere, om de skal være der
  • Undtagelser i politikker · En politik for betinget adgang kan være korrekt sat og undtage den forkerte gruppe
  • Sammenhænge · To indstillinger, der hver for sig er acceptable, kan tilsammen åbne for mere end tilsigtet
  • Det, værktøjet ikke kan se · Indstillinger uden for værktøjets regler, eller som kræver rettigheder, målekontoen ikke har

Den sidste linje er vigtig. En rapport, der viser få afvigelser, kan skyldes, at opsætningen er god. Den kan også skyldes, at målekontoen manglede rettigheder til at læse indstillingerne. Rapporten bør derfor altid sige, hvilken konto der målte, og hvor mange regler der ikke kunne vurderes.

Det samme gælder maskiner, der ikke blev nået. En måling, der er planlagt mod alle servere i en rolle, men kun nåede en del af dem, giver et billede, der ser fuldstændigt ud. Sammenlign derfor antallet af målte maskiner med systemlisten, før resultatet bruges.

Falske positive og rangordning

NIST skriver om sårbarhedsscanning, at falske positive skal frasorteres, og at manuel kontrol typisk er mere præcis end at sammenligne værktøjer (afsnit 7.3). Den, der vurderer, bør heller ikke uden videre overtage værktøjets egne risikoniveauer (afsnit 4.3). Det samme gælder en konfigurationsmåling. En regel markeret som høj risiko i værktøjet kan være uden betydning i jeres miljø, og omvendt.

En arbejdsdeling, der virker

En fremgangsmåde, der er sitets forslag:

  1. Mål alle maskiner i en rolle automatisk, ikke kun et udvalg, når værktøjet tillader det.
  2. Sammenlign resultaterne mellem maskinerne, og find dem, der afviger fra de andre.
  3. Læs regelsæt, grupper og politikker i hånden, hvor rapporten ikke kan vurdere.
  4. Kør målingen igen efter rettelserne med samme værktøj, udgave og målestok, så forskellen kan ses.

Ifølge afsnit 8 kan en rettelse kun bekræftes teknisk, når den første test køres igen på præcis samme måde. Det taler for at gemme opsætningen af målingen sammen med rapporten.

Hvad det kræver, og hvad det koster at lade være

Det kræver et værktøj, der kan måle mod den valgte målestok, en målekonto med de rette læserettigheder og tid til at læse de områder, værktøjet ikke dækker. Rapporten skal gemmes med tidspunkt, udgave og konto.

Uden automatisk måling bliver gennemgangen en stikprøve, og uensartede maskiner bliver ikke fundet. Uden læsning i hånden bliver rapporten en lang liste, hvor de alvorlige fund drukner mellem de ligegyldige.

Det skal I lade være med

  • At læse få afvigelser som et godt resultat uden at kontrollere målekontoens rettigheder · værktøjet kan have været blindt.
  • At overtage værktøjets risikoniveauer uden vurdering · NIST fraråder det.
  • At skifte værktøj eller udgave mellem første måling og opfølgning · så kan forskellen ikke ses.

Det skal gennemgangen kunne vise

  • ☐ Rapport fra den automatiske måling med tidspunkt, værktøj, udgave og målekonto.
  • ☐ Antal regler, der ikke kunne vurderes, og hvorfor.
  • ☐ Notater fra læsningen i hånden af regelsæt, grupper og politikker.
  • ☐ En ny måling efter rettelserne med samme opsætning.

Kilder

Senest gennemgået: november 2026.

Næste skridt

Find den seneste automatiske måling, I har, og kontrollér, hvilken konto der målte, og hvor mange regler der ikke kunne vurderes.

Det samme gælder maskiner, der ikke blev nået. En måling, der er planlagt mod alle servere i en rolle, men kun nåede en del af dem, giver et billede, der ser fuldstændigt ud. Sammenlign derfor antallet af målte maskiner med systemlisten, før resultatet bruges.

Læs også: Stikprøve af servere og klienter · Opfølgende gennemgang: samme udtræk, nyt resultat

→ Kontakt · Tlf. 70 13 63 23 · Teknisk sikkerhedsgennemgang hos Nielco IT

Skrevet af John Nielsen, indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Om John Nielsen · LinkedIn

John Nielsen, Nielco IT

Skal jeres opsætning gennemgås?

Skriv kort, hvilke dele af miljøet det drejer sig om, og hvad der sætter det i gang. Så vender jeg tilbage. Gennemgangen er uvildig og uafhængig, og Nielco IT har ingen forhandleraftaler.

Tak for din henvendelse. Jeg vender tilbage hurtigst muligt.