Vi har länge varit bra på att fråga vad som kan gå fel när vi installerar en uppdatering. Jag tror att vi framöver behöver ägna betydligt mer tanke åt frågan: vad kan gå fel medan vi väntar? Tiden från att en sårbarhet upptäcks tills någon försöker utnyttja den kan vara kort. När tiden mellan en släppt patch och de första angreppen kan räknas i minuter behöver både tekniken och våra arbetssätt hänga med. Några av de viktigaste besluten behöver redan vara fattade tillsammans med våra kunder, långt innan det blir bråttom.
Vi hade en rutin som fungerade
För ungefär 30 år sedan hörde man ofta uttrycket ”Don’t fix what’s working”. Fungerade systemet så lät man det vara. Varje förändring kunde ju ställa till något. Den inställningen slängde vi ut för många år sedan. Ett system kan fungera alldeles utmärkt och samtidigt ha en sårbarhet som gör det möjligt för någon annan att ta sig in.
Sedan fick vi en rutin som fungerade ganska bra. Microsoft släppte sina ordinarie säkerhetsuppdateringar den andra tisdagen i månaden, Patch Tuesday. På Tripnet patchade vi tidigare ofta Microsoftservrar veckan efter. Då hann andra upptäcka barnsjukdomarna. Vi hann läsa på, bedöma konsekvenserna, testa och informera kunderna. Det fanns en rytm som gjorde arbetet både förutsägbart och tryggt. Behövde en allvarlig sårbarhet åtgärdas akut patchade vi förstås snabbare, men i övrigt var det en bekväm princip. Månadscykeln, med en regelbunden genomgång av systemen, var lätt att tillämpa även på andra system.
Nu har vi lagt den generella väntan bakom oss. Vi patchar snabbare, utifrån vilka system det handlar om, kundernas behov och hur allvarliga sårbarheterna är. Min känsla är att vi behöver fortsätta förändra det här. En princip som tjänat oss väl behöver göras om när förutsättningarna ändras.
För enklare system, där en förändring har begränsade konsekvenser och återställningen är väl förberedd, kan automatisk patchning vara det rimliga förstahandsvalet. Det kan gå både fortare och bli enklare än att göra en ny detaljanalys av varje uppdatering. Bedömningen av vilka system och uppdateringar som lämpar sig för det behöver förstås redan vara gjord. Och där särskilda krav på testning och dokumentation gäller måste arbetssättet uppfylla dem.
Vad hinner man göra på 90 minuter?
I somras beskrev säkerhetsforskaren Adam Kues på Searchlight Cyber hur han med hjälp av GPT5.6 Sol Ultra hittade en kedja av sårbarheter i WordPress kärna. Han undersökte, verifierade och rapporterade fyndet till WordPress. Det var alltså säkerhetsforskning med hjälp av AI.
Det som verkligen fick mig att stanna upp var vad som hände när rättningen släpptes. Enligt säkerhetsföretaget Patchstack registrerades de första försöken att utnyttja sårbarheterna ungefär 90 minuter efter att WordPress 7.0.2 publicerades den 17 juli. Deras observationer gäller blockerade angreppsförsök, inte bekräftade intrång. Men de visar hur snabbt någon började försöka.
Nittio minuter. Hur mycket analys och förändringsplanering hinner man med på den tiden? Ett möte och lite kaffe? Själv hade jag semester och låg och sov medan mitt system patchades automatiskt. När jag vaknade fick jag en rapport om vad som hade fixats.
Det är oerhört enkelt att plocka isär en patch och hitta sårbarheten. AI är inte bara vårt verktyg för att hitta sårbarheter och täppa till dem, utan också ett verktyg för den mörka sidan. För mig är slutsatsen att vi måste bygga vår förmåga att agera inom betydligt kortare tidsfönster. Nästa vecka är inte tillräckligt snart. I söndags, den 27 september, blev det konkret igen. Då akutpatchade vi Citrix NetScaler efter information från leverantören. Vi använder Netscaler för vår lastbalanseringstjänst. Det var bråttom, snabba analyser och kontakt med kund. Enligt Help Net Security registrerades angreppsförsök inom minuter efter att exempelkod för att utnyttja sårbarheten hade publicerats. För mig är det ännu en påminnelse om hur små tidsmarginalerna har blivit. Angriparna väntar inte på vårt nästa servicefönster.
Det här märks i min egen vardag
Tripnets webbplats kör WordPress. Den ligger mig nära, eftersom jag som marknadschef ansvarar för den. Mina kollegor arbetar med betydligt mer affärskritiska kundsystem, men jag ser på vår egen webbplats hur mycket som händer och hur fort det går.
Sajten uppdateras automatiskt och löpande, och akuta uppdateringar hanteras direkt. Vi har en inbyggd applikationsbrandvägg och en brandvägg framför. Ändå finns det gott om aktivitet att följa. Jag ser tydligt att angreppsförsöken ökar. Min bild av hotlandskapet rymmer både enskilda angripare och statsstödda aktörer, även om jag inte kan avgöra vilka som ligger bakom försöken mot just vår sajt. Aktiviteten gör frågan väldigt påtaglig för mig.
Flera skydd behövs. Jag tänker mig flera skivor schweizerost, där hålen helst inte ligger på samma ställe. Samtidigt kan vi inte behandla något av skydden som en garanti. Patchstack beskriver till exempel hur de första brandväggsreglerna mot WordPress-sårbarheterna, även deras egna, behövde förbättras när det visade sig att de kunde kringgås. Vi behöver både laga sårbarheter och följa upp hur skydden fungerar.
Tillgänglighet och riktighet kontra konfidentialitet
När vi arbetar med informationssäkerhet återkommer vi till tillgänglighet, riktighet och konfidentialitet. Vi ska kunna använda våra system när vi behöver dem. Informationen ska vara korrekt. Och den ska bara vara tillgänglig för dem som har rätt att ta del av den.
Det finns en skillnad mellan de här egenskaperna som jag tycker förtjänar mer uppmärksamhet. Tillgänglighet kan vi återställa. Ett system som ligger nere kan komma upp igen. Det kan vara besvärligt och dyrt, och konsekvenserna av avbrottet försvinner inte för det. Men själva tillgängligheten går att få tillbaka.
Riktighet kan vi också återställa, om vi har bevarat en korrekt återställningspunkt och kan verifiera den. På Tripnet använder vi immutabla backuper, där sparade kopior skyddas mot ändring och radering under den låsta lagringstiden. Vi kan gå tillbaka i den bevarade historiken för att hitta ett läge före en förändring eller manipulation. Det kan vara ett stort arbete att fastställa när informationen senast var korrekt och att ta hand om det som hänt därefter. En oföränderlig backup bevarar det som sparades, även eventuella fel som redan fanns då. Men med rätt historik och kontroll finns en väg tillbaka.
Röjd information fungerar annorlunda. Den som har kopierat uppgifterna lämnar inte tillbaka sin kunskap för att vi återställer en backup. Ett lösenord kan bytas. Röjda personuppgifter kan finnas kvar hos någon annan långt efter att vi har fått ordning på våra system. Röjda uppgifter går inte att göra oröjda.
Jag tror därför att konfidentialitet kommer att väga tyngre i fler av de beslut vi fattar om patchning. På många system kan det vara rimligt att acceptera en större risk för ett avbrott för att minska risken att känslig information hamnar i fel händer. På andra system kan ett avbrott vara det allvarligaste som kan inträffa. Den avvägningen måste utgå från verksamheten, och det behöver vara tydliggjort i förväg.
Tänk fortare!
Min tidigare kollega Lobo brukade säga:
– Tänk fortare!
Jag älskar formuleringen och anstränger mig verkligen, men en tanke tar 0,2 sekunder ändå. Vi behöver hitta andra sätt att arbeta.
En stor del handlar om processer, prioritering och automation. Att upptäcka vilka system som berörs, hämta uppdateringar, köra förberedda tester och följa upp resultatet. Och att snabbt upptäcka om något slutar fungera. Jag är en stor anhängare av ordentliga tester. Samtidigt har jag svårt att se hur vi ska hinna om varje uppdatering kräver att någon manuellt börjar om från början.
Min förutsägelse är att vi kommer att göra mindre av det manuella arbetet för varje enskild patch och lägga mer kraft på att bygga tillförlitliga, automatiserade förlopp. På vissa system kan testerna vara korta och avgränsade. På andra krävs mer. Övervakning efteråt blir viktigare, men ersätter inte de tester som faktiskt behöver göras före.
Riskprocessen är central. I förändringsprocessen behöver vi bedöma både risken med förändringen och risken med att vänta. Vi har processer för det och ett CAB, Change Advisory Board, där förändringar bedöms. Det hjälper oss med avvägningarna. För återkommande förändringar behöver vi också ha tydliga, förhandsgodkända arbetssätt och mandat.
Vi ska helst inte behöva samla ett Emergency CAB, ett e-CAB, för varje brådskande säkerhetsuppdatering. Akuta situationer kommer att finnas, men de får inte bli vårt normala sätt att organisera arbetet. Jag vill att människor ska kunna arbeta lugnt och metodiskt även när tiden är knapp. Då måste det vara tydligt vad som gäller, vilka kontroller som ska göras och när man ska stanna upp och eskalera.
Reglerade verksamheter som berörs av NIS2, DORA och cybersäkerhetslagen behöver bygga in sina krav i de här flödena. Inom NIS2 finns för vissa aktörer uttryckliga krav på att säkerhetspatchar ska testas innan de installeras i produktionssystem. Jag kan personligen känna en oro över hur vi ska hinna med det när tidsmarginalerna blir så små. Jag tror att enklare och tydligare processer, tillsammans med automatisering, är vägen framåt för att genomföra och dokumentera kontrollerna i tid.
Microsofts bedömning, men vad är short grace period?
Microsoft har uppdaterat sin bedömning, men jag tror att vi behöver prata om vad det betyder och innebär för varje verksamhet, varje system eller rent av varje enhet. Samtidigt kan vi låta oss inspireras för alla andra system som inte är Microsoft.
| Icon | Risk level | Description |
|---|---|---|
| Current | Devices have the latest applicable security update installed, or are on the previous update within the short grace period immediately after a new release. | |
| Exposed | Devices are behind the latest applicable security update and moved beyond the initial grace period. In general, this status begins after roughly the first three days following a newly applicable update release. | |
| Critical | Devices are missing required updates long enough to represent materially higher risk. In general, devices that remain behind for a week or longer can move into this state, and unsupported versions are also treated as critical risk. | |
| Unknown build | The reported device version can't be mapped to a known supported release or update baseline. | |
| Not checked in (90+ days) | The device didn't report recently and is excluded from primary risk calculations to keep the dashboard focused on active fleet posture. |
After a newly released security update becomes applicable, devices on the previous update may remain classified as Current for a short period so the dashboard reflects normal deployment propagation instead of immediately treating the entire fleet as newly at risk.
De svåra besluten behöver fattas i förväg
Här behöver vi fortsätta prata med våra kunder. Vad är viktigast i just deras verksamhet? Vad får ett avbrott för konsekvenser? Vilken information får absolut inte komma ut? Hur upptäcker vi om data har förändrats? Och vilket mandat ska Tripnet ha att agera? Allt förändras hela tiden och det vi såg för ett halvår sen kanske inte längre är aktuellt. Tighta relationer och samarbete är avgörande. När något händer kan det vara bråttom. Då vill vi helst redan ha mandat att agera, utan att behöva väcka kunden för ett beslut vi kunde ha fattat tillsammans tidigare.
Vi behöver vara överens om förväntningarna och ansvarsfördelningen mellan kunden, oss och andra leverantörer. Vad får vi uppdatera automatiskt? Vilka förändringar kräver ett särskilt beslut? När behöver vi begränsa åtkomsten till en tjänst medan vi arbetar med en rättning? Vem ska informeras? Vilka beslut får Tripnet fatta, och vem kan fatta övriga beslut om den ordinarie kontaktpersonen inte går att nå?
Det är svåra frågor, men de blir knappast enklare av att vi tar dem första gången när angreppen redan har börjat. Den som sitter med patchningen ska kunna luta sig mot en överenskommen process och ett tydligt mandat.
Nu behöver vi agera
Mycket av det här har vi pratat om länge. Det som gör att jag tar upp det nu är tempot. På Tripnet har vi ändrat flera av våra processer, anpassar oss ständigt. Den generella väntan en vecka efter Microsofts patchsläpp hör till hur vi arbetade förr, och var aldrig hela sanningen. Vi jobbar med ständiga förbättringar och kommer att förändra mer, i nära samarbete med våra kunder och leverantörer.
Vi behöver tillsammans bygga system som går att hålla uppdaterade och som ger hög tillgänglighet, skyddar informationens konfidentialitet och bevarar dess riktighet. Teknik som minskar behovet av omstarter hjälper. Det gör också bättre tester, tydligare ansvar och processer som fungerar när tidsmarginalerna krymper.
Det här kommer vi att fortsätta prata om på driftmöten och strategimöten med våra kunder. Vi kommer också att ha rundabordssamtal på temat. Jag är nyfiken på hur du resonerar. När är det rimligt att acceptera en större risk för ett avbrott för att snabbare täppa till en sårbarhet? Och vad behöver vara överenskommet för att du ska känna dig trygg med det?
Kommentera gärna inlägget på LinkedIn, slå mig en signal eller mejla. Vi kan ta en kaffe och prata vidare, gärna tillsammans med dina och mina kollegor. Det här är en diskussion vi behöver föra medan vi fortfarande har tid att välja hur vi ska arbeta.
Läs också vår fördjupning Snabbare patchning i praktiken, om automation, testning och möjligheterna att uppdatera med färre omstarter.
