En penetrationstest er ikke en ændring i klassisk forstand, men den kan påvirke systemer, kræve midlertidige åbninger og føre til rettelser, mens den står på. Derfor hører den hjemme i IT-afdelingens ændringsstyring. Svaret på, hvordan testen registreres, hviler på et enkelt princip: alt, hvad testen kræver af ændringer i driften, skal kunne findes, godkendes og fjernes igen ad samme vej som enhver anden ændring. Testen som helhed registreres som en planlagt aktivitet, og de enkelte ændringer, den medfører, registreres hver for sig.
Hvorfor testen skal kunne ses i processen
Ændringsstyring findes, for at driften kan se, hvad der sker i miljøet, og hvem der har besluttet det. En test, der kører ved siden af processen, skaber et blindt felt i netop den periode, hvor der sker mest uventet.
- Overblik · den, der ser på ændringskalenderen, kan se, at der er en test i gang, og hvilke systemer den rører.
- Konflikter · planlagte ændringer kan flyttes, så de ikke falder sammen med testen.
- Sporbarhed · undtagelser og rettelser kan findes igen, når testen er slut.
- Fejlsøgning · et symptom i testperioden kan holdes op mod det, der står registreret.
Den amerikanske standardorganisation NIST anbefaler i sin vejledning om sikkerhedstest, at testen ikke lægges samtidig med opgraderinger, integration af nye løsninger eller andre tidspunkter, hvor sikkerheden i systemet er ved at blive ændret. Ændringskalenderen er det sted, hvor den slags konflikter bliver synlige.
Testen som planlagt aktivitet
Registrér testen som én samlet aktivitet med periode, afgrænsning og kontaktpersoner. Den skal ikke godkendes som en teknisk ændring, men som en kendt begivenhed, der påvirker driften.
- Periode · start- og slutdato og eventuelle tidspunkter uden for normal arbejdstid.
- Afgrænsning · systemer, segmenter og platforme, testen dækker, og dem, der er holdt ude.
- Kontakt · IT’s kontaktperson og testerens kontakt. → Kontaktpersonen i IT under testen
- Afhængigheder · undtagelser, testkonti og udstyr, der skal på plads før start.
- Henvisning · til den godkendte aftale, så registreringen ikke selv skal rumme alle detaljer.
Hvis jeres proces har et ændringsråd eller en fast godkender, så præsenter testen dér, før den begynder. Det giver dem, der ejer andre ændringer, mulighed for at sige fra i tide.
Drives en del af miljøet af en driftsleverandør med sin egen ændringsstyring, skal testen også registreres dér. Aftal, hvem der sørger for det, og bed om at få leverandørens registrering henvist i jeres egen. Ellers kan leverandøren gennemføre en planlagt ændring i testugen uden at vide, at systemet er under test, eller afvise en undtagelse, fordi den ikke kan genkendes. Det samme gælder cloudplatforme, hvor ændringer i politikker og roller kan ske fra flere steder.
Ændringer, testen kræver
En test kan kræve ændringer i miljøet, før den kan gå i gang. Hver af dem er en almindelig ændring og skal registreres som sådan, med ejer, godkendelse og plan for fjernelse.
- Undtagelser · en åbning i firewall eller filtre for testerens afsenderadresser, hvis det er aftalt. → Midlertidige undtagelser til testen
- Testkonti · oprettelse, rettigheder og udløbsdato.
- Netadgang · et stik, en VPN-profil eller en placering i et bestemt segment.
- Testenhed · udstyr, der sættes op på jeres net i perioden.
Koble hver ændring til testens samlede registrering. Så kan oprydningen bagefter tage udgangspunkt i én liste i stedet for hukommelsen. → Oprydning efter testen
Andre ændringer i testperioden
Tag stilling til de ændringer, der allerede er planlagt i testperioden, før den begynder. Der er tre muligheder for hver af dem: udskyd, gennemfør og meld til testeren, eller tag systemet ud af testen.
En ændring, der gennemføres midt i testen uden at blive meldt, kan give et resultat, der ikke længere passer. Et fund, testeren gjorde mandag, kan være væk tirsdag, eller et system, der var lukket, kan være åbnet. Begge dele gør rapporten sværere at læse. Brug ændringskalenderen til at finde de ændringer, der rammer systemerne i opgaven, og send listen til testeren.
Rettelser, mens testen står på
Når et alvorligt fund bliver meldt undervejs, er det fristende at rette det med det samme. Den amerikanske vejledning beskriver netop den fristelse og anbefaler, at administratorer følger organisationens ændringsstyring, også når fundet haster.
Det betyder ikke, at rettelsen skal vente til næste ændringsråd. Har jeres proces en vej til hasteændringer, kan den bruges. Det betyder, at rettelsen registreres, godkendes af den rette og meldes til testeren, så testeren ved, at systemet ikke længere ser ud, som det gjorde. Ellers kan testeren bruge tid på noget, der er ændret, og rapporten kan beskrive et fund, der allerede er rettet, uden at det fremgår. → Status undervejs
Når testen er slut
Lukningen af testen i ændringsstyringen er en kontrol, ikke en formalitet. Gennemgå de ændringer, der blev koblet til testen, og kontrollér, at hver af dem enten er fjernet eller bevidst gjort permanent. Først derefter lukkes den samlede registrering. Ændringer, der skal blive, fordi de har vist sig at være en forbedring, registreres på ny som almindelige ændringer med ejer, så de ikke står som rester af en test.
Notér samtidig de rettelser, der blev lavet under testen, så de kan genfindes, når rapporten kommer. Rapporten vil tage udgangspunkt i det, testeren så, og det er jeres registrering, der viser, hvad der er sket siden. → Fra fund til opgave
Det skal I lade være med
- At holde testen uden for ændringsstyringen, fordi den ikke ændrer noget. Den kræver ændringer og påvirker driften.
- At registrere undtagelser uden slutdato. En åbning uden udløb bliver stående.
- At rette i hast uden registrering. Så kan hverken testeren eller I selv forklare forløbet bagefter.
- At gennemføre store ændringer midt i testen. Resultatet bliver svært at tolke.
- At lukke registreringen, før oprydningen er kontrolleret. Lukningen skal bekræfte, at alt er væk.
Hvad kan og ikke kan konkluderes
At testen er registreret og godkendt i ændringsstyringen, viser, at driften har overblik over perioden. Det siger ikke noget om, hvor godt jeres ændringsstyring virker i almindelighed, og testen er ikke en revision af processen. Fund, der skyldes ændringer uden om processen, kan dog pege på, at den har huller, og den oplysning bør bruges.
Tjekliste til ændringsstyringen
- ☐ Er testen registreret som en samlet aktivitet med periode og afgrænsning?
- ☐ Er ændringsrådet eller godkenderen orienteret før start?
- ☐ Er undtagelser, testkonti og netadgang registreret som ændringer med slutdato?
- ☐ Er planlagte ændringer i perioden udskudt eller meldt til testeren?
- ☐ Er der en aftalt vej for hasteændringer under testen?
- ☐ Bliver rettelser under testen meldt til testeren?
- ☐ Er alle koblede ændringer kontrolleret, før registreringen lukkes?
Kilder
- NIST SP 800-115: test bør ikke falde sammen med opgraderinger og andre ændringer i sikkerheden; ved hurtige rettelser under testen bør organisationens ændringsstyring følges.
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler til IT-afdelingen
Læs også: Rettelser uden at stoppe driften · Forberedelse i IT-afdelingen
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT
