Penetration-test

Klar til retest: IT’s egen kontrol af rettelserne

Klar til retest: IT's egen kontrol af rettelserne

En retest bliver brugt bedst, når den bekræfter rettelser, IT allerede har kontrolleret, og ikke når den finder ud af, at en ændring aldrig nåede produktionen. Før testeren kommer igen, kan driften derfor gennemgå hver rettelse selv. Kontrollen hviler på fire spørgsmål pr. fund: er ændringen gennemført i det miljø, der blev testet, dækker den alle forekomster, er forholdene de samme som ved testen, og kan I vise, hvad der er gjort? Hvad en retest omfatter, og hvordan den bestilles, er beskrevet for køberen på penetrationtest.dk. Her handler det om IT’s forberedelse.

Hvorfor IT skal kontrollere først

En melding om, at noget er rettet, er ikke det samme som en rettelse, der virker. Ændringen kan være lavet i testmiljøet og ikke i produktionen. Den kan være lavet på én server, mens fundet gjaldt fem. Den kan være rullet tilbage under en fejlfinding uden at nogen opdagede det.

Den amerikanske standardorganisation NIST beskriver i sin vejledning om patchstyring, at en gennemført ændring skal kontrolleres for at bekræfte, at den er installeret og har virkning, og at det bagefter skal overvåges, at den ikke er fjernet igen, fx ved en gendannelse fra backup eller en nulstilling af en enhed. Det gælder også rettelser af opsætning og rettigheder.

Hvis IT selv har kontrolleret, bliver retesten en bekræftelse. Den egne kontrol giver også et bedre billede af, hvor langt rettelserne er nået, når ledelsen spørger. Hvis ikke, kan den blive den første kontrol, og så er tiden brugt på at finde det, driften kunne have set selv.

Gennemgå listen fund for fund

Tag udgangspunkt i sagerne i jeres sagssystem, ikke i hukommelsen. → Fra fund til opgave

For hvert fund, der skal med i retesten, gennemgås fem punkter.

  1. Ændringen er i drift · den er gennemført i det miljø, testen gjaldt, ikke kun i et testmiljø.
  2. Alle forekomster · fundet gjaldt måske flere systemer, end rapporten nævnte ved navn. Er de andre også rettet?
  3. Ændringen er der stadig · den er ikke rullet tilbage, overskrevet af en central politik eller fjernet ved en opdatering.
  4. Virkningen er den ønskede · det, fundet beskrev, er ikke længere muligt fra de udgangspunkter, testen brugte, så vidt IT kan se det uden at gentage testen.
  5. Dokumentation · sagen viser, hvad der er ændret, hvornår og af hvem.

Punkt 4 kræver omtanke. IT skal ikke efterligne testeren. Kontrollen kan bestå i at se i opsætningen, at en indstilling er ændret, at en adgang er lukket i firewallen, eller at en konto ikke længere er medlem af en gruppe. Det er nok til at vide, at der er noget at bekræfte. Hvis kontrollen viser, at en rettelse ikke er på plads, er det bedre at opdage det nu end i retestens rapport. Så kan I enten nå at rette eller tage fundet ud af retesten og flytte det til en senere runde.

Samme forhold som ved testen

En retest kan kun sige noget om den oprindelige svaghed, hvis den gentages under forhold, der svarer til den første test. Samme organisations vejledning om sikkerhedstest bemærker, at et testhold kun kan bekræfte en rettelse, hvis den oprindelige test gentages. Det stiller krav til driften.

  • Testkonti · findes de samme roller igen, eller skal der oprettes nye med samme rettigheder?
  • Udgangspunkt · kan testeren komme ind fra det samme sted, fx det samme net eller den samme fjernadgang?
  • Undtagelser · skal de samme undtagelser i firewall og overvågning genetableres, og er de registreret? → Midlertidige undtagelser til testen
  • Ændringer siden · er der sket ændringer i miljøet, som testeren skal kende, fx nye systemer eller flyttede servere?

