Abbiamo rivolto alcune domande, in merito al rischio clinico associato alla sicurezza informatica, a Corrado Giustozzi, esperto di sicurezza cibernetica dell’Agenzia per l’Italia Digitale per il CERT della Pubblica Amministrazione (CERT-PA).
Nella formazione classica del medico l'enfasi è posta sulla gestione del rischio clinico, e le tecnologie informatiche, per l’archiviazione dei dati dei pazienti, la condivisione in rete ecc., sono viste al meglio come utile strumento di organizzazione gestionale, ma in alcuni casi sono considerate parte del pacchetto dei vincoli burocratici.
Esiste secondo lei una consapevolezza, tra gli operatori sanitari, dell'importanza della sicurezza dei sistemi informatici sanitari?
Occorre innanzitutto distinguere tra safety e security. Di solito i medici sottovalutano la security, perché il loro focus è sulla safety, cioè sulla tutela del paziente. Tuttavia oggigiorno anche la security costituisce un rischio gravissimo per la sanità, che questa non è culturalmente ed operativamente preparata ad affrontare.
Per maggior chiarezza potremmo fare l’esempio classico della Croce Rossa: chi oserebbe mai sparare sulla Croce Rossa? Ma il giorno in cui succede, ci si accorge che è impreparata e indifesa. Così è successo recentemente in alcune strutture sanitarie americane e inglesi, dove un attacco informatico ha bloccato i sistemi e quindi la possibilità di gestire l’assistenza ai pazienti ricoverati. Gli attacchi erano finalizzati all’estorsione: organizzazioni criminali “tenevano in ostaggio” i sistemi informatici chiedendo il pagamento di un riscatto per ripristinarne la funzionalità.
Ma c’è di peggio: la security in sanità oramai non riguarda più i classici sistemi ICT ospedalieri (ndr, information and communication technologies), che gestiscono sia la parte amministrativa che quella diagnostica (pensiamo ai RIS-PACS, alle TAC, alle RMN), ma riguarda anche i singoli pazienti, e sono sempre di più, che portano dentro di sé un dispositivo medico impiantato, come un defibrillatore o una pompa di insulina. È stato dimostrato che moltissimi di questi dispositivi, pur estremamente curati dal punto di vista della safety, non lo sono affatto da quello della security, e potrebbero ad esempio essere manomessi da remoto, utilizzando un PC o addirittura uno smartphone. Proviamo a riflettere ora secondo criteri di security: se questo attacco lo facesse un terrorista? Potrebbe per esempio sabotare o addirittura spegnere il defibrillatore di qualche persona a caso tra i tifosi allo stadio, causandone la morte. Un attentato ancora più terrorizzante di un camion lanciato contro i pedoni.
È il caso di ricordare quel che ha dovuto fare la Abbott nel novembre scorso, quando ha richiamato 450.000 defibrillatori impiantati, ovvero 450.000 pazienti, in tutto il mondo, perché era stato rilevato un difetto di programmazione dei defibrillatori per cui, sfruttando questo difetto, un estraneo avrebbe potuto modificare la programmazione del defibrillatore all’insaputa del paziente. Si è trattato di un’operazione enorme, mai realizzata prima, preparata con sei mesi di anticipo, informando i medici che seguivano i pazienti, gli ospedali e richiamando tutti i pazienti, che si sono poi dovuti recare in ospedale per l’aggiornamento del software: un’operazione di enorme delicatezza e rischio. A volte osserviamo con trepidazione l’aggiornamento software del telefonino, nel timore che non tutto funzioni come prima; immaginate la stessa operazione in un pacemaker impiantato su pazienti: il blocco del pacemaker in fase di aggiornamento si può trasformare in tragedia. Tutto ha funzionato, per fortuna. Ma è una lezione da non sottovalutare.
Quindi, tornando alla domanda, la categoria dei medici non è in genere sensibile a questo problema perché non è mai stata esposta a questo tipo di rischi. Purtroppo però questi problemi ci sono, non sono fisime, non vanno sottovalutati: se si ferma il PC contenente dati amministrativi è un conto, se si ferma la TAC o la risonanza magnetica è un altro conto, se si ferma la macchina che tiene in vita un paziente è un altro conto ancora. Hanno tutti grosso modo le stesse vulnerabilità, ma con impatti drammaticamente diversi.
Al momento, se si parla di sicurezza la prima cosa cui pensa il medico è il furto di dati clinici del paziente. Questo è un problema relativo, perché i dati personali possono essere “interessanti” se sei un VIP, per scoop giornalistici, ma per i dati delle persone comuni non c’è alcun interesse, a meno che non ci sia una fuga sistematica di grandi moli dati, con altri impatti. Raccolti in forma aggregata e analizzati per aree abitative, ad esempio, potrebbero dare un quadro delle patologie più diffuse in una certa zona ed essere utili per definire il prezzo di un farmaco o del premio delle polizze assicurative sanitarie.
Là dove c’è maggiore sensibilità sulla security si tende a inserire già il rischio cibernetico all’interno dei rischi clinici, perché ora sussiste davvero la possibilità che un paziente possa peggiorare il suo stato in ospedale a causa di un incidente o attacco informatico tipicamente doloso, esattamente come sussiste il rischio di infezione nel corso della degenza. Le emergenze relative alla patologia sono previste e gestite, ma l’attacco di un terrorista o di un ricattatore che ferma i sistemi, sabota la farmacia robotizzata e assegna a un paziente il farmaco di un altro, oppure crea una situazione per cui non si può dare assistenza adeguata al paziente, il quale dunque dovrebbe essere trasferito in altro ospedale ma magari non è trasportabile, sono esempi dei problemi che potrebbero insorgere.
Quali potrebbero essere i principi, le raccomandazioni per migliorare l'integrazione tra esperto ICT di una struttura sanitaria e professionista sanitario
Occorre semplicemente comunicare, è compito dell’esperto ICT far comprendere l’importanza della “security”.
Nelle strutture sanitarie c’è la figura del Data Protection Officer ai sensi della normativa sulla privacy ma non c’è quella del responsabile della sicurezza per la gestione dei sistemi informativi, e le funzioni di governance strategica della sicurezza spesso non sono proprio previste. Non c’è una legge che lo impone, e di solito la aziende sanitarie acquistano il software da aziende esterne, cui affidano anche la gestione dei sistemi.
Mi rendo conto che nel mondo della sanità ci sono vari problemi, per esempio, un Ris Pacs, una RMN gestita da un computer ovviamente devono essere certificati per la safety, ma può succedere che questa sia gestita da vecchi PC, non sempre aggiornati, con vecchi sistemi Windows, vulnerabili. E l’aggiornamento del software di una macchina RMN deve essere fatto dalla casa madre, a valle di un processo di certificazione che ha tempi lunghi. Tutta l’industria dovrebbe quindi farsi parte più attiva nel processo di gestione della sicurezza informatica.
Il problema, va sottolineato, è nato recentemente perché fino a poco tempo fa queste macchine non erano in rete. Quindi la possibilità che entrasse un virus o in generale un agente di minaccia nella macchina era pressoché inesistente. Ora il medico può vedere la RMN dal PC del suo ufficio, lo stesso PC con cui naviga in internet, e se il suo PC viene attaccato da un virus lo propaga alla macchina.
I filtri di sicurezza?
Le difese tecniche e procedurali ovviamente esistono, simili a quelle utilizzate ad esempio dalle banche, che sono consapevoli della possibilità di attacco, e tutelano i collegamenti in modo da minimizzare i pericoli; e ciò nonostante, gli attacchi possono lo stesso avvenire. Mentre le banche hanno adottato i sistemi di sicurezza, le strutture sanitarie spesso non li hanno adottati fino in fondo, per il teorema della Croce Rossa: non si aspettavano di poter essere attaccati.
Purtroppo l’adeguamento, specie laddove ci sono sistemi molto vecchi e non concepiti per essere sicuri, può essere molto oneroso. Ma non è solo un problema di tecnologia, lo è invece anche e soprattutto di organizzazione, e di processi che devono adeguarsi alle esigenze, tenendo presente che il medico ha chiaro in mente un concetto prioritario: “ai fini della safety non devo avere barriere, perché in emergenza deve accedere velocemente ai dati”. Non vuole dunque perdere tempo con password, chiavette OTP. Il concetto è corretto ma se non attuato anche con criteri di sicurezza porta a una vulnerabilità. Serve quindi un ragionevole bilanciamento fra necessità operativa e sicurezza.
Concludendo sui pericoli di un attacco informatico in ambito sanitario, quali sono le sue raccomandazioni?
Concettualmente il discorso della privacy è importante, ma se dovessi scegliere tra il furto di dati clinici o lo spegnimento del pacemaker non avrei dubbi sulla risposta. Tra l’altro, nell’ipotesi di furto dei dati per studi epidemiologici ai fini di strategie di mercato dei farmaci, sono i dati aggregati che servono, anche anonimi.
Veniamo ora a una domanda che può sembrare bizzarra: i computer, o le reti di computer provano dolore? Come spiegherebbe, se plausibile, la sofferenza del computer?
È una domanda estremamente profonda, che ha radici storiche molto importanti: in effetti se la sono posta filosofi e pensatori già al momento della prima comparsa dei calcolatori elettronici. Ci sono stati studi che hanno in particolare approfondito il concetto di autocoscienza, di cosa comporti essere una creatura senziente. Per quanto riguarda il dolore, l’idea è che se sei senziente percepisci il tuo proprio dolore, e per estensione agli altri (assumendo che anche gli altri abbiano coscienza di sé…) pensi che essi facciano e provino altrettanto. Tu non potrai mai provare il dolore dell’altro, ma per convenzione sociale tu attribuisci agli altri lo stesso tipo di sensazioni che senti per te stesso, anche se non hai nessuna prova: “sono autocosciente, sento di sentire e mi aspetto che anche gli altri lo facciano”. La questione dunque è se le macchine, almeno ad un determinato grado di complessità, possano essere senzienti se non addirittura autocoscienti. In quel caso sarebbe ragionevole pensare che in determinate circostanze possano provare qualche forma di dolore, anche se probabilmente diversissima da quella che proviamo noi.
Agli inizi, negli anni ’40, quando è stata introdotta l’informatica (che peraltro ancora non aveva nemmeno questo nome), il famoso matematico Alan M. Turing diede un contributo estremamente importante al dibattito filosofico sul problema, che all’epoca era molto dibattuto dai filosofi e dagli epistemologi, se “le macchine possono, o potranno mai, pensare?”. Erano i primi tempi in cui si iniziavano a sviluppare macchine in grado di compiere autonomamente dei compiti per cui erano state programmate, e prima ancora che la tecnologia avesse raggiunto un grado di avanzamento tale da potersi porre legittimamente il quesito, i filosofi ne stavano già discutendo animatamente. Giova ricordare che fino agli anni ‘70 i calcolatori venivano chiamati “cervelli elettronici”, termine assolutamente sbagliato: non hanno nulla del cervello, nemmeno ne scimmiottano la fisiologia, però il mito della “macchina pensante” è stato duro a morire. (E ora sta forse ritornando grazie allo sviluppo delle tecniche di intelligenza artificiale, ma questo è un altro discorso!)
Bene, l’articolo di Turing uscì nel 1950 su Mind, una importante rivista inglese di filosofia, e mise la parola fine a questo dibattito. Si tratta del famoso articolo dal quale nasce il concetto, ben noto, di “test di Turing”.
Turing diede una soluzione diciamo fredda ed ingegneristica al problema, annullandone tutte le considerazioni emotive che lo avevano sempre caratterizzato. Mise infatti in chiaro che, per come si era sviluppato il problema, il dibattito si era basato solo su considerazioni di carattere “viscerale”, non tecnico: una riflessione che nasceva col discutere cosa fosse l’intelligenza, con considerazioni del tipo “ma gli animali sono intelligenti?”, e quindi basata su opinioni, su concetti filosofici, inevitabilmente molto soggettivi.
Il suo argomento è stato: “se continuiamo a discutere di che cos’è l’intelligenza per capire se la macchina ha l’intelligenza, non giungeremo ad una soluzione oggettiva ed universalmente condivisibile. Partiamo allora da altro punto di vista.”. E per farlo crea un esperimento mentale basato su un gioco di società dell’epoca elisabettiana, il gioco dell’imitazione, ovvero “the imitation game”. In questo gioco ci sono un uomo e una donna, in stanze separate dagli altri giocatori, che comunicano coi giocatori solo tramite bigliettini scritti portati da un messaggero: i giocatori possono inviare domande scritte ai soggetti isolati e riceverne le risposte scritte. Il gioco consiste nel riuscire ad indovinare, dalle risposte ricevute, chi è l’uomo e chi la donna: e ovviamente i due devono cercare di ingannare i partecipanti, facendo credere di essere entrambi l’uomo o la donna.
Bene, Turing immagina una versione di questo gioco dove i giocatori sono un uomo e una macchina, e dove “l’interrogatore” (lo chiama proprio così) dialoga con loro tramite una telescrivente. Lui non sa quale giocatore è l’uomo e quale è la macchina, e questi devono entrambi convincere l’interrogatore di essere l’uomo. In questa situazione, secondo Turing, se un interrogatore medio venisse ingannato per un tempo sufficiente, cioè dalle risposte ricevute non riuscisse a capire chi è chi, allora quel computer avrebbe agito “come se fosse intelligente”, perché il suo comportamento è indistinguibile da quello di un uomo posto in una situazione analoga: e ciò, attenzione, senza bisogno di definire cosa sia l’intelligenza! A Turing non interessa infatti definirla, perché sono migliaia di anni che i filosofi provano a farlo senza trovare un accordo; ma, dando per assunto che un uomo medio ce l’abbia, allora Turing conclude che se un computer riuscisse a comportarsi in mondo indistinguibile da un uomo medio, la discussione sarebbe evidentemente chiusa.
In questo modo Turing ha spostato una volta per tutte la questione dell’intelligenza da un ambito puramente emotivo e soggettivo quale “le macchine sono o potranno essere intelligenti?” ad un ambito puramente ingegneristico quale “è possibile costruire una macchina in grado di vincere al gioco dell’imitazione?”. Il problema dunque non è decidere se la macchina è intelligente ma se un giorno si riuscirà, tecnicamente, a costruire una macchina in grado di vincere questo gioco, che da allora in suo onore è stato chiamato test di Turing. Ecco, ad oggi nessuno è mai riuscito a costruire una macchina capace di farlo, anche se in certi momenti sembrava che il traguardo fosse vicino. Secondo me il problema è questo. Stabilire cosa potrebbe essere il dolore per una macchina però è ancora più difficile da dire, perché per farlo credo sia necessario tirare in ballo anche il concetto di autocoscienza. Che sembra intimamente legato a quello di intelligenza, anche se forse non è così.
Cito a proposito un esperimento degli anni ’80: dei ricercatori del MIT costruirono un semplice robottino che si muoveva su ruote, si andava a ricaricare da solo alla corrente quando aveva le batterie basse ed era stato programmato in modo tale che se gli si dava un calcio emetteva un guaito e scappava; la maggior parte della gente era convinta che provasse dolore dopo il calcio, o che avesse fame quando andava a ricaricarsi, perché in effetti abbiamo la tendenza ad antropomorfizzare i comportamenti; ma era chiaro che quel robottino, fatto con pochi semplici circuiti in croce, non aveva alcuna reale intelligenza né tanto meno autocoscienza. Semplicemente simulava una situazione per cui empaticamente gli si attribuiva dolore, ma era certamente sbagliato attribuirgli dolore. Oggigiorno abbiamo effettivamente in casa robottini aspirapolvere, apparentemente intelligenti, che a un certo punto si fermano e vanno a ricaricarsi: è suggestivo pensare che abbiano fame, ma possiamo pensarla come reale situazione di disagio o addirittura di “dolore”? Il robottino con le batterie scariche è “cosciente” di questa cosa? Evidentemente no, perché anche nei robottini aspirapolvere di oggi il progetto è molto semplice. Non è detto però che una macchina molto, molto più complessa non potrebbe anche avere un’autocoscienza, anche se qui entriamo nella filosofia; se così fosse, tuttavia, questo tipo di feedback (“batteria scarica”) potrebbe effettivamente essere assimilato a sensazioni non molto diverse da quello che per noi è il dolore, il quale si è sviluppato attraverso meccanismi evolutivi proprio per mandarci in modo rapido segnali di emergenza, di difesa da una minaccia o di reazione di fronte ad eventi che riguardano la nostra efficienza e la nostra sopravvivenza.
intervista a cura di Lorenza Saini e Fabrizio La Mura
18 dicembre 2018
Per note storiche e approfondimenti leggi anche in questo sito: Sistema nervoso e reti informatiche: breve viaggio avventuroso fra letteratura, neurologia e pirati informatici
