Hva skjer når angripere beveger seg raskere enn helsesektoren kan oppdatere?

Helsesektoren har lenge hatt en reell hindring for å patche sikkerhetsproblemer: Et sykehus sitt sikkerhetsteam kan kanskje identifisere en sårbarhet i et klinisk system på en ettermiddag, men å trygt installere en løsning blir vanligvis hindret av de praktiske realitetene i et sykehus sin hektiske hverdag. Enhetens produsent kan måtte validere en oppdatering, sykehuset kan måtte teste den og planlegge nedetid, og noen endringer kan til og med kreve en regulatorisk gjennomgang.

Angripere har ingen av disse begrensningene. Med AI‑verktøy som akselererer sårbarhetsrekognosering og forskning samt utvikling av utnyttelser, blir helsesektorens allerede belastede utbedringsprosesser utsatt for enda større press.

Det som gjør dette til et spesielt smertefullt problem, er at patch‑forsinkelser ofte forlenges av leverandøravhengigheter. Mens en løsning for et MR‑system for eksempel kan måtte valideres av leverandøren, må den ofte fortsatt godkjennes av sykehusets endringskontroll. Og alt må gjøres uten å forstyrre behandlingen.

Health-ISACs Frontier AI i helsesektoren-rapport navngir forsinket patching som en av sektorens definerende eksponeringer. Det gir sykehusene én levedyktig vei videre: De kan kanskje ikke kontrollere alle deler av patch‑tidslinjen, men de kan begrense hva en angriper kan gjøre mens en oppdatering rulles ut.

Patch‑tidslinjen har et gulv av en grunn

Mange av trinnene i et sykehus sin patch‑tidslinje kan irritere informasjonssikkerhetsprofesjonelle, men de eksisterer for å sikre pasientsikkerhet. Ingen uutprøvd oppdatering til en ventilator eller en infusjonspumpe som har som mål å lukke en cybersikkerhetsrisiko, er verdt kostnaden ved å hindre pasientbehandling. Svaret er derfor å fremskynde de delene av prosessen som kan akselereres uten å svekke eksisterende protokoller.

Revisorer og styrer har en tendens til å behandle lange utbedringsvinduer som et programmodenhets- eller budsjettproblem, og noen ganger har de rett. Vanligvis er lange patch‑tidslinjer et symptom på svak gjennomføring, mangel på ressurser eller flaskehalser utenfor sikkerhetsteamets kontroll. Flere analytikere kan forbedre sårbarhetsdeteksjon, triage og prioritering, men de kan ikke forkorte en leverandørs tidslinjer eller flytte nedetidsvinduer.

Etter hvert som utnyttelse av sårbarheter blir den mest vanlige måten angripere får tilgang til målnettverk, viser Verizon 2026 Data Breach Investigations Report (DBIR) akkurat hvor lite rom organisasjoner har til å rulle ut oppdateringer. Median tiden for full utbedring av en kjent utnyttet sårbarhet steg til 43 dager i 2026 fra 32 dager året før, mens andelen sårbarheter som ble fullstendig lukket, falt til 26 % fra 38 %.

Faktum at disse tallene ikke er spesifikke for helsesektoren viser hvor vanskelig utbedring allerede er, før man tar hensyn til de kliniske og leverandørmessige begrensningene sykehus også må håndtere.

Det er på tide å se utover alvorlighetsgrader

Mens utbedringsvinduer har blitt lengre, har angripere blitt raskere. DBIR fant at utnyttelse av sårbarheter nå er den ledende måten hackere kommer inn i systemer på, med 31 % av brudd, og overgår stjålne legitimasjoner for første gang i de 19 årene rapporten har blitt publisert.

Verizon sier at AI har bidratt til å akselerere oppdagelse og utnyttelse av sårbarheter, så mye at det som tidligere tok måneder nå kan ta timer eller dager. Og det var før den nåværende generasjonen av frontier‑modeller ble lansert, ettersom DBIR‑datasettet sluttet i oktober 2025.

Men alle forventer slik hastighet i dag. Health-ISACs rapport peker på noe mer konsekvent: nyere AI‑modeller kan koble sammen lav‑alvorlige funn til kritiske angrepsveier, og identifisere kombinasjoner av svakheter som kan virke mindre viktige i isolasjon. Det skaper et ytterligere problem for utbedringsprogrammer som prioriterer alvorlighetsgrader, ettersom lav‑alvorlige funn som ofte ignoreres eller skyves til etterslepet plutselig kan bli mye viktigere hvis de påvirker tilgang eller kritiske systemer.

Voksende etterslep forverrer bare situasjonen. I en artikkel i Nature skrev Max Planck‑institutt‑direktør Thorsten Holz om hvordan Mozilla brukte en frontier‑modell til å finne og fikse 271 sårbarheter i en enkelt Firefox‑utgivelse, langt mer enn hva deres eksisterende verktøy og gjennomgåere hadde avdekket i en vanlig måned det foregående året.

Det triage‑presset strekker seg også til leverandørsiden: Linus Torvalds, vedlikeholderen av Linux‑kjernen, påpekte i mai at feilrapporter generert av AI overbelaster vedlikeholdere.

Når du ikke kan fikse raskere, reduser det som er tilgjengelig

Heldigvis kan et etterslep som ikke kan elimineres fortsatt håndteres. Hvis en oppdatering må vente, bør prioriteten være å redusere sjansen for at noen sårbarhet blir utnyttet. Det flytter arbeidet fra utbedringshastighet til tilgjengelighet, noe sykehus kan kontrollere.

Segmentering kan fungere som en sterk motvekt. En bildediagnostisk enhet med bred tilgang kan nå en domenekontroller, en fildeling og det åpne internettet. Men hvis den er begrenset til et isolert segment som tillater trafikk til sin PACS‑server og produsentens oppdateringsendepunkt, mens den som standard nekter tilgang til resten, kan enhver sårbarhet som påvirker den forbli innelukket så lenge oppdateringen tar.

Der enhetens og leverandørens krav tillater det, kan sykehus bruke segmentering, utgående kontroller og nekt‑som‑standard‑regler for å begrense og til og med stenge av tilgangsstier mens en oppdatering venter.

Sykehus trenger ikke et komplett aktivainventar før de begynner å redusere den eksponerte overflaten. Tell først opp systemene som svarer på internett, hold dette tallet oppdatert mens det bredere inventaret fortsetter, og prioriter å begrense hva disse systemene kan nå inn i nettverket.

Health-ISACs undersøkelsesdata indikerer at bransjen allerede begynner å bevege seg i den retningen. Omtrent 80 % av Health-ISAC‑medlemmene sier de planlegger å øke budsjettet for AI‑drevne sikkerhetsverktøy eller sårbarhetsvurdering. En vei som kan vise seg nyttig er å analysere hvilke angrepsveier som fungerer i ditt eget miljø: finn kombinasjoner av lav‑alvorlige sårbarheter som kan fortjene oppmerksomhet før en prioritetsscore fanger din oppmerksomhet.

Leverandør‑samtaler må også gå forbi språket i serviceavtalen. Kontrakter inneholder det du og leverandørene forpliktet dere til for år siden, men trusselmodellen har endret seg dramatisk. Så identifiser først hvor lang tid validerte oppdateringer for sårbarheter kan ta å bli utgitt etter offentlig avsløring, og finn deretter ut hvilke mitigeringstiltak som er tilgjengelige mens du venter på oppdateringen. Det er også verdt å spørre om de tester produktet sitt mot nåværende AI‑assisterte angrepsteknikker.

Håndter eksponeringen du ikke kan fjerne

De fleste organisasjoner kan ikke si hvor lang tid det tar å ha en validert løsning i produksjon når en utnyttelse er gjort offentlig. Fokuser på å fastslå dette tallet slik at du kan slutte å diskutere patch‑vinduer og begynne å fokusere på å finne ut hvilke leverandører og systemer som forblir eksponert lengst. Det vil la deg bestemme hva dine utbedringsinnsats må prioriteres.

Deling av informasjon kan betydelig forkorte den beslutningssyklusen. Noen av de raskeste utbedringsbeslutningene jeg har sett skjer når et sykehus hører fra en kollega om at en leverandørplattform blir utnyttet før sårbarheten er offentliggjort.

Selve valideringsvinduet vil ikke bli bredere. Sykehus vil fortsette å kjøre kliniske systemer med åpne sårbarheter, noe som betyr at segmenteringsstrategien for disse systemene må få større betydning enn patch‑planen. Hvert sykehus bør kunne spesifisere, for hver av sine kritiske plattformer, hva som ville skje i nettverket hvis den plattformen ble brutt i morgen.