Penetrationstesten er et øjebliksbillede: hvad tidspunktet betyder

En pentestrapport beskriver systemerne, som de så ud i de dage, testen foregik, og ikke som de ser ud, når rapporten læses. Hvor meget resultatet stadig siger, afhænger af, hvad der er sket siden: ændringer i jeres egne systemer, ny viden om sårbarheder og ændringer i måden, systemerne bruges på.

Der findes derfor ikke en fast holdbarhedsdato for en penetrationstest. Det, der kan afgøres, er, om de forudsætninger, rapporten bygger på, stadig er til stede. Jo bedre I kender ændringerne siden testdatoen, jo bedre kan I vurdere, hvad rapporten fortsat kan bruges til.

Testperioden er rapportens tidsstempel

Hver konklusion i rapporten gælder en bestemt tilstand. Den tilstand er bestemt af den kode, den opsætning, de brugere og de forbindelser, der fandtes, da testeren arbejdede. Derfor bør rapporten angive testperioden præcist og gerne versionen af de vigtigste systemer.

Skeln mellem tre datoer: hvornår testen blev udført, hvornår rapporten blev afleveret, og hvornår eventuelle rettelser blev efterprøvet. Ved kundeportalen kan der gå tid mellem testens sidste dag og den endelige rapport. En læser, der kun ser rapportens dato, kan tro, at billedet er nyere, end det er.

Hvis I bruger rapporten over for andre, er testperioden den oplysning, modtageren har mest brug for. Den gør det muligt at sammenholde rapporten med de ændringer, der er sket siden. → Rapportens alder

Tre slags ændringer efter testdatoen

Den første slags er jeres egne ændringer. Nye funktioner i webshoppen, et nyt modul i ERP-systemet, en ændret opsætning af fjernadgangen eller en ny integration til en partner kan alle ændre det, testen undersøgte. Nogle ændringer er små og uden betydning for sikkerheden. Andre ændrer grundlaget for konklusionen. → Efter en større opdatering af systemet

Den anden slags er ny viden om sårbarheder. Der offentliggøres løbende nye sårbarheder i software, som også kan findes i jeres systemer. CVE-programmet giver kendte sårbarheder et fælles nummer, så de kan genkendes på tværs af leverandører og værktøjer. En komponent, der var uden kendte fejl på testdagen, kan have fået en offentligt kendt sårbarhed kort efter. → CVE forklaret

Den tredje slags er ændringer i brugen. En kundeportal, der var åben for nogle få pilotkunder under testen, kan senere være åben for alle. Nye leverandører kan have fået fjernadgang, og medarbejdere kan arbejde hjemmefra på en ny måde. Selv uden ændringer i koden kan eksponeringen være en anden.

Ikke alle konklusioner ældes lige hurtigt

Nogle fund handler om en bestemt version af en komponent. De ældes, så snart komponenten opdateres eller en ny sårbarhed bliver kendt. Andre fund handler om strukturelle forhold, som hvordan roller er adskilt i ERP-systemet, eller hvordan gæstenettet er skilt fra kontornettet. De ændrer sig først, når nogen bevidst ændrer arkitekturen.

Det samme gælder de mønstre, rapporten afslører. Hvis flere fund skyldes, at ændringer sættes i drift uden kontrol, er det et forhold i organisationen, som ikke forsvinder med tiden. Tværtimod kan det betyde, at nye fejl opstår i samme takt, som de gamle rettes.

Brug den skelnen, når I vurderer en ældre rapport. Spørg for hvert vigtigt fund, om det handler om en version, en opsætning eller en måde at arbejde på. Svaret fortæller, om fundet sandsynligvis stadig er aktuelt, og hvem der skal tage stilling til det. Et versionsfund hører hos driften, mens et mønster i arbejdsgangene ofte kræver en beslutning hos ledelsen.

Hold styr på ændringerne siden testen