Hvis forholdene er ændret, så skriv det på listen til testeren. Nogle ændringer er netop rettelser: en adgangsvej, der er lukket, eller en rolle, der er fjernet. Det skal fremgå, så testeren ikke bruger tid på at lede efter et udgangspunkt, der med vilje er væk, og så rapporten kan beskrive resultatet korrekt. En rettelse, der er kontrolleret under andre forhold, er et andet resultat end en rettelse, der er kontrolleret under de samme.

Skel mellem rettet, afhjulpet og åbent

Listen til testeren skal være ærlig om status. Del fundene i tre grupper.

  • Rettet · årsagen er fjernet, og IT har kontrolleret det.
  • Afhjulpet · der er indført et midlertidigt tiltag, men svagheden findes stadig. → Midlertidige afhjælpninger
  • Åbent · intet er gjort endnu, eller fundet er accepteret.

Fund i de to sidste grupper skal ikke præsenteres som rettede. Hvis de er med i retesten, er det for at få bekræftet, at det midlertidige tiltag virker, eller for at få en opdateret vurdering.

Listen til testeren

Saml resultatet i én liste, som testeren får før retesten. Den sparer tid og gør resultatet lettere at læse.

  • Fundnummer og titel · som i den oprindelige rapport.
  • Status · rettet, afhjulpet eller åbent.
  • Hvad der er gjort · kort, i almindelige ord.
  • Berørte systemer · alle forekomster, også dem, rapporten ikke nævnte.
  • Ændrede forhold · alt, der kan påvirke, om retesten kan gentage den første test.

Send listen i god tid, så testeren kan nå at spørge, hvis noget er uklart, og så omfanget af retesten kan aftales ud fra den. Ryd også op i spor fra den første test, før retesten begynder. Gamle testkonti, der stadig er aktive, gør det sværere at se, hvad der er nyt. → Oprydning efter testen

Det skal I lade være med

  • At melde rettet ud fra en sag, der er lukket. Se i opsætningen.
  • At kontrollere én forekomst og antage resten. Fund kan gælde flere systemer.
  • At præsentere et midlertidigt tiltag som rettet. Testeren kan stadig finde svagheden.
  • At ændre forholdene uden at sige det. Så kan resultatet ikke sammenlignes.
  • At efterligne testeren. IT’s kontrol handler om opsætning og dokumentation.

Hvad kan og ikke kan konkluderes

IT’s egen kontrol viser, at ændringerne er gennemført og dokumenteret, så vidt driften kan se det. Den er ikke en uafhængig bekræftelse af, at svagheden er væk. Det er retestens opgave. Retesten kan til gengæld kun sige noget om de fund og forhold, den omfatter, og den kan ikke udelukke nye svagheder, der er opstået siden den første test. → Fremdrift på rettelserne

Tjekliste før retesten

  • ☐ Er hver rettelse gennemført i det miljø, testen gjaldt?
  • ☐ Er alle forekomster af hvert fund rettet?
  • ☐ Er det kontrolleret, at ændringerne ikke er rullet tilbage?
  • ☐ Er testkonti, udgangspunkt og undtagelser klar som ved første test?
  • ☐ Er ændrede forhold skrevet på listen?
  • ☐ Er fundene delt i rettet, afhjulpet og åbent?
  • ☐ Har testeren fået listen i god tid?

Kilder

  • NIST SP 800-115, afsnit 8.3: rettelser kontrolleres ved gennemgang af systemet eller ved retest, og testholdet kan kun bekræfte en rettelse, hvis den oprindelige test gentages.
  • SP 800-40 Rev. 4, afsnit 2.2 og 2.3: en ændring skal kontrolleres for at være gennemført og have virkning, og det skal overvåges, at den ikke fjernes igen, fx ved gendannelse fra backup.

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Artikler til IT-afdelingen

Læs også: Fra fund til opgave · Rettelser uden at stoppe driften

→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT

Skrevet af John Nielsen, indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Om John Nielsen · LinkedIn

John Nielsen, Nielco IT

Skal jeres miljø testes?

Fortæl kort, hvilke dele af jeres miljø der skal testes, og hvornår I skal bruge resultatet. Så vender jeg tilbage. Testen og rådgivningen er uvildige og uafhængige, og Nielco IT har ikke indgået forhandleraftaler med leverandører.

Tak for din henvendelse. Jeg vender tilbage hurtigst muligt.