Ændringer i opgaven undervejs: hvem godkender, og hvad betyder det for rapporten?

En penetrationstest følger sjældent planen helt til punkt og prikke. Et system viser sig at hænge sammen med et andet, en tilladelse udebliver, eller en testkonto virker ikke. Ændringer kan være fornuftige, men de skal godkendes af den rette person, skrives ned og kunne genfindes i rapporten, ellers kan ingen bagefter se, hvad testen faktisk svarer på.

Kort sagt: Testeren må ikke udvide opgaven på egen hånd, og virksomheden bør ikke ændre den mundtligt. En ændring kræver en skriftlig godkendelse fra en person med mandat, en vurdering af betydningen for tid og pris og en notering, der følger med til rapporten. Det gælder både, når noget kommer til, og når noget falder bort.

Hvorfor opgaven ændrer sig

Ændringer har typisk en af få årsager. Nogle kommer fra virksomheden, andre fra testen selv.

Ny viden om systemerne · testen viser, at kundeportalen bruger en tjeneste, som ingen havde nævnt.
Manglende forudsætninger · en godkendelse fra hostingfirmaet kommer ikke, eller testkontiene til ERP-systemet virker ikke.
Driftshensyn · et system bliver ustabilt og må holdes ude af resten af testen.
Nye ønsker · en leder vil have gæstenettet med, når testeren alligevel er i gang.
Ændringer i systemet · en ny version af webshoppen sættes i drift midt i testperioden.

De første fire ændrer opgaven direkte. Den sidste ændrer grundlaget og kan betyde, at dele af testen må gentages eller noteres med forbehold. → At ændre systemet under testen

Når testeren støder på noget uden for scope

Testeren kan opdage systemer, som ikke står i scope, men som ser ud til at høre til virksomheden. Et glemt testmiljø på internettet er et typisk eksempel. Testeren må ikke teste systemet uden godkendelse. Til gengæld bør observationen meldes, så virksomheden kan tage stilling. → Glemte testmiljøer på internettet

Virksomheden kan da vælge at lade systemet indgå, efter at ejerskab og tilladelse er afklaret, eller at notere det som en observation til senere. Begge valg er legitime, så længe de træffes bevidst. Det, der ikke går, er at lade testeren afgøre spørgsmålet alene.

Hvem må sige ja?

Udpeg på forhånd, hvem der kan godkende ændringer. Det er normalt bestilleren eller en person med tilsvarende mandat, ikke den systemejer, der tilfældigvis er i kontakt med testeren. Hvis en ændring berører et system hos en leverandør, kan leverandørens godkendelse også være nødvendig. → Leverandørens godkendelse mangler

Afgrænsningen af opgaven skal stadig hænge sammen. Udvides testen fra webshoppen til ERP-systemet, er det ikke kun et spørgsmål om tid, men om tilladelse, kontaktpersoner og testkonti. Den grundlæggende tankegang bag scope er beskrevet i → Scope i en penetrationstest

Skriv ændringen ned

En ændringslog behøver ikke være kompliceret. Den skal blot vise, hvad der blev ændret, hvorfor, hvem der godkendte det, og hvornår. En mail med en bekræftelse fra begge parter kan være nok, hvis den gemmes sammen med aftalen. Det vigtige er, at alle ændringer findes samlet ét sted og ikke er spredt i telefonsamtaler og chatbeskeder.

Beskriv også konsekvensen. En udvidelse kræver typisk mere tid. En indskrænkning kan frigøre tid, der enten bruges på noget andet eller trækkes fra prisen. Hvordan ændringer afregnes, bør fremgå af kontrakten, så det ikke skal forhandles midt i testen. Omfang og pris hænger sammen, og hvad der påvirker dem, står i → Hvad påvirker omfanget og prisen?

Notér desuden, hvis ændringen påvirker tidsplanen for aflevering. En rapport, der skulle bruges til en beslutning om at åbne kundeportalen, kan blive forsinket af en udvidelse, og det skal den, der venter på rapporten, vide.

Når opgaven bliver mindre

Indskrænkninger får mindre opmærksomhed end udvidelser, men de kan have større betydning for, hvad rapporten kan bruges til. Hvis testen af webshoppen skulle dokumentere over for en kunde, at betalingsflowet var undersøgt, og netop den del må udgå, er formålet med testen ændret.

Spørg derfor ved hver indskrænkning, om testen stadig svarer på det spørgsmål, den blev bestilt til. Er svaret nej, er der flere muligheder. Den udeladte del kan testes senere, når forudsætningen er på plads. Formålet kan formuleres om, så det passer til det, der faktisk kan testes. Eller testen kan udskydes samlet, hvis den ellers vil give et billede, der kan misforstås.

Det er virksomheden, der skal bruge resultatet, og derfor hører valget hjemme hos bestilleren. Del gerne begrundelsen med dem, der venter på rapporten, så de ikke bliver overrasket ved afleveringen.

Betydningen for rapporten

Rapporten bør vise både det oprindelige scope og det endelige. Dele, der udgik, skal stå som ikke testet med en kort begrundelse. Dele, der kom til, skal stå med det tidspunkt, de blev tilføjet, og den forudsætning, de blev testet under.

Det er vigtigt, fordi rapporten ofte læses af andre end dem, der var med undervejs. En kunde eller en revisor, der får rapporten om webshoppen, skal kunne se, at betalingsdelen blev holdt ude på grund af en manglende godkendelse. Ellers kan rapporten blive læst som et bredere svar, end den kan bære. → Sådan læser I en pentestrapport

En ændring kan også betyde, at dele blev testet med mindre tid end planlagt. Det bør fremgå som en begrænsning, så læseren ved, hvor dybt den pågældende del er undersøgt. Det samme gælder dele, der blev testet før og efter en ny version af systemet blev sat i drift. Rapporten bør sige, hvilken version et resultat gælder, så systemejeren ikke retter noget, der allerede er ændret, eller overser noget, der er kommet til.

Det skal I lade være med

At udvide mundtligt · En ændring uden skriftlig godkendelse er ikke en del af opgaven.
At lade testeren afgøre ejerskab · Systemer uden for scope kræver virksomhedens afklaring.
At lade enhver systemejer godkende · Udpeg, hvem der har mandat.
At glemme leverandøren · En ændring kan kræve ny godkendelse fra hosting eller drift.
At skjule det, der udgik · Rapporten skal vise de dele, der ikke blev testet.
At ændre uden at se på tidsplanen · En udvidelse kan forsinke den beslutning, rapporten skal støtte.

Hvad kan og ikke kan konkluderes

En veldokumenteret ændring viser, at opgaven blev tilpasset bevidst og med godkendelse. Den kan ikke gøre en indskrænket test bredere, og den kan ikke give en tilføjet del samme dybde som en del, der var planlagt fra start, hvis tiden ikke rakte til det. Rapportens konklusioner gælder det endelige scope, ikke det oprindelige ønske.