Penetrationstest fra start til slut: beslutninger, leverancer og opfølgning

En penetrationstest kan være færdig hos testeren, mens virksomheden stadig mangler at beslutte, hvad der skal ske med resultatet. Et brugbart forløb bygger derfor på et fælles mål, tydelige leverancer og en plan for arbejdet efter rapporten.

Tænk på en virksomhed, der vil åbne en kundeportal. IT skal have løsningen undersøgt, projektlederen skal holde tidsplanen, og ledelsen skal tage stilling til de udestående forhold. De har brug for forskellige oplysninger fra samme opgave. Her gennemgås forløbet fra køberens side, så rapportens aflevering kan forbindes med den beslutning, virksomheden skal træffe.

Hvilken beslutning venter på resultatet?

Begynd med at skrive, hvad undersøgelsen skal bruges til. For kundeportalen kan det være en vurdering før åbning for kunder. For et eksisterende ERP-system kan det være at prioritere forbedringer. Det er forskellige beslutninger, selv om begge opgaver bestilles som en penetrationstest.

Angiv også, hvem der skal bruge svaret. En projektleder kan have brug for at kende væsentlige udeståender før en lancering. Driftsleverandøren skal kunne forstå de fund, der kræver rettelser. Ingen af delene løses alene ved at reservere en periode til test.

Skeln mellem det ønskede svar og et ønsket udfald. Bestillingen af kundeportalen bør ikke forudsætte en rapport uden fund. Den skal give viden om de aftalte forhold og forklare begrænsningerne. → Derfor får virksomheder lavet en penetrationstest

Bestillingen skal kunne læses ens

Oversæt formålet til en opgave, som både køber og tester forstår. For kundeportalen skal det blandt andet fremgå, om kundernes funktioner og medarbejdernes administration indgår. → Scope i en penetrationstest

Det næste valg er undersøgelsens udgangspunkt. Skal portalen vurderes uden en udleveret konto, med aftalte kundekonti eller med et bredere indblik i løsningen? Ordene i tilbuddet skal følges af en beskrivelse af den adgang og viden, som forudsættes. → Black box, grey box og white box

Bestillingen bør desuden angive leverancerne. En rapport, et møde om fundene og en senere kontrol af rettelser er forskellige dele. Hvis de ønskes, skal de kunne findes i aftalen. Ved flere tilbud er det indholdet i opgaven, der skal sammenlignes. → Sammenlign tilbud på penetrationstest

Kalenderforløb er mere end testarbejde

Projektets samlede tid omfatter også forberedelse, afklaringer, rapportering og virksomhedens behandling af fundene. En oplysning om selve testarbejdets varighed fortæller derfor ikke, hvornår kundeportalen er klar til en beslutning om åbning.

Lav en plan med milepæle for de leverancer, I skal bruge. Det kan være bekræftet testgrundlag, afsluttet undersøgelse, rapportgennemgang og virksomhedens stillingtagen. Skriv afhængighederne ind, så en manglende leverance ikke først bliver opdaget ved projektmødet før åbningen.

Et ERP-projekt kan eksempelvis være afhængigt af, at systemleverandøren har rettet væsentlige fund. Virksomheden bør ikke lægge denne opgave ind som en automatisk følge af rapportdatoen. Spørg, hvad der forudsættes for næste milepæl. Et bestemt antal testdage kan ikke bruges som generel garanti for hele forløbets længde.

Indlæg også plads til virksomhedens egen behandling. Rapporten kan være afleveret, uden at økonomiafdelingens systemejer har vurderet følgerne af et ERP-fund. Hvis den vurdering er nødvendig for projektets næste skridt, skal den have sin egen ansvarlige og frist. Ellers skjuler en overordnet slutdato arbejdet mellem aflevering og beslutning.

Fra bestilling til klar opgave

Inden undersøgelsen begynder, skal den aftalte løsning være til rådighed. Ved kundeportalen betyder det blandt andet, at de rigtige funktioner og brugerroller skal kunne indgå. En bestilt rolle, som ikke kan bruges, giver et udestående spørgsmål i stedet for det forventede svar.

Lad systemejeren bekræfte de forhold, som er vigtige for formålet. Hvis opgaven gælder et testmiljø, skal projektlederen kende de relevante forskelle fra den løsning, kunderne senere møder. → Penetrationstest i produktion eller testmiljø

Den praktiske vejledning om tilladelser, kontaktpersoner, stop og ændringer findes i → Før penetrationstesten. Brug den som grundlag for en samlet startafklaring. Forløbsplanen skal vise, at forberedelsen er gennemført, uden at kopiere alle spillereglerne ind i hvert projektdokument.

Hvad skal status under testen fortælle?

En status bør hjælpe virksomheden med at se, om de planlagte spørgsmål bliver belyst. Ved en webshop kan det være nyttigt at skelne mellem funktioner, der er undersøgt, og funktioner, der endnu afventer. Det er mere oplysende end en besked om, at arbejdet går fremad.

Afklar i bestillingen, hvilken status der ønskes. Det behøver ikke være et løbende referat af testerens arbejde. For projektlederen er væsentlige begrænsninger og forventet aflevering ofte de oplysninger, der skal bruges til at planlægge næste skridt.

