Når et system bliver opdateret, omkonfigureret eller rettet midt i en penetrationstest, beskriver rapporten en tilstand, som ikke længere findes, og nogle fund kan hverken genskabes eller afvises. Hvor meget ændringer betyder for resultatet, afhænger af, om de er planlagt, aftalt med testeren og skrevet ned, så rapporten kan læses med kendskab til dem.
Det handler her om ændringer i selve systemet: en ny version af webshoppen, en ændret regel i firewallen, en opdatering af ERP-systemet eller en hurtig rettelse, efter at nogen har hørt om et fund. Ændringer i selve opgaven, som når scope udvides eller indsnævres, er en anden sag. → Ændringer i opgaven undervejs
Testen undersøger et mål i bevægelse
En penetrationstest forudsætter, at systemet er nogenlunde stabilt i testperioden. Testeren bygger sit arbejde op trin for trin. En observation fra mandag kan være udgangspunktet for en undersøgelse onsdag. Hvis systemet er ændret imellem, kan sammenhængen forsvinde.
Det betyder ikke, at alt skal stå stille. Driften skal fortsætte, og sikkerhedsopdateringer kan ikke altid vente. Men ændringer i testperioden bør ske med åbne øjne, så både testeren og virksomheden ved, hvad der er ændret, og hvornår.
Emnet hører hjemme på opstartsmødet. Her kan virksomheden fortælle, hvilke udgivelser og opdateringer der er planlagt, og testeren kan sige, hvilke ændringer der vil gøre arbejdet svært. Når begge sider kender planen, kan rækkefølgen i testen tilpasses, så de dele, der skal ændres, bliver undersøgt før eller efter ændringen og ikke midt i den.
Ændringer, der kan ske i en testperiode
Nogle ændringer er planlagt længe i forvejen, andre opstår undervejs.
- Ny version · en planlagt udgivelse af kundeportalen sættes i drift midt i testen.
- Opdateringer · driftsleverandøren installerer sikkerhedsopdateringer efter sin faste plan.
- Ændret opsætning · en regel i firewallen eller en rettighed i ERP-systemet bliver justeret.
- Hurtig rettelse · en udvikler retter en fejl, efter at testeren har nævnt den.
- Ændringer hos andre · en leverandør af en integration ændrer noget, virksomheden ikke selv styrer.
Den sidste type er sværest at forudse. Den viser, hvorfor det er nyttigt at spørge leverandørerne om deres planer for testperioden. Et hostingfirma kan have planlagt vedligeholdelse, og en betalingsudbyder kan skifte en komponent, uden at virksomheden hører om det, medmindre den spørger. Spørgsmålet koster ikke meget og kan spare en del forvirring, når rapporten skal læses.
Hvad det gør ved resultatet
Den første følge er, at fund kan blive umulige at genskabe. Testeren har set et problem, men når det skal dokumenteres, er systemet ændret. Rapporten kan så kun beskrive, hvad der blev observeret, ikke vise det. Det svækker grundlaget for både rettelse og prioritering.
Den anden følge er, at dækningen bliver uklar. Hvis en ny version kom i drift halvvejs, er det uklart, hvilke dele af den testen nåede at undersøge. Rapporten kan komme til at blande resultater fra to forskellige udgaver uden at sige det.
Den tredje følge er, at fund kan blive skjult. En hurtig rettelse af én fejl kan gøre det umuligt at undersøge, hvad fejlen kunne føre videre til. Det fund, testeren havde fat i, forsvinder, men de bagvedliggende årsager kan stadig være der. → Penetrationstesten er et øjebliksbillede
En fjerde følge viser sig først ved næste test. Hvis det er uklart, hvilken udgave den forrige test gjaldt, bliver det svært at sammenligne resultaterne og se, om et fund er nyt, rettet eller blot ikke blev undersøgt sidst.
Når en rettelse undervejs er det rigtige
Der er situationer, hvor en ændring midt i testen er nødvendig. Hvis testeren finder et alvorligt fund, der kan udnyttes af andre, kan det være forkert at vente til testen er slut. Så skal fundet rettes, også selv om det påvirker resten af testen. → Kritisk fund midt i testen
Det afgørende er, at beslutningen bliver truffet bevidst og skrevet ned. Testeren skal vide, hvad der er rettet, og hvornår, så rapporten kan beskrive fundet, rettelsen og betydningen for den øvrige test. Rettelsen bør senere efterprøves som en del af opfølgningen og ikke regnes for dokumenteret, blot fordi den er lavet. → Retest efter penetrationstest
Ændringsstop eller ændringslog
Der er to måder at håndtere ændringer på. Den ene er et ændringsstop for de systemer, der testes, i testperioden. Det kræver, at driftsleverandør, udviklere og systemejere kender perioden og accepterer, at planlagte udgivelser flyttes. Testvinduet bør vælges, så det passer med udgivelsesplanen. → Test i arbejdstiden eller uden for?
Den anden er en fælles log over ændringer, som testeren har adgang til. Hver ændring noteres med tidspunkt, system og en kort beskrivelse. For webshoppen kan det være en linje om, at betalingsmodulet blev opdateret onsdag eftermiddag. Mere kræver det ikke, så længe testeren kan se det i tide. Det gør det muligt at forklare, hvorfor et fund ikke kunne genskabes, og hvilke resultater der gælder hvilken udgave.
De to kan kombineres: ændringsstop for de vigtigste dele og en log for alt det, der alligevel må ændres. Uanset valget skal driftsleverandøren være med i aftalen. → Driftsleverandøren og testen
Det skal I lade være med
- At sætte en ny version i drift midt i testen uden at sige det · testeren kan ikke vide, hvilken udgave der undersøges.
- At rette i stilhed, når et fund bliver nævnt · rettelsen skal noteres, så rapporten kan forklare den.
- At glemme driftsleverandørens faste opdateringer · spørg til planen for testperioden.
- At regne en rettelse undervejs for efterprøvet · den skal kontrolleres som alle andre.
- At lade et kritisk fund vente af hensyn til testen · alvorlige forhold rettes, og forløbet beskrives.
- At lade ændringer hos integrationspartnere komme bag på jer · spørg dem også.
Hvad kan og ikke kan konkluderes
En rapport fra en test, hvor ændringer er noteret, kan knytte hvert resultat til den udgave og det tidspunkt, det gælder. Den kan forklare, hvorfor et fund ikke kunne dokumenteres fuldt ud, og hvad en rettelse undervejs betød.
En rapport fra en test, hvor systemet ændrede sig uden at det blev noteret, kan ikke sige med sikkerhed, hvilken tilstand konklusionerne gælder. Et fund, der ikke kunne genskabes, er ikke det samme som et fund, der ikke findes. Og fravær af fund i en del, der blev ændret undervejs, siger kun lidt.
Tjekliste til testperioden
- ☐ Er udgivelser og opdateringer i testperioden kendt?
- ☐ Er der aftalt ændringsstop for de vigtigste systemer?
- ☐ Findes der en fælles log over ændringer, som testeren kan se?
- ☐ Er driftsleverandøren og integrationspartnere orienteret?
- ☐ Er det aftalt, hvordan rettelser af kritiske fund håndteres undervejs?
- ☐ Bliver rettelser undervejs noteret og senere efterprøvet?
- ☐ Kan rapporten knytte resultaterne til den rette udgave?
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler om penetrationstest
Læs også: Testvinduet · Spørgsmål og svar
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT
