Skip to content
Resilienza informatica e sicurezza dei dati, sicurezza informatica nel settore sanitario

La realtà dell’ecosistema: perché gli incidenti causati da terze parti rappresentano il principale rischio informatico nel settore sanitario

Perché tre CMIO affermano che i loro incidenti più gravi degli ultimi tempi sono tutti provenuti dall’esterno della loro struttura.


Durante i colloqui con tre Chief Medical Information Officer operanti in diversi sistemi sanitari, a ciascuno è stato chiesto di illustrare il proprio incidente di sicurezza informatica più recente. La risposta è stata unanime e significativa: nessuno dei tre aveva subito un attacco diretto ai propri sistemi. Tutti e tre, invece, stavano affrontando le conseguenze di violazioni subite da fornitori terzi che si erano ripercosse a cascata sulle loro operazioni. Non è una coincidenza: è la nuova realtà della sicurezza informatica nel settore sanitario.

Il problema del fornitore del fornitore

«Siamo abbastanza grandi da poter contare su questi esperti all’interno del nostro staff che ci proteggono», ha spiegato un CMIO. «A volte penso che questo possa rappresentare un ostacolo all’agilità, vista la nostra rigore e meticolosità nelle valutazioni. Ma credo che non possiamo garantire che i nostri partner facciano lo stesso».

Ecco la sfida: le organizzazioni sanitarie sono diventate incredibilmente sofisticate nel vagliare i fornitori diretti. Il processo di contrattazione è rigoroso, le valutazioni di sicurezza sono approfondite e i requisiti di conformità non sono negoziabili. Ma cosa succede quando il tuo fornitore stringe un accordo con un altro fornitore? Improvvisamente, ti ritrovi esposto a rischi che non hai mai valutato, provenienti da aziende di cui non hai mai sentito parlare, attraverso relazioni che non controlli.

Un responsabile della sicurezza ha illustrato perfettamente questo concetto: «Sto per stipulare un accordo per avvalermi del fornitore X affinché svolga un determinato compito per me. Ma il fornitore X potrebbe stringere un accordo con il fornitore Y che gli consenta di svolgere il proprio lavoro. Quindi, se dovesse sorgere un problema con il fornitore Y – con cui tecnicamente non ho un contratto, ma di cui il mio fornitore ha bisogno per operare – non potrei controllarlo».

Quando l’ecosistema fallisce

L’incidente di Change Healthcare ne è un chiaro esempio. Quando i suoi sistemi sono andati in tilt a causa di un attacco informatico, non è stata solo Change Healthcare a subirne le conseguenze, ma tutte le organizzazioni sanitarie che si affidavano ai suoi servizi di elaborazione delle prescrizioni. Un CMIO ha descritto l’impatto: «Abbiamo avuto molti problemi nell’inviare e ricevere le prescrizioni, senza sapere bene cosa fosse stato consegnato, cosa no e chi non avesse ricevuto i propri farmaci».

L’impatto clinico a valle è stato immediato e grave. I pazienti non potevano ottenere i farmaci, gli operatori sanitari non potevano verificare lo stato delle prescrizioni e le équipe sanitarie si sono affrettate a identificare i pazienti che potevano essere interessati dal problema. Si è trattato di un problema diretto di sicurezza dei pazienti causato da un incidente del fornitore completamente al di fuori del controllo degli operatori sanitari. Ma l’impatto clinico era solo l’inizio. Le implicazioni in termini di conformità erano altrettanto gravi, mettendo in luce una sfida fondamentale nel panorama normativo dell’assistenza sanitaria.

La trappola della conformità: quando i fallimenti dei fornitori diventano un problema normativo per voi

Le organizzazioni sanitarie devono affrontare una dura realtà normativa: gli incidenti dei fornitori non le esonerano dalle responsabilità di conformità. Anzi, spesso le amplificano. L’HIPAA richiede alle entità interessate di stipulare accordi di collaborazione commerciale (Business Associate Agreements) con i fornitori che trattano informazioni sanitarie protette. Sebbene tali accordi trasferiscano teoricamente parte della responsabilità, la realtà pratica è diversa. Quando un fornitore subisce una violazione, l’operatore sanitario deve comunque affrontare potenziali sanzioni, controlli normativi e obblighi di segnalazione.

Il solo onere della segnalazione crea una notevole pressione operativa. Gli obblighi di segnalazione entro 72 ore previsti dall’HIPAA, simili alle normative UE NIS2 e DORA per gli istituti transfrontalieri, richiedono agli operatori sanitari di comunicare rapidamente gli incidenti, indipendentemente dal fatto che la violazione abbia avuto origine dai propri sistemi o da quelli di un fornitore.

Come ha osservato un CMIO: «Dobbiamo comunicare allo Stato, ai Centri per i servizi Medicaid e Medicare: “Ecco cosa sta succedendo. Ecco a che punto siamo con il nostro ripristino”».

Ciò significa che durante un incidente in corso, quando i team clinici sono impegnati a garantire l’assistenza ai pazienti e i team IT coordinano le attività di ripristino, i team addetti alla conformità devono contemporaneamente indagare, documentare e segnalare incidenti che non hanno causato e di cui potrebbero avere una visibilità limitata. La sfida della sovranità dei dati aggiunge complessità. I fornitori che archiviano dati sanitari al di fuori delle regioni approvate possono causare violazioni di conformità di cui le organizzazioni potrebbero non essere nemmeno a conoscenza fino a quando un incidente non costringe a un audit completo del proprio ecosistema di fornitori.

«Chiediamo ai fornitori di fornirci tutto ciò che richiediamo per poterlo esaminare», ha spiegato un responsabile della sicurezza che ha subito un attacco ransomware da parte di un fornitore. «Quindi, in realtà, non c’erano limiti a ciò che potevamo chiedere». Ma questo livello di supervisione è solitamente possibile solo con i fornitori più grandi, lasciando molte dipendenze da fornitori più piccoli, ma comunque critici, in una zona d’ombra dal punto di vista della conformità.

Il campanello d’allarme di CrowdStrike

L’incidente di CrowdStrike ha messo in luce un’altra realtà: quando i fornitori di infrastrutture critiche falliscono, l’intero ecosistema sanitario crolla contemporaneamente.

«Abbiamo condotto [esercitazioni teoriche] partendo dal presupposto che si trattasse di un attacco ransomware… un evento piuttosto localizzato», ha osservato un dirigente. «E invece questo stava influenzando l’intero ecosistema. Ed è lì che abbiamo [capito] che dovevamo adottare pratiche di resilienza più ampie, in grado di tenere conto dei casi in cui l’ecosistema stesso sarebbe stato ampiamente colpito».

La sfida non era solo tecnica, ma anche operativa e normativa. Quando tutti sono fuori uso contemporaneamente, i normali piani di backup (come chiamare i fornitori per assistenza o passare a fornitori alternativi) semplicemente non funzionano. Le organizzazioni sanitarie hanno dovuto affrontare non solo l’interruzione dell’assistenza ai pazienti e gli elevati costi dovuti ai tempi di inattività, ma anche complessi requisiti di segnalazione di conformità per un incidente che era avvenuto completamente al di fuori del loro controllo.

Oltre la tradizionale valutazione dei rischi

Le organizzazioni sanitarie stanno scoprendo che il loro approccio tradizionale alla gestione dei rischi dei fornitori non è sufficiente. Il processo standard – invio di questionari, revisione della documentazione, verifica delle certificazioni di conformità – copre solo i rapporti diretti.

Ma dopo l’incidente, la situazione sta cambiando. Anziché limitarsi a chiedere «Fate questo? Fate quello?», le organizzazioni chiedono di vedere esattamente come i fornitori attuano i piani di sicurezza e di ripristino. Chiedono prove dei test effettuati, richiedono diritti contrattuali per esaminare i rapporti con i subappaltatori e introducono protezioni finanziarie.

Il nuovo modello di relazione con i fornitori

Le organizzazioni sanitarie lungimiranti stanno adottando diverse misure concrete per affrontare il rischio legato all’ecosistema:

  • Sovranità dei dati: «Vogliamo iniziare ad assumere un maggiore controllo sui dati… in modo da avere qualcosa su cui poter ricostruire o, se possibile, passare a un altro fornitore terzo», ha affermato un dirigente.
    Anziché lasciare che i fornitori detengano tutti i dati, le organizzazioni richiedono esportazioni periodiche dei dati e conservano le proprie copie delle informazioni critiche. Questo approccio contribuisce a soddisfare i requisiti di residenza dei dati e garantisce la continuità della conformità anche in caso di inadempienza dei fornitori.
  • Migliore evoluzione contrattuale: le negoziazioni contrattuali successive agli incidenti ora affrontano esplicitamente gli obblighi di conformità. Le organizzazioni richiedono tempi di notifica che soddisfino i requisiti normativi, garanzie di ripristino che riducano al minimo i costi di inattività e un risarcimento finanziario sia per le perdite dirette che per le sanzioni di conformità derivanti da interruzioni causate dai fornitori.
  • Gestione degli aggiornamenti attenta alla conformità: l’incidente di CrowdStrike ha evidenziato come gli aggiornamenti dei fornitori possano creare rischi sia operativi che di conformità. Molte organizzazioni hanno implementato politiche di “due versioni indietro” per gli aggiornamenti di sicurezza critici, bilanciando il rischio di patch ritardate con il rischio di violazioni di conformità derivanti da aggiornamenti non testati che potrebbero causare interruzioni diffuse.
  • Integrazione della conformità normativa nella gestione dei fornitori: le organizzazioni stanno integrando direttamente le considerazioni relative alla conformità nella valutazione dei fornitori e nella supervisione continua. Ciò include la garanzia che i fornitori siano in grado di soddisfare gli stessi requisiti di segnalazione entro 72 ore, mantenere un’adeguata residenza dei dati e fornire la documentazione necessaria per la segnalazione normativa.

Il punto di vista del settore assicurativo

Forse l’aspetto più significativo è il modo in cui il settore assicurativo considera questi rischi. Come ha riferito un responsabile della sicurezza citando un collega che si occupa di modellizzazione dei rischi assicurativi: «Il rischio principale che corriamo è un’interruzione simile a quella di CrowdStrike, in cui dipendiamo talmente tanto da queste piattaforme tecnologiche che, quando non sono disponibili, si verificano enormi interruzioni nei servizi e nelle operazioni. Lei sostiene che questo sia il rischio principale nel nostro modello di rischio. Non sono gli attacchi ransomware».

Questo cambiamento nella valutazione dei rischi riflette una trasformazione fondamentale. La sicurezza informatica tradizionale era incentrata sulla prevenzione dell’accesso da parte di malintenzionati. La sicurezza informatica moderna deve invece affrontare la realtà secondo cui i fornitori critici, pur con le migliori intenzioni e solide pratiche di sicurezza, possono comunque compromettere interi ecosistemi a causa di guasti operativi.

La sfida del ripristino minimo praticabile in un mondo ecosistemico

La pianificazione tradizionale del ripristino spesso presuppone che sia possibile ripristinare tutto in modo sistematico, ma quando interi ecosistemi falliscono contemporaneamente, le organizzazioni devono concentrarsi sul ripristino minimo praticabile (MVR).

Il concetto di “funzionalità minima” diventa fondamentale quando sono coinvolti i vostri fornitori, i loro fornitori e potenzialmente anche i vostri fornitori di backup. Come abbiamo visto nella nostra analisi delle minacce informatiche nel settore sanitario e dell’MVR, la domanda non è solo «Come possiamo ripristinare tutto?», ma anche «Quali sono gli elementi essenziali di cui abbiamo bisogno per garantire l’assistenza ai pazienti mentre l’ecosistema si ricostruisce?».

Questa realtà dell’ecosistema rende la preparazione al ripristino organizzativo più complessa che mai. Quando non è possibile fare affidamento sui fornitori abituali o sui provider di backup, il piano MVR deve tenere conto della reale indipendenza dall’ecosistema più ampio, almeno temporaneamente.

Andare avanti

Le organizzazioni non possono limitarsi a proteggere il proprio perimetro; devono comprendere e pianificare la rete interconnessa di dipendenze su cui si basa la sanità moderna. Ciò significa ripensare radicalmente la pianificazione della continuità operativa per tenere conto di guasti simultanei all’ecosistema. Significa mantenere la sovranità dei dati anche quando si utilizzano fornitori SaaS. E significa accettare che alcuni rischi semplicemente non possono essere eliminati, ma solo gestiti e pianificati.

I leader del settore sanitario con cui abbiamo parlato non erano pessimisti riguardo a queste sfide, ma pragmatici. Comprendono che i vantaggi dei sistemi sanitari interconnessi e del cloud superano di gran lunga i rischi.

Verifica la resilienza del tuo ecosistema

Comprendere i rischi è solo il primo passo. Il passo successivo consiste nel valutare onestamente se la vostra organizzazione è preparata alla nuova realtà dei guasti interconnessi. Quanto siete sicuri che il vostro piano MVR funzionerebbe se anche i vostri fornitori abituali e i vostri sistemi di backup fossero compromessi? Le organizzazioni sanitarie che prendono sul serio la resilienza dell’ecosistema dovrebbero valutare il proprio stato di Readiness in tre aree critiche: definizione delle priorità aziendali, risposta tecnica misurabile e preparazione organizzativa al Recovery. La valutazione «Minimum Viability Healthcare Assessment» di Commvault aiuta a valutare le vostre attuali capacità e offre raccomandazioni concrete per colmare eventuali lacune. Non aspettate il prossimo incidente a livello di ecosistema per scoprire se i vostri piani di ripristino tengono conto della realtà dell’IT sanitario interconnesso. Effettuate oggi stesso la valutazione e costruite una vera resilienza per le sfide di domani.


Blog correlati:

Altri post correlati


Thumbnail_Blog_Ready-or-Not-Ep5-Data

Dati: quando “troppo” diventa “mai abbastanza”

Per saperne di più su Dati: quando "troppo" diventa "mai abbastanza"
Thumbnail_Blog_Ready-or-Not-Ep5-Data

Dati: quando “troppo” diventa “mai abbastanza”

Per saperne di più su "Dati: quando troppo diventa mai abbastanza"
Thumbnail_Blog_Ransomware-Trends-2025-1

Perché i rischi informatici moderni richiedono una resilienza informatica completa

Per saperne di più su Perché i rischi informatici moderni richiedono una resilienza informatica completa