Undgå at læse foreløbige meldinger som endelige konklusioner. En besked uden alvorlige fund indtil nu er ikke en samlet vurdering af kundeportalen. En nyttig status skelner mellem foreløbige observationer, afklarede forhold og spørgsmål, der stadig står åbne. Den endelige dokumentation skal bære konklusionen.

Rapporten skal føre til beslutninger

Ved afleveringen skal de aftalte spørgsmål findes frem igen. For kundeportalen skal det være muligt at se, hvilke funktioner der blev undersøgt, hvad der blev påvist, og hvilke væsentlige begrænsninger resultatet har. → Sådan læser I en pentestrapport

Brug gennemgangen til at få uklare fund forklaret. Systemejeren skal forstå følgerne for løsningen. Driftsleverandøren skal kunne vurdere arbejdet med rettelserne. Ledelsen skal kende de forhold, der kræver en beslutning om risiko eller tidsplan.

Adskil rapportens anbefaling fra virksomhedens beslutning. Hvis et fund i ERP-systemet kræver en ændring, bør det fremgå, hvem der tager stilling, og hvem der gennemfører arbejdet. Et møde, hvor alle har hørt rapporten, er ikke i sig selv en fordeling af opgaver. Afslut mødet med en fælles liste over de næste handlinger.

Gør det samtidig tydeligt, hvad modtagelsen af rapporten betyder. For kundeportalen kan den bekræfte, at en aftalt leverance er kommet, uden at virksomheden dermed har godkendt åbning eller accepteret alle fund. Dokumentér beslutningerne hver for sig, så projektets status ikke får en bredere betydning, end deltagerne havde tænkt.

Rettelser og afslutning er en selvstændig del

Efter rapporten kan et fund gå videre til rettelse, nærmere afklaring eller en begrundet beslutning om håndtering. For kundeportalen skal virksomhedens oversigt vise, hvad der er besluttet, og hvilket grundlag beslutningen bygger på.

Hvor der er behov for retest, skal efterprøvningen beskrives særskilt. Leverandørens besked om en rettelse og resultatet af en aftalt kontrol er forskellige oplysninger. → Retest efter penetrationstest

Denne opdeling mellem planlægning, undersøgelse og arbejdet bagefter indgår i NIST SP 800-115, afsnit 2.1 og kapitel 8. For en webshop bør afslutningen derfor omfatte både dokumentationen fra testen og status på virksomhedens egne opgaver. Senere testbehov vurderes særskilt. → Hvor ofte skal I teste?

Det skal I lade være med

At bruge rapportdatoen som beslutning om åbning. Kundeportalen kan stadig have forhold, som virksomheden skal behandle.
At reservere test uden tid til opfølgning. Driftsleverandørens rettelser af webshoppen kræver en plads i projektplanen.
At forveksle aktivitet med dækning. Arbejde på ERP-systemet fortæller ikke alene, hvilke roller der blev undersøgt.
At antage, at retest følger med. Kontrollér den aftalte leverance, før en senere kontrol indgår i planen.
At lade fund ende mellem parterne. Fordel virksomhedens opgaver, så systemejer og leverandør kender deres ansvar.

Hvis behovet primært er overblik over indstillinger frem for praktisk afprøvning, bør undersøgelsesformen vurderes tidligt. → Sårbarhedsscanning, sikkerhedstjek eller penetrationstest?

Hvad kan og ikke kan konkluderes

Et gennemført forløb kan give et fælles grundlag for beslutninger om de omfattede systemer. Det er ikke det samme som en erklæring om, at kundeportalen er sikker i enhver situation. Konklusionen afhænger af den undersøgelse, der faktisk blev gennemført.

En afsluttet test kan heller ikke dokumentere rettelser, som først blev gennemført bagefter. Hvis ERP-leverandøren har ændret løsningen, skal den nye oplysning holdes adskilt fra den oprindelige rapport. En eventuel efterprøvning har sit eget omfang og tidspunkt.

Ledelsens beslutning om at åbne webshoppen skal derfor bygge på mere end, at en rapport findes. Beslutningen bør tage højde for fund, rester, øvrige projektforhold og virksomhedens ansvar for driften. Testen bidrager med viden; den overtager ikke beslutningen.

Tjekliste til hele forløbet

☐ Beskriv den beslutning, undersøgelsen skal understøtte.
☐ Udpeg de systemer og brugerroller, der er nødvendige for svaret.
☐ Saml de ønskede leverancer og milepæle i bestillingen.
☐ Bekræft, at forberedelsen passer til den aftalte opgave.
☐ Skeln mellem foreløbig status og rapportens konklusioner.
☐ Sæt ansvarlige på virksomhedens behandling af fundene.
☐ Afklar behovet for efterprøvning og dens dokumentation.
☐ Registrér de spørgsmål, som stadig mangler svar ved afslutningen.

Kilder

NIST SP 800-115, afsnit 2.1 samt kapitel 6 og 8: planlægning, gennemførelse og opfølgning.
NCSC: Penetration testing, afsnittet om en model for testopgaven og opfølgning på rapporten.

Senest gennemgået: oktober 2026.