Sårbarhedsstyring og penetrationstest: to forskellige opgaver

Skal virksomheden have sårbarhedsstyring, en penetrationstest eller begge dele? Svaret hviler på, at de to løser forskellige opgaver: sårbarhedsstyring er en løbende driftsproces, mens en penetrationstest er en afgrænset afprøvning på et bestemt tidspunkt.

Den ene erstatter ikke den anden. Sårbarhedsstyring holder styr på kendte svagheder i alle de systemer, virksomheden har ansvar for. En penetrationstest undersøger, hvad udvalgte svagheder betyder i praksis, og finder ofte forhold, som en løbende proces ikke opdager. Spørgsmålet er derfor sjældent enten eller, men hvordan de to hænger sammen.

Sårbarhedsstyring er en proces, ikke en leverance

Sårbarhedsstyring betegner det løbende arbejde med at finde, vurdere, prioritere og håndtere tekniske svagheder. Arbejdet gentages hele tiden, fordi nye svagheder bliver kendt, og fordi systemerne ændrer sig. Det er en del af den almindelige drift på linje med backup og brugeradministration.

Processen bygger typisk på en oversigt over virksomhedens systemer, oplysninger om kendte svagheder og en fast måde at beslutte, hvad der skal rettes hvornår. Kendte svagheder har ofte et fælles nummer i det offentlige katalog, så forskellige parter kan tale om den samme fejl. → CVE forklaret

ISO/IEC 27001 indeholder en kontrol om håndtering af tekniske sårbarheder. Den beskriver en ramme for at få oplysninger om sårbarheder, vurdere eksponeringen og træffe passende foranstaltninger. Standarden siger ikke, at kontrollen opfyldes ved én bestemt aktivitet, og den gør ikke en enkelt test til en proces. → Penetrationstest og standarder

En penetrationstest besvarer et afgrænset spørgsmål

En penetrationstest tager udgangspunkt i et aftalt spørgsmål, et aftalt omfang og en aftalt periode. Testeren undersøger, hvad der kan opnås fra det givne udgangspunkt, og om svagheder kan kombineres til en større konsekvens. Resultatet er en rapport om de forhold, der blev afprøvet.

Testen kan finde svagheder, som ikke har noget nummer: fejl i opsætningen, forkerte rettigheder i ERP-systemet eller logikfejl i kundeportalen, hvor en kunde kan se en andens oplysninger. Den slags forhold er specifikke for netop jeres løsning og dukker derfor ikke op i en oversigt over kendte fejl.

Til gengæld dækker testen kun det, der var i scope, og kun forholdene på testtidspunktet. Dagen efter kan en ny svaghed blive kendt i en komponent, som webshoppen bruger. Det er sårbarhedsstyringens opgave at fange den.

Hvordan de to opgaver supplerer hinanden

Den løbende proces giver bredde og kontinuitet. Testen giver dybde og et blik udefra på, hvordan svaghederne hænger sammen. Kombineret giver de et bedre billede end hver for sig.

En penetrationstest kan også bruges til at efterprøve processen. Hvis testeren finder en kendt svaghed, der burde være opdaget og rettet for længe siden, siger det noget om sårbarhedsstyringen, ikke kun om det enkelte system. Det er værd at spørge, hvorfor processen ikke fangede den: manglede systemet i oversigten, blev fundet nedprioriteret, eller ventede rettelsen på en leverandør?

Tidspunktet for testen kan også vælges ud fra processen. En test lige efter en større opdateringsrunde siger noget andet end en test midt i en periode, hvor flere rettelser venter. Ingen af delene er forkert, men rapporten bør nævne, hvor i forløbet testen blev gennemført, så fundene kan forstås i den rette sammenhæng. Det gør det også lettere at sammenligne med en senere test af kundeportalen eller kontornettet.

Omvendt kan sårbarhedsstyringen gøre testen mere værdifuld. Når de kendte svagheder allerede er håndteret, kan testtiden bruges på de forhold, kun en manuel undersøgelse kan finde. → Automatisk eller manuel penetrationstest

