Torna a Eventi FPA

News

Photo by rawpixel on Unsplash

Sicurezza in sanità, bisogni e opportunità. Leggi, consolidamento e cose concrete da fare senza budget e con poche risorse

Il 4 dicembre, all’interno di FORUM PA Sanità, Alessandro Vallega condurrà due Learning Areas – “Security all’alba del 2020” e “Comprendere e semplificare il GDPR. Andiamo al punto” -, per questa ragione vi proponiamo un testo a sua firma che contiene la prospettiva di trattare insieme Security e Compliance. È apparso nel Rapporto Clusit 2017, ma rimane di grande attualità


di Alessandro Vallega, Senior advisors Information & Cyber Security Advisor, Integration and Change, Community Management – P4I Digital360 

Solamente le aziende che considerano l’informatica un fattore critico di successo sono riuscite a tenere il passo con la rapida evoluzione della tecnologia e con le sfide relative alla sicurezza. Molte soffrono degli effetti di una progettazione incrementale e a volte disorganizzata e della determinazione degli attaccanti a sfruttare la debolezza dei sistemi informatici per trarne un illecito vantaggio.

La sicurezza informatica nella sanità ospedaliera pubblica italiana soffre in misura maggiore di problematiche comuni anche ad altri ambiti industriali e al settore pubblico in generale. Seguono alcuni spunti sulle cause, sugli effetti e su cosa bisognerebbe probabilmente fare per migliorare la situazione.

Ruolo dell’IT negli ospedali

È evidente che lo scopo di un ospedale è quello di curare: servono dei buoni medici, dei buoni macchinari e un’adeguata quantità di altro personale competente. Si è sottovalutata l’importanza della tecnologia digitale perchè non sembrava direttamente e immediatamente connessa alla cura. Ciò è capitato anche se ormai l’informatica viene utilizzata sostanzialmente in tutti i processi sia clinici sia amministrativi.

L’utilizzo di informatica in sanità non è quasi mai avvenuto nel quadro di un piano pluriennale di sviluppo organico del sistema informativo aziendale bensì come risposta a problemi contingenti e di nicchia. Questo approccio ha determinato il proliferare di tecnologie diverse, la scarsa integrazione tra i sistemi e ha ridotto la capacità organizzativa a gestire grandi cambiamenti nel medio lungo periodo. Di conseguenza ha causato dei ritardi dello sviluppo dell’ICT, una scarsa propensione a percepire l’ICT come reale leva di cambiamento e a notevoli scoperture in merito alla sicurezza informatica.

Silos

L’utilizzo di ICT come mezzo per risolvere problemi di nicchia di tipo contingente ha creato silos informativi separati e integrabili con fatica. I progetti di cartella clinica elettronica, dossier sanitario e la condivisione con i fascicoli sanitari a livello regionale / nazionale sono in parte tutt’ora in corso e di media soddisfazione. Le autorità ne hanno promosso la realizzazione (pensando ai benefici per i cittadini e al risparmio per la collettività) e regolamentato gli aspetti di sicurezza e interoperabilità (pensando al rischio di incidenti di sicurezza e privacy), ma abbiamo osservato distinzioni a volte cavillose sulle misure da applicare al dato sanitario (per esempio quando costituisca dossier e quando no), sulle misure minime o idonee e altre cose.

Correre veloci nella direzione giusta

L’informatica fa molta fatica a parlare la lingua della legge e tali difficiltà si acuiscono quando l’evoluzione tecnologica crea degli scenari che non erano stati pensati al momento di legiferare e quando la medicina trova dei nuovi modelli organizzativi per ottimizzare i costi e aumentare la qualità. Due esempi in questo senso sono: la condivisione di referti tra medici tramite WhatsApp e l’affermarsi di processi di cura distribuiti nel tempo, nel territorio e tra soggetti diversi (persone fisiche e giuridiche, “titolari e responsabili del trattamento” ) come i PDTA[1].

Le leggi moderne pongono una grande enfasi sulla sicurezza come obiettivo da raggiungere. Per esempio il Regolamento 679/2016 sulla Data Protection (il cosiddetto GDPR), menziona la cifratura che impedisce l’accesso ai dati a chi non sia autorizzato, ma non specifica misure tecnologiche e organizzative per proteggere le chiavi stesse e non prescrive tecnologie specifiche per altri ambiti di sicurezza (ad esempio in merito alla gestione dei log di accesso). Troviamo solamente alcuni riferimenti al controllo accessi nell’articolo 32 Sicurezza del trattamento[2] e nell’articolo 25 Protezione dei dati fin dalla progettazione e protezione per impostazione predefinita[3]. Il Regolamento mette in capo al titolare e al responsabile del trattamento la responsabilità di definire con intelligenza (tenendo conto dello stato dell’arte della tecnologia e dei costi di attuazione) quali siano le misure di sicurezza adeguate rispetto al bene da proteggere (diritti e libertà delle persone) ma non fornisce indicazioni di tipo tecnico.

Il dovere di essere responsabili ci darebbe quindi il diritto di scegliere le misure. Anche le certificazioni e i codici di condotta (art. 40-43), la cui adesione è facoltativa, solamente aiutano a dimostrare la conformità.

Tale margine di manovra viene però limitato dal corpus normativo consistente in alcune altre leggi e diversi provvedimenti dell’Autorità (italiana) per la protezione dei dati personali come per esempio le Linee guida in materia di Dossier sanitario – 4 giugno 2015. Chi opera deve quindi tenere in mente tutte queste e le loro interrelazioni. Si potrebbe arrivare al paradosso di dover rispondere, nel dettaglio, rispetto a queste ultime (se non l’ho fatto sono colpevole) e, nello spirito, al Regolamento (quello che ho fatto potrebbe non bastare e sarei quindi nuovamente colpevole).

Alcune aziende vedono di buon occhio avere prescrizioni precise sulle cose da fare perché si crede che così la legge semplifichi il processo decisionale relativamente al “cosa fare” e al “perché farlo”; ma ciò ci fa sprecare l’opportunità di fare le cose giuste rispetto alla specifica situazione aziendale, ai vincoli e alle opportunità. Accettare questo passaggio concettuale fa tornare in primo piano i temi della “responsabilizzazione”, della consapevolezza su privacy e su security e della cultura informatica (che purtroppo non brillano in sanità e in molti altri settori industriali italiani). Il nostro ritardo ha causato numerosi incidenti di sicurezza e nel tentativo di proteggere gli interessati al trattamento, i cittadini e i pazienti, il legislatore ha inefficacemente riempito uno spazio lasciato vuoto dai nostri errori.

Identità e log

D’altra parte anche la legge fa fatica a parlare la lingua dell’informatica. Per esempio, salvo poche e parziali eccezioni[4], non si ha traccia di quanto sia importante garantirsi che l’“account” (rappresentato dal codice utente) sia assegnato nominativamente e sia profilato secondo il privilegio minimo (devo poter fare solo quello che serve per il mio lavoro). Ogni utente e ogni applicazione deve avere il suo proprio personale e riservato codice di accesso ai sistemi informatici, il cui uso individuale sia garantito da appropriati controlli tecnologici di sicurezza.

Ho accennato a cifratura e controllo accessi e ritengo che la sicurezza si possa esemplificare come una serie di misure atte a garantire che solo le persone autorizzate e con uno scopo lecito possano accedere ai dati aziendali. Siano essi medici , infermieri, personale amministrativo, programmatori o amministratori di sistema… La cifratura senza la gestione dell’identità e degli account è inutile; è come chiudere una (delle) porte e dare a tutti la chiave.

L’account nominativo permetterebbe anche di far funzionare effettivamente gli strumenti che controllano l’operato degli utenti e delle macchine analizzando i log prodotti, sia perché quanto registrato diventa riconducibile all’utilizzatore (e quindi produce informazione utile), sia perché la quantità di log prodotti e/o analizzati può essere ridotta tenendo conto delle variabili di contesto, la prima delle quali è appunto l’identità dell’utente[5].

Purtroppo spesso le applicazioni e i sistemi software hanno delle limitazioni e le pratiche organizzative le acuiscono. Alcuni esempi, scelti tra i numerosi disponibili, sono: i PC di corsia loggati con l’account del medico di turno e lasciati aperti per diverse ore; l’assenza di funzionalità di delega di funzioni autorizzative che rende necessaria la condivisione delle password tra operatori, direzione e segreteria; la condivisione della password dell’applicazione all’interno dei gruppi di sviluppo e infine la mancata propagazione tra diversi componenti software dell’identità dell’utente che effettua l’operazione.

Anche tali limitazioni sono ampiamente spiegate dall’evoluzione tecnologica. Il software e le pratiche organizzative si trasformano più lentamente di quanto l’abbiano fatto i requisiti di business e quelli “non funzionali” (qualità, sicurezza, manutenibilità, ecc). Una via d’uscita si intravede pensando alla specializzazione dei componenti architetturali.

Specializzazione, coesione e accoppiamento

La storia dell’innovazione in informatica ripete più volte lo stesso schema: le funzioni ricorrenti di un programma si separano dal corpo dello stesso e si invocano come servizio. Capitava 40 anni fa in linguaggio macchina e in COBOL con l’istruzione CALL e capita oggi con il middleware di vario tipo, la programmazione ad oggetti, la SOA (service oriented architecture) e con le API (application programming interface). Il componente che fornisce il servizio, compie bene quello specifico compito e si comporta come una scatola nera dalla quale aspettarsi un risultato a fronte di una specifica richiesta.

È necessario progettare le applicazioni sanitarie come servizi e spostare le funzioni di sicurezza nel “middleware”. Il risultato sarebbe software migliore, interoperabile e sicuro, ma tale trasformazione richiede “vision”, “governance” e un impegno rilevante dei clienti e dei loro fornitori. Inoltre ci si può aspettare delle resistenze perché esporre le proprie funzionalità come servizi permetterebbe la sostituzione degli stessi con dei servizi migliori come si fa con il plug and play. Quante applicazioni hanno il loro specifico modulo del consenso? Quanti diversi moduli del consenso ci sono in ogni ospedale?

Un altro aspetto della specializzazione, che non approfondisco qui, riguarda la specializzazione del lavoro in ambito informatico. Avere personale specializzato permette di eccellere in compiti specifici e riusare l’esperienza, ma ovviamente le organizzazioni con organici ridotti devono privilegiare l’ampiezza delle competenze rispetto alla specializzazione.

Conclusione

In sanità per via della delicatezza dei diritti sottesi (diritto alla salute, diritto alla privacy) e della carente informatizzazione si ha molto bisogno di investire in sicurezza informatica: persone, processi e tecnologia.

Dobbiamo essere in grado di prevenire, individuare, rispondere e predire gli incidenti di sicurezza.

Abbiamo bisogno di comprendere la situazione attuale, le sfide relative a rischio e compliance odierne e future, aggiungere nella nostra equazione il contributo di un ecosistema di attori che possono contribuire o ostacolare il cambiamento (lo stato, le regioni, i fornitori, dipendenti, consulenti ecc.).

Dobbiamo verificare lo stato e la qualità dell’implementazione di alcune tecnologie di base (networking, antivirus…) e valutare investimenti nelle tecnologie non ancora compiutamente adottate in sanità come ad esempio la gestione delle identità, il controllo accessi, la raccolta e analisi dei log e la cifratura dei dati “at rest” e “in transit”.

Dobbiamo controllare la rete, le applicazioni, gli application server, i database management systems, i sistemi operativi, i processi di sviluppo e manutenzione del software, di installazione, hardening, patching, configuration management, asset management…  e dobbiamo formare il personale e far evolvere l’organizzazione.

Gli argomenti sono innumerevoli, le competenze richieste sono molto specializzate e la complessità del sistema elevata: come si fa con budget e risorse limitate a fare bene tutto questo? Non si può.

Per scelta politica il governo della sanità è fornito a livello regionale e questo provoca una frammentazione degli investimenti che ostacola una modernizzazione estesa. Quanti diversi progetti FSE sono in corso oggi? Quanto software viene effettivamente riusato? Il resto dell’industria sta da diversi anni conducendo progetti di consolidamento infrastrutturale e applicativo. I centri servizi sono in questa logica, come lo è il cloud nei suoi diversi service model (IaaS, PaaS e finalmente SaaS) e deployment model (private, community, public, hybrid). In sanità invece il sistema evolve lentamente in questa direzione e solo all’interno delle Regioni.

Bisogna comprendere che l‘IT è anche in sanità un fattore critico di successo, che investire per fare bene le cose permette di spendere meno e migliorare contemporaneamente sia la qualità delle cure, sia il diritto alla protezione dei dati personali e inoltre aiuta a proteggere la reputazione e la proprietà intellettuale dell’azienda. Come prima cosa occorre puntare sulla qualità delle persone che governano la trasformazione digitale per cogliere le opportunità e non fallire di fronte agli ineluttabili e omnipresenti attacchi informatici. Una possibilità per recuperare le risorse necessarie è il consolidamento organizzativo e informatico, del software e dei data center.


[1] Per i problemi di sicurezza e privacy dei Percorsi Terapeutici Assistenziali (PDTA) rimando al sito AISIS e al lavoro svolto con Clusit e APIHM.

[2] Art. 32 paragrafo 4: Il titolare del trattamento e il responsabile del trattamento fanno sì che chiunque agisca sotto la loro autorità e abbia accesso a dati personali non tratti tali dati se non è istruito in tal senso dal titolare del trattamento, salvo che lo richieda il diritto dell’Unione o degli Stati membri.

[3] Art. 25 paragrafo 2: Il titolare del trattamento mette in atto misure tecniche e organizzative adeguate per garantire che siano trattati, per impostazione predefinita, solo i dati personali necessari per ogni specifica finalità del trattamento. Tale obbligo vale per la quantità dei dati personali raccolti, la portata del trattamento, il periodo di conservazione e l’accessibilità. In particolare, dette misure garantiscono che, per impostazione predefinita, non siano resi accessibili dati personali a un numero indefinito di persone fisiche senza l’intervento della persona fisica.

[4] Una di queste è rappresentata per l’aspetto dell’account nominativo e solo per gli amministratori di sistema ma non per quello del privilegio minimo, nel provvedimento del Garante denominato “Misure e accorgimenti prescritti ai titolari dei trattamenti effettuati con strumenti elettronici relativamente alle attribuzioni delle funzioni di amministratore di sistema” http://www.garanteprivacy.it/web/guest/home/docweb/-/docweb-display/docweb/1577499

[5] Ho già scritto degli errori più comuni nella gestione dei sistemi informativi nel rapporto Clusit precedente e gli esperti sanno che, anche nelle grandi aziende, alla regola dell’account nominativo non mancano le numerose eccezioni.

Photo by rawpixel on Unsplash