En rettelse efter en penetrationstest gælder kun den maskine, den blev lavet på, medmindre den også kommer ind i det, nye maskiner bygges ud fra. Ellers dukker fejlen op igen på næste server, næste bærbare eller næste virtuelle maskine, og næste rapport finder det samme. Rettelsen bliver permanent, når den findes i tre ting: den beskrevne standardopsætning, de skabeloner og politikker, der udruller den, og en kontrol, der opdager, når en maskine afviger.
Hvor fejlen egentlig kom fra
Før en rettelse kan gøres permanent, skal I vide, hvor fejlen opstod. Spørg for hvert fund: blev det bygget ind fra start, eller opstod det senere?
- Fra skabelonen · maskinen blev installeret ud fra et billede eller en skabelon, der allerede havde fejlen.
- Fra en politik · en central indstilling, fx i gruppepolitikker, gav alle maskiner samme svaghed. → Gruppepolitikker som testområde
- Fra en manuel ændring · en administrator ændrede noget på én maskine for at løse et akut problem.
- Fra en leverandør · systemet blev leveret og sat op af en tredjepart efter dennes egen standard.
- Fra tidens gang · en indstilling var i orden, da maskinen blev bygget, men er ikke længere god nok.
Hver årsag kræver sin rettelse. Retter I kun den maskine, testeren fandt, mens årsagen ligger i skabelonen, kommer fundet igen.
Standardopsætningen som dokument
Beslut, hvordan en maskine af hver type skal være sat op, og skriv det ned. Det behøver ikke være et stort dokument. Det skal kunne svare på, hvilke indstillinger der skal være til stede, hvorfor, og hvem der må ændre dem.
Microsoft beskriver en sikkerhedsbaseline som en samling anbefalede indstillinger med en forklaring af deres betydning for sikkerheden, og anbefaler at bygge på en kendt og afprøvet baseline frem for at lave sin egen fra bunden. En baseline fra producenten kan derfor være et udgangspunkt, som I tilpasser jeres miljø. → Hærdningsstandarder og sikkerhedsbaselines
Rapportens fund er et konkret input til standarden. Hvert fund, der skyldtes en indstilling, bør give anledning til spørgsmålet: står den rigtige indstilling i standarden nu? Hvis ikke, skal standarden opdateres, før rettelsen meldes færdig.
Skabeloner og udrulning
Standarden skal ud i de ting, der faktisk bygger maskinerne.
- Installationsbilleder · de billeder, nye klienter og servere installeres fra.
- Skabeloner til virtuelle maskiner · både lokalt og i cloud. → Virtuelle maskiner i Azure og AWS
- Centrale politikker · gruppepolitikker og enhedspolitikker, der styrer indstillinger på eksisterende maskiner.
- Infrastruktur som kode · beskrivelser, der opretter netværk, servere og tjenester automatisk. → Infrastruktur som kode
- Leverandørens opsætning · krav til de leverandører, der installerer systemer i jeres miljø.
Det er her, en enkelt rettelse får størst virkning. En ændring i en central politik eller et installationsbillede kan rette alle fremtidige maskiner på én gang. Til gengæld kan en fejl i den samme ændring også ramme alle. Ændringer i skabeloner skal derfor gennem den samme afprøvning og godkendelse som andre ændringer i produktionen. → Rettelser uden at stoppe driften
Eksisterende maskiner
En opdateret skabelon retter kun de maskiner, der bygges fremover. De eksisterende skal have rettelsen på anden vis, enten gennem en central politik eller ved at blive bygget om.
Lav en oversigt over, hvilke maskiner der er bygget ud fra den gamle skabelon, og hvornår de får rettelsen. Maskiner, der aldrig bliver bygget om, skal enten nås af en central politik eller stå på listen over undtagelser med en begrundelse. Vær særligt opmærksom på maskiner, der står uden for den almindelige administration, fx systemer i produktionen, maskiner hos eksterne medarbejdere og servere, en leverandør passer. De bliver let overset, når en rettelse rulles ud centralt, og det kan være netop dem, næste test finder.
Hvem ejer standarden
En standard uden ejer bliver ikke opdateret. Udpeg en person eller et team for hver type maskine: klienter, servere, netværksudstyr og cloudressourcer. Ejeren beslutter, hvad der står i standarden, sørger for, at skabelonerne følger med, og tager stilling, når nogen beder om en undtagelse.
Ejeren skal også have fundene fra testen. Når rapporten kommer, gennemgår ejeren de fund, der vedrører egen maskintype, og vurderer, om standarden skal ændres. Det samme gælder, når producenten udgiver en ny version af sin baseline, eller når driften selv opdager en indstilling, der giver problemer.
Har I en driftsleverandør, der bygger maskinerne, skal det stå i aftalen, hvis standard der gælder, og hvordan ændringer efter en test kommer ind i den. Ellers kan rettelsen ende hos jer, mens skabelonen ligger hos leverandøren og fortsætter uændret.
Kontrol af afvigelser
Opsætning ændrer sig over tid. En administrator slår en indstilling fra for at få et program til at virke, en leverandør tilføjer en konto, en ny version af styresystemet har andre standardværdier. Uden kontrol glider maskinerne væk fra standarden, og efter et par år ligner miljøet det, testen fandt.
NIST’s vejledning om sikkerhedsfokuseret konfigurationsstyring beskriver, at konfigurationen af systemer skal styres og overvåges, og at det er en del af den almindelige konfigurationsstyring. For driften betyder det:
- Sammenligning · en fast kontrol af, om maskinerne stemmer med standarden.
- Ejer af afvigelser · en person, der vurderer, om en afvigelse skal rettes eller godkendes.
- Godkendte undtagelser · registreret med begrundelse og udløbsdato.
- Ændringer gennem processen · ændringer i standarden går gennem jeres ændringsstyring. → Testen i jeres ændringsstyring
Det skal I lade være med
- At rette maskinen og glemme skabelonen. Næste maskine får samme fejl.
- At ændre en central politik uden afprøvning. Fejlen rammer alle maskiner på én gang.
- At skrive standarden og aldrig kontrollere den. Maskinerne glider væk over tid.
- At lade manuelle ændringer stå uden registrering. De er de første, der går tabt ved næste opbygning.
- At glemme leverandørernes opsætning. Systemer, de installerer, følger ikke automatisk jeres standard.
- At melde rettelsen færdig før standarden er opdateret. Så er kun symptomet væk.
Hvad kan og ikke kan konkluderes
En opdateret standard, skabeloner med rettelsen og en kontrol af afvigelser viser, at fundet er rettet ved årsagen og ikke kun på den maskine, testeren nåede. Det viser ikke, at standarden er god nok mod andre svagheder, eller at alle maskiner faktisk følger den. Næste test kan vise, om de samme fund er væk, men den dækker også kun det, den når.
Tjekliste til permanente rettelser
- ☐ Er årsagen til hvert fund kendt: skabelon, politik, manuel ændring, leverandør eller tid?
- ☐ Er den rigtige indstilling skrevet ind i standardopsætningen?
- ☐ Er installationsbilleder, skabeloner og politikker opdateret?
- ☐ Er ændringen afprøvet, før den rulles ud til alle?
- ☐ Har eksisterende maskiner fået rettelsen, eller står de på en undtagelsesliste?
- ☐ Findes der en fast kontrol af afvigelser fra standarden?
- ☐ Er leverandørerne bedt om at følge standarden?
Kilder
- Microsoft Learn: Security baselines guide: en sikkerhedsbaseline er en samling anbefalede indstillinger med forklaret sikkerhedsbetydning; Microsoft anbefaler en kendt og afprøvet baseline frem for at lave sin egen.
- NIST SP 800-128: sikkerhedsfokuseret konfigurationsstyring, hvor systemernes konfiguration styres og overvåges som del af den almindelige konfigurationsstyring.
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler til IT-afdelingen
Læs også: Hærdning forklaret · Klientopsætningen under lup · Fund i systemer, som forretningen ejer
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT
