En sårbarhedsscanning finder kun sårbarheder på de systemer, den er sat til at scanne. Kontrollen af dækningen består i at lægge scannerens mål ved siden af den fulde liste over net og systemer og finde det, der aldrig bliver scannet.
Scanneren kan ikke selv vise hullet. Dens rapport handler om det, den har set. Et net, der ikke står i dens mål, findes ikke for den, og et system, der var slukket, mens scanningen kørte, optræder ikke som et fund.
Hvad målestokkene siger
To punkter i bilaget til forordning 2024/2690 hører sammen her. Punkt 6.10.2, litra b, handler om scanning efter en fast plan med dokumenterede resultater, hvor det er relevant. Punkt 12.4 handler om en fuldstændig fortegnelse over aktiver. Begge binder de omfattede enheder og kan lånes af alle andre, og kontrollen her er afstemningen mellem dem.
Hos finansielle enheder kræver artikel 10 i DORA’s tekniske standard automatiseret sårbarhedsscanning, hvor hyppighed og omfang følger aktivets klassificering og risikoprofil. Aktiver bag kritiske eller vigtige funktioner skal scannes mindst en gang om ugen. Alle opdagede sårbarheder registreres, og afviklingen overvåges. Ugekravet gælder kun det afgrænsede og kun finansielle enheder.
Vejledningen til de statslige tekniske minimumskrav stiller et andet krav, som ofte bliver læst forkert. Myndigheder skal mindst hvert kvartal lave en portscanning af deres egne internettilgængelige IP-adresser, og det er nok at scanne alle TCP-porte. Vejledningen skriver ligeud, at tjenesterne skal afdækkes, men at de ikke skal sårbarhedsscannes. Ubrugte adresser, myndigheden har brugsret til, skal også scannes. Leverandørers adresser er ikke omfattet, men vejledningen anbefaler krav i kontrakterne. Kravet binder statslige myndigheder.
Hvorfor huller opstår
NIST SP 800-115 fra 2008 påpeger, at netværksbaseret scanning kun finder aktive systemer. Det er den enkleste forklaring på mange huller. En bærbar, der var hjemme i scanningsvinduet, en server, der kun startes ved månedsskiftet, eller en virtuel maskine, der var slukket, bliver ikke set.
De andre forklaringer handler om opsætningen. Nye net bliver oprettet uden at komme med i scannerens mål. Net bag en firewall, som scanneren ikke kan nå, giver ingen fund, fordi trafikken bliver blokeret. Cloudmiljøer ligger ofte helt uden for den lokale scanners rækkevidde. Og systemer, der drives af en leverandør, er måske undtaget i aftalen uden, at nogen har noteret det.
Afstemningen
Afstemningen bygger på to lister.
Den første er den fulde liste over net og systemer. Den bør bygges fra systemerne selv: DHCP-områder, routertabeller, katalogets computerobjekter, hypervisorens maskiner og cloudkontoens ressourcer. En liste, der kun er skrevet i hånden, har typisk de samme huller som scanneren.
Den anden er scannerens mål og resultat: hvilke net og adresser den er sat til, og hvilke systemer den faktisk har set ved seneste scanning.
Læg dem ved siden af hinanden. Net, der står i den første liste, men ikke i scannerens mål, er aldrig scannet. Systemer, der står i den første liste og ligger i et scannet net, men ikke er set af scanneren, var slukket, utilgængelige eller blokeret. Begge slags er fund.
Et tænkt resultat kan se sådan ud: tolv net i alt, ti i scannerens mål, et gæstenet og et net til produktionsudstyr udeladt. Af 340 kendte maskiner i de scannede net er 41 ikke set ved seneste scanning, de fleste bærbare.
Intervallet
Kun DORA’s standard sætter et tal på, hvor ofte der skal scannes, og kun for det afgrænsede område. Forordningens bilag nøjes med at tale om en plan. Hyppigheden er derfor jeres egen beslutning, som skrives ned med begrundelse i risikoen. Gennemgangen kontrollerer derefter, om scanningerne faktisk er kørt med det interval, I har besluttet, ved at læse scannerens historik for det seneste år.
At lukke hullerne
Nogle huller lukkes ved at føje net til målet. Andre kræver en anden metode. Bærbare, der sjældent er på kontoret, kan dækkes af en agent eller en scanning med login, der kører, når maskinen er tilsluttet. Net bag en firewall kan kræve en scanner placeret inde i nettet. Systemer hos en leverandør kræver en aftale om, hvem der scanner, og at resultatet deles.
Hvert hul, der ikke lukkes, bør stå på undtagelseslisten med begrundelse, ejer og udløb.
Hvad det kræver, og hvad det koster at lade være
Afstemningen kræver en systemliste bygget fra flere kilder og adgang til scannerens opsætning og resultat. Første gang er arbejdet størst, fordi systemlisten skal bygges.
Uden afstemningen kan scanningsrapporten se ren ud, mens et helt net står uden for. De sårbarheder, der findes dér, bliver aldrig rapporteret, og ingen spørger efter dem.
Det skal I lade være med
- At læse en ren scanningsrapport som bevis for, at alt er scannet · den viser kun det, scanneren så.
- At bruge en håndskrevet netliste som facit · byg listen fra systemerne selv.
- At tro, at statens kvartalsvise portscanning er en sårbarhedsscanning · den afdækker kun tjenester.
Det skal gennemgangen kunne vise
- ☐ En liste over net og systemer bygget fra mindst to uafhængige kilder.
- ☐ Scannerens mål og de systemer, den faktisk så ved seneste scanning.
- ☐ En afstemning med net uden for målet og systemer, der ikke blev set.
- ☐ En undtagelsesliste for de huller, der ikke lukkes, med begrundelse og udløb.
Kilder
- Gennemførelsesforordning (EU) 2024/2690, dansk tekst, bilagets punkt 6.10.2 og 12.4, læst 13. november 2026.
- Delegeret forordning (EU) 2024/1774, artikel 10, stk. 2, litra b og h, læst 13. november 2026.
- Vejledning til de tekniske minimumskrav til it-sikkerhed i staten, september 2025, afsnit 3.9, læst 13. november 2026.
- NIST SP 800-115, september 2008, afsnit 4.4, læst 13. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Træk DHCP-områderne fra jeres DHCP-servere, og se, om hvert område står i scannerens mål.
Læs også: Undtagelseslisten · Det, der står åbent mod internettet
→ Kontakt · Tlf. 70 13 63 23 · Teknisk sikkerhedsgennemgang hos Nielco IT
