At genbruge sidste års opgave uden at se på ændringerne

Penetrationtest: opslagsværk om penetrationstest på dansk

Sidste års opgavebeskrivelse er fristende at sende igen, fordi den blev godkendt, og fordi testeren kender den. Problemet er, at dokumentet beskriver virksomheden, som den så ud dengang, og en test er kun så præcis som den beskrivelse, den bygger på.

Genbrug er i sig selv fornuftigt. Strukturen, kontaktlisten og formuleringerne om rammer kan spare tid. Men hvert afsnit skal læses igennem med ét spørgsmål for øje: passer det stadig? Svaret er sjældent ja over hele linjen, selv i en virksomhed, der føler, at intet er sket.

Hvorfor det gamle dokument ser rigtigt ud

En opgavebeskrivelse ældes stille. Adresserne står der stadig, systemnavnene er velkendte, og ingen har sendt en besked om, at noget er forældet. Derfor kan den virke dækkende, selv om grundlaget har flyttet sig.

Ændringer sker ofte i små skridt, som ingen enkeltperson samler. Driftsleverandøren flytter en server, marketing får en ny kampagneside, og en afdeling tager en ny tjeneste i brug. Hver ændring virker for lille til at nævne, men tilsammen kan de betyde, at dokumentet beskriver et andet miljø end det, der findes i dag.

Der er også en menneskelig side. Den, der skrev dokumentet sidste år, er måske ikke den, der bestiller nu. Den nye bestiller kan opfatte teksten som facit frem for som et udkast, der skal efterprøves. → Opgavebeskrivelsen

Hvad der typisk har flyttet sig

Gennemgangen bliver lettere, når den deles op efter emner, hvor forældelse kan gemme sig. Brug listen som udgangspunkt, og tilføj jeres egne punkter.

Systemer og adresser · nye, nedlagte eller omdøbte løsninger, domæner og adresser.
Leverandører · skift af hostingfirma, driftsleverandør eller softwareleverandør siden sidst.
Brugerroller · nye kundetyper i kundeportalen eller ændrede administrative roller i ERP-systemet.
Forbindelser · integrationer, der er kommet til eller er fjernet.
Kontakter · personer, der har skiftet stilling eller er fratrådt.
Undtagelser · forhold, der var udeladt af en grund, som ikke længere gælder.

Et gammelt dokument kan også indeholde systemer, der er lukket. At bede om en test af en nedlagt løsning koster tid i opstarten og kan give en forkert forventning til rapportens dækning. Nedlagte systemer skal ud, og det bør fremgå, at de er fjernet med vilje. → IP-adresser og domæner

Undtagelserne fortjener særlig opmærksomhed

Sidste års undtagelser blev aftalt i en bestemt situation. Måske var webshoppen midt i en flytning, eller måske manglede en leverandørs tilladelse. Hvis undtagelsen bare kopieres, kan et område blive holdt uden for testen år efter år uden en aktiv beslutning.

Læs hver undtagelse og skriv begrundelsen ved siden af. Gælder grunden stadig, kan undtagelsen blive stående. Er grunden væk, skal området enten med eller have en ny begrundelse. Det giver ledelsen et ærligt billede af, hvad testen ikke dækker, og hvorfor.

Det modsatte kan også ske. Et område, der var med sidste år, kan være blevet så ustabilt eller så tæt på udskiftning, at det giver bedre mening at vente. Den beslutning skal også stå i dokumentet. → Et for snævert scope

Hvem skal læse dokumentet igennem?

Den, der bestiller, kender sjældent alle ændringer alene. En kort runde med de personer, der ejer systemerne, giver et mere retvisende billede end en gennemlæsning ved skrivebordet. Det kan være projektlederen for kundeportalen, ejeren af ERP-systemet og den, der har kontakten til driftsleverandøren.

