La domanda da porsi, dopo il primo caso riportato di paziente morta per colpa di un ransomware, è questa: come è stato possibile che l’interruzione di uno o più applicativi abbia giocato un ruolo così determinante?
Sappiamo che il ransomware ha determinato l’interruzione dell’operatività del sistema informativo in un ospedale tedesco. Sistema che dovrebbe essere a supporto del processo di erogazione del servizio sanitario.
La risposta a quella domanda, forse, non è da ricercare nell’ambito della gestione dei sistemi informativi, ma nell’ambito della gestione dei servizi.
Indice degli argomenti
Morte per ransomware in ospedale: problemi di continuità operativa
In prima battuta, quindi, non scomoderei il security manager del presidio universitario ospedaliero, ma chiederei conto al continuity manager dello stesso presidio, domandandogli come mai l’interruzione di un sistema a supporto di un servizio sanitario abbia avuto un tale impatto, contribuendo a determinare questo epilogo.
È verosimile che un presidio ospedaliero universitario non abbia definito le procedure volte a garantire la continuità operativa della propria struttura ?
È possibile che lo scenario “indisponibilità del sistema informativo” non sia stato contemplato?
Sul tema della continuità operativa, lo schema di riferimento è la norma internazionale ISO 22301:2019 (BCMS – Business Continuity Management Systems), finalizzata a definire “la struttura e i requisiti per l’implementazione e il mantenimento di un sistema di gestione della continuità aziendale (BCMS) che sviluppi una continuità operativa adeguata alla quantità e al tipo di impatto che l’organizzazione può o non può accettare a seguito di un’interruzione.”
Quando si parla di continuità operativa di un servizio (Service Continuity) è importante fare attenzione e non confonderla con la disponibilità del servizio (Service Availability), che invece viene definita in sede di progetto del sistema in funzione dei requisiti del servizio.
Nella “cassetta degli attrezzi” della 22301 troviamo alcuni strumenti utili, come la BIA (Business Impact Analysis), le cui linee guida per la corretta implementazione sono dettate dalla ISO/TS 22317:2015 (Guidelines for business impact analysis (BIA)).
Questo strumento consente di fare delle valutazioni in termini di impatto sul business (business che, nel caso di un presidio ospedaliero, è l’erogazione dei servizi sanitari), considerando i vari fattori che possono intervenire in caso di interruzione del servizio.
Nel determinare l’impatto complessivo atteso per un dato servizio, si prendono in considerazione i principali elementi che sono coinvolti nel processo di business, da fattori reputazionali a fattori economici, dalle possibili conseguenze sulla salute delle persone a considerazioni sugli aspetti normativi coinvolti.
L’impatto, così determinato, varia al passare del tempo, in genere in modo progressivo. Più passa il tempo, maggiore sarà l’impatto complessivo sul business.
Con questo strumento definiamo, quindi, in modo strutturato le tempistiche (RTO – Recovery Time Objective) entro le quali è opportuno (necessario) intervenire per rispristinare il servizio interrotto, affinché questa interruzione non determini degli impatti rilevanti sul business, e come questo impatto varia al passare del tempo.
Avendo chiare le tempistiche massime di intervento, possiamo identificare le procedure operative più efficaci per ripristinare l’operatività del Servizio (da non confondere con il ripristino dell’operatività del sistema informativo, che potrebbe ancora essere compromesso).
Queste procedure, nell’ambito di un piano di intervento, costituiscono il Business Continuity Plan (BCP), ossia il Piano di Continuità Operativa del servizio, viene predeterminato dall’organizzazione a fronte di determinati scenari, e attivato qualora un incident causi l’interruzione di un servizio.
Nel caso in cui un servizio primario, come quello dell’emergenza sanitaria, dovesse essere oggetto di una interruzione, il piano definito per tale scenario (es: indisponibilità del sistema IT) dovrebbe essere attuato per consentire che il servizio possa essere comunque erogato.
È importante identificare preventivamente i possibili scenari
L’identificazione preventiva dei possibili scenari è funzionale all’identificazione di quelli che potrebbero essere i fattori determinanti per la compromissione del servizio (del tutto o in parte).
Per specifici contesti critici, come quelli dell’emergenza sanitaria, il parametro RTO dovrebbe essere “Near Zero” (ossia prossimo allo Zero), e il BCP deve essere rapidamente applicabile.
Per fare un esempio pratico, il triage di un paziente in arrivo al pronto soccorso viene svolto dall’infermiere, ed in funzione del codice di emergenza attribuito al paziente, si determina la priorità di accesso e di cura.
In mancanza del sistema informativo, le informazioni che risultano necessarie si annotano in modalità cartacea e l’informazione segue il paziente nel processo di gestione all’interno dei reparti.
Analogamente, durante chiamata al numero di emergenza 112, se il sistema informativo che gestisce la comunicazione tra il chiamante e i PSAP di 2 livello (Public Safety Answering Point) dovesse risultare improvvisamente indisponibile, l’operatore continuerebbe a gestire la chiamata di emergenza su carta, e comunicherebbe le informazioni per la gestione delle chiamate via telefonica e non attraverso il sistema informativo attraverso la scheda contatto, come avviene in condizioni normali.
In entrambe gli esempi, il servizio continua ad essere erogato senza interruzioni sostanziali, ancorché il sistema informativo a supporto sia nel frattempo ancora indisponibile o parzialmente degradato nelle sue funzionalità.
Sarà, infine, l’attuazione del DRP (Disaster Recovery Plan) che consentirà di ripristinare, dal punto di vista tecnico, il sistema informativo compromesso.
Cosa non ha funzionato nell’infrastruttura IT
Naturalmente, non ci siamo dimenticati del security manager, pertanto superata la gestione critica dell’incident, nell’ottica di comprendere le cause che hanno determinato l’interruzione del sistema informativo (siamo quindi nella fase di gestione del problem) potremmo approfondire gli aspetti legati all’infratruttura IT, analizzando la situazione per comprendere ad esempio come sia stato possibile che un ransomware il cui obiettivo parrebbe fosse l’università, abbia potuto colpire la rete ospedaliera.
Forse il livello di segregazione delle rispettive reti, e più in generale le misure di sicurezza adottate dalle strutture coinvolte, non erano del tutto adeguate per far fronte a questa tipologia di incident.
Per scongiurare il ripetersi di questi episodi, sarebbe pertanto auspicabile rivedere il piano di gestione della continuità operativa, e contestualmente le misure tecnico-organizzative legate alla protezione dei dati, di entrambe le strutture coinvolte in questo episodio.
