En penetrationstest arbejder i rigtige systemer, og selv en forsigtig test kan få et system til at opføre sig uventet. Spørgsmålet for driften er derfor ikke, om der findes en backup, men om I kan vende tilbage til en kendt tilstand for netop de systemer, testen rører. Svaret hviler på tre ting: et friskt gendannelsespunkt for de vigtigste systemer, en kontrol af, at det kan bruges, og en klar aftale om, hvem der beslutter at gendanne. Det tager kort tid at forberede og kan spare mange timer, hvis noget går skævt.
Hvorfor en test kræver et gendannelsespunkt
Det britiske NCSC skriver i sin vejledning om penetrationstest, at testerne skal gøre alt for at undgå unødig påvirkning, men at uventede reaktioner ikke kan udelukkes. Den amerikanske standardorganisation NIST nævner tab af tilgængelighed som en af de risici, der skal overvejes, før teknikker vælges. Ingen af de to lover, at en test er uden følger, og det skal driften heller ikke gøre.
En test kan ændre data, oprette filer eller konti, belaste en tjeneste eller ramme et ældre system, der ikke tåler det. Den slags følger hører som udgangspunkt til oprydningen efter testen. Men hvis et system går i stå, eller data bliver ændret på en måde, ingen havde forudset, er gendannelse den sikre vej tilbage. → Skrøbelige systemer
Hvad der skal kunne rulles tilbage
Start med testens afgrænsning og spørg for hvert område: hvad er det værste, der kan ske, og hvor ligger vejen tilbage?
- Identitet · katalogtjenesten og de systemer, der styrer konti og grupper. Her kan en fejl ramme alle brugere på én gang.
- Forretningssystemer · databaser og programmer, hvor testen arbejder med rigtige data eller rigtige roller.
- Opsætning af netværksudstyr · firewalls, routere og adgangspunkter, hvis testen kan påvirke dem eller kræver midlertidige ændringer.
- Servere i opgaven · især de gamle og de følsomme, som I allerede ved er sårbare over for belastning.
- Cloudopsætning · politikker, roller og indstillinger i de lejere og abonnementer, testen dækker.
- Webapplikationer · indhold og database bag de applikationer, der testes med login.
Opsætningsfiler er lette at overse. En firewall, der skal genopsættes efter hukommelsen, er en langsommere vej tilbage end en gemt kopi fra dagen før.
Friskt, kendt og afprøvet
Et gendannelsespunkt fra sidste måned hjælper kun lidt, hvis der er sket meget siden. Lav eller bekræft et punkt så tæt på testens start som muligt, og skriv tidspunktet ned. Det tidspunkt er jeres reference, hvis I senere skal afgøre, om en ændring skete før eller under testen.
Notér også, hvornår jeres faste backupjob kører i testperioden. Et natligt job, der belaster lager og net, kan forveksles med testens påvirkning, og det er lettere at udelukke, når tidspunktet står i jeres egen log. → Driftslog over testperioden
En backup, der aldrig er gendannet, er en antagelse. NCSC anbefaler i sit indlæg om offline backup, at sikkerhedskopier tages jævnligt og afprøves jævnligt, så man ved, at de virker som forventet.
Før testen behøver I ikke en fuld gendannelsesøvelse. Det er nok at kontrollere for de vigtigste systemer, at kopien findes, at den er læsbar, og at den person, der skal gendanne, ved hvordan og har de nødvendige rettigheder. Er gendannelsen afhængig af en leverandør, så bekræft, at leverandøren kan nås i testperioden og kender til testen.
Systemer, I ikke selv tager backup af
Nogle af systemerne i opgaven ligger hos andre. Det kan være en hostet webshop, et fagsystem, som leverandøren drifter, eller en tjeneste i Microsoft 365, hvor platformen selv står for en del af sikringen. Her kan IT-afdelingen ikke bare tage et gendannelsespunkt.
Spørg leverandøren, før testen begynder, hvad der kan rulles tilbage, hvor langt tilbage, og hvor hurtigt. Svaret afgør, hvor forsigtig testen skal være i netop det system, og om nogle dele bør holdes ude. For cloudtjenester kan det være relevant at vide, om der findes versionshistorik eller mulighed for at hente slettede data tilbage. NCSC nævner netop den mulighed som noget, der bør afklares med udbyderen.
Skriv svarene ind i listen over systemer i opgaven. Står der intet om gendannelse ud for et system, er det et tegn på, at spørgsmålet ikke er stillet endnu. → Netværkstegning og systemoversigt
Hvem beslutter at gendanne
Gendannelse er en beslutning, ikke en refleks. Den sletter det, der er sket siden gendannelsespunktet, også data, som brugerne har lavet i mellemtiden, og spor, som kan forklare, hvad der gik galt.
Aftal derfor på forhånd, hvem der må beslutte at gendanne et system i testperioden. Det er normalt systemets ejer i samråd med IT’s kontaktperson. Testeren beslutter ikke gendannelse og udfører den ikke. Før der gendannes, bør testeren have stoppet aktiviteten mod systemet og oplyst, hvad der blev gjort. → Beredskab under testen
Backupsystemet er også et testområde
Det kan være fristende at holde backupsystemet helt uden for testen, så intet kan ske med det. Det er en afvejning. Backupsystemet har vide rettigheder og indeholder kopier af alt, og det er derfor et mål i sig selv for en angriber. Hvis det holdes ude, skal det være et bevidst valg, som fremgår af rapporten.
NCSC anbefaler, at mindst én kopi er adskilt fra resten, så en enkelt hændelse ikke kan nå alle kopier. Om jeres opsætning lever op til den tanke, er et spørgsmål for testen, ikke for forberedelsen. → Backupsystemet som mål
Det skal I lade være med
- At antage, at den natlige backup er nok. Kontrollér tidspunktet og indholdet for de systemer, testen rører.
- At glemme opsætningen af netværksudstyr. Den er ikke altid med i den almindelige backup.
- At gendanne, før testeren har stoppet. Ellers kan det samme ske igen kort efter.
- At lade testeren rette eller gendanne. Genopretning følger jeres egne procedurer.
- At undtage backupsystemet uden at skrive det ned. Så tror læseren af rapporten, at det er testet.
Hvad kan og ikke kan konkluderes
Et friskt og afprøvet gendannelsespunkt gør konsekvenserne af en uheldig test mindre, men det forhindrer ikke, at noget kan gå galt. At backuppen kunne gendannes før testen, siger heller ikke noget om, hvor godt den er beskyttet mod en angriber. Det sidste er et spørgsmål, testen selv eller en senere gennemgang skal svare på.
Tjekliste før testen
- ☐ Er de systemer, testen rører, gennemgået for gendannelsespunkter?
- ☐ Er opsætningen af netværksudstyr gemt?
- ☐ Er gendannelsespunktets tidspunkt noteret?
- ☐ Er det kontrolleret, at kopierne findes og kan læses?
- ☐ Ved den, der skal gendanne, hvordan det gøres?
- ☐ Er det aftalt, hvem der beslutter gendannelse?
- ☐ Er backupjobbenes tidspunkter kendt af kontaktpersonen?
Kilder
- NCSC (UK): Penetration testing: testere skal undgå unødig påvirkning, men uventede reaktioner kan ikke udelukkes.
- NIST SP 800-115: penetrationstest kan føre til tab af tilgængelighed, og risikoen skal indgå i valget af teknikker.
- NCSC: Offline backups in an online world: britisk myndigheds indlæg om at holde mindst én kopi adskilt og afprøve gendannelse jævnligt.
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler til IT-afdelingen
Læs også: Forberedelse i IT-afdelingen · Driftsovervågning under testen
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT
