Perché la sicurezza del cloud nel settore sanitario non può essere trattata alla stregua della sicurezza standard del cloud aziendale?

In che modo la sicurezza dei dati sanitari si differenzia dalla sicurezza standard dei dati aziendali?

La sicurezza dei dati sanitari è soggetta a una serie di considerazioni in materia di sicurezza che raramente emergono nelle tipiche discussioni sulla privacy e sulla sicurezza aziendale. Una serie di rigorosi requisiti normativi, la natura irripetibile e insostituibile dei dati personali e il fatto che la salute del paziente ne sia il risultato diretto contribuiscono a spiegare perché gli obblighi di protezione dei dati sanitari siano diversi da qualsiasi altro quadro normativo relativo alla sicurezza generica del cloud.

In che modo le informazioni sanitarie protette (PHI) sono particolarmente sensibili?

Le informazioni sanitarie protette (PHI) si collocano a un livello di sensibilità diverso rispetto al resto dei dati aziendali di un’organizzazione. Il Dipartimento della Salute e dei Servizi Umani (DHHS) definisce le PHI come informazioni sanitarie identificabili individualmente relative alle condizioni di salute fisica o mentale passate, presenti o future di una persona, alla prestazione di assistenza sanitaria o al pagamento delle cure.

Una carta di credito può essere invalidata una volta scoperta l’intrusione, con il successivo rilascio di una nuova carta. Ciò non vale per le malattie, i fattori genetici o le diagnosi di salute mentale: tali dati sono davvero permanenti.

Ogni volta che le PHI vengono compromesse, i rischi che tali violazioni comportano vanno ben oltre il semplice furto d’identità. Le cartelle cliniche possono essere utilizzate per escludere i pazienti dalla copertura assicurativa, ostacolare le opportunità lavorative e perpetrare frodi mirate ai danni di anziani e disabili. La riservatezza delle PHI è resa ancora più critica dall’ampiezza delle informazioni che possono essere qualificate come PHI.

Ecco gli esempi più significativi:

• Nome completo e informazioni di contatto collegate a una patologia o a un trattamento
• Date di nascita, ricovero, dimissione o decesso
• Dati geografici a un livello inferiore a quello statale
• Identificatori biometrici quali impronte digitali o impronte vocali
• Qualsiasi altro numero o codice identificativo univoco associato all’assistenza sanitaria

Perché riservatezza, integrità e disponibilità assumono un peso diverso nel settore sanitario?

Riservatezza, integrità e disponibilità (talvolta denominate «triade CIA») si applicano a tutti i protocolli di sicurezza. Tuttavia, gli ambienti cloud del settore sanitario tendono a considerare questi pilastri in modo diverso rispetto alle consuete implementazioni aziendali.

Ad esempio, la disponibilità comporta conseguenze cliniche significative anche a seguito di semplici interruzioni di servizio che non hanno eguali in nessun altro settore. La perdita del servizio non rappresenta semplicemente una perdita di produttività negli ambienti sanitari: comporta l’impossibilità di prescrivere farmaci, di accedere ai risultati degli esami di diagnostica per immagini o di consentire ai paramedici di consultare la cartella clinica del paziente.

Di seguito vengono fornite informazioni più generali su tutti e tre i pilastri sopra menzionati:

In che modo l’esigenza di conservazione a lungo termine e di verificabilità modifica i requisiti di sicurezza?

Le cartelle cliniche e la documentazione di sicurezza associata devono essere conservate per un periodo molto più lungo rispetto ai normali programmi di conservazione dei dati aziendali.

HIPAA (Health Insurance Portability and Accountability Act) stabilisce che i soggetti interessati debbano conservare le proprie politiche, procedure e la relativa documentazione per 6 anni a partire dalla data di creazione o dall’ultima data di entrata in vigore. Tale periodo potrebbe essere ancora più lungo in alcuni stati per quanto riguarda tipi specifici di documentazione.

Anche i controlli di sicurezza nel cloud che supportano e proteggono tali dati devono essere mantenuti per lo stesso periodo di tempo. Tali controlli devono essere applicabili, verificabili e ripristinabili per l’intero periodo di 6 anni.

Tali requisiti influenzano la progettazione più ampia dell’architettura di sicurezza del cloud nel settore sanitario. La gestione delle chiavi per la crittografia, i registri di accesso e l’integrità dei backup: nessuno di questi aspetti può essere considerato semplicemente come una questione operativa a breve termine. Una traccia di audit utile per indagare su una violazione della sicurezza, o un’indagine normativa che potrebbe verificarsi tra cinque anni, dipenderà dai controlli implementati e gestiti oggi.

In che modo la conformità e le normative sanitarie modificano i requisiti di sicurezza del cloud?

Gli obblighi normativi nel settore sanitario non costituiscono semplicemente un quadro aggiuntivo alla sicurezza del cloud. Tali obblighi comportano anche una modifica dei controlli richiesti, dei soggetti responsabili e delle conseguenze in caso di loro mancato rispetto. HIPAA, GDPR, HITECH e un elenco sempre più ampio di normative a livello statale impongono ciascuno i propri requisiti (tecnici e contrattuali) agli ambienti cloud, con cui i quadri di conformità aziendali standard non sono stati concepiti per interagire.

Quali obblighi specifici impongono l’HIPAA, il GDPR e altre normative sanitarie sull’uso del cloud?

Ogni principale quadro normativo ha una propria prospettiva in materia di sicurezza del cloud:

• HIPAA disciplina le informazioni sanitarie protette (PHI) archiviate presso le entità soggette alla normativa con sede negli Stati Uniti e i loro partner commerciali; ciò include anche le soluzioni cloud che archiviano, elaborano e trasmettono dati sensibili dei pazienti per loro conto.
• GDPR si applica alle situazioni in cui sono coinvolti i dati sanitari dei residenti nell’UE, anche se l’infrastruttura di archiviazione cloud si trova altrove.
• HITECH estende e rafforza le capacità di applicazione dell’HIPAA, aumentando i livelli delle sanzioni e ampliando al contempo i requisiti relativi alla notifica obbligatoria delle violazioni.

Gli obblighi imposti da ciascun quadro normativo all’ambiente cloud differiscono in modo significativo l’uno dall’altro in termini di ambito di applicazione, meccanismi e conseguenze:

In che modo i tempi e l’ambito di applicazione delle notifiche di violazione differiscono per le organizzazioni sanitarie?

Le notifiche di violazione dei dati relative alle informazioni sanitarie sono inoltre molto più rigorose (e con una posta in gioco più elevata) rispetto a quelle applicate nella maggior parte dei settori aziendali. I termini sono fissi, i destinatari delle segnalazioni sono diversi e le soglie che determinano i diversi obblighi di notifica sono altamente specifiche:

• 60 giorni – termine massimo entro il quale un soggetto soggetto alla normativa HIPAA deve informare le persone interessate dopo aver scoperto una violazione
• 60 giorni – lo stesso termine si applica alla notifica al Dipartimento della Salute e dei Servizi Umani degli Stati Uniti (HHS)
• Oltre 500 persone interessate – determina l’obbligo di informare i principali organi di informazione dello Stato o della giurisdizione interessati
• Meno di 500 persone – i casi possono essere registrati e segnalati all’HHS con cadenza annuale, ma la notifica individuale deve comunque avvenire entro 60 giorni
• GDPR – richiede la notifica all’autorità di controllo competente entro 72 ore dal momento in cui si viene a conoscenza di una violazione, nonché alle persone interessate senza indebito ritardo qualora sussista un rischio elevato
• Leggi statali – diversi stati impongono scadenze più brevi rispetto ai 60 giorni previsti dall’HIPAA; alcuni richiedono la notifica entro 30 giorni o meno

Tutte queste tempistiche si complicano ulteriormente quando si tratta di ambienti cloud. Ogni volta che le informazioni sanitarie protette (PHI) sono distribuite tra diversi fornitori di servizi cloud, regioni o servizi di terze parti, l’identificazione dell’intera portata di una violazione (ai fini di una notifica accurata) richiede molto più tempo rispetto a quanto avviene in ambienti on-premise circoscritti.

Perché il settore sanitario richiede una verifica della conformità al cloud più rigorosa?

Il principale punto debole di una rigorosa verifica della conformità al cloud nel settore sanitario è che nessuna certificazione di conformità esistente corrisponde direttamente ai requisiti normativi specifici del settore sanitario, e il presupposto di equivalenza rischia potenzialmente di esporre la vostra organizzazione a un rischio di lacuna significativo.

Ad esempio, ogni volta che un fornitore di servizi cloud possiede una certificazione SOC 2 Tipo II o un accreditamento ISO 27001, soddisfa uno standard di sicurezza riconosciuto. Allo stesso tempo, nessuno di questi standard è stato creato tenendo conto delle PHI, della necessità di accessibilità clinica o delle misure tecniche di protezione previste dall’HIPAA.

Una verifica più rigorosa negli ambienti cloud del settore sanitario implica andare oltre le normali revisioni delle certificazioni. Ciò include:

• Verificare che gli accordi BAA riflettano accuratamente le effettive pratiche di trattamento dei dati del fornitore
• Assicurarsi che le configurazioni dei registri di audit soddisfino sia i requisiti di conservazione previsti dall’HIPAA sia quelli a livello statale
• Verificare se le implementazioni di crittografia coprano le PHI inattive, in transito e, soprattutto, durante l’elaborazione

Perché la sicurezza dei pazienti è una questione di sicurezza che l’IT spesso trascura?

La maggior parte dei settori subisce perdite finanziarie, perdita di dati o danni alla reputazione a causa di una violazione della sicurezza. Tuttavia, i problemi di sicurezza nel settore sanitario possono causare lesioni dirette al paziente. Questa distinzione, di per sé, modifica radicalmente il modo in cui vengono stabilite le priorità e gestite le decisioni relative alla sicurezza del cloud.

Perché le organizzazioni sanitarie devono proteggere i dati dei pazienti per garantire un’assistenza sicura?

La disponibilità costante dei dati dei pazienti è indispensabile per l’assistenza clinica. Le ripercussioni di qualsiasi problema in un ambiente cloud (una violazione, un’interruzione di servizio, un evento di danneggiamento dei dati) si propagano immediatamente ben oltre il reparto IT. Ciò include:

• Medici che perdono l’accesso alle anamnesi terapeutiche
• Infermieri che non sono più in grado di accedere ai piani di cura attivi
• Squadre di pronto soccorso costrette a prendere decisioni senza tenere conto del contesto diagnostico fondamentale

La possibilità di accedere ai dati dei pazienti e la disponibilità di dati validi non costituiscono un indicatore di prestazione IT, bensì un indicatore di sicurezza dei pazienti. L’ente sanitario che considera la sicurezza del cloud una questione di «back office» crea un rischio per i pazienti ogni volta che il proprio sistema subisce un’interruzione o che la cartella clinica viene alterata senza alcuna prova.

Perché gli SLA di disponibilità devono essere trattati come controlli del rischio clinico?

La protezione della continuità operativa è senza dubbio uno dei temi centrali di un normale SLA aziendale. Negli ambienti cloud del settore sanitario, questo documento deve fungere da controllo del rischio clinico, tenendo conto delle conseguenze che un periodo di inattività comporterebbe per i pazienti.

Le garanzie generiche di uptime non sono in grado di affrontare le realtà operative degli ambienti clinici. Uno SLA che disciplina un’implementazione cloud nel settore sanitario dovrebbe specificare:

• Obiettivo di tempo di ripristino (RTO) allineato alla criticità del flusso di lavoro clinico – l’accesso alla cartella clinica elettronica (EHR), ad esempio, richiede un RTO molto più breve rispetto ai sistemi di fatturazione
• Obiettivo di punto di ripristino (RPO) sufficientemente rigoroso da impedire la perdita di dati clinicamente rilevanti tra l’ultimo backup e il momento del guasto
• Finestre di manutenzione programmata pianificate in base ai periodi di bassa affluenza, non alle normali ore non di punta
• Procedure di escalation che indirizzino le notifiche di interruzioni critiche direttamente alla direzione delle operazioni cliniche, non solo all’IT
• Supporto alle procedure in caso di interruzioni – documentazione o strumenti che consentano flussi di lavoro clinici manuali quando i sistemi cloud non sono disponibili

In che modo i team di sicurezza e protezione dovrebbero collaborare in modo diverso rispetto ai team standard di IT e sicurezza?

In un tipico ambiente aziendale, il team di sicurezza definisce i controlli mentre i team IT li implementano. Il contributo clinico è raramente coinvolto in nessuno di questi processi.

Operare con le tecnologie cloud nel settore sanitario richiede un modello operativo completamente nuovo che trasformi il ruolo dei responsabili della sicurezza dei pazienti, dei team di informatica clinica e degli ingegneri biomedici: da semplici destinatari del flusso di lavoro relativo alle decisioni di sicurezza, essi diventano partecipanti a pieno titolo a quello stesso flusso di lavoro.

Questo modello modifica anche il modo in cui il rischio viene considerato nella sua totalità. Un team di sicurezza incaricato di decidere se sia necessaria un’ulteriore autenticazione avrà bisogno del contributo clinico per valutare in che modo l’aumento dei controlli influisca sul flusso di lavoro del pronto soccorso. Un ingegnere biomedico che intenda gestire l’integrazione della connettività deve poter visionare tutte le segmentazioni del cloud che incidono sulla comunicazione tra i dispositivi.

Le politiche di sicurezza progettate senza considerare gli aspetti clinici tendono a essere aggirate (non perché qualcuno sia negligente, ma perché introducono attriti che impediscono al personale sanitario di operare correttamente). Una collaborazione adeguata tra sicurezza operativa e sicurezza informatica nel contesto sanitario è un requisito strutturale, non una best practice facoltativa.

In che modo la sicurezza del cloud nel settore sanitario modifica il modello di responsabilità condivisa?

Il modello di responsabilità condivisa di solito specifica in che modo e in che misura l’onere della sicurezza sia ripartito tra il fornitore di servizi cloud e il cliente. Questa ripartizione è molto più complessa negli ambienti sanitari, poiché il semplice fatto di ospitare informazioni sanitarie protette (PHI) non esonera l’organizzazione dalla responsabilità normativa. Nel contempo, i meccanismi contrattuali che regolano tale responsabilità devono essere ben più precisi rispetto a quelli utilizzati per i normali accordi aziendali.

Quali responsabilità spettano al fornitore di servizi cloud e quali all’organizzazione sanitaria?

Il modello standard di responsabilità condivisa assegna la sicurezza dell’infrastruttura al fornitore, mentre la sicurezza dei dati è di competenza del cliente. Questa separazione rimane valida negli ambienti cloud del settore sanitario, ma la portata degli obblighi di ciascuna parte si amplia notevolmente quando sono coinvolte le informazioni sanitarie protette (PHI):

Perché le ipotesi relative alle protezioni gestite dai fornitori possono esporre dati sensibili e informazioni sanitarie protette (PHI)?

Sorprendentemente, gli attacchi complessi non rappresentano la principale fonte di vulnerabilità nel cloud sanitario. Tale primato spetta piuttosto ai problemi derivanti da un ambiente configurato in modo errato, realizzato sulla base di ipotesi non verificate.

Non è raro che le organizzazioni sanitarie diano per scontato che un fornitore di servizi cloud conforme alla normativa HIPAA garantisca automaticamente, per impostazione predefinita, la conformità HIPAA anche dell’ambiente al suo interno. Tale presupposto è errato. Ciò che i fornitori possono fare è offrire tutte le funzionalità tecniche necessarie per garantire il rispetto dei requisiti di conformità, ma la configurazione, l’applicazione e la verifica dei risultati di tali funzionalità sono di competenza del cliente.

Possiamo prendere come primo esempio la crittografia dei dati inattivi. Essa può essere abilitata di default sull’archiviazione primaria, ma non sui livelli di backup, sulle esportazioni dei log o sugli ambienti di elaborazione temporanea in cui le PHI transitano durante i flussi di lavoro analitici. La registrazione degli audit potrebbe essere attivata di default, ma non al livello di granularità necessario. I bucket di archiviazione a oggetti che contengono dati sanitari protetti (PHI) potrebbero essere stati creati con politiche di accesso poco rigorose durante una migrazione e non essere mai stati resi più restrittivi in seguito.

Ognuna di queste lacune risulterebbe quasi invisibile durante le operazioni di routine, mentre risalterebbe enormemente nel corso di un audit normativo o di un’indagine su una violazione.

Quali misure di sicurezza dovrebbero includere i contratti e gli SLA per gli ambienti sanitari nel cloud?

Un Accordo di Collaborazione Commerciale (BAA) firmato rappresenta il requisito contrattuale minimo indispensabile per qualsiasi ambiente cloud che interagisca con le PHI – e anche in tal caso, il BAA da solo non è sufficiente. I contratti relativi al cloud nel settore sanitario devono essere in grado di affrontare obblighi di sicurezza che vanno ben oltre qualsiasi condizione commerciale standard:

• Ambito di applicazione del BAA e copertura dei subappaltatori – l’accordo deve indicare esplicitamente o coprire in modo categorico tutti i subappaltatori che potrebbero avere accesso alle PHI
• Diritti di verifica – l’organizzazione sanitaria deve riservarsi il diritto di condurre o commissionare valutazioni di sicurezza dell’ambiente del fornitore
• Tempi di notifica degli incidenti – i contratti dovrebbero specificare tempi di notifica dal fornitore al cliente inferiori al limite massimo di 60 giorni previsto dall’HIPAA, concedendo all’organizzazione sanitaria il tempo necessario per adempiere ai propri obblighi di segnalazione
• Proprietà delle chiavi di crittografia – gli accordi dovrebbero chiarire se l’organizzazione sanitaria controlli le proprie chiavi di crittografia o si affidi a chiavi gestite dal fornitore, e quale accesso il fornitore mantenga
• Residenza e sovranità dei dati – i contratti devono specificare i confini geografici per l’archiviazione e il trattamento delle PHI, in particolare quando si applicano i requisiti di localizzazione dei dati previsti dal GDPR o a livello statale
• Cancellazione verificata dei dati – le clausole di risoluzione devono richiedere la conferma scritta della cancellazione delle PHI da tutti i livelli di archiviazione, inclusi i backup e gli ambienti di disaster recovery
• Impegni relativi al tempo di attività e all’RTO – le garanzie di disponibilità devono essere calibrate in base alle esigenze cliniche, non generiche

In che modo l’interoperabilità e lo scambio di dati modificano il modello di minaccia?

Gli ambienti cloud nel settore sanitario non possono essere sistemi chiusi per loro stessa natura. I mandati normativi, i requisiti di coordinamento dell’assistenza e gli obblighi di accesso dei pazienti richiedono tutti che i dati siano trasferibili – tra fornitori, pazienti, enti pagatori e applicazioni di terze parti.

Tale natura aperta non costituisce affatto una falla di sicurezza, bensì un requisito di progettazione. Purtroppo, proprio questo requisito contribuisce all’enorme espansione della superficie di attacco di cui i programmi di sicurezza sanitaria devono tenere conto.

Perché le API, le integrazioni FHIR e la connettività delle cartelle cliniche elettroniche aumentano i rischi per la sicurezza nel cloud?

Il 21st Century Cures Act, insieme alle successive norme di interoperabilità del CMS, impone alle organizzazioni sanitarie di rendere accessibili i dati dei pazienti tramite API FHIR (Fast Healthcare Interoperability Resources) standardizzate. Ciò trasforma lo scambio di dati con soggetti esterni in un obbligo legale, anziché in una mera scelta architettonica.

Ogni endpoint API che fornisce informazioni sanitarie protette (PHI) a un utente autorizzato può rappresentare anche un potenziale punto di accesso per soggetti non autorizzati. La superficie di attacco creata dall’interoperabilità non è accidentale, ma strutturale – e cresce con ogni nuova integrazione abilitata dalle organizzazioni sanitarie.

La connettività con i sistemi EHR non fa che aggravare ulteriormente questo problema. Le moderne piattaforme EHR si integrano regolarmente con ambienti di analisi ospitati nel cloud, portali di coinvolgimento dei pazienti, strumenti per la salute della popolazione e sistemi dei pagatori. Ciascuna di queste connessioni rappresenta un flusso di dati che deve essere autenticato, crittografato, monitorato e sottoposto a revisione periodica.

Il modello di minaccia degli ambienti sanitari non è statico, ma si espande con ogni nuova integrazione approvata – e raramente si riduce quando le integrazioni vengono sostituite o dismesse.

Come si dovrebbero garantire l’autenticazione, gli scambi di token e la crittografia dei dati per i flussi di lavoro clinici?

I modelli di autenticazione aziendali tipici funzionano in ambienti controllati in cui gli utenti effettuano l’accesso da dispositivi noti all’interno di reti gestite. I flussi di lavoro clinici non funzionano in questo modo. I medici devono accedere a sistemi ospitati nel cloud da postazioni di lavoro condivise, dispositivi personali e sedi remote – spesso sotto pressione temporale, il che rende un’autenticazione troppo complessa un vero e proprio rischio per l’assistenza.

SMART (Substitutable Medical Applications, Reusable Technologies) su FHIR è un framework di autorizzazione basato su OAuth 2.0 progettato specificamente per i contesti delle applicazioni cliniche, che rappresenta l’attuale standard di riferimento per garantire l’accesso basato su token alle API FHIR.

Tuttavia, la qualità della sua implementazione varia a seconda dei fornitori e delle implementazioni. Le finestre di scadenza dei token, le limitazioni di ambito e la gestione dei token di aggiornamento richiedono tutte una configurazione esplicita, poiché le impostazioni predefinite privilegiano regolarmente la praticità a scapito della sicurezza.

Oltre all’autenticazione, è obbligatorio l’uso del protocollo TLS su tutti i flussi di dati PHI, e la crittografia dovrebbe estendersi ai dati inattivi all’interno di qualsiasi sistema cloud che riceva informazioni da una cartella clinica elettronica (EHR) o da un’integrazione API.

Le aree chiave che richiedono un’attenzione esplicita anziché affidarsi alle impostazioni predefinite:

• Ambito del token limitato all’accesso minimo necessario ai dati
• Token di accesso a breve durata con politiche di aggiornamento controllate
• TLS reciproco per le connessioni API da server a server
• Crittografia verificata su tutti i livelli di archiviazione che ricevono dati PHI provenienti dalle API

In che modo la connettività delle app di terze parti aumenta i rischi legati alla catena di approvvigionamento e ai movimenti laterali?

Le aziende sanitarie che collegano applicazioni di terze parti ai propri ambienti cloud ereditano una parte del livello di sicurezza di ciascun fornitore, indipendentemente dal fatto che lo abbiano valutato o meno.

Un’applicazione rivolta ai pazienti con accesso in scrittura alla cartella clinica elettronica (EHR), uno strumento di analisi della salute della popolazione con ampie autorizzazioni di interrogazione dei dati o un’integrazione di fatturazione con accesso ai dati relativi alle richieste di rimborso e ai dati demografici rappresentano ciascuno un potenziale punto di ingresso nella catena di approvvigionamento. Se un’applicazione di terze parti viene compromessa, un aggressore può acquisire qualsiasi diritto di accesso di cui tale applicazione disponga. Negli ambienti cloud del settore sanitario, tale accesso spesso comprende percorsi di accesso a sistemi che contengono PHI su larga scala.

I questionari periodici sulla sicurezza dei fornitori raramente sono sufficienti a mettere in luce i rischi specifici introdotti dalle integrazioni delle API cliniche, e il monitoraggio continuo del comportamento delle connessioni di terze parti non è ancora una pratica diffusa in tutto il settore.

Perché i controlli di identità e di accesso sono fondamentali per la sicurezza del cloud nel settore sanitario?

Controllare chi può accedere a cosa e in quali circostanze rappresenta una delle maggiori sfide di sicurezza per qualsiasi ambiente cloud. Per quanto riguarda il settore sanitario, tale sfida è ulteriormente amplificata dall’enorme varietà di persone che necessitano di accesso a sistemi sensibili, dall’urgenza con cui talvolta tale accesso è richiesto e dalle gravi conseguenze derivanti sia da un’eccessiva restrizione che da una restrizione insufficiente dell’accesso.

In che modo le esigenze di accesso basate sui ruoli e sugli attributi variano tra gli utenti clinici e quelli amministrativi?

I controlli di accesso basati sui ruoli (RBAC) si fondano sul principio di assegnare le autorizzazioni di sistema in base al ruolo professionale dell’utente anziché alla sua identità individuale. Un coordinatore della fatturazione ha accesso ai registri finanziari. Un radiologo ha accesso ai sistemi di imaging. Un infermiere di reparto ha accesso ai registri di somministrazione dei farmaci relativi al reparto a lui assegnato.

L’RBAC costituisce la base di riferimento nella gestione dell’accesso al cloud sanitario e riduce notevolmente la possibilità che gli utenti debbano visualizzare informazioni che non sono di loro competenza dal punto di vista clinico o operativo (se implementato correttamente).

Il problema principale in questo contesto è che i ruoli sanitari raramente possono essere suddivisi in categorie ben definite. I controlli di accesso basati sugli attributi (ABAC) ampliano il modello RBAC aggiungendo vari fattori contestuali: il reparto in cui l’utente sta attualmente lavorando, l’ora del giorno, il paziente specifico che sta curando o il fatto che stia accedendo al sistema da un dispositivo autorizzato su una rete interna.

Un medico che opera in più reparti, un infermiere specializzato con autorizzazioni in due strutture o un coordinatore dell’assistenza che opera sia in ambito ospedaliero che ambulatoriale presentano tutti esigenze di accesso complesse che una definizione statica dei ruoli avrebbe difficoltà a soddisfare in modo chiaro. L’ABAC consente di esprimere sfumature come queste sotto forma di politica, anziché gestirle come eccezioni.

Perché l’accesso contestuale basato sul principio del «minimo privilegio» è fondamentale negli scenari di assistenza al letto del paziente e di emergenza?

L’accesso basato sul principio del «minimo privilegio» è una pratica di sicurezza consolidata: il principio secondo cui ogni utente dovrebbe avere accesso solo al minimo indispensabile di dati e sistemi necessari per l’attività che sta svolgendo. Nella maggior parte degli ambienti aziendali, l’applicazione di questa pratica è principalmente un esercizio tecnico e amministrativo. Nel settore sanitario, tuttavia, tale pratica è in netto contrasto con la realtà delle cure di emergenza.

Un medico traumatologo che si occupa di un paziente incosciente giunto in ospedale senza documenti di identità necessita di un accesso immediato a tutte le cartelle cliniche del paziente (la sua anamnesi allergica, i farmaci attualmente assunti e le diagnosi precedenti). Il fatto che tale medico possa non avere alcun precedente rapporto terapeutico con il paziente implica che un’applicazione rigorosa del modello del «minimo privilegio» finirà per bloccare proprio quell’accesso che l’assistenza medica richiede.

È qui che entra in gioco il modello di accesso «break-glass». Si tratta di un meccanismo di deroga controllato che consente al personale clinico di aggirare le restrizioni di accesso standard in caso di vere emergenze, registrando al contempo ogni azione intrapresa durante quella sessione per una successiva revisione.

L’accesso “break-glass” non rappresenta una vulnerabilità di sicurezza, bensì una valvola di sicurezza deliberata e verificabile. Tuttavia, può diventare un problema di sicurezza quando è definito in modo inadeguato, registrato in modo incoerente o utilizzato con una frequenza tale da perdere ogni significato come eccezione.

Ecco perché sono necessarie politiche di accesso sensibili al contesto. Esse tengono conto dell’ubicazione del paziente, dell’assegnazione del team di cura e dell’urgenza clinica per ridurre la frequenza di utilizzo del modello “break-glass” senza eliminarlo come opzione.

Come dovrebbero essere regolati e verificati gli accessi temporanei, contingenti e dei fornitori?

Gli ambienti cloud nel settore sanitario ospitano spesso utenti le cui esigenze di accesso sono, per impostazione predefinita, limitate nel tempo. Tra questi figurano infermieri itineranti e medici sostituti che coprono carenze a breve termine, fornitori terzi che eseguono la manutenzione dei sistemi, consulenti di implementazione con privilegi amministrativi temporanei e revisori esterni che esaminano la documentazione di conformità. Concedere l’accesso a uno qualsiasi di questi utenti rappresenta un rischio che continua ad aumentare ogni volta che non viene gestito attivamente.

I requisiti fondamentali sono chiari, anche se la loro applicazione coerente non lo è:

• Le autorizzazioni di accesso per gli utenti temporanei devono riportare date di scadenza esplicite, stabilite al momento del provisioning
• L’accesso dei fornitori e delle terze parti deve essere limitato ai sistemi e ai dati specifici necessari per l’incarico – nulla di più ampio
• Tutte le sessioni di accesso temporaneo devono essere registrate con dettagli sufficienti a supportare una traccia di audit completa
• Le revisioni degli accessi devono essere programmate in modo proattivo, anziché essere attivate solo da eventi di cessazione del rapporto

La situazione di fallimento più comune non è nemmeno di natura dolosa, ma amministrativa. Ciò include credenziali temporanee che non sono mai state revocate, account dei fornitori che sono rimasti attivi oltre la durata dell’incarico e accessi degli appaltatori che si sono estesi in modo incrementale senza una revisione formale.

In che modo i dispositivi medici e l’IoT modificano i requisiti di sicurezza del cloud?

I dispositivi medici e le apparecchiature cliniche connesse rientrano in una categoria di rischio a sé stante che non può essere adeguatamente affrontata dalle linee guida standard relative all’IoT. Tali dispositivi non sono semplici sensori per edifici o termostati intelligenti, bensì sistemi critici per la sicurezza con un impatto diretto sui pazienti: ecco perché i vincoli di sicurezza a cui sono soggetti differiscono sostanzialmente da qualsiasi altro elemento in un tipico ambiente cloud.

Perché i vincoli dei dispositivi (sistemi operativi obsoleti, possibilità limitate di applicazione delle patch) sono importanti per l’integrazione nel cloud?

Molti dispositivi medici (pompe di infusione, sistemi di imaging, monitor paziente, ventilatori) utilizzano sistemi operativi obsoleti. Windows 7, Windows XP e piattaforme ancora più datate rimangono attivamente in uso clinico ancora oggi. Ciò accade solitamente quando i produttori dei dispositivi sviluppano e certificano il proprio software in base a una versione specifica del sistema operativo, il che significa che la sostituzione o l’aggiornamento di tale software richiederebbe di sottoporsi nuovamente all’intera procedura di revisione normativa della FDA.

Questo è il motivo principale per cui l’applicazione delle patch – il meccanismo più elementare per risolvere le vulnerabilità del software – non è disponibile per gran parte dei dispositivi che si connettono agli ambienti cloud sanitari.

Un dispositivo che non può essere aggiornato con patch non può essere considerato sicuro nel senso convenzionale del termine. Ogni volta che tali dispositivi devono trasmettere dati telemetrici di vario tipo alle piattaforme cloud o ricevere aggiornamenti di configurazione da sistemi di gestione ospitati nel cloud, la sicurezza di tale connessione deve essere gestita esclusivamente dal lato della rete o del cloud, poiché il dispositivo stesso non è in grado di offrire praticamente nulla al riguardo.

Come dovrebbero essere progettati la telemetria, l’identità del dispositivo e la segmentazione per i dispositivi critici per la sicurezza?

La segmentazione della rete costituisce la prima linea di difesa negli ambienti sanitari. I dispositivi medici dovrebbero essere mantenuti all’interno di segmenti di rete isolati, con accesso solo ai sistemi cloud specifici di cui hanno bisogno. Un monitor paziente non dovrebbe essere in grado di stabilire una connessione con l’archiviazione cloud, i server di amministrazione, la rete esterna o qualsiasi altra cosa, ad eccezione di quel particolare sistema cloud. La segmentazione non risolve la vulnerabilità del dispositivo stesso, ma può almeno limitare il «raggio d’azione» di una delle vulnerabilità sfruttate.

L’identità del dispositivo è altrettanto importante. Ogni dispositivo che si connette a un ambiente cloud deve dimostrare la propria identità utilizzando credenziali univoche (idealmente, un certificato associato al dispositivo, non solo semplici dati di accesso). In questo modo, eventuali dispositivi che presentano modelli di comportamento inattesi possono essere identificati e gestiti senza influire sugli altri dispositivi presenti nella stessa rete. Anche la possibilità di mantenere un inventario accurato dei dispositivi connessi in qualsiasi momento rappresenta un vantaggio.

I flussi di telemetria provenienti dai dispositivi medici devono inoltre essere monitorati per individuare eventuali anomalie. Qualsiasi tipo di andamento insolito può costituire un indicatore di compromissione o di configurazione errata (che si tratti di volumi di dati insoliti, destinazioni di connessione inaspettate o modelli di comunicazione che esulano dal comportamento normale di un dispositivo).

In che modo l’analisi lato cloud può comportare rischi per la privacy dei dati generati dai dispositivi?

Esiste un presupposto diffuso riguardo alla telemetria dei dispositivi, secondo cui tali dati sarebbero per loro natura a bassa sensibilità, più simili all’output di una macchina che alle informazioni sanitarie protette (PHI). Tale presupposto è spesso errato.

I flussi continui di dati provenienti da dispositivi quali glucometri, unità di telemetria cardiaca o monitor respiratori possono contenere informazioni sufficienti per identificare pazienti specifici, dedurre diagnosi e ricostruire le cronologie delle cure (anche dopo aver rimosso gli identificatori evidenti). Ogni volta che tali dati vengono trasferiti a piattaforme di analisi basate sul cloud, possono essere aggregati, conservati, condivisi con fornitori di analisi di terze parti o persino utilizzati per addestrare modelli in modi insoliti.

Il rischio di reidentificazione per i dati sanitari generati dai dispositivi è significativo e spesso sottovalutato. La criticità di tali informazioni implica che esse meritino almeno lo stesso trattamento riservato alle PHI, al pari di qualsiasi dato etichettato come cartella clinica.

Cosa si rendono conto solitamente troppo tardi le organizzazioni sanitarie dopo aver trasferito dati sensibili sul cloud?

Nel settore sanitario, l’adozione del cloud spesso precede lo sviluppo di programmi di sicurezza progettati a supporto di tale adozione. Le lacune di sicurezza che emergono a causa di questo problema spesso passano inosservate finché non si verifica un problema.

Perché gli ambienti cloud tecnicamente conformi continuano a subire violazioni dei dati sanitari?

Le valutazioni di conformità normativa possono solo verificare se i controlli di sicurezza necessari siano presenti in un determinato momento. Tali test non sono in grado di determinare se tali controlli continueranno a funzionare correttamente diversi mesi dopo, una volta che l’ambiente circostante sia cambiato.

L’infrastruttura cloud di per sé è raramente statica e inattiva. Gli sviluppatori attivano nuove risorse di archiviazione, vengono aggiunte regolarmente integrazioni tra i sistemi e le autorizzazioni vengono spesso modificate per risolvere rapidamente i problemi di accesso (senza mai essere riviste in seguito). Nessuna di queste modifiche, di per sé, darà luogo a una verifica di conformità, ma ogni singola modifica di questo tipo può comunque essere considerata un’opportunità per l’ambiente di allontanarsi dallo stato che gli ha permesso di superare l’ultimo audit.

Argomenti come questi devono essere menzionati perché la configurazione errata rimane ancora oggi la causa principale delle violazioni dei dati nel cloud: nessuno dei sofisticati attacchi da parte di Stati-nazione o degli exploit zero-day si avvicina nemmeno lontanamente a essa. Una parte sostanziale degli incidenti nel cloud nel settore sanitario è il risultato di:

• Bucket di archiviazione esposti
• Politiche di accesso eccessivamente permissive
• Registrazione disabilitata

È piuttosto comune che un’organizzazione sanitaria superi un audit HIPAA per poi subire, solo pochi mesi dopo, una violazione che si sarebbe potuta evitare. Al momento dell’audit non vi era nulla di errato nell’ambiente dell’organizzazione, ma l’ambiente stesso è cambiato. Ecco perché la conformità è uno stato, non una garanzia.

In che modo le ipotesi relative alla migrazione al cloud indeboliscono silenziosamente la sicurezza del cloud nel settore sanitario?

L’errore più grave che si possa commettere nella migrazione è presumere che i controlli di sicurezza on-premise funzioneranno esattamente allo stesso modo una volta trasferiti nel cloud. Questo approccio viene talvolta definito lift-and-shift: consiste nel prendere i carichi di lavoro preesistenti e spostarli nell’infrastruttura cloud senza apportare alcuna modifica per adattarli al nuovo ambiente. Si tratta di una soluzione rapida ad alcuni problemi, ma è anche estremamente rischiosa.

• Le regole del firewall che proteggevano un data center non regolano i bucket di archiviazione nel cloud
• I perimetri di rete che limitavano i movimenti laterali in locale non esistono allo stesso modo in un ambiente cloud
• I controlli di accesso che un team IT in loco gestiva manualmente non vengono trasferiti insieme ai dati e devono essere ricostruiti appositamente nel cloud

La causa principale di quasi tutte le vulnerabilità legate alla migrazione si riduce alla confusione che circonda il modello di responsabilità condivisa. Le aziende che migrano i propri dati verso un provider cloud presumono che le impostazioni di sicurezza predefinite del provider coprano ciò che il loro team interno era solito fare in locale – ma non è così.

Uno dei riscontri più ricorrenti dopo la migrazione riguarda i ruoli di gestione delle identità e degli accessi (IAM) con autorizzazioni eccessive: configurazioni create con ampie capacità di accesso durante la migrazione per evitare intoppi, contrassegnate come temporanee e mai rimosse in seguito. Questi ruoli possono rimanere inattivi nell’ambiente per lungo tempo, fornendo agli aggressori che sono riusciti a raggiungerli un livello di accesso ben superiore a quello che dovrebbe mai essere concesso a un singolo utente.

Problemi come questi non sono mai drammatici né evidenti, poiché i sistemi continuano a funzionare, i log continuano a essere generati e così via. I problemi iniziano a manifestarsi durante un incidente, quando si scopre che il bucket configurato in modo errato era accessibile da mesi, oppure che il ruolo dotato di autorizzazioni eccessive disponeva di accesso in lettura a ogni set di dati contenente informazioni sanitarie protette (PHI) presente nell’ambiente.

Perché i fallimenti nel backup e nel ripristino sono spesso più dannosi dell’attacco cloud originario?

Molti attacchi cloud possono solo interrompere le operazioni nel momento stesso in cui si verificano. Un evento di ripristino fallito, d’altra parte, rischia di prolungare tale interruzione a tempo indeterminato.

Non è poi così raro che le organizzazioni sanitarie scoprano problemi critici relativi ai propri backup su cloud durante attacchi ransomware – proprio quando meno se lo possono permettere. Tra questi figurano:

• I backup erano archiviati nello stesso ambiente dei sistemi primari e crittografati insieme a essi
• I processi di backup risultavano completati con successo sulla dashboard, ma i dati ripristinati erano incompleti o danneggiati
• Il ripristino non era mai stato testato end-to-end in uno scenario realistico
• Le politiche di conservazione erano impostate in modo errato, lasciando punti di ripristino troppo lontani nel tempo per essere clinicamente utilizzabili

Il secondo punto relativo ai report sui backup merita particolare attenzione. Le dashboard dei backup, per loro natura, segnalano il completamento dei processi, non il successo del ripristino. È del tutto possibile che un’operazione si concluda senza errori pur creando un backup che non può essere utilizzato per ripristinare un sistema funzionante. L’unico modo per sapere se un backup funziona è testarlo – ma il test è un’attività che troppe aziende tralasciano regolarmente.

I backup immutabili rappresentano la contromisura diretta al rischio legato ai backup nell’era del ransomware. Si tratta di copie che possono essere scritte una sola volta, senza la possibilità di modificarle, cancellarle o crittografarle in seguito. L’immutabilità non impedisce che si verifichi un attacco, ma può garantire che il ripristino rimanga possibile anche dopo che l’attacco si è verificato.

L’assenza di backup immutabili rappresenta un problema critico, poiché molti autori di attacchi ransomware che dispongono di accesso sufficiente ai sistemi primari spesso hanno accesso anche ai backup, con la possibilità di compromettere alla radice qualsiasi piano di backup.

Come si svolge tipicamente una violazione dei dati nel cloud nel settore sanitario moderno?

Le violazioni negli ambienti cloud del settore sanitario raramente hanno origine da un exploit tecnico complesso. Questi eventi iniziano con una persona e da lì si intensificano rapidamente.

In che modo gli autori degli attacchi passano dal phishing alla compromissione dei sistemi sanitari basati sul cloud?

Di solito è sufficiente una singola e-mail per innescare l’intera catena. Qualsiasi membro del personale potrebbe cliccare su un link che sembra una normale richiesta di identificazione IT o un aggiornamento del portale pazienti. Una volta inserite le credenziali, l’attacco passa a una fase diversa.

Il percorso dal phishing all’accesso all’ambiente cloud è molto più breve di quanto la maggior parte delle aziende creda, poiché gran parte del personale sanitario utilizza ancora lo stesso set di credenziali su sistemi diversi (mentre le console di gestione del cloud sono accessibili da qualsiasi browser).

Non è necessario che un aggressore violi un perimetro di sicurezza quando dispone di una combinazione valida di nome utente e password: può semplicemente effettuare l’accesso come qualsiasi altro utente.

Una volta ottenuto l’accesso, l’attenzione si sposta sull’espansione e sulla persistenza. L’autore dell’attacco cerca di individuare gli ambienti di archiviazione cloud che contengono il maggior volume di dati, gli account di servizio con le autorizzazioni più ampie e i sistemi collegati che potrebbero essere utilizzati per acquisire ulteriori informazioni sanitarie protette (PHI).

La maggior parte degli attacchi ai cloud nel settore sanitario raggiunge la fase di esfiltrazione delle informazioni sanitarie protette (PHI) entro pochi giorni dall’accesso iniziale. Quando il comportamento anomalo viene rilevato, è altamente probabile che l’autore dell’attacco abbia già raggiunto l’obiettivo prefissato.

Perché le piattaforme di archiviazione cloud e le API del settore sanitario sono sempre più prese di mira?

Sia le API del settore sanitario che le piattaforme di archiviazione cloud sono prese di mira principalmente a causa del loro enorme ritorno sull’investimento.

È sufficiente un unico bucket di archiviazione cloud configurato in modo errato in un ambiente sanitario per esporre milioni di cartelle cliniche dei pazienti. Nel frattempo, le credenziali API compromesse sarebbero in grado di offrire un accesso continuo e autenticato a un flusso di dati aggiornato in tempo reale.

I dati sanitari rappresentano una merce molto più preziosa sui mercati criminali rispetto ai dati finanziari. Una cartella clinica completa vale molte volte di più di un numero di carta di credito, poiché contiene dati immutabili che possono essere sfruttati in molteplici modi per un periodo di tempo prolungato.

Anche la natura accessibile delle API le rende obiettivi allettanti. Un’API è necessaria per trasferire le informazioni tra i sistemi in modo fluido, il che le rende raggiungibili, funzionali e interrogabili su larga scala senza far scattare molti allarmi nell’ambiente.

Quali interruzioni operative si verificano dopo che gli aggressori hanno ottenuto l’accesso agli ambienti cloud del settore sanitario?

Una violazione del cloud nel settore sanitario ha un impatto clinico e operativo di vasta portata che va ben oltre i sistemi compromessi stessi. Tra le interruzioni più comuni figurano:

• Indisponibilità delle cartelle cliniche elettroniche (EHR) – il personale clinico perde l’accesso alle anamnesi farmacologiche, ai piani di cura e ai risultati diagnostici, costringendo a ricorrere a processi manuali cartacei
• Deviazione delle ambulanze – gli ospedali che operano secondo procedure di emergenza possono dichiarare lo stato di emergenza interna, reindirizzando i pazienti in arrivo verso altre strutture
• Interventi annullati – gli interventi chirurgici elettivi e non urgenti, gli appuntamenti per esami di diagnostica per immagini e le visite ambulatoriali vengono rinviati quando i sistemi che supportano i controlli pre-intervento sono offline
• Ritardi nella dispensazione dei farmaci – i sistemi di prescrizione elettronica smettono di funzionare, introducendo rischi nel momento della somministrazione dei farmaci
• Paralisi della fatturazione e delle richieste di rimborso – i sistemi del ciclo di fatturazione che dipendono dall’infrastruttura cloud smettono di funzionare, creando arretrati finanziari che persistono a lungo anche dopo il ripristino dei sistemi clinici
• Esposizione normativa e legale – gli obblighi di notifica delle violazioni si attivano immediatamente, aggiungendo un carico di lavoro in materia di conformità proprio nel momento in cui il ripristino operativo sta assorbendo la massima capacità organizzativa

Le interruzioni cliniche potrebbero essere risolte nel giro di pochi giorni o settimane, ma le conseguenze normative, legali e reputazionali di un singolo attacco tendono a durare molto più a lungo.

Perché la risposta agli incidenti e l’analisi forense devono essere personalizzate per i cloud del settore sanitario?

L’obiettivo primario della risposta agli incidenti per la maggior parte dei settori è contenere la minaccia e ripristinare l’ambiente. Il settore sanitario aggiunge a ciò un ulteriore obiettivo: garantire la sicurezza dei pazienti durante il processo. Inoltre, questi due obiettivi non sempre puntano nella stessa direzione.

In che modo la necessità di una rapida continuità clinica modifica le strategie di contenimento degli incidenti?

Le dottrine standard di risposta agli incidenti si basano in larga misura sull’isolamento. Ogni volta che un sistema viene compromesso, viene messo offline e scollegato dalla rete per impedire che l’attacco si diffonda. Si tratta di un approccio valido per la maggior parte dei sistemi a supporto delle operazioni aziendali. Purtroppo, lo stesso non si può dire per i sistemi che supportano l’assistenza attiva ai pazienti.

Mettere fuori linea una cartella clinica elettronica (EHR) durante un incidente in corso impedisce al personale clinico di accedere alle cartelle terapeutiche, alle anamnesi allergiche e ai dati di monitoraggio in tempo reale. Il tentativo di isolare un ambiente cloud che supporta la telemetria in terapia intensiva o la dispensazione farmaceutica comporta un rischio clinico diretto. L’azione di contenimento stessa può causare danni, motivo per cui i team di risposta agli incidenti negli ambienti sanitari non possono limitarsi a seguire il consueto manuale operativo utilizzato da tutti.

In questo caso è necessario un approccio più mirato. Anziché procedere a un isolamento generalizzato, i team di risposta agli incidenti (IR) del settore sanitario devono disporre di strategie di contenimento predefinite in grado di distinguere tra i sistemi che possono essere messi offline e gli ambienti che devono rimanere disponibili a tutti i costi. Tutte queste decisioni devono essere prese con largo anticipo rispetto al verificarsi di un incidente, poiché prendere decisioni in tempo reale su quali sistemi clinici possano essere interrotti in sicurezza durante una violazione della sicurezza è una pratica ad alto rischio.

Quali controlli forensi e registrazioni sono necessari per supportare sia le indagini legali che quelle cliniche?

La maggior parte delle violazioni tipiche nel settore sanitario che coinvolgono il cloud richiede almeno due indagini concomitanti:

1. La verifica della conformità e del contenzioso
2. La verifica della compromissione dei dati clinici e dell’impatto sulle decisioni relative all’assistenza ai pazienti

L’elemento critico che ogni indagine cercherà si baserà esattamente sulle stesse prove: i registri. Praticamente tutto il valore forense di un ambiente cloud è determinato dalle decisioni relative alla registrazione prese ben prima dell’incidente. Le prove che non sono state acquisite non possono essere recuperate a posteriori.

I requisiti fondamentali di registrazione per gli ambienti cloud nel settore sanitario includono:

• Registri di accesso che coprano ogni interazione con le informazioni sanitarie protette (PHI) — chi vi ha avuto accesso, quando, da dove e quali azioni sono state intraprese
• Registri di autenticazione, inclusi i tentativi di accesso non riusciti, gli eventi di bypass dell’autenticazione a più fattori (MFA) e l’escalation dei privilegi
• Registri delle chiamate API che acquisiscano tutte le richieste alle interfacce di gestione del cloud e alle API dei dati sanitari
• Registri dei flussi di rete sufficienti a ricostruire i movimenti laterali e i percorsi di esfiltrazione dei dati
• Registri delle modifiche di configurazione che tracciano le modifiche alle autorizzazioni di archiviazione, ai ruoli IAM e alle regole dei gruppi di sicurezza

I periodi di conservazione di questi registri devono essere allineati sia al requisito di documentazione di sei anni previsto dall’HIPAA sia a qualsiasi normativa statale applicabile. I registri devono essere archiviati separatamente dai sistemi che monitorano, al fine di impedire che un aggressore che abbia ottenuto l’accesso all’infrastruttura primaria possa alterare o cancellare le prove.

In che modo le esercitazioni teoriche e i playbook dovrebbero differenziarsi dagli scenari esclusivamente aziendali?

La maggior parte delle simulazioni di risposta agli incidenti (IR) aziendali coinvolge tipicamente i team IT e di sicurezza (a cui talvolta si aggiungono anche i team legali e di comunicazione). Le simulazioni nel settore sanitario richiedono uno spazio significativamente più ampio – e scenari significativamente diversi.

Dovrebbe essere presente la dirigenza delle operazioni cliniche, poiché le decisioni su quali sistemi debbano essere messi fuori servizio devono essere prese sotto l’autorità clinica. L’ingegneria biomedica deve essere coinvolta ogni volta che gli scenari riguardano dispositivi connessi. I responsabili della privacy devono partecipare agli alberi decisionali relativi alla notifica delle violazioni.

Gli scenari stessi dovrebbero riflettere le minacce specifiche del settore sanitario:

• Un ransomware che crittografa contemporaneamente sia i sistemi primari di cartelle cliniche elettroniche (EHR) sia i backup su cloud
• Una credenziale API compromessa che consente l’accesso silenzioso ai dati dei pazienti per un periodo prolungato
• Una configurazione errata del cloud che ha esposto pubblicamente le informazioni sanitarie protette (PHI) per un periodo di tempo sconosciuto
• Una violazione presso un fornitore terzo che si propaga nell’ambiente cloud dell’organizzazione sanitaria attraverso un’integrazione attiva

Un playbook non può essere considerato sufficiente in un contesto sanitario se non include l’attivazione della procedura di emergenza (flussi di lavoro manuali a cui il personale clinico ricorre quando i sistemi non sono disponibili). Quella sezione della risposta presenta il rischio maggiore per la sicurezza dei pazienti ed è spesso assente dai piani mutuati da settori non clinici.

Perché la sicurezza del cloud nel settore sanitario è più complessa rispetto alla tradizionale sicurezza del cloud aziendale?

Tutti i settori devono affrontare, in una certa misura, le sfide legate alla sicurezza del cloud, e il settore sanitario non fa eccezione – presenta addirittura una serie di vincoli che non riguardano nessun altro settore. La difficoltà della sicurezza del cloud nel settore sanitario è di natura strutturale, non tecnica.

Perché gli operatori sanitari non possono semplicemente limitare tutti gli accessi al cloud?

Il settore sanitario ha già superato il punto in cui la limitazione rappresenterebbe una strategia praticabile. Molti degli elementi moderni di un ambiente sanitario sono praticamente impossibili senza l’archiviazione nel cloud. Ad esempio:

• I flussi di lavoro clinici dipendono da piattaforme di cartelle cliniche elettroniche (EHR) ospitate nel cloud
• I pazienti si aspettano di poter accedere alle proprie cartelle cliniche tramite portali online
• La telemedicina si basa su un’infrastruttura cloud
• Le immagini diagnostiche vengono archiviate e trasmesse tramite il cloud poiché le dimensioni dei file in questione rendono l’archiviazione locale impraticabile su larga scala

Limitare in modo significativo l’accesso al cloud nel settore sanitario non lo renderà più sicuro, ma ne comprometterà il funzionamento. La questione non riguarda mai il consentire o negare l’accesso al cloud, ma il renderlo il più sicuro possibile senza compromettere l’assistenza che esso supporta.

In che modo i flussi di lavoro delle cure d’emergenza creano inevitabili compromessi in materia di sicurezza del cloud?

Le politiche di sicurezza non seguono le stesse tempistiche delle cure d’emergenza. Un’équipe di traumatologia che si occupa di un paziente in condizioni critiche non può permettersi di attendere il completamento di un processo di autenticazione in più fasi. Un medico di turno in un reparto sconosciuto alle 3 del mattino non attenderà l’approvazione di una richiesta di accesso mentre esamina l’anamnesi di un paziente le cui condizioni stanno peggiorando.

La natura stessa delle cure di emergenza implica che qualsiasi controllo di sicurezza che crei ostacoli venga aggirato, anziché rispettato. Nel settore sanitario, tali aggiramenti sono spesso giustificati anche dal punto di vista clinico, il che li rende estremamente difficili da prevenire con le sole politiche.

Controlli di sicurezza più rigorosi possono ridurre il rischio in condizioni stabili, ma lo aumentano nelle situazioni di emergenza. Il compromesso è reale e del tutto inevitabile. La sicurezza di una struttura sanitaria va affrontata non come un mezzo per raggiungere un fine, ma come un elenco di scelte ragionate e documentate su dove tali rischi possano essere accettati (tenendo conto del parere clinico, non solo della sicurezza).

Perché l’accesso continuo ai dati crea rischi di sicurezza informatica specifici nei sistemi sanitari?

La maggior parte dei sistemi aziendali tende ad avere ritmi naturali che includono:

• Picchi di utilizzo durante l’orario di lavoro
• Attività ridotta durante la notte
• Finestre di manutenzione nei fine settimana

Ciò non vale per i sistemi sanitari. Le piattaforme EHR, i sistemi farmaceutici ospitati nel cloud e gli ambienti di monitoraggio dei pazienti funzionano a piena capacità 24 ore su 24, tutti i giorni dell’anno.

La disponibilità continua esclude alcune opzioni su cui i team di sicurezza aziendali fanno regolarmente affidamento. Pianificare i tempi di inattività per la gestione delle patch diventa essenzialmente una questione di gestione del rischio clinico. I sistemi progettati per rilevare anomalie nel normale traffico di rete devono tenere conto del fatto che, nel settore sanitario, i periodi di minor traffico nel senso tradizionale del termine sono molto rari.

Un sistema sempre attivo è un sistema costantemente esposto. Costruire la sicurezza attorno a tale realtà richiede un approccio completamente diverso rispetto a quello utilizzato per proteggere la maggior parte delle altre infrastrutture in settori diversi.

In che modo l’architettura cloud-native modifica la sicurezza cloud negli ambienti sanitari?

Gli ambienti IT sanitari tradizionali erano costruiti attorno a grandi applicazioni centralizzate, in cui i dati risiedevano in posizioni prevedibili e i confini di sicurezza erano facili da definire. L’avvento dell’architettura cloud-native ha modificato entrambi questi fattori contemporaneamente.

Perché i microservizi, i container e il serverless richiedono una nuova modellazione delle minacce per le PHI?

In un’applicazione monolitica tradizionale, la maggior parte delle funzionalità si svolge all’interno dello stesso sistema. Il flusso è semplice: le PHI arrivano, vengono elaborate e archiviate. Tutto ciò avviene all’interno di un unico sistema con confini di sicurezza abbastanza ben definiti.

Le applicazioni cloud-native si comportano in modo diverso. Un’architettura basata su microservizi trasforma quell’unica applicazione in decine o centinaia di servizi più piccoli, indipendenti ma in grado di comunicare tra loro attraverso la rete. Ciascuno di questi servizi potrebbe gestire le PHI per un breve periodo (ricevendole, trasformandole, trasmettendole) senza archiviarle in modo permanente.

Sebbene tale approccio moderno sia estremamente efficiente, implica anche che le PHI si spostino costantemente attraverso un gran numero di componenti, ciascuno dei quali rappresenta un potenziale punto di esposizione.

I container – piccoli pacchetti portatili che eseguono singoli servizi – sono per loro natura effimeri, pertanto possono apparire, svolgere la propria funzione e poi scomparire. La natura stessa dei container li rende particolarmente problematici quando si tratta di monitoraggio costante e applicazione di patch di sicurezza nel senso convenzionale del termine.

Le funzioni serverless portano questo approccio un passo oltre: il codice viene eseguito in risposta a un trigger, opera per un breve periodo e poi si arresta. In questo modo, non esiste un server persistente da monitorare o proteggere, almeno in senso tradizionale. Ogni volta che le PHI transitano attraverso una funzione serverless, la finestra temporale per osservarle e registrarle rimane molto ridotta.

Tutte queste caratteristiche e approcci richiedono un modello di minaccia notevolmente più distribuito rispetto a qualsiasi cosa per cui fosse stata concepita la tradizionale sicurezza informatica nel settore sanitario.

In che modo le pipeline CI/CD e il DevSecOps dovrebbero essere adattati per garantire la conformità nel settore sanitario?

Una pipeline CI/CD (Continuous Integration and Continuous Deployment) è un meccanismo automatizzato che prende il codice scritto dagli sviluppatori, lo testa e lo distribuisce in produzione. Tale processo può essere molto rapido nel contesto degli ambienti cloud-native. Nuove configurazioni, servizi aggiornati e politiche di accesso modificate possono diventare operative nel giro di pochi minuti.

Se i controlli di sicurezza non sono integrati nella pipeline sin dall’inizio, tale velocità diventa un rischio per la conformità. Il DevSecOps consiste nell’integrare le fasi di convalida della sicurezza nel processo di sviluppo e distribuzione, anziché esaminarle separatamente in un secondo momento.

Cosa significa questo nel contesto sanitario:

• Eseguire automaticamente la scansione del codice dell’infrastruttura alla ricerca di configurazioni errate prima della distribuzione
• Segnalare le risorse di archiviazione o gli endpoint API che potrebbero esporre le informazioni sanitarie protette (PHI) senza crittografia
• Bloccare le distribuzioni che comporterebbero la rimozione della registrazione di audit richiesta
• Verificare che i nuovi servizi soddisfino i requisiti di sicurezza previsti dal BAA prima che entrino in produzione

Individuare le lacune di conformità quando la loro correzione è meno onerosa (prima che il codice diventi operativo) è l’obiettivo primario di questo approccio, che risulta significativamente più efficace rispetto all’individuazione di tutti i problemi dopo un incidente o durante un audit.

Quali controlli automatizzati proteggono l’infrastruttura cloud del settore sanitario dalle configurazioni errate?

La revisione manuale delle configurazioni è chiaramente insufficiente, data la velocità con cui cambiano gli ambienti cloud-native. I controlli automatizzati sono praticamente indispensabili per monitorare continuamente l’ambiente e rilevare le deviazioni non appena si verificano.

Le principali categorie di controlli da tenere presenti includono:

• Cloud Security Posture Management (CSPM) — strumenti che analizzano continuamente gli ambienti cloud alla ricerca di configurazioni errate, confrontando in tempo reale le impostazioni attuali con i benchmark di sicurezza e i framework di conformità
• Analisi Infrastructure-as-Code (IaC) — analisi automatizzata del codice utilizzato per definire l’infrastruttura cloud, che individua le configurazioni non sicure prima ancora che vengano implementate
• Rilevamento delle derive — monitoraggio che identifica quando un ambiente cloud attivo si discosta dalla propria configurazione di riferimento approvata, segnalando le modifiche non autorizzate o accidentali non appena si verificano
• Applicazione delle policy-as-code — regole di sicurezza scritte sotto forma di policy leggibili da macchina che vengono automaticamente applicate e fatte rispettare su tutte le risorse cloud, eliminando la dipendenza dalla revisione manuale

È importante sottolineare che nessuno di questi controlli elimina completamente la necessità di una supervisione umana, ma essi cercano di garantire che il volume e il ritmo dei cambiamenti negli ambienti cloud-native non possano superare la capacità del team di sicurezza di stare al passo con essi.

In che modo le organizzazioni sanitarie possono migliorare la sicurezza del cloud nel settore sanitario durante l’adozione del cloud?

Limitarvisi a comprendere perché la sicurezza del cloud nel settore sanitario sia così impegnativa rappresenta solo metà del lavoro. L’altra metà consiste nel creare programmi sufficientemente pratici da poter essere effettivamente seguiti contemporaneamente dal personale clinico, dai team di sicurezza e dalla dirigenza.

Quali rischi legati al cloud computing dovrebbero affrontare le organizzazioni sanitarie durante la migrazione?

La fase più rischiosa del percorso di adozione del cloud è la migrazione: un processo decisionale rapido sotto la pressione del progetto comporta anni di debito di sicurezza. Prima che le informazioni sanitarie protette (PHI) vengano trasferite in qualsiasi ambiente cloud, le organizzazioni dovrebbero affrontare:

• Classificazione dei dati — identificare quali dati costituiscono le PHI, dove sono attualmente archiviati e quali servizi cloud li tratteranno
• Copertura BAA — confermare che siano in vigore Accordi di Collaborazione (BAA) firmati con ogni fornitore e sub-responsabile del trattamento che gestirà le PHI
• Progettazione del controllo degli accessi — definire politiche di accesso basate sui ruoli per l’ambiente cloud prima della migrazione, non dopo
• Configurazione della registrazione dei log — stabilire l’ambito dei log di audit, i periodi di conservazione e l’isolamento dell’archiviazione come parte della configurazione iniziale
• Verifica della crittografia — confermare che la crittografia copra tutti i livelli di archiviazione, i percorsi di transito e gli ambienti di elaborazione che tratteranno le PHI
• Test di backup e ripristino — verificare che i processi di backup funzionino correttamente nell’ambiente cloud prima del passaggio dei sistemi primari
• Mappatura delle responsabilità condivise — documentare in modo esplicito quali obblighi di sicurezza spettano al fornitore e quali all’organizzazione

In che modo le organizzazioni sanitarie possono ridurre i rischi in un ambiente cloud durante l’adozione graduale?

Trasferire tutto nel cloud in una sola volta massimizza sia la velocità che il rischio. Un approccio graduale, passo dopo passo, consente di verificare i controlli di sicurezza in ogni fase prima che inizi quella successiva.

Un punto di partenza ragionevole consiste nel testare l’adozione del cloud con carichi di lavoro a bassa sensibilità — sistemi amministrativi, strumenti di collaborazione non clinici o ambienti di analisi anonimizzati. Ciò concede ai team di sicurezza e IT il tempo necessario per comprendere come i controlli del fornitore di servizi cloud si comportino effettivamente nella pratica, identificare le discrepanze tra le impostazioni di sicurezza predefinite previste e quelle effettive e acquisire familiarità operativa prima che siano coinvolte le informazioni sanitarie protette (PHI).

Ogni fase dovrebbe includere un punto di controllo di convalida formale prima dell’espansione. Ciò significa testare il backup e il ripristino, esaminare i registri di accesso alla ricerca di comportamenti inattesi, confermare che la registrazione dei log stia acquisendo i dati previsti e verificare che i confini della responsabilità condivisa vengano effettivamente rispettati nella pratica.

L’adozione graduale non equivale a un’adozione più lenta del cloud. Si tratta piuttosto di un’adozione del cloud che non genera arretrati di interventi correttivi destinati a perseguitare l’organizzazione per anni.

Quali metriche e KPI dovrebbero monitorare i dirigenti del settore sanitario per misurare la maturità della sicurezza nel cloud?

Determinare la maturità della sicurezza rappresenta una vera sfida in assenza di misurazioni specifiche. Le metriche descritte di seguito mirano ad aiutare i dirigenti del settore sanitario a verificare se le misure di sicurezza nel cloud siano effettivamente operative e non semplicemente implementate.

In che modo Bacula Systems può migliorare la sicurezza del cloud negli ambienti sanitari?

Garantire la sicurezza delle informazioni sanitarie protette (PHI) nel cloud richiede ben più che semplici controlli preventivi: è inoltre necessario avere la certezza che il ripristino sia possibile quando tali controlli vengono testati correttamente. Bacula Systems offre funzionalità di backup di livello aziendale, oltre a soluzioni di ripristino e gestione dei dati progettate tenendo conto della complessità dei moderni ambienti cloud nel settore sanitario.

Ecco in che modo Bacula Systems fa davvero la differenza:

• Backup immutabili — copie di backup che non possono essere modificate, eliminate o crittografate da un malintenzionato, nemmeno da chi dispone di accesso amministrativo ai sistemi primari
• Ripristino granulare — ripristino di singoli file, database o interi sistemi senza la necessità di recuperare tutto in una volta, riducendo i tempi di inattività clinica durante un incidente
• Controllo delle chiavi di crittografia — le organizzazioni mantengono la proprietà delle proprie chiavi di crittografia anziché delegare tale responsabilità alle impostazioni predefinite di un fornitore di servizi cloud
• Registrazione pronta per gli audit — registri dettagliati di backup e ripristino che soddisfano i requisiti di documentazione HIPAA e supportano le esigenze delle indagini forensi
• Supporto ibrido e multi-cloud — protezione coerente dei dati in ambienti on-premise, cloud privato e cloud pubblico da un’unica interfaccia di gestione
• Implementazione flessibile — l’architettura di Bacula si adatta all’infrastruttura sanitaria esistente, anziché richiedere un approccio di sostituzione totale

In definitiva, tutti i programmi di sicurezza cloud nel settore sanitario possono essere valutati sulla base di un’unica domanda: quando si verifica un problema, con quale rapidità e completezza è possibile ripristinare le operazioni? Bacula Systems è progettato per fornire una risposta definitiva — in contesti IT sanitari reali, ibridi, multi-cloud e legacy.

Domande frequenti

Perché le organizzazioni sanitarie faticano a mantenere politiche di sicurezza cloud coerenti negli ambienti sanitari multi-cloud e ibridi?

Gli ambienti cloud utilizzati dalle organizzazioni sanitarie raramente vengono realizzati partendo da zero. Spesso sono il risultato di anni di acquisti indipendenti, fusioni, acquisizioni e accordi con i fornitori. Ogni ambiente presenta un proprio modello di controllo degli accessi, un proprio meccanismo di registrazione degli eventi e un proprio set di strumenti per il monitoraggio della sicurezza. L’applicazione di una politica per la protezione delle informazioni sanitarie protette (PHI) richiederà un livello di gestione centralizzato che, ad oggi, la maggior parte delle organizzazioni non ha ancora implementato.

In che modo le organizzazioni sanitarie dovrebbero indagare sulle violazioni nel cloud quando i log e le prove sono distribuiti tra più fornitori?

L’accuratezza di un’indagine su una violazione dipende dalla completezza dei log a supporto della stessa. Gli ambienti multi-cloud raramente archiviano i log in un’unica posizione o in un formato coerente. I log dovrebbero essere trasmessi da ogni ambiente cloud a un archivio centralizzato, separato e sicuro in tempo reale, anziché essere recuperati in modo reattivo solo dopo la scoperta di una violazione. Le procedure forensi per ciascun fornitore, comprese le modalità di acquisizione delle prove conservate, dovrebbero essere predefinite prima che si verifichi una violazione, anziché essere sviluppate nel corso della stessa.

Perché l’automazione cloud-native e le pipeline DevSecOps possono esporre accidentalmente dati sanitari sensibili su larga scala?

Se un errore di configurazione viene consolidato in una pipeline automatizzata, non avrà ripercussioni su un solo sistema, ma si diffonderà in ogni ambiente con cui la pipeline interagisce. Un sistema di distribuzione automatizzata progettato per creare una risorsa di archiviazione che conceda permessi di accesso aperto come configurazione predefinita può riprodurre tale errore centinaia di volte prima ancora che un essere umano si accorga della sua esistenza. Nel settore sanitario, un controllo di sicurezza codificato in una pipeline automatizzata non è una comodità ingegneristica, ma un obbligo a tutela della privacy dei pazienti.