Næsten hver intern test giver fund om manglende opdateringer. Det fristende er at behandle dem som en liste: installer det, der mangler, og sæt flueben. Men en manglende opdatering er ikke nødvendigvis bare en glemt opgave. Den er et tegn på, at noget i processen ikke virker, og det er det, der skal rettes, hvis fundet ikke skal komme igen. Svaret på, hvad testen viser, hviler derfor på mønstret i fundene: hvilke systemer mangler opdateringer, hvor længe, og hvorfor.
Hvorfor opdateringer ikke gør testen overflødig, er beskrevet for køberen på penetrationtest.dk. Her er det driftens spørgsmål: hvad siger fundene om jeres proces?
Hvad testen ser, og hvad den ikke ser
En penetrationstest er ikke en fuld opgørelse over opdateringer. Den ser de systemer, der var i scope og tændt i testperioden, og den ser dem udefra eller fra den position, testeren havde. Den kan konstatere, at et system har en version med kendte svagheder, og i nogle tilfælde, at svagheden kan udnyttes.
Det, testen ikke ser, er lige så vigtigt. Maskiner, der var slukket, systemer uden for scope og programmer, der ikke er synlige over nettet, er ikke med. NCSC beskriver penetrationstest som en måde at få sikkerhed for, at jeres egne processer for sårbarheder virker, ikke som den primære måde at finde dem på. Et fund om manglende opdatering er derfor også en besked om, at jeres egen overvågning ikke fangede det først. → Scanning mellem testene
Det kan I forberede
Testen giver mest, når I selv har et bud på status, før den begynder. Så kan rapporten vise forskellen mellem det, I troede, og det, testeren fandt.
- En aktuel status · træk en opgørelse fra jeres eget opdateringssystem over klienter og servere, og notér, hvor gammel den er.
- Kendte undtagelser · systemer, der bevidst ikke opdateres, med begrundelse. Testeren skal stadig rapportere dem, men kan skrive dem som kendte.
- Planlagte opdateringer · hvis der opdateres i testperioden, skal testeren vide det. Ellers kan et fund forsvinde eller opstå undervejs uden forklaring.
- Udstyr uden for processen · lister over netværksudstyr, apparater og systemer, som andre end IT opdaterer.
NCSC anbefaler, at en aktuel sårbarhedsvurdering deles med testerne, så de kan vurdere, om den er præcis og fuldstændig. Det er netop den kontrol af jeres egen proces, der gør testen værdifuld.
Mønstre i fundene
Læs fundene om opdateringer som en gruppe, ikke som enkeltstående punkter. Typiske mønstre peger på hver sin årsag.
- Én servertype mangler · fx alle servere med et bestemt fagsystem. Årsagen kan være, at opdateringer er undtaget, fordi leverandøren skal godkende dem.
- Tredjepartsprogrammer mangler · styresystemet er opdateret, men programmer fra andre leverandører er ikke. Processen dækker kun en del af softwaren.
- Enkelte maskiner er langt bagud · de står uden for den centrale styring, er glemt eller har fejlet stille. → Enheder uden ejer
- Opdateringen er installeret, men ikke aktiv · en genstart mangler, eller en indstilling skal ændres, før rettelsen virker.
- Systemer uden support · der kommer ingen opdateringer, fordi producenten er holdt op. → Servere og styresystemer uden support
- Netværksudstyr og apparater · firmware på switche, printere og andet udstyr er måske ikke med i processen.
Hvert mønster har sin egen rettelse, og måske også sin egen ejer: driftsleverandøren, fagsystemets leverandør eller den afdeling, der har købt udstyret. Det er derfor, rapportens enkelte fund skal oversættes til årsager, før der planlægges.
Hvad en god proces dækker
NIST beskriver opdateringer som forebyggende vedligeholdelse og deler arbejdet op i at identificere, prioritere, anskaffe, installere og kontrollere. Fundene fra testen kan placeres på de led.
- Identificere · ved I, hvilke systemer og programmer I har, og hvem der ejer dem? NCSC lægger vægt på netop den oversigt.
- Prioritere · har I en måde at afgøre, hvad der skal opdateres først? CISA vedligeholder en liste over sårbarheder, der vides at blive udnyttet, og anbefaler, at den indgår i prioriteringen.
- Anskaffe og installere · når opdateringen faktisk ud til alle systemer, også dem uden for standardprocessen?
- Kontrollere · kontrolleres det bagefter, at opdateringen er installeret og virker?
Et fund om en manglende opdatering kan føres tilbage til et af de fire led. Er det det første, mangler I overblik. Er det det sidste, mangler I kontrol.
Når opdateringen ikke kan installeres
Nogle systemer kan ikke opdateres med det samme. Fagsystemer kræver godkendelse fra leverandøren, produktionsudstyr kan ikke genstartes, og ældre systemer har ingen opdatering at få.
NCSC skriver, at en beslutning om ikke at opdatere er en risikobeslutning, som hører til et ledelsesniveau. For IT-afdelingen betyder det, at undtagelsen skal skrives ned med en begrundelse, en ejer og en dato, og at den skal ledsages af andre tiltag, fx afskærmning af systemet. → Når et system ikke kan opdateres
Sådan bruger I fundene
- Grupper fundene efter årsag · ikke efter system. Én rettelse i processen kan lukke mange fund.
- Ret det akutte først · sårbarheder, der vides at blive udnyttet, og systemer, der kan nås udefra, går forrest. → Advarsel om kendt sårbarhed
- Ret processen bagefter · udvid opdateringerne til tredjepartsprogrammer, find maskinerne uden for styringen, og indfør kontrol.
- Registrer undtagelserne · systemer, der ikke kan opdateres, får en skriftlig beslutning.
- Sæt det i opgavesystemet · både de konkrete opdateringer og ændringerne i processen. → Fund ind i opgavesystemet
Det skal I lade være med
- At installere de manglende opdateringer og stoppe der. Processen, der lod dem mangle, er uændret.
- At tro, at testen har set alt. Den har set de systemer, der var tændt og i scope.
- At glemme tredjepartsprogrammer og udstyr. De kan falde uden for den faste proces.
- At lade undtagelser leve uden dato. En undtagelse uden ejer bliver permanent.
- At sætte lighedstegn mellem opdateret og sikker. Opsætning og rettigheder rettes ikke af en opdatering. → Forældede komponenter og biblioteker
Hvad kan og ikke kan konkluderes
Testen viser, hvilke af de undersøgte systemer der manglede opdateringer i testperioden, og hvilke mønstre fundene danner. Den viser ikke den samlede status for alle systemer og kan ikke garantere, at systemer uden fund er opdaterede. Et resultat uden fund om opdateringer gælder kun den dag og de systemer, testen så.
Tjekliste til opdateringsprocessen
- ☐ Har I en oversigt over systemer og programmer med en ejer for hver?
- ☐ Dækker processen også tredjepartsprogrammer, firmware og netværksudstyr?
- ☐ Har I en måde at prioritere sårbarheder, der vides at blive udnyttet?
- ☐ Kontrolleres det, at opdateringer faktisk er installeret og aktive?
- ☐ Har systemer, der ikke kan opdateres, en skriftlig beslutning og en dato?
- ☐ Er maskiner uden for den centrale styring fundet og håndteret?
Kilder
- NIST SP 800-40 Rev. 4: Guide to Enterprise Patch Management Planning: opdateringer som forebyggende vedligeholdelse; at identificere, prioritere, anskaffe, installere og kontrollere.
- NCSC: Vulnerability management: opdatering som udgangspunkt, oversigt over systemer og ejere, prioritering, og at en beslutning om ikke at opdatere er en risikobeslutning på ledelsesniveau.
- CISA: Known Exploited Vulnerabilities Catalog: den amerikanske myndigheds liste over sårbarheder, der vides at være udnyttet, og anbefalingen om at bruge den i prioriteringen.
- NCSC: Penetration testing: penetrationstest som sikkerhed for egne processer for sårbarheder.
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler til IT-afdelingen
Læs også: Scanning mellem testene · Servere som testområde
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT
