En penetrationstest kan vare dage eller uger, og rapporten kommer først bagefter. Imens skal IT-afdelingen vide, hvad der sker i miljøet, så driften kan planlægge, reagere og forstå symptomer. Svaret på, hvad I skal bede om, hviler på formålet med en status: den skal give driften overblik over aktivitet, forhindringer og forhold, der ikke kan vente, ikke være en lille rapport. Den amerikanske standardorganisation NIST beskriver i sin vejledning om sikkerhedstest løbende statusmøder og rapporter, hvor hyppigheden afhænger af testens længde og kompleksitet, og hvor indholdet dækker det udførte, problemer undervejs og kritiske fund.
Hvad en status skal bruges til
Før formen aftales, skal det være klart, hvad driften vil bruge statussen til. Der er fire formål.
- Planlægning · at vide, hvilke systemer testeren arbejder på i den kommende periode, så overvågning og vagt kan fokusere. → Driftsovervågning under testen
- Fejlsøgning · at kunne holde et symptom op mod testerens aktivitet.
- Forhindringer · at fjerne det, der stopper testeren, fx en konto uden rettigheder eller en forbindelse, der ikke virker.
- Hastende forhold · at få besked om det, der ikke kan vente til rapporten.
Hvis statussen ikke tjener mindst ét af formålene, er den overflødig. Hvis den mangler et af dem, er den for tynd.
Drives dele af miljøet af en driftsleverandør, kan leverandøren have brug for et uddrag af statussen, så dens vagt ved, hvilke systemer der er i spil. Det er jeres kontaktperson, der videregiver det relevante, ikke testeren, der sender direkte til flere parter.
Det, statussen bør indeholde
En god status er kort og ens fra gang til gang, så den kan læses hurtigt og sammenlignes.
- Udført · hvilke områder og systemer testeren har arbejdet på siden sidst.
- Næste skridt · hvad testeren planlægger frem til næste status.
- Forhindringer · hvad der har stoppet eller forsinket arbejdet, og hvad testeren har brug for.
- Påvirkning · om testeren har set tegn på, at systemer er påvirket.
- Ændringer · om planen, afgrænsningen eller tidsplanen er ændret.
- Hastende forhold · en kort henvisning, hvis der er meldt noget særskilt.
Statussen behøver ikke beskrive, hvordan testeren arbejder. Den skal beskrive hvor og hvornår, så driften kan forholde sig til det.
Bed også om at få nævnt, hvis testeren har oprettet filer, konti eller andre spor i miljøet siden sidst. Det gør den senere oprydning lettere, fordi listen bygges op undervejs i stedet for at blive skrevet efter hukommelsen til sidst. → Spor efter testeren
Hyppighed og form
Der er ingen fast regel for, hvor ofte en status skal komme. Den amerikanske vejledning giver som eksempel en test over en måned med ugentlige møder og daglige rapporter i den mest aktive fase. Eksemplet viser princippet: jo kortere og mere intens testen er, jo tættere skal kontakten være. Læg tidspunktet, så statussen når driften, før næste arbejdsperiode begynder. Arbejder testeren om aftenen, er en status om morgenen mere nyttig end en sen besked, som ingen læser før dagen efter.
Aftal formen før testen.
- Skriftlig · en kort besked ad en aftalt kanal er let at gemme og finde igen.
- Mundtlig · et kort opkald eller møde giver plads til spørgsmål, men skal følges op skriftligt.
- Modtagere · IT’s kontaktperson og opgavens ejer, ikke en bred fordelerliste. → Kontaktpersonen i IT under testen
Hold modtagerkredsen lille. En status kan nævne systemer, hvor testeren har gjort fremskridt, og den slags oplysninger skal ikke ligge i mange postkasser. Aftal også, hvem der svarer på statussen, hvis den rejser et spørgsmål eller en forhindring, så testeren ikke venter på et svar, ingen har ansvaret for at give.
Hastende forhold venter ikke på statussen
Statussen er det faste spor. Forhold, der ikke kan vente, går et andet spor. NCSC beskriver i sin vejledning om penetrationstest, at den tekniske kontakt skal hjælpe testerne med at løfte kritiske forhold, og det skal ske, når de opstår.
Aftal derfor, at testeren ringer til kontaktpersonen med det samme ved alvorlige fund eller tegn på, at en anden end testeren er i miljøet, og at det bagefter bekræftes skriftligt. I den næste status står så kun en henvisning. Hvordan fundet håndteres, hører under jeres beredskab. → Beredskab under testen
Status er ikke rapporten
En status beskriver foreløbige observationer. Testeren har ikke nødvendigvis vurderet alvoren endeligt, og et forhold, der ser alvorligt ud tirsdag, kan vise sig at være mindre torsdag, eller omvendt. Brug derfor ikke statussen som grundlag for prioritering af rettelser, medmindre testeren selv har markeret noget som hastende. Spørger ledelsen undervejs, hvordan det går, kan IT-chefen fortælle om fremdrift og forhindringer, men bør vente med at nævne konklusioner, til rapporten foreligger.
Rettes noget på baggrund af en status, skal det gå gennem ændringsstyringen og meldes tilbage til testeren. Ellers kan rapporten beskrive et forhold, som allerede er ændret, uden at det fremgår. → Testen i jeres ændringsstyring
Gem statusserne
Statusserne er et spor over testperioden. Læg dem sammen med driftsloggen, så de kan bruges, når rapporten skal læses. De kan forklare, hvorfor et område blev dækket mindre end planlagt, eller hvorfor et system blev taget ud af testen. → Driftslog over testperioden
Sammenhold også statusserne med rapportens beskrivelse af, hvad der blev testet. Passer de ikke, er det et spørgsmål til afslutningsmødet. Det kan være en simpel forklaring, fx en ændring i planen, men den skal stå i rapporten, så læseren ikke tror, at et område er dækket fuldt ud.
Det skal I lade være med
- At bede om en fuld beskrivelse af fund i hver status. Det tager testtid og hører til rapporten.
- At sende statussen bredt rundt. Den kan indeholde følsomme oplysninger.
- At vente på statussen med noget, der haster. Hastende forhold har deres eget spor.
- At rette på baggrund af en status uden at melde det. Så passer rapporten ikke.
- At droppe statussen, når testen kører roligt. Det er netop dér, den viser, at alt er, som det skal være.
Hvad kan og ikke kan konkluderes
En status viser, hvad testeren har arbejdet på, og hvad der har stået i vejen. Den viser ikke, hvad testen har fundet, og den kan ikke erstatte rapportens vurdering. Mangler der statusser, eller er de uklare, siger det noget om samarbejdet, men ikke nødvendigvis noget om testens kvalitet.
Tjekliste til status undervejs
- ☐ Er formålet med statussen aftalt?
- ☐ Er indholdet fastlagt i en fast skabelon?
- ☐ Er hyppighed og form aftalt?
- ☐ Er modtagerkredsen begrænset?
- ☐ Har hastende forhold et separat spor?
- ☐ Bliver statusserne gemt sammen med driftsloggen?
Kilder
- NIST SP 800-115: løbende statusmøder og rapporter; hyppigheden afhænger af testens længde og kompleksitet; eksempel med ugentlige møder og daglige rapporter i den aktive fase; indhold om det udførte, problemer og kritiske fund.
- NCSC (UK): Penetration testing: den tekniske kontakt hjælper testerne med at løfte kritiske forhold.
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler til IT-afdelingen
Læs også: Beredskab under testen · Fra fund til opgave
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT
