Cosa succede quando gli aggressori si muovono più velocemente di quanto la sanità possa applicare le patch?

Il settore sanitario ha da tempo affrontato un vero ostacolo nell:applicare le patch di sicurezza: il team di sicurezza di un ospedale può identificare una vulnerabilità in un sistema clinico in un pomeriggio, ma l’installazione sicura di una correzione è solitamente ostacolata dalle realtà pratiche del ritmo frenetico quotidiano di un ospedale. Il produttore del dispositivo potrebbe dover convalidare un aggiornamento, l’ospedale potrebbe doverlo testare e programmare un periodo di inattività, e alcune modifiche potrebbero richiedere persino una revisione normativa.

Gli aggressori non hanno alcuna di queste limitazioni. Con gli strumenti di IA che accelerano la ricognizione e la ricerca delle vulnerabilità così come lo sviluppo degli exploit, i processi di rimedio già sotto pressione del settore sanitario subiscono ulteriori sollecitazioni.

Ciò che rende la questione particolarmente dolorosa è che i ritardi nell’applicare le patch sono spesso prolungati dalle dipendenze dal fornitore. Ad esempio, una correzione per un sistema MRI potrebbe dover essere convalidata dal fornitore, ma deve comunque essere approvata dal controllo dei cambiamenti dell’ospedale. E tutto ciò deve avvenire senza interrompere l’assistenza.

Il rapporto di Health-ISAC Frontier AI in the Health Sector indica i ritardi nelle patch come una delle esposizioni fondamentali del settore. Ciò lascia gli ospedali con un’unica via praticabile: potrebbero non essere in grado di controllare ogni fase della tempistica delle patch, ma possono limitare ciò che un aggressore può fare mentre un aggiornamento viene distribuito.

La tempistica delle patch ha un limite per una ragione

Molti dei passaggi nella tempistica delle patch di un ospedale possono infastidire i professionisti della sicurezza informatica, ma esistono per garantire la sicurezza dei pazienti. Nessun aggiornamento non testato a un ventilatore o a una pompa di infusione volto a chiudere una vulnerabilità di cybersicurezza vale il costo di ostacolare l’assistenza ai pazienti. La risposta, quindi, è accelerare le parti del processo che possono essere velocizzate senza indebolire i protocolli esistenti.

Gli auditor e i consigli di amministrazione tendono a considerare le lunghe finestre di rimedio come un problema di maturità del programma o di budget, e a volte hanno ragione. Di solito, le lunghe tempistiche delle patch sono sintomo di esecuzione debole, mancanza di risorse o colli di bottiglia al di fuori del controllo del team di sicurezza. Più analisti possono migliorare la rilevazione delle vulnerabilità, la triage e la priorità, ma non possono accorciare le tempistiche del produttore né spostare le finestre di inattività.

Con lo sfruttamento delle vulnerabilità che emerge come il modo più comune con cui gli aggressori ottengono l’accesso alle reti target, il Verizon 2026 Data Breach Investigations Report (DBIR) mostra quanto poco spazio abbiano le organizzazioni per distribuire le patch. Il tempo medio per rimediare completamente a una vulnerabilità nota sfruttata è salito a 43 giorni nel 2026 dai 32 giorni dell’anno precedente, mentre la percentuale di vulnerabilità completamente chiuse è scesa al 26% dal 38%.

Il fatto che questi dati non siano specifici al settore sanitario dimostra quanto sia già difficile la rimessione, prima ancora di considerare le restrizioni cliniche e dei fornitori che gli ospedali devono gestire.

È tempo di guardare oltre i punteggi di gravità

Mentre le finestre di rimedio si sono allungate, gli aggressori sono diventati più rapidi. Il DBIR ha scoperto che lo sfruttamento delle vulnerabilità è ora il modo principale con cui gli hacker accedono ai sistemi, rappresentando il 31% delle violazioni, superando le credenziali rubate per la prima volta nei 19 anni in cui il rapporto è stato pubblicato.

Verizon afferma che l’IA ha contribuito ad accelerare la scoperta e lo sfruttamento delle vulnerabilità, al punto che ciò che una volta richiedeva mesi ora può richiedere ore o giorni. E ciò avveniva prima del rilascio dell’attuale generazione di modelli di frontiera, poiché il set di dati del DBIR si è concluso nell’ottobre 2025.

Ma oggi tutti si aspettano tale velocità. Il rapporto di Health-ISAC segnala qualcosa di ancora più rilevante: i nuovi modelli di IA possono concatenare rilevamenti a bassa gravità in percorsi di attacco critici, identificando combinazioni di vulnerabilità che isolate sembrano meno importanti. Questo crea un ulteriore problema per i programmi di rimedio che danno priorità ai punteggi di gravità, poiché i rilevamenti a bassa gravità, spesso ignorati o rimandati, possono improvvisamente assumere molta più importanza se influenzano l’accesso o sistemi critici.

L’aumento dei backlog peggiora ulteriormente la situazione. Scrivendo su Nature, il direttore del Max Planck Institute Thorsten Holz ha descritto Mozilla che utilizza un modello di frontiera per trovare e correggere 271 vulnerabilità in un singolo rilascio di Firefox, ben oltre ciò che i suoi strumenti e revisori esistenti avevano individuato in un tipico mese dell’anno precedente.

Questa pressione di triage si sta estendendo anche al lato della fornitura: Linus Torvalds, il manutentore del kernel Linux, a maggio ha osservato che i report di bug generati dall’IA stanno sovraccaricando i manutentori.

Quando non puoi correggere più velocemente, riduci ciò che è raggiungibile

Fortunatamente, un backlog che non può essere eliminato può comunque essere gestito. Se una patch deve attendere, la priorità dovrebbe essere ridurre le probabilità che una vulnerabilità venga sfruttata. Ciò sposta il lavoro dalla velocità di rimedio alla raggiungibilità, un aspetto che gli ospedali possono controllare.

La segmentazione può fungere da forte compensazione. Un dispositivo di imaging con ampio accesso può raggiungere un controller di dominio, una condivisione di file e Internet aperto. Ma se è limitato a un segmento isolato che consente il traffico verso il suo server PACS e il punto di aggiornamento del produttore, negando per impostazione predefinita l’accesso al resto, qualsiasi vulnerabilità che lo colpisce può rimanere contenuta per tutto il tempo necessario alla patch.

Quando i requisiti del dispositivo e del fornitore lo consentono, gli ospedali possono utilizzare la segmentazione, controlli di uscita e regole di negazione per impostazione predefinita per restringere e persino chiudere i percorsi di accesso mentre una patch è in attesa.

Gli ospedali non hanno bisogno di un inventario completo degli asset prima di iniziare a ridurre la superficie esposta. Contare prima i sistemi che rispondono a Internet, mantenere quel numero aggiornato man mano che l’inventario più ampio prosegue, e dare priorità a limitare ciò che quei sistemi possono raggiungere all’interno della rete.

I dati del sondaggio di Health-ISAC indicano che il settore sta già iniziando a muoversi in quella direzione. Circa l’80% dei membri di Health-ISAC dichiara di pianificare un aumento del budget per strumenti di sicurezza potenziati dall’IA o per la valutazione dell’exploitability. Un percorso che potrebbe rivelarsi utile è analizzare quali percorsi di attacco funzionano nel proprio ambiente: trovare combinazioni di vulnerabilità a bassa gravità che potrebbero meritare attenzione prima che un punteggio di priorità attiri la tua attenzione.

Le conversazioni con i fornitori devono superare anche il linguaggio presente negli accordi di livello di servizio. I contratti contengono ciò a cui tu e i tuoi fornitori vi siete impegnati anni fa, ma il modello di minaccia è cambiato drasticamente. Quindi, prima identifica quanto tempo impiegano le patch convalidate per essere rilasciate dopo la divulgazione pubblica, poi scopri quali misure di mitigazione sono disponibili mentre attendi l’aggiornamento. Vale anche la pena chiedere se testano il loro prodotto contro le attuali tecniche di attacco assistite dall’IA.

Gestire l’esposizione che non puoi rimuovere

La maggior parte delle organizzazioni non può dire quanto tempo occorra per avere una correzione convalidata in produzione una volta che un exploit è stato reso pubblico. Concentrati nel determinare quel valore così da smettere di dibattere sulle finestre di patch e iniziare a capire quali fornitori e sistemi rimangono esposti più a lungo. Questo ti consentirà di decidere cosa debbano prioritizzare i tuoi sforzi di rimedio.

Condividere informazioni può accorciare significativamente quel ciclo decisionale. Alcune delle decisioni di rimedio più rapide che ho visto avvengono quando un ospedale sente da un collega che una piattaforma di un fornitore è stata sfruttata prima che la vulnerabilità fosse divulgata pubblicamente.

La finestra di validazione stessa non si allargherà. Gli ospedali continueranno a far funzionare sistemi clinici con vulnerabilità aperte, il che significa che la strategia di segmentazione per tali sistemi deve avere più importanza rispetto al programma di patch. Ogni ospedale dovrebbe poter specificare, per ciascuna delle proprie piattaforme critiche, cosa accadrebbe sulla rete se quella piattaforma fosse violata domani.