En pentestrapport ligger som et dokument, men IT-afdelingen arbejder i et sagssystem, og et fund, der ikke findes dér, bliver ikke rettet. Overførslen hviler på fire valg: hvordan et fund deles op i opgaver, hvem der ejer hver opgave, hvem der må se detaljerne, og hvad der skal være opfyldt, før en sag lukkes. Ledelsens samlede handlingsplan og prioriteringen af fundene er beskrevet for køberen på penetrationtest.dk. Her handler det om, hvordan driften gør planen til arbejde, der kan følges dag for dag.
Ét fund er ikke altid én sag
Rapporten er skrevet ud fra det, testeren så. Sagssystemet skal afspejle, hvem der gør hvad. De to inddelinger passer ikke nødvendigvis én til én.
- Ét fund, flere systemer · et fund om svage indstillinger på en serverrolle kan gælde mange servere med forskellige ejere. Del det op efter, hvem der skal handle.
- Ét fund, flere parter · en del af rettelsen ligger hos jer, en anden hos en leverandør. Giv hver part sin egen sag.
- Flere fund, én årsag · fund om de samme forældede indstillinger på klienter og servere kan have samme rod. Opret en fælles sag for årsagen og lad de enkelte fund pege på den.
- Hurtig del og lang del · en afskærmning kan laves i dag, mens den egentlige rettelse kræver et projekt. Hold dem adskilt. → Hurtige rettelser og større projekter
Behold rapportens fundnummer i hver sag. Det er den nøgle, der binder sagen til rapporten, til den senere kontrol og til næste års sammenligning. Når et fund er delt op, skal det samme nummer stå i alle delsagerne, så I kan se, at fundet først er løst, når den sidste af dem er lukket.
Hvad en sag skal indeholde
En sag skal kunne forstås af den, der får den, uden at rapporten ligger åben ved siden af. Det betyder ikke, at hele fundet skal kopieres ind.
- Fundnummer og titel · nøjagtigt som i rapporten.
- Berørte systemer · navne, ikke kun adresser, så den ansvarlige genkender dem.
- Hvad der skal være anderledes · det ønskede resultat i almindelige ord, fx at en administrationsflade kun kan nås fra driftsnettet.
- Alvorlighed og jeres vurdering · testerens vurdering og jeres egen, hvis den afviger.
- Frist · den dato, der er fastsat i handlingsplanen.
- Afhængigheder · andre sager, der skal løses først.
- Kriterium for lukning · hvordan I kan se, at opgaven er løst.
Det sidste punkt er let at springe over, når sagerne oprettes i en fart. Uden det bliver sagen lukket, når nogen har lavet noget, ikke når problemet er væk. Et godt kriterium kan efterprøves af en anden end den, der lavede ændringen, og det beskriver tilstanden bagefter, ikke arbejdet undervejs.
Følsomme detaljer hører ikke til i alle køer
Rapportens tekniske bilag kan beskrive, præcis hvordan testeren kom frem. Et sagssystem kan være åbent for mange: servicedesk, leverandører, studerende og vikarer. Overvej derfor, hvor meget der skal stå i selve sagen.
En praktisk løsning er at lade sagen beskrive opgaven og resultatet og henvise til fundets nummer i rapporten, som ligger et sted med begrænset adgang. Den, der skal rette, får adgang til det relevante afsnit. Når sagen lukkes, ligger beskrivelsen af fremgangsmåden stadig kun ét sted, og det er lettere at styre, hvem der har set den. Hvis sagssystemet kan begrænse synligheden af enkelte sager, så brug det til sager om alvorlige fund, indtil de er lukket.
Tænk også på leverandører med adgang til jeres system. En driftsleverandør skal se sine egne sager, ikke nødvendigvis hele listen over åbne svagheder i miljøet. → Rettelser efter kundens test
Hvilken sagstype passer?
Et testfund er hverken en hændelse eller en almindelig brugerhenvendelse. Hvis det lægges i køen for brugerhenvendelser, risikerer det at blive målt på svartid og lukket med en standardtekst. Vælg en sagstype, der passer til planlagt arbejde, og som kan følges over uger.
Selve ændringen i miljøet skal stadig gennem jeres ændringsstyring. Sagen om fundet og ændringen hører sammen, men er ikke det samme: én sag om et fund kan føre til flere ændringer, og en ændring kan dække flere fund. Lad dem henvise til hinanden, så den, der senere ser på en ændring, kan se, hvilket fund den skulle løse, og omvendt. → Testen i jeres ændringsstyring
Den amerikanske standardorganisation NIST beskriver i sin vejledning om sikkerhedstest, at planen for afhjælpning løbende skal opdateres med det, der er gjort, delvist gjort eller afventer en anden, og at den bør hænge sammen med organisationens styring af ændringer. Et sagssystem, der allerede bruges til ændringer, er et naturligt sted at gøre det.
Status, der siger noget
Statusfelterne i et sagssystem er lavet til drift, ikke til testfund. Aftal, hvad hver status betyder for et fund, så alle bruger dem ens.
- Åben · sagen er oprettet, men ingen er gået i gang.
- I gang · ejeren arbejder på den eller har bestilt arbejdet.
- Afventer · sagen venter på en anden sag, en leverandør eller en beslutning.
- Rettet · ændringen er gennemført i drift.
- Kontrolleret · rettelsen er efterprøvet, internt eller ved retest.
- Accepteret · ledelsen har besluttet ikke at rette, med begrundelse og dato for ny vurdering.
Forskellen på rettet og kontrolleret er den vigtigste. En sag, der springer direkte fra i gang til lukket, siger intet om, hvorvidt fundet er væk. → Klar til retest
Det skal I lade være med
- At vedhæfte hele rapporten til en sag. Del kun det, den ansvarlige skal bruge.
- At oprette én samlesag for hele testen. Den kan ikke fordeles eller følges.
- At lade sager stå uden ejer. En kø er ikke en ejer.
- At lukke sager på en melding om, at noget er ændret. Kriteriet for lukning skal være opfyldt.
- At slette fundnummeret. Uden det kan sagen ikke spores tilbage til rapporten.
Hvad kan og ikke kan konkluderes
En sagsliste, hvor hvert fund har sin sag, sin ejer og sin status, viser, at rapporten er omsat til arbejde. Den viser ikke, at prioriteringen er rigtig, eller at rettelserne virker. Den viser heller ikke noget om svagheder, testen ikke fandt. Sagssystemet er driftens redskab. Overblikket til ledelsen bygger på det, men er et andet produkt. → Status til ledelsen om rettelserne
Tjekliste til overførslen
- ☐ Har hvert fund mindst én sag med rapportens fundnummer?
- ☐ Er fund med flere ejere eller parter delt op?
- ☐ Har fælles årsager deres egen sag?
- ☐ Har hver sag en navngiven ejer og en frist?
- ☐ Er det beskrevet, hvornår sagen må lukkes?
- ☐ Er adgangen til tekniske detaljer begrænset?
- ☐ Er statusværdierne aftalt, herunder forskellen på rettet og kontrolleret?
- ☐ Henviser sager og ændringer til hinanden?
Kilder
- NIST SP 800-115, afsnit 8.2 og 8.3: planen for afhjælpning skal løbende opdateres med gennemførte, delvist gennemførte og afventende aktiviteter og bør indgå i organisationens styring af ændringer.
- NCSC: Penetration testing: vurdering og afhjælpning af sårbarheder er en forretningsproces, som ikke helt kan overlades til testholdet.
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler til IT-afdelingen
Læs også: Rettelser uden at stoppe driften · Klar til retest
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT
