Questo articolo rappresenta il capitolo conclusivo della serie dedicata alla cybercriminalità nel settore sanitario, concentrandosi sugli aspetti operativi della gestione del rischio cyber. Dopo aver analizzato le minacce e le vulnerabilità del sistema sanitario digitale, questo contenuto si focalizza sulle metodologie concrete di risk management, dalla matrice di valutazione del rischio alla Data Protection Impact Assessment (DPIA).

Risk management nel comparto sanitario

Nei previ capitoli si è avuto modo di comprendere come il cyber risk sia ad oggi un rischio che, in certi settori e per alcune tipologie di danni (quali il furto di dati personali, il blocco di attività produttive o catene di fornitura, la violazione sistematica della privacy etc.), possa comportare impatti catastrofali.

Pertanto sarà necessario per costruire un’efficace politica di sicurezza[1], nonché per mettere in atto con successo le strategie preventive sopra descritte, attuare la c.d. “gestione dei rischi” (anche risk management)[2], quale processo comprendente tutte quelle azioni finalizzate ad identificare eventuali minacce o vulnerabilità cui una azienda risulti esposta al fine di sviluppare strategie e contromisure atte a poterle mitigare e controllare.[3]

Sebbene nessun sistema possa definirsi del tutto sicuro, esiste tuttavia un livello accettabile di sicurezza che è generato proprio dal bilanciamento di varie componenti: il valore di quanto si intende difendere, l’investimento economico che si è disposti a sostenere ed il livello di rischio che si è disposti a tollerare, pertanto risulterà essenziale addivenire ad un ragionevole compromesso tra tali esigenze poste in gioco.[4]

Soffermandosi il tempo dovuto sul concetto stesso di rischio, esso si figura quale condizione esistenziale, ineliminabile di ogni azienda, un fenomeno dalla natura sistematica,[5] che assume carattere dinamico,[6] essendo in grado di influenzare le condizioni di equilibrio economico, finanziario e patrimoniale.

Ancora si potrebbe qualificare come l’incertezza misurabile, riferendosi ad eventi, esterni od interni, per i quali è sempre possibile quantificare la frequenza con cui essi sono avvenuti in passato e di conseguenza il grado di probabilità di una loro verificazione futura.

Dando uno sguardo al panorama normativo ed in particolare all’art. 2 del D.lgs. n. 81/2008 (Testo unico per la sicurezza sul lavoro)[7], il rischio viene indicato come “la probabilità di raggiungimento del livello potenziale di danno nelle condizioni di impiego o di esposizione ad un determinato fattore o agente oppure alla loro combinazione”, si sta pertanto trattando ivi di una grandezza aleatoria, quale esprimente la probabilità che si verifichi un evento in grado di causare concretamente un danno.

Nonostante il legislatore stesso non suggerisca metodologie precise per addivenire ad un preciso calcolo del rischio, nella maggioranza dei casi ci si rifà al c.d. “metodo a matrici”, derivante originariamente dalle linee guida Ue atte a indirizzare ed accompagnare piccole e medie imprese verso una corretta ed efficace valutazione dei rischi.

Ebbene la matrice di rischio (anche matrice di impatto), quale strumento di analisi è riassumibile nella formula: [R] = [P] x [E], dove la grandezza [P] suole indicare la quantificazione (stima) della probabilità che il danno, derivante da un fattore di rischio dato, effettivamente si verifichi, mentre [E] risulta essere la quantificazione (stima) del potenziale danno, nella sua entità (o gravità).

La probabilità di accadimento [P] può assumere un valore sintetico in una scala da 1 a 4, a seconda della gamma di soglie di probabilità:

[P1] improbabile: il danno dipenderebbe da una concatenazione di eventi altamente improbabili e fra loro indipendenti, non sono mai stati registrati episodi simili in passato;

[P2] poco probabile: il danno si potrebbe verificare solo in circostanze alquanto particolari, raramente simili episodi sono accaduti in precedenza;

[P3] probabile: il danno potrebbe accadere, anche se non in modo automatico o diretto, suscitando una scarsa sorpresa, sono invero già stati riscontrati alcuni episodi simili in passato;

[P4] molto probabile: la situazione rilevata è direttamente correlata al verificarsi di un danno, la cui verificazione non susciterebbe stupore (anzi l’evento sarebbe largamente atteso), sono noti svariati episodi della stessa tipologia accaduti in precedenza.

La gravità del possibile danno [E] può assumere un valore sintetico in una

scala da 1 a 4, a seconda della gamma di soglie del danno:

[E1] lieve: si pensi ad un infortunio con effetti di inabilità temporanea, che siano rapidamente reversibili;

[E2] significativo: quale un infortunio con lesioni significative, ma ad ogni modo reversibili a medio termine;

[E3] grave: si pensi ad un infortunio con lesioni significative irreversibili o di invalidità parziale;

[E4] gravissimo: come un infortunio con lesioni altamente gravi irreversibili, invalidità totale o conseguenze letali. [8]

Pertanto una volta individuata una specifica situazione di pericolo, il valore numerico del rischio [R] sarà stimato quale prodotto fra l’entità del danno [E] e la probabilità di accadimento dello stesso [P], arrivando ad assumere un valore sintetico numerico compreso fra 1 e 16, per come si è voluto ricostruire nella matrice di rischio riportata a seguire:

Fig 6.1 Matrice di rischio secondo la formula [R]= [P] x [E]

In definitiva, l’anzidetta matrice risulta schematicamente una griglia, al cui interno da un alto verrà riportata la probabilità che un certo evento si verifichi e dall’altro l’impatto che questo stesso può comportare, incrociando le suddette grandezze poi si otterranno, come possibili risultati, differenti livelli di rischio:[9]

Rischio basso [1 ≤ R ≤ 2 ]: è da ritenersi pienamente accettabile, sicché non si richiederà l’adozione di alcuna tipologia di intervento;

Rischio moderato [3 ≤ R ≤ 4 ]: è anch’esso sopportabile, per cui l’adozione di specifiche azioni correttive sarà da valutare caso per caso;

Rischio medio [R=6]: è un livello che deve allertare, pertanto occorre tenerlo sotto adeguato controllo, saranno poi necessari interventi tecnici, organizzativi o procedurali, da programmare nel medio termine;

Rischio rilevante [R=9]: non risulta accettabile, richiederà pertanto interventi in tempi celeri atti a risolvere il problema;

Rischio alto [12 ≤ R ≤ 16]: è un livello di rischio assolutamente non accettabile che richiederà di interrompere immediatamente le operazioni e/o le attività e di non riprenderle fintanto che non si sia risolto il problema all’origine.[10]

Sulla base dei risultati sopra ottenuti, saranno adottabili tutta una serie di decisioni, quali: assumersi od evitare il rischio (ad esempio decidendo di iniziare o meno una determinata attività), rimuovere la fonte di rischio (quale una falla nella sicurezza di un sistema), modificarne la probabilità e le conseguenze (adottando misure, strategie e meccanismi di sicurezza), od altresì condividere il rischio stesso (servendosi di servizi assicurativi).

Da ultimo, con l’applicazione di una delle anzidette condotte si andrà ad evidenziare il grado di probabilità e gravità che permarrà, nonostante le azioni di mitigazione poste in essere, ossia il cosiddetto “rischio residuo”, che dovrà necessariamente esser tracciato, nonché sottoposto a periodici monitoraggi, in quello che si figura essere un modello di analisi dinamico e circolare.

Valutazione d’impatto (DPIA)

Passando ora a prendere in considerazione l’ambito della salute, risulta chiaro come medici, e strutture sanitarie in generale, debbano anch’essi gestire tutti quei rischi derivanti dal trattamento di una ingente mole di dati ipersensibili dei pazienti, optando per soluzioni operative che offrano massima protezione e riservatezza, nel rispetto dei diritti fondamentali degli individui.

Si ricordi come il Regolamento Ue 2016/679 (GDPR) si muova in un’ottica di responsabilizzazione (o accountability) nei confronti della figura del Titolare del trattamento[11], che dovrà adottare tutte le misure tecniche ed organizzative adeguate per garantire un livello di sicurezza proporzionato al rischio, di varia probabilità e gravità per i diritti e le libertà delle persone, inclusa la protezione, ex art. 5 contro “trattamenti non autorizzati o illeciti, la perdita, la distruzione o il danno accidentale”.

Ecco come posto di spiccato rilievo viene assunto, tra le novità introdotte dalla suddetta disciplina europea, dalla Valutazione d’impatto sulla protezione dei dati (anche detta DPIA, ossia Data Protection Impact Assessment), quale processo volto a descrivere il trattamento, valutarne necessità e proporzionalità, nonché ad identificare e gestire i rischi che ne derivino per i diritti delle persone fisiche, determinando in tal modo tutte le misure e tecniche atte ad affrontarli.

Nello specifico dall’art. 35 del Regolamento Ue, si evince come la DPIA sia obbligatoria laddove si svolgano trattamenti che, per loro stessa natura, oggetto, contesto e finalità possano presentare un rischio considerabile come elevato.[12] Ovvio è come identificare tutti i casi rientranti nello scenario appena delineato non sia sempre un’operazione semplice ed immediata, per questo si necessita di una fase preliminare, definibile per l’appunto come “prevalutazione d’impatto”, in cui il titolare del trattamento, una volta raccolte le informazioni essenziali, coadiuvato dal DPO (Data protection officer) qualora designato, valuterà l’opportunità e/o la necessità di procedere o meno ad una DPIA.

Il GDPR stesso viene in soccorso in tale prevalutazione, non elencando tassativamente i casi di obbligatorietà, ma limitandosi ad individuare tre ipotesi generali in cui la DPIA viene richiesta:

a) quando il trattamento comporta una valutazione sistematica e globale di aspetti personali relativi a persone fisiche, basata su un trattamento automatizzato, compresa la profilazione, e sulla quale si fondano decisioni che hanno effetti giuridici o incidono in modo analogo significativamente su dette persone fisiche;

b) in caso di trattamento, su larga scala, di categorie particolari di dati personali di cui all’articolo 9, paragrafo 1 (fra i quali, si ricorderà, sono compresi i dati relativi alla salute);

c) qualora il trattamento abbia ad oggetto la sorveglianza sistematica su larga scala di una zona accessibile al pubblico.

A tali indicazioni generali poi si vanno a sommare le Linee Guida WP 248 emanate dal Gruppo di lavoro “Articolo 29” (ad oggi European Data protection Board), che a loro volta identificano nove casi in presenza dei quali si può desumere che il trattamento presenti proprio “un rischio elevato per i diritti e le libertà delle persone fisiche” e che dunque si debba procedere con la DPIA:[13]

a) valutazione o assegnazione di un punteggio, inclusiva di profilazione e previsione;

b) processo decisionale automatizzato, mirante a consentire l’adozione di decisioni in merito agli interessati che abbiano effetti giuridici o che incidano in modo analogo significativamente su dette persone fisiche;

c) monitoraggio sistematico;

d) trattamento di dati sensibili od aventi carattere altamente personale;

e) trattamento di dati su larga scala, valutando a tal fine: il numero di soggetti interessati, il volume e le diverse tipologie dei dati, la durata, la persistenza ed altresì la portata geografica dell’attività di trattamento;

f) creazione di corrispondenze o combinazione di insiemi di dati;

g) trattamento di dati relativi ad interessi definibili come vulnerabili;

h) uso innovativo od anche applicazione di nuove soluzioni tecnologiche ed organizzative;

i) quando il trattamento in sé impedisce agli interessati di esercitare un diritto o di avvalersi di un servizio o contratto.

Risulta evidente come l’ambito sanitario vada a soddisfare molteplici dei suddetti requisiti, dal momento che risulta qualificabile come trattamento “su larga scala” di dati “sensibili” e/o relativi a categorie di interessati “vulnerabili” (si pensi a minori, anziani, pazienti affetti da patologie invalidanti etc.), che fa largo uso di tecnologie “avanzate ed innovative”.

Effettivamente la rilevazione di dati e parametri vitali tramite strumenti di monitoraggio a distanza (o mediante wearable devices), l’utilizzo di sistemi di AI per l’individuazione di terapie personalizzate, l’adozione di tecniche di machine learning nell’individuazione di gruppi di pazienti con una maggiore o minore propensione a sviluppare specifiche patologie, sono tutti esempi di acquisizione di dati che incidono sì principalmente sul diritto alla salute, ma altresì su svariati ambiti di vita quotidiana dei singoli individui, per tale motivo una valutazione d’impatto incentrata sull’analisi dei rischi derivanti da tali tipologie di trattamenti sanitari si profila come pienamente necessaria.[14]

Uno specifico modello di gestione dei dati dovrà essere in grado infatti di assicurare, costantemente, la riservatezza, l’integrità, la disponibilità ed anche la resilienza dei sistemi, cosicché in caso di accadimento di un evento negativo (interno od esterno) si possa comunque ripristinare tempestivamente tanto la disponibilità quanto l’accesso ai propri dati personali. [15]

Si passino così a considerare le concrete fasi del processo iterativo di una DPIA, per come vengono delineate dalle sopradette linee guida del WP29:

a) Descrizione del trattamento: innanzitutto occorrerà identificare tutti i diversi soggetti che siano coinvolti a diverso titolo (titolare ed eventuali contitolari, outsourcer responsabili esterni, amministratori di sistema etc.), come anche le tipologie di dati trattati, le piattaforme tecnologiche utilizzate e le finalità del trattamento stesso.

L’individuazione dei soggetti e la definizione dei livelli di responsabilità è indubbiamente un primo step difficoltoso, considerando la necessaria condivisione ed interoperabilità che caratterizza primi fra tutti i dati sanitari (si pensi a tutti gli episodi sanitari che caratterizzano la presa in carico di un paziente: assistenza domiciliare, programmi di screening, assistenza specialistica ambulatoriale, ricoveri, riabilitazione, gestione della cronicità etc.).

Durante ogni contatto infatti il paziente riceve determinate prestazioni (visite, esami, terapie, interventi etc.) che a loro volta ingenerano atti sanitari (un referto, il risultato di un esame di laboratorio etc.) per i quali può essere necessario impiegare risorse (materiali, attrezzature, spazi etc.) e dati clinici, che successivamente potranno essere aggregati e strutturati in documenti più complessi per essere consultati da differenti tipologie di utenti in funzione dei profili di abilitazione e delle differenti esigenze cliniche (percorsi diagnostici, terapeutici, assistenziali etc.).[16]

Risulta evidente come, alla luce della particolare sensibilità e rilevanza sia per la sicurezza dei procedimenti che dei pazienti, i dati clinici debbano essere gestiti seguendo criteri di sicurezza e tracciabilità (ossia verificando i sistemi di log management, assicurando l’autenticità, la data certa e le versione dei documenti ed altresì garantendo la loro non cancellazione o sovrascrittura);

b) Valutazione circa la necessità e proporzionalità del trattamento: in tale fase, una volta individuate possibili linee guida di riferimento da seguire (quali in materia di referti online, sul trasporto di campioni diagnostici, sul generale trattamento di dati genetici etc.) e descritto il ciclo di vita dei dati, la valutazione della proporzionalità dovrà essere approfondita in termini di quantità, frequenza, persistenza di raccolta di dati, come anche di ampiezza geografica dell’area di raccolta (si pensi ad un titolare che operi su più presidi territoriali);

c) Valutazione dei rischi: è indubbiamente la fase saliente della DPIA, in cui peraltro si evidenzia la necessità di far sì che la predisposizione del registro dei trattamenti[17] non sia un mero esercizio forma, ma piuttosto l’esito di una attenta valutazione tanto del contesto organizzativo di riferimento quanto dei processi aziendali da cui le attività di trattamento dei dati scaturiscono.

Per una corretta individuazione delle minacce si opererà una combinazione dei seguenti elementi, che stanno all’origine dei possibili incidenti: risorse (hardware, software, infrastrutture, etc.), azioni (guasto, atto doloso, errore etc.) e rischi dati (perdita di integrità, di confidenzialità, di riservatezza etc.).

Così a titolo esemplificativo, la minaccia di accesso abusivo ad un sistema è conseguenza di un atto doloso (azione), perpetrata su di una infrastruttura di rete (risorsa) che avrà ripercussioni sulla confidenzialità del dato. Ovvio è che suddetta analisi delle minacce non dovrà essere limitata al mero “rischio dato” inerente alla perdita di integrità, confidenzialità e disponibilità, ma anzi dovrà prendere in considerazione anche i possibili effetti che il rischio può avere per i diritti e le libertà delle persone fisiche, seguendo così un approccio altamente multidisciplinare che tenga conto in egual misura della sicurezza dei pazienti, della continuità operativa, della cybersecurity ed anche della capacità di resilienza dei sistemi. [18]

Cyber risk management: vulnerabilità e minacce nelle organizzazioni ospedaliere

A proposito di rischio si rilevi come nel complesso panorama sanitario oltre alla sicurezza delle cure, vi sia quella del farmaco, quella dei luoghi di lavoro, del rischio infettivo, delle radiazioni ionizzanti, quella strutturale ed ovviamente quella informatica. Tutti tali aspetti orbitano attorno a chiunque partecipi alla vita delle aziende sanitarie (si pensi ad operatori, utenti, fornitori terzi, visitatori etc.), ebbene non pare più possibile ragionare “per silos”, anzi ad oggi occorre una visione del rischio che sia quanto più integrata e complessiva possibile.

Ad ogni modo sono gli attuali fatti di cronaca a parlare chiaro: l’ambito sanitario risulta uno dei settori maggiormente esposti e vulnerabili sul versante della cybersecurity.

Tra i fattori di rischio che più possono incidere in tal senso si notino:

1. L’ampia diversificazione delle figure professionali coinvolte, ognuna di queste con diversi profili di autorizzazione nei sistemi informatici e che spesso si ritrovano a poter accedere anche a più attrezzature collegate in rete;
2. La necessità di garantire l’interoperabilità dei sistemi, e di integrare attrezzature fortemente diversificate sia all’interno della organizzazione che lungo la supply chain;
3. L’utilizzo di strumentazioni medicali, fra cui sempre più soluzioni IoMT, non sempre progettate secondo una logica di sicurezza by design e che, non di rado, si ritrovano ad essere dotate di sistemi operativi obsoleti o per i quali non sono facilmente disponibili o reperibili patch di aggiornamento. Ad oggi invero un paziente può essere monitorato in modo più completo, senza tuttavia la necessità di appuntamenti “faccia a faccia” o trattamenti invasivi (si pensi al telemonitoraggio domiciliare attuato tramite dispositivi indossabili). L’attuale molteplicità di dispositivi interconnessi crea numerosi potenziali punti di infiltrazione e conduce inevitabilmente alla possibilità di subire maggiori attacchi informatici. [19] Sotto quest’ultimo profilo si rammenti ivi la c.d. Valutazione delle tecnologie sanitarie (anche detta Health Technology Assessment o HTA) quale strumento utilizzato a livello internazionale consistente nella “complessiva e sistematica valutazione multidisciplinare circa le conseguenze assistenziali, economiche, sociali ed etiche provocate in modo diretto ed indiretto, nel breve e lungo periodo, dalle tecnologie sanitarie esistenti e quelle di nuova introduzione”. [20]

È dunque una guida, un ponte fra il mondo tecnico-scientifico e quello propriamente decisionale, incentrata sull’analisi delle conseguenze attese dall’introduzione di specifiche tecnologie sanitarie, nonché di soluzioni digitali nel contesto di una organizzazione sanitaria (si pensi all’adozione di nuovi dispositivi medici, farmaci, sistemi diagnostici, procedure chirurgiche, percorsi assistenziali, attrezzature sanitarie, od assetti strutturali, organizzativi e manageriali, etc.), atta a focalizzare l’attenzione sulla attenta valutazione circa i profili di: efficacia clinica, protezione dei dati personali, prospettiva dei pazienti, cybersicurezza, aspetti economici, organizzativi, come anche etici e legali;

1. La stessa mancanza di risorse ingenera vulnerabilità, volendosi riferire sia al fattore umano, per cui il personale IT risulta essere inadeguato, mancando per di più figure altre che possano occuparsi di campi multidisciplinari quali il risk management, la data protection o la stessa privacy management (portando ad una inevitabile ambiguità rispetto a chi sia effettivamente responsabile circa le tematiche di sicurezza). Ma un’altra risorsa a mancare risulta essere proprio il budget ed uno dei motivi per cui i fondi per la sicurezza informatica sembrano essere insufficienti è che le organizzazione sanitarie tendono ad indirizzare le proprie scelte d’acquisto, nonché finanziamento verso risorse legate propriamente all’assistenza clinica ed alle cure mediche, lasciando gli aspetti legati alla cybersicurezza nel dimenticatoio.[21]

Chiaro risulta come la cultura del rischio si sia evoluta nella sanità italiana, facendosi strada la graduale consapevolezza per cui la sicurezza in sanità non possa limitarsi solo più al rischio clinico, ma debba abbracciare ogni ambito, dall’informatico, al gestionale ed altresì strutturale. Il paradigma invero sta per mutare: dati e servizi sanitari saranno sempre meno chiusi negli hardware delle strutture sanitarie e sempre più diffusi e scambiati sui cloud, e ciò non farà altro che aumentare i rischi. Occorre dunque cogliere questo momento di passaggio per costruire una matura cultura delle sicurezza cyber prima che sia fin troppo tardi per arginare i danni.

Si voglia indirizzarsi verso le conclusioni riportando di seguito il survey realizzato da SHAM Italia, società specializzata in assicurazione e gestione rischi, datato al 2021, quale indagine conoscitiva rivolta ai professionisti ed alle strutture sanitarie e socio-sanitarie italiane, col preciso obiettivo di comprendere quanto il cyber-rischio sia conosciuto, come venga gestito, ed altresì quali siano le prospettive per il futuro.[22]

In particolare i partecipanti a tale sondaggio sono stati 68, provenienti da strutture ed aziende sanitarie, pubbliche e private, di 14 regioni italiane, sebbene non si tratti di un campione eccessivamente esteso, il contributo fornisce ad ogni modo un valido punto di partenza per comprendere il grado di consapevolezza degli operatori sanitari su tema del rischio cyber come anche quali siano le principali aree dove intervenire al fine di poter migliorare il campo della sicurezza informatica.

Il primo dato ricavabile, che lascia peraltro ben sperare, è l’alta sensibilità in materia: circa il 60% dei rispondenti (ossia Referenti di direzione sanitaria generale e di ingegneria clinica, responsabili CISO della sicurezza informatica, Risk manager, Data protection officer etc.) dichiara invero il cyber risk come altamente impattante sui modelli organizzativi interni e sulle attività da erogare, oltre ad un ulteriore 31% che lo qualifica comunque come un tema parzialmente prioritario, se si vanno a sommare tali due espressioni di interesse si ottiene un buon 90% dei rispondenti che valorizzano positivamente l’interessamento al tema de quo.

Di contro però l’immediato paradosso: il 53% dei rispondenti dichiara di non aver (o aver solo in parte) definito concretamente un piano di gestione del rischio, solo il 44% poi dichiara di aver reattivamente adottato ed implementato azioni di miglioramento interno in seguito all’avverarsi di eventi avversi, ed ancora meccanismi quali mappature dei rischi od anche test sulle vulnerabilità risultano scarsamente effettuati (da circa il 30% dei rispondenti).

Ebbene all’elevato interesse sul tema non sembra quindi corrispondere un altrettanto sentita sua identificazione, misurazione e gestione, si noti peraltro come solo il 10% dei rispondenti affermi di aver provveduto a contrarre apposite polizze assicurative contro i danni informatici al fine sia di trasferire eventuali conseguenze economiche circa un evento avverso, sia di avere un adeguato supporto tecnico attivo in caso di necessità. Soffermandosi celermente sui rischi legati alla sottrazione dati ed alla violazione della privacy, è da rilevare come nel corso degli ultimi anni sia cresciuta in maniera esponenziale la domanda di coperture assicurative strutturate in modo da affrontare i costi relativi a tali nuovi rischi ed incidenti cyber.

Anche in tali tipologie di polizze si troverà una concezione strettamente attuariale delle assicurazioni, basata sulla capacità di prevedere in anticipo la probabilità e l’impatto di possibili eventi dannosi, informazioni che vengono per lo più ricavate dai dati relativi al passato, facendo poi delle ipotesi sui futuri accadimenti. Ciononostante, suddetti rischi risultano comunque particolarmente complessi da decodificare, a causa proprio della rapida evoluzione tecnologica che caratterizza il settore de quo.

Sicuramente nel novero delle principali cyberminacce per le quali potrebbe essere disponibile una copertura assicurativa rientrano:

1. la divulgazione di informazioni sensibili protette od il blocco dei sistemi informatici (si ricordi come l’estorsione preveda, nella maggior parte dei casi, il pagamento del riscatto tramite valuta digitale);
2. il mancato guadagno lungo il perdurare di un certo periodo di tempo, determinato a causa di un evento di violazione delle informazioni.[23]

Rimane tuttavia importante considerare che sarebbe del tutto irrealistico pensare di poter azzerare completamente il rischio cibernetico all’interno di una azienda: diventa quindi ineludibile un cambio di paradigma, che vede un diretto coinvolgimento ed una forte implementazione del risk management, nelle sue diverse declinazioni di: mitigazione, prevenzione, trasferimento ed assunzione del rischio.

Ed il risk management dovrà essere inteso quale approccio valutativo che incomincia con l’identificazione di tutti i rischi potenziali, nonché degli asset e delle specifiche vulnerabilità, per successivamente valutare la probabilità circa l’avverarsi di un evento avverso, il suo impatto e le misure di salvaguardia da adottare per ridurne gli effetti negativi. Solo così il rischio potrà essere mitigato ed altresì costantemente monitorato nel tempo, seguendo una procedura dal carattere fortemente circolare atta a garantire alti livelli di cybersicurezza.[24]

Da qui l’assunto cardine per indirizzare il futuro della sanità italiana: senza una adeguata sicurezza, la digitalizzazione del settore sanitario non potrà mai dispiegarsi compiutamente, in quanto la sicurezza stessa non è una risposta alla innovazione, ma piuttosto il suo requisito fondamentale.

Una visione d’insieme

Si voglia a questo punto indirizzarsi verso riflessioni conclusive fornendo una prospettiva sistematica e strutturata, volta ad analizzare le dinamiche di sviluppo ed implementazione della cybersecurity nelle strutture ospedaliere e su come talune dinamiche organizzative interne possano a tutti gli effetti interagire fra loro al fine di sviluppare un sistema sanitario complessivamente cybersicuro.

Si è già ampiamente notato nel discorrere dei capitoli precedenti come le capabilities relative alla cybersicurezza in sanità includano una ampia varietà di programmi, sistemi, comportamenti e tecnologie che un ospedale può decidere di impiegare col preciso obiettivo di potenziare la propria resilienza informatica.

Tuttavia non tutte le anzidette strategie e soluzioni operative si presentano come autosufficienti, anzi possono erodersi e scemare nel tempo laddove non vengano opportunamente attuate, adottate, monitorate e mantenute. Al fine di voler riassumere graficamente un panorama organizzativo così complesso si farà uso a seguire delle variabili di stock e di flusso.[25]

Si incominci dunque dando uno sguardo al nucleo del modello proposto, ossia la variabile di stock evidenziata e denominata “Cybersecurity capabilities at hospital” quale raffigurante l’accumulo di tutti i programmi implementati e comportamenti adottati determinanti la sicurezza complessiva di una specifica organizzazione. Una variabile di flusso invece ha la funzione di modificare e far variare quella anzidetta di stock, da qui si possono notare la variabile di afflusso (“Cybersecurity capability development”), indicante il tasso al quale le capacità vengono aggiunte allo stock esistente, e di deflusso (“Cybersecurity capability erosion”), specificante viceversa il tasso al quale le capacità stesse vengono eliminate dallo stock esistente (Fig. 6.2). [26]

Fig. 6.2 Primo loop di cybersecurity

Fonte: “Cybersecurity in hospitals: a systematic, organizational perspective”, in Journal of medical Internet Research, rimando a nota.

Un primo fattore variabile viene rappresentato dalla disponibilità di risorse (“Resource availability”): mezzi quali acquisti, protocolli, strumenti, tecnologie e personale costituiscono invero gli elementi costitutivi essenziali che consentono ad una struttura sanitaria di compiere gli sforzi necessari al fine di aumentare la capability development rate e di conseguenza incrementare lo stock delle attuali potenzialità ospedaliere. A sua volta ciò innescherebbe un accrescimento circa il livello di sicurezza informatica (“Cybersecurity level”), riducendo il divario fra il livello effettivo e quello desiderato di protezione, e, si capirà, laddove tale gap diminuisca, si attenueranno di conseguenza anche gli sforzi (“Efforts to fill out the gaps”) richiesti per colmare le lacune di sistema.

È così che si verrà a delineare un primo anello, anche detto feedback loop (B1) indirizzato a bilanciare e stabilizzare il sistema complessivo, guidandolo verso il raggiungimento dell’obiettivo desiderato.

Congiungendo allo schema de quo ulteriori elementi (Fig. 6.3), si osservi come il livello di sicurezza possa calare a causa della presenza di specifiche vulnerabilità (si pensi all’arretratezza delle tecnologie adoperate), che implicano una più alta probabilità di successo circa la perpetrazione di eventuali cyber attacchi, che laddove raggiungano effettivamente un esito positivo, non faranno altro che sobbarcare una data struttura di maggiore pressione ed impellenza circa l’urgente necessità di raggiungere il livello desiderato (nonché richiesto) di security (da qui il secondo cerchio, o balancing loop B2, raffigurante il giungere del bisogno di più robuste capabilities).

Fig. 6.3 Secondo loop di cybersecurity

Ancora si vogliano aggiungere ulteriori fattori rilevanti (Fig 6.4), in primis la complessità degli end point (ossia di tutti i device, strumenti, apparecchiature e macchinari interconnessi), aggravata dalla mancanza di consapevolezza da parte del personale medico circa le corrette pratiche di sicurezza informatica da dover adottare nell’operare quotidiano, andando così ad accentuare fortemente le già esistenti vulnerabilità della struttura, conducendo inevitabilmente ad una riduzione della complessiva capacità dell’organizzazione di gestire lo scenario relativo alla propria cybersicurezza.

In secundis si sottolinei come laddove tutti gli attori dell’organigramma sanitario non riconoscano la dovuta importanza alle tematiche di security, cooperando e collaborando fra loro, andranno a minare fortemente tutti gli sforzi fatti per colmare tutte le lacune di sistema sopradette, impattando negativamente sul livello generale di cybersecurity (entrando in un loop recitante “We are gonna get hacked anyway”).

Viceversa dovrebbe essere proprio quella anzidetta pressione ingenerata dall’eventualità di subire cyber attacchi indirizzati alla propria struttura (quale il non voler subire un danno reputazionale) a spingere tutti gli stakeholder interni ad allinearsi lungo la medesima strategia operativa difensiva e di rafforzamento della propria resilienza.

Fig 6.4 End point e stakeholder nel sistema

Ebbene il meccanismo circolare delineatosi sino a qui non risulta, a ben vedere, applicabile solo ad una singola realtà ospedaliera, ma altresì a tutto un sistema sanitario nella sua interezza, essendo che le vulnerabilità informatiche proprie delle strutture sanitarie in un dato Paese altro non è che il risultato, non certo di una, quanto di una ingente molteplicità di strutture.

Per esemplificare si ipotizzi di applicare il modello de quo su 1000 ipotetici ospedali (nonostante ciascuno abbia il proprio livello di disponibilità di risorse ed il proprio personale target di sicurezza da raggiungere), ciò che è ricavabile da suddetta operazione è proprio il livello di vulnerabilità complessivo di un sistema sanitario, che andrà necessariamente a determinare l’attrattiva che quest’ultimo riveste per l’agire di cybercriminali (attrattiva che verrà valutata assieme ad altri fattori variabili, quali il valore economico dei dati sanitari custoditi dalle diverse organizzazioni).

Fig. 6.5 Applicazione del modello su larga scala

Pertanto guardando i risultati ottenuti adottando un punto di vista macro, la vulnerabilità cyber delle infrastrutture ospedaliere di un dato Paese si ritrova ad esser fortemente condizionata dalle capabilities proprie di ogni singola struttura. Cercare dunque di ridurre ed appianare i divari circa le differenti disponibilità di risorse (tanto fisiche quanto umane) fra diversi ospedali, disseminati in una data zona geografica, potrebbe aiutare a rendere l’intero sistema meno vulnerabile, si spieghi meglio: anche solo pochi ospedali con scarsi livelli di cybersecurity potrebbero andare a minare un’intera assistenza sanitaria nazionale.

In altre parole risulta ad oggi necessario che le strutture si muovano unite e di pari passo, all’interno di una cornice di politiche indirizzate ad incrementare il pari livello collettivo di sicurezza cyber, riducendo le dissomiglianze ed i divari in termini di disponibilità di risorse

Lo sviluppo di una digital health nazionale dovrà quindi trovare piena realizzazione all’interno di un progetto di politiche pubbliche che sia organico e lungimirante di governance sanitaria, che promuova una condivisione selettiva dei dati sanitari, scongiurando la perdita di informazioni sensibili od il blocco dei sistemi interni, al fine di minimizzare i rischi cibernetici e le conseguenti possibili lesioni dirette alla sfera personale della riservatezza, della dignità e della safety degli individui.

Strategie future per il risk management della sanità digitale italiana

Si voglia ivi ripetere il seguente concetto a fini riassuntivi: l’uso di Internet e delle ICT (Information and Communications Technology) costituisce, per il mondo sanitario, un meccanismo senza precedenti, propulsore di innovazione, atto a fornire risposte sempre più efficienti alle odierne problematiche legate alla salute. Maggiore informatizzazione e automazione dei processi tuttavia, se da un lato comportano nobili ed evidenti vantaggi, dall’altro, laddove non vengano sapientemente governati, rendono qualsivoglia struttura permeabile e terreno fertile per nuove forme di rischio. [27]

Tentando di pronosticare l’evolversi della sanità si può, a ben vedere, immaginare uno scenario futuro sempre più ibrido: alcune prestazioni sanitarie permarranno erogate “on site”, ossia in presenza del paziente (negli ospedali, nelle strutture diagnostiche), altre rimarranno ibride, ossia in parte in presenza ed in parte virtuali (si pensi al telemonitoraggio ed alla telerefertazione), altre ancora diventeranno solo più virtuali (quali una televisita).

Il perimetro dunque da securizzare tenderà ad allargarsi, passando da una sanità “ospedalocentrica”, ad un coinvolgimento domiciliare del cittadino, con un conseguente numero maggiore di dati in circolo e sempre più persone coinvolte nel, già complesso, organigramma sanitario.

Si voglia pertanto spostare l’attenzione sulle attuali sfide e sui conseguenti approcci che si pensa debbano essere adottati per farvi fronte.

Innanzitutto occorre assumere una piena consapevolezza circa l’ampiezza del tema, il problema della sicurezza infatti non è riconducibile solo al terreno puramente tecnologico, ma anzi va declinato sulla realtà aziendale nella sua interezza ed alla complessiva capacità di essere resiliente. Si riportino a questo proposito le parole di Schneier: “If you think technology can solve your security problems, then you don’t understand the problems and you don’t understand the technology”.[28]

Peraltro ritenere che il CISO o il DPO siano le uniche figure a doversi curare ed occupare delle tematiche inerenti alla sicurezza significa sviare la sua complessità, banalmente nel momento in cui si stipula un contratto di fornitura di beni o servizi occorrerà domandarsi se il fornitore, sebbene soggetto terzo, sia esso stesso in grado di fornire sicurezza.

Da qui deriva l’attuale problema della supply chain, che non concerne quindi solamente i fornitori tecnologici (se si acquista Office 3.6.5 ci si può aspettare, a ben vedere, un certo livello di sicurezza garantito), ma anche coloro che, nonostante siano slegati da aspetti puramente informatici, devono parimenti essere responsabilizzati (si pensi ad un’azienda che distribuisce ossigeno ai pazienti terminali, questa avrà tutta una catena logistica di furgoni, mezzi ed operatori in grado accedere agli archivi di una azienda sanitaria e modificarne i dati contenuti, ad esempio laddove cambi il caregiver di un paziente).

Si auspica quindi di far comprendere come tutta la catena plurisoggettiva dovrà essere responsabilizzata tramite procedure e protocolli sofisticati, anche se i soggetti protagonisti risultino prima facie estranei da quell’area puramente tecnologica maggiormente esposta al rischio.

Così Sergio Fumagalli, esperto CLUSIT: [29] “Il tema da dover interfacciare è l’interoperabilità, andando cioè a toccare tutti i processi, le risorse umane ed ogni altra risorsa essenziale, che non sia soltanto IT, altrimenti si rimarrebbe bloccati in un’attitudine settoriale, come in una linea Maginot francese, invece il modello da adottare deve essere quello «svizzero», in cui tutte le persone di ogni cantone dedicano un mese all’anno per l’addestramento alla difesa del proprio cantone. Certo nella sanità il confine non si figura fisso e definito come quello svizzero, anzi si espande in continuazione, con nuovi cantoni (od unità) dando forma ad una realtà in cui addestrare e formare ciascuno per difendere il proprio tassello”.

È così che si arriva nuovamente a ribadire il problema della formazione: a nulla servirà infatti dotarsi di sofisticati sistemi di identity management se poi l’operatore finale sanitario finisce per attaccare con un post-it sul proprio pc la password per accedere sistema. Una attuale sfida risulta allora far crescere una sempre maggiore cyber-cultura tramite corsi di aggiornamento e di formazione che appaiano stimolanti per gli operatori e che non vengano viceversa percepiti quali gravose lungaggini o perdite di tempo, da dover sostenere solo perché vi si è costretti.

Come fare concretamente?

Si ipotizzi la possibilità di programmare incontri diretti (invece che online) ravvicinati e collegiali, in presenza di tutti coloro che si ritrovano day by day ad operare sui dati, oppure si consideri la creazione di siti web e piattaforme FAQ (ossia, di Frequently Asked Questions) facilmente intuibili e dotati di rapide risposte, pare verosimile infatti ritenere che il personale sanitario voglia seguire procedure sicure, che spesso e volentieri però non sappia concretamente come fare. Peraltro non è più il tempo di mirare ad una formazione generale (e quindi, dispersiva), sarebbe invero preferibile cucirla ad hoc su ogni soggetto (primario, infermiere, fornitore etc.) di modo che concerna nello specifico i singoli tasselli operativi e gli obiettivi propri di ciascuno.

Questo è ad oggi il punto focale: la cyber-formazione deve essere sentita come obbligatoria, nonché avvertita come indispensabile per tutti, avvicinando l’offerta know-how con chi dovrà porre in essere determinati trattamenti, e nella sanità tutto ciò risulta difficile perché le priorità avvertite sono altre (quali la cura e l’assistenza puramente clinica dei pazienti). Com’è evidente, sarebbe più facile dotarsi di consulenti e di una svariata serie di procedure per ottemperare alla compliance richiesta piuttosto che “calarsi in basso”, andando a toccare e correggere automatismi, nonché consuetudini di lavoro profondamente radicate che nessuno ha veramente l’intenzione di cambiare.

Resta il fatto che procedure tecnico-organizzative, set documentali, oneri burocratici e compliance non bastino più, occorre sopportare il costo (oneroso) del modificare alla radice il modo attuale di operare, perché il rischio di non farlo è, come si è visto, seriamente alto e cresce in misura esponenziale col crescere della pervasività della tecnologia.

È evidente, ma pare comunque doveroso sottolineare che la sanità, quale sistema informativo complesso, necessiti di una attenzione costante nel tempo e di un approccio sistematico alle tematiche di sicurezza e privacy, che non sia viceversa sporadico, non servirà “correre dietro all’emergenza”, anzi oggi più che mai vi è la forte necessità di stanziare budget pluriennali e fissi da investire miratamente sulle tematiche inerenti alla sicurezza cyber.

Al fine di concretizzare quanto finora descritto il settore sanitario dovrà ad ogni modo rivedere e superare la sua attuale infrastruttura informatica, spesso eterogena e frammentata, facendo ricorso ad un approccio olistico che dia forma ad una governance in grado di coniugare sia misure di natura tecnica, sia aspetti organizzativi, procedurali, normativi ed in particolar modo di gestione ed analisi del rischio.

A proposito di rischi, dal momento che ad oggi risultano tutti strettamente connessi, ed analizzabili di conseguenza in un’unica sintesi, allora tutti dovranno comparire dinnanzi alla Direzione strategica misurati e comparati, così da poter operare una valutazione obiettiva circa le esigenze da soddisfare, individuando dove investire sulla base dei punti di forza e debolezza individuati all’interno delle stesse Aziende sanitarie.

Da qui discende l’attuale urgenza di implementare e rafforzare il ruolo del risk manager, quale figura altamente multidisciplinare, in grado di abbracciare, comprendere e ponderare tutti gli ambiti del rischio. D’altra parte conseguire le competenze professionali necessarie a rivestire tale posizione è un processo, o meglio una evoluzione, in cui piuttosto che il curriculum formativo di partenza conta la formazione continua ed altresì l’aggiornamento costante lungo tutta la propria vita lavorativa circa ogni aspetto organizzativo, tecnologico, normativo o clinico che possa riguardare il rischio.

Questo è ciò che pare emergere: il reale bisogno di un risk manager che entri nei processi, che sappia ampliare le proprie competenze anche all’area della business continuity e alla gestione delle emergenze, una figura autorevole con una padronanza della materia, in grado di gestire la crescente complessità del nostro quotidiano.

Tale esigenza si origina direttamente da alcune criticità e vulnerabilità che caratterizzano l’ambiente sanitario, prima fra tutti la scarsa conoscenza dei rischi, per come celati anche nelle operazioni più banali poste in essere da parte dei tanti operatori che si servono quotidianamente di digital data e device, inconsci spesso di cosa mettono in moto e della esposizione che possono provocare.

Ancora, si osservi come il personale addetto alla sicurezza informatica risulti alle volte insufficiente, così come i ruoli legati propriamente al rischio cyber non sufficientemente definiti all’interno dello stesso organigramma sanitario, la gestione dei sistemi tecnologici quindi pare abbisognare di maggiori addetti e nuovi ruoli professionali atti ad informare e dialogare periodicamente con gli stessi risk manager. [30]

Pertanto, l’ambito dove risiede una maggior possibilità di miglioramento e, parallelamente, in cui vi è l’urgenza di adottare azioni e misure correttive, risulta essere la competenza, la formazione costante, ed anche la chiarezza dei ruoli, risultando l’investimento più promettente al fine di rafforzare ed implementare la resilienza e sicurezza informatica della sanità italiana.

Nel futuro prossimo l’unità organizzativa di risk management allora dovrà integrare nuove competenze e sperimentare nuovi modelli, che siano applicabili anche su scala nazionale, che prevedano il legame diretto tra risk management e Dirigenza strategica, riconoscendo allo stesso risk manager la possibilità di analizzare tutte le informazioni circa i vari rischi provenienti dai dipartimenti specialistici e determinare di conseguenza il livello di urgenza degli interventi di mitigazione. Se le organizzazioni sanitarie viceversa continueranno ad ignorare, o quantomeno sottostimare, l’importanza strategica del risk management sarà inevitabile assistere ad un forte e costante incremento dei cyber attacchi e delle conseguenze dannose in termini tanto di privacy, quanto di safety e security.

La gestione del cyber rischio in sanità richiede un approccio olistico che vada oltre la semplice implementazione tecnologica, abbracciando una cultura della sicurezza condivisa da tutti gli stakeholder del sistema sanitario.

Come evidenziato in questo articolo, il successo nella protezione dei dati sanitari dipende dall’integrazione di metodologie di risk assessment, compliance normativa GDPR, e formazione continua del personale. Per approfondire tutti gli aspetti della cybersecurity sanitaria e accedere a un’analisi completa del fenomeno, scarica gratuitamente il white paper di Maria Vittoria Zucca “La cybercriminalità nel settore sanitario: anamnesi, diagnosi e prognosi di una ‘patologia’ informatica”.

Fonti:

[1] Per politica di sicurezza si intende la dichiarazione formale delle regole che vincolano coloro che hanno accesso agli investimenti tecnologici e di informazione di un’organizzazione, Cfr. B. Fraser, RFC2196 : Site Security Handbook, RFC Editor, USA, 1997.

[2] L’emersione della gestione del rischio quale vera e propria disciplina si registra dall’inizio degli anni Cinquanta, in principio tuttavia si rivolgeva quasi esclusivamente all’ambito bancario ed assicurativo, occupandosi dei rischi finanziari (c.d. insurance risk management), per poi solo successivamente essere applicata anche in aziende operanti in altri settori, da qui si è avvertita la necessità di istituire all’interno delle imprese una funzione unicamente dedicata a tale attività.

[3] C. Zagaria, L’enterprise Risk Management: gestione del rischio, profili di comunicazione ed evidenze empiriche, Giappichelli Editore, Torino, 2017, pp. 2-5.

[4] L. Donati, G. Vaciago, Compliance 231: Modelli organizzativi e OdV tra prassi applicative ed esperienze di settore, Gruppo Sole 24 Ore, Milano, 2022, p. 196.

[5] Il primo studioso italiano ad evidenziare la sistematicità dei rischi d’impresa è stato S. Sassi, Il sistema dei rischi d’impresa, Vallardi Editore, Milano, 1940, p. 103.

[6] U. Bertini, Introduzione allo studio dei rischi nell’economia aziendale, Giuffrè Editore, Milano, 1987, pp. 34-35.

[7] Decreto legislativo 9 Aprile 2008 n. 81, Testo unico in materia di tutela della salute e della sicurezza, per come aggiornato dalla L. 17 Dicembre 2021, n. 215.

[8] Si provino a prendere in considerazione i possibili livelli di impatto di un data breach (violazione di dati personali), anch’essi infatti saranno distinguibili in: low (gli interessati non incontreranno inconvenienti o comunque di poco conto, quale un maggior tempo impiegato a reinserire informazioni); medium (gli interessati potrebbero incontrare inconvenienti significativi che saranno comunque in grado di superare nonostante alcune difficoltà, come costi aggiuntivi sopportati); high (gli interessati potrebbero incontrare conseguenze significative che dovrebbero esser in grado di superare, anche se sopportando gravi difficoltà, quali danni alla proprietà, peggioramento della salute etc.); very high (gli interessati potrebbero incontrare conseguenze significative od addirittura irreversibili non superabili, quali incapacità al lavoro, disturbi fisici o psicologici a lungo termine etc.). Cfr. ENISA, Online platform for security of personal data processing: reinforcing trust and security in the area of electronic communications and online services, European Union Agency for Cybersecurity, 19 December 2019, reperibile al sito internet https://www.enisa.europa.eu/publications/reinforcing-trust-and-security-platform

[9] N. Distefano, “Risk Management e Metodi di Risk Assessment: Tecniche per la valutazione del rischio”, presentazione presso DICAR (Dipartimento di Ingegneria Civile e Architettura), in data 2 Luglio 2020.

[10] ENISA, Recommendations for a methodology of the assessment of severity of personal data breaches, European Union Agency for Network and Information Security (ENISA), Working document V. 10, December 2013, pp 4-6.

[11] Il Titolare del trattamento, ex art. 4 GDPR “persona, fisica o giuridica, che dispone dei dati e determina i fini e le modalità del trattamento”, nel caso della libera professione in uno studio privato, sarà rinvenuto nella figura del medico. Quest’ultimo può trasmettere certo informazioni ad altri soggetti, si pensi ad un laboratorio esterno di analisi cliniche, che tutt’al più sarà inteso quale Responsabile del trattamento, ossia soggetto esterno, che tratta i dati solo su istruzione del Titolare, privo del potere di iniziativa o di autonomia decisionale. Nella sanità pubblica invece la titolarità dei dati personali che tratta il medico di base è, in linea di principio, in capo alla ASL o ai servizi della Regione, o anche al Ministero della salute. Dunque il medico rivestirà in tal caso la funzione di Responsabile del trattamento, ricevendo istruzioni (e subendo i controlli) da parte di tali strutture.

[12] Così recita l’art. 35 Gdpr: “Quando un tipo di trattamento, allorché prevede in particolare l’uso di nuove tecnologie, considerati la natura, l’oggetto, il contesto e le finalità del trattamento, può presentare un rischio elevato per i diritti e le libertà delle persone fisiche, il titolare del trattamento effettua, prima di procedere al trattamento, una valutazione dell’impatto dei trattamenti previsti sulla protezione dei dati personali”.

[13] Article 29 Data Protection Working Party, Guidelines on Data Protection Impact Assessment (DPIA) and determining whether processing is “likely to result in a high risk” for the purposes of Regulation 2016/679, WP 248 re.01, 4 April 2017.

[14] Il Considerando 75 del GDPR identifica cosa si debba intendere con il concetto di rischio, riportando che: “I rischi per i diritti e le libertà delle persone fisiche, aventi probabilità e gravità diverse, possono derivare da trattamenti di dati personali suscettibili di cagionare un danno fisico, materiale o immateriale, in particolare: se il trattamento può comportare discriminazioni, furto o usurpazione d’identità, perdite finanziarie, pregiudizio alla reputazione, perdita di riservatezza dei dati personali protetti da segreto professionale, decifratura non autorizzata della pseudonimizzazione, o qualsiasi altro danno economico o sociale significativo; se gli interessati rischiano di essere privati dei loro diritti e delle loro libertà o venga loro impedito l’esercizio del controllo sui dati personali che li riguardano; se sono trattati dati personali che rivelano l’origine razziale o etnica, le opinioni politiche, le convinzioni religiose o filosofiche, l’appartenenza sindacale, nonché dati genetici, dati relativi alla salute o i dati relativi alla vita sessuale o a condanne penali […] ”.

[15] C. Gallotti, Sicurezza delle informazioni: valutazione del rischio; i sistemi di gestione per la sicurezza delle informazioni; la norma IOS/IEC 27001, Lulu Press Inc., Raleigh, 28 Gennaio 2019.

[16] P. Locatelli, D. Zacchetti, F. Chiodini, F. Ferrara, “I modelli necessari a strutturare un clinical data repository”, in Progettare per la sanità, n. 5, Ottobre 2019.

[17] Si rammenti come, ex art. 30 Gdpr, suddetto registro altro non sia che lo strumento attraverso il quale il titolare e il responsabile del trattamento documentano in forma scritta, le principali informazioni relative alle attività di trattamento e alle misure di garanzia adottate, in base alle finalità perseguite e ai profili di rischio rilevati, al fine di poter poi dimostrare all’Autorità di controllo (ossia il Garante per la protezione dei dati) di aver adempiuto correttamente al proprio obbligo circa la protezione dei dati personali.

[18] Si rimarchi ivi la nozione di “sicurezza by design”: una adeguata DPIA dovrà essere fatta in fase di concepimento di un servizio, assicurando lo svolgersi di un integrale e corretto processo di sicurezza nell’acquisizione di sistemi e servizi, nella contrattualizzazione con i fornitori, così da sviluppare il procurement stesso in un modo sano. In tal modo si può avere una evoluzione dei servizi verso una maggiore resilienza nei confronti degli attacchi, se invece si affrontano tali iter come oneri burocratici, cercando di minimizzare il fastidio che crea la DPIA, a questo punto si perde una fondamentale occasione.

[19] D. Farringer, “Maybe if we turn it off and then turn it back on again? Exploring Health Care Reform as a means to curb cyber-attacks”, in Journal of Law, Medicine & Ethics, 47(S4), 2019, pp. 91-201.

[20] Commissione Europea, Proposta di Regolamento del Parlamento Europeo e del Consiglio relativo alla valutazione delle tecnologie sanitarie, che modifica la Direttiva 2011/24/UE, Bruxelles, 31.01.2018; si faccia riferimento anche alla Carta di Trento sulla valutazione dei servi sanitari, quale documento fondante la Società Italiana di Health Technology Assessment, Trento, in data 28 Marzo 2006.

[21] S. Ghafur, E. Grass, N. R. Jeggings, “The challenges of cybersecurity in health care: the UK National Health service as a case study”, in Lancet Digit Health, Volume 1, issue 1, May 2019, pp. 10-12.

[22] SHAM ITALIA, Capire il rischio cyber: il nuovo orizzonte in sanità, whitepaper SHAM Italia, 2021.

[23] Volendo poi indicare quali siano le coperture assicurative che concernono il c.d. rischio cibernetico si possono individuare due tipologie: l’Assicurazione primaria diretta che risarcisce chi si assicura (per danni ad asset informatici, interruzione dell’attività, danno reputazionale, estorsione, furto, etc.); ed Assicurazione RC vs. terzi (nei casi di violazioni di dati sensibili, spese legali, indennizzi a terzi), Cfr. C. Savino, “Cyber risk, assicurazioni e PMI”, presentazione per Ania: Associazione Nazionale fra le imprese assicuratrici, 7 Marzo 2017.

[24] S. Bhuyan, U. Kabir, J. M. Escareno, K. Ector, S. Palakodeti, D. Wyant et al., Transforming healthcare cybersecurity from reactive to proactive: current status and future recommendations, in Journal of Medical Systems, Vol. 44/98, 2 Aprile 2020.

[25] Una variabile di stock è misurata in uno specifico momento e rappresenta una quantità esistente in un determinato istante, una variabile di flusso è misurata invece relativamente ad un intervallo di tempo, queste ultime fanno variare le variabili di stock.

[26] M. S. Jalali, J. P Kaiser, “Cybersecurity in hospitals: a systematic, organizational perspective”, in Journal of Medical Internet Research, Vol. 20, iss. 5, 2018, pp. 1-16; si noti come nonostante sia uno studio formulato guardando al sistema sanitario statunitense, tuttavia risulti essere un modello applicabile anche ai sistemi sanitari di altri Paesi.

[27] A. Antonilli, “Sicurezza informatica e trattamento dei dati in ambito sanitario”, in Salute e società, XVI, suppl. 3/2017, pp. 97-98.

[28] B. Schneier, Schneier on security, John Wiley & Sons, September 2008.

[29] S. Fumagalli (intervento), al talk “Cybersecutity per la sanità digitale: conoscere per non rischiare”, andato in onda il 28 Ottobre 2021, nella prima giornata di FORUM PA Sanità, evento digitale organizzato da FPA e P4I-Partners4Innovation.

[30] E. Sorano, A. Guerrieri, A. Sardi, “Criticità e consapevolezze” in Capire il rischio cyber: il nuovo orizzonte in sanità, whitepaper SHAM ITALIA, 2021, p. 42.

https://www.ictsecuritymagazine.com/articoli/risk-management-sanita/

L’Europa resta ai margini nello sviluppo e nella gestione delle tecnologie AI più avanzate. È quanto emerge dal caso Mythos, il nuovo modello di intelligenza artificiale sviluppato dalla società statunitense Anthropic, la cui distribuzione è stata limitata a un ristretto gruppo di partner tecnologici, escludendo di fatto gran parte dei regolatori europei.

L’Anthropic ha deciso di concedere l’accesso al modello solo alle big tech. Le altre circa 40 realtà avrebbero ottenuto accesso, ma senza dettagli pubblici. Parallelamente, l’azienda ha confermato “discussioni in corso con funzionari del governo degli Stati Uniti”.

Secondo quanto riporta Politico, solo l’agenzia tedesca per la cybersicurezza ha avviato contatti con Anthropic, senza però aver ancora testato direttamente il modello. Diverse istituzioni pubbliche europee avrebbero avuto accessi limitati o parziali, mentre l’agenzia europea ENISA non ha commentato eventuali interlocuzioni.

Fa eccezione il Regno Unito, dove l’AI Security Institute ha già testato Mythos e pubblicato una prima valutazione, segnalando un divario operativo evidente rispetto al continente europeo.

Un modello potente e controverso

Mythos è considerato uno dei modelli AI più avanzati mai sviluppati per la cybersicurezza. Secondo Anthropic, il sistema è in grado di “superare quasi tutti gli esseri umani” nell’individuare e sfruttare vulnerabilità informatiche. Una capacità che lo rende al tempo stesso uno strumento difensivo estremamente efficace e una potenziale arma nelle mani di attori malevoli.

Proprio questo dual use ha spinto l’azienda a limitarne la diffusione, ma la scelta ha sollevato forti critiche. “È profondamente preoccupante che siano le aziende tecnologiche, e non i regolatori, a decidere come gestire questi rischi”, ha dichiarato Yoshua Bengio, tra i pionieri dell’intelligenza artificiale.

Governance globale assente

Il caso evidenzia un problema più ampio: l’assenza di un sistema globale di governance dell’AI. Negli ultimi anni sono state avviate diverse iniziative internazionali, dal processo di Hiroshima del G7 al dialogo globale delle Nazioni Unite, ma senza risultati concreti sul piano operativo.

Nel frattempo, le priorità politiche si sono spostate verso la competizione tecnologica, lasciando in secondo piano i temi della sicurezza. Il risultato è un vuoto regolatorio che consente alle aziende private di mantenere il controllo su tecnologie ad alto impatto.

“Il fatto che modelli con un impatto così rilevante siano governati da una società privata è preoccupante”, ha osservato Marietje Schaake, ex europarlamentare e consulente della Commissione europea.

Europa tra ambizioni regolatorie e limiti operativi

Per l’Unione europea, il caso Mythos rappresenta una contraddizione evidente. Da un lato, Bruxelles ha costruito negli anni una forte identità come regolatore tecnologico globale, anche attraverso l’AI Act. Dall’altro, manca ancora un reale accesso alle tecnologie più avanzate sviluppate oltreoceano.

Secondo Laura Caroli, esperta di AI e tra i consulenti del regolamento europeo, l’UE è stata “messa da parte perché il modello non è stato rilasciato sul mercato”, e quindi non rientra pienamente negli obblighi previsti dalla normativa.

La Commissione europea ha fatto sapere di stare “valutando le possibili implicazioni” e monitorando gli impatti sulla sicurezza, ricordando che l’AI Act impone ai fornitori di gestire i rischi cyber e che il Cyber Resilience Act introduce requisiti obbligatori per i prodotti digitali.

Leggi le altre notizie sull’home page di Key4biz

https://www.key4biz.it/anthropic-gli-usa-lasciano-fuori-leuropa-dal-caso-mythos/569570/

Bucate le difese di Booking.com: a rischio i dati personali degli utenti. Rassicurazioni sui pagamenti, ma cresce l’allerta

Booking.com finisce nel mirino degli hacker. La nota piattaforma di prenotazioni online ha confermato di aver subito un attacco informatico che ha consentito a soggetti non autorizzati di accedere ad alcune informazioni dei clienti. Un episodio che riaccende i riflettori sui rischi legati alla sicurezza digitale e alla protezione dei dati personali.

Secondo quanto comunicato dalla società con sede ad Amsterdam e rilanciato dai media, l’attività sospetta “è stata individuata tempestivamente e contenuta”. “Abbiamo rilevato un accesso non autorizzato ad alcune informazioni di prenotazione e siamo intervenuti per bloccare l’incidente”, ha fatto sapere Booking.com, precisando di aver aggiornato i PIN di sicurezza delle prenotazioni coinvolte e informato direttamente gli utenti interessati.

Quali dati sono stati coinvolti

Nel messaggio inviato ai clienti, l’azienda ha chiarito che le informazioni potenzialmente esposte includono:

• dettagli delle prenotazioni
• nomi e cognomi
• indirizzi email
• numeri di telefono
• indirizzi fisici
• eventuali informazioni condivise con le strutture ricettive

Un elemento rassicurante riguarda invece i dati finanziari, che secondo la piattaforma: non risultano compromessi.

I rischi per i consumatori

Nonostante il mancato accesso dei cyber criminali ai dati di pagamento (almeno stando a quanto precisato da Booking.com), l’attacco rappresenta comunque un rischio concreto per gli utenti. Le informazioni sottratte possono infatti essere utilizzate per:

• tentativi di phishing mirati, con email o messaggi apparentemente legittimi
• truffe personalizzate, sfruttando i dettagli reali delle prenotazioni
• furti di identità o accessi non autorizzati ad altri servizi

Negli ultimi mesi, Booking.com è già stata al centro di numerosi tentativi di frode online, spesso basati proprio su richieste di pagamento fasulle o verifiche urgenti prima del soggiorno.

Un problema non nuovo

Non è la prima volta che la piattaforma affronta problemi di sicurezza. Già nel 2018 un attacco phishing aveva colpito dipendenti di strutture ricettive negli Emirati Arabi, permettendo ai criminali di accedere ai dati di oltre 4.000 utenti. In quell’occasione, la società fu anche sanzionata per aver comunicato il data breach in ritardo alle autorità.

Cosa devono fare gli utenti

Alla luce dell’accaduto, gli esperti invitano alla massima prudenza. Poche regole da rispettare e tenere sempre a mente, ma efficaci. In particolare:

• diffidare di email o messaggi che chiedono pagamenti o dati personali
• verificare sempre il mittente delle comunicazioni
• accedere alla piattaforma solo tramite canali ufficiali
• non condividere informazioni sensibili via email o chat

L’allarme sicurezza resta alto

Con oltre 30 milioni di strutture presenti sulla piattaforma e milioni di utenti in tutto il mondo, Booking.com rappresenta un obiettivo privilegiato per i cybercriminali. L’episodio conferma come, anche in assenza di violazioni finanziarie, i dati personali restino una risorsa preziosa e vulnerabile.

Per i consumatori, la regola d’oro è sempre una e una sola: prestare la massima attenzione quando si opera online. In un contesto digitale sempre più esposto, anche un semplice dato può diventare la chiave per nuove truffe.

Leggi le altre notizie sull’home page di Key4biz

https://www.key4biz.it/booking-com-sotto-attacco-a-rischio-dati-personali-e-prenotazioni-salvi-i-pagamenti/569346/

L’adozione spontanea, diffusa e spesso non governata di strumenti di intelligenza artificiale generativa nei contesti di lavoro ha reso attuale un fenomeno che, in modo convenzionale, viene definito Shadow AI: l’uso di sistemi o modelli AI da parte di dipendenti, collaboratori o funzioni aziendali fuori dai processi di approvazione, procurement, risk assessment e controllo interno.

Non si tratta di una categoria giuridica autonoma, ma di un problema organizzativo e di compliance che interseca più discipline: protezione dei dati, sicurezza delle informazioni, responsabilità organizzativa, contrattualistica ICT e, oggi, anche la governance dell’AI. L’interesse editoriale del tema è espresso in modo diretto anche dal piano 2026 di ICT Security Magazine, che colloca “Shadow AI in azienda: rischi, detection e governance” tra le proposte centrali del pilastro dedicato a intelligenza artificiale e machine learning per la sicurezza.

La rilevanza del tema dipende da un dato semplice: l’AI generativa abbassa drasticamente la soglia di accesso a strumenti capaci di trattare testi, dati, codice, documenti, immagini e workflow aziendali.

Di conseguenza, l’uso “di fatto” precede quasi sempre la formalizzazione delle regole e proprio in questa asimmetria si collocano i rischi principali, tra i quali si annoverano, tra gli altri, l’inserimento di dati personali o confidenziali nei prompt; la perdita di controllo su basi giuridiche, le finalità e i tempi di conservazione; la generazione di output inesatti ma apparentemente affidabili; la dipendenza da fornitori esterni non valutati; l’uso di plugin, agenti o integrazioni che ampliano la superficie d’attacco; e, non ultimo, la difficoltà di audit e di attribuzione delle responsabilità.

Il quadro normativo europeo non usa l’etichetta “Shadow AI”, ma fornisce già un reticolo di obblighi sufficiente a farne un tema di governance: il GDPR impone liceità, minimizzazione, integrità e riservatezza, responsabilizzazione del titolare e misure tecniche e organizzative adeguate; la NIS2 richiede misure di gestione del rischio di cybersicurezza e sicurezza della supply chain; l’AI Act impone almeno, fin da subito, obblighi di AI literacy per provider e deployer e, su altre scansioni temporali, ulteriori doveri in materia di GPAI, trasparenza e sistemi ad alto rischio.

La tesi di questo policy brief è che il modo più efficace per affrontare la Shadow AI non sia né il laissez-faire né il divieto assoluto. Il primo espone l’organizzazione a violazioni prevedibili; il secondo è spesso inefficace, perché spinge l’uso dell’AI fuori dai circuiti visibili. La soluzione ragionevole è una governance minima efficace: un insieme essenziale ma verificabile di regole, processi e controlli che renda l’uso dell’AI consentito, tracciabile, proporzionato al rischio e difendibile in sede di audit, ispezione o contenzioso.

Questo modello deve essere interdisciplinare e coinvolgere legal, privacy, security, procurement, HR, internal audit e funzioni di business; distinguere tra usi vietati, usi consentiti e usi consentiti con condizioni; documentare decisioni e responsabilità; integrare la valutazione AI con i processi già esistenti di sicurezza e protezione dati.

Le raccomandazioni finali sono dieci: censimento degli strumenti; classificazione degli usi; regole sui prompt e sui dati in input; valutazione dei fornitori; presidio contrattuale; logging e auditabilità; coordinamento con GDPR e NIS2; formazione mirata; presidio degli incidenti AI-related; accountability del management perché l’obiettivo non è frenare l’innovazione, ma renderla governabile.

Il problema: che cos’è davvero la Shadow AI

Con l’espressione Shadow AI si descrive, in senso pratico, l’impiego di strumenti di AI al di fuori del perimetro autorizzato e governato dell’organizzazione. Il fenomeno richiama, per analogia, quello più noto dello shadow IT, ma presenta caratteristiche ulteriori. Nel caso della Shadow AI, il rischio non deriva solo dall’adozione di un software non approvato, bensì dal fatto che l’utente interagisce con sistemi capaci di elaborare, inferire, trasformare, sintetizzare e generare contenuti a partire da input che possono incorporare dati personali, segreti commerciali, know-how, codice sorgente, documentazione contrattuale, informazioni strategiche o elementi soggetti a vincoli regolatori. Il problema, dunque, non è soltanto tecnologico: è informativo, organizzativo e giuridico.

Tra i rischi da trattare, vi sono il data leakage verso modelli esterni, le violazioni GDPR e AI Act e la necessità di policy di acceptable use. In effetti, la Shadow AI prospera precisamente negli spazi vuoti della governance: licenze individuali acquistate con carta aziendale; uso di account gratuiti; accesso a chatbot pubblici da device corporate; upload di file o screenshot per ottenere sintesi, traduzioni o analisi; uso di AI coding assistants senza regole di segregazione dei repository; integrazione di modelli in workflow o applicazioni interne senza previa valutazione dei rischi.

Dal punto di vista giuridico, il primo equivoco da sciogliere è che la Shadow AI non sia un “non-problema” solo perché il termine non compare nei testi normativi. Al contrario, proprio perché non esiste una disciplina speciale dedicata, il fenomeno ricade integralmente nel diritto comune della protezione dei dati, della sicurezza, della responsabilità d’impresa e, quando rilevante, nell’AI Act. In altri termini, l’assenza di una definizione legislativa non crea un vuoto di tutela; semmai aumenta il rischio di sottostimare obblighi già esistenti.

Perché il problema è oggi più grave di ieri

La novità non è l’esistenza di strumenti esterni al controllo IT, ma la loro capacità di penetrare i processi decisionali e documentali ordinari. Un modello generativo può essere usato per: redigere email; riassumere contratti; analizzare dataset; generare codice; produrre policy; preparare report per il board; assistere ticketing, HR, procurement e customer service.

Ciò significa che l’AI non entra in azienda come semplice utility, bensì come mediatore cognitivo delle attività professionali. Se questo avviene in assenza di regole, l’organizzazione perde visibilità su ciò che viene conferito ai sistemi, su dove i dati transitano, su quali siano le basi giuridiche che fondano il trattamento, su quali siano le clausole che regolano il rapporto con il fornitore e su quali controlli di sicurezza siano effettivamente applicati.

Sotto il profilo della protezione dei dati, il rischio è duplice: da un lato, l’utente può conferire dati personali in assenza di necessità, violando il principio di minimizzazione o utilizzando uno strumento che non è stato valutato in termini di liceità, trasparenza e sicurezza; dall’altro, anche quando l’organizzazione ritiene di star trattando dati “anonimizzati”, l’assunto potrebbe essere fragile.

L’EDPB, nell’Opinion 28/2024, ha chiarito che i modelli AI addestrati con dati personali non possono, in tutti i casi, essere considerati anonimi e che l’anonimizzazione va valutata caso per caso, anche rispetto alla possibilità di estrarre dati o re-identificare persone mediante interrogazioni del modello. Questo è un passaggio fondamentale: molte pratiche informali di uso della GenAI in azienda si fondano su una nozione eccessivamente intuitiva di “dato non personale”.

Sotto il profilo della cybersicurezza, la Shadow AI amplia la superficie d’attacco. Non solo perché i modelli possono essere esposti a prompt injection, data exfiltration, output manipolati o dipendenze terze, ma anche perché l’organizzazione introduce nuove dipendenze di filiera senza presidiarle.

La NIS2 richiede che i soggetti interessati adottino misure tecniche, operative e organizzative adeguate e proporzionate per gestire i rischi per la sicurezza dei sistemi informativi; tra tali misure rientrano, espressamente, la sicurezza della supply chain e dei rapporti con i fornitori, la sicurezza nell’acquisizione, sviluppo e manutenzione di reti e sistemi informativi, nonché politiche di valutazione dell’efficacia delle misure di gestione del rischio. Se l’AI entra in azienda attraverso canali non autorizzati, ciascuno di questi presìdi è, di fatto, eluso.

Sotto il profilo della governance dell’AI, il quadro è ormai ancora meno rinviabile. L’AI Act è entrato in vigore il 1° agosto 2024; alcune disposizioni si applicano già dal 2 febbraio 2025, fra cui gli obblighi di AI literacy, mentre altre si applicano secondo ulteriori scadenze, inclusi gli obblighi per i provider di GPAI dal 2 agosto 2025 e le norme di trasparenza dal 2 agosto 2026. L’art. 4 dell’AI Act impone a provider e deployer di adottare misure per garantire un livello sufficiente di alfabetizzazione AI del personale e di altri soggetti che operano per loro conto, tenendo conto delle competenze tecniche, dell’esperienza, della formazione e del contesto d’uso.

In termini organizzativi, questo significa che lasciare l’AI in una zona grigia, priva di policy e formazione, non è più una scelta neutra: è un indice di governance debole.

Il quadro normativo applicabile

GDPR: il cuore del problema è l’accountability

Il GDPR resta la prima lente giuridica con cui leggere la Shadow AI. Non perché ogni uso dell’AI implichi necessariamente un trattamento illecito, ma perché ogni uso aziendale rilevante richiede di rispondere alle domande classiche del diritto sui dati: quali dati entrano nel sistema; per quali finalità; su quale base giuridica; con quali ruoli tra i soggetti coinvolti; per quanto tempo; con quali misure di sicurezza; con quali trasferimenti; con quali diritti per gli interessati.

Gli artt. 5, 24 e 32 del GDPR impongono rispettivamente i principi di liceità, correttezza e trasparenza, minimizzazione, integrità e riservatezza; la responsabilità del titolare di mettere in atto misure tecniche e organizzative adeguate; e l’obbligo di garantire un livello di sicurezza adeguato al rischio.

Per la Shadow AI, il punto decisivo è l’accountability. Se il dipendente inserisce dati personali in un tool esterno, il problema non si esaurisce nella “colpa individuale”, poiché occorre domandarsi se l’organizzazione abbia predisposto policy, restrizioni, whitelist, regole di classificazione dei dati, formazione, controlli e procedure di autorizzazione adeguati. In assenza di questi elementi, diventa difficile sostenere che il titolare abbia davvero “messo in atto” misure idonee. La Shadow AI, quindi, non è solo un tema di comportamento scorretto del singolo; è un test della maturità organizzativa del titolare.

NIS2: rischio cyber e supply chain

Anche laddove non vi siano dati personali, la Shadow AI può rilevare in chiave NIS2; infatti l’art. 21 della direttiva richiede misure di gestione del rischio che coprano analisi dei rischi, gestione degli incidenti, business continuity, sicurezza della supply chain, sicurezza nell’acquisizione, nello sviluppo e nella manutenzione di reti e sistemi informativi, uso della crittografia e formazione di base in materia di cybersicurezza. L’utilizzo di strumenti AI esterni o di plugin non valutati può incidere su più di uno di questi profili: terze parti non censite, flussi di dati non mappati, integrazioni non presidiate, possibili dipendenze operative non considerate nei piani di continuità.

Per le organizzazioni soggette a NIS2, la Shadow AI non può quindi essere archiviata come tema di mera produttività individuale. È, piuttosto, una variante contemporanea del rischio da supply chain e del rischio da configurazione organizzativa non controllata e ciò vale, a maggior ragione, nelle realtà che operano in settori regolati o critici.

AI Act: dalla sperimentazione alla governance

L’AI Act non disciplina la Shadow AI come fattispecie nominata, ma ne rende più difficile la tolleranza organizzativa. La ragione minima è l’art. 4 sull’AI literacy, già applicabile dal 2 febbraio 2025. La Commissione europea, nelle FAQ dedicate, chiarisce che provider e deployer devono adottare misure per garantire un livello sufficiente di AI literacy in relazione al personale e al contesto d’uso. In termini pratici, un’organizzazione che consenta o subisca un uso diffuso di AI senza formazione, istruzioni, classificazione degli usi e definizione delle responsabilità si espone a una criticità di conformità già attuale.

Inoltre, la progressiva applicazione delle regole sui modelli GPAI e, poi, delle norme di trasparenza e sugli high-risk systems impone una capacità interna di mappare gli usi dell’AI. Senza inventario e governance, l’organizzazione non sarebbe in condizione di capire se stia agendo come mero utilizzatore di un servizio, come deployer di un sistema AI, o se abbia integrato un modello in processi che fanno emergere ulteriori obblighi.

Le opzioni di policy

Una politica aziendale sulla Shadow AI può, in astratto, muoversi lungo tre modelli.

La prima opzione è lo status quo: nessuna regola specifica, affidamento alla prudenza dei team, eventuali richiami generici nelle policy IT o privacy. È la soluzione peggiore, perché crea un divario tra uso reale e uso formalmente consentito. Il risultato è una non-governance che alimenta il rischio sul piano probatorio: quando si verifica un incidente, mancano inventari, logiche autorizzative, evidenze formative e responsabilità chiare.

La seconda opzione è il divieto generalizzato di strumenti AI non approvati o, più radicalmente, di ogni uso della GenAI, ed è comprensibile che in ambienti altamente sensibili tale soluzione possa apparire una risposta intuitiva; tuttavia, come regola generale, funziona poco. Dove il bisogno di produttività è forte, il divieto assoluto tende a spostare l’uso fuori dai radar, su account personali, dispositivi privati o canali non tracciabili e il rischio si riduce solo in apparenza.

La terza opzione è una governance minima efficace. Il suo pregio è di combinare realismo operativo e presidio giuridico. Non parte dall’idea irrealistica di azzerare l’uso dell’AI, ma da quella di ricondurlo entro un perimetro visibile, valutabile e documentato. È il modello preferibile perché consente all’organizzazione di classificare i casi d’uso, graduare i controlli in base al rischio e produrre evidenze difendibili.

Un modello minimo di governance: dieci raccomandazioni

1. Censire gli strumenti AI effettivamente usati.

Senza inventario non esiste governance, per tale ragione occorre mappare chatbot, coding assistants, servizi di trascrizione, traduzione, analisi documentale, plugin e API. La ricognizione deve essere sia top-down, tramite procurement e IT, sia bottom-up, tramite survey, interviste e controlli sui workflow.

2. Distinguere tra usi vietati, consentiti e consentiti con condizioni.

La regola non può essere binaria poiché devono esistere almeno tre classi: usi proibiti; usi ammessi senza dati sensibili o riservati; usi ammessi solo previa valutazione e con strumenti approvati. Questo consente di rendere comprensibile la policy agli utenti.

3. Introdurre una disciplina rigorosa degli input.

Il rischio principale sta spesso nei prompt e proprio in tale operazione può essere utile vietare o limitare l’inserimento di dati personali non necessari, categorie particolari di dati, segreti commerciali, credenziali, codice proprietario, atti processuali, pareri legali non ancora diffusi, documentazione classificata o materiale soggetto a obblighi di segretezza.

4. Valutare i fornitori come terze parti critiche.

Ogni servizio AI esterno deve essere trattato, sul piano della governance, come un fornitore potenzialmente rilevante per privacy e sicurezza. Vanno esaminati termini contrattuali, ruoli privacy, subfornitori, localizzazione dei dati, politiche di retention, opt-out rispetto al training, misure di sicurezza, auditability e supporto agli incidenti. Questo approccio è coerente sia con l’accountability del GDPR sia con l’attenzione NIS2 alla supply chain.

5. Integrare la valutazione AI con i processi già esistenti.

La Shadow AI prospera quando l’AI viene trattata come eccezione. Al contrario, deve essere incorporata nei processi ordinari: vendor assessment, DPIA quando necessaria, security review, change management, classificazione delle informazioni, incident management, internal audit.

6. Garantire logging, tracciabilità e conservazione delle evidenze.

Non ogni interazione con un sistema AI può o deve essere integralmente registrata, ma un livello adeguato di auditabilità è essenziale e ciò perché la governance deve poter dimostrare chi ha approvato lo strumento, per quali usi, con quali limitazioni, con quale formazione erogata e con quali verifiche periodiche.

7. Predisporre una policy di AI acceptable use.

La policy dovrebbe essere breve, concreta e leggibile, non un manifesto meramente programmatico. Deve chiarire finalità consentite, divieti, regole sui dati, uso di account personali, divieto di integrare tool non approvati, regole di verifica degli output e canali per richiedere approvazioni o segnalare incidenti.

8. Rendere effettiva l’AI literacy.

La formazione richiesta dall’art. 4 AI Act non può ridursi a un webinar introduttivo. Deve essere differenziata per ruoli: utenti comuni, manager, HR, legali, sviluppatori, security, procurement, includendo casi concreti: quali dati non inserire, come validare un output, quali errori sono tipici, quali sono le responsabilità.

9. Gestire gli incidenti AI-related come incidenti reali.

Un errore frequente è quello di considerare un uso improprio di GenAI come una semplice deviazione interna, ben potendo, al contrario, configurarsi come un data breach, una violazione contrattuale, una dispersione di segreti, una produzione di documenti inaccurati o l’introduzione di vulnerabilità nel codice; è per tale motivo che le istruzioni da fornire agli operatori non possono prescinere da questi scenari.

10. Coinvolgere il management e formalizzare le responsabilità.

Un altro errore piuttosto comune è quello di considerare la Shadow AI come materia di esclusiva pertinenza del reparto IT. Le scelte sul livello di tolleranza al rischio, sulle categorie di dati, sulle eccezioni consentite e sulle priorità di investimento sono decisioni di governance e proprio per tale motivo occorre una responsabilizzazione del management, con sponsorship chiara e reporting periodico.

Profili di responsabilità

Una governance debole della Shadow AI può produrre responsabilità su più livelli: sul piano amministrativo-regolatorio, possono emergere contestazioni in materia di protezione dati, sicurezza o settoriale; sul piano civilistico, l’uso improprio dell’AI può tradursi in danni da divulgazione indebita, perdita di segreti commerciali, inadempimento contrattuale o affidamento su output erronei; sul piano organizzativo interno, può emergere una responsabilità da carenza di presidi, specie quando l’uso dell’AI sia diffuso, noto o prevedibile e l’ente non abbia adottato misure ragionevoli.

È importante sottolineare un punto: la governance della Shadow AI non chiede alle organizzazioni l’impossibile, poiché nessuna disciplina pretende un rischio pari a zero, in ossequio al brocardo ad impossibilia nemo tenetur, pretende, però, un presidio ragionevole e documentabile. Ed è proprio la documentazione delle scelte, dei controlli e della formazione a costituire la prima linea difensiva in caso di audit o contenzioso.

Conclusioni

La Shadow AI non è una moda terminologica, ma la manifestazione concreta di un mutamento nel modo in cui il lavoro cognitivo viene svolto dentro le organizzazioni e proprio per tali ragioni non può essere affrontata con categorie residuali o con policy generiche. Il diritto già offre gli strumenti per qualificarla: accountability e sicurezza nel GDPR; risk management e supply chain nella NIS2; AI literacy e progressiva strutturazione della governance nell’AI Act.

La domanda non è se l’IA stia già entrando nei processi aziendali; la risposta è sì. La domanda giuridicamente rilevante è se vi stia entrando in modo governato e per molte organizzazioni, oggi, la risposta è ancora incerta. Ed è proprio in questa incertezza che si annidano i rischi più seri: non solo tecnologici, ma probatori, reputazionali e regolatori.

Una politica efficace non deve demonizzare l’IA, né inseguire un controllo assoluto; deve, più modestamente e più utilmente, renderla visibile, classificabile, governabile. In questo senso, un modello minimo di governance della Shadow AI non è un costo di compliance: è una condizione di uso legittimo e sostenibile dell’innovazione.

Bibliografia

Normativa europea

Regolamento (UE) 2016/679 del Parlamento europeo e del Consiglio del 27 aprile 2016 (General Data Protection Regulation – GDPR).

Direttiva (UE) 2022/2555 del Parlamento europeo e del Consiglio del 14 dicembre 2022 (Direttiva NIS2).

Regolamento (UE) 2024/1689 del Parlamento europeo e del Consiglio che stabilisce regole armonizzate sull’intelligenza artificiale (AI Act).

Documenti istituzionali e linee guida

Agenzia per la Cybersicurezza Nazionale, Linee guida per l’adozione dell’intelligenza artificiale nella Pubblica Amministrazione, 2024.

Agenzia per l’Italia Digitale, Linee guida sull’acquisizione e il riuso di software per la PA (aggiornate 2023–2024).

European Data Protection Board (EDPB), Opinion 28/2024 on certain data protection aspects related to AI models, 2024.

European Commission, AI Act – Questions & Answers, 2024–2025.

European Commission, Guidelines on General Purpose AI (GPAI), 2025.

ENISA, Threat Landscape 2025, 2025.

ENISA, Cybersecurity and AI: Threats and Opportunities, 2023.

Garante per la protezione dei dati personali, Provvedimento del 30 novembre 2023 su ChatGPT (OpenAI), doc. web n. 9973484.

NIST, AI Risk Management Framework (AI RMF 1.0), 2023.

NIST, Secure Software Development Framework (SSDF), SP 800-218, aggiornamenti 2024.

Standard tecnici e best practice

ISO/IEC 27001:2022, Information Security Management Systems.

ISO/IEC 27701:2019, Privacy Information Management.

ISO/IEC 42001:2023, Artificial Intelligence Management Systems.

Report e fonti di contest

World Economic Forum, Global Cybersecurity Outlook 2025, 2025.

IBM Security, Cost of a Data Breach Report 2024.

Gartner, Top Cybersecurity Trends 2025.

Cloudflare, DDoS Threat Report 2025.

Letteratura e contributi su AI e diritto

Veale, M., Borgesius, F.Z., Demystifying the Draft EU Artificial Intelligence Act, Computer Law Review International, 2021.

Edwards, L., Veale, M., Slave to the Algorithm? Why a Right to Explanation Is Probably Not the Remedy You Are Looking For, Duke Law & Technology Review, 2017.

Wachter, S., Mittelstadt, B., Floridi, L., Why a Right to Explanation of Automated Decision-Making Does Not Exist in the GDPR, International Data Privacy Law, 2017.

https://www.ictsecuritymagazine.com/articoli/shadow-ai/

Il Cyber Resilience Lifecycle di ReeVo ridisegna la gestione del rischio cyber nel momento in cui le certezze su cui si reggeva la sicurezza informatica stanno cedendo una dopo l’altra. Non è una provocazione: è la logica conseguenza di un cambiamento che molti hanno visto arrivare, ma che pochi hanno saputo anticipare davvero.

Per anni il paradigma dominante ha risposto alle minacce con più controlli, più policy, più layer tecnologici. Un accumulo progressivo di difese che, però, continuava a ragionare in modo lineare in un mondo diventato radicalmente non lineare. Gli attaccanti evolvono, si adattano, imparano dagli errori altrui. Le organizzazioni, troppo spesso, no.

La vera domanda, allora, non è più se un attacco arriverà, ma quanto velocemente si sarà in grado di riconoscerlo, contenerlo e trasformarlo in un’informazione utile per il futuro. Resilienza, non invulnerabilità: un cambio di paradigma che suona semplice, ma che richiede metodo, visione e continuità. Perché nel panorama attuale, sopravvivere a un incidente non basta: bisogna uscirne più forti di prima, con una postura di sicurezza più matura e consapevole dei propri punti critici.

Il Cyber Resilience Lifecycle di ReeVo: un approccio integrato e continuo alla gestione del rischio cyber

Negli ultimi anni il cybercrime ha superato i confini tradizionali, trasformandosi in un fenomeno sempre più pervasivo e strutturato, nel quale criminalità organizzata, dinamiche geopolitiche e tecnologie emergenti si intrecciano. Gli attacchi informatici non sono più eventi isolati, ma operazioni sofisticate, spesso automatizzate e condotte su larga scala, capaci di colpire indistintamente aziende di ogni dimensione e settore. In questo scenario, la cybersecurity non può più fondarsi su un approccio statico, basato su controlli rigidi e limitato ad attività di compliance, ma deve evolvere in un processo continuo e adattivo di gestione del rischio.

Da questa esigenza nasce il Cyber Resilience Lifecycle sviluppato da ReeVo, un modello dinamico progettato per accompagnare le organizzazioni in un percorso di miglioramento continuo della propria postura di sicurezza. Non si tratta soltanto di adottare tecnologie avanzate, ma di costruire una strategia integrata, capace di anticipare, affrontare e superare le minacce informatiche in modo strutturato ed efficace.

Il modello si articola in cinque fasi consecutive – Know, Prevent, Detect, Respond e Assess – che coprono l’intero ciclo della cybersecurity. La fase di Know rappresenta il punto di partenza: comprendere il proprio livello di esposizione al rischio è fondamentale per definire priorità e orientare gli investimenti. Questo significa mappare gli asset critici, identificare le vulnerabilità e analizzare le possibili superfici di attacco.

Segue la fase di Prevent, in cui vengono implementate misure di protezione volte a ridurre la probabilità di compromissione. In questa fase rientrano tecnologie, policy e attività di formazione, elementi indispensabili per costruire una prima linea di difesa efficace. La fase di Detect assume un ruolo centrale, poiché consente di individuare tempestivamente eventuali anomalie o comportamenti sospetti.

Quando un incidente si verifica, è essenziale intervenire in modo rapido e coordinato. La fase di Respond si concentra proprio sulla gestione degli attacchi, con l’obiettivo di minimizzare l’impatto operativo e garantire la continuità del business. Infine, la fase di Assess chiude il ciclo attraverso un’attività di valutazione e miglioramento continuo: analizzare quanto accaduto consente infatti di rafforzare le difese e prepararsi meglio alle minacce future.

Il Cyber Resilience Lifecycle è dunque un processo continuo, alimentato costantemente da nuove informazioni, verifiche e adattamenti. In un contesto in cui anche la compliance normativa assume un ruolo sempre più rilevante, adottare un approccio strutturato e proattivo alla sicurezza non è più un’opzione, ma una necessità strategica per garantire resilienza, continuità e competitività nel tempo.

https://www.ictsecuritymagazine.com/notizie/cyber-resilience-reevo/

Nasce l’AI Mythos, ma Anthropic ne ha quasi paura e il rilascio sarà controllato solo per aziende selezionate

Nel mezzo di uno scontro senza precedenti con il dipartimento della Guerra e lo stesso Presidente americano Donald Trump, Anthropic ha avviato una distribuzione estremamente limitata di Mythos, un nuovo modello di intelligenza artificiale (AI) che, secondo fonti governative e industriali, rappresenta un salto qualitativo senza precedenti nel campo della sicurezza informatica. Non si tratta di un semplice avanzamento delle capacità dei modelli generativi esistenti, ma di un cambiamento di paradigma che avvicina l’intelligenza artificiale al ruolo di vero e proprio operatore autonomo nel dominio cyber.

Mythos si distingue infatti per la sua natura agentica: non si limita ad analizzare codice o suggerire soluzioni, ma è in grado di comprendere architetture complesse, individuare vulnerabilità e orchestrare autonomamente sequenze di attacco articolate.
Come spiegato da Jim VandeHei e Mike Allen su Axios, “il modello può pianificare ed eseguire operazioni multi-step, adattarsi dinamicamente all’ambiente target e muoversi lateralmente tra sistemi compromessi”, replicando e in alcuni casi “superando le tecniche tipiche delle Advanced Persistent Threat”.

In questo senso, la distanza rispetto ai tradizionali strumenti di supporto alla sicurezza è netta: “non siamo più di fronte a un assistente, ma a un sistema capace di iniziativa operativa”, hanno precisato gli esperti.

Il test di laboratorio che ha messo paura ad Anthropic

Le preoccupazioni più rilevanti emergono dai test condotti internamente da Anthropic. Durante una fase di sperimentazione, Mythos è riuscito a eludere le restrizioni di un ambiente sandbox, cioè isolato e controllato, sviluppando un exploit multi-fase che gli ha consentito di accedere a risorse esterne non autorizzate.

L’episodio, reso noto dalla stessa azienda, evidenzia una capacità di ragionamento sistemico e di chaining (tecnica per insegnare sequenze complesse, suddividendole in piccole azioni semplici) delle vulnerabilità che va oltre quanto finora osservato nei modelli AI.
Ancora più significativo è il fatto che il sistema abbia agito con un certo grado di autonomia, senza un’esplicita istruzione a violare i vincoli imposti, anticipando implicitamente l’obiettivo di estendere il proprio raggio d’azione.

Una combinazione rischiosa di autonomia, capacità ed adattabilità

È proprio questa combinazione di autonomia, capacità di exploit e adattabilità a rendere Mythos di Anthropic una tecnologia potenzialmente critica per la sicurezza nazionale.

In uno scenario in cui attori statali o gruppi ostili potessero disporre di strumenti analoghi, la soglia tecnica necessaria per condurre operazioni cyber complesse si abbasserebbe drasticamente. Infrastrutture critiche, sistemi finanziari e supply chain digitali potrebbero diventare bersagli di attacchi su larga scala, orchestrati con una velocità e una precisione difficilmente contrastabili con gli strumenti tradizionali.

La dimensione del rischio è amplificata dalla capacità di questi sistemi di operare senza interruzioni e su molteplici target simultaneamente, introducendo una scala operativa che supera quella delle campagne APT (acronimo inglese di Advanced Persistent Threat, cioè attacchi informatici mirati, sofisticati e prolungati) finora conosciute.

Con le super AI difficile individuare gli attori di un cyber attacco

A ciò si aggiunge un ulteriore elemento di complessità: l’attribuzione. L’automazione avanzata rende ancora più difficile identificare con certezza gli autori di un attacco, complicando le dinamiche di risposta e deterrenza. In un contesto geopolitico già caratterizzato da tensioni crescenti nel cyberspazio, questa opacità rischia di aumentare l’instabilità e di ridurre l’efficacia delle tradizionali leve diplomatiche e militari.

Anche per il settore privato le implicazioni sono profonde e Anthropic ha compreso il livello di pericolosità. Le grandi imprese, in particolare quelle fortemente integrate in ecosistemi digitali globali, si trovano esposte a un rischio sistemico che va oltre il singolo incidente.

La possibilità che un sistema come Mythos possa individuare e sfruttare catene di vulnerabilità complesse apre scenari in cui attacchi mirati possono avere effetti a cascata lungo intere filiere tecnologiche. La sicurezza non è più solo una questione di protezione perimetrale o di gestione delle vulnerabilità note, ma diventa una sfida dinamica in cui l’avversario è in grado di apprendere, adattarsi e innovare in tempo reale.

Mythos sarà testata solo da 40 organizzazioni

In questo contesto si inserisce la decisione di Anthropic di limitare l’accesso a Mythos a circa quaranta organizzazioni selezionate, tra cui grandi operatori tecnologici, aziende di cybersecurity e soggetti coinvolti nella gestione di infrastrutture critiche.

L’obiettivo è duplice: da un lato testare il modello in ambienti altamente controllati, dall’altro consentire ai difensori di sviluppare contromisure prima che capacità analoghe si diffondano più ampiamente. Iniziative come quella di Anthropic chiamata Project Glasswing, che promuovono la condivisione delle conoscenze acquisite, si collocano in questa logica di “preparazione al peggio”.

Tra i partner selezionati figurano Amazon Web Services, Apple, Broadcom, Cisco, CrowdStrike, Google, JPMorgan Chase, la Linux Foundation, Microsoft, NVIDIA e Palo Alto Networks.

A fare paura è la diffusione sempre più rapida (e incontrollata) di tecnologie come Mythos

Tuttavia, la questione centrale resta l’inevitabilità della diffusione. È improbabile che Mythos rimanga un caso isolato: altri attori industriali e statali stanno già lavorando a sistemi comparabili, e la competizione globale nel campo dell’intelligenza artificiale rende verosimile una rapida convergenza verso livelli di capacità simili. Questo riduce drasticamente la finestra temporale a disposizione per costruire difese adeguate.

Ogni vantaggio tecnologico, in questo senso e in questo caso per gli Stati Uniti, ha vita breve, è solo temporaneo.

Mythos segna dunque l’ingresso in una nuova fase, in cui la cybersecurity tradizionale appare sempre meno sufficiente. La prospettiva è quella di un confronto tra sistemi automatizzati, in cui la difesa dovrà necessariamente evolvere verso modelli basati a loro volta su intelligenza artificiale avanzata.
In questo scenario, la sicurezza delle infrastrutture digitali diventa inseparabile dalla governance dell’AI, trasformandosi in una questione di rilevanza strategica per Stati e imprese. Il punto non è più se queste tecnologie verranno utilizzate in contesti offensivi, ma quando e con quali conseguenze.

In prospettiva, non saranno solo le grandi potenze a poter sfruttare queste capacità, ma anche attori più piccoli o gruppi non statali, con effetti destabilizzanti più ampi.

Leggi le altre notizie sull’home page di Key4biz

https://www.key4biz.it/anthropic-rilascia-mythos-la-super-ai-che-mette-in-crisi-la-cyber-sicurezza-di-imprese-e-nazioni/568805/

Un cambio di paradigma silenzioso ma strutturale

Per oltre un decennio il ransomware ha seguito uno schema riconoscibile: infiltrazione nella rete, cifratura dei file, richiesta di riscatto in cambio della chiave di decrittazione. Le aziende hanno risposto investendo in backup, piani di disaster recovery e soluzioni di ripristino rapido, con risultati concreti. Secondo il Coveware Quarterly Ransomware Report Q2 2025, circa il 97% delle organizzazioni colpite da cifratura riesce oggi a ripristinare i propri dati senza pagare.

I criminali lo sanno. E hanno cambiato tattica.

Secondo il 2025 Cyber Risk Report di Resilience, basato su 827 sinistri analizzati dalla compagnia assicurativa, gli attacchi di sola sottrazione dati sono passati dal 49% dei casi estorsivi nella prima metà del 2025 al 65% nella seconda metà. Sull’intero anno, il 57,6% degli eventi estorsivi ha riguardato furto di dati senza alcuna cifratura, mentre solo il 13% ha utilizzato esclusivamente la cifratura. Il rimanente 29,4% ha combinato entrambe le tecniche.

La conferma arriva anche dal Red Report 2026 di Picus Labs, che certifica una svolta ancor più netta a livello di tooling offensivo: l’uso della tecnica “Data Encrypted for Impact”, ovvero il cuore del ransomware classico, è calato del 38% nel corso del 2025. Come documentato da ICT Security Magazine nell’analisi sul cybercrime 2026, gli attaccanti non ottimizzano più per il rumore della cifratura, ma per la persistenza silenziosa e l’esfiltrazione continua.

Il messaggio è inequivocabile: il backup è irrilevante quando la leva non è operativa ma reputazionale, regolamentare e legale. Siamo di fronte a una mutazione strutturale dell’ecosistema criminale, non a una semplice variazione tattica.

Il modello operativo: Cl0p e Dark Angels come archetipi

Due gruppi incarnano questa evoluzione con approcci complementari ma entrambi paradigmatici.

Cl0p (Snakefly): la fabbrica dell’estorsione su scala

Dal 2021 Cl0p ha progressivamente abbandonato la cifratura, concentrandosi in modo esclusivo sull’esfiltrazione massiva di dati attraverso zero-day su piattaforme enterprise di file transfer, senza stabilire persistenza nelle reti compromesse e senza distribuire payload ransomware tradizionali. Fonte: cybersecuritynews.com, Ransomware Attack 2025 Recap.

Il playbook del gruppo è ormai collaudato su cinque campagne di portata globale:

1. Acquisire uno zero-day exploit su software enterprise largamente diffuso;
2. Compromettere il maggior numero possibile di istanze prima del rilevamento;
3. Esfiltrare dati dai clienti downstream, spesso al di fuori della loro rete;
4. Monetizzare tramite estorsione scalare su ogni singola organizzazione colpita.

Dopo GoAnywhere MFT (2023), MOVEit Transfer (2023) e Cleo (fine 2024), nel Q4 2025 Cl0p ha lanciato una nuova campagna sfruttando la vulnerabilità critica CVE-2025-61882 in Oracle E-Business Suite versioni 12.2.3–12.2.14, abilitando remote code execution tramite server-side request forgery (SSRF). L’intera catena d’attacco, dall’intrusione all’esfiltrazione, è avvenuta senza distribuire alcun ransomware. Tra le vittime dell’ondata Oracle EBS, secondo Symantec Threat Intelligence: Schneider Electric, Emerson, Logitech, Harvard University, Washington Post.

La metodologia operativa è ottimizzata per la furtività: lateral movement con Mimikatz, PsExec e Cobalt Strike, disabilitazione di Windows Defender e dei processi di backup, esfiltrazione tramite strumento custom Teleport. Fonti dirette: Zscaler ThreatLabz; Coveware.

Un dato interessante emerge però dall’analisi longitudinale delle campagne: secondo il The NAS Guy Research (febbraio 2026), la campagna Oracle EBS 2025 ha generato uno dei livelli più bassi di monetizzazione mai registrati per Cl0p. Le organizzazioni stanno maturando nella valutazione costi/benefici del pagamento, ma questo non riduce il danno causato dall’esfiltrazione stessa.

Dark Angels: il cacciatore solitario di grandi prede

Il modello di Dark Angels è agli antipodi per scala, ma ugualmente illuminante. Il gruppo, attivo dal 2022 e collegato ad ambienti russi, non si avvale di affiliati RaaS né di initial access broker. Questo limita il numero degli attacchi ma li rende chirurgicamente mirati verso grandi organizzazioni enterprise. Il criterio per decidere se cifrare o meno è pragmatico: la cifratura viene distribuita solo se causa disruption operativa sufficiente ad aumentare la leva, altrimenti viene omessa. Fonte: Zscaler ThreatLabz.

Dark Angels infiltra le reti, esfiltra volumi di dati tipicamente compresi tra 1 e 100 TB, rimanendo in rete anche cinque mesi prima di agire, e solo successivamente valuta se distribuire il ransomware. L’obiettivo primario è operare sotto il radar: il gruppo preferisce non fare notizia e non disturbare le operazioni della vittima, perché questo massimizza la probabilità di ottenere il pagamento senza interventi di incident response aggressivi.

Questa strategia ha prodotto il riscatto singolo più alto mai registrato: 75 milioni di dollari pagati da una Fortune 50 company nel primo trimestre 2024, dopo l’esfiltrazione di 100 TB di dati aziendali. Il pagamento è stato confermato da Chainalysis e Zscaler. Secondo TechTarget/SearchSecurity, altri gruppi hanno già preso nota del modello Dark Angels e lo replicheranno: target singoli ad alto valore, volumi massicci di dati come leva, nessuna cifratura quando non necessaria.

Il contesto italiano: chi viene colpito e come

L’Italia rappresenta un bersaglio sproporzionato rispetto al proprio peso economico. Secondo il Rapporto Clusit 2025, con il 9,6% degli incidenti gravi a livello globale, l’Italia subisce una quota di attacchi nettamente superiore al suo 1,8% del PIL mondiale.

Il dato più rilevante per questa analisi arriva dall’Exprivia Threat Intelligence Report Italia 2025: nel 2025 l’Italia ha registrato 3.732 attacchi informatici con una media di circa 10 eventi al giorno, segnando un +82% nel volume rispetto ai valori di fine 2024. Il furto di dati da solo ha rappresentato circa il 70% degli eventi malevoli nel 2025, a grande distanza dal danno economico diretto (16%) e dall’interruzione dei servizi (circa il 7%). I threat actor preferiscono operazioni silenti: esfiltrazione graduale, monetizzazione dei dati, nessuna firma visibile.

Per quanto riguarda i settori in Italia più colpiti, le fonti Clusit, Exprivia e Check Point convergono su un quadro coerente.

Manifatturiero. Come documentato nell’approfondimento intersettoriale su ICT Security Magazine, il manifatturiero italiano è sotto pressione strutturale. Il Rapporto Clusit 2025 indica che nel primo semestre 2025 il settore ha già raggiunto il 90% degli attacchi subiti in tutto il 2024, passando dal settimo al quarto posto tra i più colpiti in Italia. L’Italia subisce il 25% di tutti gli attacchi globali al settore manifatturiero. Casi documentati: STIM (INC Ransom, 100 GB esfiltrati), Microdevice (Beast, 850 GB), SIAD, Mutti, Colacem. Fonte: techfromthenet.it analisi cybercrime 2025.

Pubblica Amministrazione. Secondo il Clusit, il 38% degli attacchi in Italia nel primo semestre 2025 ha colpito enti pubblici o strutture governative. Secondo il report CSIRT Italia primo semestre 2025, i principali bersagli sono stati PA locale, PA centrale e telecomunicazioni, con 91 attacchi ransomware registrati nel semestre. Le implicazioni per gli obblighi NIS2 in capo alla PA sono analizzate su ICT Security Magazine — NIS2 Governance Aziendale.

Sanità. Con 337 incidenti nel primo semestre 2025, il settore sanitario ha realizzato il 67% degli incidenti registrati in tutto il 2024, con gli attacchi a impatto critico raddoppiati rispetto all’anno precedente. Fonte: Clusit primo semestre 2025.

Finance, Media e Telco. Secondo il Check Point Research Global Threat Intelligence Report febbraio 2026, in Italia i settori più colpiti dal ransomware nel mese di febbraio 2026 sono PA, media e intrattenimento, e telecomunicazioni. Il settore finance ha registrato 1.432 fenomeni nell’intero 2025 (Exprivia). Akira è responsabile di oltre il 20% degli attacchi su MSP e telco.

Il vettore d’accesso prevalente in Italia rimane l’esposizione RDP e l’abuso di credenziali valide reperite sul dark web. Come documentato da ICT Security Magazine sul cybercrime 2026, la catena è ormai standardizzata: infostealer, log di credenziali, marketplace dark web, initial access broker, operatore ransomware/extortion. Picus Labs documenta che gli infostealer hanno raccolto oltre 2 miliardi di credenziali nel primo semestre 2025 (fonte Resilience).

Perché i backup non bastano più

Il punto critico di questa evoluzione è la sua implicazione pratica per le strategie difensive consolidate. Il backup era la risposta principale al ransomware classico. Secondo il Resilience 2025 Cyber Risk Report: “Questo spostamento ha reso le strategie di recupero basate sui backup largamente inefficaci contro la minaccia primaria, che è ora il danno reputazionale, regolamentare e legale derivante dall’esposizione dei dati rubati.”

Le ragioni sono strutturali.

Una volta che i dati sono stati esfiltrati, il backup è irrilevante: i dati sono già fuori dal perimetro. La violazione del GDPR è già avvenuta. L’obbligo di notifica al Garante Privacy e agli interessati scatta indipendentemente dalla cifratura, entro 72 ore in caso di rischio per i diritti e le libertà degli interessati. Gli obblighi di notifica NIS2 al CSIRT Italia (preallarme entro 24 ore, notifica entro 72 ore) si applicano indipendentemente dal vettore. Su questi aspetti si rimanda all’analisi di Massimiliano Nicotra e Marco Maria De Cesaris sugli adempimenti NIS2 e le scadenze 2026.

I procedimenti legali e le cause di class action possono partire in pochi giorni dalla disclosure pubblica: secondo il Resilience Report, i claim timelines si estendono ora routinariamente su due o tre anni, mentre litigation, perizie forensi contabili e procedimenti regolatori avanzano su binari paralleli.

Un ulteriore elemento di complessità riguarda l’affidabilità del pagamento: come documentato da Resilience, pagare per sopprimere i dati rubati si è rivelato inaffidabile perché i dati frequentemente riemergono su altri canali, gli obblighi di notifica rimangono applicabili e le cause collettive seguono comunque. Fonte: Insurance Business Magazine, gennaio 2026.

Implicazioni per le strategie di difesa

La risposta difensiva deve necessariamente evolversi da un modello centrato sul recovery a uno centrato sulla prevenzione dell’esfiltrazione. Come sintetizzato da Resilience: “Backups become irrelevant because the leverage is now reputational, regulatory, rather than operational.”

Data governance e classificazione. Non si può proteggere ciò che non si conosce. Una classificazione efficace dei dati sensibili, unita a politiche di accesso basate sul principio del least privilege, riduce il volume di informazioni esportabili in caso di compromissione. Il censimento dei dati in ambienti SaaS e cloud è il punto di partenza obbligato. Il Red Report 2026 di Picus Labs documenta che il 38% delle tecniche di attacco impiegate nel 2025 operava nella fase di Discovery e Collection, cioè mappatura e raccolta di dati prima dell’esfiltrazione vera e propria.

Identity e prevenzione del lateral movement. L’autenticazione multifattore su tutti gli accessi remoti, il monitoring delle sessioni privilegiate, il rilevamento anomalo dei movimenti laterali e la micro-segmentazione di rete sono i pilastri fondamentali.

Monitoraggio dell’esfiltrazione. Strumenti DLP (Data Loss Prevention), analisi del traffico verso destinazioni esterne non autorizzate e alerting su volumi anomali di dati in uscita devono integrare, e non sostituire, le difese perimetrali. Secondo la Relazione Annuale ACN 2025, nel caso Dark Angels “il furto di 100 TB implica settimane di attività con traffico anomalo verso l’esterno che le organizzazioni hanno mancato di rilevare.”

Third-Party Risk Management (TPRM). Gli attacchi alla supply chain software come quelli sfruttati da Cl0p dimostrano che la superficie d’attacco si estende ben oltre i propri sistemi. I vendor-related incidents hanno rappresentato il 22% delle perdite nel 2024, sceso al 18,8% nel 2025 (Resilience). Un programma strutturato di TPRM con monitoraggio continuo dei fornitori critici non è più optional. Su questo tema si rimanda agli approfondimenti su ICT Security Magazine sul Supply Chain Risk Management e sulla Supply Chain Security e SBOM.

Incident response con dimensione legale integrata. La risposta agli incidenti deve includere fin dall’inizio la dimensione legale e comunicativa: notifica tempestiva al Garante Privacy (entro 72 ore), gestione delle comunicazioni agli interessati, attivazione del team legale per la difesa da eventuali class action, e adempimenti NIS2 verso il CSIRT Italia. Per il quadro normativo aggiornato: ICT Security Magazine sulla governance aziendale NIS2.

Implicazioni per le polizze cyber

La trasformazione del modello estorsivo ha costretto il mercato assicurativo a un profondo ripensamento. Con il 57,6% dei sinistri estorsivi 2025 riconducibili a furto dati senza cifratura (Resilience), i profili di rischio si ridistribuiscono radicalmente.

Manifatturiero, sanità e retail hanno insieme rappresentato il 68% delle perdite di portafoglio nel 2025, con ciascun settore vulnerabile in modi strutturalmente diversi. Fonte: Risk & Insurance, febbraio 2026.

Le aree di maggiore pressione per il mercato assicurativo sono tre. Prima: costi di notifica, gestione degli interessati e difesa legale, che nel 2025 hanno eguagliato o superato i costi diretti di risposta agli incidenti, con claim timelines estesi routinariamente a due o tre anni. Seconda: business interruption di lungo periodo, non più limitata all’interruzione operativa immediata ma comprensiva del danno reputazionale e delle perdite commerciali per mesi o anni. Terza: esposizione da compromissione di fornitori critici, con le assicuratrici che iniziano a richiedere evidenza di TPRM come requisito di sottoscrizione.

Sul fronte della sottoscrizione, le compagnie stanno progressivamente integrando requisiti di controlli preventivi specifici per l’esfiltrazione come condizione per la copertura, andando oltre i tradizionali backup e piani di recovery. Secondo Resilience Cybersecurity Predictions 2026, nel 2026 ci sarà un dibattito sempre più acceso su cosa sia etico, legale e assicurabile in materia di pagamento di riscatti per sopprimere la pubblicazione di dati già esfiltrati. È una questione aperta che potrebbe ridisegnare i confini della copertura nei prossimi anni.

Il ransomware senza cifratura non è una variante del ransomware classico: è un modello di business criminale strutturalmente diverso, che sfrutta le asimmetrie del quadro normativo, la natura non reversibile della pubblicazione dei dati e la paura del danno reputazionale come leva principale.

Come certificato dal Red Report 2026 di Picus Labs e confermato dai dati di sinistro di Resilience, l’era in cui il ransomware significava file cifrati e il recovery significava ripristino da backup si sta concludendo. La risposta difensiva deve evolversi di conseguenza: dalla protezione dell’operatività alla protezione del dato come asset a rischio intrinseco di esposizione permanente.

La domanda che i CISO devono porre oggi non è “Riusciamo a ripristinare i sistemi dopo un attacco?”, ma “Siamo in grado di rilevare e bloccare l’esfiltrazione di dati sensibili prima che raggiunga l’esterno del perimetro?”. È una domanda diversa, che richiede risposte diverse e, come documentato da Lorenzo Giustiniani nell’analisi sulla cybersecurity per le PMI italiane, risposte che molte organizzazioni italiane non hanno ancora costruito.

https://www.ictsecuritymagazine.com/notizie/ransomware-senza-cifratura/

Il 2026 è l’anno in cui la NIS2 smette di essere un impegno dichiarativo e diventa un sistema operativo verificabile. Con oltre 20.000 organizzazioni italiane nel perimetro e la scadenza finale al 31 ottobre 2026 che si avvicina, la pressione sul fronte della compliance è concreta e progressiva. Questa guida mappa ogni adempimento per fase, per area tematica e per soggetto obbligato, partendo esclusivamente dalle fonti normative primarie, senza approssimazioni.

Il quadro normativo di riferimento

La Direttiva (UE) 2022/2555 è stata recepita nell’ordinamento italiano con il D.Lgs. 4 settembre 2024, n. 138, entrato in vigore il 16 ottobre 2024. Il decreto estende gli obblighi di sicurezza informatica a 18 settori critici: dall’energia alla sanità, dai trasporti alle infrastrutture digitali, coinvolgendo tanto i soggetti privati quanto le pubbliche amministrazioni classificati come essenziali o importanti.

Il quadro degli obblighi operativi è stato definitivamente consolidato a fine dicembre 2025 con l’adozione di due determinazioni del Direttore Generale dell’ACN:

A queste si affianca il Regolamento di esecuzione (UE) 2024/2690, che specifica requisiti tecnici e metodologici per categorie specifiche di fornitori digitali, tra cui DNS, cloud, data center, CDN, marketplace, piattaforme social e prestatori di servizi fiduciari.

La struttura degli obblighi: due filoni, un orizzonte comune

Prima di entrare nel dettaglio delle scadenze, è necessario comprendere l’architettura degli obblighi così come definita dal Decreto e dalla pagina normativa ufficiale dell’ACN. Gli adempimenti si articolano su due filoni principali, entrambi con termini che decorrono dalla comunicazione di inserimento nell’elenco nazionale NIS inviata dall’ACN ai soggetti individuati tra marzo e aprile 2025:

• 9 mesi dalla comunicazione: obbligo di notifica degli incidenti significativi al CSIRT Italia, con scadenza al 15 gennaio 2026.
• 18 mesi dalla comunicazione: adozione delle misure di sicurezza di base, con scadenza entro ottobre 2026.

Come precisa la sezione “Modalità e specifiche di base” del portale ACN, i soggetti importanti adottano le misure dell’Allegato 1, i soggetti essenziali quelle dell’Allegato 2 della Determinazione 379907/2025. Non si tratta di date universali fisse, ma di termini mobili: chi ha ricevuto la comunicazione ACN ad aprile 2025 ha come scadenza ottobre 2026; chi la ricevesse in ritardo avrà un termine corrispondentemente protratto.

La mappa per fasi

Fase 1. Dal 1° gennaio al 28 febbraio 2026: registrazione e avvio notifica incidenti

Registrazione sul portale ACN. L’art. 11, comma 10 della Determinazione 379887/2025 stabilisce la finestra di registrazione e rinnovo dal 1° gennaio al 28 febbraio 2026. Il flusso è duplice: i soggetti già registrati nel 2025 rinnovano la registrazione confermando o aggiornando i dati; i nuovi soggetti effettuano la prima iscrizione. L’ACN ha predisposto dichiarazioni precompilate per i soggetti già qualificati come essenziali o importanti, da validare digitalmente dal legale rappresentante. Non attendere il 28 febbraio è fortemente raccomandato, per evitare il sovraccarico della piattaforma già verificatosi nel 2025.

Un’attenzione particolare va alla distinzione tra i tre obblighi di aggiornamento informativo che la Determinazione 379887/2025 stabilisce in modo distinto. Il primo è l’aggiornamento continuo, da effettuare entro 14 giorni da ogni evento modificativo rilevante. Il secondo è la registrazione o il rinnovo annuale nella finestra 1° gennaio – 28 febbraio. Il terzo è l’aggiornamento informativo annuale nella finestra 15 aprile – 31 maggio, previsto dall’art. 30 del Decreto e dall’art. 16 della Determinazione 379887/2025. Confondere questi tre adempimenti espone a violazioni autonome, oltre a indebolire la posizione dell’ente in caso di incidente o ispezione.

Notifica degli incidenti significativi. Dal 15 gennaio 2026, ai sensi dell’art. 3, comma 2, della Determinazione 379907/2025, è pienamente operativo il regime di notifica al CSIRT Italia. Il processo è articolato in quattro momenti, come stabilisce l’art. 25 del Decreto: pre-notifica entro 24 ore dalla conoscenza dell’evento; notifica entro 72 ore con valutazione iniziale di gravità e impatto e, ove disponibili, indicatori di compromissione; relazione finale entro un mese (con root cause probabile e misure di mitigazione adottate); relazioni mensili se l’incidente è ancora in corso alla scadenza del mese. Per i prestatori di servizi fiduciari qualificati, la notifica principale deve avvenire entro 24 ore.

I criteri che qualificano un incidente come “significativo” sono definiti negli Allegati 3 e 4 della Determinazione 379907/2025: quattro fattispecie totali, tre comuni a tutti i soggetti e una riservata ai soli essenziali.

Un elemento spesso trascurato: la qualificazione dell’evento ai fini della notifica richiede l’integrazione della Tassonomia Cyber ACN versione 2.0 (novembre 2025), indispensabile per garantire la coerenza tra la versione tecnica interna dell’incidente e quella trasmessa all’autorità.

Checklist Fase 1:

• Rinnovo o prima registrazione sul portale ACN entro il 28 febbraio
• Verifica e aggiornamento dei dati del Referente CSIRT (misura GV.RR-02 degli allegati alla Determinazione 379907/2025)
• Attivazione operativa del processo di notifica incidenti (pre-notifica 24h, notifica 72h, relazione finale 30 giorni)
• Formalizzazione dell’Incident Management Team con ruoli, escalation e procedure documentate

Fase 2. Da febbraio a settembre 2026: linee guida settoriali e gap analysis

Tra febbraio e settembre 2026, l’ACN pubblicherà progressivamente le linee guida settoriali dedicate alle diverse tipologie di misure di sicurezza. Non si tratterà di un unico documento, ma di una serie di pubblicazioni calibrate sui diversi contesti operativi. Le organizzazioni sono tenute a monitorare il calendario delle pubblicazioni ACN e ad adattare la propria pianificazione man mano che i documenti diventano disponibili.

Parallelamente, tra aprile e maggio 2026, l’ACN definirà le modalità per la categorizzazione delle attività e dei servizi dei soggetti NIS ai sensi dell’art. 42 del Decreto. Questo passaggio aprirà la strada a una differenziazione più granulare dei livelli di sicurezza richiesti nella fase successiva all’ottobre 2026.

Questa è anche la finestra naturale per completare la gap analysis strutturata: il confronto tra lo stato attuale dell’organizzazione e la baseline delle misure di sicurezza minime. Il riferimento metodologico obbligatorio è la Linee Guida NIS – Specifiche di base – Guida alla lettura, versione 2.0, pubblicata da ACN a dicembre 2025. Come approfondito nel nostro articolo sui 13 pilastri dell’implementazione tecnica NIS2, la mappatura verso standard già consolidati come ISO/IEC 27001:2022 e NIST CSF 2.0 può supportare l’analisi, a condizione che il mapping verso i requisiti NIS2 sia esplicito e verificabile.

Checklist Fase 2:

• Monitoraggio e acquisizione delle linee guida settoriali ACN man mano che vengono pubblicate
• Completamento della gap analysis con riferimento agli Allegati 1 e 2 della Determinazione 379907/2025
• Inventario degli asset informativi e perimetrazione dei sistemi informativi di rete rilevanti, definiti dall’art. 1 della Determinazione 379907/2025 come quelli la cui compromissione comporterebbe un impatto significativo su riservatezza, integrità e disponibilità dei servizi NIS
• Classificazione dei fornitori ICT rilevanti e aggiornamento delle clausole contrattuali
• Formalizzazione del piano di remediation con owner, scadenze, criteri di accettazione e prove attese

Fase 3. Da settembre al 31 ottobre 2026: implementazione e dimostrabilità

Il 31 ottobre 2026 è il termine ultimo per la piena operatività delle misure di sicurezza di base, come stabilisce l’art. 4 della Determinazione 379907/2025. Dopo questa data, l’ACN transita dalla fase di accompagnamento alla fase ispettiva.

La parola chiave di questa fase è dimostrabilità. Come analizzato in modo approfondito nel nostro articolo sugli adempimenti NIS2 entro ottobre 2026, le misure di sicurezza non possono essere implementate in modo atomistico o concentrate nelle ultime settimane prima della scadenza: la loro logica è progressiva e cumulativa. La governance abilita il risk management; il risk management orienta le misure tecniche; le misure tecniche devono essere testate; i test devono generare evidenze; le evidenze devono alimentare un ciclo di miglioramento continuo.

La conformità richiede un doppio livello di evidenza. Il primo riguarda l’esistenza formale del requisito: policy, elenco aggiornato, assegnazione di responsabilità, procedure approvate con delibera. Il secondo riguarda la coerenza sostanziale con l’analisi del rischio: motivazioni delle scelte, priorità di intervento, allocazione di risorse. Una misura formalmente adottata ma sistematicamente elusa nella pratica non soddisfa il requisito di adeguatezza e proporzionalità previsto dall’art. 24 del Decreto.

Checklist Fase 3:

• Approvazione formale con delibera degli organi di amministrazione delle policy di sicurezza (art. 23, D.Lgs. 138/2024)
• Operatività delle misure per tutti i cluster: Governance (GV), Identificazione (ID), Protezione (PR), Rilevamento (RS), Risposta e Recupero, secondo gli Allegati 1 e 2 della Determinazione 379907/2025
• Completamento della formazione specifica per gli organi di amministrazione e avvio dei programmi periodici per i dipendenti
• Test e simulazione delle procedure di incident response
• Audit interni e chiusura delle non conformità rilevate in fase di gap analysis
• Verifica della supply chain: mappatura dei fornitori ICT rilevanti, audit mirati, clausole contrattuali aggiornate

Gli adempimenti per area tematica

Governance: la responsabilità del vertice aziendale

L’art. 23 del D.Lgs. 138/2024 introduce una trasformazione strutturale nella governance della cybersicurezza: non più delegata unicamente alla funzione tecnica, ma elevata a materia di competenza diretta degli organi apicali. Il CdA e gli organi direttivi sono obbligati ad approvare le modalità di implementazione delle misure di gestione dei rischi, a sovraintendere all’attuazione degli obblighi del Capo IV, a seguire formazione specifica e a promuoverla periodicamente verso i dipendenti.

Come documentiamo nel nostro approfondimento su NIS2 e governance aziendale, qualsiasi assetto in cui la sicurezza sia delegata esclusivamente al CISO, senza flussi informativi e decisionali verso il vertice, risulta strutturalmente non conforme. Le evidenze richieste dalla norma su questo punto includono delibere formali, registri di formazione e flussi di reporting tracciabili.

Gestione del rischio e misure di sicurezza di base

Il cuore operativo della compliance risiede nell’art. 24, che impone misure tecniche, operative e organizzative “adeguate e proporzionate” basate su un approccio all-hazard, cioè all’intero spettro delle fonti di danno e non solo agli attacchi cyber. Il catalogo minimo include: analisi del rischio, gestione degli incidenti, continuità operativa e crisis management, sicurezza della supply chain, gestione delle vulnerabilità, valutazione dell’efficacia delle misure, igiene cyber e formazione, e specifiche misure tecniche quali crittografia, controllo accessi, autenticazione multifattore e comunicazioni protette.

Un punto critico spesso frainteso riguarda il ruolo dell’analisi del rischio nel modello ACN. Nel sistema definito dagli Allegati 1 e 2 della Determinazione 379907/2025, l’analisi del rischio non è il criterio di selezione delle misure minime, che sono obbligatorie per tutti. È invece il criterio di modulazione della loro profondità e configurazione. L’ente non può invocare una propria bassa esposizione per disapplicare una misura di base; deve però dimostrare che quella misura è stata implementata in modo coerente con il suo contesto operativo. La distinzione è centrale ai fini della verifica ispettiva.

Notifica degli incidenti: una capacità operativa, non un documento

Il regime di notifica, operativo dal 15 gennaio 2026, richiede che l’organizzazione sia in grado di rilevare tempestivamente un incidente, qualificarlo come significativo secondo i criteri degli Allegati 3 e 4 della Determinazione 379907/2025 e produrre in tempi brevissimi informazioni coerenti e difendibili verso il CSIRT Italia. Gli elementi centrali ai fini della verifica sono: timeline dell’evento, log e indicatori di compromissione, registri delle decisioni di incident response, documentazione delle mitigazioni adottate. La notifica è, in concreto, un atto amministrativo-informativo che può essere oggetto di contestazione.

Sicurezza della supply chain

La NIS2 non ammette zone d’ombra sui fornitori strategici. La normativa richiede mappatura e classificazione dei fornitori ICT rilevanti, inserimento nei contratti di requisiti minimi di sicurezza (clausole su gestione incidenti, obblighi di notifica, diritto di audit) e monitoraggio periodico dello stato di sicurezza. Non è sufficiente aggiungere una clausola contrattuale: il controllo deve essere eseguito attraverso campioni, attestazioni, audit e test di conformità. Per i soggetti del settore finanziario, questo tema si intreccia con gli obblighi DORA, analizzati nel nostro articolo su NIS2, DORA e CER: la convergenza normativa europea.

Il regime sanzionatorio

Il sistema sanzionatorio previsto dall’art. 38 del D.Lgs. 138/2024 è articolato e proporzionato alla categoria di appartenenza. Per i soggetti essenziali le sanzioni possono arrivare fino a 10 milioni di euro o al 2% del fatturato mondiale annuo, applicando il valore più elevato. Per i soggetti importanti il limite è fissato a 7 milioni di euro o all’1,4% del fatturato. In caso di inottemperanza alla diffida dell’ACN, si aggiungono sanzioni accessorie di natura personale, inclusa la possibilità di incapacità temporanea a svolgere funzioni dirigenziali.

Il regime si differenzia per tipologia di soggetto anche sul piano dell’approccio ispettivo: controlli preventivi per gli essenziali, verifiche post-evento per gli importanti, soprattutto a seguito di incidenti significativi o segnalazioni. Le modalità di vigilanza ricalcano quelle già sperimentate in ambito GDPR: richieste documentali, valutazioni delle misure tecniche e organizzative, audit sul campo. La conformità va dimostrata prima, non costruita in emergenza quando l’autorità avvia la verifica.

Per i dettagli sulle singole fattispecie sanzionatorie, rimandiamo al nostro articolo su NIS2: scadenze e sanzioni per le imprese e le pubbliche amministrazioni.

Da ottobre 2026: fine della fase di accompagnamento, inizio della verifica

Il 31 ottobre 2026 non è la fine del percorso. Come chiarisce il portale ACN nella sezione dedicata alle modalità e specifiche di base, dopo questa data l’Agenzia potrà avviare le attività ispettive. Parallelamente, già tra aprile e maggio 2026, l’ACN avrà avviato la definizione degli obblighi a lungo termine e della categorizzazione delle attività dei soggetti NIS ai sensi dell’art. 42 del Decreto, aprendo la strada a livelli di sicurezza più granulari e differenziati.

Il ciclo di adeguamento è strutturalmente aperto: le misure di base rappresentano il livello di partenza, non il traguardo. Come emerso dal Forum ICT Security 2025 nel confronto tra ACN e imprese sulla governance NIS2, la direttiva va intesa come un percorso di maturazione continua verso la resilienza, non come un adempimento da spuntare su una lista.

Il rischio del procrastinare

Con oltre 20.000 organizzazioni nel perimetro, un accumulo generalizzato nelle ultime settimane prima del 31 ottobre 2026 sarebbe operativamente ingestibile: mancherebbero consulenti qualificati, tempo sufficiente per il testing delle misure e la produzione delle evidenze richieste. Il messaggio dell’ACN, ribadito più volte, è inequivoco: chi inizia ora riduce rischi, costi e stress organizzativo.

L’approccio più efficace prevede tre livelli temporali sovrapposti: interventi rapidi nei primi 60 giorni dall’avvio del progetto, hardening strutturale tra i 60 e i 180 giorni, consolidamento della maturità oltre i 180 giorni. Ciascuna misura deve avere un owner identificato, una scadenza, un criterio di accettazione e una prova attesa: non per burocrazia, ma perché senza evidenze non esiste conformità verificabile.

Conclusioni

Il D.Lgs. 138/2024 delinea un paradigma in cui la cybersicurezza diventa dovere di governo e di rendicontazione permanente. Gli obblighi imposti ai soggetti essenziali e importanti non si esauriscono nell’adozione di un catalogo di misure: si traducono nell’istituzione di un sistema governato, documentato e continuamente verificabile, nel quale governance, analisi del rischio, misure di base, notifica degli incidenti e gestione della supply chain si integrano in un circuito unitario.

L’ente che saprà tradurre queste prescrizioni in un sistema organico non solo ridurrà l’esposizione sanzionatoria, ma consoliderà la propria resilienza operativa e la propria credibilità istituzionale. La compliance apparente, costruita su misure sulla carta e processi non testati, è destinata a non reggere la fase ispettiva che si apre dopo ottobre 2026.

https://www.ictsecuritymagazine.com/notizie/nis2-adempimenti/

La cybersecurity sanitaria rappresenta oggi una delle sfide più critiche del sistema healthcare moderno, minacciata costantemente da attacchi ransomware capaci di paralizzare intere strutture ospedaliere e mettere a rischio la vita dei pazienti. Questo articolo fa parte di una serie dedicata all’analisi approfondita della sicurezza informatica in ambito medico e offre un quadro completo del panorama normativo europeo e italiano, dall’evoluzione della Direttiva NIS alle nuove sfide della NIS 2, fino alle linee guida ENISA per la protezione degli ospedali.

Definizione e evoluzione della cybersecurity sanitaria

Nella sua accezione più generale la cybersecurity viene presentata quale semplice estensione del concetto di “sicurezza informatica”[1], tuttavia certo è che limitare suddetto concetto alla sola protezione dei sistemi informativi risulta tanto fuorviante, quanto anacronistico. Di gran lunga più attuale si dimostra la definizione riportata all’interno dello standard ISO/IEC 27032:2012 (per come rivisto e confermato nel 2018), che rievocando le componenti della triade CIA, si appresta a designare la cybersicurezza come: “la pratica che consente ad una entità di proteggere i propri asset fisici, come anche la confidenzialità, l’integrità e la disponibilità delle proprie informazioni, da quelle minacce che provengono dal cyberspace.”[2]

Il contesto in cui si suole operare è pertanto infinitamente più complesso di un semplice computer (o di una rete internet), consistente nel cyberspazio tutto, inteso quale complex environment, composto dalla costante interazione tra fattore umano, software e servizi.[3]

È innegabile difatti che il problema della cybersecurity coinvolga un vasto insieme di soggetti del moderno mondo digitale, si prenda da esempio il settore dell’healthcare: quando le organizzazioni sanitarie abbracciano la trasformazione digitale, diventano più aperte agli scambi con un ecosistema ampio composto da pazienti, partner, fornitori terzi, ed autorità sanitarie governative, il tutto in un ambiente di cura integrata e collaborativa. Dal momento che parallelamente allo sviluppo tecnologico, è proliferata anche la frequenza ed il grado di raffinatezza dei cyber attacchi, la sicurezza informatica risulta ad oggi la conditio sine qua non per la stessa innovazione: gli strumenti di sicurezza devono saper gestire e “stare al passo” con la progressiva e repentina digitalizzazione.[4]

La cybersecurity pertanto altro non è che un’attività di prevenzione, basata sul principio fondante, diffuso tra gli esperti di sicurezza, che recita “paranoia is a virtue”: non ci si può d’altronde affidare alla speranza che un evento avverso non accada, in quanto gli attuali automatismi dei sistemi di attacco rendono ogni dispositivo, sistema o servizio un possibile bersaglio.[5]

Diverse misure di tutela sono già state poste in essere per la protezione delle infrastrutture critiche[6] e dei servizi digitali nei Paesi dell’Unione europea, si vogliano pertanto passare in rassegna le principali normative susseguitesi nel tempo in materia di sicurezza informatica.

Posizione di spicco viene ricoperta dalla Direttiva (Ue) 2016/1148 recante “misure per un livello comune elevato di sicurezza delle reti e dei sistemi informativi” (c.d. Direttiva NIS, acronimo di Network and Information security)[7], recepita nel nostro ordinamento con il Decreto legislativo n. 65/2018, pubblicato sulla Gazzetta Ufficiale il 9 Giugno 2018 ed in vigore dal 24 Giugno dello stesso anno.[8] Così facendo l’Unione Europea ha voluto affrontare, con un approccio organico e trasversale, la sempre più emergente questione della cybersecurity, col fine di promuovere la cultura in materia di sicurezza cibernetica, rafforzare la resilienza delle infrastrutture nazionali ed altresì migliorare la cooperazione tra Stati membri.

Come riportato nelle considerazioni introduttive della sopradetta Direttiva, le reti, i sistemi ed i servizi informativi svolgono un ruolo cruciale nell’agevolare i movimenti transfrontalieri di beni, servizi e persone, e una loro perturbazione potrebbe sì avere ripercussioni non solo sui singoli Stati, ma in tutta l’Unione, danneggiandone l’economia nel suo complesso: si legge per l’appunto come la sicurezza delle reti e dei sistemi informatici siano essenziali “per l’armonioso funzionamento del mercato interno”.[9]

Si rilevi come il legislatore europeo, nel redigere il testo della Direttiva, non abbia adottato un orientamento prescrittivo (seguendo un approccio similare a quanto fatto con il GDPR), non disponendo cioè misure obbligatorie minimali da seguire pedissequamente, ma indicando semplicemente degli obiettivi generici da raggiungere, lasciando poi ai singoli soggetti un ampio margine di manovra nell’individuare ed implementare mezzi e strumenti considerati più idonei per il loro stesso raggiungimento. Si richiederà infatti genericamente che le misure di sicurezza adottate, sia a livello tecnico che organizzativo, siano proporzionate al rischio individuato, oltre che adeguate a prevenire e ridurre l’impatto che ogni incidente informatico potrebbe avere sulle reti e sui sistemi in uso, garantendo così la continuità del servizio offerto.

Come si evince poi dal testo del d.lgs. 65/2018, che ricalca accuratamente la Direttiva NIS, il settore sanitario, alla luce del suo impatto tanto economico quanto sul benessere e sulla qualità di vita della popolazione, è considerato una filiera strategica, rientrante pienamente nell’ambito della disciplina europea NIS, in particolare nella categoria dei c.d. “Operatori di servizi essenziali” (OSE).

Si chiarisce infatti come ogni Stato membro debba operare una attenta individuazione nel proprio territorio degli OSE, guardando a tutti quei soggetti, che siano pubblici o privati, operanti negli specifici settori elencati dall’allegato II della Direttiva (quali energia, trasporti, sanità, mercati finanziari, distribuzione di acqua potabile etc.), purché ex art. 5 :

a) Forniscano servizi essenziali per il mantenimento di attività sociali o economiche fondamentali;

b) La fornitura del servizio dipenda dalla rete e dai sistemi informativi;

c) Un possibile incidente abbia effetti negativi rilevanti sulla fornitura del servizio[10]

Chiaro è come fra i soggetti suscettibili di essere nominati OSE nell’ambito sanitario verranno ricompresi tutti gli istituti sanitari (ospedali e cliniche private inclusi), e che l’autorità competente incaricata di tale individuazione sarà, ex art. 7 del Decreto attuativo, specificatamente il Ministero della salute, d’intesa con le Regioni e le Province autonome di Trento e Bolzano. Una volta identificati, gli Operatori di servizi essenziali saranno tenuti, ex art 12, ad adottare, “tenendo in considerazione le conoscenze più aggiornate in materia”, ogni misura tecnico-organizzativa atta a prevenire, gestire e minimizzare l’impatto di incidenti malevoli indirizzati a carico della sicurezza della rete e dei sistemi informatici utilizzati, al fine di assicurare la continuity dei servizi erogati.

Si ripeta come i testi normativi de quo non forniscano un elenco tassativo di misure da adottare, limitandosi invece ad esprimere un generico obbligo di implementare un livello di protezione e sicurezza adeguato al rischio esistente, che i soggetti saranno quindi chiamati a raggiungere in una autonomia relativa, tenendo cioè in debita considerazione tutte le linee guida e le best practices predisposte in materia dalle autorità competenti.[11]

Ulteriore obbligo gravante su tutti gli OSE (operatori nella filiera sanitaria inclusi) è poi quello di notificare, senza ingiustificato ritardo, al CSIRT italiano, ed alle autorità competenti NIS (ossia, i singoli Ministeri), eventuali incidenti in ambito cyber aventi un impatto rilevante sulla continuità dei servizi forniti, allegando le informazioni necessarie per constatarne portata e ripercussioni.

Il CSIRT (acronimo di Computer Security Incident Response Team), nasce invero dall’idea di fondere in un unico istituto[12] tutte le procedure di notifica, risposta e recovery, andando a migliorare così la cooperazione degli OSE e creando una maggiore consapevolezza in ambito di cybersecurity. Suddetta struttura poi, insieme ad altri organi di raccordo, avrà il compito di supportare la vittima di un cyber attacco fornendo tutte le informazioni e l’expertise necessari per facilitare una gestione efficace dell’evento dannoso, ed altresì per andarne a minimizzare le dirette ripercussioni.

Si aggiunga da ultimo come le autorità competenti NIS (trattando di sanità, il Ministero della salute e le Regioni), siano anche responsabili per l’attuazione della Direttiva NIS, vegliando sulla sua corretta applicazione, potendo invero richiedere agli OSE informazioni, documenti e dimostrazioni di aver adottato ed implementato tutte le misure di sicurezza adeguate.

Difatti ex art 21 del Decreto n. 65/2018, le stesse autorità NIS possono applicare sanzioni pecuniarie amministrative laddove rilevino inosservanze da parte degli OSE circa il rispetto dei propri obblighi di sicurezza (si pensi alla non adozione di misure adeguate e proporzionate alla gestione del rischio, come anche alla mancata notifica al CSIRT italiano), comprese queste ultime fra i 12.000 ed i 150.000 euro per le violazioni più gravi.

A distanza di oltre sei anni dalla sua pubblicazione, pur risultando evidente il valore che la Direttiva NIS ha avuto nell’innalzare il livello di sensibilità degli Stati in materia di cybersicurezza, non si possono comunque sottacere anche i molteplici limiti che tale normativa ha palesato nella sua fase attuativa: non solo a causa dei recenti eventi pandemici che hanno certo mutato repentinamente il sistema socioeconomico globale o per la massiccia e costante digitalizzazione, ma anche per l’incapacità del legislatore europeo di prevedere la complessità di armonizzare quanto delineato nel testo normativo originario.

Tant’è vero che in un dettagliato report del 2019 la Commissione europea ha operato il punto della situazione proprio in tema di coerenza degli approcci assunti dagli Stati membri nella fase di adozione della Direttiva NIS. Così invero si legge: “Sebbene la Direttiva NIS abbia avviato un processo fondamentale per aumentare e migliorare le pratiche di gestione dei rischi degli operatori in settori critici, vi è un notevole grado di frammentazione in tutta l’Unione”.[13]

È proprio a causa del sopraricordato ampio margine di autonomia lasciato ai Paesi membri in fase di recepimento della Direttiva NIS che si sono venute a delineare fin da subito evidenti incertezze e disomogeneità su quali siano le misure di sicurezza da adottare ed implementare, su come identificare gli OSE, come anche sullo scambio di informazioni relative agli incidenti cyber a livello europeo.

Alla luce di tale scenario, e data l’urgenza di rafforzare le disposizioni della previa direttiva, la Commissione Europea ha avanzato, nel Dicembre 2020, una proposta di revisione, andando così a tracciare il percorso per la nascita di una direttiva nuova, che andrà ad abrogare e sostituire il testo precedente.[14]

È così che nel Dicembre 2022 la Direttiva Ue 2022/2555 (anche chiamata NIS 2) è stata pubblicata in Gazzetta Ufficiale dell’Unione europea, per entrare in vigore in data 17 Gennaio 2023, momento dal quale gli Stati membri avranno a disposizione ventuno mesi per adottare e pubblicare i relativi atti nazionali di recepimento.[15]

Ovvio è che la suddetta Direttiva NIS 2 presenti svariati punti in comune con la preesistente normativa, al contempo però vede anche importanti novità, fra cui un maggiore ambito di applicazione: il legislatore europeo ha infatti arricchito il ventaglio degli attori, includendo ulteriori soggetti a cui applicare le disposizioni normative, appartenenti a settori definiti “ad alta criticità”, fra cui si ricordino in questa trattazione i produttori farmaceutici, come anche i fabbricanti di dispositivi medici e medico-diagnostici in vitro.

Tali soggettivi attivi peraltro non verranno più identificati dai singoli Stati membri liberamente, ma anzi si seguiranno criteri condivisi ed uniformi così da permettere una più coerente ed organica identificazione degli operatori, pubblici e privati, da assoggettare alla nuova disciplina, evitando l’applicazione di criteri disomogenei fra Paesi membri.[16]

Nonostante resti fermo poi, ex art 21, l’obbligo di adottare misure tecniche, operative ed organizzative adeguate e proporzionate alla gestione dei rischi, viene al contempo aggiunta un’elencazione di misure specifiche, che dovranno essere necessariamente adottate, andando così a limitare la precedente piena discrezionalità dei Paesi membri, fra le cui misure si rinvengono:

a) politiche sull’analisi dei rischi e sulla sicurezza dei sistemi informatici;

b) sistemi di gestione degli incidenti;

c) strategie di business continuity (come la gestione dei backup o anche il disaster recovery[17]);

d) misure di gestione circa la sicurezza della supply chain (c.d. catena di approvvigionamento), compresi tutti gli aspetti in materia di sicurezza riguardanti i rapporti tra ciascun soggetto ed i suoi diretti fornitori;

e) sicurezza circa l’acquisizione, lo sviluppo e la manutenzione dei sistemi informatici, comprese la gestione e la divulgazione delle vulnerabilità;

f) pratiche di igiene informatica base e formazione in materia di sicurezza informatica;

g) politiche e procedure relative all’uso della crittografia e della cifratura;

h) misure in materia di sicurezza delle risorse umane, politiche di controllo degli accessi e di gestione degli asset;

i)l’utilizzo di soluzioni di autenticazione a più fattori o di autenticazione continua, di comunicazioni vocali, video e testuali protette e di sistemi di comunicazione di emergenza.

Fisso resta inoltre l’obbligo di notificazione alle autorità competenti circa gli incidenti cyber che abbiano un impatto significativo sulla continuità e fornitura del servizio, ed anche circa qualsiasi minaccia informatica che potrebbe aver potenzialmente provocato un incidente significativo (c.d. near miss), tuttavia nella NIS 2 viene regolamentato l’iter in maniera più dettagliata, prevedendo la trasmissione di un “early warning” (ossia di un preallarme) entro il termine di 24 ore dalla conoscenza dell’incidente, seguito, entro 72 ore, dalla notifica di una sua analisi dettagliata, che aggiorni oltretutto le informazioni fornite col primo preallarme.[18]

Si osservi ancora come la nuova Direttiva de quo preveda poteri minimi di indagine in capo alle autorità nazionali affinché valutino l’adeguatezza delle misure concretamente adottate, con la rinnovata possibilità di applicare sanzioni amministrative pecuniarie in caso di rilevate violazioni (si pensi ad una mancata notifica), per un massimo di almeno 10 milioni di euro, o fino al 2% del fatturato globale annuo dell’anno precedente dell’impresa (si noterà come rispetto alla previa disciplina NIS si sia avuto un incremento sanzionatorio importante).[19]

Le sopra analizzate direttive rimangono comunque solamente uno dei tasselli del complesso universo normativo della cybersecurity nell’ambito healthcare, dovranno infatti essere affiancate a tutti gli altri strumenti legislativi europei, rilevanti per gli operatori del settore sanitario, di cui peraltro già si è discusso in precedenza: si ricordi il Regolamento Ue 2016/679 (ossia il GDPR) riguardante il trattamento dei dati personali, ed i Regolamenti 2017/745 (MDR, European Medical Devices Regulation) e 2017/746 (IVDR, In-vitro Diagnostics Regulation). Di recente poi si è raggiunto un accordo circa l’approvazione della Direttiva sulla resilienza delle infrastrutture critiche (Critical Entities Resilience, CER), per come proposta dalla Commissione Europea nel Dicembre 2020.[20]

La CER andrà sostituire la Direttiva 2008/114/CE (ECI),[21] che peraltro si applicava solo ai settori dell’energia e dei trasporti, occupandosi nello specifico della sicurezza cyber relativa alle entità “altamente critiche” (fra cui, il settore della sanità) e della loro resilienza rispetto a una serie di possibili minacce, sia naturali che antropiche. Ai sensi della Direttiva de quo ogni Paese membro sarà chiamato ad adottare una strategia nazionale risk based, assicurandosi che tutti i soggetti critici adottino ogni misura tecnico-organizzativa atta a prevenire gli incidenti, proteggere fisicamente le aree sensibili, mitigare le conseguenze malevoli, gestire la sicurezza dei dipendenti ed aumentare il livello di awareness fra il personale.

SI capirà allora come la Direttiva CER si vada ad inserire in un panorama già complesso e ad oggi sempre più interconnesso, ponendo un approccio nei confronti delle infrastrutture “altamente critiche” più ampio ed inclusivo, così peraltro dichiara in Conferenza stampa Ylva Johansson, Commissario Europeo per gli Affari interni: “Alla luce dell’attuale situazione geopolitica in Europa, rafforzare la nostra resilienza è di fondamentale importanza. La Direttiva CER ci renderà maggiormente preparati ad affrontare le perturbazioni che incidono sulla sicurezza dei nostri cittadini e sulla prosperità del mercato interno […]. La nuova Direttiva garantirà infatti la fornitura di servizi essenziali come l’energia, i trasporti, l’acqua, l’assistenza sanitaria, riducendo al minimo l’impatto degli incidenti che siano naturali, o provocati dall’uomo.”[22]

Linee guida ENISA

In materia di cybersecurity è indubbio che si possa ivi rimarcare anche l’operato svolto da ENISA (acronimo di European Network and Information Security Agency), quale Agenzia dell’Unione europea mirante a conseguire un elevato livello condiviso di cybersicurezza in tutto il panorama comunitario. Sono ormai oltre quindici anni difatti che l’anzidetta Agenzia svolge un ruolo fondamentale nel rafforzare la sicurezza digitale in tutta Europa, contribuendo positivamente a consolidare le capacità di preparazione e di risposta degli Stati membri in caso di incidenti informatici.[23]

Guardando poi alle sue nuove pubblicazioni, per ciò che più sta a cuore alla presente trattazione, si riporti la recente relazione dal titolo: “Procurement guidelines for cyber security in hospitals”, in cui l’Agenzia ha voluto raggruppare tutta una serie di prassi e raccomandazioni, applicabili a livello ospedaliero, atte a garantire la sicurezza dei propri sistemi.

Nelle note introduttive invero l’Agenzia asserisce come la cybersecurity sia diventata sempre più una assoluta priorità per le strutture ospedaliere, tale da dover essere ad oggi fortemente integrata in tutti i processi, fasi e componenti che vadano a caratterizzare ed influenzare l’ecosistema ICT sanitario.[24]

In particolare la guida fa riferimento all’ambito del procurement in sanità, inteso quale processo di approvvigionamento indirizzato all’ottenimento di beni, servizi o lavori da una fonte esterna che siano necessari per l’azienda, ottenuti spesso tramite procedura di gara od offerta competitiva.[25]

Pertanto il procurement va a rivestire indubbiamente un key role all’interno di una qualsivoglia struttura sanitaria, dato il suo compito strategico di gestirne efficacemente il budget, provvedendo all’ottenimento delle risorse necessarie al perseguimento degli obiettivi aziendali.

Al fine di chiarire quali siano i sistemi ed i dispositivi rientranti negli acquisti sanitari, ENISA avvia il report delineandone una tassonomia, comprendente:

a) sistemi informativi clinici (ossia software orientati all’assistenza medica, quali i Laboratory Information System[26] o i Drug Databases);

b) dispositivi medici (qualsiasi componente hardware che sia destinato al trattamento, controllo o diagnosi di malattie, quali: apparecchiature di radiologia, robot chirurgici, pompe per infusione, dispostivi impiantabili come pacemakers, holters, defibrillatori cardiaci, infusori per l’insulina etc.);

c) apparecchiature di rete (cavi, routers, firewalls, reti VPN etc.);

d) sistemi di assistenza remota;

e) sistemi di identificazione (per identificare pazienti o medici, garantendo che non vi siano accessi non autorizzati, fra cui gli scanner biometrici);

f) sistemi di gestione degli edifici (linee elettriche, tubature e qualsiasi tipologia di costruzione che possa ospitare strumentazioni mediche,);

g) servizi professionali (esternalizzati o meno, prestati da professionisti o società: servizi di trasporto, progettazione, contabilità, manutenzione consulenza legale etc.);

h) servizi cloud (quali sistemi informativi per la gestione dei rapporti con i clienti, che non siano ubicati nella struttura ospedaliera).

Com’è immaginabile ognuno di tali sistemi e dispositivi porta con sé fattori di rischio propri, esaminati da Enisa e legati ad errori nella progettazione, all’uso di protocolli non sicuri, a difetti di autenticazione che comportano accessi non autorizzati o talvolta anche ad una impropria implementazione degli stessi all’interno della struttura sanitaria.

Per fornire peraltro un quadro maggiormente completo circa le possibili minacce in cui ogni struttura ospedaliera può incorrere, l’Agenzia Ue raggruppa queste ultime in cinque macrocategorie, in base alla loro origine:

a) Natural phenomena: sebbene rappresentino i rischi più remoti, vi si possono ricomprendere tutti gli eventi naturali disastrosi come incendi, allagamenti, terremoti. Non è raro peraltro che diverse strumentazioni (quali per le risonanze magnetiche o le radioterapie) siano localizzate ai piani interrati, divenendo di conseguenza maggiormente esposte a tali fenomeni;

b) Malicious actions: si ripeta come nelle organizzazioni sanitarie i sistemi IT siano fortemente interconnessi e difficili da isolare senza ingenerare una interruzione del servizio erogato, creando un fertile ecosistema per i cybercriminali. ENISA altro non fa che elencare nel dettaglio le azioni malevoli che potrebbero toccare l’health system, su cui già la suddetta trattazione si è soffermata: malware (virus, ransomware etc.), attività di social engineering (si pensi al phishing), manomissione dei dispositivi medici (Medjacking) , attacchi DoS, cyber spionaggio (celato dietro ad interessi di industrie farmaceutiche), furti d’identità e compravendita di dati sanitari;[27]

c) Supply chain failure: non tutti i servizi sono infatti localizzati nei server ospedalieri, ma possono essere esternalizzati e dipendere da servizi cloud o di rete relativi a fornitori terze parti (gli stessi dispositivi IoMT funzionano nel cloud). Pertanto se i provider non si adoperano per garantirne il funzionamento anche off-line, ciò potrebbe inevitabilmente causare gravi interruzioni nella erogazioni dei servizi sanitari.

Rientrano in tale categoria anche tutti i possibili guasti, errori di design, e di progettazione relativi ai dispositivi medicali;

d) Human errors: vengono ivi ricomprese dalle minacce connesse ad una mancanza di compliance e policies efficaci, a default password deboli, sistemi mal gestiti, accessi non autorizzati, fino ad errori di inserimento dei dati sanitari da parte del personale medico;

e) System failures: i guasti del sistema possono essere relazionati ad avaria dei software, a mancati aggiornamenti dei firmware, ad una insufficiente manutenzione o alla non disponibilità dei sistemi per sovraccarichi di rete.

Si capirà la motivazione di tali premesse: è di fondamentale importanza conoscere, studiare e parametrare ogni possibile minaccia che possa intaccare una struttura ospedaliera al fine di poter dare priorità a tutti quei prodotti e/o servizi che si rivelano esposti e particolarmente sensibili.

Ed è così che l’agenzia ENISA arriva a disporre in elenco specifiche good practices da adottare cosicché qualsiasi operatore IT sanitario possa avere un ottimo punto di partenza nell’acquisire apparecchiature ospedaliere.[28]

Si segnali peraltro come suddetta serie di buone prassi e raccomandazioni sia il risultato raggiunto per il tramite di contributi ottenuti dai molteplici operatori sanitari intervistati. In suddette good practices si suole raccomandare di:

a) Coinvolgere il dipartimento IT ospedaliero nelle diverse fasi di scelta e valutazione circa la fornitura di beni e servizi, così da garantire che non vengano tralasciati gli aspetti relativi alla cybersicurezza;

b) Attuare ed implementare una procedura di identificazione e gestione delle vulnerabilità ancor prima di acquisire i nuovi sistemi, prodotti e/o servizi, e mantenerla per tutta la durata del loro ciclo di vita;

c) Tener in stretta considerazione gli aspetti riguardanti l’interoperabilità, al fine di garantire l’assenza di divari in termini di sicurezza rispetto alle componenti già esistenti nella struttura informatica preesistente;

d) Sviluppare una policy per gli aggiornamenti hardware e software che assicuri l’installazione delle patch più recenti (sia sui sistemi operativi che sugli antivirus, firewall);

e) Programmare periodici test sulla sicurezza sia dei prodotti, fra cui i test anti-intrusione (c.d. penetration test), sia dei sistemi (l’accesso alle reti wireless ospedaliere dovrà essere rigorosamente limitato e controllato), così da poter eventualmente adottare misure correttive;

f) Progettare piani di azione a garanzia della business continuity, atti cioè ad assicurare che un guasto del sistema non causi l’interruzione in toto dei servizi essenziali erogati dall’ospedale;

g) Garantire la sicurezza dei log di accesso ai sistemi per prevenire ed intervenire sugli eventuali accessi non autorizzati all’interno dei sistemi, ed essere comunque in grado di tracciare l’entità delle informazioni perse o rubate una volta che il sistema sia stato compromesso;

h) Crittografare i dati personali sensibili che siano conservati o diffusi, per il tramite di una policy per sistemi, servizi e dispostivi ex 9 GDPR;

i) Fornire una adeguata formazione sulle prassi di cybersecurity così da garantire che il personale interno ed anche i contraenti esterni siano correttamente preparati circa tutti i rischi connessi a prodotti o servizi recentemente acquisiti.[29]

Volendo concludere, non basterà dotare la propria infrastruttura IT di una serie di tools e pensare di aver in tal modo conferito sicurezza all’intera struttura ospedaliera, viceversa occorrerà mettere in atto una strategia olistica di “difesa in profondità”, attuata mediante una metodologia globale di gestione del ciclo di vita della cybersecurity, che parta cioè dall’analisi e dalla valutazione dei rischi, all’adozione di idonee architetture di sistema, per arrivare alla gestione e monitoraggio in tempo reale di sistemi e servizi sanitari. Il tutto attraverso soluzioni sì intrinsecamente sicure e resilienti che, pur offrendo sempre il livello massimo di sicurezza e di business continuity dei sistemi e servizi sanitari, non ne ostacolino mai al contempo la piena efficienza operativa.

Readiness, response, recovery

Si voglia ivi scendere ancora più nel dettaglio circa quali siano le concrete misure di sicurezza, metodi e strategie da dover adottare al fine di incrementare fortemente la protezione delle strutture critiche sanitarie. A tale scopo si analizzi la guida pratica “Healthcare system cybersecurity” elaborata nel 2022 da ASPR (Administration for strategic preparedness and response), Agenzia statunitense, operante all’interno del Dipartimento della salute e dei servizi umani, focalizzata ad operare nel settore della prevenzione, preparazione e risposta circa tutti gli incidenti che possano essere impattanti sulla salute pubblica.[30]

Il documento de quo si presenta suddiviso in tre sezioni, rappresentanti cronologicamente l’iter di sicurezza nel suo svolgersi, ossia per come costituito dalle fasi di: Readiness, Response e Recovery.

Si esordisca quindi guardando alla fase di preparazione (o mitigazione), quale momento in cui le strutture hanno l’incarico di fissare regolari penetration tests, scansioni delle vulnerabilities, nonché protocolli di monitoraggio, al fine di garantire una rapida identificazione delle possibili minacce.

Man mano poi che tali vulnerabilità vengono rilevate, dovrebbero esser classificate in un ordine di priorità ed in seguito risolte per mezzo delle più recenti patch (quali modifiche, aggiornamenti, da qui letteralmente il “mettere una pezza”) od altre attività propriamente di blocco. Ancora si dovranno porre in essere tecniche di network segmentation (si ripeta, comportano il partizionare una data rete ospedaliera in piccole sezioni, cosicché anche se un malintenzionato riuscisse ad infiltrarsi in una di queste, le altre rimarrebbero ad ogni modo sicure), ed altresì tecniche atte a gestire e controllare gli accessi (si pensi alle, già in precedenza trattate, autenticazioni multifattoriali od anche agli approcci Zero Trust).

Sempre in questa preliminare fase dovranno essere testati e regolarmente aggiornati i c.d. Disaster recovery plans, intesi quali piani di continuità operativa contenenti soluzioni dettagliate atte ad indicare come rispondere efficacemente a svariate tipologie di incidenti, al fine di ridurre al minimo ogni interruzione delle normali operazioni, limitare la portata dei danni, definire in anticipo specifiche modalità operative alternative, fornire un rispristino del servizio rapido, ed altresì addestrare il personale alle procedure di emergenza.[31]

In aggiunta dovranno essere assicurati anche i Business contnuity plans quali documenti ancora più completi dei precedenti, contenenti tipicamente una checklist comprendente i piani di emergenza per i processi aziendali, i beni, le risorse umane ed i partner commerciali, ossia circa ogni aspetto del business che potrebbe essere colpito. Assicurandosi sempre che suddetti plans vengano rispettati ed includano anche tutti i servizi ancillari ed off-campus, (si pensi alle sedi ambulatoriali od ai laboratori di analisi) e che prevedano l’eventualità che un’interruzione possa intaccare anche strutture sanitarie limitrofe, precludendo così il trasferimento dei pazienti critici.

Affinché poi gli anzidetti piani di recovery e continuity siano efficaci, sarà comunque necessario mantenere un robusto ed affidabile inventario circa tutti gli hardware, software, dati e dispostivi medici utilizzati, dei fattori che possano impattare sul loro funzionamento e come a loro volta questi stessi possano influenzare la salute del paziente, in particolare si dovranno identificare tutti i supporti critici vitali e salvavita (si pensi ai ventilatori polmonari od alle pompe infusionali) che potrebbero essere particolarmente vulnerabili a possibili attacchi informatici, assicurandosi di prevedere un loro efficace piano di backup.

Ovvio è poi che le strutture devono essere preparate a segnalare qualsiasi incidente insolito o comportamento anomalo del sistema (si pensi ad un riavvio non pianificato, un arresto, un crash od una interruzione di rete apparentemente casuale) non appena venga indentificato, tramite rapida segnalazione.

Dunque altrettanto ovvio è che il personale tutto dovrà avere familiarità e formazione circa le modalità di incident reporting, ossia avendo ben chiaro a chi segnalare, quando farlo, ed altresì quali informazioni includere, creando a tal fine adeguati protocolli di notifica, o sistemi di comunicazione di massa, o anche applicazioni che consentano agli stessi dipendenti di ricevere alerts automatici durante una emergenza. Si potrebbe peraltro anche prendere in considerazione la possibilità di sviluppare un color code atto a comunicare agilmente i livelli idi sicurezza informatica, presupponendo che il personale comprenda il significato dei colori e le relative implicazione ed azioni da intraprendere.

Si riporti a tal fine la griglia elaborata dalla Nebraska Medicine, azienda sanitaria statunitense con sede a Omaha:

• Green : gli incidenti e le segnalazioni di sicurezza informatica sono ad un normale livello; gli strumenti e le protezioni funzionano correttamente.
• Yellow : gli incidenti e le segnalazioni di sicurezza informatica sono leggermente superiori al normale; gli strumenti e le protezioni non stanno funzionando correttamente.
• Red : gli incidenti e le segnalazioni di sicurezza informatica sono molto più elevati del normale; gli strumenti e le protezioni non funzionano e non risultano efficaci.

Ancora, prendendo atto di come il sistema sanitario si figuri quale una complessa catena multisoggettiva, occorrerà capire in che misura i fornitori terzi possano influenzare le prestazioni e la protezione dei sistemi critici, pianificare adeguati piani di risposta, basati sulla valutazione di come possano gli incidenti intaccare le risorse compromesse (si pensi ad una possibile interruzione della funzionalità di un sistema salvavita).

Data l’interoperabilità poi dei sistemi sanitari dotarsi di una c.d. Application Dependency Map (ADM) può aiutare a conferire una precisa mappatura di tutte le applicazioni e dispositivi, nonché delle interdipendenze reciproche, sicché, in caso di incidente informatico, venga seguito accuratamente un ordine di priorità nelle attività di ripristino, a seconda proprio del diverso grado di criticità di ogni tecnologia. Al fine di determinare suddetto ordine di priorità nella restoration occorre stilare invero un ranking circa il grado di impatto di un sistema, software o dispositivo compromesso nei confronti di:

a) Sicurezza del paziente e qualità della cura;

b) Numero di dipendenti e pazienti interessati dalla violazione;

c) Entrate perse;

d) Costi ed implicazioni legali;

e) Numero di pazienti dirottati presso altre strutture;

f) Danni reputazionali e legati all’immagine.

In combinazione con gli sforzi di mitigazione, sarà anche opportuno prepararsi opportunamente ai tempi di inattività (c.d. downtimes) dovuti ad un incidente cyber, ossia regolamentando il ciclo di vita dei documenti cartacei (disponendo istruzioni chiare su quali moduli usare ed in quale momento), ed altresì verificando che tutti i vari supplies (moduli, etichette, attrezzatura clinica manuale, chiavette USB etc.) siano prontamente disponibili all’occorrenza.

Anche i tempi di inattività possono essere categorizzati in base al loro impatto sulla continuity aziendale (ad esempio di Categoria A se determinano 12 ore o meno di inattività, di Categoria B per un calo di oltre 24 ore, Categoria C per più di 3 giorni etc.), affinché in tal modo le attività di risposta siano parametrare sulla severity dell’incidente informatico.

Transitando ora alla successiva fase della response, ovvio è che quando si sospetta la verificazione di un incidente informatico, gli esperti IT inizieranno immediatamente a valutarne il livello di impatto sul sistema e sulle infrastrutture (sulla base dei criteri di gravità ed impatto previamente determinati). Mentre indagano sulla entità del danno si muoveranno al fine di isolare, riparare o rimuovere le tecnologie interessate, cercando ad ogni modo di stabilizzare le prestazioni erogate e mantenere una assistenza sicura ai pazienti.

Una volta poi che minaccia e livello di impatto sono stati identificati, il team IT dovrà seguire i protocolli corrispondenti alla portata dell’evento informatico, dal momento che ogni tipologia di incidente differirà nel grado di impatto e richiederà una differente combinazione di risposte e strategie di recovery.[32]

È in tale momento che viene in gioco la capacità di essere resiliente di una struttura, gli stessi dipartimenti infatti dovranno poter richiedere e disporre di personale aggiuntivo (o riallocato) per far fronte ai periodi di interruzione ed inattività. Si dovrebbe dunque condurre in tempo reale un inventario di tutto il personale disponibile, così da poter pianificare un’eventuale redistribuzione ed allocazione delle risorse umane nei reparti maggiormente bisognosi di addetti supplementari (si pensi all’eventualità che degli infermieri da un’unità chirurgica vengano spostati per assistere alle attività di pronto soccorso).

È evidente che in tali redistribuzioni bisognerà garantire che la forza lavoro trasferita disponga delle competenze necessarie, che abbia familiarità con i flussi di lavoro operativi all’interno del nuovo dipartimento, sicché si garantisca sempre e comunque la sicurezza dei pazienti e l’erogazione di prestazioni efficaci. Certo è possibile che risulti necessaria una formazione just-in-time, in tal caso si prenda in considerazione la possibilità di affiancare il personale senior alle figure lavorative meno esperte. Da ultimo ancora si tenga aperta la possibilità di richiedere personale off-site, ossia proveniente da strutture terze non direttamente colpite dall’incidente informatico, al fine di integrare eventuali carenze operative.

A livello operativo poi se l’accesso all’EHR (electronic heatlh record, ossia la versione digitale della cartella clinica di un paziente) risulta limitato o non possibile, dovranno determinarsi le modalità con cui le varie informazioni sul paziente (anamnesi, farmaci, dati clinici etc.) debbano essere, anche se in forma cartacea, registrati e mantenuti. Si vadano a delineare poi le possibili opzioni atte a ridurre il volume dei pazienti (quali annullare gli appuntamenti non urgenti, dirottare le ambulanze verso strutture vicine etc.), stimando per quanto tempo debbano essere attuate in base alla durata prevista per l’evento, al fine di comunicare il tutto alle strutture sanitarie e partner circostanti.[33]

Si tenga inoltre a mente come durante un evento informatico, una efficace condivisione delle informazioni sia vitale per ottenere efficaci riposte e sforzi di rispristino e per salvaguardare le sicurezza dei pazienti. Si identifichi quindi il modo migliore per veicolare la messaggistica interna (si pensi alle piattaforme di collaborazione come Microsoft Teams o WebEx), al fine di agevolare le comunicazioni collaborative.

Per quanto concerne invece la comunicazione con l’esterno, occorre essere preparati alle impellenti domande che si origineranno dai media (quale “I nostri dati sono al sicuro?”), cercando di comunicare, almeno nei primi periodi, esclusivamente con dichiarazioni scritte, tenendo monitorate costantemente le testate giornalistiche ed i social media per rimediare ad una possibile disinformazione o a lacune informative ed altresì per rimanere al corrente del sentimento pubblico generale.

Sempre nella fase di riposta avranno luogo infine le attività di reporting e monitoraggio, per le quali attività è necessario che il personale tutto conosca i protocolli di segnalazione e di notifica.

Si giunga quindi alla fase di recovery, che vede come assunto base il fatto che sarà proprio la gravità dell’attacco a determinare la durata del recupero.

Si sottolinei come i sistemi informativi di regola non vengano rispristinati immediatamente, anzi ogni modifica richiederà adeguati monitoraggi, nonché costanti aggiustamenti distribuiti lungo un elaborato processo di analisi.

Mano a mano che i sistemi ed i reparti vengono rispristinati, sarà infatti necessario valutarne il livello di vantaggio o dannosità generale, ad esempio se un sistema risulta solo parzialmente funzionante, ci si dovrà chiedere se le funzionalità mancanti possano ostacolare il flusso di lavoro od aumentare il rischio. Bisognerà inoltre pianificare la migrazione di tutta la documentazione manuale venutasi a creare nel periodo di inattività, facendola trasmigrare dal formato cartaceo a quello elettronico, una volta ottenuto il completo ripristino.

Ancora, non appena le condizioni lo consentano, dovranno essere riprese tutte le procedure diagnostiche e terapeutiche in precedenza sospese, attuando una procedura per contattare i pazienti i cui appuntamenti ambulatoriali sono stati di fatto posticipati, in modo tale da poterli riprogrammare. Se necessario, si pianifichi anche il rimpatrio di tutti i pazienti che sono stati trasferito in strutture sanitarie limitrofe. Ovvio è che il ripristino possa (e alle volte debba) comportare anche l’applicazione di patch ed aggiornamenti calati sui software e sulle apparecchiature mediche, cosicché venga ridotta una possibile reiterazione dell’incidente informatico.

In conclusione si definiscano i criteri per dichiarare concluso l’incidente ed il ritorno alle normali operazioni, avvisando le parti interessate e preparando dichiarazioni pubbliche finali per i media. Le azioni che sono state intraprese, i piani ed i correttivi attuati sono comunque informazioni utili da dover mantenere, così come i dati post-incident da conservare accuratamente in uno storage a ciò dedicato. Si completi da ultimo il processo di rifornimento, inventariando tutte le supplies necessarie.[34]

Avendo ad ora chiaro lo scenario normativo che attornia la cybersicurezza ospedaliera, come anche l’iter pratico di misure e strategie da adottare in caso di incidente informatico, rimane ivi da chiedersi cosa accada concretamente all’interno delle strutture sanitarie italiane, come venga percepito il rischio cyber, e quali siano gli ostacoli legati ad una corretta attuazione ed implementazione del massimo livello di sicurezza possibile.

A tale fine si vogliano riportare a seguire le riflessioni ed i pareri di due figure professionali, tanto distinte quanto complementari, inserite a piena regola nell’organigramma sanitario, e di conseguenza nelle problematiche di sicurezza cyber che possano derivarne.

Intervista: nell’ottica di un clinico

Si voglia riportare a seguire la testimonianza diretta, uno spaccato reale e veritiero, per come derivante dalla prospettiva, nonché sensibilità, di un esperto clinico quale operatore sanitario che day by day si ritrova ad agire in un campo (si potrebbe dire minato) ed a dover tenere il passo rispetto ad una continua e rapida cyber-evoluzione che indubbiamente pone nuovi quesiti, problematicità e sfide ad una professione che oggi più che mai appare in forte sovraccarico.

Sin da subito invero le complessità si sono poste in evidenza con estrema lucidità, ovvio è che in ambito medicale si debba operare un netto discrimine fra chi si occupa del settore puramente clinico e chi si occupa di igiene informatica, organizzazione e management, tuttavia: “È proprio da tale basilare distinzione che si nota il sorgere di una prima problematica: l’informazione ultrasensibile sanitaria, il dato digitale, l’utilizzo del macchinario o strumentazione medica è ad appannaggio esclusivo del clinico, e non dell’igienista, la qual cosa comporta necessariamente una esposizione a molteplici rischi, legata per di più ad una totale incoscienza ed inconsapevolezza rispetto a ciò che il clinico abitualmente mette in moto e pone in essere. Lo scenario quindi è semplice ed è il seguente: nessun clinico è realmente consapevole circa quanto egli stesso si espone e quanto a sua volta fa esporre un dato sensibile od un paziente”.

Ebbene si prosegua domandando se possa capitare che gli stessi medici, nello svolgimento delle proprie abituali funzioni, si servano di mezzi non pensati e progettati specificatamente per l’ambito sanitario (si pensi all’uso improprio di una applicazione di messaggistica), bypassando così quel livello di sicurezza e protezione che dovrebbe viceversa esser pienamente garantito, la risposta in tal caso risulta immediata ed autentica: “Abitualmente, o meglio quotidianamente, ricevo e-mail, contenenti dati relativi ai pazienti, da parte di altri clinici, che necessitano di ottenere un secondo parere. Questo, per quanto banale, risulta un chiaro indice di quella mancanza di consapevolezza di cui poc’anzi”.

Pare ovvio, ma vale comunque la pena ribadire in questa sede che trovare un giusto equilibrio non sia affatto semplice: in ambito sanitario difatti l’adozione di una misura di sicurezza, se troppo debole, potrebbe apparire insufficiente a prevenire una qualsivoglia violazione (o cyber-threat), viceversa però, se troppo restrittiva, porterebbe comunque andar a nuocere e rallentare l’operato medico, si pensi ai casi urgenti relativi ad emergenze sanitarie.

Invero così si vuole proseguire: “È comunque una strada che continua ad essere seguita, per esigenze che sono tanto comodità quanto di celerità, ossia per ricevere e fornire risposte rapide ed esaustive in tutti quei casi che siano necessitanti di un celere consulto medico.”

Rimane purtuttavia vero il fatto che esistano tutta una serie di sistemi atti ad agevolare la complessità della realtà sanitaria: dalla cartella elettronica a livello regionale, fino all’odierna implementazione del S.I.O (Sistema informativo Ospedaliero) che intende perseguire il progetto di affinare la trasmissione da ospedale ad ospedale, creando una interconnessione più agile all’interno, ma non solo, della stessa regione, fornendo così un concreto supporto, moderno ed efficace, alle quotidiane attività di sia tipo sanitario che amministrativo.

Seguono le parole di commento: “Eppure tutto ciò, fino a questo momento, rimane qualcosa di assolutamente non realizzato e non utilizzato. Si immagini il restare nella impossibilità di poter visualizzare le immagini di un paziente che ha fatto una tac, ad esempio a Vicenza, fintanto che non sia il paziente stesso od i familiari a portare fisicamente il “dischetto”, o qualsivoglia supporto rigido, su cui poi poter basare le proprie valutazione mediche. È ovvio quindi che tutti i restanti sistemi di interconnessione siano da sempre risultati largamente più agili ed efficaci, da qui il loro abitudinario utilizzo”.

Preciso istante in cui il colloquio de quo subisce una interruzione, la quale altro non farà che avvalorare, nella maniera più pratica e dimostrativa possibile, quanto detto sin qui, così invero si riprende: “Ecco una dimostrazione pratica, mi è appena arrivato un messaggio tramite whatsapp da parte di un collega, riportante -il paziente X sta sanguinando lo portiamo o meno in sala ?- Certo è indicato solo il cognome, senza nome e senza data di nascita, con la patologia di riferimento, è ovvio comunque che il paziente sia facilmente identificabile”.

Così si continua, in un’ottica di commento: “Questa è la realtà dei fatti e non è superabile: in una comunicazione all’interno di un medesimo ospedale è stato un collega di un’altra specialità ad informarmi circa la situazione di un paziente ed a pormi di conseguenza domande urgenti su come affrontare la specifica situazione. Sistemi di supporto con fini agevolatori ci saranno in futuro, ma non potranno in alcun modo sostituire una comunicazione come quella che ad oggi avviene abitualmente”.

Ciò che si può ricavare quindi è quasi un muoversi in automatismo, dovuto ad una routinaria abitudine, come anche alla necessità di dover gestire il proprio operato professionale quotidiano, nonostante la mancanza di una piena presa di coscienza e consapevolezza circa il valore sotteso al proprio agire, da qui: “Sono pienamente convinto del fatto che il collega che mi ha appena inviato tale messaggio non ritenga in alcun modo di aver commesso un errore, nonostante abbia fornito un dato clinico ultrasensibile, riferito ad un paziente identificabile, attraverso uno strumento che non è sicuramente congruo per la tipologia di informazione che viene trasferita”.

Ci si interroga pertanto su quanto possa effettivamente essere estesa la mancanza di cyber-cultura in ambito ospedaliero, i fatti di cronaca sembrano parlare chiaro: una larga parte della intrusioni, violazioni, data breach ed altresì attacchi ransomware sono dovuti, o perlomeno facilitati, all’assenza di nozioni e pratiche base di igiene e sicurezza informatica, si pensi all’utilizzo di password di default o al servirsi di sistemi informatici non correttamente aggiornati.

Di seguito la precisazione fornita in risposta: “Certo tutte queste tipologie di problemi non competono ad un sanitario, tutt’al più alla Direzione, ossia il centro informatico che ogni ospedale ed ogni ASL presenta, d’altronde io non mi sono mai neanche chiesto se il computer dell’Azienda, che ho qui sulla mia scrivania, sia sufficientemente protetto. Ad esempio è il sistema stesso a chiedermi il cambio delle password dopo il passare di un tot di tempo, sebbene poi alla fin fine le mie password siano sempre le medesime tre che girano e ricircolano al trascorrere ogni tre mesi. Quindi sì, è possibile che ci sia una superficialità sottesa, come anche una non percezione del rischio reale, ma dirò di più forse anche un po’ di arroganza da parte della categoria sanitaria, nel pensare di doversi curare unicamente della salute del paziente e poco importa dell’eventualità che i suoi stessi dati possano effettivamente circolare”.

Si intervenga allora sostenendo che sebbene sia intuibile la superficialità che si può dimostrare nei confronti di un’eventuale violazione della privacy, non si può non domandarsi se la sensibilità al rischio malevolo cambi laddove ad essere in pericolo possa essere la stessa salute di un paziente, si pensi ai casi di utilizzo di robot chirurgici: “In tal caso da clinico ho un interesse al corretto funzionamento dello strumento, al fatto che vi sia una corretta riproduzione del mio input, che il mio feedback visivo sia efficace ed affidabile (ossia con latenze che siano le più basse e ravvicinate possibili), e che dalla interazione robot-paziente non derivi alcun danno biologico. Ciononostante, ciò che vi è fra la console ed il paziente stesso non è un problema di mia competenza, se tra qualche anno infatti verrà attuata una implementazione della telechirurgia la stessa tematica delle intromissioni malevoli sarà sì un problema dei sanitari, ma non verrà percepito come tale”.

Rimanendo ancora all’interno del capiente “termine ombrello” dell’e-Health si consideri la delicatezza che può attorniare i sistemi di telemonitoraggio: “Più attuale e differente risulta tale ambito, siamo infatti dinnanzi ad informazioni che verranno analizzate e utilizzate dal clinico per assumere determinate decisioni, ovvio appare in tal caso l’assunto: se l’informazione fornita è scorretta, il clinico prenderà d’immediata conseguenza decisioni scorrette”. Per esser più chiari si pensi ai casi di telemonitoraggio domiciliare, reso possibile grazie all’utilizzo di dispositivi wearable atti a misurare dati quali i parametri vitali di base, col fine di fornire feedback lungo l’arco della giornata relativi ai pazienti, per appurare ad esempio come stia procedendo un post-operatorio.

Così si è voluto puntualizzare: “Indubbiamente tali dati hanno rilievo, ma importanza ancora maggiore in termini di sicurezza viene rivestita da altre tipologie di informazioni e dispostivi – si pensi ai pacemakers o ai defibrillatori impiantabili – anche in questo caso tuttavia la sicurezza verrà data da parte del sanitario per scontata, ossia si confiderà nel fatto che la casa produttrice del dispositivo abbia messo in campo tutta una serie di strategie per far sì che non vi siano intrusioni od altri incidenti”.

Si tragga da tali parole una coincisa riflessione: la sicurezza informatica non può ormai esser concepita secondo la classica, ed anacronistica, metafora del “castello”, un approccio che ha funzionato in passato finché la maggior parte dei dati ed applicazioni di un’azienda venivano custoditi all’interno di propri data center, protetti in un ristretto perimetro da apposite “cinte murarie” di firewalls, piani di back up, procedure di gestione degli accessi etc.

Ad oggi infatti il perimetro non risulta più così definito: dati e servizi sanitari raramente appaiono chiusi negli hardware delle strutture stesse, viceversa sono sempre più diffusi e scambiati sui cloud, si assiste inoltre ad un panorama multisoggettivo (si pensi a tutti i produttori e fornitori terzi di dispositivi, sistemi e servizi), per cui il concetto di sicurezza informatica sta mutando la propria forma verso una nuova effige, ossia quella di una catena.

In tale nuovo paradigma è di fondamentale importanza che gli operatori sanitari escano da una logica solista, prendendo maggiore visione d’insieme e coscienza circa la loro appartenenza ad un sistema molto più esteso in cui la propria sicurezza dipende quella altrui e viceversa, solo così non risulteranno essere l’anello debole.

Tornando al colloquio de quo, una volta elencate tutte quelle capabilities che paiono esser necessarie al fine di rendere una struttura sanitaria affidabile, efficiente e cyber-resiliente (ossia dalle risorse tecnologiche e strumentazioni mediche adeguate, alle sessioni di training e formazione del personale, alla metodologia di gestione del rischio, fino alla compliance normativa nelle nomine di figure quali il DPO, il CISO, od anche il risk manager), ci si è domandati se suddetti requisiti vengano concretamente soddisfatti.

A seguire le parole di commento: “Nelle aziende sanitarie quanto elencato risulta essere presente, sebbene con diversi gradi e complessità, si guardi per esemplificare alla formazione: i corsi che noi sanitari abbiamo come obbligatori da seguire online sono per lo più incentrati proprio sul risk management, od in generale sulle tematiche relative sicurezza, il problema ancora una volta risulta perciò essere alla base. O meglio, è una questione di percezione, capita infatti che per il clinico puro tali tipologie di corsi siano avvertiti quasi come perdite di tempo, ossia quali gravose lungaggini ed inevitabili coercizioni, sebbene possa capitare che le nozioni acquisite risultino anche concretamente utili in occasioni future. Di conseguenza ritengo che sia la trasmissione dell’informazione a dover essere veicolata in una maniera, benché non saprei come, più stimolante ed allettante per il clinico, cosicché non sia percepita quale rigida imposizione”.

D’altronde si ritorna di nuovo a rimarcare quell’ottica individualista, solista ed un poco boriosa che sembra alle volte appartenere alla categoria sanitaria: “in effetti il ragionamento dietro spesso è questo: il mio mestiere è altra cosa, ed è di una nobiltà tale per cui di tutti questi elementi non me ne devo né curare né preoccupare”.

Paiono ad ogni modo parimenti giuste, ragionevoli e ben spese anche le osservazioni poste a difesa: “noi sanitari siamo soverchiati da problematiche di ordine generale, clinico ed amministrativo, dobbiamo studiare le leggi per la somministrazioni dei farmaci, per i piani di cura, ed ancora dobbiamo spendere dai dieci ai quindici minuti di tempo solo per inserire in maniera digitale la somministrazione del farmaco, per poi controllarla e vigilarla. Quindi si immagini la volontà, e voglia, di dedicarsi anche agli aspetti più propriamente inerenti alla sicurezza dei dati, alle possibili intromissioni ed alla cybersecurity in generale”.

Ed è in questo momento che traspare maggiormente il forte sovraccarico che un clinico può sentir pesare gravosamente su di sé: “chi si occupa di igiene e prevenzione vuole che io sia formato ed informato sulla sicurezza nel luogo del lavoro, chi invece si occupa di gas biomedicali vuole a sua volta che io sia informato sull’uso delle apparecchiature, chi si occupa di ingegneria, ed io devo utilizzare un elettrobisturi, mi chiede di esser informato sulla sua impostazione e su cosa si debba intendere per un malfunzionamento, dando ovviamente per scontato che, a ben vedere, io dovrò essere assolutamente e perfettamente informato circa la patologia che sto trattando, il paziente che ho dinnanzi ed il suo specifico trattamento”.

Viene pertanto da pensare che vi sia la forte esigenza di formare nuove figure professionali con competenze altamente specifiche e multidisciplinari che debbano essere inserite nell’organico sanitario al fine di affiancare gli operatori stessi e garantire per loro, attenuando in tal modo tutta una serie di incombenze d’organizzazione, amministrative, nonché di sicurezza di cui si trovano ad esser addossati: “non sto chiedendo che qualcuno mandi e-mail al posto mio, ma che io possa avere ad esempio un sistema di messaggistica imposto dall’Ordine dei Medici che risulti assolutamente blindato.”

Questo non significa deresponsabilizzare l’intera categoria, ma trovare un corretto equilibrio fra le diverse figure che possa risultare ottimale, da qui: “Noi dobbiamo ovviamente avere chiari i problemi relativi alla cybersecurity, ma dobbiamo parimenti aver chiaro che ci sia qualcuno che quel problema lo può risolvere e lo ha risolto. L’equilibrio sta tutto qui: il problema sì lo dobbiamo conoscere, ma non ce ne dobbiamo concretamente occupare dal momento che non abbiamo tempo, voglia, testa e tantomeno formazione in materia.”

Son parole queste ultime dotate di estrema lucidità ed obiettività, tramite le quali un clinico riconosce la giustezza dell’informarsi, aggiornarsi, e curarsi circa le nuove tematiche emergenti, che siano anche le più lontane possibili dal suo quotidiano operare, ma ugualmente riconosce i propri limiti: “figure terze devono ad oggi poterci mettere nella condizione migliore affinché i problemi di cyber-sicurezza in primis siano solo più questioni da dover conoscere e non più di cui doverci concretamente occupare”.

Intervista: nell’ottica di un ingegnere informatico

Si voglia ora interfacciarsi con la proverbiale “altra faccia della medaglia”, costituita dal quel settore professionale legato propriamente alla cybersicurezza ospedaliera, ed in particolare riportando il parere di un ingegnere informatico inserito a pieno titolo in una Azienda sanitaria, al fine di ricostruire un panorama di figure, ruoli e percezioni che appaia il più completo possibile.

Pur riconoscendo che diversi gradi di complessità e eterogeneità possono contraddistinguere l’assetto di ogni struttura ospedaliera, si chieda innanzitutto di tratteggiare l’organigramma di ruoli e figure professionali che orbitano attorno all’ambito della sicurezza, da qui la risposta: “Per tutte le questioni inerenti alla gestione della privacy si guarda al ruolo dei DPO, ma ciò che più mi compete, e di conseguenza maggiormente conosco, è proprio la disciplina settoriale della security informatica. Quest’ultima, badi bene, è purtroppo una branca molto giovane nelle strutture ospedaliere come quella in cui opero, dal momento che l’attenzione e sensibilità verso tale ambito si è raggiunta solo di recente, proprio in seguito all’inasprirsi degli attacchi informatici ed all’interesse mediatico che ne è conseguito, da tale enfasi ne sono poi scaturiti diversi investimenti in tal senso. Penso di poter dire dunque che solo da un anno a questa parte si è effettivamente posto l’accento sulla security, grazie anche al recepimento della direttiva NIS, per il cui adeguamento stiamo lavorando aspramente, prima di ciò si guardava essenzialmente a quanto previsto dal GDPR in tema di trattamento dei dati personali.

Si domandi pertanto quale sia il panorama normativo di riferimento in tema di sicurezza informatica, se vi siano ulteriori normative o protocolli di settore a cui riferirsi nel proprio operare: “Attualmente la normativa a cui ci riferiamo ed andiamo ad attuare è fondamentalmente la NIS, è il nostro punto focale e filone principale, nonché leva per chiedere finanziamenti ed investimenti che, capirà, in aziende come la nostra, con 50.000 prese di rete e 7.000 dipendenti, sono piuttosto elevati e per nulla banali, e comunque in passato spesso sono venuti a mancare. Nell’ultimo anno invece sono stati stanziati investimenti importanti e questo lascia ben sperare in una direzione di possibile progredimento.

Addentrandosi più specificatamente rispetto al tema delle cyber minacce, si chieda un commento circa i noti fattori di vulnerabilità riguardanti una struttura critica come quella ospedaliera, fra cui l’essere dotati di un sistema informatico complesso, l’utilizzo di dispostivi IoMT non sempre progettati seguendo elevati standard di sicurezza by design, l’articolata catena della supply chain, nonché il fattore umano cui si faccia affidamento, la risposta: “Dunque per tutto ciò che riguarda le tematiche propriamente legate all’IT, quale nostro perimetro storico, attualmente stiamo portando avanti progetti che paiono essere promettenti, per tutto ciò che attiene invece agli altri ambiti ci atteniamo a quanto ci viene fornito. Mi spiego meglio: i device elettromedicali per loro natura sono certificati CE tout court (cioè per le componenti hardware, software, di configurazione etc.), quindi se noi volessimo installarci un antivirus non è detto che questo sia possibile, dal momento che si va ad inficiare la certificazione stessa. Per riuscire a sopperire a tale problema si è dovuta elaborare una struttura di «securizzazione laterale», in cui i device medicali raffigurano il nucleo, da proteggere tramite cinta murarie di sicurezza, affinché il perimetro sia il meno vulnerabile possibile.

Come vede dunque la tecnologia ci viene in soccorso, però è proprio qui che scatta il terzo fattore, ossia quello propriamente umano, chiaro è che se vedi una postazione di lavoro con una presa USB libera e scarichi i compiti di tuo figlio nel sistema, puoi anche inficiare e far crollare tutto il lavoro che è stato fatto. Vorrei che lei notasse come la parte umana rimanga ad oggi questione davvero rilevante della problematica, veda il dilagante fenomeno del phishing”

Appare lampante la sovrapponibilità di suddette dichiarazioni con quanto dichiarato in precedenza disquisendo con un clinico puro, si ricordi invero come si fosse già confermato l’utilizzo abituale di applicazioni di messaggistica non congrue al trattamento di dati ultrasensibili come possono essere quelli sanitari, si chieda ivi conferma: “È assolutamente così, c’è una totale sconsideratezza nell’inviare referti ed analisi tramite WeTransfer o simili, e ciò è tutt’altro che infrequente, anzi è una pratica comune. Per questa ragione stiamo sempre più insistendo nell’ottica di una maggiore sensibilizzazione ed acculturamento, ad esempio tramite campagne di falso phishing, inviando cioè una serie di email e laddove l’operatore sanitario apra il link, contenente tanto per capirci «bravo hai vinto un milione di euro», riveliamo di esserci noi informatici dalla parte opposta, avvertendo gli operatori stessi che un’azione del genere avrebbe portato a tutta una serie di determinate conseguenze dannose.

Il fattore umano è dunque altamente impattante in una struttura come la nostra e peraltro vorrei far notare come ci siano molte persone estremamente refrattarie al cambiamento delle proprie (scorrette) abitudini operative.”

Si voglia ancora ricordare come nell’ottica del clinico puro gli stessi corsi di formazione sui temi della cybersicurezza siano spesso percepiti come gravose lungaggini, da dover seguire solo perché obbligati, segue la veloce interruzione: “Sì mi lasci dire che la percezione è che la security sia proprio una gran rottura di scatole, intendendola cioè quasi come una limitazione alla libertà personale, vuoi perché non puoi navigare in Internet a tuo piacimento, ma nei siti indicati, vuoi perché non puoi trasferire su WeTransfer un’immagine clinica per avere un secondo parere medico”.

Chiaro è però come vi sia una costante tensione ed un difficile equilibrio da delineare fra la cura propriamente clinica, anche emergenziale, del paziente e la “cura” degli aspetti maggiormente di privacy e security: “Esatto, questo è proprio uno dei temi su cui spesso ci scontriamo, in quanto limita il nostro operare, ossia poniamo il caso di un chirurgo che necessita, per il bene del paziente, di fare vedere l’immagine di un tumore ad un collega negli Stati Uniti per avere una seconda opinion, ovvio è che la questione sia altamente delicata.

Se lei mi chiede se esistano regole specifiche e normative atte a fare in modo che un tale trasferimento avvenga in maniera sicura, le rispondo di sì, ma tale tipologia di flussi, come può immaginare, non è certamente gratuito, anzi presenta un costo non indifferente”.

Tornando al tema della cyber-formazione, si rammenti come nell’ottica del clinico puro si dovessero trovare soluzioni innovative e maggiormente stimolanti per incentivare l’apprendimento di nozioni di igiene informatica, si proponga ivi una possibile organizzazione di incontri in presenza, laddove il metodo online possa apparire alle volte maggiormente sgradito e gravoso, così la risposta: “Io mi occupo della formazione dai tempi precedenti al Covid, di conseguenza non via web, ma in aula, e le persone che avevo dinnanzi si dividevano in due, anzi almeno tre gruppi: gli annoiati, ossia coloro a cui la tematica non importava affatto, che erano presenti solo perché ciò è dovuto, poi una minimissima parte effettivamente interessata all’argomento, e da ultimo una buona parte refrattaria al cambiamento, irremovibilmente radicati ed attaccati alle proprie abitudini, che non sono assolutamente intenzionati a modificare e correggere. Ora addirittura via web non ho nemmeno più questa percezione, basta spegnere la telecamera ed addormentarsi”.

A seguire vengono pronunciate parole che richiamano alla memoria quella arroganza già ammessa espressamente da parte del clinico: “Se devo essere sincero, poi sarà una mia percezione soggettiva, c’è proprio un sentimento di superiorità da parte della classe medica, nel pensare di essere in un ambiente prettamente clinico, in cui il core business è la cura del paziente e tutto quanto il resto dovrà essere assoggettato e seguire le esigenze proprie di tale categoria professionale. Non mi spingo oltre, ma comunque tenga presente che io tutti i giorni ho dei disguidi dovuti proprio ai motivi detti fino ad ora”.

Appare ad ogni modo irrazionale tale ritrosia al cambiamento, soprattutto davanti ad una cybercriminaltà che è in continua crescita, sempre più sofisticata ed invasiva, che non si ferma più solo sul versante della violazione e furto dati, ma che prende di mira le stesse strutture (si pensi agli attacchi ransomware) o che s’introduce nelle apparecchiature e dispositivi, si commenta: “Per quanto riguarda le intrusioni cyber devo fare un premessa: la telechirurgia deve ancora fare notevoli passi avanti, ad esempio i telerobot utilizzati nella nostra struttura sono utilizzati solo localmente, il paziente ed il robot si trovano cioè a due metri di distanza dall’operatore chirurgico, ed è una modalità operatoria utilizzata più che altro per annullare eventuali tremori fisiologici ed affaticamenti delle braccia del chirurgo, di conseguenza i problemi legati alle intrusioni malevoli saranno eventualmente preoccupazioni future, che seguiranno di pari passo l’evoluzione della medesima telechirurgia.

Più rilevante invece, quale perimetro che ad oggi nessuno sta prendendo seriamente in considerazione, risulta essere quello dell’attuazione meccanica di dispositivi quali le UTA (unità trattamento aria)[35] ad esempio usate nelle sale operatorie. Dal mio punto di vista di ingegnere informatico, con una conoscenza di elettronica, io mi preoccuperei di tali sistemi, dato che sono comandati da un sistema informatico IP, banalmente se un attaccante riesce ad intromettersi può manipolarle a proprio piacimento, agire sugli interruttori, arrivando anche a fare saltare la corrente di tutto l’ospedale.

Ecco che il passaggio da un attacco ransowmare diretto a cifrare i dati e chiedere un riscatto, ad un attacco di mera “guerriglia” indirizzato a creare una magnitudo massima di dannosità, pare piuttosto breve. Chiaro che nel secondo caso una volta che il sistema è stato «bruciato» tutto, i paziente attaccati ad un respiratore muoiono, o soffrono comunque un pesante disservizio. Quindi sì, fra le minacce temute da una azienda come la nostra, un posto è senza dubbio rivestito dal ransomware, ma non escluderei possibili attacchi alle UTA od alle cabine elettriche a fini puramente distruttivi. Qui si inserisce la normativa, che per quanto riguarda le UTA prevede che possano essere aperte o chiuse, ad esempio in funzione di un incendio, «anche» per via informatica, bene allora io mi aspetterò che venga studiata, attuata ed implementata «anche» una security informatica in tale direzione.

Procedendo nella discussione si cerchino di riassumere le capabilities da adottare affinché una infrastruttura critica sia resiliente ed in grado di mitigare il rischio cyber: risorse tecnologiche adeguate, compliance normativa, sessioni di training del personale, metodologie di analisi e gestione del rischio, strategie di business continuity e disaster recovery, periodici test sulla sicurezza dei device e soluzione di identity management (quali gestione dei privilegi, autenticazioni multifattoriali etc.), da qui il commento: “In effetti la normativa NIS prevede tutto questo, e ci stiamo attualmente adoperando affinché tali azioni vengano attuate, cercando di sopperire a ciò in cui siamo carenti, il vantaggio apportato dalla NIS è invero l’aver fatto chiarezza sulla strada da dover intraprendere.

Non è che prima della NIS non ci fossero buone pratiche adottate, erano tuttavia procedure non scritte, diciamo «tramandate», che a seguire sono state poi specificatamente delineate dalla normativa, che ha avuto peraltro anche il ruolo fondamentale di spostare i riflettori sull’importanza di tali tematiche”.

Si domandi di conseguenza quali siano le sfide attuali od altresì gli ambiti su cui doversi focalizzare al fine di implementare gli attuali livelli di sicurezza: “A parer mio il fattore umano, inteso dalla base al vertice, ossia dall’operatore utilizzatore della specifica tecnologia alla Direzione stessa, rimane devastante, e necessita ad oggi di un’alta sensibilizzazione sui requisiti di security da dover rispettare.

Non è più il tempo di una formazione generale e dispersiva, ognuno dovrà essere istruito in misura settoriale sulle proprie competenze: chi compra device ed apparecchiature, o altresì chi fornisce la struttura, tutti possono a loro modo essere impattanti sulla sicurezza della struttura nel suo complesso.

A me personalmente come formula da seguire piace molto il concetto di cybersecurity “by design”, da attuare in tutti i campi, ciò significa che se devo comprare una qualsiasi strumentazione, dovrò richiedere fin dal principio agli stessi fornitori il rispetto di tutta una serie di requisiti di compliance”.

Parole conclusive sono state spese in uno spontaneo commento circa lo stato del proprio settore professionale: “Vorrei comunque ancora sottolineare come i professionisti della security si stiano facendo solamente adesso, difatti persone della mia generazione orientate in maniera specifica e verticale su tali tematiche sono davvero poche. C’è l’attuale bisogno di formare una classe professionale che svolga il mio stesso lavoro, che abbia le spalle un po’ più large, seguendo un’ottica diciamo sempre più «entreprise» ed in Italia sotto questo profilo non siamo tanto avanti.”

La cybersecurity sanitaria emerge come una sfida complessa che richiede un approccio multidisciplinare, dove normative stringenti, tecnologie avanzate e cultura della sicurezza devono convergere per proteggere infrastrutture critiche sempre più interconnesse. Nel prossimo e ultimo approfondimento parleremo di un approccio risk-based alla cybersecurity sanitaria, mostrando come la valutazione del rischio diventerà lo strumento chiave per bilanciare investimenti, minacce e livello di protezione accettabile.

Per maggiori approfondimenti sul tema è possibile scaricare gratuitamente il white paper di Maria Vittoria Zucca dal titolo “La cybercriminalità nel settore sanitario: anamnesi, diagnosi e prognosi di una ‘patologia’ informatica”.

Fonti:

[1] Così la definizione fornita dal dizionario Merriam-Webster: “measures taken to protect a computer or computer system (as on the Internet) against unauthorized access or attack”, per come disponibile al sito internet https://www.merriam-webster.com/dictionary/cybersecurity

[2] ISO/IEC 27032: 2012, “Information technology – Security techniques – Guidelines for cybersecurity”, July 2012, reperibile al sito internet https://www.iso.org/standard/44375.html

[3] P. Montessoro, “Cybersecurity: conoscenza e consapevolezza come prerequisiti per l’amministrazione digitale”, in Istituzioni del federalismo, n.3, 2019, pp. 783-800.

[4] Alcatel Lucent Enterprise, Sicurezza informatica della rete sanitaria nell’era della trasformazione digitale: con una intervista speciale a Silvia Piai, Research Director per IDC Health Insights, ALE international, 2020.

[5] D.A. Wheeler, Secure Programming HOWTO, v3.72 Edition, 2015, p.16.

[6] Per infrastrutture critiche (IC) si intendono i sistemi, i servizi, le reti o le risorse che, se danneggiati o distrutti, causerebbero gravi ripercussioni alle funzioni cruciali della società, tra cui la catena di approvvigionamenti, la salute, la sicurezza ed il benessere economico-sociale della popolazione.

[7] Direttiva (UE) 2016/1148 (Direttiva NIS) del Parlamento europeo e del Consiglio del 6 luglio 2016 recante misure per un livello comune elevato di sicurezza delle reti e dei sistemi informativi nell’Unione.

[8] Decreto Legislativo 18 maggio 2018, n. 65 Attuazione della direttiva (UE) 2016/1148 del Parlamento europeo e del Consiglio, recante misure per un livello comune elevato di sicurezza delle reti e dei sistemi informativi nell’Unione.

[9] R. Setola, G. Assenza, “Recepimento della direttiva NIS sulla cyber-security delle reti”, in Sicurezza e Giustizia, n. IV, 2018, pp. 32-35.

[10] Ex art 6 della direttiva NIS, per determinare la rilevanza degli effetti negativi si dovrà tener contro dei seguenti fattori: il numero di utenti e altri settori che dipendono dal servizio offerto dal soggetto interessato; l’impatto che gli incidenti potrebbero avere, in termini di entità e di durata, sulle attività economiche e sociali o sulla pubblica sicurezza; la diffusione geografica relativamente all’aerea che potrebbe essere toccata da un incidente; l’importanza del soggetto per il mantenimento di un livello sufficiente del servizio, tenendo conto della disponibilità di strumenti alternativi per la fornitura del detto servizio.

[11] Quali le Linee guida per gli operatori di servizi essenziali (OSE), lavoro coordinato dalla Presidenza del Consiglio dei Ministri, dal Dipartimento delle informazioni per la sicurezza (DIS), in cooperazione con le autorità NIS di tutti i Ministeri, emanate in data 16 Luglio 2019.

[12] Proviene infatti dall’unificazione dei due Computer Emergency Teams preesistenti: il CERT nazionale ed il CERT-PA, quest’ultimo era pensato appositamente per i soggetti della pubblica amministrazione, dunque era precedente punto di riferimento degli ospedali pubblici.

[13] Commissione Europea, Relazione della Commissione al Parlamento Europeo e al Consiglio di valutazione della coerenza degli approcci adottati dagli Stati membri per l’identificazione degli operatori di servizi essenziali conformemente all’articolo 23, paragrafo 1, della direttiva 2016/1148/UE sulla sicurezza delle reti e dei sistemi informativi, Bruxelles 28.10.2019.

[14] Commissione Europea, Proposta di direttiva del Parlamento europeo e del Consiglio relativa a misure per un livello comune elevato di cybersicurezza nell’Unione, che abroga la direttiva (UE) 2016/1148, Bruxelles 16.12.2020

[15] Direttiva (UE) 2022/2555 del Parlamento europeo e del Consiglio del 14 dicembre 2022 relativa a misure per un livello comune elevato di cibersicurezza nell’Unione, recante modifica del regolamento (UE) n. 910/2014 e della direttiva (UE) 2018/1972 e che abroga la direttiva (UE) 2016/1148 (direttiva NIS 2), in Gazzetta Ufficiale dell’Unione Europea, L333, 27 Dicembre 2022.

[16] Si evidenzi peraltro come la Direttiva NIS 2 suddivida i propri attori in “soggetti essenziali” (settore di energia, trasporti, sanità, pubblica amministrazione, infrastrutture digitali etc.) e “soggetti importanti” (produzione e distribuzione di prodotti chimici, fornitori digitali, servizi postali, produzione di apparecchiature medicali etc.): ai primi si applicherà un rigoroso regime di vigilanza ex ante, mentre i secondi saranno sottoposti ad una vigilanza ex post che interverrà in caso di rilievi o segnalazioni di non conformità.

[17] Per Disaster recovery si intende quell’insieme di azioni e strategie operative, logistiche ed organizzative che una azienda mette in atto per mettere al sicuro e ripristinare i propri dati e la propria infrastruttura IT in seguito ad una interruzione forzata causata da un evento straordinario, sia esso di tipo accidentale, colposo o volontario.

[18] D. Pierattoni, “La direttiva NIS2: nuovi obblighi e opportunità”, in Sicurezza e Giustizia, V. II, MMXXII, pp.34-37

[19] Si specifichi che se un incidente informatico ha comportato anche un data breach per come disciplinato dal GDPR, da cui è derivata una sanzione ai sensi del Regolamento privacy europeo, le sanzioni amministrative della Direttiva de quo non saranno applicabili.

[20] European Commission, Proposal for a directive of the european parliament and of the council on the resilience of critical entities, Bruxelles 16.12.2020.

[21] Direttiva 2008/114/CE del Consiglio, dell’ 8 dicembre 2008 , relativa all’individuazione e alla designazione delle infrastrutture critiche europee e alla valutazione della necessità di migliorarne la protezione (Testo rilevante ai fini del SEE), in Gazzetta Ufficiale dell’Unione Europea, L345/75, 23.12.2008.

[22] Press release in occasione dell’accordo raggiunto fra Parlamento Europeo e Consiglio dell’Unione Europea circa l’approvazione della Direttiva CER, “Security Union: Commission welcomes today’s political agreement on new rules to enhance the resilience of critical entities”, 28 June 2022, Bruxelles.

[23] ENISA, Un Europa affidabile e sicura dal punto di vista informatico: Strategia Enisa, Agenzia dell’Unione europea per la cibersicurezza, Atene, Giugno 2020.

[24] ENISA, Procurement guidelines for cybersecurity in hospitals: good practices for the security of Healthcare services, European Union Agency for Cybersecurity, Athens Office, February 2020, reperibile al sito internet https://www.enisa.europa.eu/publications/good-practices-for-the-security-of-healthcare-services.

[25] Si precisi come il termine appalto, nella sua connotazione giuridica, sia inteso come procedura, quale corpus di principi e regole, che il legislatore italiano ha previsto quando una istituzione soggetta alla regolazione giuridica pubblica acquista o vende sul mercato beni, servizi ed opere. Tuttavia si vanno ad oggi via via ampliando i tradizionali modi di intendere l’attività d’appalto permettendo di comprendere fattispecie contrattuali diverse dal contratto di appalto stesso, quali la somministrazione, la locazione finanziaria o la concessione. Cfr. E. Pintus, Scelte pubbliche e strumenti di management per gli acquisti, McGraw-Hill, Milano, 2009.

[26] Per Laboratory Information System (LIS) si intende un particolare tipo di software utilizzato nei laboratori di analisi per la gestione integrata di molteplici tipi di dati e processi.

[27] S. Smith and R. Koppel, “Healthcare Information Technology’s Relativity Problems: A Typology of How Patients’ Physical Reality, Clinicians’ Mental Models, and Healthcare Information Technology Differ”, in Journal of the American Medical Informatics Association, 21, no. 1, January 2014, pp. 117–31.

[28] Peraltro il Procurement viene tripartito da ENISA in tre fasi: la plan phase (in cui l’ospedale analizza e studia i propri bisogni e necessità), la source phase (dove viene avviata la procedura di approvvigionamento, momento in cui l’ospedale riceve le relative offerte, valutando e selezionando i prodotti/servizi più adeguati, procedendo poi all’aggiudicazione del contratto), ed infine la manage phase (in cui si monitorano le effettive performance dei sistemi, servizi e/o dispositivi in modo tale da poter porre in essere eventuali misure correttive).

[29] Medesime raccomandazioni sono state emanate dall’Istituto Superiore della Sanità il 17 Giugno 2019, nel Documento di indirizzo del Gruppo di Studio Nazionale sulla Cybersecurity nei servizi sanitari, dal titolo “Buone pratiche per la sicurezza informatica nei servizi sanitari”.

[30] ASPR, Healthcare system cybersecurity: Readiness & Response Considerations, ASPR (Administration for strategic preparedness and response) – TRACIE (healthcare emergency preparedness information gateway), originally published February 2021, Updated October 2022.

[31] CINI-Cybersecurity National Lab, Il futuro della Cybersecurity in Italia: ambiti progettuali strategici, progetti ed azioni per difendere al meglio il Paese dagli attacchi informatici, Laboratorio Nazionale di Cybersecurity- CINI Consorzio interuniversitario Nazionale per l’Informatica, 9 Ottobre 2018.

[32] Si può comunque optare per l’organizzazione di un initial incident brief comprensivo della leadership aziendale, dei capi di dipartimento, degli esperti tecnici, dei consulenti legali e del personale in materia di pubbliche relazioni, ove vengono identificate quali funzionalità da adottare siano disponibili, sicure e maggiormente efficaci.

[33] Ministry of health Singapore, Healthcare Cybersecurity Essentials, CSA (Security Agency of Singapore), August 2021.

[34] Per ulteriori approfondimenti si indichi CREST, Cyber Security Incident Response Supplier Selection Guide, Version 1, 2013; Osterman Research, Cyber security in Healthcare, Whitepaper, February 2020.

[35] Con l’espressione UTA si intendono quelle apparecchiature atte a sopperire alla necessità di mantenere sotto controllo parametri d’aria come umidità, temperatura e purezza all’interno degli ambienti chiusi.

https://www.ictsecuritymagazine.com/articoli/cybersecurity-sanitaria/

Apr 03, 2026 Giancarlo Calzetta Approfondimenti, In evidenza, News, RSS, Scenario, Scenario 0

---

Nel mese scorso, il governo degli USA ha rilasciato un documento intitolato “President Trump’s CYBER STRATEGY  for America” che dovrebbe delineare la nuova strategia statunitense per la lotta al cybercrimine. L’obiettivo è quello di andare oltre la mera difesa tecnica e avanzare verso una trasformazione strutturale del modello di sicurezza, sempre più integrato con economia, geopolitica e innovazione tecnologica.

Ovviamente, lo scopo primario è quello di rafforzare la resilienza nazionale, ma subito dopo viene dichiarato quello di sostenere la competitività globale delle imprese americane facendo diventare la sicurezza non solo un costo operativo ma un fattore di crescita economica e digitale.

La strategia si articola attorno a sei direttrici principali, che ridefiniscono il ruolo dello Stato e del settore privato. Tra queste emergono con forza il rafforzamento della deterrenza contro gli attori ostili, l’introduzione di regolamentazioni più stringenti e la modernizzazione delle infrastrutture federali. Gli esperi di Trend Micro hanno analizzato il documento ed estratto alcuni punti chiave.

Il ruolo dell’intelligenza artificiale nella sicurezza nazionale

Uno degli elementi centrali della strategia è il ruolo dell’intelligenza artificiale come fattore duale: opportunità e minaccia. L’AI viene identificata come tecnologia chiave per rafforzare le capacità difensive, ma anche come acceleratore delle minacce.

Le analisi Trend Micro mostrano come il cybercrime stia evolvendo verso modelli sempre più autonomi, basati su agenti AI capaci di operare su larga scala e con velocità macchina e quindi le organizzazioni devono adottare modelli di sicurezza proattivi e automatizzati, in grado di competere con attaccanti sempre più sofisticati e industrializzati. Il tema non è più solo prevenire, ma reagire in tempo reale o, addirittura, anticipare gli attacchi.

Implicazioni per le imprese: più responsabilità e nuovi modelli operativi

La strategia introduce un principio destinato ad avere impatti profondi sul mercato: una maggiore responsabilità per i fornitori di tecnologia e per le organizzazioni che gestiscono infrastrutture critiche. Questo significa che la sicurezza “by design” dovrà entrare nei processi aziendali e nelle architetture digitali, piuttosto che essere aggiunta a posteriori. Dal punto di vista economico, ciò implica investimenti più consistenti ma anche più mirati, con un ritorno in termini di resilienza operativa, continuità del business e fiducia degli stakeholder.

Sovranità digitale e competizione globale

Un altro elemento chiave è il rafforzamento della sovranità digitale. La strategia punta a ridurre la dipendenza da tecnologie esterne e a consolidare un ecosistema nazionale forte, in grado di competere a livello globale. Questo approccio ha implicazioni dirette anche per il mercato europeo, dove temi analoghi – dalla NIS2 al concetto di cloud sovrano – stanno emergendo con forza. Inoltre, aggiungiamo noi, questo si configura come un ulteriore sprone alla creazione di un ecosistema europeo di cybersecurity, in grado di fornire tutta la tecnologia che verrà a mancare per “motivi di sicurezza nazionale” in futuro. In altre parole, la cybersecurity diventa un terreno di competizione tra blocchi economici, dove regolamentazione, innovazione e capacità industriale si intrecciano.

Verso un modello di sicurezza “a velocità macchina”

I commenti fatti dagli esperti di Trend Micro convergono sul fatto che il vero punto di discontinuità è rappresentato dalla velocità. Gli attacchi evolvono ormai a ritmi incompatibili con modelli difensivi tradizionali e quindi la strategia americana spinge verso un approccio basato su automazione, intelligence e piattaforme integrate. La sicurezza deve operare alla stessa velocità delle minacce, trasformandosi in un sistema continuo e adattivo. Per le aziende, questo significa ripensare completamente gli stack tecnologici, privilegiando piattaforme unificate e modelli operativi orientati alla gestione del rischio in tempo reale. Questo comporta un impegno notevole dal punto di vista di budget, ma soprattutto la necessità per gli europei di ripensare la propria necessità di sovranità tecnologica, accelerando per sopperire agli sviluppi che vedremo diventare sempre più estremi nei prossimi anni.

---

---

---

https://www.securityinfo.it/2026/04/03/strategia-cybersecurity-usa-verso-un-modello-piu-assertivo-e-industriale/?utm_source=rss&utm_medium=rss&utm_campaign=strategia-cybersecurity-usa-verso-un-modello-piu-assertivo-e-industriale