Patchstyring

Patchstyring er processen med at identificere, teste og installere softwareopdateringer for at lukke sikkerhedssårbarheder. Manglende patches er en af de hyppigste årsager til succesfulde cyberangreb og kan undgås med en struktureret proces.

Tilbage til ordbog

Hvad er patchstyring?

En patch er en softwareopdatering, der retter fejl, lukker sikkerhedssårbarheder eller forbedrer funktionalitet. Patchstyring (patch management) er den strukturerede proces, der sikrer, at patches identificeres, testes, godkendes og installeres rettidigt på alle relevante systemer.

Manglende patching er en af de mest udnyttede angrebsvektorer. Mange af de store cyberangreb i historien udnyttede kendte sårbarheder, hvor patches havde været tilgængelige i uger eller måneder. Sårbarhedsscanning afslører disse mangler, men kun patchstyring lukker dem.

Patchstyring hænger tæt sammen med konfigurationsstyring (hold styr på, hvad der er installeret), endpoint-sikkerhed (beskyt endpoints mod udnyttelse) og overvågning (opdage forsøg på udnyttelse af upatched systemer).

Patch management-processen

En struktureret patch management-proces inkluderer:

Inventar: Kend alle systemer og software i organisationen. Du kan ikke patche, hvad du ikke ved eksisterer. Konfigurationsstyring og CMDB er fundamentet.
Identifikation: Overvåg leverandørers udgivelser og sikkerhedsmeddelelser. Sårbarhedsscanning identificerer systemer med manglende patches.
Vurdering: Prioritér patches baseret på sårbarhedens alvorlighed (CVSS-score) og systemets kritikalitet.
Test: Test patches i et testmiljø for at sikre kompatibilitet med eksisterende applikationer. Særligt vigtigt for forretningskritiske systemer.
Udrulning: Installér patches efter en fastlagt plan. Brug automatiserede værktøjer til endpoints og planlagte vedligeholdelsesvinduer til servere.
Verifikation: Kontrollér, at patches er installeret korrekt. Scanning efter patching verificerer, at sårbarhederne faktisk er lukket.

Prioritering

Ikke alle patches er lige kritiske. En riskobaseret tilgang sikrer, at de vigtigste patches installeres først:

Kritisk (CVSS 9.0-10.0): Sårbarheder, der kan udnyttes remote uden autentificering og giver fuld kontrol over systemet. Patchning inden for 24-72 timer. Hvis patching ikke er mulig, implementér kompenserende kontroller som netværkssegmentering.

Høj (CVSS 7.0-8.9): Alvorlige sårbarheder med begrænsede betingelser for udnyttelse. Patchning inden for en uge.

Medium (CVSS 4.0-6.9): Sårbarheder med moderat risiko. Patchning inden for 30 dage via den normale patch-cyklus.

Lav (CVSS 0.1-3.9): Sårbarheder med begrænset påvirkning. Patchning i næste planlagte vedligeholdelsesvindue.

Brug trusselsintelligens til at justere prioriteringen. En sårbarhed med lav CVSS-score, der aktivt udnyttes, bør prioriteres højere end scoren alene tilsiger.

Regulativer og standarder

CIS 18 adresserer patchstyring i kontrol 7 (kontinuerlig sårbarhedsstyring), med krav om at identificere og patche sårbarheder rettidigt.

ISO 27001 og Annex A inkluderer kontrol A.8.8 om styring af tekniske sårbarheder. Et ISMS bør definere en patchstyringspolitik som en del af de tekniske og organisatoriske foranstaltninger.

NIS2 kræver, at organisationer håndterer sårbarheder proaktivt. DORA stiller konkrete krav til patchstyring af finansielle institutioners IKT-systemer. Under GDPR er patchstyring en grundlæggende foranstaltning til beskyttelse af persondata.

Ofte stillede spørgsmål om patchstyring

Hvor hurtigt bør man installere patches?

Kritiske sikkerhedspatches bør installeres inden for 24-72 timer. Høj-risiko patches inden for en uge. Medium og lav-risiko patches inden for 30 dage. Prioritering bør baseres på sårbarhedens alvorlighed og systemets kritikalitet.

Hvad gør man, hvis en patch ikke kan installeres?

Hvis en patch ikke kan installeres med det samme (f.eks. på grund af kompatibilitetsproblemer), bør du implementere kompenserende kontroller. Det kan være netværkssegmentering, yderligere overvågning eller midlertidig deaktivering af den sårbare funktion.

Skal man teste patches før installation?

Ja, på kritiske systemer bør patches testes i et testmiljø først. Test at forretningskritiske applikationer fungerer korrekt efter patching. For endpoints kan man rulle patches ud til en pilotgruppe først.