Vad händer när angripare rör sig snabbare än sjukvården kan patcha?

Hälsovårdssektorn har länge stått inför ett verkligt hinder för att patcha säkerhetsproblem: ett sjukhus säkerhetsteam kan kanske identifiera en sårbarhet i ett kliniskt system på en eftermiddag, men att på ett säkert sätt installera en åtgärd hindras ofta av de praktiska realiteterna i ett sjukhus hektiska vardagstakt. Enhetens tillverkare kan behöva validera en uppdatering, sjukhuset kan behöva testa den och schemalägga driftstopp, och vissa förändringar kan till och med kräva en regulatorisk granskning.

Angripare har inga av dessa begränsningar. Med AI-verktyg som påskyndar sårbarhetsrekognosering och forskning samt exploateringsutveckling, utsätts vårdens redan ansträngda återställningsprocesser för ännu större press.

Det som gör detta till ett särskilt smärtsamt problem är att patchningsförseningar ofta förlängs av leverantörsberoenden. Även om en åtgärd för ett MR‑system till exempel kan behöva valideras av leverantören, måste den ofta fortfarande godkännas av sjukhusets förändringskontroll. Och allt måste göras utan att störa vården.

Health-ISAC:s Frontier AI i hälsosektorn-rapport benämner försenad patchning som en av sektorns definierande exponeringar. Det lämnar sjukhusen med ett enda genomförbart alternativ: De kanske inte kan kontrollera varje del av patch‑tidslinjen, men de kan begränsa vad en angripare kan göra medan en uppdatering rullas ut.

Patch-tidslinjen har ett golv av en anledning

Många av stegen i ett sjukhus patch‑tidslinje kan irritera informationssäkerhetsproffs, men de finns för att säkerställa patientens säkerhet. Ingen otestad uppdatering till en ventilator eller en infusionspump som syftar till att täppa till en cybersäkerhetsrisk är värd kostnaden att hindra patientvården. Svaret är därför att påskynda de delar av processen som kan accelereras utan att försvaga befintliga protokoll.

Revisorer och styrelser tenderar att behandla långa återställningsfönster som ett programmognads‑ eller budgetproblem, och ibland har de rätt. Vanligtvis är långa patch‑tidslinjer ett symptom på svag genomförande, brist på resurser eller flaskhalsar utanför säkerhetsteamets kontroll. Fler analytiker kan förbättra sårbarhetsdetektering, triage och prioritering, men de kan inte förkorta en tillverkares tidslinjer eller flytta driftstopp.

Med utnyttjande av sårbarheter som den vanligaste metoden för angripare att få åtkomst till mål‑nätverk, visar Verizon 2026 Data Breach Investigations Report (DBIR) hur lite utrymme organisationer har för att rulla ut patchar. Medianen för tid att fullt återställa en känd exploaterad sårbarhet steg till 43 dagar år 2026 från 32 dagar föregående år, medan andelen sårbarheter som helt stängdes föll till 26 % från 38 %.

Faktum att dessa siffror inte är specifika för vården visar hur svårt återställning redan är, innan man tar hänsyn till de kliniska och leverantörsbegränsningar som sjukhus också måste hantera.

Det är dags att se bortom allvarlighetsgraderingar

Medan återställningsfönsterna har blivit längre, har angriparna blivit snabbare. DBIR fann att utnyttjande av sårbarheter nu är det främsta sättet hackare tar sig in i system, med 31 % av intrång, och passerar stulna autentiseringsuppgifter för första gången under de 19 år rapporten har publicerats.

Verizon säger att AI har hjälpt till att påskynda upptäckten och utnyttjandet av sårbarheter, så mycket att vad som tidigare tog månader nu kan ta timmar eller dagar. Och det var innan den nuvarande generationen av frontier‑modeller släpptes, eftersom DBIR:s dataset avslutades i oktober 2025.

Men alla förväntar sig sådan hastighet nuförtiden. Health-ISAC:s rapport flaggar något mer betydelsefullt: nyare AI‑modeller kan kedja lågallvarliga fynd till kritiska attackvägar, och identifiera kombinationer av svagheter som kan verka mindre viktiga i isolering. Det skapar ytterligare ett problem för återställningsprogram som prioriterar allvarlighetsgraderingar, eftersom lågallvarliga fynd som ofta ignoreras eller skjuts upp i backloggen plötsligt kan bli mycket viktigare om de påverkar åtkomst eller kritiska system.

