Patch

Også kendt som: sikkerhedsopdatering, opdatering, rettelse

Et lille stykke software fra en leverandør, der retter en fejl - ofte en sårbarhed - i et program, som allerede er installeret.

Kladde - dette opslag er endnu ikke gennemgået.

Sådan kommer du i gang

De typiske trin i rækkefølge. Tilpas dem til jeres organisation.

Når en patch udkommer, så læs leverandørens sikkerhedsmeddelelse, og notér, hvilke versioner den retter, om fejlen allerede udnyttes, om den kræver genstart, og om der er kendte problemer.
Find alle maskiner og enheder i jeres oversigt, der kører en berørt version, også servere, appliances og systemer, som leverandører driver.
Fastsæt fristen ud fra risikoen, fx inden for få dage, hvis fejlen står i CISA's KEV-katalog eller systemet vender mod internettet, og ellers i den næste faste cyklus.
Tag backup eller snapshot af kritiske systemer, og aftal et servicevindue og en plan for at rulle tilbage med systemejeren, før I installerer.
Installér først patchen på en pilotgruppe, tjek, at de vigtigste funktioner stadig virker, og rul den derefter ud i ringe til resten.
Genstart maskinerne, hvor patchen kræver det, og bekræft med en sårbarhedsscanning eller opdateringsværktøjets rapport, at den nye version faktisk kører.
Hvis patchen ikke kan installeres i tide, så brug leverandørens workaround, eller bloker adgangen til den sårbare funktion, og registrér undtagelsen med en ejer og en slutdato.
Luk opgaven i ændringsloggen med, hvad der blev patchet, hvornår og af hvem, og følg op på maskiner, hvor det fejlede.

Typiske faldgruber

At markere en patch som færdig, når den er udrullet, selv om maskinen ikke er genstartet og stadig kører den gamle kode.
At anvende workarounden og glemme den egentlige rettelse, så systemet igen er sårbart, når workarounden fjernes.
At hente patches fra uofficielle sider eller usignerede kilder, som kan levere malware i stedet for en rettelse.

Gode vejledninger

Opdater programmer løbende(åbner i en ny fane) · Styrelsen for Samfundssikkerhed
Known Exploited Vulnerabilities Catalog(åbner i en ny fane) · CISA (på engelsk)
Create a deployment plan - Windows updates(åbner i en ny fane) · Microsoft (på engelsk)

Teknisk uddybning

Teknisk spænder en patch fra en bogstavelig diff, der anvendes på kildekode (det samlede diff-format fra diff/patch og git), over en binær delta og en ny pakkeversion til en kumulativ opdatering. Windows udsender nu månedlige kumulative opdateringer, så hver enkelt indeholder alle tidligere rettelser, og maskiner kan ikke selektivt springe én over; Linux-distributioner udsender genbyggede pakker og backporter ofte en sikkerhedsrettelse til en ældre upstream-version, hvilket er grunden til, at en sårbarhedsscanner, der kun sammenligner versionsnumre, giver falske positiver på RHEL eller Debian. Firmware, BIOS/UEFI, netværksudstyr og indlejrede enheder har deres egne, ofte manuelle, opdateringskanaler og er dem, der oftest bliver glemt.

Microsofts Patch Tuesday, anden tirsdag i hver måned, stammer fra 2003 og er i lignende form overtaget af Adobe, SAP og andre; Oracle bruger kvartalsvise Critical Patch Updates. Ekstraordinære udgivelser følger ved aktivt udnyttede fejl. Udgivelsen starter et kapløb, fordi angribere sammenligner patchede og upatchede binære filer for at finde sårbarheden (patch diffing) og nogle gange har fungerende exploits klar inden for få dage. Prioritering bør derfor ikke hvile på CVSS-basisscoren alene (CVSS v4.0 kom i november 2023), men kombinere den med tegn på udnyttelse, fx CISA's Known Exploited Vulnerabilities-katalog, som amerikanske føderale myndigheder efter Binding Operational Directive 26-04 (juni 2026, der afløste BOD 22-01) skal afhjælpe inden for en frist, der fastsættes for hver CVE ud fra eksponering, udnyttelighed og konsekvens og kan være helt ned til tre dage, med sandsynlighedsestimater som EPSS og med aktivets eksponering.

NIST SP 800-40 Rev. 4 (april 2022) beskriver patching som forebyggende vedligehold med en fastlagt risikohåndtering for hver aktivklasse: patch inden for en vedligeholdelsesplan, kør en nødcyklus ved alvorlige udnyttede fejl, afbød med konfiguration eller netværkskontroller, når der ikke findes en patch, eller accepter og dokumenter restrisikoen. En moden proces har en opdateret aktivfortegnelse, testringe (pilot, bred udrulning, kritiske systemer), planer for tilbagerulning, servicevinduer aftalt med forretningen og efterfølgende verifikation via scanning eller konfigurationsstyring, fordi "udrullet" ikke er det samme som "installeret og genstartet". ISO/IEC 27001:2022 kontrol 8.8 (håndtering af tekniske sårbarheder) er det sædvanlige revisionsankerpunkt, og NIS2 art. 21, stk. 2, litra e, kræver håndtering og offentliggørelse af sårbarheder som en del af foranstaltningerne til styring af cybersikkerhedsrisici.

Reguleringen når nu også leverandørsiden. Efter EU's Cyber Resilience Act (forordning (EU) 2024/2847) skal producenter af produkter med digitale elementer fra 11. september 2026 underrette deres CSIRT og ENISA om aktivt udnyttede sårbarheder og alvorlige hændelser (tidlig varsling inden for 24 timer), mens pligten til at levere gratis sikkerhedsopdateringer i hele en oplyst supportperiode gælder sammen med hovedkravene fra 11. december 2027. Patches kan også selv være angrebsvejen: kompromitteret opdateringsinfrastruktur leverede malware i NotPetya (via M.E.Doc, 2017) og SolarWinds Orion (2020), og derfor skal opdateringer være signerede og signeringsnøglerne beskyttede. En patch retter en fejl; en workaround eller afbødning mindsker kun eksponeringen og bør følges, indtil den egentlige rettelse er installeret.

Relationer

Åbner for: Patch management Zero-day-sårbarhed
Afbøder: Sårbarhed
Bruges sammen med: Sårbarhedsscanning Styresystem

Kilder og videre læsning

Standarder og officielle tekster

NIST SP 800-40 Rev. 4, Guide to Enterprise Patch Management Planning · NIST

Officiel dokumentation

Cyber Resilience Act - policy page · European Commission
BOD 26-04 - Prioritizing Security Updates Based on Risk · CISA

Hvor dataene kommer fra

Dette opslag er skrevet af en AI ud fra kilderne ovenfor og er endnu ikke gennemgået af et menneske. Brug det som udgangspunkt, og tjek alt vigtigt mod kilderne.

Se gennemgangskøen Foreslå en rettelse på GitHub Dette begreb som JSON

Nævnt i

Kerne (kernel)Hypervisor Infrastructure as a service (IaaS)Angrebsflade CVE og CVSS Cyberrobusthedsforordningen (CRA)Exploit IT-drift Legacy-system Risikohåndtering Sikkerhedsmåling (KPI'er)

Test dig selv

Indlæser…