En rettelse efter en penetrationstest er en ændring i et miljø, som brugere og kunder er afhængige af, og en rettelse, der stopper driften, kan gøre mere skade end fundet. Svaret på, hvordan IT retter uden at skabe nye problemer, hviler på tre ting: rettelsen afprøves, før den når hele produktionen, den gennemføres efter en plan, alle berørte kender, og der findes en vej tilbage, hvis den ikke virker. Her beskrives det på begrebsniveau. Den konkrete fremgangsmåde afhænger af systemet og af jeres egen ændringsstyring.
Hvorfor rettelser kan gå galt
Testeren anbefaler en ændring ud fra det, testen viste. Testeren kender ikke nødvendigvis alle de systemer, der afhænger af den indstilling, der skal ændres. En stramning af adgangen til en fildeling kan ramme et nattligt job. En ny regel i firewallen kan afbryde en integration til en leverandør. En opdatering kan ændre en indstilling, som ingen havde tænkt over.
Den amerikanske standardorganisation NIST nævner i sin vejledning om patchstyring, at en installation kan have bivirkninger, fx at eksisterende sikkerhedsindstillinger ændres, og at driftsproblemer kan gøre det nødvendigt at fjerne ændringen igen, vende tilbage til den tidligere udgave eller gendanne fra backup. Det samme gælder rettelser af opsætning og rettigheder.
Find ud af, hvad ændringen rører ved
Før en rettelse planlægges, skal det være klart, hvad den berører.
- Systemer · hvilke servere, klienter eller tjenester ændres direkte?
- Afhængigheder · hvilke andre systemer, job og integrationer bruger det, der ændres?
- Brugere · hvem mærker ændringen, og hvordan?
- Leverandører · skal en leverandør godkende, udføre eller være klar til at hjælpe?
- Overvågning · hvordan ser I, om noget holder op med at virke?
Hvis afhængighederne er ukendte, er det første skridt at finde dem. Logning af, hvem der faktisk bruger en tjeneste, kan give svaret, før ændringen laves. → Når testen viser, at dokumentationen ikke passer
Afprøv før produktion
Den bedste afprøvning sker et sted, der ligner produktionen. Samme organisations vejledning om sikkerhedstest anbefaler, at tekniske ændringer afprøves på sammenlignelige systemer i et testmiljø, før de rulles ud, og tilføjer, at det mindsker risikoen for uventede reaktioner uden at fjerne den.
Har IT-afdelingen ikke en fuld kopi af produktionen, kan afprøvningen ske i mindre skridt.
- En enkelt maskine eller konto · ændringen laves på ét system, der er repræsentativt, og som kan undværes et stykke tid.
- En lille gruppe · ændringen rulles ud til en afgrænset gruppe, fx IT-afdelingen selv eller en afdeling, der har sagt ja til at være først.
- Resten i bølger · når den lille gruppe har kørt uden problemer, udvides udrulningen.
Vejledningen om patchstyring beskriver netop sådan en trinvis udrulning, hvor en lille del af systemerne får ændringen først og fungerer som forvarsel for resten. Hvis der opstår problemer, kan udrulningen stoppes, før den rammer alle.
Vælg de første systemer med omtanke. De skal ligne resten nok til, at et problem viser sig hos dem, og de skal have brugere, der melder tilbage, når noget opfører sig anderledes. En gruppe, der aldrig bruger den berørte funktion, giver en falsk tryghed. Aftal også, hvor længe hvert trin skal køre, før det næste begynder, og hvem der beslutter at gå videre.
Planen for selve ændringen
En rettelse, der gennemføres uden plan, kan være svær at gennemskue bagefter. Planen behøver ikke være lang, men den skal svare på nogle faste spørgsmål.
- Hvornår · i hvilket tidsrum, og passer det med forretningens travle perioder?
- Hvem · hvem udfører, hvem er klar til at hjælpe, og hvem skal kontaktes, hvis noget går galt?
- Hvordan ser succes ud · hvad skal virke bagefter, og hvordan kontrolleres det?
- Hvornår stopper I · hvad får jer til at afbryde og rulle tilbage?
- Hvem skal vide det · servicedesk, brugere og leverandører, der kan blive påvirket.
Planen går gennem jeres ændringsstyring som enhver anden ændring. At fundet stammer fra en sikkerhedstest, giver ikke ret til at springe processen over. → Testen i jeres ændringsstyring
Vejen tilbage
En vej tilbage er en beskrevet måde at bringe systemet til tilstanden før ændringen. Den skal være kendt, før ændringen laves, ikke opfundet midt i en forstyrrelse.
For en indstilling kan vejen tilbage være at notere den gamle værdi. For en opdatering kan det være at fjerne den igen eller vende tilbage til et gendannelsespunkt. For en større ændring kan det kræve en backup, der er afprøvet. Skriv vejen tilbage ind i planen med de samme detaljer som selve ændringen, og lad den, der skal bruge den, læse den igennem på forhånd. Overvej også, om vejen tilbage selv kræver adgang, som ændringen fjerner. En stramning af administratoradgangen må ikke låse den person ude, der skal rulle den tilbage.
Når en ændring rulles tilbage, er fundet stadig åbent. Notér, hvad der gik galt, og planlæg et nyt forsøg eller en midlertidig beskyttelse. Tilbagerulningen er en nyttig oplysning: den viser en afhængighed, som ingen kendte, og den bør skrives ind i dokumentationen af systemet. → Midlertidige afhjælpninger
Servicevinduer og samlede ændringer
Nogle rettelser kræver genstart eller korte afbrydelser. Saml dem gerne i faste servicevinduer, så brugerne kun forstyrres på kendte tidspunkter. Men saml ikke for mange ændringer i samme vindue. Hvis ti ændringer laves på én gang, og noget går galt, er det svært at se, hvilken der er årsagen.
Et alvorligt fund kan ikke altid vente på næste faste vindue. Aftal på forhånd, hvordan et ekstra vindue besluttes, og hvem der kan godkende det. → Hurtige rettelser og større projekter
Det skal I lade være med
- At rette direkte i produktionen, fordi det haster. Selv et akut fund fortjener en kort afprøvning.
- At gå i gang uden en vej tilbage. Den skal være kendt før ændringen.
- At samle alle rettelser i ét vindue. Fejlfinding bliver svær.
- At glemme servicedesken. Den møder brugernes spørgsmål først. → Servicedesken under testen
- At lukke fundet, når en ændring er rullet tilbage. Fundet er stadig åbent.
Hvad kan og ikke kan konkluderes
En rettelse, der er afprøvet, gennemført efter plan og kørt uden problemer, viser, at ændringen ikke har forstyrret driften. Den viser ikke i sig selv, at fundet er væk. Det kræver en kontrol af, at rettelsen har den virkning, rapporten efterspurgte. Afprøvning før produktion mindsker risikoen for forstyrrelser, men kan ikke udelukke dem.
Tjekliste før hver rettelse
- ☐ Er berørte systemer, afhængigheder og brugere kendt?
- ☐ Er ændringen afprøvet på et repræsentativt system eller en lille gruppe?
- ☐ Er tidspunkt, udfører og kontaktpersoner aftalt?
- ☐ Er det beskrevet, hvordan succes kontrolleres?
- ☐ Er vejen tilbage beskrevet og mulig at gennemføre?
- ☐ Er ændringen godkendt i ændringsstyringen?
- ☐ Er servicedesk og berørte brugere informeret?
Kilder
- NIST SP 800-115, afsnit 8.3: tekniske ændringer bør afprøves på sammenlignelige systemer i et testmiljø før udrulning; afprøvningen mindsker, men fjerner ikke, risikoen.
- SP 800-40 Rev. 4: bivirkninger ved installation, tilbagerulning eller gendannelse fra backup ved driftsproblemer og trinvis udrulning, hvor en lille gruppe systemer får ændringen først.
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler til IT-afdelingen
Læs også: Fra fund til opgave · Gør rettelserne permanente
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT
