En anbefaling i en pentestrapport siger, hvad der bør ændres, men sjældent hvem der skal gøre det, hvad det kræver, og hvornår arbejdet er færdigt. Oversættelsen til en opgave hviler på tre spørgsmål: hvilket problem rådet skal løse, hvilken løsning der passer til jeres systemer, og hvordan I bagefter kan se, at opgaven er udført.
Anbefalingen er altså et udgangspunkt og ikke en arbejdsordre. Den er skrevet af en person, der kender fundet, men ikke jeres drift, jeres aftaler eller jeres planer for systemerne. Den viden skal virksomheden selv lægge til.
Hvad en anbefaling er, og hvad den ikke er
Testeren beskriver som regel en eller flere måder at fjerne eller mindske et fund på. Nogle anbefalinger er konkrete og peger på en bestemt indstilling eller funktion. Andre er brede og handler om et princip, fx at adgang skal begrænses til dem, der har brug for den.
Begge former har samme begrænsning. Testeren har set systemet udefra eller fra de roller, der indgik i testen. Hvilke andre systemer der afhænger af en ændring, og hvad den betyder for driften, ligger uden for det, rapporten kan vurdere. Et råd om at lukke en funktion i kundeportalen kan være rigtigt ud fra fundet og samtidig ramme en integration, som testeren aldrig så.
Læs derfor anbefalingen sammen med beskrivelsen af fundet og ikke for sig. Det er fundet, der fortæller, hvad der står på spil. → Sådan læser I en pentestrapport
Find problemet bag rådet
Før en anbefaling kan blive til en opgave, skal problemet kunne siges med almindelige ord. Hvad kan en uvedkommende gøre i dag, som ikke burde være muligt? Hvilke data eller funktioner er berørt? Når det er besvaret, bliver det lettere at vurdere, om den foreslåede løsning er den eneste vej.
Et fund i webshoppen kan fx handle om, at en kunde kan se oplysninger, der tilhører en anden kunde. Anbefalingen beskriver måske en bestemt kontrol i koden. Opgaven for virksomheden er bredere: adskillelsen mellem kunder skal virke i alle de funktioner, hvor den betyder noget, og leverandøren skal kunne vise, hvor ændringen er lavet.
Spørg testeren, hvis formuleringen er uklar. En kort afklaring på afslutningsmødet kan spare tid senere, når opgaven ligger hos en leverandør, der ikke var med i forløbet.
Én anbefaling kan blive til flere opgaver
Et råd kan rumme både en hurtig afhjælpning og en mere grundlæggende ændring. Det første kan være at slå en funktion fra eller begrænse, hvem der kan nå den. Det næste kan være at ændre selve løsningen, så problemet ikke opstår igen.
Del dem op i hver sin opgave. Den hurtige del kan have en kort frist og en klar ejer i driften. Den grundlæggende del kan kræve et udviklingsforløb hos leverandøren og en plads i den næste udgivelse. Står de som én opgave, risikerer I, at den midlertidige løsning bliver betragtet som det hele.
Nogle anbefalinger går på tværs af flere fund. Et råd om bedre styring af brugerkonti kan ramme både ERP-systemet, kontornettet og fjernadgangen. Saml den slags i en fælles opgave med én ansvarlig, og henvis til de fund, den dækker. → Fra rapport til handlingsplan
Når den anbefalede løsning ikke passer
Det er ikke et brud med rapporten at vælge en anden løsning end den foreslåede. Systemet understøtter den måske ikke, leverandøren kan have en bedre måde, eller funktionen bruges slet ikke og kan fjernes. Det afgørende er, at det oprindelige problem bliver løst.
Skriv valget ned. Notér, hvad anbefalingen var, hvad I valgte i stedet, og hvorfor. Så kan en senere tester eller revisor forstå sammenhængen, og en kontrol kan rettes mod den løsning, der faktisk findes, frem for den, der blev foreslået. → Retest efter penetrationstest
Hvis ingen løsning er mulig lige nu, er det en anden beslutning. Den hører hjemme i en risikoaccept med begrundelse og en dato for ny vurdering, ikke i en opgave, der står åben uden fremdrift. → Risikoaccept: når et fund ikke rettes
Skriv opgaven, så den kan afsluttes
En opgave, der kun gentager rapportens tekst, er svær at følge op på. Beskriv i stedet, hvad der skal være anderledes, når opgaven er løst, og hvordan I kan se det. Det kan være, at en bestemt funktion kun kan bruges af én rolle, eller at et system ikke længere kan nås fra gæstenettet.
Hver opgave bør have en ejer med mandat til at få den løst. Det er ikke altid den person, der udfører arbejdet. Ved fund hos hostingfirmaet eller driftsleverandøren kan ejeren være den, der styrer aftalen, mens leverandøren laver ændringen. → Hvem retter? Ansvar mellem virksomhed og leverandør
Sæt også en rækkefølge. Ikke alle anbefalinger er lige vigtige, og rapportens alvorlighed er kun ét af hensynene. Systemets betydning for jer og indsatsen bag rettelsen spiller også ind. → Prioritering af rettelser efter testen
Giv til sidst hver opgave en frist, som passer til jeres egen vurdering af risikoen og til leverandørens muligheder. Rapporten kan pege på, hvad der haster, men den kender ikke jeres udgivelsesplaner eller de aftaler, der styrer leverandørens tid. En frist, der er sat uden leverandøren, holder ikke nødvendigvis. → Frister for rettelser
Det skal I lade være med
- At kopiere anbefalingen direkte ind som opgave · teksten er skrevet til en tekniker og mangler ejer, omfang og slutpunkt.
- At lade den midlertidige løsning stå som den endelige · del rådet op, så den grundlæggende ændring ikke forsvinder.
- At afvise en anbefaling uden at løse problemet · en anden løsning er i orden, ingen løsning kræver en beslutning.
- At sende rapporten til leverandøren uden en opgave · leverandøren skal vide, hvad I forventer, ikke kun hvad testeren skrev.
- At lukke opgaven, når ændringen er meldt · en melding fra leverandøren er ikke en kontrol.
Hvad kan og ikke kan konkluderes
En anbefaling kan vise en vej til at fjerne eller mindske et konkret fund. Den kan ikke alene afgøre, om løsningen passer til jeres øvrige systemer, eller hvad den betyder for driften. Den vurdering ligger hos virksomheden og de leverandører, der kender systemerne.
At alle anbefalinger er omsat til opgaver, viser, at rapporten er taget i brug. Det viser ikke, at fundene er væk. Det kan først siges, når opgaverne er udført og kontrolleret.
Tjekliste for hver anbefaling
- ☐ Er problemet bag anbefalingen beskrevet med almindelige ord?
- ☐ Er hurtig afhjælpning og grundlæggende ændring delt i hver sin opgave?
- ☐ Har hver opgave en ejer med mandat?
- ☐ Er det beskrevet, hvordan I kan se, at opgaven er løst?
- ☐ Er et fravalg af den foreslåede løsning begrundet?
- ☐ Er fund uden mulig løsning ført over i en risikoaccept?
- ☐ Er det aftalt, hvilke opgaver der skal efterprøves?
Kilder
- NIST SP 800-115, kapitel 8: anbefalinger til afhjælpning og rapportering efter testen.
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler om penetrationstest
Læs også: Sådan læser I en pentestrapport · Afslutningsmødet efter penetrationstesten
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT
