Et tal, der siger, at næsten alle servere har backup, lyder præcist, men det er kun så godt som listen over servere. Mangler en del af systemerne på listen, kan tallet være højt, mens det reelle hul er stort.
Det er sitets vurdering, at nævneren er den svageste del af de fleste dækningstal. Tælleren kommer fra et værktøj, der viser det, det kender. Nævneren burde være alt det, der skulle være dækket, og den findes sjældent ét sted.
Hvad NIST siger om den slags tal
NIST kalder den slags tal implementeringsmålinger i sin vejledning om sikkerhedsmåling. De viser fremdrift i at indføre en kontrol og opgøres som regel i procent. Vejledningen giver eksemplet andelen af servere i et system med en standardkonfiguration.
Vejledningen har et særskilt felt for scope i beskrivelsen af hver måling. Det felt skal vise forskellen på hele risikoen og den del, tallet faktisk dækker. Datakilde og implementeringsbevis er egne felter. Tilsammen siger felterne, at et dækningstal skal oplyse, hvad det dækker, hvor tallene kommer fra, og hvordan man kan se, at de er rigtige.
Hvorfor nævneren snyder
Der er tre typiske grunde til, at nævneren er for lille.
- Værktøjet tæller sig selv · et backupværktøj kender kun de servere, der er sat op i det. Spørger man det om dækning, svarer det ud fra sin egen liste.
- Listerne er lokale · i en koncern har hvert selskab sin oversigt, og de følger ikke samme regler for, hvad der tælles med.
- Nye ting kommer ikke med · cloudtjenester, testmiljøer og systemer fra et opkøbt selskab står ofte uden for listen, til nogen opdager dem.
Når et dækningstal stiger, kan det derfor skyldes to ting. Flere systemer er dækket, eller nogle systemer er røget ud af nævneren. Uden et blik på nævneren kan man ikke se forskel.
Sådan efterprøves udtrækket
Det er almindelig praksis i en vurdering at efterprøve et dækningstal ved at sammenholde to uafhængige lister. Tænkte eksempler:
- Stærk godkendelse · Kilde til tælleren: Identitetssystemets rapport · Uafhængig kilde til nævneren: Lønsystemets liste over ansatte og konsulentkontrakter
- Central logning · Kilde til tælleren: Logplatformens liste over kilder · Uafhængig kilde til nævneren: Aktivregistret eller netværksscanning
- Backup · Kilde til tælleren: Backupværktøjets jobliste · Uafhængig kilde til nævneren: Virtualiseringsplatformens og cloudkontoens liste over maskiner
- Opdateret software · Kilde til tælleren: Patchværktøjets rapport · Uafhængig kilde til nævneren: Netværksscanning af aktive enheder
Forskellen mellem de to lister er fundet. Systemer, der står i den uafhængige kilde, men ikke i værktøjet, er de huller, dækningstallet ikke viser.
Det er også god praksis at tage en lille stikprøve fra den uafhængige liste og følge hvert system ind i værktøjet. Det viser, om tallet holder i praksis, og det kan gøres af intern revision eller anden linje uden ekstern hjælp. De tekniske detaljer i den slags kontrol er beskrevet på sitet om tekniske kontrolpunkter.
Data fra egne værktøjer som bevis
Udtræk fra egne værktøjer er ofte det bedste bevis, der findes. De er hurtige, fuldstændige for det, de dækker, og kan trækkes igen. Svagheden er, at de ikke siger noget om det, de ikke kender. Derfor bør et udtræk altid ledsages af en oplysning om, hvilken liste det er holdt op imod.
En vurdering kan acceptere et værktøjsudtræk som bevis, hvis nævneren er efterprøvet. Uden den efterprøvning er udtrækket en påstand om dækning, ikke et bevis. Hvad der generelt tæller som bevis i en audit, gennemgås på sitet om den almene auditmetode.
Dækningsgrad i rapporten til bestyrelsen
I en rapport til bestyrelsen er det sitets forslag at vise dækningsgraden sammen med to oplysninger: hvilken liste nævneren kommer fra, og hvornår den sidst blev sammenholdt med en uafhængig kilde. Det tager én linje, men det fortæller læseren, om tallet kan bære en beslutning.
I en koncern bør tallet vises pr. selskab. Et selskab med en mangelfuld liste kan ellers trække koncerntallet op, fordi det ser ud til at have fuld dækning af det lille, det kender.
Når nævneren ændrer sig
Nævneren skifter, når koncernen køber eller sælger selskaber, flytter systemer til skyen eller lukker gamle platforme. Det er god praksis at notere hver større ændring i nævneren i rapporten, så læseren kan se, om en ændring i dækningsgraden skyldes arbejde med kontrollen eller ændringer i, hvad der tælles med. Et tænkt eksempel er et opkøbt selskab med mange servere uden backup, som får koncernens dækningstal til at falde, selvom intet er blevet dårligere i de andre selskaber.
Hvad det kræver, og hvad det koster at lade være
Det kræver en fælles definition af, hvad der skal tælles med, og mindst én uafhængig liste at sammenholde med. Sammenholdelsen skal gentages, fordi miljøet ændrer sig.
Lader man være, viser rapporten høje tal, mens de systemer, ingen kender, står udækkede. Det er ofte netop dem, en angriber finder.
Det skal I lade være med
- At lade værktøjet levere både tæller og nævner · så måler det kun sig selv.
- At lægge enhedernes dækningstal sammen uden fælles definition · nævnerne er forskellige.
- At fejre en stigning uden at se på nævneren · den kan skyldes færre systemer på listen.
Det skal gennemgangen kunne vise
- ☐ En skriftlig definition af nævneren for hvert dækningstal.
- ☐ En dato for sidste sammenholdelse med en uafhængig liste.
- ☐ Listen over systemer, der manglede i værktøjet.
- ☐ Dækningstal pr. selskab med samme definition.
Kilder
- NIST SP 800-55v1, december 2024, afsnit 3.1.1 og 3.3.1, læst 14. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Vælg ét dækningstal fra jeres rapport, og find ud af, hvilken liste nævneren kommer fra. Sammenhold den med én uafhængig kilde.
Læs også: Overvågning med huller · NIST SP 800-55 fra 2024
→ Kontakt · Tlf. 70 13 63 23 · Sikkerhedsmodenhed hos Nielco IT