Scanning er et værktøj i processen

Sårbarhedsscanning bliver ofte brugt som en del af sårbarhedsstyringen. Den giver en gentagelig liste over mulige svagheder, som derefter skal vurderes. Scanningen er dermed et af redskaberne i processen, men den er ikke hele processen, og den er ikke en penetrationstest.

En liste fra en scanning skal sorteres. Nogle resultater er falske, andre er reelle men uden betydning for jer, og nogle kræver handling med det samme. Den sortering kræver kendskab til systemerne og til virksomheden. Forskellen mellem scanning, sikkerhedstjek og test er gennemgået i → Sårbarhedsscanning, sikkerhedstjek eller penetrationstest?

Hvem gør hvad i jeres virksomhed?

Sårbarhedsstyring kræver en ejer. Det kan være IT-afdelingen, driftsleverandøren eller en fordeling mellem dem. Det vigtige er, at det er aftalt, hvem der holder oversigten over systemer, hvem der følger med i nye svagheder, og hvem der beslutter, hvad der rettes først.

Har I en driftsleverandør, så spørg konkret, hvad der er med i aftalen. Opdatering af servere er ikke det samme som at holde øje med svagheder i webshoppens tilføjelser eller i kundeportalens komponenter. Huller i ansvarsfordelingen er en af de ting, en penetrationstest kan gøre synlige.

En mindre virksomhed uden egen IT-afdeling kan godt have sårbarhedsstyring. Den kan være enkel: en liste over systemer, en fast aftale med leverandøren om opdateringer og faste tidspunkter i kalenderen, hvor en navngiven person ser listen igennem. Det afgørende er, at nogen faktisk gør det, og at det kan ses bagefter.

Rapporten fra testen bør føres ind i den samme proces. Fund skal have en ejer, en prioritet og en status som alle andre svagheder. Alvorligheden i rapporten kan bruges som udgangspunkt, men prioriteringen skal også tage højde for, hvad systemet betyder for jer. → CVSS-score

Det skal I lade være med

At kalde en årlig test for sårbarhedsstyring · En test på et tidspunkt dækker ikke de svagheder, der bliver kendt bagefter.
At regne scanning for en penetrationstest · En liste over mulige svagheder viser ikke, hvad de betyder i jeres løsning.
At antage, at driftsleverandøren dækker alt · Spørg, hvilke systemer og komponenter aftalen omfatter.
At holde testens fund uden for processen · Fund fra rapporten skal følges som alle andre svagheder.
At springe årsagen over · Når en test finder en gammel kendt fejl, skal processen også gennemgås.

Hvad kan og ikke kan konkluderes

En velfungerende sårbarhedsstyring kan vise, at virksomheden løbende kender og håndterer kendte svagheder i de systemer, der er med i oversigten. Den kan ikke vise, at løsningen er fri for opsætnings- og logikfejl.

En penetrationstest kan vise, hvad der kunne opnås i et afgrænset område på testtidspunktet. Den kan ikke vise, at virksomheden har en proces for de svagheder, der kommer bagefter. Ingen af delene er alene en dokumentation for, at krav i en standard er opfyldt. → Hvor ofte skal I teste?

Tjekliste til samspillet

☐ Er det aftalt, hvem der ejer sårbarhedsstyringen?
☐ Findes der en opdateret oversigt over de systemer, processen omfatter?
☐ Er det klart, hvilke dele driftsleverandøren dækker, og hvilke I selv dækker?
☐ Bliver resultater fra scanninger vurderet, før de prioriteres?
☐ Føres fund fra penetrationstesten ind i samme proces?
☐ Undersøges årsagen, når en test finder en kendt svaghed?
☐ Er det besluttet, hvilke områder en test skal gå i dybden med?

Kilder

ISO/IEC 27001: standarden for ledelsessystemer for informationssikkerhed, herunder kontrollen om håndtering af tekniske sårbarheder.
CVE: det fælles katalog over offentligt kendte sårbarheder.
NIST SP 800-115: forskellen mellem scanning og test og deres begrænsninger.

Senest gennemgået: oktober 2026.