Växande backloggar förvärrar bara bilden. I en artikel i Nature skrev Max Planck‑institutet chef Thorsten Holz om hur Mozilla använde en frontier‑modell för att hitta och åtgärda 271 sårbarheter i en enda Firefox‑utgåva, långt mer än vad deras befintliga verktyg och granskare hade upptäckt under en typisk månad det föregående året.

Det trycket på triage sträcker sig också till leveranssidan: Linus Torvalds, underhållaren av Linux‑kärnan, påpekade i maj att felrapporter genererade av AI överbelastar underhållare.

När du inte kan fixa snabbare, minska det som är nåbart

Tack och lov kan en backlog som inte kan elimineras ändå hanteras. Om en patch måste vänta bör prioriteten vara att minska sannolikheten för att någon sårbarhet blir nådd. Det flyttar arbetet från återställningshastighet till åtkomlighet, vilket är något sjukhus kan kontrollera.

Segmentering kan fungera som ett starkt motmedel. En bildbehandlingsenhet med bred åtkomst kan nå en domänkontroller, en fildelning och det öppna internet. Men om den begränsas till ett isolerat segment som tillåter trafik till dess PACS‑server och tillverkarens uppdateringsändpunkt, samtidigt som åtkomst till resten nekas som standard, kan en sårbarhet som påverkar den förbli innesluten så länge patchen tar.

Där enhetens och leverantörens krav tillåter det kan sjukhus använda segmentering, utflödeskontroller och nekande‑som‑standard‑regler för att begränsa och till och med stänga av åtkomstvägar medan en patch är pågående.

Sjukhus behöver inte en komplett inventering av tillgångar innan de börjar minska den exponerade ytan. Räkna först systemen som svarar på internet, håll det antalet aktuellt medan den bredare inventeringen fortsätter, och prioritera att begränsa vad dessa system kan nå inom nätverket.

Health-ISAC:s undersökningsdata visar att branschen redan börjar röra sig i den riktningen. Ungefär 80 % av Health-ISAC:s medlemmar säger att de planerar att öka sina budgetar för AI‑drivna säkerhetsverktyg eller exploaterbarhetsbedömning. En väg som kan vara användbar är att analysera vilka attackvägar som fungerar i din egen miljö: hitta kombinationer av lågallvarliga sårbarheter som kan förtjäna uppmärksamhet innan ett prioriteringsbetyg drar din uppmärksamhet.

Leverantörssamtal måste också gå förbi språket i serviceavtalet. Avtal innehåller vad du och dina leverantörer åtagit er för år sedan, men hotmodellen har förändrats dramatiskt. Så identifiera först hur lång tid validerade patchar för sårbarheter kan ta att utfärdas efter offentliggörande, och ta sedan reda på vilka mitigationsåtgärder som finns tillgängliga medan du väntar på uppdateringen. Det är också värt att fråga om de testar sin produkt mot nuvarande AI‑assisterade attacktekniker.

Hantera exponeringen du inte kan ta bort

De flesta organisationer kan inte säga hur lång tid det tar att ha en validerad åtgärd i produktion när en exploatering har offentliggjorts. Fokusera på att fastställa det talet så att du kan sluta diskutera patch‑fönster och börja fokusera på att ta reda på vilka leverantörer och system som förblir exponerade längst. Det gör att du kan avgöra vad dina återställningsinsatser måste prioritera.

Att dela information kan avsevärt förkorta den beslutsprocessen. Några av de snabbaste återställningsbesluten jag har sett sker när ett sjukhus hör från en kollega om att en leverantörsplattform utnyttjas innan sårbarheten offentliggörs.

Valideringsfönstret i sig kommer inte att breddas. Sjukhus kommer att fortsätta köra kliniska system med öppna sårbarheter, vilket innebär att segmenteringsstrategin för dessa system måste ges större betydelse än patch‑schemat. Varje sjukhus bör kunna specificera, för var och en av sina kritiska plattformar, vad som skulle hända i nätverket om den plattformen blev komprometterad i morgon.