Spørg konkret. Et spørgsmål om, hvad der er nyt, giver ofte svaret ingenting. Et spørgsmål om, hvilke leverandører, integrationer og roller der er ændret siden sidste test, giver bedre svar. Bed også om at få at vide, om noget er planlagt i den periode, hvor testen skal finde sted.

Driftsleverandøren og hostingfirmaet kan bidrage med deres egen oversigt over ændringer. Deres liste kan afsløre forhold, som ingen internt har opdaget. → Driftsleverandøren og testen

Gem svarene sammen med dokumentet. En kort note om, hvem der har bekræftet hvilke afsnit og hvornår, gør næste års gennemgang hurtigere. Den viser også, hvilke dele der ikke blev bekræftet af nogen, og som derfor bør have ekstra opmærksomhed i opstartsmødet med testeren.

Formålet kan også være forældet

Det er ikke kun systemerne, der ændrer sig. Grunden til at teste kan være en anden i år. Sidste år var anledningen måske en ny kundeportal, mens det i år er en kunde, der beder om dokumentation, eller ledelsen, der vil vide, om kontornettet er adskilt fra gæstenettet. Et nyt formål kan kræve en anden afgrænsning, selv om systemerne er de samme.

Skriv derfor formålet forfra, før resten af dokumentet gennemgås. Når formålet er på plads, er det lettere at se, hvilke afsnit der stadig passer, og hvilke der skal skrives om.

Sidste års rapport er et input, ikke en skabelon

Den forrige rapport fortæller, hvad testen fandt, og hvilke områder der var svære at vurdere. Begge dele er nyttige, når årets opgave skal formes. Et område med mange åbne spørgsmål kan fortjene mere plads, mens et område, der er erstattet, kan udgå.

Rapporten fortæller derimod ikke, hvad der er sket bagefter. Rettelser, nye funktioner og ændrede arbejdsgange ligger uden for den. Den skal derfor læses sammen med listen over ændringer og ikke i stedet for den.

Hvis I ønsker, at resultaterne skal kunne sammenlignes med sidste år, skal ændringerne stå tydeligt. Ellers kan en forskel i resultatet skyldes, at noget andet blev testet, og ikke at sikkerheden har ændret sig. Hvordan testens indhold kan fornys fra år til år, er behandlet i → Den årlige test.

Det skal I lade være med

At sende dokumentet uændret · Uden gennemgang bliver gamle fejl og forældede oplysninger til årets opgave.
At kopiere undtagelser uden begrundelse · Et område kan forsvinde fra testen uden, at nogen har besluttet det.
At lade nedlagte systemer stå · De forvirrer opstarten og giver et forkert billede af dækningen.
At læse dokumentet alene · Systemejere og leverandører kender ændringer, som bestilleren ikke kender.
At sammenligne resultater uden at notere ændringer · Forskelle kan skyldes en anden opgave og ikke en anden sikkerhed.

Hvad kan og ikke kan konkluderes

En opdateret opgavebeskrivelse gør det muligt at læse årets rapport som et billede af det miljø, der findes nu. Den er ingen garanti for, at alle ændringer er fanget. Noget kan være overset, også efter en grundig runde.

At sidste års opgave genbruges, er ikke et problem i sig selv. Det afgørende er, om genbruget er et resultat af en gennemgang eller af en vane. Kun det første giver et udgangspunkt, som holder, når ledelsen eller en kunde spørger ind til det.

Tjekliste før dokumentet sendes igen

☐ Er alle systemer, adresser og domæner kontrolleret mod virksomhedens nuværende oversigt?
☐ Er nedlagte løsninger fjernet og nye tilføjet?
☐ Har hver undtagelse en begrundelse, der stadig gælder?
☐ Er leverandører, kontakter og brugerroller opdateret?
☐ Har systemejerne læst de afsnit, der vedrører dem?
☐ Er planlagte ændringer i testperioden noteret?
☐ Står det tydeligt, hvad der er ændret i forhold til sidste år?

Senest gennemgået: oktober 2026.