Den enkleste måde at holde øjebliksbilledet brugbart på er at føre en oversigt over væsentlige ændringer efter testdatoen. Oversigten behøver ikke være lang. Den skal vise, hvilke systemer der er ændret, hvornår, og om ændringen berører det, testen undersøgte.

Et praktisk greb er at knytte oversigten til rapportens scope. Står webshoppen, fjernadgangen og gæstenettet i scope, så skriv ændringerne under de samme overskrifter. Så kan en læser hurtigt se, hvilke dele af rapporten der stadig beskriver virkeligheden, og hvilke der er overhalet. Ændringer i systemer uden for scope hører også med, hvis de kan påvirke de testede dele, for eksempel en ny forbindelse fra ERP-systemet til kundeportalen.

Lad driftsleverandøren og systemejerne bidrage til oversigten. De kender ændringerne bedst, og det gør det lettere at vurdere, hvornår en ny test eller en målrettet kontrol er nødvendig. Den løbende håndtering af kendte sårbarheder er en anden opgave end testen, men de to supplerer hinanden. → Sårbarhedsstyring og penetrationstest

En retest ændrer ikke på øjebliksbilledet for hele løsningen. Den giver et nyere billede af de konkrete fund, den efterprøvede, og intet andet. → Retest efter penetrationstest

Når nogen spørger, om testen stadig gælder

En kunde, en revisor eller bestyrelsen kan spørge, om sidste års test stadig er gyldig. Et ærligt svar består af tre dele: hvornår testen blev udført, hvilke væsentlige ændringer der er sket siden, og hvad der er gjort ved fundene. Et ja eller nej uden de oplysninger siger for lidt.

Hvis modtageren har et bestemt krav til alder eller interval, gælder det krav. PCI DSS krav 11.4 nævner for eksempel både et fast interval og test efter væsentlige ændringer for de omfattede miljøer. Uden et sådant krav må I selv vurdere, hvornår ændringerne er så store, at et nyt billede er nødvendigt. → Hvor ofte skal I teste?

Det skal I lade være med

At bruge rapportens dato som testdato · Testperioden er den dato, konklusionerne gælder.
At kalde en rapport gyldig uden at kende ændringerne · Gyldighed er et spørgsmål om forudsætninger, ikke kun om tid.
At overse ændringer i brugen · Flere brugere eller nye adgangsveje kan ændre eksponeringen uden ny kode.
At lade en retest stå for en ny test · Den dækker kun de efterprøvede fund.
At glemme ny viden om sårbarheder · Komponenter uden kendte fejl på testdagen kan have fået dem senere.

Hvad kan og ikke kan konkluderes

En penetrationstest kan dokumentere, hvad der blev fundet i de undersøgte systemer i testperioden. Sammen med en oversigt over ændringer kan den give et rimeligt grundlag for at vurdere, hvor meget af billedet der stadig holder.

Den kan ikke sige noget om tilstanden efter testperioden, og den kan ikke forudsige, hvilke sårbarheder der bliver kendt senere. Den vurdering må bygge på jeres egen viden om ændringer og løbende opfølgning.

Tjekliste til en rapport, der skal bruges senere

☐ Står testperioden og versionen af de vigtigste systemer i rapporten?
☐ Er rapportdato, testdato og dato for retest holdt adskilt?
☐ Føres der en oversigt over væsentlige ændringer siden testen?
☐ Er ændringer i brugere, adgangsveje og leverandører med i oversigten?
☐ Er det vurderet, hvilke fund der handler om versioner, opsætning eller arbejdsgange?
☐ Kendes modtagerens eventuelle krav til alder eller interval?

Kilder

CVE: fælles katalog og nummerering af offentligt kendte sårbarheder.
PCI DSS krav 11, gengivet af Microsoft Learn: krav 11.4 om penetrationstest med interval og efter væsentlige ændringer.

Senest gennemgået: oktober 2026.