En penetrationstest er et øjebliksbillede, og dagen efter rapporten kan en ny server komme på nettet eller en ny svaghed blive offentliggjort. Løbende sårbarhedsscanning udfylder pauserne mellem testene, men kun hvis IT-afdelingen bestemmer, hvad den skal holde øje med, hvem der læser resultaterne, og hvad der sker med dem. Scanningen er et opsyn med kendte fejl. Den er ikke en mindre udgave af testen.
Forskellen på de to opgaver og deres plads i sårbarhedsstyringen er forklaret for køberen på penetrationtest.dk. Her handler det om, hvordan driften bruger scanningen i perioden mellem to test.
Hvad scanningen kan, og hvad den ikke kan
Den amerikanske standardorganisation NIST beskriver i sin tekniske vejledning om sikkerhedstest, at en sårbarhedsscanning sammenligner de systemer, den finder, med en database over kendte svagheder. Den kan pege på manglende opdateringer, forældede versioner og opsætning, der afviger fra jeres politik. Den samme vejledning nævner også begrænsningerne: scanningen ser kun systemer, der er tændt og nås, den finder svagheder hver for sig og ikke i sammenhæng, og den melder fejl, som ikke findes.
For IT betyder det tre ting.
- Bredde frem for dybde · scanningen dækker mange systemer ofte, men den undersøger ikke, hvad en svaghed kan føre til.
- Kendte fejl · forkerte rettigheder, svage arbejdsgange og fejl i jeres egen opsætning af forretningssystemer ligger uden for, hvad scanningen kan se.
- Rå data · resultatet er en liste, der skal vurderes af nogen, der kender systemerne.
Det er grunden til, at scanningen supplerer testen og ikke erstatter den.
Hvad scanningen skal holde øje med
Brug den seneste rapport som udgangspunkt for, hvor scanningen skal se. Rapportens fund fortæller, hvor jeres svage punkter var, og scanningen kan vise, om de bliver ved med at være lukkede.
- De internetvendte systemer · alt, der kan nås udefra, også det, der kom til efter testen. → Overblik over internetvendte systemer
- Opdateringsstatus · servere og klienter, der halter efter resten. → Opdateringsstatus på klienter og servere
- Rettede fund · de forhold, rapporten påpegede, og som er meldt lukket.
- Nye systemer · maskiner og tjenester, der ikke var med, da testen blev planlagt.
- Systemer uden support · det, der er accepteret som midlertidigt, men stadig står der.
Scanningen bør dække hele det miljø, I har ansvar for, ikke kun det, testen havde i scope. Et scope er en afgrænsning af en opgave. Opsynet i driften har ikke samme grænse.
Hvem læser resultatet
En scanning, som ingen læser, giver kun en falsk tryghed. Giv derfor resultatet en ejer, og aftal hvor ofte listen gennemgås. Hyppigheden afhænger af, hvor hurtigt jeres miljø ændrer sig, og hvor meget der står ud mod internettet. Der findes ikke én rigtig takt.
Ejeren skal kunne skelne mellem tre slags resultater.
- Falske fund · meldinger om svagheder, der ikke findes. De noteres, så de ikke vurderes igen næste gang.
- Reelle, men uden betydning · svagheder, der findes, men hvor systemets rolle gør risikoen lav. Vurderingen skrives ned med en begrundelse.
- Reelle og vigtige · svagheder, der skal ind i opgavesystemet med en ejer og en frist. → Fra fund til opgave
Den amerikanske vejledning understreger også, at den alvorlighed, et scanningsværktøj sætter på et fund, ikke nødvendigvis afspejler den faktiske risiko for organisationen. Den samme vurdering gælder her som for fundene i rapporten: værktøjets niveau er et udgangspunkt, jeres viden om systemet afgør prioriteten.
Når scanningen og rapporten ikke er enige
Det sker, at scanningen ikke melder noget på et system, hvor rapporten fandt et alvorligt problem. Det betyder ikke, at problemet er væk. Fundet i rapporten kan være opstået af en kombination af flere mindre forhold, eller det kan ligge i opsætningen af en rolle eller en rettighed, som scanningen ikke ser.
Omvendt kan scanningen melde svagheder på et system, som testeren ikke nævnte. Det kan skyldes, at systemet lå uden for scope, at svagheden er blevet kendt efter testen, eller at meldingen er falsk. Alle tre forklaringer skal undersøges, før fundet afvises.
Uoverensstemmelserne er nyttige i sig selv. Hvis testeren fandt noget, scanningen aldrig har meldt, ved I, at opsynet har en blind vinkel på netop den type forhold. Hvis scanningen melder noget, der er overset i flere måneder, peger det på en svaghed i gennemgangen af resultaterne. Skriv begge dele ned, og tag dem med, når næste test skal planlægges. Så bliver scanningen og testen to kilder, der retter hinanden, og ikke to lister, der lever hver sit liv.
Brug derfor aldrig en ren scanning som bevis for, at et fund fra testen er rettet. Kontrollen af rettelserne er en opgave for sig. → Klar til retest
Driftens hensyn
Scanning sender trafik mod systemerne, og ifølge samme vejledning kan den påvirke de systemer og net, der scannes. Det gælder især ældre udstyr og skrøbelige systemer, der også krævede særlige hensyn under testen.
- Samme hensyn som under testen · systemer, der blev behandlet varsomt i testen, skal også behandles varsomt i scanningen. → Skrøbelige systemer
- Kendte tidspunkter · overvågningen og servicedesken skal vide, hvornår der scannes, så alarmer ikke behandles som angreb.
- Opdateret database · et værktøj, der ikke kender de seneste svagheder, finder dem ikke.
- Adgang til scanningen · resultaterne er en liste over jeres svage punkter og skal beskyttes som en pentestrapport.
Har en driftsleverandør ansvaret for scanningen, skal aftalen sige, hvad der scannes, hvor ofte, og hvem der modtager og vurderer resultatet.
Det skal I lade være med
- At kalde en scanning for en penetrationstest. Den finder kendte fejl, ikke sammenhænge.
- At scanne uden en ejer af resultatet. En liste uden læser er ikke et opsyn.
- At bruge værktøjets alvorlighed direkte. Den kender ikke systemets betydning for jer.
- At begrænse scanningen til testens scope. Det nye og glemte kan ligge udenfor.
- At lukke et fund fra rapporten, fordi scanningen er ren. Testerens fund er ikke nødvendigvis synligt for scanningen.
Hvad kan og ikke kan konkluderes
Løbende scanning kan vise, at kendte svagheder bliver opdaget og rettet mellem testene, og at nye systemer ikke glider uden om opsynet. Den kan ikke vise, at miljøet modstår en angriber, eller at fejl i rettigheder, logik og arkitektur er væk. En rolig scanningshistorik er ikke en grund til at springe næste test over.
Tjekliste til scanningen mellem testene
- ☐ Dækker scanningen hele det miljø, I har ansvar for, også nye systemer?
- ☐ Bruges rapportens fund til at vælge, hvor scanningen ser efter?
- ☐ Har resultatet en navngiven ejer og en fast gennemgang?
- ☐ Bliver falske og ubetydelige fund noteret med en begrundelse?
- ☐ Kommer vigtige fund ind i opgavesystemet med ejer og frist?
- ☐ Er skrøbelige systemer undtaget eller behandlet varsomt?
- ☐ Er resultaterne beskyttet som en rapport om jeres svagheder?
Kilder
- NIST SP 800-115, afsnit 4.3: sårbarhedsscanning sammenligner fundne systemer med kendte svagheder, ser kun aktive systemer og svagheder hver for sig, kan melde falske fund og påvirke systemerne, og værktøjets risikoniveau afspejler ikke nødvendigvis organisationens faktiske risiko.
- NCSC: Vulnerability management: sårbarhedsstyring som en løbende proces, der skal prioritere og udvikle sig med miljøet.
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler til IT-afdelingen
Læs også: Fremdrift på rettelserne · Rapporten i næste års driftsplan
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT
