Penetrationtest

Sårbarhedsscanning, penetrationstest eller red teaming: hvad skal I vælge?

Sårbarhedsscanning, penetrationstest eller red teaming: hvad skal I vælge?

Når ledelsen beder om “en sikkerhedstest”, kan svaret være tre meget forskellige opgaver, og det er ikke ligegyldigt, hvilken der bestilles. Valget afhænger af to ting: hvilket spørgsmål I vil have besvaret, og hvad jeres organisation allerede har på plads. Kort sagt giver sårbarhedsscanning et bredt og hyppigt overblik over kendte svagheder, en penetrationstest viser, om svaghederne i et afgrænset område kan udnyttes, og red teaming viser, om I opdager og håndterer et målrettet angreb. De fleste virksomheder har brug for de to første, før den tredje giver mening.

Siden om undersøgelsesformerne gennemgår flere varianter, bl.a. sikkerhedstjek og teknisk gennemgang. → Sårbarhedsscanning, sikkerhedstjek eller penetrationstest? Her er fokus på valget mellem de tre, og på rækkefølgen.

Tre spørgsmål, tre opgaver

Det hjælper at formulere spørgsmålet, før opgaven får et navn:

  1. Har vi kendte svagheder, vi ikke har opdaget? Det er scanningens spørgsmål. Svaret er en liste over mulige fund, der skal vurderes og følges op.
  2. Kan en angriber komme videre i netop dette system? Det er penetrationstestens spørgsmål. Svaret er påviste svagheder og deres betydning i en bestemt sammenhæng.
  3. Opdager og stopper vi en modstander, der går målrettet efter os? Det er red teamings spørgsmål. Svaret handler om organisationens evne til at se og reagere, ikke kun om tekniske fejl.

Spørgsmålene kan godt stilles på samme tid, men de besvares ikke af den samme opgave. En scanning af kundeportalen siger ikke, om en kunde kan se en anden kundes data. En penetrationstest siger ikke, om driftsleverandørens overvågning ville have reageret.

Sårbarhedsscanning: bredde og gentagelse

En scanning sammenligner systemer med kendte svagheder og fejlopsætninger. Den kan køre ofte og dække mange systemer, og den er god til at fange det, der dukker op mellem to test, fx en manglende opdatering på en server.

Til gengæld giver scanningen observationer, ikke vurderinger. Nogle er falske positiver, og logiske fejl i en webshop eller rettigheder i et ERP-system falder typisk uden for, hvad en scanning kan se. Scanning hører hjemme i den løbende sårbarhedsstyring. → Sårbarhedsstyring og penetrationstest

Afklar også, hvem der kører scanningen, og hvem der læser resultatet. Ofte er det driftsleverandøren eller hostingfirmaet, og så skal aftalen sige, hvilke systemer der er med, hvor ofte der scannes, og hvem der beslutter, hvad der rettes først. En scanning, som ingen følger op på, giver kun en længere liste.

Penetrationstest: dybde i et afgrænset område

En penetrationstest er en aftalt afprøvning af bestemte systemer inden for et bestemt tidsrum. Testeren prøver at bruge svaghederne, sætter dem i sammenhæng og vurderer, hvad de betyder for netop jeres virksomhed. Den kan inddrage roller, forretningslogik og forbindelser mellem systemer.

Resultatet er en rapport, der kan bruges til at prioritere rettelser, og som ofte kan vises til kunder eller revisorer. Organisationen ved som regel, at testen foregår, og den måler derfor ikke, om forsvaret opdager den. → Typer af penetrationstest

Red teaming: organisationens reaktion

Red teaming er en angrebssimulering mod et mål, fx adgang til økonomisystemet eller kundedata, ofte over længere tid og med få indviede. Den kan kombinere teknik, social engineering og fysisk adgang. Formålet er at afprøve, om mennesker, processer og overvågning virker sammen, når det gælder. Grænsen til penetrationstesten er beskrevet nærmere i → Red teaming eller penetrationstest, og red teaming som disciplin har sit eget opslagsværk på red-teaming.dk.

Fordi øvelsen foregår i det skjulte, kræver den mere planlægning end en almindelig test: en lille gruppe, der kender til den og kan gribe ind, klare regler for, hvad holdet må, og tilladelser fra de leverandører, hvis systemer indgår. → Rules of engagement

Hvad hver opgave kræver af jer

Valget handler også om modenhed. Hver opgave forudsætter noget hos jer, før den giver værdi:

  • Scanning · et overblik over, hvilke systemer der er jeres, og en fast proces for at vurdere og rette fundene.
  • Penetrationstest · et afgrænset scope, en ansvarlig for rettelserne og tid til at følge op, når rapporten kommer.
  • Red teaming · en overvågning, nogen der reagerer på den, en beredskabsplan, og en ledelse der vil have et ærligt svar, også hvis det er ubehageligt.

En virksomhed uden overvågning får ikke meget ud af at måle, om overvågningen reagerer. Den får mere ud af at rette de svagheder, en penetrationstest peger på, og at få styr på scanning og opdateringer. → Assume breach

Et tænkt forløb over et år

En mellemstor virksomhed med en kundeportal, et ERP-system og en ekstern driftsleverandør kan bygge de tre lag op sådan her:

  • Løbende · scanning af de systemer, der vender ud mod internettet, med fast opfølgning hos driftsleverandøren.
  • Én gang om året eller ved større ændringer · penetrationstest af kundeportalen med flere brugerroller og af adskillelsen mellem kontornettet og gæstenettet.
  • Senere, når overvågningen er etableret · en afgrænset red team-øvelse med ét scenarie, fx adgang til kundedata.

Eksemplet er ikke en norm. Rækkefølgen og hyppigheden afhænger af risiko, krav fra kunder og ændringer i systemerne. Stiller en kunde krav om en pentestrapport, er det penetrationstesten, der skal leveres, uanset hvor moden overvågningen er. Og kommer der en større ændring i ERP-systemet, kan en ny test være relevant før den planlagte.

Det skal I lade være med

  • At kalde en scanning en penetrationstest · de to rapporter siger noget forskelligt, og forskellen opdages ofte af kunden.
  • At bestille red teaming for at få en liste over svagheder · det spørgsmål besvares mere direkte af scanning og penetrationstest.
  • At springe penetrationstesten over, fordi der scannes · logik og rettigheder ligger uden for scanningens rækkevidde.
  • At vælge efter, hvad konkurrenten har gjort · det relevante er jeres spørgsmål og jeres forudsætninger.
  • At se valget som en engangsbeslutning · behovet ændrer sig, når organisationen modnes.

Hvad kan og ikke kan konkluderes

De tre opgaver supplerer hinanden. Ingen af dem viser, at en virksomhed er sikker. En ren scanning betyder ikke fravær af svagheder, en penetrationstest gælder et afgrænset område på et bestemt tidspunkt, og en red team-øvelse afprøver ét eller få scenarier. Det, man kan konkludere, afhænger af det spørgsmål, opgaven var bygget til.

Tjekliste før I vælger

  • ☐ Er spørgsmålet formuleret, før opgaven har fået et navn?
  • ☐ Ved I, hvilke systemer der er jeres, og hvem der ejer dem?
  • ☐ Er der en fast proces for at følge op på fund fra scanning?
  • ☐ Er der en ansvarlig for rettelser efter en penetrationstest?
  • ☐ Findes der overvågning og beredskab, som en red team-øvelse kan måle?
  • ☐ Har ledelsen besluttet, hvordan resultatet skal bruges?

Kilder

  • NCSC: Penetration testing: forskellen på sårbarhedsscanning og penetrationstest og råd om, hvornår en test giver værdi.
  • NIST SP 800-115: teknikker til sikkerhedsafprøvning, fra gennemgang og scanning til målrettede test.

Senest gennemgået: november 2026.

Næste skridt

Del af: Artikler om penetrationstest

Læs også: Sårbarhedsstyring og penetrationstest · Penetrationstest eller IT-sikkerhedsaudit

→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest 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 I have testet noget?

Fortæl kort, hvad I vil have testet, og hvornår I skal bruge resultatet. Så vender jeg tilbage. Testen og rådgivningen er uvildige og uafhængige, og Nielco IT har ikke indgået forhandleraftaler med leverandører.

Tak for din henvendelse. Jeg vender tilbage hurtigst muligt.