Hur blir vi snabbare på att patcha och samtidigt trygga med det vi gör? Jag tror att mycket avgörs långt innan nästa uppdatering finns att hämta. Vi behöver känna våra system, ha fattat de beslut som går att förbereda och ha byggt de kontroller som ska hjälpa oss när tiden blir knapp.
Här delar jag mina tankar om hur vi kan göra patchningen snabbare och tryggare. Vilka arbetssätt som passar behöver vi bedöma tillsammans, utifrån din verksamhet och de tjänster du har hos oss. Tripnets ansvar och mandat utgår från vårt avtal. Därför behöver vi vara tydliga med vem som bevakar sårbarheter, genomför uppdateringar, testar att applikationerna fungerar och fattar beslut när det är bråttom. Det kan vara vi, du eller din applikationsleverantör. Det viktiga är att inget hamnar mellan stolarna.
Gör riskbedömningen möjlig att använda
En lista över servrar räcker inte för att prioritera. Vi behöver veta vad de gör, vilken information de hanterar, hur de är exponerade och vilka andra system som är beroende av dem. Ett enkelt system kan vara en väg vidare till något betydligt känsligare. Därför behöver prioriteringen bygga på både risken med förändringen och risken med att vänta. Att ett system har fått etiketten ”affärskritiskt” säger inte tillräckligt om hur en viss uppdatering ska hanteras.
Min praktiska utgångspunkt är att förbereda olika arbetssätt för olika situationer. Återkommande uppdateringar med känd och begränsad påverkan kan hanteras som förhandsgodkända standardförändringar. Andra behöver en särskild bedömning. När sårbarheter redan utnyttjas behöver vi kunna fatta beslut snabbt och veta när frågan ska eskaleras.
Här har vårt CAB, Change Advisory Board, en viktig roll i att förbereda arbetssätten och bedöma förändringar. Målet är att ett Emergency CAB, ett e-CAB, ska behövas när situationen verkligen kräver det. Varje brådskande patch ska helst inte innebära att vi måste samla alla och börja om från början.
Håll efter patchskulden
Hur snabbt vi kan lägga på en akut säkerhetspatch beror också på vilket skick systemet är i när den kommer. Har vi tidigare bedömt att en uppdatering kan vänta behöver vi också fundera på vad det betyder för nästa uppdatering. Beroende på produkt och uppgraderingsväg kan man behöva gå igenom både större versionslyft och mindre uppdateringar innan den akuta rättningen går att installera. Då växer förändringen, fler beroenden behöver kontrolleras och arbetet kan ta längre tid. Allt detta när vi egentligen behöver agera snabbt.
– Problem kan uppstå om vi sitter med system där vi känner att vi har "good enoug" uppdatering och så visar det sig att vi snabbt behöver uppdatera flera minor eller Major releaser för att täppa till en sårbarhet, säger Robert Wemmenlöv, systemingenjör på Tripnet.
Det är det vi menar med patchskuld. Vi har skjutit arbete framför oss som kan behöva göras vid ett betydligt sämre tillfälle. Att avvakta med en enskild uppdatering kan vara ett genomtänkt beslut, men konsekvenserna behöver följas upp.
Därför behöver det löpande underhållet hålla systemen på en stödd och underhållen versionsnivå, med en känd väg till nya säkerhetsrättningar. Vi behöver veta vilka versioner vi kör, vilka uppgraderingssteg som kan krävas och vem som ansvarar för att de genomförs. Även det behöver ingå i överenskommelsen mellan oss, kunden och berörda leverantörer.
För mig är det här en viktig del av beredskapen. En del av arbetet med nästa akutpatch kan vi göra redan nu, medan vi fortfarande har tid att planera.
Vikten av autenticitet
NIS2 lyfter autenticitet vid sidan av tillgänglighet, riktighet och konfidentialitet. I patchningen blir det konkret: uppdateringen ska verkligen komma från den leverantör vi tror att den kommer från. Ursprunget ska gå att verifiera. Ju mer vi automatiserar, desto viktigare blir det att sådana kontroller finns inbyggda i flödet.
Vi behöver också kontrollera att uppdateringen inte har förändrats på vägen. Att automatiskt och snabbt installera fel programvara kan få stora konsekvenser. Därför behöver kontrollen av ursprung och innehåll vara en del av samma förberedelser som testerna och själva installationen.
Automatisera kontrollerna
Ett förberett flöde kan identifiera berörda system, kontrollera uppdateringens ursprung, köra tester i en representativ testmiljö och därefter uppdatera en begränsad del av produktionen. Utrullningen fortsätter om kontrollerna går igenom. På så sätt får vi ytterligare kontroll i produktionen efter de tester som ska göras före produktionssättning.
Testerna behöver kontrollera det verksamheten faktiskt använder. Att servern svarar säger ganska lite om tjänsten fungerar. Kan kunden fortfarande logga in, genomföra sin beställning och få sin integration att fungera?
Automatisera de viktiga kontrollerna och spara resultaten tillsammans med förändringen. Då blir det lättare att upptäcka fel och förstå vad som faktiskt hände om något avviker.
Testkraven följer med in i det snabbare arbetssättet
Cybersäkerhetslagen kräver lämpliga och proportionella säkerhetsåtgärder utifrån risk, bland annat för kontinuitet och säkerhet i leveranskedjan. Inom NIS2 finns också mer detaljerade krav för vissa digitala tjänsteleverantörer. De omfattar bland annat patchning inom rimlig tid, tester före produktionssättning och kontroll av patcharnas ursprung och integritet.
Det betyder att vi behöver ta reda på vilka krav som gäller för verksamheten och bygga flöden som uppfyller dem. Automation kan användas även i reglerade miljöer. En enklare rutin eller en riskacceptans innebär däremot inte i sig att ett uttryckligt testkrav försvinner.
Jag tror att en stor del av arbetet framåt handlar om att få de här kontrollerna att fungera snabbare och med mindre manuellt arbete. Vi behöver kunna genomföra dem även när tidsmarginalerna är små.
Bygg för underhåll – livepatchning kan komplettera
– Tror det är väldigt få scenarion där livepatchning faktiskt är relevant. Om tillgängligheten är så viktig att man inte klarar någon minuts nedtid så är inte livepatchning lösningen, utan då behöver systemet vara byggt för hög tillgänglighet, säger Björn Åberg, systemingenjör på Tripnet.
Om verksamheten har svårt att acceptera ens korta avbrott behöver vi börja med hur hela tjänsten är byggd. Kan en server tas ur drift för uppdatering medan andra tar över? Fungerar det även för applikationen, databasen och deras beroenden? Hög tillgänglighet behöver omfatta både planerat underhåll och oväntade fel.
Livepatchning kan vara ett komplement i vissa miljöer. På Linux handlar det ofta om att rätta utvalda sårbarheter i den körande kärnan och därmed minska exponeringen fram till nästa planerade omstart. Övriga uppdateringar och behovet av underhåll finns fortfarande kvar.
Hotpatch i Windows Server 2025 gör det möjligt att installera de säkerhetsuppdateringar som omfattas utan omstart. För Standard och Datacenter finns stöd via Azure Arc, förutsatt att kraven för funktionen är uppfyllda. Men omstarterna försvinner inte helt. Nya baslinjeuppdateringar kräver normalt omstart varje kvartal, och ytterligare omstarter kan behövas. Bland annat .NET, drivrutiner och firmware behöver hanteras separat.
Det är ett spännande område. Samtidigt tycker jag att stödet fortfarande är mer begränsat än man skulle önska. Vi behöver titta på vad som fungerar i den aktuella miljön och vilka uppdateringar som faktiskt omfattas.
På Linux-sidan är Canonicals Livepatch för Ubuntu ett exempel. Det åtgärdar utvalda kritiska och allvarliga sårbarheter i Linuxkärnan medan systemet körs. Det omfattar inte hela systemet. Bibliotek och applikationer behöver fortfarande uppdateras på andra sätt.
Exempel på teknik som kan minska behovet av omstarter
Tabellen nedan visar exempel på tekniska möjligheter. Den ska inte läsas som att lösningarna ingår i Tripnets ordinarie leverans eller att vi rekommenderar dem för alla system. Om någon av dem är lämplig behöver vi bedöma utifrån den aktuella miljön, nyttan, supporten och hur lösningen passar in i vår överenskomna förvaltning.
| Operativsystem | Lösning | Möjlighet | Kvar att hantera |
|---|---|---|---|
| Windows Server 2025 | Microsoft Hotpatch | Säkerhetsuppdateringar som omfattas kan installeras utan omstart. Stöd finns för Standard och Datacenter via Azure Arc. | Baslinjeuppdateringar kräver återkommande omstarter. Bland annat .NET, drivrutiner och firmware hanteras separat. |
| Ubuntu LTS | Canonical Livepatch, via Ubuntu Pro | Utvalda kritiska och allvarliga sårbarheter i Linuxkärnan kan rättas under drift. | Kräver en kärna som stöds. Bibliotek, applikationer och övriga uppdateringar hanteras separat. |
| Red Hat Enterprise Linux, RHEL | Red Hats kernel live patching, med kpatch | Utvalda säkerhetsrättningar kan installeras i den körande kärnan utan omstart. | Täcker inte alla allvarliga kärnsårbarheter. Stödet beror på kärnversion och dess supportperiod. Applikationer och bibliotek hanteras separat. |
| SUSE Linux Enterprise Server, SLES | SUSE Linux Enterprise Live Patching | Utvalda kärnsårbarheter och vissa stabilitetsproblem kan rättas under drift. SUSE erbjuder även livepatchning för vissa bibliotek. | Kräver rätt prenumeration och stödda versioner. Alla rättningar omfattas inte, och vanliga uppdateringar och omstarter behövs fortfarande. |
| Oracle Linux | Oracle Ksplice | Säkerhetsrättningar för stödda kärnor kan installeras utan omstart. Kan även rätta vissa sårbarheter i glibc och OpenSSL under drift. | Kräver tillgång till Ksplice, exempelvis genom Premier Support eller OCI. Täcker inte alla bibliotek, applikationer eller uppdateringar. |
| Debian | Exempelvis TuxCare KernelCare, en tredjepartstjänst | Kärnor som omfattas av tjänstens stöd kan få säkerhetsrättningar utan omstart. | Kontrollera exakt Debianversion, kärna och arkitektur. Övriga uppdateringar och eventuella tjänsteomstarter hanteras separat. |
| Rocky Linux | Exempelvis TuxCare KernelCare, en tredjepartstjänst | Säkerhetsrättningar kan installeras i stödda kärnor under drift. | Kontrollera version och kärna mot tjänstens supportlista. RHEL-kompatibilitet innebär inte automatiskt tillgång till Red Hats livepatchar eller support. |
| AlmaLinux | Exempelvis TuxCare KernelCare, en tredjepartstjänst | Säkerhetsrättningar kan installeras i stödda kärnor utan omstart. | Kräver separat tjänst och stöd för den aktuella kärnan. Bibliotek, applikationer och övriga uppdateringar hanteras separat. |
De här möjligheterna kan minska konflikten mellan snabb patchning och tillgänglighet. Uppdateringen kan fortfarande påverka hur systemet fungerar. Tester och uppföljning behövs även när omstarten kan undvikas.
Planera även för när något går fel
Innan vi rullar ut behöver vi veta vilka fel som ska stoppa fortsatt utrullning och vad vi gör då. I vissa fall kan återställning automatiseras. I andra måste vi först förstå hur data och beroenden har påverkats, eller om uppdateringen har ändrat databasen på ett sätt som gör det svårt att backa.
Att backa en patch kan också öppna sårbarheten igen. Återställningsplanen behöver därför innehålla ett sätt att skydda systemet under tiden.
Hotpatch är heller inget löfte om automatisk återställning. Microsoft anger att automatisk rollback inte stöds för Windows Server Hotpatch. Om en uppdatering orsakar problem behöver den avinstalleras och den senaste fungerande baslinjen installeras. Det kräver omstart. Det är en sådan begränsning vi behöver känna till när vi utformar processen.
Patchtisdagarna har aldrigt varit hela sanningen
Linuxdistributioner och många applikationer publicerar säkerhetsuppdateringar löpande. Debian beskriver till exempel ett flöde där rättningar testas, paketeras och publiceras när de är klara. Vår bevakning behöver därför följa de program vi faktiskt använder. Ett månatligt underhållsfönster räcker inte som enda sätt att upptäcka och hantera nya risker.
Publiceringen kan dessutom ge ledtrådar till angripare. I WordPress-fallet som jag tar upp i huvudartikeln var kodrättningen synlig ungefär en och en halv timme före själva versionssläppet. Det gäller inte generellt för all öppen källkod. Samordnad publicering och embargo, där information hålls tillbaka under en överenskommen tid, förekommer också.
Även kompilerade uppdateringar till sluten programvara kan analyseras. Vi behöver känna till våra leverantörers arbetssätt och kunna agera när informationen blir offentlig.
Börja med en överenskommelse som går att genomföra
Ett bra nästa steg är att välja en tjänst och gå igenom hela kedjan tillsammans: kundens prioriteringar, leverantörernas ansvar, vad som ska testas, vem som beslutar och hur vi återställer. Då märker vi var tiden försvinner och vilka moment som går att förbereda eller automatisera. Därifrån kan vi förbättra fler tjänster.
Det är så jag tror att vi får både högre tempo och större trygghet. Vi bygger förmågan medan vi har arbetsro och använder den när det är bråttom.
Läs också När det blir farligare att vänta än att patcha, om avvägningen mellan tillgänglighet, riktighet och konfidentialitet och samtalen vi behöver föra med våra kunder.
