Un attacco alla supply chain software attraverso npm e PyPI non è più un’ipotesi accademica: è il meccanismo operativo che nel 2025 ha permesso la distribuzione di oltre 454.000 nuovi pacchetti malevoli nei registri open-source globali. È una cifra che merita di essere ripetuta, perché racconta qualcosa di profondo sulla fragilità strutturale dell’ecosistema su cui poggia la quasi totalità del software moderno.

Ogni volta che uno sviluppatore esegue npm install o pip install, sta dichiarando fiducia implicita in un registro pubblico che non richiede validazione dell’identità del publisher, non verifica la corrispondenza tra nome del pacchetto e contenuto, e – aspetto decisivo – privilegia automaticamente la versione più recente di ogni dipendenza. In un ecosistema dove i download annuali hanno superato i 9,8 trilioni e i componenti open-source costituiscono l’80-90% delle applicazioni moderne, quella fiducia implicita è diventata l’arma più efficiente a disposizione degli attaccanti.

Il 2026 State of the Software Supply Chain Report di Sonatype – pubblicato il 28 gennaio 2026 e basato sull’analisi di oltre 1,233 milioni di pacchetti malevoli cumulativi – documenta un’evoluzione che non è più quantitativa ma qualitativa: il malware nella supply chain software ha adottato la stessa architettura modulare, la stessa logica di riuso e la stessa capacità di scala che rendono potente l’open-source legittimo. Non stiamo più parlando di script rudimentali nascosti in pacchetti oscuri. Stiamo parlando di campagne industrializzate, persistenti, spesso orchestrate da attori statali, che trattano npm e PyPI come canali di distribuzione a basso attrito verso macchine di sviluppo e pipeline CI/CD – ambienti che, per definizione, sono vicini ai dati sensibili e all’accesso di produzione.

Questo articolo analizza i tre eventi che, tra la fine del 2025 e l’inizio del 2026, hanno reso impossibile ignorare la portata del problema: la campagna Lazarus “Graphalgo”, l’attacco “XPACK ATTACK” e – soprattutto – il worm autoreplicante Shai-Hulud, che ha dimostrato che la propagazione autonoma nei registri open-source non è più teoria, ma realtà operativa.

L’anatomia di Graphalgo: come Lazarus ha trasformato un colloquio di lavoro in un trojan multi-stadio

Il 12 febbraio 2026, ReversingLabs ha pubblicato l’analisi dettagliata di una campagna denominata “Graphalgo” – dal nome del primo pacchetto malevolo pubblicato su npm – attribuita con grado di confidenza medio-alto al Lazarus Group nordcoreano. La campagna era attiva dal maggio 2025 e rappresenta un salto qualitativo nelle operazioni di supply chain poisoning condotte da attori statali.

Il meccanismo è sofisticato nella sua semplicità psicologica. Gli attaccanti contattano sviluppatori JavaScript e Python attraverso LinkedIn, Facebook e Reddit, proponendo opportunità lavorative presso “Veltrix Capital” – una società fittizia presentata come operatore blockchain e crypto exchange, completa di domini registrati (veltrixcap[.]org, veltrixcapital[.]ai) e organizzazioni GitHub con repository apparentemente legittimi. Ai candidati viene chiesto di completare un “coding test” come parte del processo di selezione. I repository contengono dipendenze che puntano a pacchetti compromessi su npm e PyPI.

Qui sta il genio tattico: quando la vittima esegue o fa il debug del codice di test, il package manager installa automaticamente le dipendenze malevole. I pacchetti agiscono come loader di primo stadio, scaricando un Remote Access Trojan (RAT) dall’infrastruttura C2 controllata dagli attaccanti. Il RAT è in grado di eseguire comandi arbitrari, caricare e scaricare file, elencare i processi in esecuzione e – dettaglio rivelatore – verificare la presenza dell’estensione browser MetaMask, indicando un interesse specifico per il furto di asset crittografici. Sono state identificate tre varianti del RAT, scritte in JavaScript, Python e Visual Basic Script.

ReversingLabs ha identificato complessivamente 192 pacchetti malevoli in due lotti distinti: quelli con “graph” nel nome (apparsi su npm dal 2 maggio 2025 e su PyPI dal giugno 2025, progettati per mimare librerie legittime come graphlib e networkx) e quelli con “big” nel nome (apparsi su npm dal 17 novembre 2025 e su PyPI dal 9 dicembre 2025, probabilmente collegati a una seconda campagna di facciata ancora non identificata).

L’esempio emblematico è il pacchetto npm bigmathutils: la prima versione, benigna, è stata pubblicata e ha accumulato oltre 10.000 download. Solo a quel punto – quando la fiducia era stata costruita attraverso i numeri – gli attaccanti hanno iniettato il payload malevolo nella versione 1.1.0, pubblicata poco prima dell’11 febbraio 2026. Una strategia di attivazione ritardata che sfrutta la meccanica stessa dell’ecosistema: più download ha un pacchetto, più appare legittimo, più viene installato senza scrutinio.

L’attribuzione a Lazarus si basa su pattern ricorrenti documentati in operazioni precedenti: finti colloqui di lavoro come vettore di contatto iniziale, storie a tema crypto, malware multi-stadio con offuscamento stratificato, infrastruttura C2 protetta da token e – dato forense significativo – timestamp nei commit Git allineati al fuso orario GMT+9, quello della Corea del Nord. La campagna è una ramificazione diretta di operazioni precedenti come VMConnect (PyPI e GitHub) e Contagious Interview, documentate da Socket, Unit 42, Phylum e Veracode.

Il dato strategico: il design modulare di Graphalgo consente a Lazarus di sostituire le “facciate” (Veltrix oggi, un altro nome domani) mantenendo invariata l’infrastruttura backend di payload e C2. Questo significa che altre false aziende, altri pacchetti e altri test di codifica sono non solo probabili, ma inevitabili.

XPACK ATTACK: quando l’installazione diventa estorsione

Lo stesso giorno della divulgazione di Graphalgo, The Hacker News ha riportato la scoperta di una seconda campagna, indipendente da Lazarus ma emblematica dell’evoluzione creativa del malware nella supply chain. Denominata “XPACK ATTACK” da OpenSourceMalware e registrata per la prima volta il 4 febbraio 2026, questa operazione rappresenta un modello di monetizzazione completamente inedito: l’estorsione diretta durante l’installazione del pacchetto npm.

I pacchetti, tutti caricati dall’utente “dev.chandra_bose”, abusano del codice di stato HTTP 402 (“Payment Required”) per creare quello che appare come un legittimo paywall. Come ha spiegato il ricercatore Paul McCarty, l’attacco blocca l’installazione fino a quando la vittima non paga 0,1 USDC/ETH al wallet dell’attaccante, raccogliendo nel frattempo username GitHub e fingerprint del dispositivo. Se la vittima rifiuta di pagare, l’installazione fallisce dopo oltre cinque minuti – e lo sviluppatore potrebbe non rendersi nemmeno conto di aver incontrato malware piuttosto che un legittimo sistema di licensing.

XPACK ATTACK è significativo non per la sua scala (modesta) ma per il precedente concettuale che stabilisce: la monetizzazione del malware open-source non richiede più l’esfiltrazione di credenziali, l’installazione di backdoor o il deployment di ransomware. Può avvenire direttamente nell’atto stesso dell’installazione, sfruttando un meccanismo HTTP standardizzato che conferisce un’aura di legittimità tecnica all’estorsione.

Shai-Hulud: il worm che ha dimostrato che la propagazione autonoma è possibile

Se Graphalgo rappresenta la sofisticazione dello state-sponsored supply chain attack e XPACK ATTACK l’innovazione nel modello di monetizzazione, il worm Shai-Hulud è l’evento che ha ridefinito il perimetro della minaccia. Identificato per la prima volta il 15 settembre 2025 da ReversingLabs e oggetto di un advisory dedicato della CISA, Shai-Hulud è il primo malware autoreplicante nell’ecosistema npm – un worm che si propaga sfruttando le credenziali dei maintainer compromessi per pubblicare versioni avvelenate dei pacchetti che questi mantengono, creando una catena di infezione esponenziale senza intervento umano diretto.

Il meccanismo di propagazione è elegante nella sua brutalità. Una volta installato attraverso un pacchetto compromesso, il worm esegue discovery del sistema locale utilizzando TruffleHog – un tool legittimo di scansione segreti capace di identificare oltre 800 tipi diversi di credenziali – alla ricerca di token GitHub, NPM, chiavi AWS, GCP e Azure; esfiltra le credenziali raccolte verso un endpoint controllato dall’attaccante; crea un repository pubblico GitHub denominato “Shai-Hulud” sotto l’account della vittima, pubblicando i segreti rubati; utilizza i token npm rubati per autenticarsi nel registro come lo sviluppatore compromesso; identifica gli altri pacchetti mantenuti dallo stesso sviluppatore, inietta codice malevolo e pubblica versioni compromesse – permettendo al worm di propagarsi ai downstream user di quei pacchetti.

Il “paziente zero” identificato è il pacchetto rxnt-authentication versione 0.0.3, pubblicato il 14 settembre 2025. Da quel punto, la CISA ha confermato la compromissione di oltre 500 pacchetti. Ma è la seconda ondata, denominata “Shai-Hulud 2.0” e individuata nel novembre 2025, ad aver mostrato la vera portata della minaccia: 795 pacchetti compromessi, molti dei quali ampiamente utilizzati. Il pacchetto @asyncapi/specs, ritenuto il “paziente zero” di questa seconda ondata, contava da solo oltre 100 milioni di download lifetime. Complessivamente, i pacchetti compromessi – tra cui quelli di progetti come AsyncAPI, Zapier, PostHog e Postman – totalizzavano decine di milioni di download settimanali.

Shai-Hulud 2.0 ha introdotto diverse innovazioni rispetto alla prima variante. L’esecuzione del codice malevolo avviene nella fase preinstall anziché postinstall, ampliando drammaticamente la superficie d’impatto perché il malware si attiva prima che qualsiasi test o controllo di sicurezza possa intervenire. Il worm può infettare fino a 100 pacchetti npm (contro i 20 della prima versione). E, dettaglio particolarmente aggressivo, se non riesce né a replicarsi né a esfiltrare dati, tenta di cancellare la directory home dell’utente.

La tecnica di esfiltrazione ha introdotto il concetto di “cross-victim exfiltration”, documentato da Datadog Security Labs: le credenziali di una vittima vengono pubblicate in un repository GitHub associato a una vittima diversa e non correlata. Questo significa che cercare nei propri repository potrebbe non rivelare i dati esfiltrati dal proprio ambiente. Se il malware non trova credenziali GitHub disponibili localmente, cerca proattivamente su GitHub i repository di esfiltrazione creati da altre vittime e tenta di utilizzare i token compromessi di queste ultime per continuare la propagazione.

La risposta è stata significativa. Microsoft ha pubblicato una guida dettagliata per la detection e l’investigazione, introducendo una nuova funzionalità in Microsoft Defender for Cloud basata su agentless code scanning per identificare i pacchetti Shai-Hulud 2.0 tramite SBOM. Palo Alto Networks Unit 42 ha fornito un’analisi tecnica approfondita con regole di detection. GitHub, che mantiene il registro npm, ha introdotto nuove misure di hardening: 2FA obbligatorio per tutte le pubblicazioni locali, limitazione della durata dei token a sette giorni, revoca dei classic token dal 9 dicembre 2025, e promozione del trusted publishing – un approccio pionierato da PyPI che rimuove i token API dalle pipeline di build.

La scala industriale: numeri che raccontano una mutazione

I tre eventi descritti non sono anomalie. Sono manifestazioni di una tendenza strutturale documentata dal report Sonatype 2026 con una granularità senza precedenti: 454.648 nuovi pacchetti malevoli identificati nel solo 2025, che portano il totale cumulativo a 1,233 milioni. La crescita anno su anno è del 75%.

Il dato più significativo non è la quantità ma la distribuzione: oltre il 99% del malware open-source si concentra su npm. Non è casuale. npm è il registro più grande al mondo, con il maggior volume di download, la minore frizione nella pubblicazione e – crucialmente – nessun requisito di validazione del namespace. Un attaccante può pubblicare un pacchetto con qualsiasi nome, e il tooling dell’ecosistema tende a preferire la versione più recente di ogni dipendenza. È una combinazione di fattori che rende l’avvelenamento strutturalmente facile.

Il 55,9% di tutti i pacchetti malevoli registrati nel 2025 è classificato come “repository abuse”: gli attori trattano i registri come piattaforme, automatizzando la pubblicazione e iterando rapidamente per massimizzare la copertura. Il 27,5% rientra nella categoria “Potentially Unwanted Application” – pacchetti vuoti, demo con credenziali hardcoded, framework per bot di spam su messaging app. Ma il restante è malware operativo: dropper, infostealer, RAT, cryptominer, credential harvester.

L’attore più prolifico è il Lazarus Group, che secondo Sonatype ha individuato oltre 800 pacchetti associati a Lazarus nel 2025, evolvendosi da semplici dropper e cryptominer a catene di payload a cinque stadi che combinano dropper, furto credenziali e accesso remoto persistente. Solo nel primo semestre 2025, Sonatype ha bloccato 234 pacchetti npm e PyPI malevoli attribuiti a Lazarus, stimando fino a 36.000 vittime potenziali.

La campagna IndonesianFoods, scoperta nel novembre 2025, ha aggiunto un’altra dimensione: oltre 150.000 pacchetti pubblicati da un sistema automatizzato che genera un nuovo pacchetto ogni pochi secondi. La campagna, attiva da oltre due anni prima di essere individuata, sfruttava il protocollo TEA per monetizzare attraverso token blockchain le metriche di impatto artificialmente gonfiate.

È importante precisare che, a differenza di Shai-Hulud, il meccanismo di propagazione di IndonesianFoods richiede esecuzione manuale e non costituisce un worm nel senso stretto del termine, come evidenziato da Socket.dev. Tuttavia, la scala dell’operazione resta impressionante. Come ha osservato Garrett Calpouzos di Sonatype, dopo GlassWorm e l’hijack di chalk/debug, IndonesianFoods è l’iterazione successiva dello stesso playbook: ogni ondata di attacchi trasforma l’apertura di npm in un’arma leggermente diversa.

Perché il modello di fiducia dell’open-source è strutturalmente rotto

C’è un paradosso al centro di questa crisi che merita di essere esplicitato: le stesse caratteristiche che rendono l’open-source potente – apertura, riusabilità, distribuzione frictionless – sono esattamente quelle che lo rendono vulnerabile. npm non è stato progettato come sistema di distribuzione di software con garanzie di sicurezza. È stato progettato come commons collaborativo. La fiducia non è un meccanismo di sicurezza verificabile: è un’assunzione sociale.

Il modello di minaccia tradizionale per la supply chain software presupponeva che l’attaccante dovesse compromettere un sistema di build, alterare un artefatto firmato, o sfruttare una vulnerabilità in un componente legittimo. Quello che il 2025 ha dimostrato è che nulla di tutto questo è necessario. Basta pubblicare un pacchetto con un nome plausibile, accumulare download (o acquistarli), e attendere che il tooling di milioni di sviluppatori lo installi automaticamente come dipendenza transitiva.

Il report Sonatype documenta un ulteriore livello di rischio: lo sviluppo assistito da AI amplifica il problema. Analizzando quasi 37.000 upgrade di dipendenze assistiti da LLM, Sonatype ha riscontrato che circa il 28% erano allucinazioni – versioni inesistenti di pacchetti. In alcuni casi, gli LLM hanno suggerito l’installazione di pacchetti effettivamente malevoli. Senza intelligence verificata in tempo reale, l’AI non corregge i dati cattivi: li distribuisce più velocemente.

Le contromisure: dalla fiducia implicita alla verifica operativa

La fine della fiducia implicita nei registri pubblici non è una catastrofe: è un momento di maturazione. Ma richiede un cambio di paradigma operativo che va oltre il singolo strumento. Ecco le contromisure che, sulla base dell’evidenza raccolta, hanno dimostrato efficacia concreta.

Software Bill of Materials (SBOM) come prerequisito – L’SBOM non è più un nice-to-have regolatorio: è l’unico modo per avere visibilità su cosa effettivamente risiede nell’ambiente di build. Microsoft ha introdotto la generazione SBOM agentless in Defender for Cloud specificamente per identificare i pacchetti Shai-Hulud 2.0 – dimostrando che senza un inventario delle dipendenze leggibile da macchina, la detection è cieca. Il Cyber Resilience Act europeo e l’AI Act stanno convergendo sulla richiesta di prova di provenienza, contenuto e controllo lungo l’intero ciclo di vita del software.

Repository firewall e policy di lockfile – Un repository firewall agisce come proxy tra l’ambiente di build e il registro pubblico, bloccando pacchetti noti come malevoli e applicando policy di approvazione prima che qualsiasi pacchetto entri nella pipeline. La policy di lockfile (package-lock.json per npm, Pipfile.lock per Python) impedisce che il tooling risolva automaticamente alla versione più recente, neutralizzando il vettore della delayed malicious update sfruttato da Graphalgo.

Trusted publishing e token hygiene – Dopo Shai-Hulud, GitHub ha imposto 2FA obbligatorio per le pubblicazioni npm locali, limitato la durata dei token a sette giorni e revocato i classic token dal 9 dicembre 2025. Il modello di trusted publishing, già adottato da PyPI, rimuove i token API dalle pipeline di build sostituendoli con attestazioni verificabili legate al provider CI/CD. Ogni organizzazione che pubblica pacchetti su npm dovrebbe adottare questo modello come standard minimo.

Dependency cooldown e binary analysis – I pacchetti malevoli nella supply chain software si eseguono durante l’installazione, prima ancora che il codice venga compilato o testato. Un approccio emergente, adottato da Elastic dopo l’incidente Shai-Hulud 2.0, prevede un periodo di “cooldown” (14 giorni nel caso di Elastic) durante il quale le nuove versioni dei pacchetti non vengono automaticamente adottate, permettendo alla comunità di individuare eventuali compromissioni. L’analisi binaria dei pacchetti e il monitoraggio runtime delle connessioni di rete anomale durante l’installazione sono complementi necessari allo scanning statico del codice.

Separazione degli ambienti e least privilege – Le macchine di sviluppo e gli agenti CI/CD non dovrebbero mai avere accesso diretto a credenziali di produzione, token cloud o segreti critici. Shai-Hulud ha dimostrato che un singolo pacchetto compromesso può raccogliere token GitHub, npm, AWS, GCP e Azure dalla stessa macchina. La segmentazione degli ambienti e il principio di least privilege per le pipeline di build non sono best practice opzionali: sono l’unica barriera tra un’infezione locale e una compromissione dell’infrastruttura cloud.

Il quadro normativo: NIS2, CRA e la responsabilità della supply chain

L’evoluzione normativa europea sta convergendo sulla supply chain software come area di responsabilità esplicita. La direttiva NIS2 (Direttiva UE 2022/2555) richiede alle entità essenziali e importanti di gestire i rischi della catena di approvvigionamento digitale, inclusa la verifica delle pratiche di sicurezza dei fornitori di software. Il Cyber Resilience Act (Regolamento UE 2024/2847), entrato in vigore il 10 dicembre 2024, impone ai produttori di prodotti con elementi digitali di garantire la sicurezza del software lungo l’intero ciclo di vita, incluse le dipendenze open-source. Gli obblighi principali saranno applicabili da dicembre 2027, con quelli relativi alla gestione delle vulnerabilità e alla segnalazione degli incidenti in vigore già da settembre 2026.

Questo significa che un’organizzazione europea che subisce una compromissione attraverso un pacchetto npm malevolo non può più invocare l’imprevedibilità dell’attacco come attenuante. La due diligence sulla supply chain software – SBOM, scansione delle dipendenze, policy di approvazione dei pacchetti – è diventata un obbligo di compliance, non una raccomandazione di best practice.

Prospettive: cosa aspettarsi nei prossimi 12 mesi

La traiettoria è chiara e il suo prossimo punto di accelerazione è identificabile. L’avvelenamento della supply chain software diventerà più sofisticato lungo tre direttrici convergenti.

La prima è l’integrazione con l’ingegneria sociale avanzata. Graphalgo ha dimostrato che il vettore “fake recruiter” è devastantemente efficace perché sfrutta la legittima aspirazione professionale degli sviluppatori. Varianti future sostituiranno le finte aziende crypto con finte aziende AI, finti progetti open-source alla ricerca di contributori, finte conferenze con “workshop pre-evento” che richiedono l’installazione di dipendenze compromesse.

La seconda è la propagazione autonoma. Shai-Hulud ha dimostrato il principio; le varianti successive saranno più silenziose, più selettive e più difficili da rilevare. Un primo segnale è già arrivato: il 20 febbraio 2026, Socket ha identificato SANDWORM_MODE, un nuovo worm stile Shai-Hulud che aggiunge capacità di prompt injection nei coding assistant AI, posizionandosi all’interno sia delle pipeline CI che degli strumenti di sviluppo. Un worm che compromette solo pacchetti con download settimanali superiori a una soglia, che attende settimane prima di attivare il payload, e che esfiltra attraverso canali legittimi (webhook GitHub, API cloud native) potrebbe propagarsi per mesi prima di essere individuato.

La terza è il targeting dei modelli AI e dei sistemi agentic. Sonatype documenta già la presenza di payload malevoli nascosti in modelli AI e container image su piattaforme come Hugging Face. Con l’adozione dei Model Context Protocol (MCP) server e degli agenti AI autonomi che installano dipendenze senza supervisione umana, la superficie d’attacco della supply chain software si sta espandendo verso un territorio dove la velocità dell’infezione potrebbe superare la velocità della detection.

Conclusione: la supply chain software come campo di battaglia permanente

L’attacco alla supply chain software attraverso npm e PyPI non è un’emergenza temporanea da gestire con una patch: è una condizione permanente dell’ecosistema digitale moderno. I 454.648 pacchetti malevoli del 2025, il worm autoreplicante Shai-Hulud, la campagna state-sponsored Graphalgo e l’innovazione estorsiva di XPACK ATTACK sono manifestazioni diverse dello stesso fenomeno strutturale: la fiducia implicita nei registri pubblici open-source è diventata il punto di ingresso più efficiente per gli attaccanti, dagli adolescenti opportunisti agli apparati di intelligence statali.

La risposta non può essere la rinuncia all’open-source – sarebbe come rinunciare all’elettricità perché i fulmini esistono. Ma richiede l’abbandono definitivo dell’approccio “install and trust” a favore di un modello “verify then install”: SBOM operativi, repository firewall, lockfile rigorosi, trusted publishing, segmentazione degli ambienti, monitoraggio runtime. Non come aspirazione, ma come standard operativo quotidiano.

Il report Sonatype 2026 chiude con un’osservazione che vale come monito: il pacchetto malevolo non è più l’intero attacco, ma il primo passo di un’intrusione supply chain più ampia. Per ogni organizzazione che costruisce software – cioè, nel 2026, praticamente ogni organizzazione – il rischio della supply chain software non è un rischio da delegare ai developer: è un rischio da governare al livello del board.

Fonti principali

Sonatype, 2026 State of the Software Supply Chain Report (28 gennaio 2026)

ReversingLabs, Inside the ‘graphalgo’ fake crypto developer recruitment campaign (febbraio 2026)

ReversingLabs, Fake recruiter campaign targets crypto developers with RAT (febbraio 2026)

The Hacker News, Lazarus Campaign Plants Malicious Packages in npm and PyPI Ecosystems (12 febbraio 2026)

CISA, Widespread Supply Chain Compromise Impacting npm Ecosystem (23 settembre 2025)

Palo Alto Networks Unit 42, Shai-Hulud Worm Compromises npm Ecosystem (settembre-novembre 2025)

Microsoft Security Blog, Shai-Hulud 2.0 Guidance (9 dicembre 2025)

Datadog Security Labs, The Shai-Hulud 2.0 npm worm (25 novembre 2025)

ReversingLabs, Shai-Hulud 2.0 FAQ (9 dicembre 2025)

Infosecurity Magazine, Over 200 Malicious Open Source Packages Traced to Lazarus Campaign (novembre 2025)

Security Affairs, Malicious npm and PyPI packages linked to Lazarus APT (15 febbraio 2026)

Sonatype, Open Source Malware Chapter – 2026 Report

Elastic Blog, Navigating the Shai-Hulud Worm 2.0 (2 dicembre 2025)

Sysdig, Shai-Hulud: The Novel Self-Replicating Worm (17 dicembre 2025)

Checkmarx, NPM Hit By Shai-Hulud (dicembre 2025)

BleepingComputer, IndonesianFoods spammer floods npm with 150,000 packages (novembre 2025)

SecurityWeek, Amazon Detects 150,000 NPM Packages in Worm-Powered Campaign (novembre 2025)

Aikido Security, Shai Hulud Strikes Again (24 novembre 2025)

Socket.dev, Another Round of TEA Protocol Spam Floods npm (novembre 2025)

Kodem Security, SANDWORM_MODE (febbraio 2026)

https://www.ictsecuritymagazine.com/articoli/supply-chain-software/

Questo articolo fa parte di una serie dedicata all’analisi approfondita della cybercriminalità nel settore sanitario italiano. In questa sezione esamineremo il fenomeno dei data breach sanitari e la loro crescente incidenza nelle strutture sanitarie, analizzando l’evoluzione del concetto di privacy dalla tradizionale riservatezza alla moderna protezione dei dati personali sotto il GDPR.

Crescente rischio dei data breach sanitari e impatto economico della cybercriminalità

Con le seguenti allarmanti parole si avvia la prefazione del tradizionale rapporto CLUSIT 2020 sulla sicurezza ICT[1] in Italia:

Nell’anno appena passato si è consolidata una discontinuità, si è oltrepassato un punto di non ritorno, tale per cui ormai ci troviamo a vivere ed operare in una dimensione differente, in una nuova epoca, in un altro mondo, del quale ancora non conosciamo bene la geografia, gli abitanti, le regole e le minacce”. La convinzione, prosegue il Rapporto, è che sia avvenuto “un vero e proprio cambiamento epocale nei livelli di cyber-insicurezza, causato dall’evoluzione rapidissima degli attori, delle modalità, della pervasività e dell’efficacia degli attacchi.[2]

Il quadro così delineato dal rapporto Clusit va a destrutturare quella convinzione di cybersecurity fin troppo spesso associata a “realtà suggestive” (o fantascientifiche), distanti dalla vita di tutti i giorni, nonché appannaggio dei soli protagonisti della governance statale ed internazionale.

In una comunicazione congiunta, del 13 Settembre 2017, al Parlamento Europeo e al Consiglio traspare, con nitidezza, come i rischi cibernetici stiano aumentando in maniera esponenziale: “Secondo alcuni studi l’impatto economico della cybercriminalità è aumentato di cinque volte tra il 2013 e il 2017 e potrebbe ancora quadruplicarsi entro il 2019. […] Se non miglioreremo sostanzialmente la nostra cybersicurezza il rischio aumenterà in funzione della trasformazione digitale.” Dunque è senza dubbio diventato fondamentale rafforzare una cyber-resilienza attraverso “un solido mercato unico, importanti progressi nella capacità tecnologica nell’Unione e un numero molto più elevato di esperti qualificati”.[3]

Allora il fine che si è indirizzati a perseguire è proprio una accettazione più ampia del fatto che la cybersicurezza rappresenti una sfida sociale comune, motivo per cui dovrebbero essere coinvolti, in ottica di risposta, molteplici livelli: dell’amministrazione pubblica, dell’economia e della società.

Ovvio è come, in tale contesto, alcuni ambiti specifici debbano affrontare altrettanto specifiche problematiche, che impongono una integrazione delle strategie di cybersecurity di carattere generale con quelle di tipo settoriale: ed uno dei settori specifici che, negli ultimi decenni, più di altri ha subito notevoli trasformazioni, con un progressivo utilizzo di nuove tecnologie è proprio quello sanitario.

Il mercato sanitario invero si figura sempre più attenzionato da parte dei c.d. Tech Giants (Google, Amazon, Walmart etc.), i quali promettono di rivoluzionarne le tradizionali modalità di assistenza sanitaria attraverso una digitalizzazione dei servizi e una disintermediazione degli stessi rispetto agli erogatori tradizionali.

Il settore sanitario è presto diventato così un banco di prova paradigmatico per nuove ed ardue questioni, poste innanzitutto ai giuristi, in ragione specialmente della straordinaria mole di dati accumulati, della articolata complessità dei rapporti giuridici che vi si instaurano, nonché della esigenza di garantire il più alto livello possibile di sicurezza e privacy.[4]

Prima di procedere alla disamina delle principali condotte di cyber-criminalità che colpiscono l’healthcare system, si vuole qui fornire una panoramica sulla gravità e pericolosità degli attacchi, in quanto impattanti su un settore altamente vulnerabile: come si può intuire infatti c’è un legame diretto tra gli attacchi informatici subiti dalle strutture sanitarie e le condizioni dei pazienti che si affidano alle loro cure.

A tal fine si richiama il recente report condotto da Ponemon Institute, una delle principali organizzazioni di ricerca sulla sicurezza informatica, in unione con Proofpoint, società leader nel settore della cybersecurity e compliance, dal titolo “Cyber Insecurity in Healthcare: The Cost and Impact on Patient Safety and Care”.[5]

Lo studio vede coinvolti 641 professionisti dell’It (Information technology) quali responsabili, nonché partecipanti all’elaborazione di strategie di sicurezza informatica sanitaria, e fin da subito pone in marcata evidenza come l’89% delle organizzazioni intervistate dichiari di aver subito una media di 43 attacchi negli ultimi 12 mesi, quasi uno a settimana.

Si continua poi andando a delineare i quattro tipi di attacchi più comuni: la compromissione del cloud, l’attacco ransomware, alla supply chain[6], ancora la compromissione delle e-mail aziendali/ spoofing[7] ed il phishing[8].

Ecco che tali attacchi vengono messi in relazione con le loro dirette conseguenze verificatesi in sanità: da ritardi nelle procedure e negli esami, alla degenza più lunga dei pazienti, ad un loro progressivo trasferimento in altre strutture sanitarie, al sorgere di maggiori complicazioni nel fornire prestazioni sanitarie, fino ad un incremento dei tassi di mortalità.[9]

Così difatti recita il quesito formulato nel report, con l’ovvia possibilità per gli intervistati di apporre più di una risposta: “Se la tua organizzazione ha subito queste tipologie di attacchi informatici, quale impatto hanno avuto sulla cura dei pazienti?”.

Si è voluto innanzi graficamente rappresentare i dati raccolti (Figura 4.1) al fine di poter constatare come l’attacco ransomware rimanga a tutti gli effetti una sfida significativa: è difatti la tipologia di attacco informatico con la maggiore probabilità di influire sulla cura dei pazienti rispetto alle altre tipologie malevoli (il 64% delle aziende colpite da ransomware ha registrato ritardi nelle procedure mediche e quasi altrettante hanno visto prolungare le degenze dei pazienti).

Tali risultati rimarcano come le organizzazioni sanitarie dovrebbero dare maggiore priorità alla sicurezza IT, in questo senso commenta Larry Ponemon, presidente e fondatore di Ponemon Institute: “Gli attacchi che abbiamo analizzato mettono a dura prova le risorse delle organizzazioni sanitarie. Il risultato non è solo una enorme perdita economica, ma anche un impatto diretto sull’assistenza ai pazienti, che mette in allarmante pericolo la loro sicurezza e salute”.

A seguire si riportano altri risultati chiave emersi dal report:[10]

a) Dispositivi medici e mobile apps rimangono una delle principali preoccupazioni in tema di cybersicurezza. A tal proposito si usa l’espressione di Internet of Medical Things (IoMT) per indicare tutti i devices medici, di varia natura, collegati ad una struttura o ad un operatore sanitario tramite internet, in grado di generare, raccogliere, analizzare e trasmettere dati sanitari (si pensi a dispositivi indossabili, strumenti per il monitoraggio remoto dei pazienti, pompe di infusione, pacemakers).

Le organizzazioni sanitarie hanno in media più di 26.000 dispositivi connessi alla rete: sebbene il 64% degli intervistati si sia dichiarato preoccupato per la sicurezza inerente a tali devices medici, solamente il 51% di questi afferma che la propria organizzazione si sia effettivamente provvista di strategie di sicurezza informatica di prevenzione e risposta a possibili attacchi contro tali dispositivi.

b) Le organizzazioni si sentono al contempo più vulnerabili e più preparate alla compromissione del cloud: il 75% degli intervistati si dichiara difatti vulnerabile verso tali tipologie di attacchi e il 54% afferma di averne subito almeno uno negli ultimi due anni (le organizzazioni ricomprese in quest’ultimo gruppo arrivano a sostenere una media di 22 compromissioni negli ultimi due anni). Tuttavia, oltre ad essere più vulnerabili, si dichiarano anche maggiormente preparate ad affrontare tali minacce, con il 63% che dichiara di aver optato per l’adozione di misure specifiche al fine di esser preparati nel rispondere a simili cyberattacchi.

c) Il ransomware è la seconda più sentita vulnerabilità con il 72% degli intervistati che ritiene la propria organizzazione esposta a tale cyber-rischio, e con il 60% che sostiene come sia effettivamente la tipologia di attracco che desta maggiori preoccupazioni. Negli ultimi due anni le organizzazioni che sono state sottoposte ad attacchi ransomware (41% degli intervistati), hanno subito una media di tre di questi attacchi.

d) La mancanza di preparazione mette a rischio tanto le organizzazioni sanitarie quanto i pazienti stessi. Meno della metà degli intervistati dichiara di avere effettivamente una strategia documentata da seguire per gli attacchi spoofing/phishing (48%), e ugualmente per gli attacchi alla supply chain (44%).

e) I programmi di formazione e sensibilizzazione al cyber-rischio, insieme al monitoraggio dei dipendenti, rappresentano una delle principali strategie per mitigare le minacce informatiche: solo però il 59% degli intervistati ha dichiarato che la propria organizzazione stia affrontando concretamente il problema della mancanza di cyber-consapevolezza tramite o l’adozione di programmi di training per i dipendenti o monitorando il loro stesso operato.

f) La mancanza di competenze interne, fondi e risorse mettono anch’essi a dura prova la sicurezza informatica complessiva: il 53% degli intervistati sostiene di soffrire la mancanza di competenze interne specializzate e il 46% afferma come il personale lavorativo risulti insufficiente.

g) I cyberattacchi provocano enormi costi. È stato chiesto agli intervistati di stimare il singolo attacco informatico più dannoso subito negli ultimi 12 mesi: sulla base delle risposte ottenute, il costo totale medio per l’attacco informatico più dannoso è stato di 4.4 milioni di dollari, con una perdita di produttività quale conseguenza finanziaria di circa 1.1 milioni di dollari.

Da tale studio si è ricavata l’urgente necessità di investire nella cyber security: si è visto chiaramente come una scarsa protezione IT possa avere effetti assolutamente profondi e tangibili tanto sulla struttura sanitaria quanto sui pazienti. Purtroppo ancora oggi gli investimenti in termini di sicurezza vengono visti unicamente come costi e per questo spesso limitati il più possibile; se invece ci si rendesse conto che si tratta di veri e propri investimenti dotati di un loro ritorno in diminuzione dei rischi, molti incidenti potrebbero essere fortemente limitati se non evitati, assieme ad un ingente risparmio sia di tempo che di denaro.[11]

Così conclude commentando Ryan Witt, healthcare cybersecurity leader di Proofpoint: “L’assistenza sanitaria è rimasta indietro rispetto ad altri settori nell’affrontare il crescente numero di attacchi informatici, e questa immobilità impatta negativamente sulla sicurezza e sul benessere dei pazienti. […]

Finché la sicurezza informatica rimarrà una priorità di basso livello, gli operatori sanitari continueranno a mettere in pericolo i loro stessi pazienti. Per evitare conseguenze drammatiche, le organizzazioni sanitarie devono allora comprendere come la cybersecurity influisca sull’assistenza ai pazienti e mettere in atto i passi necessari per proteggere al meglio le persone e i loro dati”.

Ed è proprio di dati che nel diretto prosieguo si tratterà, o meglio, delle loro sempre più frequenti illecite violazioni, divulgazioni, perdite e compromissioni, anche conosciute col nome di Data breaches.

Data breach

Nuova frontiera della privacy: la protezione dei dati personali

La nozione di privacy trova una sua primordiale accezione nel “right to be alone”[12] teorizzato dai due giuristi statunitensi Warrein e Brandeis nel 1890, traducendosi nel diritto dei singoli alla riservatezza: uno spazio della vita, quasi fisico, da cui il soggetto aveva diritto di tenere esclusi gli altri, a loro volta doverosi di rispettarne l’individualità, una sorta di “tutela dell’intimità privata”.[13]

Sin da subito si può constatare come esso si presenti quale diritto a contenuto essenzialmente negativo, comprendente il non subire ingerenze, il non far conoscere e il mantenere riservate alcune informazioni, piuttosto che a contenuto positivo, che viceversa si avrebbe con l’esercitare un effettivo controllo sulle informazioni medesime.

La definizione di privacy innanzi prospettata appare però, oramai da qualche decennio, non più perfettamente corrispondente alle trasformazioni socio-economiche subite dalla società, soprattutto alla luce della sua preponderante digitalizzazione. Per chiarire, con l’avvento della stagione degli elaboratori elettronici e con l’introduzione della ragnatela del web, la circolazione dei dati personali è divenuta indubbiamente regola fisiologica della società: una società per l’appunto denominata “dell’informazione e della comunicazione”.

Ecco che allora la diffusione e l’utilizzo delle nuove tecnologie e delle reti informatiche hanno prodotto un mutamento semantico del concetto di tutela della privacy: nata come diritto dell’individuo borghese a escludere gli altri da ogni forma di invasione della propria sfera privata (“my home, my castle”), si è sempre più strutturata come diritto di ogni persona al mantenimento del controllo sui propri dati, ovunque essi su trovino, riflettendo così il nuovo contesto in cui ogni persona cede continuamente e nelle forme più diverse dati che la riguardano.[14]

Di qui alcuni studiosi sono arrivati a formulare il cosiddetto “privacy paradox”:[15] le condotte di condivisione di informazioni (si pensi all’uso dei social networks) non sempre implicano anche la consapevolezza da parte degli utenti della divulgazione che i propri dati possono avere. A tal proposito asserisce Antonello Soro, Presidente dell’autorità Garante per la protezione dei dati personali: “Poiché i dati rappresentano la proiezione digitale delle nostre persone, aumenta in modo esponenziale anche la nostra vulnerabilità. La libertà di ciascuno è insidiata da forme sottili e pervasive di controllo, che noi stessi, più o meno consapevolmente, alimentiamo per l’incontenibile desiderio di continua connessione e condivisione”.[16]

D’altronde mentre la violazione di altri diritti fondamentali quali libertà personale, integrità personale, libertà di parola, si risolve più frequentemente in fatti e comportamenti visibili, spesso la violazione del diritto alla riservatezza si risolve in fatti e comportamenti di più difficile percezione, ma ugualmente di estrema gravità. E tale percettibilità delle violazioni è ancora minore in Internet rispetto alla vita reale. Per esser chiari, si voglia fornire un’ esemplificazione.

Se ad un individuo che entrasse in un negozio fosse sfilato il portadocumenti al fine di copiare l’indirizzo di casa e spedire continuamente materiale pubblicitario mirato, o per controllare le ricevute della carta di credito dalle quali ricavare ciò che l’individuo ha comprato nelle settimane precedenti, o ancora per ricavare dalle diverse tessere di cui è in possesso il suo orientamento politico, sindacale ed i suoi interessi sociali, tale soggetto si sentirebbe di certo profondamente leso dall’aver subito grave abuso.

Questo ed altro avviene in rete, e non vi è reazione lontanamente avvicinabile.[17]

Ora, tornando all’evolvere del concetto di privacy, a fronte quindi di un individuo messo a nudo, nella sua intimità, da una tecnologia sempre più invasiva (che è legata al polso da un orologio smart, che entra nelle case con una televisione di ultima generazione, che segue gli spostamenti in auto attraverso l’utilizzo di sensori connessi ad internet), la privacy segue un mutamento di rotta, finendo per essere ridefinita nella più comprensiva nozione di “protezione dei dati”, concetto che va ben oltre ai problemi legati alla difesa della sfera privata, abbracciando regole generali sulla circolazione delle informazioni.[18]

Il diritto alla protezione dei dati personali può essere definito come il diritto a che le informazioni su una persona fisica individuata o individuabile siano raccolte e trattate in modo lecito: esso consiste dunque nel diritto del soggetto cui i dati si riferiscono di esercitare un controllo, anche attivo, su detti dati, che si estende dall’accesso alla loro rettifica.[19]

Si qualifica allora come un diritto proprio di ogni soggetto ad autodefinirsi e determinarsi, dal contenuto fortemente positivo, consistente nell’esercitare un controllo effettivo sul flusso delle proprie informazioni, distinguendosi dalla mera riservatezza quale libertà negativa di non subire interferenze.

Con l’entrata in vigore del GDPR, e la consequenziale modifica al Codice della Privacy intervenuta con d.lgs. 10 Agosto 2018, n. 101, ha trovato allora finalmente realizzazione nell’ordinamento italiano quel microsistema autonomo basato sul riconoscimento di un nuovo bene giuridico di settore: il trattamento dei dati personali, su cui peraltro svariati cenni sono già stati fatti nel discorrere del secondo capitolo, a cui si rimanda.

Si consideri comunque che la stessa giurisprudenza europea condivideva il bisogno di mutare l’approccio consolidatosi negli anni precedenti, basato su di una statica tutela della riservatezza. La Corte di Lussemburgo, infatti, aveva più volte evocato il concetto di “sovranità digitale”, allo scopo di indurre i legislatori nazionali a prendere in debita ed attenta considerazione l’esistenza di un nuovo ordinamento giuridico, l’ordinamento digitale, inteso come spazio immateriale in cui confluiscono e vengono trattati dati personali digitali.

Architravi della nuova disciplina risultano essere i fondamentali principi del consenso e di accountability che, si voglia ripetere anche in questa sede, consiste nella responsabilizzazione di chi è titolato a trattare i dati, cui viene imposta, tramite l’ordine di rendicontazione, una gestione idonea a garantire la piena conformità del trattamento ai principi sanciti dal Regolamento Ue e dalla legislazione interna.[20]

Pare, tuttavia, che l’evoluzione legislativa si sia qualitativamente arrestata, nonostante i proclami in materia di prossime regolamentazioni[21] e nonostante l’approvazione del GDPR: il diritto alla protezione dei dati personali, per come oggi regolamentato, si appalesa anacronistico.

Rimane infatti un diritto che affonda le proprie radici nella società degli anni Settanta, che si apprestava a diventare la Società dell’informazione, un mondo ad oggi profondamente mutato: il dato è sempre meno controllabile, fra Big Data[22] e sistemi in cloud, o comunque sostanzialmente inaccessibile a chi dovrebbe sorvegliare l’applicazione della normativa.

Se da un lato le tecnologie che plasmano la società avanzano ad un ritmo impressionante, dall’altro gli strumenti di protezione effettiva diventano sempre più obsoleti, senza tuttavia essere aggiornati o rimpiazzati, il che causerà conseguenze particolarmente gravi nei settori a maggior rischio, come quello della salute.[23]

Ai fini della trattazione, ciò che è fin qui stato detto nel discorrere di privacy dovrà essere necessariamente trasposto sul piano della sanità, per qualche considerazione.

Ormai è chiara l’evoluzione dal materiale al digitale che negli ultimi anni ha profondamente toccato il sistema sanitario italiano, evoluzione da cui emergono nuovi profili critici non soltanto per quanto riguarda l’efficienza delle cure e l’efficientamento delle strutture sanitarie, ma anche, e soprattutto, per quanto riguarda il coordinamento tra il diritto alla salute e il diritto alla protezione dei dati sanitari dei pazienti.

La nostra Carta Costituzionale all’art. 32 riconosce e tutela il diritto alla salute come diritto fondamentale dell’individuo e interesse della collettività,[24] prescrivendo altresì una riserva di legge rafforzata in forza della quale un trattamento sanitario previsto per legge “non può in nessun caso violare i limiti imposti dal rispetto della persona umana”. Formula questa complementare alla tutela della dignità, riconducibile all’art. 2 della Costituzione stessa.[25]

A sua volta, il diritto alla protezione dei dati, trova suo massimo riconoscimento nel secondo articolo costituzionale, in quanto riconducibile anch’esso all’esigenza di assicurare la dignità dell’interessato, che potrebbe essere difatti violata ogni qualvolta si verifichi un qualsivoglia vulnus nelle misure tecniche ed organizzative preposte alla tutela di tali dati.[26]

Entrambi i principi, tutela della salute e protezione dei dati personali, saranno allora meritevoli di una tutela intensa quanto dinamica, in costante adeguamento con l’evoluzione tecnologica e il progresso scientifico: sarà compito del giurista trovare il giusto equilibrio fra efficienza del sistema sanitario e delle cure e rischi per la dignità dei pazienti, derivanti dalla digitalizzazione dei dati sanitari.

Ovvio è infatti come i dati sanitari, se illecitamente trattati, siano suscettibili di esporre l’interessato a forme di discriminazioni rese per l’appunto possibili dalla conoscenza di aspetti particolarmente intimi della persona, quali quelli idonei a rivelarne lo stato di salute.

Ad enucleare le criticità di una sanità digitale si richiamino, ancora una volta, le parole di Soro:

Sotto questo profilo la strada da fare è ancora tanta: recenti ricerche hanno indicato, infatti, il settore sanitario come uno di quelli esposti ai maggiori rischi in termini di cyberattacchi perché carente di un piano organico di sicurezza e protezione, oltre che di risorse necessarie per investimenti sulle infrastrutture informative. Eppure proprio questo dovrebbe essere, invece, il settore su cui investire di più in termini di sicurezza informatica e digitale, per garantire che il processo di innovazione tecnologica sia accompagnato da misure tali da assicurare autenticazione dei dati, loro tracciabilità, accessi selettivi con credenziali univoche, cifrature, sistemi di alert, attività di auditing […] La protezione del paziente da queste vecchie e nuove vulnerabilità deve essere un obiettivo centrale per un sistema sanitario all’altezza delle sfide della società digitale, in cui parallelamente alle opportunità (di ricerca, di cura, di avanzamento delle diagnosi e delle terapie) crescono anche i rischi.[27]

Nozione di Data Breach

I dati personali conservati, trasmessi o trattati da aziende e pubbliche amministrazioni possono essere soggetti al rischio di perdita, distruzione o diffusione indebita, a seguito di attacchi informatici, accessi abusivi, incidenti o eventi avversi (si pensi ad incendi od altre calamità).

Così per data breach (o violazione dei dati personali) si intende ex art. 4 n.12 GDPR “una violazione di sicurezza che comporta, accidentalmente o in modo illecito, la distruzione, la perdita, la modifica, la divulgazione non autorizzata o l’accesso ai dati personali trasmessi, conservati o comunque trattati”.

Ecco che una violazione di tal genere non può che compromettere quella triade CIA dell’Information Security di cui già si trattava nel previo capitolo, sorretta dai pilastri della riservatezza, integrità e disponibilità.

Si vogliano qui fornire alcuni possibili esempi di condotte riconducibili a tale definizione:

1. L’accesso o l’acquisizione dei dati da parte di terzi non autorizzati;
2. Il furto o la perdita di dispositivi informatici contenenti dati personali;
3. La deliberata alterazione di dati personali;
4. L’impossibilità di accedere ai dati per cause accidentali o per attacchi esterni, virus, malware etc.;
5. La divulgazione non autorizzata di dati personali.

Nelle previsioni del Regolamento Ue 2016/679 viene disciplinato in dettaglio il procedimento che il titolare del trattamento[28] dovrà porre in essere nel caso in cui sia in atto una simil violazione dei dati personali.

Dall’art. 33 GDPR si ricava infatti che il titolare del trattamento (soggetto pubblico, impresa, associazione etc.) senza ingiustificato ritardo, e ove possibile, entro 72 ore dal momento in cui ne sia venuto a conoscenza, deve notificare la violazione dei dati personali all’autorità di controllo competente (si intenda ivi il Garante per la protezione dei dati personali), a meno che sia improbabile che la violazione stessa comporti un rischio per i diritti e le libertà delle persone fisiche. Qualora la notifica al Garante sia effettuata oltre il termine delle 72 ore, dovrà essere corredata dai motivi del suddetto ritardo.[29]

Da ciò si ricava come siano da notificare unicamente le violazioni di dati personali che possono avere effetti significativi sugli individui, causando danni fisici, materiali o immateriali (si pensi alla perdita del controllo sui propri dati personali, ad un danno reputazionale, una perdita finanziaria, il furto di identità, la discriminazione o il rischio frode).

Al terzo comma del medesimo articolo si specifica che tale notifica dovrà avere come contenuto minimo:

1. Una descrizione della natura della violazione dei dati personali che comprenda, ove possibile, le categorie e il numero approssimativo di persone interessate nonché le categorie e il numero approssimativo dei dati personali interessati;
2. Il nome e i riferimenti di contatto del responsabile della protezione dei dati (se designato dal titolare) o comunque di un referente competente a fornire ulteriori informazioni;
3. Una descrizione delle possibili conseguenze della violazione dei dati personali;
4. Una descrizione delle misure adottate o di cui si propone l’adozione per porre rimedio alla violazione dei dati personali, comprese, se del caso, le misure adottate per mitigare eventuali effetti negativi.

Si noti come il responsabile del trattamento[30] che viene a conoscenza di una eventuale violazione sarà tenuto ad informare tempestivamente il titolare di modo che quest’ultimo possa attivarsi di conseguenza.

Inoltre, a prescindere dalla notifica al Garante, il titolare del trattamento documenta tutte le violazioni dei dati personali, comprese le circostanze ad esse relative, le conseguenze e i provvedimenti adottati per porvi rimedio. Tale documentazione consente alla stessa autorità di controllo di effettuare eventuali verifiche sul rispetto della normativa.

All’art. 34 GDPR viene prevista poi una ulteriore importante incombenza, collegata alla precedente, e cioè la comunicazione della violazione dei dati personali a tutti gli interessati, ovvero alle persone fisiche cui si riferiscono i dati personali oggetto del trattamento. Difatti quando la violazione è suscettibile di presentare un rischio elevato per i diritti e le libertà delle persone fisiche, il titolare del trattamento dovrà necessariamente comunicarla, con linguaggio semplice e chiaro, agli interessati, senza ingiustificato ritardo.[31]

A norma del terzo comma tuttavia tale comunicazione non risulta esser dovuta unicamente nei casi in cui:

1. Il titolare del trattamento abbia messo in atto le misure tecniche ed organizzative adeguate di protezione e tali misure siano state applicate ai dati personali oggetto della violazione, in particolare quelle destinate a rendere i dati incomprensibili a chiunque non sia autorizzato ad accedervi (si pensi ai sistemi di cifratura);
2. Il titolare del trattamento abbia successivamente adottato misure atte a scongiurare il sopraggiungere di un rischio elevato per i diritti e le libertà degli interessati;
3. Detta comunicazione richiederebbe sforzi sproporzionati. In tal caso si proceda invece tramite una comunicazione pubblica o simile misura di analoga efficacia.

Nel caso in cui poi il titolare del trattamento non abbia ancora comunicato all’interessato la violazione dei dati personali, la stessa autorità Garante potrà richiedere, dopo aver valutato la probabilità che la violazione rappresenti un rischio elevato, che vi provveda.

Qualora sia rilevata una violazione delle disposizioni del Regolamento Ue, il Garante potrà, ex art. 58 GDPR, prescrivere diverse misure correttive, fra le quali:

1. Rivolgere ammonimenti ed avvertimenti al titolare o al responsabile del trattamento;
2. Ingiungere al titolare o al responsabile del trattamento di conformare i trattamenti stessi alle disposizioni del Regolamento, in una determinata maniera ed entro un determinato termine;
3. Ingiungere al titolare del trattamento di comunicare all’interessato la violazione dei dati personali;
4. Imporre una limitazione provvisoria o definitiva al trattamento, incluso il divieto di trattamento, nonché ordinare la rettifica o la cancellazione di dati personali;
5. Infliggere una sanzione amministrativa pecuniaria ai sensi dell’art. 83 GDPR, in aggiunta alle misure correttive sopradette, o in luogo di tali misure.

Si ricavi come, quando si parla di violazioni della normativa in materia di privacy, il GDPR disciplini esclusivamente le sanzioni amministrative: il regolamento europeo stabilisce infatti, all’art. 84, che spetti a ciascuno Stato membro fissare autonomamente le sanzioni penali, purché queste ultime siano effettive, proporzionate e dissuasive.

Nel nostro ordinamento, come si avrà modo di approfondire in seguito, si è scelto dunque di mantenere in vigore quanto stabilito dal Codice della Privacy, emanato nel 2003, ed in particolare dagli articoli 167 e successivi, così come riformati dal d.lgs. n.101/2018.

Come sottolineato poc’anzi il GDPR disciplina in dettaglio solamente le sanzioni amministrative, pertanto di natura pecuniaria, senza fissarne un valore minimo: all’art. 83 si dispongono molteplici criteri atti ad orientare il Garante nella quantificazione della sanzione stessa, fra cui:

1. La natura, la gravità ed altresì la durata della violazione, tenendo in considerazione la natura, l’oggetto o la finalità del trattamento nonché il numero di interessati lesi e il livello del danno da essi subito;
2. Il carattere doloro o colposo della violazione;
3. Le misure adottate dal titolare o dal responsabile del trattamento per attenuare il danno subito dagli interessati;
4. Il grado di responsabilità del titolare o del responsabile del trattamento, tenendo conto delle misure tecniche e organizzative da essi messe in atto;
5. Eventuali precedenti violazioni pertinenti commesse dal titolare o dal responsabile del trattamento;
6. Il grado di cooperazione con l’autorità di controllo al fine di porre rimedio alla violazione;
7. Le categorie di dati personali interessati dalla violazione;
8. Eventuali altri fattori aggravanti o attenuanti applicabili alle circostanze del caso (si pensi a benefici finanziari conseguiti o perdite evitate).

Ai paragrafi 4 e 5 del medesimo articolo, il GDPR specifica poi che, accertata la violazione, la sanzioni amministrative pecuniarie possano arrivare fino a:

1. 10 milioni di euro, o per le imprese, fino al 2% del fatturato mondiale annuo dell’anno precedente, nei casi in cui, ad esempio, i dati personali vengano trattati in maniera illecita, non venga nominato il DPO (Data protection officer) o non venga comunicato un data breach all’Autorità Garante;
2. 20 milioni di euro, o per le imprese, fino al 4% del fatturato mondiale annuo dell’anno precedente, nei casi più gravi quali l’inosservanza dei diritti degli interessati o il trasferimento illecito di dati personali ad altri Paesi.

Riassumendo, le possibili conseguenze per le organizzazioni che agiscono in violazione del GDPR comprendono sia sanzioni amministrative, che sanzioni penali, come anche condanne al risarcimento del danno ed eventuali misure correttive (si pensi al sopracitato divieto temporaneo di trattamento dei dati personali).[32]

Allora, considerate tali ripercussioni, si intuirà l’importanza di interpretare correttamente le disposizioni Regolamento ed, in particolare, il suo “DNA di fondo”, ossia il sopracitato principio di accountability (traducibile come principio di responsabilizzazione).[33]

Sulla base di tale obbligo di rendicontazione spetterà infatti al titolare del trattamento adottare (e rispettare) tutte le misure tecniche, organizzative e legali necessarie a garantire l’effettiva protezione dei dati personali, consapevole che su di lui stesso, ed in minor parte anche sul responsabile del trattamento, graverà l’onere di documentare e dimostrare ex post la conformità di ogni misura adottata alla normativa Ue.

La chiave per interpretare correttamente la disciplina europea risiede proprio nel termine “dimostrare”: un buon titolare del trattamento farà in modo che ogni misura, ogni procedura, ogni metodologia applicativa sia affidabile, credibile e giustificabile ex post.

Per far ciò risulta necessario sviluppare una forte sensibilità informatica, tecnologica e legale, imparando a valutare in modo appropriato le proprie decisioni, servendosi ad esempio di una Gap Analysis, ossia l’effettuazione di una mappatura completa dei trattamenti, confrontando le misure adottate con i principi stabiliti dal GDPR e verificando l’eventuale sussistenza di difformità , in modo tale da, eventualmente, intraprendere azioni correttive di adeguamento.

Simulazione pratica di un data breach sanitario in ospedale

Si sono definiti i data breach come eventi di violazione della sicurezza di una banca dati, che possono trovare derivazione tanto da semplici errori umani (commessi, ad esempio, nella fase di progettazione od implementazione di un software) quanto, ed è ciò che in questa sede più interessa, da sofisticati attacchi informatici ad opera di cyber criminali.

Si può parlare in tali casi di una “falla” (o per l’appunto, breccia): ossia una fessura nella quale l’hacker può insinuarsi ed avere accesso non autorizzato ai dati personali di un individuo, quali possono essere i dati sulla salute.

L’ambito sanitario infatti, formato da strutture che archiviano ed elaborano un quantitativo considerevole di informazioni sensibili sui pazienti, si presenta, ancor più di altri settori, obiettivo vulnerabile agli attacchi informatici.

Si voglia di seguito, per amor di chiarezza, presentare una simulazione, in ambito ospedaliero, di quelli che possono essere i possibili scenari scaturenti da un data breach, quali: il furto dei dati sanitari, l’eliminazione dei dati stessi e la loro alterazione.[34]

Tizio in tarda serata viene ricoverato per una colecisti, all’arrivo in ospedale viene immediatamente sottoposto a trattamenti ed esami sanitari il cui esito viene registrato in una cartella clinica a disposizione del medico che lo visiterà il giorno seguente. Durante la nottata tuttavia, un gruppo di hacker riesce a “bucare” ed intromettersi nel sistema informatico ospedaliero, grazie ad alcune chiavette USB, contrassegnate appositamente dal logo ospedaliero, precedentemente lasciate in alcune postazioni del reparto col fine di esser scoperte ed in seguito installate dal personale. Gli infermieri infatti inserendo, erroneamente, le pendrive hanno dato immediato innesco al virus informatico artefice della “breccia” nel sistema ospedaliero.[35]

Durante la notte i cybercriminali si sono dunque connessi al database, dove risiedono registrati i dati sanitari di tutti i pazienti, inclusi quelli di Tizio.

Ed ecco così delinearsi i possibili scenari, lesivi rispettivamente dei tre principi cardine della triade CIA, ossia confidenzialità, disponibilità ed integrità:

Scenario 1. La sottrazione del dato. La mattina seguente i dati di Tizio vengono trovati correttamente dal medico curante che procede così con anamnesi, diagnosi e cure appropriate. La degenza ospedaliera di Tizio viene metodicamente seguita, fino alle sue dimissioni definitive.

Tutto procede regolarmente fino a quando però il reparto ICT, dotato di un sistema di tracciamento dei dati correttamente configurato, si accorge dell’avvenuto data breach e del conseguente furto di dati perpetrato.

Ecco che, in conformità alla normativa europea sopra ricordata, verrà redatta e notificata la segnalazione al Garante Privacy contenente gli elementi essenziali richiesti ex art. 33 GDPR (natura della violazione, numero degli interessati coinvolti, le misure adottate per porvi rimedio, etc.).

Da tale momento l’Autorità garante nazionale, in base al principio di accountability, darà avvio all’iter procedurale di controllo e valutazione in merito all’accaduto, vagliando le misure tecniche ed organizzative poste in essere dal titolare del trattamento, iter che potrebbe culminare in un provvedimento amministrativo sanzionatorio, laddove si accertasse una effettiva violazione o un non adeguamento alla disciplina Ue in materia di trattamento dei dati personali.

Si noti come in tale primo scenario non vi siano conseguenze strettamente cliniche pregiudizievoli per il paziente Tizio, questi ha subito infatti unicamente un danno derivante dalla perdita del controllo sui propri dati personali, una lesione della propria riservatezza.

A tal proposito l’art 82 GDPR prevede che “chiunque subisca un danno materiale o immateriale causato da una violazione del presente regolamento ha il diritto di ottenere il risarcimento del danno dal titolare del trattamento o dal responsabile del trattamento”.

Ciò significa che il soggetto danneggiato (ossia l’interessato), a seguito di un trattamento dei propri dati in violazione della normativa GDPR, potrà ottenere il risarcimento di qualunque danno occorsogli, agendo per l’intero indifferentemente contro il titolare o il responsabile del trattamento, tenuti solidalmente al risarcimento (eventuali clausole contrattuali di ripartizione del danno varranno difatti solo nei rapporto interni tra i danneggianti stessi).

A proposito della risarcibilità del danno la Suprema Corte di Cassazione ha, in una recente pronuncia,[36] ribadito come il danno non patrimoniale, pur determinato da una lesione del diritto fondamentale alla protezione dei dati personali, tutelato dall’art. 2 Cost. e dall’art. 8 CEDU, non si sottrae alla verifica della “gravità della lesione” e della “serietà del danno”. Da una lettura congiunta allora dell’art. 82 GDPR e della pronuncia della Suprema Corte emerge con chiarezza come, ai fini della risarcibilità del suddetto danno, siano necessarie in primis l’esistenza di una violazione del Regolamento 2016/679 e a seguire la dimostrazione dell’entità del danno stesso (nei due aspetti della gravità e della serietà).

In riferimento alla risarcibilità del danno viene poi precisato nel Considerando 146 del Reg. Ue che: “Il titolare del trattamento o il responsabile del trattamento dovrebbero risarcire i danni cagionati ad un soggetto da un trattamento non conforme al presente regolamento, ma dovrebbero essere comunque esonerati da tale responsabilità se dimostrano che l’evento dannoso non sia in alcun modo ad essi imputabile”.

Si ricordi come l’art. 24 GDPR e il Considerando 74 stabiliscano che il titolare debba mettere in atto, previa valutazione della natura, ambito e finalità del trattamento nonché del grado di rischio, le misure tecniche ed organizzative adeguate, prescrivendogli inoltre di esser in grado di dimostrarne l’efficacia.

L’imputabilità del titolare allora dovrà necessariamente esser valutata alla luce dei principi di responsabilizzazione e accountability del GDPR, il titolare (o il responsabile) potrà fornire la prova che il danno si è verificato perché non poteva esser previsto, dato che esulava dalla propria possibilità di controllo (si pensi al caso fortuito o alla forza maggiore) o che sono comunque state opportunamente predisposte tutte le misure tecniche e organizzative per evitare che il danno potesse verificarsi.

Scenario 2. L’eliminazione dei dati. La mattina seguente i dati sanitari di Tizio non vengono trovati, ciò provoca un immediato allarme nel reparto e gli esami clinici vengono ripetuti con urgenza: Tizio subisce perciò un ritardo nel trattamento, ciononostante le sue condizioni mediche non sono gravi. I dati questa volta vengono ritirati “a mano” e si procede con le cure del caso. L’eliminazione dei dati allerta ad ogni modo il reparto ICT che procede ad una diagnostica da cui viene rilevata una eliminazione non autorizzata del dato sanitario: il database viene dunque scansionato ed il sistema bonificato.[37]

Si è assistito anche in tal caso ad una compromissione dei dati personali che ne ha causato una perdita della loro pronta disponibilità, per cui si vedrà ex art. 33 GDPR la stesura e la notifica al Garante privacy dell’avvenuta violazione degli stessi dati sanitari dei pazienti. Da qui prenderà avvio il regolare iter di accertamento e di valutazione da parte dell’Autorità di controllo nazionale in merito alla sicurezza del sistema informatico ospedaliero, vagliandone le misure tecnico-organizzative adottate.

In tale secondo scenario non vi sono parimenti danni seri al paziente, ma si registra comunque un discreto esborso di denaro al fine di pagare le risorse incaricate di sistemare la parte software, nonché ripristinare il corretto livello di sicurezza informatica.

Scenario 3. L’alterazione dei dati. La mattina seguente i dati di Tizio vengono letti dal medico curante che, preoccupato per i valori completamente fuori norma, suggerisce una terapia con un farmaco che peggiora le condizioni del paziente. Da questo momento la salute di Tizio si aggrava celermente, i medici comprendono che vi è una discrepanza fra i risultati riportati nel sistema e le risposte biologiche del paziente. Non trovando una corrispondenza Tizio viene sottoposto ad ulteriori esami clinici per poi, successivamente, vedersi corrisposte le corrette cure ed i trattamenti opportuni.

Rendendosi comunque conto del danno arrecatogli, dovuto ad una non corretta protezione della integrità dei propri dati sanitari da parte della struttura sanitaria, che con molta probabilità non aveva adottato tutte le adeguate misure tecnico-organizzative per prevenire il pericolo di data breach, Tizio si vede intenzionato ad agire per ottenere un risarcimento ex art. 82 GDPR.

Nel frattempo, si apre anche una fase di accertamento della sicurezza dei sistemi informativi dal lato del Garante che, accertato il data breach e il non adeguamento alla normativa europea sulla protezione dei dati, emette un immediato provvedimento con annessa sanzione amministrativo-pecuniaria. Il reparto ICT intanto effettua una riprogettazione dei sistemi di gestione del dato e della sicurezza, andando ad incidere ulteriormente sui costi da sopportare.

Ci si accorgerà di come il terzo scenario sia con probabilità quello con i costi di gestione maggiori, ma soprattutto, di come sia l’unico ad aver realmente messo a rischio la salute del paziente. L’alterazione del dato è sicuramente molto meno visibile e rilevabile rispetto alla sua cancellazione o al suo furto e questo non fa che peggiorare i ritardi nelle reazioni del reparto ICT.

A tal proposito il tempo di rilevazione di un data breach risulta di dirimente importanza: al di là invero del caso in cui sia il malintenzionato stesso a render edotte le vittime circa l’effettuata violazione dei sistemi (spesso, come si vedrà, per chiedere un riscatto al fine di ripristinarne il regolare funzionamento), i tempi generali per suddetta rilevazione risultano ad oggi comunque molto alti.

Ovvio è pertanto che riuscire a monitorare i sistemi e le attività in modo tale da avere la piena capacità di accorgersi di una violazione in atto risulta il requisito imprescindibile per arrivare a prevedere, mitigare, nonché contenere tutti i possibili rischi informatici.[38]

A questo punto della trattazione appare comprensibile incominciare a domandarsi i motivi che si celano dietro a tali cyber-condotte, per quale ragione i dati sanitari siano tanto ambiti e soprattutto che concreto valore abbiano: se questi infatti sono un obiettivo criminale, significa che esiste una domanda di tali dati, e se c’è una domanda deve esserci un ritorno sull’investimento.

Si possono richiamare a tal proposito le parole di Agostino Ghiglia, componente del Garante per la protezione dei dati personali:

Ad oggi il settore meno preparato risulta essere proprio quello sanitario che, tra l’altro, paga il prezzo di gran lunga più caro dal momento che la spesa per i data breach è notevolmente aumentata. È evidente che il comparto sanitario risulti essere il più bersagliato a causa della quantità e qualità dei dati custoditi e che, ovviamente, hanno un notevole valore economico. Gli attacchi criminali non mirano infatti solo a bloccare i sistemi dietro la richiesta di un riscatto, ma soprattutto a capitalizzare i dati sensibili. È fondamentale per questo motivo che le strutture sanitarie prevedano un piano operativo d’azione che racchiuda sia una difesa in ambito tecnologico che un piano formativo del personale dal momento che il più delle volte gli attacchi vengono veicolati con precise comunicazione e-mail.[39]

Il mercato nero della salute

Vanno moltiplicandosi gli studi e le indagini che si interrogano sul perché il rischio cyber imperversi così minacciosamente sul mondo della sanità e, in particolare, sul mercato dei dati sanitari nel dark web[40], al fine di comprendere struttura, profitto ed acquirenti di un fenomeno mondiale così in profonda crescita.

Di seguito si riportano le parole di Soro: “Si tratta del commercio di dati tra i più delicati, in quanto in grado di rivelare gli aspetti più privati della vita, ed espressivi, oltretutto di una condizione di particolare vulnerabilità quale è quella di un paziente ricoverato in ospedale. Che è dunque affidato ad una struttura pubblica, dalla quale deve potersi aspettare non soltanto attenzione e cura, ma anche un assoluto rispetto per la propria riservatezza e dignità”.[41]

Innanzitutto si premetta come il valore di tali dati sensibili sia strettamente legato alla loro stessa tipologia, essi invero possono includere: dati personali identificativi del paziente, indirizzi e-mail, numeri di tessere sanitarie, varie informazioni mediche (esami diagnostici, referti di laboratorio, prescrizioni di medicinali etc.), dati assicurativi, nonché attestati e certificati di laurea in medicina.

Risulta in questa sede opportuno rifarsi al report “Healthcare Cyber Heists” condotto dalla società statunitense di cybersicurezza Carbon Black, datato al 2019. Il rapporto si fonda su un campione di interviste, rivolte a venti manager CISOs[42], ossia soggetti responsabili del definire e sviluppare strategie di sicurezza informatica, in tal caso specificatamente nel settore sanitario.[43]

È fuor di dubbio che tale survey offra unicamente una prospettiva parziale, ma ad ogni modo rilevante per comprendere quanto siano frequenti le cyber-offensive, come vengano rubati i dati sanitari e successivamente venduti.

Si vogliano dapprima riassumere i risultati chiave scaturenti dal rapporto:

a) L’83% delle organizzazioni sanitarie intervistate ha notato un notevole aumento dei cyber attacchi nell’ultimo anno (riferendosi al 2018);

b) I tentativi di intromissione informatica sono stati, in media, 8.2 al mese per ogni endpoint, ossia non per ogni organizzazione, ma per ciascun dispositivo connesso alla Rete;

c) Il 66% delle organizzazioni ha affermato che le offensive non sono solo più numerose ma anche maggiormente sofisticate, testimoniando di esser state bersaglio sia di attacchi ransomware che island hopping[44];

d) All’interrogativo su quale sia la maggiore preoccupazione della propria organizzazione le risposte sono state: la compliance (33%), i limiti di budget e risorse (22%), la perdita dei dati sanitari (16%) la vulnerabilità dei medical devices (16%) e l’impossibilità sopraggiunta di accedere ai dati dei pazienti (13%). Da qui si ricavi forse uno dei maggiori problemi della sicurezza sanitaria: pensare che la compliance (traducibile col termine “conformità”) equivalga alla sicurezza.

Troppe organizzazioni, seppur considerate conformi agli standard generali di sicurezza, sono ad ogni modo state vittime di molteplici violazioni: la conformità a disposizioni normative, regolamenti e codici di condotta è indubbiamente un buon punto di partenza, ma ciò non basta, Troppe organizzazioni, seppur considerate conformi agli standard generali di sicurezza, sono ad ogni modo state vittime di molteplici violazioni: la conformità a disposizioni normative, regolamenti e codici di condotta è indubbiamente un buon punto di partenza, ma ciò non basta, è infatti necessario creare un programma di sicurezza atto a contemplare anche tutte le esigenze specifiche di una organizzazione.

Il rapporto prosegue poi stilando un borsino indicativo di quelle che sono le tipologie di dati sanitari maggiormente vendute sul dark web, disposte di seguito in ordine di valore:

a) I dati in assoluto più costosi, nonché di allarmante diffusione, sono i Provider Data, si possono cioè trovare online i “pacchetti Fullz” ( 4.2) contenenti tutti i documenti di cui si necessita per ricostruire il background di un medico professionista: dati personali identificativi, diplomi di laurea, licenze mediche, nonché documenti assicurativi. Il costo del “pacchetto” si aggira sui 500 dollari.

Si intuisce già la versatilità che tali dati garantiscono nel loro utilizzo: dal procurarsi farmaci soggetti a prescrizione medica (per un uso personale od altresì per rivenderli in rete), fino all’acquisire falsi documenti (passaporti, patenti di guida etc.) con cui un qualsiasi soggetto non qualificato possa porsi come medico nei confronti di organizzazioni come assicurazioni e servizi sanitari.

Ciò che accade dunque vede in primo luogo un hacker compromettere la rete di un fornitore di servizi sanitari al fine di ricavarne documenti amministrativi che possano supportare l’identità contraffatta di un medico, cosicché successivamente un qualsiasi acquirente possa, a proprio vantaggio, presentarsi con la falsa identità del medico de quo.

A seguire le parole del Professor Kevin Curran, dell’università di Ulster:

Dire che i dati dei pazienti siano dalle 10 alle 15 volte più preziosi dei dati inerenti alle carte di credito è una buona stima, dato che tali dati offrono ai criminali informazioni permanenti ed altamente fruttifere”.[45] Ovvio è che nel caso di una carta di credito rubata, questa possa essere istantaneamente disattivata e gli addebiti fraudolenti contestati. Negli ultimi anni poi le banche hanno notevolmente rafforzato la propria sicurezza online incorporando trasferimenti e transazioni più sicure. Nel mondo sanitario il tutto risulta più complesso: i dati rubati non sono facilmente recuperabili e, in verità, non si dispone nemmeno di un chiaro processo per aiutare i pazienti a fronteggiare le conseguenze del furto di identità. È pertanto indispensabile prevedere delle misure proattive al fine di ridurre le probabilità che tale dati vengano trafugati.

b)Altri contenuti sanitari rinvenuti nella darknet, più numerosi e meno costosi dei precedenti, sono i forgeries (o falsificazioni), venduti ad una fascia di prezzo compresa fra i 10 e i 120 dollari. Essi possono assumere la forma di tessere sanitarie contraffatte, come anche di false prescrizioni mediche ( 4.3). Ad un venditore possono difatti esser forniti tutti i dati necessari per realizzare una prescription label personalizzata per l’acquirente, con cui ad esempio possa superare i controlli (quali in aeroporto) che vietano il trasporto di alcuni farmaci senza specifica prescrizione medica.

c) Ancora si possono trovare insurance login information, ad un prezzo contenuto di 3.25 dollari per singola credenziale di accesso, il basso costo è dovuto alla rapidità con cui le medesime credenziali possono esser cambiate una volta che la compromissione del database viene scoperta. Comunque, una volta ottenute le informazioni di accesso, l’acquirente può ottenere illecitamente tutte le informazioni riguardanti una determinata assicurazione medica, utilizzabili a loro volta per ricevere cure mediche o medicinali sotto prescrizione.[46]

Si vogliano qui riassumere i fini a cui si può indirizzare il furto dei dati sanitari: la costruzione di false identità, la commissione di frodi ai danni dei sistemi assicurativi, la richiesta di somme di denaro come riscatto al fine di rientrare in possesso dei propri dati, la contraffazione di documenti (certificati di nascita, passaporti etc.), l’emissione di false ricette mediche, nonché l’ottenimento di determinati farmaci.

Non si può nemmeno escludere che fra gli acquirenti nel suddetto sistema di compravendita vi siano anche grandi aziende, interessate parimenti ad entrare in possesso di Big Data altrimenti irraggiungibili, si pensi a grandi imprese farmaceutiche che potrebbero sfruttare i pacchetti di dati medicali in vendita per la ricerca e lo sviluppo di nuovi farmaci, avvantaggiandosi così notevolmente sulla propria concorrenza.

Si sottolinei invero come dai dati sanitari, in una loro forma aggrega, sia possibile derivare, predittivamente, una conoscenza circa: le aspettative di vita di una popolazione, la futura necessità di cure, assistenza o medicinali, la suscettibilità di sviluppare determinate patologie, tutte informazioni altamente sfruttabili per orientare determinate politiche e scelte commerciali ad opera di grandi competitors.[47]

Chiaro è comunque come i dati sanitari protetti di ciascun individuo, quelli che identificano ogni nostra storia di salute individuale, stiano diventando ad oggi miniera d’oro per i cyber criminali.

Così Roberto Setola dell’Università Campus Bio-Medico di Roma: “I dati sanitari sono i più appetibili per i cyber criminali. Sul dark web infatti sono quelli che vengono venduti al prezzo più elevato, ciò è dovuto alla loro grande versatilità: possono infatti risultare redditizi sia vendendoli sia utilizzandoli, sempre da un punto di vista criminale, contro il soggetto a cui appartengono. […] Il problema maggiore è che i dati sanitari non sono ben protetti: il passaggio dalla carta al digitale negli ospedali e nelle strutture sanitarie non è stato accompagnato da un cambiamento culturale degli operatori della sanità esponendo così i dati ad un alto rischio di perdita, furto, nonché alterazione.” [48]

Caso: Ulss 6 Euganea di Padova

Si voglia qui brevemente ricostruire un recente caso di cronaca, al fine di comprendere quanto siano attuali gli argomenti di cui si va trattando e di che ampio raggio siano, penisola italica inclusa.

Il tutto ha inizio il giorno 3 Dicembre 2021, momento in cui cominciano a diffondersi in rete le prime notizie riguardanti un attacco informatico subito dalla Ulss 6 Euganea, ossia l’Unità locale socio sanitaria di Padova. [49]

Non tarda ad arrivare un comunicato da parte della medesima struttura: “L’Ulss 6 Euganea informa che nella notte si è verificato un attacco hacker, che ha comportato il blocco della maggior parte dei server, compromettendone la fruibilità. Stiamo intervenendo con la massima celerità con tutti i nostri tecnici informatici al fine di ripristinare il prima possibile i servizi.”

I criminali hanno agito tramite attacco ransomware, di cui si avrà modo di trattare in seguito, rendendo impossibile accedere alle banche dati ed inviare informazioni alle piattaforme sanitarie, sospendendo le nuove registrazioni dei pazienti, il sistema dei laboratori, alcuni punti tamponi e hub vaccinali.

Di qui le immediate ripercussioni: i padiglioni di tamponi e vaccini (si pensi che in quel periodo si registravano più di 800 positivi in 24 ore a Padova e provincia) hanno dovuto riprendere a lavorare in modalità cartacea, e diversi problemi sono stati riscontrati al pronto soccorso, nelle terapie intensive, nelle radiologie, nei cup e nei laboratori analisi.

Così informa l’Ulss “È in essere una collaborazione stretta con l’Azienda ospedaliera Università di Padova e con il privato accreditato, ai quali vengono convogliati i casi indifferibili. Ove non supportati da reti informatiche esterne, l’Azienda procederà provvisoriamente alla registrazione su supporto cartaceo, che potrà creare inevitabili rallentamenti.”

Inutile dire come si sono adoperati e hanno lavorato strenuamente oltre 60 tecnici del settore al fine di contrastare il blocco, di minimizzare i danni, nonché di bonificare tutte le macchine ospedaliere e certificare quelle “pulite”.

Ad una settimana dall’attacco tuttavia soltanto un terzo dei computer risulta bonificato, ed i problemi persistono: seri danni vengono riscontrati alle infrastrutture IT, non risulta possibile emettere ricette dematerializzate, non possono essere inseriti i dati relativi agli isolamenti domiciliari da Covid-19, sono stati chiusi i punti prelievo e bloccate le prenotazioni specialistiche.

Solo in data 20 Dicembre si percepisce una lenta ripresa, si hanno difatti i primi risultati positivi (quali la riapertura di alcuni punti prelievi), al contempo però cominciano a diffondersi notizie circa una colossale mole di dati sensibili e di credenziali di accesso trafugati, il cui valore di mercato risulta incalcolabile: ecco profilarsi la probabile vera finalità dell’attacco informatico.

Con l’inizio del nuovo anno, dopo circa un mese da quello che è stato uno dei più gravi attacchi alla sanità italiana, sopraggiunge così la rivendicazione dell’attacco da parte del gruppo hacker Lockbit 2.0 che, in un post, avvia una sorta di “countdown”: i dati sottratti dall’azienda sanitaria saranno resi pubblici il giorno 15 Gennaio 2022, salvo pagamento di un riscatto (la somma pareva ammontare sugli 800.000 euro in criptovalute).

Viene dunque immediatamente aperta da parte del Garante della privacy una istruttoria per il data breach, processo mirante a verificare se i dati in possesso dell’Ulss fossero adeguatamente protetti e se sia stato fatto tutto il possibile (ossia adottata ogni misura tecnico-organizzativa necessaria) per evitare che i dati venissero sequestrati ed eventualmente diffusi dai criminali informatici.

Come preannunciato, nel pomeriggio del 15 Gennaio, Lockbit pubblica i dati sanitari, e più precisamente vengono diffuse due cartelle dal nome “Ulss2” e “Ulss3” contenenti all’incirca 9.300 documenti (fra cui pdf, documenti excel, word, etc.) riportanti svariate informazioni: dati sensibili dei pazienti (referti medici, analisi, esiti di tamponi molecolari Covid, coi rispettivi dati anagrafici) tabelle illustrative di stipendi e turni ospedalieri del personale medico-sanitario, nonché informazioni sul budget dei vari reparti e tanto altro ancora.

Non è da escludere che ciò che sia stato divulgato sia solo una quota delle informazioni in possesso del gruppo hacker Lockbit, il quale potrebbe aver nel frattempo rivenduto un’altra importante porzione di dati nell’underground del web.

Da parte dell’Ulss è stato emesso di conseguenza un conclusivo comunicato ufficiale[50] in cui si legge:

Fino ad oggi non sussisteva alcuna certezza che i malviventi fossero riusciti a venire in possesso di informazioni, in che quantità e il loro genere. I criminali avevano avanzato una richiesta di riscatto in denaro in cambio della non pubblicazione delle informazioni a loro dire sottratte all’Azienda Ulss 6. Tentativo estorsivo prontamente denunciato alle forze dell’ordine e alla Procura della Repubblica. […] La task force dell’Azienda Ulss 6, nel pieno rispetto delle indagini in corso, è al lavoro per valutare entità e tipologia dei dati pubblicati. Si ricorda che le informazioni comparse sul dark web sono altresì frutto di attività illegale e dunque chiunque intendesse consultarle o utilizzarle commetterebbe un reato […] Il confronto e lo scambio di informazioni con la Procura della Repubblica e il Garante per la protezione dei dati personali è costante, siamo a disposizione dei nostri utenti e confidiamo che le indagini di Procura e forze dell’ordine, che ringraziamo per il supporto, permettano di individuare e fermare questi criminali.

Tirando le fila di tale vicenda si può meditare sui danni che ne sono conseguiti: oltre alle perdite economiche riflesse sia a livello regionale che di sistema sanitario nazionale ed al grave danno reputazionale e d’immagine in capo all’Ulss, non si può trascurare l’offesa subita dai pazienti e dai cittadini che si sono visti negare diversi servizi sanitari (si pensi ad una visita specialistica per una malattia degenerativa) o hanno comunque subito dei rallentamenti nelle ricevere le proprie cure.

I dubbi, c’è da dire, permangono: è stato avviato un programma cyber ad hoc e sono state intraprese azioni di miglioramento per scongiurare, l’altrimenti inevitabile, ripetersi di un simile attacco?

Utili risultano, a tal proposito, le parole di Pierguido Iezzi, CEO e fondatore della cyber security company Swascan:[51] “Di base, per rendere sicura una struttura è necessario ridurne il livello di esposizione al rischio cyber. […] Quanto affermato passa per l’adozione tout court dei tre pilastri della cyber security moderna: sicurezza predittiva, preventiva, proattiva.

Bisogna implementare nel perimetro delle strutture un sistema di tecnologie e processi non solo in grado giocare “di risposta” agli attacchi, ma anche in grado di prevederli e anticiparli tramite l’utilizzo di sistemi quali la Threat Intelligence,[52] che sia associata all’expertise di un Centro operativo di sicurezza”.

Inquadramento giuridico: il reato informatico

Si è già potuto rimarcare, nello scorso capitolo, come la rivoluzione informatica abbia consentito la smaterializzazione della realtà fenomenica, con l’introduzione di oggetti privi di sostanza materiale (si pensi al semplice “dato” informatico), intangibili, componenti di una nuova e parallela realtà, quella virtuale.[53]

Tuttavia il progressivo ampliamento degli strumenti informatici e la loro capillare diffusione hanno presto, si è visto, provocato uno sviluppo patologico e distorto dei sistemi di informatizzazione, portando ad una evoluzione delle pratiche criminose: sono emerse molteplici forme delinquenziali nuove, tanto per le modalità di esecuzione, quanto per i beni materiali e giuridici coinvolti, divenendo sempre più urgente l’esigenza di sollecitare un intervento legislativo in materia di diritto penale dell’informatica.

Si avviarono di conseguenza primordiali riflessioni, ad opera di cultori del diritto, incentrate sulla possibile individuazione di nuovi beni giuridici prodotti direttamente dall’informatica, andando presto a delinearsi due orientamenti contrapposti. [54]

Secondo il primo indirizzo, assai diffuso in Europa, i nuovi delitti cibernetici non producevano inediti interessi meritevoli di tutela, bensì introducevano soltanto nuove modalità di aggressione di beni giuridici comunque preesistenti (per chiarire, secondo tale visione, la frode informatica altro non sarebbe che una truffa realizzata servendosi di un computer, e l’interesse aggredito rimarrebbe pur sempre, come per la truffa comune, il patrimonio). Tale corrente di pensiero mirava dunque a sostenere il cosiddetto “metodo evolutivo”, e cioè la necessità di introdurre singole disposizioni specifiche, riferite all’informatica, all’interno delle normative penali previgenti, impendendo così il ricorso a procedimenti interpretativi di tipo analogico, non consentiti in sede penale.

Diversamente, per il secondo indirizzo dottrinario, sviluppatosi per lo più nei Paesi anglosassoni, le nuove tecnologie determinavano il sorgere di nuovi interessi suscettibili di tutela ed era pertanto auspicato un intervento normativo ad hoc specifico e autonomo (seguendo il metodo delle cosiddetta “legge organica”), in grado di disciplinare separatamente dalle normative previgenti l’intero fenomeno criminale.[55]

Per comprendere quale indirizzo sia stato in concreto adottato nel nostro ordinamento, occorre dapprima volgere lo sguardo alla evoluzione normativa in materia di criminalità informatica, costituita da molteplici interventi legislativi fortemente condizionati da indicazioni di fonte sovranazionale.

Il legislatore italiano si è infatti mosso sulla spinta della Raccomandazione del Consiglio d’Europa del 1989 “Sur la criminalité en relation avec l’ordinateur” mirante a che i diversi Paesi instaurassero una stretta collaborazione per la repressione della criminalità informatica, in quanto sempre più contraddistinta da carattere sovranazionale. [56]

Essa proponeva inoltre alle Nazioni aderenti due liste di cybercrimes: una cosiddetta “lista minima” comprendente fattispecie la cui incriminazione, in virtù della loro diffusione e gravità era ritenuta obbligatoriamente necessaria (fra cui la frode informatica, l’accesso non autorizzato ad una rete o sistema, il danneggiamento di dati o programmi) ed una “lista facoltativa”, riguardante invece condotte punibili sulla base della discrezionalità rimessa a ciascun Paese, anche solo con strumenti di tipo amministrativo.

Il legislatore italiano ebbe così il giusto input per rivedere le proprie disposizioni penali in merito ai crimini informatici, dando forma, nello stesso anno, alla Commissione Callà, composta sia da giuristi che da esperti di informatica col fine di arrivare alla stesura di un compiuto disegno di legge, che fu approvato il 23 Dicembre 1993.

Tramite la sopradetta legge n. 547 del 1993 (“Modificazioni ed integrazioni alle norme del Codice penale e del Codice di procedura penale in tema di criminalità informatica”) si è potuto da un lato introdurre all’interno del codice penale nuove fattispecie delittuose (quali gli artt. 615-ter, quater e quinquies) e dall’altro modificare le fattispecie esistenti con il riferimento ai beni informatici (ad esempio, prevedendo che il delitto di attentato ad impianti di pubblica utilità, ex art. 420 c.p., riguardi anche l’ipotesi di danneggiamento o distruzione dei sistemi informatici o telematici di pubblica utilità o di dati in essi contenuti). [57]

Ne consegue allora come il legislatore italiano abbia optato per il metodo sopraricordato come “evolutivo”, ritenendo che le tecnologie informatiche vadano ad incidere sulle modalità di aggressione a beni giuridici o interessi che rimangono purtuttavia invariati, ossia già oggetto di tutela nelle diverse parti del codice. Rispetto dunque ad altri Paesi, quali gli Stati Uniti o la Francia, che differentemente hanno dedicato ai delitti informatici leggi ad hoc e titoli appositi all’interno dei rispettivi codici, in Italia le nuove norme sono state inserite in diverse parti del Codice penale, ciascuna vicino alla previgente norma ritenuta simile.

Da qui la distinzione dei fatti criminosi che possono essere commessi nel cyberspace in due diverse categorie: i reati informatici “in senso stretto”, che includono fattispecie che presentano espressamente, nella propria formulazione letterale, elementi descrittivi di modalità, oggetti, attività frutto della tecnologia informatica, ossia relativi a procedimenti di elaborazione automatizzata di dati (si pensi all’accesso abusivo “ad un sistema informatico o telematico”), ed i reati informatici “in senso lato”, dove vi rientrano invece fattispecie che, pur non tipizzando espressamente elementi di natura tecnico/informatica, comprendono anche i fatti criminosi commessi nel cyberspazio, costituendo essi semplici forme di aggressione a beni giuridici già tutelati da norme incriminatrici comuni (si pensi al reato di sostituzione di persona, integrato ad ogni modo qualora siano utilizzate le generalità di una diversa persona per creare un falso account tale da indurre taluno in errore).[58]

Ancora ulteriori riforme della legislazione penale sono state in seguito apportate dalla legge n. 48 del 2008, recante la “Ratifica ed esecuzione della Convenzione del Consiglio d’Europa sulla criminalità informatica, firmata a Budapest il 23 Novembre 2001 e norme di adeguamento dell’ordinamento interno”, per mezzo della quale sono state introdotte alcune modifiche allo stesso codice penale (con l’inserimento degli artt. 635-bis, 635-ter, 635-quater, 635-quinquies), al codice di procedura penale, e anche al D.Lgs n. 231/2001 prevedendo la responsabilità degli enti per un’ampia serie di reati informatici. [59]

Come evidenziato comunque nella relazione parlamentare relativa a suddetto disegno di legge “la portata dell’adeguamento normativo da realizzare nel settore del diritto penale sostanziale è risultata modesta, essendo in molti casi già in vigore una disciplina esaustiva, anzi addirittura più incisiva di quella richiesta dalle disposizioni della Convenzione di Budapest medesima”.

Si osservi in conclusione come, volendo contrastare fenomeni legati al funzionamento delle tecnologie, il legislatore debba necessariamente fare i conti con modalità, oggetti e comportamenti di natura squisitamente informatica, ossia elementi indubbiamente ardui da trasporre sul piano normativo.

Il rischio comunque è che l’individuazione di particolari modalità d’azione, volte a dar veste giuridica a determinati fatti criminosi informatici, possa risultare una tecnica di normazione inefficace: il costante aggiornamento delle tecnologie impiegate potrebbe cioè far cadere in rapida desuetudine le norme incriminatrici di settore, insuscettibili di essere aggiornate di pari passo con il celere sviluppo tecnologico.

Per tali ragioni, si è scelto di adottare una tecnica di tipizzazione che, pur impiegando nuove terminologie, non si concentra tanto sulla tecnologia utilizzata, quanto si focalizza più in generale sulle finalità perseguite, o ancora, sugli eventi realizzati. È così che lo strumentario di diritto sostanziale adottato nel nostro sistema penale sembra esser in grado di apprestare strumenti di qualificazione giuridica sempre attuali. [60]

L’accesso abusivo ad un sistema informatico o telematico

Si passi ora ad una breve rassegna delle disposizioni normative che più possono inquadrare giuridicamente le condotte di Data breach per come ivi descritte.

L’esigenza di perseguire l’accesso abusivo a sistemi informatici emerse già alla fine degli anni ’80 quando, precisamente nel 1989, suddetto reato fu inserito nella sopraricordata “lista minima” delle condotte informatiche abusive, proposta dal Consiglio d’Europa nella Raccomandazione sulla Criminalità Informatica, per poi esser così recepito nel Codice penale italiano con la legge n. 547 del 1993, seguendo l’approccio “old wine in new bottles”,[61] che contempla l’accostamento dei cybercrimes ai reati tradizionali.

Più nel dettaglio, con la legge 547/93 sono state introdotte all’interno della Sezione IV, capo III, del titolo XII del Codice penale, dedicata alla disciplina dei delitti contro l’inviolabilità del domicilio, tre disposizioni (gli artt. 615-ter, 615-quater, 615-quinquies) riguardanti, rispettivamente: l’accesso abusivo ad un sistema informatico o telematico, la detenzione e diffusione abusiva di codici di accesso a sistemi informatici o telematici, nonché la diffusione di programmi diretti a danneggiare o interrompere un sistema informatico.

Ebbene si parta dall’art 615-ter ragionando in primo luogo sulla sua collocazione normativa, ossia nella parte del codice penale per l’appunto riservata ai delitti contro la persona, ed in particolare, nella sezione dedicata alla tutela del domicilio, come a voler dire che il sistema informatico vada in qualche modo assimilato ad una privata dimora.[62]

Nella relazione accompagnante il disegno della citata legge del 1993, il legislatore riconosceva espressamente come i sistemi informatici e telematici rappresentassero ormai “una espansione ideale dell’area di rispetto pertinente al soggetto interessato” a cui, dunque, estendere la tutela della riservatezza della sfera individuale, così come garantito dall’art. 14 della Costituzione.[63]

In tal modo si sono mossi i primi passi verso la formulazione della nozione di “domicilio informatico”,[64] inteso proprio quale spazio ideale di pertinenza della persona (fisica o giuridica): i sistemi informatici e telematici, al pari del domicilio, rappresentano ambienti che devono rimanere riservati e conservati al riparo da ingerenze e intrusioni altrui, luoghi dunque inviolabili, delimitati da confini virtuali paragonabili a qualunque altro spazio privato, in cui un soggetto esplica liberamente la sua personalità in tutte le sue manifestazioni, ed esercita il proprio diritto allo ius excludendi alios.[65]

Di conseguenza l’art 615-ter (con una formulazione simmetrica rispetto all’art 614 c.p.[66]) punisce, nell’ipotesi base, con la pena della reclusione sino a tre anni, colui che si introduce abusivamente, o si mantiene contro la volontà espressa o tacita di chi ha diritto di escluderlo, in un sistema informatico o telematico protetto da misure di sicurezza.

Stando a tale disposizione risulta passibile di esser punito tanto chi senza esservi autorizzato (da qui il carattere della abusività[67]) entra nel sistema altrui, che il soggetto, pur autorizzato, il quale si mantiene nel sistema oltre i limiti temporali e le modalità consentite: si noti come in entrambi i casi si venga puniti anche se l’introduzione nel sistema non comporti danni o manomissioni, in quanto bene giuridico protetto dalla norma non pare essere l’integrità del sistema informatico o la riservatezza dei dati ivi contenuti, bensì, come poi confermato dalle pronunce dei giudici di legittimità,[68] risulta tutelato il domicilio informatico, quale luogo riservato, nonché estensione naturale del domicilio materiale. [69]

Così come avviene infatti per la violazione di domicilio, che si consuma quando un soggetto si introduce nell’abitazione altrui senza il permesso, la violazione di domicilio informatico, si realizza nel momento in cui un soggetto abusivamente acceda al sistema altrui, risultando ad ogni modo irrilevanti, ai fini della sussistenza del reato, punito a titolo di dolo generico, le finalità specifiche (quali trarre profitto dall’ottenimento di informazioni riservate, o cagionare danni) che abbiano soggettivamente motivato l’ingresso nel sistema, salvo una loro rilevanza per integrare diverse ed ulteriori fattispecie criminose.[70]

Chiaro è infatti, e lo si è potuto capire discorrendo dei casi di Data breach, come l’accesso abusivo sia solitamente prodromico alla realizzazione di reati più gravi, come il danneggiamento di sistemi informatici, nonché connesso alle ancora più frequenti richieste di pagamento di riscatti per ripristinare il sistema stesso violato.

Andando ad operare poi una analisi letterale della norma si aggiunga che una “introduzione”, penalmente rilevante, in un sistema si concretizzi mediante la lettura dei dati ivi contenuti, o eventualmente una loro copiatura:[71] tali condotte, assieme a quella del “trattenimento” nel sistema, devono avvenire invito domino, ossia contro la volontà del titolare del diritto all’esclusione.

Ancora, mentre l’art 614 c.p. consente di tutelare qualsiasi abitazione o privata dimora, l’art 615-ter tutela soltanto quei sistemi informatici o telematici che risultano “protetti da misure di sicurezza”, scelta questa non ampiamente condivisa dai commentatori, in quanto percepita da certi autori al pari di un “proteggo solo le abitazioni munite di una serratura antiscasso”, senza contare che rimangono diversi problemi interpretativi circa cosa si debba intendere per misura di sicurezza.

Parte della dottrina ritiene che non si tratti di mezzi di protezione del luogo ove trovasi il computer (si pensi a lucchetti, porte, guardiani), ossia le cosiddette misure di sicurezza fisico-materiali, bensì mezzi di protezione aventi ad oggetto direttamente ed esclusivamente il sistema informatico o telematico, ossia le cosiddette misure di sicurezza logico-tecniche (si pensi alle password, o alla cifratura dei dati)[72]. Altri, prendendo spunto dal fatto che si parli di misure di sicurezza al plurale, ritengono che una semplice parola chiave o un codice d’accesso non sarebbero sufficienti: le predette misure dovrebbero anzi essere intese come qualcosa di più complesso di una semplice password.[73]

Sembra comunque da preferire la tesi, accolta dalla giurisprudenza consolidata, secondo cui risulta sufficiente una qualunque misura di protezione, che sia anche banale e facilmente aggirabile, appunto perché la ratio sottesa all’inserimento di tale requisito è quella di richiedere un impegno effettivo, da parte dell’interessato, tenuto così a predisporre misure di sicurezza, quali elementi in grado di rendere esplicita e inequivoca all’esterno la propria volontà di riservare l’accesso solo a determinate persone.

Per quanto riguarda le non specificate nozioni di “sistema telematico ed informatico”, queste sono volutamente lasciate in forma aperta dal legislatore, affinché possano essere inquadrate di pari passo e correlatamente allo sviluppo tecnologico.[74]

Per ciò che propriamente attiene alle nozioni di tempus e locus commissi delicti, seguendo la dottrina maggioritaria, si tratterebbe di reato istantaneo, consumantesi nel momento stesso in cui l’agente non autorizzato accede al sistema (o di reato istantaneo ad effetto permanente nell’ipotesi in cui questi vi permanga), ed in quell’esatto luogo in cui è presente il cosiddetto “terminale periferico”, da cui il soggetto agente, quindi da remoto, digita le credenziali di autenticazione, esegue il login ed accede al sistema, superando le misure di sicurezza predisposte, risultando perciò assolutamente irrilevante il luogo fisico in cui si trova effettivamente il server centrale.[75]

In conclusione, si evidenzi come i commi secondo e terzo della norma in discorso contemplino alcune ipotesi aggravate, con rispettive sanzioni più severe, per quel che ivi interessa si noti come si abbia un incremento di pena qualora: dal fatto derivi la distruzione o il danneggiamento del sistema, o l’interruzione totale o parziale del suo funzionamento, ovvero la distruzione o il danneggiamento di dati, informazioni o programmi ivi contenuti; ed anche qualora i sistemi informatici o telematici in oggetto siano di interesse pubblico, quale chiaramente è il settore della sanità.[76]

La detenzione e diffusione abusiva di codici di accesso a sistemi informatici o telematici

Si è appreso come la riuscita di una intrusione in un sistema informatico dipenda in primo luogo dall’impiego di password e procedure d’accesso, passibili di essere rubate o scoperte con facilità.

Per tale ragione il legislatore è intervenuto in ottica preventiva, delineando una anticipazione della soglia della punibilità, configurando la fattispecie de quo quale reato di pericolo, ed andando così a sanzionare le condotte di detenzione e diffusione abusiva (ossia “illegittima”) di codici di accesso, quali condotte oggettivamente prodromiche ad una successiva indebita intrusione nei sistemi informatici medesimi.

L’art. 614-quater risulta di notevole ampiezza, dal momento che delinea alternativamente come illecite non solo le condotte del procurarsi, riprodurre (ossia duplicare o creare autonomamente), diffondere (divulgare in modo indifferenziato), comunicare (render noto ad un numero chiuso di soggetti), nonché consegnare codici d’accesso, ma altresì il fornire indicazioni tecniche riservate od istruzioni idonee a svelare il metodo attraverso cui si possano aggirare, neutralizzare o superare le barriere di accesso al sistema, così da coprire ogni sorta di comportamento che possa consentire a terzi di acquisire la possibilità di accedere abusivamente a sistemi informatici, anche solo implementandone il patrimonio di conoscenze.[77]

In tutti i casi delineati, ai fini della sussistenza del reato, risulta necessario che tali condotte siano rette dal dolo specifico, consistente nel fine di procurare a sé o ad altri un profitto o di arrecare ad altri un danno. Va richiamata a tal proposito la nozione ampia di “profitto”, elaborata dalla giurisprudenza per i reati contro il patrimonio, secondo cui tale vantaggio può essere anche di natura non strettamente patrimoniale (ad esempio qualora il soggetto agisca spinto da mero movente di soddisfazione morale).

Per quanto concerne poi il rapporto fra le due fattispecie incriminatrici agli art. 615-ter e 615-quater si è espressa recentemente la Corte di Cassazione, pronunciatasi per l’appunto su di un caso in materia di accesso abusivo a sistema informatico ed illecita acquisizione ed utilizzo di codici d’accesso.

Come spiegato nella pronuncia “I delitti di cui agli artt.. 615-ter e 615-quater sono posti a tutela del medesimo bene giuridico, ovvero il c.d. “domicilio informatico”, che l’art 615-quater protegge in misura meno ampia (ovvero limitatamente alla riservatezza informatica del soggetto) e l’art 615-ter più incisivamente, operando un più ampio riferimento al domicilio informatico tout court, quale spazio ideale di esclusiva pertinenza di una persona fisica o giuridica”.

La Suprema Corte ha enunciato così il principio di diritto secondo il quale, poiché il delitto di detenzione di codici d’accesso costituisce l’antecedente necessario del più grave reato di accesso abusivo a sistemi informatici, in caso di contestazione dei due delitti in riferimento al medesimo contesto spazio-temporale ed in danno dello stesso soggetto passivo, il primo reato dovrà considerarsi assorbito nella seconda e più grave fattispecie.[78]

Ancora, similmente a quanto previsto per l’accesso abusivo, anche l’art 615-quater, al suo secondo comma, prevede sanzioni più severe qualora il fatto sia posto a danno di un sistema informatico o telematico utilizzato dallo Stato, o da altro ente pubblico o da impresa esercente pubblici servizi o di pubblica necessità, oppure altresì quando venga commesso con abuso della qualità di operatore di sistema.

La ratio dietro all’ultima ipotesi aggravata sopra elencata si rinviene nel voler punire più severamente comportamenti illeciti di agevole commissione, dato che l’operatore di sistema, in ragione delle sue funzioni ed attività, si trova in una evidente posizione di vantaggio dal punto di vista attivo, avendo la possibilità di accedere al sistema, alle sue aree riservate e di controllarne le operazioni.

Si specifichi infine come vada considerato “operatore di sistema” non soltanto il tecnico che si trovi ad operare come programmatore o analista sull’hardware o sul software di un sistema informatico, ma anche qualsiasi soggetto che per le funzioni svolte si trovi ad intervenire su di questo stesso in forza di un titolo che glielo consente o glielo impone (si pensi ad un contratto per l’assistenza e/o manutenzione di un sistema informatico), volendosi sanzionare anche il tradimento della fiducia riposta dal titolare del sistema in chi professionalmente dovrebbe prendersene diligentemente cura.

La diffusione di programmi diretti a danneggiare o interrompere un sistema informatico

L’elemento soggettivo del dolo specifico e la ratio di anticipare la protezione dei sistemi informatici vanno a connotare anche la successiva norma, di cui all’art. 615-quinquies, disciplinante una delle condotte maggiormente pericolose per l’integrità dei sistemi informatici, quale è la divulgazione di programmi informatici aventi effetti distruttivi (ipotesi tipica sono i c.d. virus informatici, frequenti cause di alterazione e danneggiamento dei sistemi in cui riescono a diffondersi e riprodursi).

Si conceda una breve digressione, senza pretesa di completezza.

Il virus è un programma caratterizzato dalla possibilità di espandersi e riprodursi all’interno del software in cui è stato inserito, “infettando” altri programmi e compromettendone la funzionalità. È solitamente di dimensioni molto ridotte (da pochi byte ad alcuni kilobyte) ed è specializzato per eseguire soltanto poche e semplici operazioni impiegando il minor numero di risorse, in modo da rendersi il più possibile “invisibile”.

Un virus di per sé non è un programma eseguibile in maniera autonoma, per attivarsi invero necessita di un software ospite: il virus cioè inserisce una copia di se stesso nel file eseguibile, alterandolo, ed in questo modo quando un utente andrà a “lanciare” il programma infettato, dapprima verrà impercettibilmente eseguito il virus e poi, regolarmente, il programma stesso, e mentre dunque l’utente vedrà, ignaro, l’esecuzione del programma lanciato, non si accorgerà del fatto che il virus sia attualmente in esecuzione e stia compiendo tutte le varie operazioni contenute nel suo codice.

Programmi virus circolano in rete, come anche nei messaggi di posta elettronica, ma possono ugualmente essere contenuti in supporti esterni quali floppy disk, pen drive, cd-rom e dvd.

Sicuramente diverse possono essere le motivazioni sottostanti alla creazione e diffusione di programmi virus, dal comportamento semplicemente vandalico, a comportamenti di natura estorsiva, alla volontà di compromettere la funzionalità di sistemi informatici per ragioni concorrenziali o per interessi economici (si pensi a virus diffusi da tecnici informatici coscienti del fatto che vi sia la possibilità di esser chiamati a ripristinare l’efficienza del sistema).

Tornando alla norma de quo, anch’essa delinea una tutela preventiva, strutturandosi quale reato di pericolo astratto, dal momento che si prefigge di sanzionare condotte propriamente prodromiche rispetto ad un eventuale vero e proprio danneggiamento o malfunzionamento del sistema, che, laddove si realizzi, verrebbe tutt’al più punito ai sensi degli articoli 635-bis e seguenti.

Non vi è dubbio quindi che il reato si consumi anche se il programma nocivo non sia ancora stato inserito in alcun sistema informatico o non abbia ancora prodotto i suoi effetti, ma possieda in concreto le tipiche potenzialità distruttive, come nel caso di virus a tempo od attivazione collegata a particolari condizioni.[79] Suddetto arretramento della soglia di punibilità è determinato dal paradigma preventivo ad oggi dominante: se il fine del diritto penale è invero impedire eventi dannosi o pericolosi, è necessario anticipare la soglia della risposta punitiva allo stadio della realizzazione di atti idonei a determinare tali esiti infausti od addirittura a quella del presunto pericolo derivante da uno specifico comportamento.[80]

Altrettando ovvio è come tale operazione vada a collidere con l’assunto per il quale la sanzione maggiormente afflittiva della libertà personale dovrebbe sopraggiungere soltanto ove si accerti un fatto materiale connotato da reale disvalore e a condizione che non sia rintracciabile, nell’ordinamento giuridico nel suo complesso, un altro strumento in grado di arrecare efficace e pronta risposta al di fuori del diritto penale, dovendosi perciò tendenzialmente evitare i reati di mera disobbedienza e trovare rimedi giuridici alternativi per argine certe pratiche e comportamenti.

La disposizione in questione comunque, per come modificata ed ampliata dalla legge 48/2008, sanziona colui che abusivamente procura, detiene, produce, riproduce, importa, diffonde, comunica, consegna o in ogni altro modo mette a disposizione di altri apparecchiature, programmi, o dispositivi informatici vietati, il tutto allo scopo di danneggiare illecitamente un sistema informatico o telematico (o i dati ivi contenuti), ovvero di favorire l’interruzione, totale o parziale, od altresì l’alterazione del funzionamento del sistema medesimo.[81]

Si noti come per integrare la fattispecie criminosa possa bastare anche una consapevolezza ben minore del fine di distruzione o danneggiamento: a tal proposito infatti la Giurisprudenza di merito ha ritenuto sufficiente che vi sia l’accertata volontà dell’agente di diffondere il programma unita alla semplice consapevolezza dei suoi concreti effetti.

Opinioni discordanti in dottrina si registrano invece nei riguardi del bene giuridico protetto: secondo un primo orientamento la norma sarebbe posta a presidio del medesimo bene giuridico di cui agli artt. 615-ter e 615-quater, dotando così il domicilio informatico di una tutela rafforzata contro quelle condotte che, per la frequenza e la gravità dei danni che sono in grado di cagionare, rappresentano la minaccia maggiore alla sua integrità.[82]

Viceversa altri indirizzi di pensiero individuano il bene giuridico tutelato nella nozione di patrimonio (nella sua accezione di corretto funzionamento di un sistema informatico e di integrità dei dati ivi contenuti), in tal caso sarebbe stata allora più opportuna una collocazione sistematica della fattispecie all’interno del titolo XIII del codice penale (quale atto a disciplinare per l’appunto i delitti contro il patrimonio).[83]

In merito infine al rapporto fra l’art 615-quinquies e i reati informatici previamente trattati, si evidenzi come, in una sentenza di merito, si sia riscontrato il concorso proprio con l’art 615-ter di accesso abusivo ai sistemi informatici: il virus diffuso nel caso di specie aveva difatti consentito l’accesso ad un sistema informatico violandone le “barriere” protettive.[84]

Per quanto riguarda invece il rapporto con gli artt. 635-quater e quinquies (che verranno trattati nel dettaglio in seguito, in tema di attacchi ransomware), relativi al danneggiamento di sistemi informatici e telematici, ovvio è che vi sia una chiara interconnessione con la fattispecie de quo: in quest’ultima, quale reato di pericolo, le condotte previste verranno punite di per sé, prescindendo dalla verificazione del danno che, semmai, laddove in concreto realizzatosi verrà punito propriamente ex artt. 635- bis e 635-quater.

Si concluda sottolineando come i reati informatici sopra analizzati rientrino a tutti gli effetti fra i reati presupposto previsti dall’art 24-bis del D.lgs. del 2001 n. 231, per come modificato dalla legge 48/2008, ai fini della responsabilità penale degli enti: è stato infatti superato il principio per cui societas delinquere non potest ed è stato delineato come anche gli enti possano esser chiamati a rispondere dei reati posti in essere dai loro amministratori, dirigenti e dipendenti se realizzati nell’interesse o a vantaggio dell’ente medesimo.

All’esordio del suddetto del decreto legislativo (art. 1, comma II) si precisa tuttavia come le disposizioni in esso previste si applichino “agli enti forniti di personalità giuridica e alle società e associazioni anche prive di personalità giuridica”, precisando al terzo comma che saranno viceversa esclusi da tale disciplina “lo Stato, gli enti pubblici territoriali, gli altri enti pubblici non economici, nonché gli enti che svolgono funzioni di rilievo costituzionale”.

Di conseguenza, ed è il motivo per cui si è voluto inserire l’argomento in trattazione, la dottrina correttamente esclude dal novero dei possibili destinatari della disciplina anche altri soggetti giuridici di natura pubblica che, pur non esercitando pubblici poteri, non si ritiene opportuno possano esser destinatari delle sanzioni indicate nel decreto legislativo n. 231, fra cui si evidenziano: le Aziende ospedaliere e le Aziende sanitarie locali.[85]

Quindi sebbene il D.lgs. 231/2001 possa applicarsi a tutti i soggetti privati del comparto sanità, in quanto inevitabilmente rientranti nelle definizioni di “enti forniti di personalità giuridica/società e associazioni anche prive di personalità giuridica” (quali case di cura, cliniche private, società che gestiscono strutture ospedaliere etc.), le problematiche applicative affiorano nella disciplina relativa agli enti pubblici.

Così infatti la Corte di Cassazione, con la sentenza n. 28699/2010 ha chiarito che

Il tenore testuale della norma è inequivocabile nel senso che la natura pubblicistica di un ente è condizione necessaria, ma non sufficiente, all’esonero dalla disciplina in discorso, dovendo altresì concorrere la condizione che l’ente medesimo non svolga attività economica. [..] Ogni società, proprio in quanto tale, è costituita pur sempre per l’esercizio di un’attività economica al fine di dividerne gli utili”. Per cui, pensando alle Aziende sanitarie locali, queste ultime ai sensi dell’art 3 del D.lgs. 502/1992 risultano qualificabili come enti pubblici operanti secondo le norme del diritto privato ed agenti con il principio di pareggio di bilancio, non risultando pertanto caratterizzate da finalità lucrative dovranno ritenersi escluse dall’ambito applicativo della 231. Pur tuttavia, in ambito regionale la tendenza rimane quella di recepire la disciplina 231 in una ottica di prevenzione da reato, ed anche quale ulteriore garanzia della migliore organizzazione e trasparenza delle PA. [86]

Profili di interdisciplinarietà: il Codice Privacy

Chiaro è che, inevitabilmente, in caso di commissione di reati informatici, si vadano ad intersecare profili di interdisciplinarietà con il trattamento illecito dei dati personali, tanto che una qualsiasi organizzazione, sia essa titolare o responsabile del trattamento, davanti, ad esempio, ad un accesso abusivo al proprio sistema informatico, dovrà avviare indagini interne al fine di verificare se vi sia stata anche una effettiva compromissione dei dati personali ivi trattati ed eventualmente aprire la regolare procedura per la gestione dei casi di violazione dei dati ai sensi dei, già visti in precedenza, articoli 33 e 34 del Regolamento Ue 2016/679.

Tra le varie tipologie di attacchi informatici infatti ve ne sono diversi caratterizzati sovente da una condotta di osservazione, illecita, delle abitudini del soggetto targettizzato, volta ad acquisire il maggior numero di informazioni possibili, così difatti argomenta K. D. Mitnick, noto informatico e hacker statunitense trattando del valore nascosto delle informazioni: “qualunque tipo di informazione ha un suo valore economico, che sia poco utile o irrilevante, perché qualsiasi dato che entra in interconnessione con altri dati può consentire di risalire ad infinite informazioni sempre più importanti o significative”. [87]

È dunque naturale che, affrontando il tema dei reati informatici, vengano in rilievo anche nozioni quali la tutela e la disciplina in materia di riservatezza e protezione dei dati personali.

Si ripeta in questa sede che il Considerando 149, in combinato disposto con l’art. 84 del GDPR, sanciscano come i singoli Stati debbano stabilire le disposizioni concernenti le sanzioni penali applicabili per le violazioni del Regolamento Ue e delle norme nazionali attuative. Nel nostro ordinamento si è scelto così di mantenere in vigore quanto stabilito dal Codice della Privacy, emanato nel 2003, ed in particolare dagli articoli 167 e successivi, così come riformati dal d.lgs. n.101/2018.

Detta soluzione ha tuttavia restituito all’interprete un sistema caotico, ossia caratterizzato da continui rimandi tra normative eterogenee e da conseguenti problemi interpretativi nascenti dalla sovrapposizione di diverse fonti. Ne è scaturito cioè un corpus iuris connotato da sistemi sanzionatori disomogenei, passibili anche di entrare in conflitto fra loro, provocando un inevitabile vulnus ai principi di logicità, ragionevolezza, nonché al canone di proporzione[88]

Infatti, come si vedrà, la scelta di utilizzare norme penali in bianco per sanzionare comportamenti lesivi della privacy mal si concilia con i principi di tassatività e di determinatezza che dovrebbero invece caratterizzare i precetti penali. La tecnica del rinvio poi rischia non solo di estendere eccessivamente l’ambito di rilevanza penale a fatti che sarebbero privi di quel disvalore, ma soprattutto, porta con sé il rischio che il rimando a norme secondarie renda l’opera di interpretazione della condotta vietata di estrema difficoltà tanto per l’interprete, quanto soprattutto per il cittadino che, come noto, dovrebbe invece conoscere il precetto prima della possibile commissione del fatto di reato, con conseguenze negative in termini di certezza del diritto e della pena.[89]

Si faccia a questo punto riferimento ad una delle più importanti norme del diritto penale della privacy, ossia l’art. 167 del Codice in materia di protezione dei dati personali che al primo comma punisce colui che, titolare o responsabile del trattamento, al fine di trarre per sé o per altri profitto ovvero di arrecare danno all’interessato, “operando in violazione di quanto disposto dagli articoli 123[90], 126[91] e 130[92] o dal provvedimento di cui all’articolo 129[93] arreca nocumento[94] all’interessato”.

Ancora, ai sensi del secondo comma, è punito colui che, al fine di trarre per sé o per altri profitto ovvero arrecare danno all’interessato, “procedendo al trattamento dei dati personali di cui agli articoli 9 e 10 del Regolamento[95], in violazione delle disposizioni di cui agli articoli 2-sexies e 2-octies[96] o delle misure di garanzia di cui all’articolo 2-septies[97], arreca nocumento all’interessato”.

Come sopra anticipato, si tratta di una norma penale in bianco in quanto non contiene una descrizione esaustiva delle condotte vietate, ma anzi, per l’identificazione del precetto vietato, fa rinvio a molteplici altre norme del Codice privacy, stabilenti criteri di liceità di determinati trattamenti di dati personali, la cui violazione andrà ad integrare la fattispecie de quo.

Oltre a ciò, talvolta la condotta a cui la norma fa riferimento è addirittura contenuta in altre disposizioni di rango secondario e di futura emanazione, o in provvedimenti generali del Garante, con le evidenti conseguenze, di cui già si accennava, in termini di vulnus ai principi di tassatività e di determinatezza della fattispecie.

In conclusione si ricordi come uno dei principi cardine del diritto penale sia il ne bis in idem, ossia il divieto di esser sottoposti a processo, o di essere puniti due volte, per il medesimo fatto. Da qui discende il problema del coordinamento fra le conseguenze previste dal GDPR (ed il procedimento innanzi al Garante), con le conseguenze penali ed il relativo processo.

Tale coordinamento risulta in parte gestito proprio dai commi 4 e 5 della fattispecie in esame, i quali si preoccupano di delineare, in via generale, le modalità di collaborazione tra i due soggetti: Garante ed il Pubblico Ministero.

Si prevede infatti che sia il Pubblico Ministero, alla ricezione della notizia di reato di cui all’art. 167, ad informare senza ritardo il Garante, e che sia viceversa quest’ultimo, nell’ipotesi in cui nel corso delle proprie attività ispettive rinvenga elementi da cui si possa presumere sussistente il reato, a trasmettere la relativa documentazione raccolta al Pubblico Ministero. L’Autorità Garante comunque, in virtù dei poteri autorizzativi e di accertamento riconosciuti ex lege, potrà partecipare alle indagini della Pubblica Accusa e svolgerne delle proprie, al fine di raccogliere elementi di prova.

È come se l’Autorità assumesse il ruolo atipico di “coordinatore tecnico” delle indagini preliminari: al termine infatti della sua attività istruttoria dovrà redigere un parere motivato da indirizzare al Pubblico Ministero, la cui decisione in merito all’esercizio dell’azione penale sarà inevitabilmente influenzata. Entrambe le Autorità dovrebbero infine modulare le rispettive sanzioni, conformemente a quanto previsto dal Considerando 149 del Regolamento Ue e nel rispetto dello stesso ne bis in idem, ed in particolare al sesto comma viene prevista una riduzione della sanzione penale nel caso in cui sia già stata riscossa a carico dell’imputato una sanzione amministrativa pecuniaria.[98]

L’analisi dei data breach sanitari rivela un quadro allarmante: il settore healthcare risulta tra i più vulnerabili agli attacchi informatici, con conseguenze che vanno ben oltre il danno economico, compromettendo direttamente la sicurezza dei pazienti. Abbiamo esaminato come la protezione dei dati personali sanitari richieda un approccio integrato tra misure tecniche, organizzative e normative, evidenziando l’importanza del principio di accountability del GDPR.

Nel prossimo capitolo approfondiremo specificamente gli attacchi ransomware, la tipologia di cyberattacco più devastante per il settore sanitario, analizzando le modalità di prevenzione e risposta a queste minacce sempre più sofisticate. Per una comprensione completa del fenomeno, scarica il white paper di Maria Vittoria Zucca dal titolo “La cybercriminalità nel settore sanitario: anamnesi, diagnosi e prognosi di una ‘patologia’ informatica”.

Fonti:

[1] Per ICT (acronimo di Information ad Communications Technology) si intendono tutti i processi e le pratiche connesse alla trasmissione, ricezione ed elaborazione dei dati e delle informazioni.

[2] Per una sua approfondita analisi si rimanda al Rapporto Clusit 2020 sulla sicurezza ICT in Italia reperibile al sito internet https://clusit.it/

[3] Commissione Europa, Alto Rappresentante dell’Unione per gli affari esteri e la politica di sicurezza, Comunicazione congiunta al Parlamento e al Consiglio: Resilienza, deterrenza e difesa: verso una cibersicurezza forte per l’UE, Bruxelles, 13 Settembre 2017.

[4] E. Macrì, “Il quadro giuridico del cyber risk”, in Capire il rischio cyber: il nuovo orizzonte in sanità, whitepaper SHAM Italia, 2021, pp. 15 – 22.

[5] Ponemon Institute, Cyber Insecurity in Healthcare: The Cost and Impact on Patient Safety and Care, 2022.

[6] Un attacco alla supply chain (chiamato anche attacco di terze parti) avviene quando l’aggressore accede alla rete di un’azienda tramite una terza parte fornitrice. Questo tipo di attacco necessita di un software o di una singola applicazione compromessa per diffondere il malware nell’intera catena di fornitura. Di solito prende di mira il codice sorgente di un’applicazione, inserendo così il proprio codice dannoso nel sistema.

[7] Per spoofing ci si riferisce all’impersonificazione da parte di un hacker di un altro dispositivo o di un altro utente su una rete al fine di impadronirsi di dati, diffondere malware o superare dei controlli di accesso.

[8] Per phishing si intende quel tipo di attacco che consiste nell’inviare e-mail malevoli scritte appositamente con lo scopo di spingere le vittime a cadere nella trappola dei cybercriminali. Spesso lo scopo infatti è di portare gli utenti a rivelare informazioni bancarie, credenziali di accesso o altri dati sensibili.

[9] Ponemon Institute, op. citata supra a nota 117, p. 11

[10] Ponemon Institute, op. citata supra a nota 93, p. 5

[11] A. Gelpi, “La Sicurezza dei dati sanitari”, in Torino Medica. La rivista dell’ordine dei medici chirurghi e odontoiatri della provincia di Torino, anno XXXIII, numero 3-4, 2021, pp. 11-21.

[12] S. Warren, L.D. Brandeis, “The right to Privacy”, in Harvard Law Review, Vol. 4, No. 5, 1890, pp.193-220.

[13] P. Rescigno, Diritti della personalità, Enc. Giur. Treccani, Roma, 1994.

[14] S. Rodotà, Il mondo nella rete. Quali i diritti, quali i vincoli, Laterza-la Repubblica, Roma-Bari, 2014, pp. 27-32

[15] S.B. Barnes, “A privacy paradox: Social networking in the United States”, in First Monday, Issue 11/9, 2006.

[16] Intervento di A. Soro, Presidente dell’autorità Garante per la protezione dei dati personali, Big Data: La nuova geografia dei poteri, in occasione della Giornata Europea della protezione dei dati personali, 30 Gennaio 2017.

[17] Per un dettagliato approfondimento sul tema si rimanda a N. Lugaresi, Internet, privacy e i pubblici poteri negli Stati Uniti, Giuffrè editore, Milano, 2000.

[18] F. Carlino, “L’origine della privacy e l’esigenza di tutelare i dati personali”, in Iusinitinere, Rivista Semestrale di diritto, ISSN 2724-2862, 4 Luglio 2020, aggiornato 13 Luglio 2020, pp. 1-13.

[19] G. Finocchiaro, Il nuovo regolamento europeo sulla privacy e sulla protezione dei dati personali, Zanichelli editore, Bologna, 2017, p. 6.

[20] G. Fornari, Il trattamento dei dati: rischi penali e compliance dell’impresa, Fornari e Associati studio legale, Milano-Roma, Gennaio 2021, p 2-4.

[21] Si pensi, in particolare, alla proposta di Regolamento del Parlamento europeo e del Consiglio che stabilisce regole armonizzate sull’intelligenza artificiale, del 21 Aprile 2021.

[22] Con tale locuzione si indica una ingente mole di dati informatici, le cui caratteristiche sono facilmente riassumibili seguendo il modello delle tre “V”: Volume (grande quantità), Velocità (di generazione dei dati e della loro elaborazione) e Varietà (forte eterogeneità).

[23] G. Fioriglio, “La protezione dei dati sanitari nella Società algoritmica. Profili informatico-giuridici”, in Journal of Ethics and Legal Technologies, Volume 3(2), Novembre 2021, pp. 85-86.

[24] “La Repubblica tutela la salute come fondamentale diritto dell’individuo e interesse della collettività, e garantisce cure gratuite agli indigenti. Nessuno può essere obbligato a un determinato trattamento sanitario se non per disposizione di legge. La legge non può in nessun caso violare i limiti imposti dal rispetto della persona umana”.

[25] “La Repubblica riconosce e garantisce i diritti inviolabili dell’uomo, sia come singolo sia nelle formazioni sociali ove si svolge la sua personalità, e richiede l’adempimento dei doveri inderogabili di solidarietà politica, economica e sociale”.

[26] F. Carlino, “il trattamento dei dati sanitari mediante il dossier sanitario”, in Iusinitinere, Rivista Semestrale di diritto, ISSN 2724-2862, 29 Maggio 2020, pp. 1-3.

[27] Intervento di A. Soro, Presidente del Garante per la protezione dei dati personali, al convegno “La smaterializzazione dei documenti e il suo impatto sul sistema salute”, Roma 6 Maggio 2016.

[28] Ex art. 4 n.7 GDPR per titolare del trattamento di intende “la persona fisica o giuridica, l’autorità pubblica, il servizio o altro organismo che, singolarmente o insieme ad altri, determina le finalità e i mezzi del trattamento di dati personali”.

[29] A partire dal 1 Luglio 2021, la notifica di una violazione di dati personali deve essere inviata al Garante tramite apposita procedura telematica, resa disponibile nel portale dei servizi online dell’Autorità.

[30] Ex art. 4 n.8 GDPR per responsabile del trattamento si intende “la persona fisica o giuridica, l’autorità pubblica, il servizio o altro organismo che tratta dati personali per conto del titolare del trattamento”.

[31] L’European Data Protection Board ha fissato dei parametri per la valutazione dei fattori che determinano il rischio per le libertà e i diritti degli interessati, tra cui rientrano: il tipo di “breach”, ossia il tipo di violazione; la natura, numero e grado di sensibilità dei dati personali violati; la facilità di associare i dati violati alla persona fisica; la gravità delle conseguenze per gli interessati ed il numero degli interessati esposti al rischio.

[32] L. Smoraldi, M. Strazzullo, “Prevenire è meglio che curare: il compito dell’avvocato in caso di data breach”, in Data Protection Law: diritto delle nuove tecnologie, privacy e protezione dati personali – Rivista online Giuridica Semestrale, n. 2, 2021, p. 73.

[33] Intervento di Luca Bolognini, Presidente dell’Istituto italiano per la privacy, avvocato ICT Legal Consulting, al Convegno Privacy Unolegal , Milano, 14 Giugno 2017.

[34] E. Limone, “Sanità digitale: scenari scatenati da un data breach”, in Agendadigitale.eu, Editore ICT&Strategy, Gruppo Digital360, Milano, 1 Luglio 2019.

[35] Indipendent Security Evaluators, Securing Hospitals: a research study and blueprint, 23 February 2016, p.39

[36] Cass. Civ, sez. I, sentenza 12 Novembre – 31 Dicembre 2020, n. 29982.

37] Per bonifica informatica si intende quel procedimento tramite cui si evidenziano intromissioni illecite all’interno di un sistema informatico.

[38] C. Telmoni (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.

[39] Intervista a Agostino Ghiglia, componente del Garante per la protezione dei dati personali, “La sanità la più colpita. Proteggere reti e dati sensibili”, di Luigi Garofalo, 9 Novembre 2021.

[40] Il termine dark web indica un insieme di contenuti e servizi della Rete nascosti ai motori di ricerca, necessitanti di appositi programmi per essere raggiunti.

[41] Intervista ad Antonello Soro, presidente dall’Autorità Garante per la privacy dei dati personali, “Il Garante: un caso di straordinaria gravità”, riportata sul Corriere della Sera – Ed. Bergamo, 31 Ottobre 2013, di G. Ubbiali

[42] Si noti come CISO sia l’acronimo di Chief Information Security Officer.

[43] R. McElroy, T. Kellermann, Healthcare Cyber Heists in 2019: 20 leading CISOs from the healthcare industry offer their perspective on evolving cyberattacks, ransomware & the biggest concerns to their organizations, Carbon Black, June 2019.

[44] Per island hopping si intende una tecnica di attacco informativo utilizzata dagli hacker per infiltrarsi nella rete informatica di una azienda sfruttando le strutture satellite, ossia tante organizzazioni più piccole e con standard di sicurezza IT maggiormente vulnerabili rispetto all’obiettivo principale. Ecco che, bucando la rete informatica del fornitore, l’hacker riesce a risalire fino alla rete dell’azienda target principale.

[45] N. Griffin, Health correspondent, “Patient data 10-15 times more valuable than credit card data”, in Irish Examiner, May 19 2021.

[46] Per ulteriori immagini esemplificative si rimanda al report di Trend Micro, Cybercrime and Other Threats Faced by the Healthcare Industry, Mayra Rosario Fuentes Forward-Looking Threat Research (FTR) Team, 2017, pp.13-17

[47] Intervento Prof. Matteo Bonfanti, al convegno “Cybersecurity e protezione dei dati personali nella sanità: un nodo strategico per l’interesse nazionale”, Fondazione ICSA in partnership con Link Campus University, 16 Giugno 2022.

[48] V. Franzellitti, G. Cavalcanti, intervista a Roberto Setola dell’Università Campus Bio-Medico di Roma durante la seconda giornata del convegno “Big Data in Health”, riportata in Sanità Informazione, 3 Ottobre 2019.

[49] Notizia riportata sui giornali locali quali Padovaoggi, “Attacco hacker Ulss 6 Euganea, pubblicati oltre 9.300 documenti”, 16 Gennaio 2022.

[50] Comunicato stampa relativo all’azienda Ulss n. 6 Euganea, 15 Gennaio 2022, Padova.

[51] Intervista a Pierguido Iezzi, pubblicata il 14.05.2022, ad opera di Massimo Canorro, sul quotidiano sanitario nazionale Nurse24.

[52] Per Cyber Threat Intelligence (CTI) si intende una attività di raccolta di informazioni provenienti da varie fonti, in merito ad attacchi informatici che colpiscono o sono potenzialmente in grado di offendere la sicurezza di una organizzazione. Tale patrimonio conoscitivo acquisito viene poi utilizzato per attuare consapevolmente strategie ed azioni utili alla prevenzione, alla mitigazione e all’eradicazione della minacce, a partire da una corretta valutazione dei rischi.

[53] T. Pietrella, “Reati informatici e concorso di norme: come l’evoluzione tecnologica informa il diritto penale. Il caso delle Botnets”, in Discrimen – Rivista di diritto penale, ISSN 2704-6338, 2.12.2021, pp. 2-7.

[54] P. Galdieri, “Il reato informatico”, in G. Marotta (a cura di), Tecnologie dell’informazione e comportamenti devianti, Edizioni Universitarie di Lettere Economia Diritto, Milano, 2004 , pp. 29-74.

[55] V. Frosini, Contributi ad un diritto dell’informazione, Liguori, Napoli, 1991, pp. 165 ss.

[56] Comitato dei Ministri del Consiglio d’Europa, Raccomandazione Sur la criminalité en relation avec l’ordinateur, 13 Settembre 1989.

[57] Legge 23 Dicembre 1993, n. 547, Modificazioni ed integrazioni alle norme del Codice penale e del Codice di procedura penale in tema di criminalità informatica.

[58] R. Flor, D. Falcinelli, S. Marcolini, La giustizia penale nella “rete”: le nuove sfide della società dell’informazione nell’epoca di Internet, Edizioni DiPlaP, Milano, 2015, p. 101.

[59] Legge 18 Marzo 2008, n.48, “Ratifica ed esecuzione della Convenzione del Consiglio d’Europa sulla criminalità informatica, fatta a Budapest il 23 Novembre 2001, e norme di adeguamento dell’ordinamento interno”.

[60] E. Albamonte, “Il reato informatico nella prassi giudiziaria: le linee guida internazionali per il contrasto ai nuovi fenomeni criminali”, in Rivista Elettronica di Diritto, Economia, Management, n.3, 2013, p.146-157.

[61] S. Brenner, “Defining cybercrime: a review of state and federal Law”, in R.D. Clifford, Cybercrime: The investigation, prosecution of a computer-related crime, Carolina Academic Press, Durham, 2006, pp. 15-104.

[62] Il domicilio, nel diritto privato italiano, corrisponde ex art. 43 c.c al luogo in cui una persona “ha stabilito la sede principale dei suoi affari ed interessi” , per tali intendendosi tanto quelli di natura personale, quanto quelli di natura sociale, politica ed economica.

[63] Art. 14 Cost. “Il domicilio è inviolabile. Non vi si possono eseguire ispezioni o perquisizioni o sequestri, se non nei casi e modi stabiliti dalla legge secondo le garanzie prescritte per la tutela della libertà personale”.

[64] L. Levita, “La disciplina sostanziale: i reati informatici in senso stretto”, in G. D’aiuto (a cura di) I reati informatici: disciplina sostanziale e questioni processuali, Giuffrè Editore, 2012, pp. 3

[65] Cfr. Cass. Pen. Sezioni Unite, Sentenza 26 Marzo 2015, n. 17325.

[66] Art 614 c.p. “Chiunque s’introduce nell’abitazione altrui, o in un altro luogo di privata dimora, o nelle appartenenze di essi, contro la volontà espressa o tacita di chi ha il diritto di escluderlo, ovvero si introduce clandestinamente o con l’inganno, è punito con la reclusione da uno a quattro anni”.

[67] Secondo alcuni autori l’espressione in parola sarebbe del tutto superflua e non aggiungerebbe nulla sotto il profilo interpretativo, poiché utilizzata al solo fine di far virare l’attenzione sull’antigiuridicità della condotta (Cfr. C. Piergallini, “I delitti contro la riservatezza informatica” C. Piergallini, F. Viganò, M. Vizzardi, A. Verri (a cura di) in Delitti Contro la persona, CEDAM, Padova, 2015, pag. 770). La stessa Corte di Cassazione ha criticato la locuzione “abusivamente si introduce” per la sua “forte ambiguità e la conseguente possibilità d’imprevedibili e pericolose dilatazioni della fattispecie penale se non intesa in senso di accesso non autorizzato”, Cass. Sez. V 17 Gennaio 2008 n. 2534.

[68] Cfr. Cass. Sez. V, 26 Ottobre 2012, n. 42021; Sez. V, 31 Marzo 2016 n. 13057.

[69] C. Domenicali, “Tutela della persona negli spazi virtuali”, in Federalismi.it Rivista di diritto pubblico italiano, comparato, europeo, ISSN 1826-3534, n. 7, 28 Marzo 2018, pp. 10-14.

[70] Sul dolo generico richiesto si rimanda alla pronuncia della Cassazione sent. 2012, n. 4694 secondo cui integra il delitto ex art. 615-ter c.p.: “La condotta di colui che, pur essendo abilitato, acceda o si mantenga in un sistema informatico o telematico protetto, violando le condizioni e i limiti risultanti dal complesso delle prescrizioni impartite dal titolare del sistema per delimitarne oggettivamente l’accesso, rimanendo invece irrilevanti, ai fini della sussistenza del reato, gli scopi e le finalità che abbiano soggettivamente motivato l’ingresso nel sistema”.

[71] Cfr. Cass. Pen. Sez. V, 8 Luglio 2008, n. 37322, secondo cui il termine “accesso” deve intendersi non come collegamento fisico, ma logico: un superamento cioè della barriera di protezione del sistema che rende possibile il dialogo col medesimo, di modo che l’agente venga a trovarsi nella condizione di conoscere dati, informazioni e programmi.

[72] R. Borruso, “La tutela del documento e dei dati”, in R. Borruso, G. Buonomo, G. Corasaniti, G. D’Aietti (a cura di), Profili penali dell’informatica, Giuffrè Editore, Milano, 1994, p.29 ss.

[73] G. Ceccacci, Computer Crimes: la nuova disciplina dei reati informatici, FAG, Milano, 1994, pag.70.

[74] Secondo la Convenzione Europea di Budapest sulla Criminalità informatica, stipulata il 23 Novembre 2001 “computer system means any device or a group of interconnected or related devices, one or more of which, pursuant to a program, performs automatic processing of data”.

[75] Cfr. Cass. Sez. Un., sent. 26 Marzo 2015, n. 17325.

[76] Secondo la Cass. Pen. Sez. V, 21 Gennaio 2011, n. 1934 per aversi “sistema informatico di interesse pubblico” non è sufficiente la qualità di concessionario di pubblico servizio rivestita dal titolare del sistema, dovendosi accertare se il sistema stesso si riferisca ad attività direttamente rivolte al soddisfacimento di bisogni generali della collettività.

[77] G. Amato, V. Sandro Destito, G. Dezzani, C. Santoriello, I reati informatici, CEDAM, La biblioteca del penalista, Milano, 2010, pp. 89-96.

[78] Cfr. Cass., Sez. II, Sent. 14/01/2019, n. 21987: “L’art 615quater, in quanto destinato a reprimere condotte prodromiche alla possibile realizzazione del delitto di accesso abusivo ad un sistema informatico o telematico, protetto da misure di sicurezza, e, quindi, pericolose per il bene giuridico tutelato dall’art. 615ter c.p., si atteggia quale necessarioantefatto di detto reato, la cui latitudine lesiva sotto un profilo naturalistico necessariamente le presuppone e ricomprende”.

[79] L. Cuomo. R. Razzante, La nuova disciplina dei reati informatici, Giappichelli, 2009, p.129.

[80] M. Donini, Il volto attuale dell’illecito penale. La democrazia penale tra differenziazione e sussidiarietà, in A. Bernardi, M. Donini, V. Militello, M. Pasa, S. Seminara (a cura di), Collana quaderni di diritto penale comparato, Internazionale ed Europeo, Milano, Giuffrè editore, 2004, p. 104 ss.

[81] Secondo App. Bologna Sez. II, 27 Marzo 2008, sussiste il concetto di “alterazione” di un programma informatico quando lo si manipoli in maniera tale che compia azioni non volute dall’utente, ovvero si modifichino i parametri di funzionamento, anche secondo opzioni e possibilità previste nel programma stesso, contro la volontà dell’utilizzatore.

[82] P. Galdieri, Teoria e pratica nell’interpretazione del reato informatico, Giuffrè editore, Milano, 1997.

[83] G. Pica, Diritto penale delle tecnologie informatiche, UTET, Torino, 1999; F. Mantovani, Diritto penale. Parte Speciale: I, CEDAM, Torino, 2014.

[84] Trib. Bologna, Sez. I Monocratica, Sent. 21 Luglio 2005, n. 11577.

[85] C. Pecorella, “Principi generali e criteri di attribuzione della responsabilità”, In A. Alessandri & al. (a cura di), La responsabilità amministrativa degli enti. D. lgs. 8 giugno 2001 n. 231, Milano, pp. 65-89.

[86] Così ad esempio la Regione Lombardia ha inteso mutuare i principi 231 ai fini dell’introduzione del Codice Etico e dell’implementazione del Modello Organizzativo nelle Aziende Sanitarie Locale ed Ospedaliere, formulando linee guida per l’analisi del rischio.

[87] F. Peluso, La responsabilità nei nuovi reati informatici. Mezzi di ricerca e acquisizione della prova, Maggioli Editore, Gennaio 2020, p. 180.

[88] M. Solinas, “Tutela penale della privacy dopo il Gdpr: la frettolosa giustapposizione delle fonti è scaturigine di un sistema farraginoso che crea confusione, in Responsabilità Civile e Previdenza, fasc. 2, Vol. 85, 1 Gennaio 2020, pp. 663-688.

[89] P. Balboni, F. Tugnoli, “Reati informatici e tutela dei dati personali: profili di responsabilità degli enti”, in Giurisprudenza Penale, 2021/1-bis , pp. 3-8.

[90] L’art. 123 disciplina le modalità con le quali risulta lecito, secondo il codice privacy, il trattamento dei dati di traffico.

[91] L’art 126 si occupa di disciplinare il trattamento dei dati di ubicazione.

[92] L’art 130 disciplina le c.d. “comunicazioni indesiderate” (si pensi alle comunicazioni di marketing).

[93] Ex art. 129 “Il Garante individua con proprio provvedimento, […] le modalità di inserimento e di successivo utilizzo dei dati personali relativi ai contraenti negli elenchi cartacei o elettronici a disposizione del pubblico”.

[94] Secondo Cass. Sez. 3, n. 40103 del 05/02/2015, per nocumento si deve intendere “una concreta lesione della sfera personale o patrimoniale, direttamente riconducibile ad una operazione di illecito trattamento dei dati protetti”.

[95] Il riferimento è al trattamento di particolari categorie di dati personali (che rivelino ad esempio origine razziale o etnica, opinioni politiche, ma anche dati biometrici e genetici).

[96] Si riferiscono al trattamento di categorie particolari di dati personali, necessario per motivi di interesse pubblico rilevante (si pensi ai dati relativi a condanne penali e reati).

[97] Si intendono le misure di garanzia per il trattamento di dati genetici, biometrici e relativi alla salute.

[98] L. Bolognini, E. Pelino, Codice privacy: tutte le novità del D.lgs. 101/2018, Giuffrè Editore, Milano, 2019.

https://www.ictsecuritymagazine.com/articoli/data-breach-sanitari/

Il Red Report 2026 di Picus Labs, pubblicato il 10 febbraio 2026, non è il solito bollettino annuale sulle minacce. È un referto autoptico su un modello di attacco che ha dominato un decennio – il ransomware distruttivo – e la certificazione della nascita di qualcosa di più insidioso: il parassita digitale.

Il dataset parla con una chiarezza che lascia poco spazio alle interpretazioni. Picus Labs ha analizzato 1.153.683 file unici, di cui il 94% classificato come malevolo, mappando oltre 15,5 milioni di azioni avversarie sul framework MITRE ATT&CK. Il risultato è una radiografia completa del comportamento offensivo nel 2025, e ciò che emerge rovescia le priorità difensive di migliaia di organizzazioni.

Il dato che definisce l’intero Red Report 2026 è questo: la tecnica “Data Encrypted for Impact” (T1486) – la firma operativa del ransomware – è crollata del 38%, passando dal 21% dei campioni nel 2024 al 12,94% nel 2025. Contemporaneamente, l’80% delle dieci tecniche MITRE ATT&CK più diffuse è ora dedicato a evasione delle difese, persistenza e comando e controllo stealth. La concentrazione più alta di tradecraft stealth mai registrata in sei edizioni del report.

Come ha sintetizzato il Dr. Süleyman Özarslan, co-fondatore e VP di Picus Labs: gli attaccanti hanno capito che è più redditizio abitare l’host che distruggerlo.

Nota metodologica: il Red Report 2026 è prodotto da Picus Security, vendor specializzato in security validation. Questo non ne diminuisce il valore analitico – il dataset di oltre un milione di campioni e la mappatura su MITRE ATT&CK rappresentano uno dei corpus empirici più ampi disponibili sul comportamento avversario – ma è un elemento che il lettore professionista deve considerare nel valutare le raccomandazioni operative, che naturalmente convergono verso l’approccio di validazione continua propugnato dall’azienda.

Dal predatore al parassita: anatomia di un cambio di paradigma

Per comprendere la portata di questo cambiamento, occorre partire da una premessa spesso dimenticata: il ransomware tradizionale – quello che cifra i file e chiede un riscatto – è sempre stato, dal punto di vista dell’attaccante, un modello ad alto rischio e rendimento decrescente.

L’encryption è rumorosa. Attiva alert, mobilita incident response, scatena comunicazioni di crisi. E soprattutto, negli ultimi anni, ha perso la sua leva principale: i backup. Man mano che le organizzazioni hanno investito in strategie di recovery, la capacità del ransomware di estorcere pagamenti si è erosa.

I dati convergono da fonti indipendenti: Chainalysis ha stimato che nel 2025 solo il 28% delle vittime identificate ha pagato un riscatto, in netto calo rispetto al 62,8% del 2024 e al 78,9% del 2022. I pagamenti on-chain si sono attestati intorno a 820 milioni di dollari, in calo dell’8% rispetto all’anno precedente. Coveware, da un campione diverso e con metodologia differente, riporta percentuali ancora più basse: il 23% nel Q3 2025, con un crollo al 19% per gli incidenti di sola esfiltrazione dati senza cifratura. Le percentuali esatte variano tra le fonti perché coprono campioni e periodi diversi, ma la direzione del trend è univoca e confermata da tutti gli analisti di settore.

Il Red Report 2026 documenta la risposta strategica degli attaccanti a questa crisi di redditività: l’abbandono dell’encryption a favore di ciò che Picus Labs definisce “residenza silenziosa”. Invece di cifrare e fare rumore, il malware moderno si insedia nei sistemi, si mimetizza tra i processi legittimi e opera sotto la soglia di rilevamento per settimane o mesi. L’obiettivo non è più bloccare le operazioni della vittima, ma alimentarsi di credenziali, dati sensibili e accessi privilegiati senza essere scoperto.

È la logica del parassita biologico: l’organismo che uccide il proprio ospite ha vita breve. Quello che lo sfrutta senza ucciderlo prospera.

L’evoluzione in numeri: Red Report 2025 vs Red Report 2026

Prima di analizzare i tratti del parassita digitale, vale la pena inquadrare l’evoluzione anno su anno. Il confronto tra le due edizioni del report rivela una trasformazione accelerata.

Il Red Report 2025, basato su oltre 1 milione di campioni e 14 milioni di azioni malevole mappate su ATT&CK, aveva già identificato l’ascesa degli infostealer e delle campagne multi-stadio come tendenza dominante, con un aumento triplicato del malware mirato ai credential store (T1555 passato dall’8% al 25%). Picus Labs aveva coniato la metafora del “colpo perfetto” (The Perfect Heist) per descrivere campagne di esfiltrazione sofisticate e silenziose.

Il Red Report 2026 segna il passaggio dalla tendenza al paradigma consolidato. La T1555 si stabilizza al 23,49% – un livello ormai strutturale – mentre il calo della T1486 (encryption) dal 21% al 12,94% certifica che il furto di credenziali non è più un complemento al ransomware: lo sta sostituendo come tecnica primaria di monetizzazione. Le tecniche di evasion e persistence sono passate dall’essere “in crescita” (2025) a rappresentare l’80% della top 10 (2026), il dato più alto mai registrato.

In altri termini, ciò che nel 2024 era un segnale debole, nel 2025 era una tendenza, e nel 2026 è il modello operativo dominante. Il Red Report 2026 di Picus Labs cattura il momento in cui la curva si è piegata in modo irreversibile.

Le sei caratteristiche del parassita digitale

Il Red Report 2026 identifica sei tratti comportamentali che definiscono il malware moderno e lo distinguono dalle generazioni precedenti. Non si tratta di tendenze vaghe, ma di pattern empirici osservati su oltre un milione di campioni.

1. Process Injection come mimetismo molecolare

La Process Injection (T1055) si conferma per il terzo anno consecutivo la tecnica più diffusa, presente nel 30% dei campioni analizzati. Il suo scopo è elementare e devastante: iniettare codice malevolo all’interno di processi legittimi e affidabili del sistema operativo. Una volta che il codice dell’attaccante vive dentro un processo di sistema come svchost.exe o explorer.exe, distinguere l’attività malevola da quella legittima diventa un problema di analisi comportamentale che la maggior parte degli strumenti basati su firme non riesce a risolvere.

La persistenza di questa tecnica in cima alla classifica per tre anni consecutivi racconta una storia precisa: le difese non riescono a tenere il passo. Finché la process injection resta dominante, significa che funziona – e funziona perché le organizzazioni non validano abbastanza i propri controlli contro questa specifica classe di attacco.

2. Il malware che fa matematica

Il Red Report 2026 documenta per la prima volta un comportamento inedito: campioni di malware come LummaC2 utilizzano la trigonometria – calcolando la distanza euclidea e gli angoli dei movimenti del mouse – per distinguere un utente umano da una sandbox automatizzata. Se il mouse si muove in linea retta, tipico dell’input programmato nelle sandbox, il malware riconosce di essere osservato e rifiuta di attivarsi. Se il movimento è irregolare e curvilineo, come quello di un essere umano, il malware si innesca.

Questo è un salto qualitativo nella sofisticazione dell’evasione. Non si tratta più di controllare la presenza di file di sistema, analizzare il numero di CPU disponibili o verificare chiavi di registro associate a macchine virtuali – tecniche ormai note e spesso simulate dalle sandbox moderne. Si tratta di analizzare il comportamento fisico dell’operatore attraverso modelli geometrici, portando l’evasione a un livello che richiede sandbox con simulazione biometrica convincente per essere superato.

3. Sandbox Evasion al quarto posto

La tecnica di Virtualization/Sandbox Evasion (T1497) è esplosa fino alla quarta posizione nella classifica delle tecniche più diffuse, comparendo in circa il 20% degli attacchi osservati. Il fenomeno del “fingersi morto” – il malware che resta dormiente finché non è sicuro di non essere analizzato – è diventato una precondizione operativa standard per il malware moderno.

L’implicazione per i difensori è diretta: le sandbox tradizionali, pilastro dell’analisi dinamica del malware, stanno perdendo efficacia. Un campione che decide di non detonare in ambiente controllato appare benigno – e viene rilasciato negli ambienti di produzione dove poi si attiva. Questo impone una revisione delle strategie di detonazione, includendo sandbox con interazione umana simulata, analisi comportamentale post-deployment e validazione continua dei controlli di prevention.

4. Credenziali come chiave d’accesso permanente

Il furto di credenziali rimane centrale, ma ha cambiato forma. Le tecniche “rumorose” come il credential dumping (T1003 – OS Credential Dumping, che richiede interazione diretta con processi sensibili come LSASS e genera artefatti rilevabili) sono uscite dalla top 10. Al loro posto, Credentials from Password Stores (T1555) compare nel 23,49% degli attacchi – quasi un attacco su quattro implica l’estrazione silenziosa di password salvate nei browser, nei keychain e nei password manager.

La differenza operativa è significativa: accedere a un password store è un’operazione che può apparire legittima – dopotutto, anche i processi autorizzati leggono questi archivi. Il credential dumping da LSASS, invece, richiede privilegi elevati e genera eventi distintivi che un EDR ben configurato può intercettare. Il passaggio dall’uno all’altro riflette perfettamente la filosofia del parassita: evitare il rumore, sfruttare i canali fidati.

5. Living off the Cloud

Il report documenta l’emergere di tecniche C2 che sfruttano servizi cloud legittimi per comunicare con i server di comando e controllo. L’esempio più emblematico è la backdoor SesameOp, scoperta da Microsoft DART nel luglio 2025 durante l’indagine su un’intrusione protrattasi per mesi in un ambiente corporate. SesameOp instradava tutto il traffico C2 attraverso l’API Assistants di OpenAI, mascherando le comunicazioni malevole come normale attività di sviluppo AI. Nessun dominio sospetto, nessun IP anomalo – solo traffico TLS verso api.openai.com, indistinguibile da milioni di connessioni legittime.

Come ha documentato Microsoft nel suo blog post tecnico, SesameOp non utilizzava alcun SDK o funzionalità AI di OpenAI: sfruttava l’API esclusivamente come canale di relay, usando i campi “description” degli Assistants come flag di comando (SLEEP, Payload, Result) e i messaggi come veicolo per payload cifrati con layer AES e RSA. L’obiettivo dell’attacco è stato determinato come persistenza a lungo termine per finalità di spionaggio – il profilo perfetto del parassita digitale.

Parallelamente, il Red Report 2026 di Picus documenta il gruppo Storm-0501, osservato da Microsoft mentre interrogava direttamente servizi di gestione dei segreti cloud (come AWS Secrets Manager) via API nativa per raccogliere credenziali, evitando completamente il rilevamento endpoint. Il parassita digitale non ha bisogno di forzare le porte: semplicemente, effettua il login.

6. Complessità crescente per campione

Ogni campione di malware esegue in media 14 azioni malevole e implementa 12 tecniche ATT&CK distinte. Non si tratta più di un singolo payload con una funzione. Il malware moderno è un organismo multi-funzionale che combina evasione, persistenza, furto credenziali, comunicazione C2 e preparazione all’esfiltrazione in un unico pacchetto coordinato. Questo livello di sofisticazione per singolo campione significa che affrontare una sola tecnica alla volta – l’approccio a “silos” tipico di molte architetture difensive – è strutturalmente inadeguato.

Il gap dell’invisibilità: quando le difese sono cieche

Il Red Report 2026 acquista la sua piena dimensione strategica se letto insieme al Blue Report 2025 di Picus Security, basato su oltre 160 milioni di simulazioni di attacco condotte in ambienti di produzione reali tra gennaio e giugno 2025. I due report, insieme, raccontano una storia preoccupante di perfetto allineamento tra capacità offensive e debolezze difensive.

Il dato che sintetizza tutto: il 54% dell’attività degli attaccanti viene registrata nei log, ma solo il 14% genera un alert. Le organizzazioni rilevano solo un attacco simulato su sette. Questo significa che le tecniche di persistenza e evasione a basso rumore operano regolarmente sotto le soglie di detection, nello spazio tra attività e consapevolezza dove il parassita digitale prospera.

Ancora più critico è il collasso delle difese contro l’esfiltrazione dati. Secondo il Blue Report 2025, la prevenzione dell’esfiltrazione è crollata dal 9% al 3%, confermandosi il vettore d’attacco meno contrastato per il terzo anno consecutivo. In un contesto in cui gli attaccanti stanno migrando dall’encryption all’esfiltrazione silenziosa, questo dato rappresenta una vulnerabilità sistemica: le organizzazioni hanno investito massicciamente nella resilienza anti-ransomware (backup, disaster recovery), ma hanno trascurato la protezione contro il furto graduale dei dati.

L’identità è il territorio dove il gap è più ampio. Il Blue Report 2025 ha rilevato che gli attacchi basati su credenziali valide (T1078 – Valid Accounts) hanno avuto successo nel 98% degli ambienti testati. Il cracking delle password è riuscito nel 46% degli ambienti, raddoppiando rispetto al 25% dell’anno precedente. L’efficacia complessiva della prevenzione è scesa dal 69% al 62%, invertendo i guadagni dell’anno precedente. Una volta che l’attaccante supera il confine dell’identità, l’attività malevola si confonde con le operazioni normali, rendendo il rilevamento una sfida di analisi comportamentale che la maggior parte dei SOC non è attrezzata ad affrontare.

Le cause di questo fallimento difensivo sono documentate nel Blue Report con precisione chirurgica: il 50% dei fallimenti nelle regole di detection è dovuto a problemi di raccolta log, il 24% a colli di bottiglia nelle performance, il 13% a misconfigurazioni. Non sono problemi di tecnologia mancante – sono problemi di manutenzione e validazione di tecnologia già presente.

Il paradosso del ransomware 2026: più attacchi, meno incassi

Il Red Report 2026 fornisce la spiegazione empirica di un paradosso che ha dominato il dibattito di settore nell’ultimo anno: come è possibile che gli attacchi ransomware aumentino mentre i pagamenti diminuiscono?

I numeri sono eloquenti. BlackFog ha registrato un aumento del 49% anno su anno negli attacchi ransomware dichiarati pubblicamente nel 2025, con un totale record di 1.174 incidenti e 130 gruppi attivi. Cyble ha registrato 6.604 attacchi ransomware a livello globale nel 2025, in aumento del 52% rispetto ai 4.346 del 2024, con gli Stati Uniti che hanno rappresentato il 55% degli attacchi totali.

Il Red Report 2026 offre la chiave interpretativa: il calo dell’encryption non è una ritirata, è una migrazione strategica. Gli attaccanti non stanno smettendo di monetizzare – stanno cambiando il modello di business. L’esfiltrazione silenziosa sostituisce la cifratura perché offre opzioni di monetizzazione multiple e prolungate nel tempo: estorsione graduale, rivendita dell’accesso persistente a terzi (initial access broker), intelligence gathering per insider trading, raccolta continuativa di credenziali da rivendere nei marketplace del dark web. Un singolo accesso persistente può essere monetizzato ripetutamente, mentre un’operazione di encryption ha un unico momento di leva – che sempre più spesso viene rifiutato dalla vittima.

Integrity360 conferma questa lettura nel suo report 2026: il 42% delle organizzazioni compromesse ha subito tattiche di doppia o tripla estorsione, dove il furto di dati e la pressione secondaria vengono utilizzati insieme o al posto dell’encryption. Ma l’estorsione basata sul solo furto dati sta paradossalmente perdendo efficacia: le organizzazioni hanno compreso che pagare non elimina gli obblighi legali di notifica, non garantisce la cancellazione dei dati e non impedisce la ri-estorsione. Coveware ha documentato come anche il solo negoziare con i criminali rappresenti un rischio crescente, con attori malevoli che non esitano a ricorrere allo SWATting – l’invio di squadre d’intervento armato ai domicili dei dirigenti – per forzare il pagamento.

La risposta degli attaccanti al calo dei pagamenti è la diversificazione: DDoS combinato con ransomware, reclutamento di insider aziendali, minacce reputazionali, pressioni su clienti e partner della vittima. Il parassita digitale descritto nel Red Report 2026 è la forma più sofisticata di questa diversificazione: invece di un singolo tentativo di estorsione ad alto rischio, l’attaccante mantiene un accesso persistente e a basso profilo che può essere sfruttato in modi multipli e su orizzonti temporali estesi.

Cosa cambia per chi difende: dalla detection dell’encryption alla caccia al parassita

Se il modello offensivo è cambiato, il modello difensivo deve seguire. E questo è, probabilmente, l’aspetto più doloroso del Red Report 2026: la maggior parte delle architetture di sicurezza è ancora ottimizzata per rilevare il ransomware tradizionale, non il parassita digitale.

Metriche di detection da ripensare

Il “time to detect encryption” era la metrica regina quando il ransomware cifrava i file entro ore dall’intrusione iniziale. In un modello parassitario, la metrica critica diventa il “time to detect data exfiltration” – e il Blue Report 2025 ci dice che questa capacità è al 3%. Il dwell time medio si allunga significativamente quando l’attaccante non ha alcun incentivo a fare rumore: la backdoor SesameOp ha operato per mesi prima di essere scoperta.

Le organizzazioni devono ripensare il proprio framework di metriche: non più solo MTTD (Mean Time to Detect) e MTTR (Mean Time to Respond) basati su alert di encryption, ma indicatori di compromissione comportamentali – anomalie nei pattern di accesso, volumi insoliti di query a password store, traffico outbound verso servizi cloud legittimi che eccede le baseline storiche.

Threat hunting: dalla ricerca di lateral movement alla low-and-slow exfiltration

Il threat hunting tradizionale si concentra sul rilevamento di lateral movement e privilege escalation – fasi che, nel modello tradizionale, precedono l’encryption. Il parassita digitale opera diversamente: una volta ottenuto l’accesso tramite credenziali valide, non ha bisogno di muoversi lateralmente in modo aggressivo. Può limitarsi a interrogare i password store e i servizi cloud utilizzando le stesse API e gli stessi strumenti degli amministratori legittimi.

I team di threat hunting devono sviluppare capacità di rilevamento “low-and-slow”: esfiltrazione di piccoli volumi distribuiti nel tempo, accesso a risorse sensibili da account validi ma in orari o con pattern anomali, query ai servizi di gestione dei segreti che non corrispondono ai workflow operativi documentati.

Architetture di sicurezza: dall’anti-ransomware al monitoraggio continuo

L’investimento in backup e disaster recovery resta essenziale, ma non è più sufficiente come strategia primaria. Il parassita digitale non distrugge i backup perché non ha bisogno di farlo: il suo obiettivo è l’esfiltrazione, non la cifratura.

Le architetture devono incorporare: Identity Threat Detection and Response (ITDR), per monitorare come le credenziali vengono utilizzate oltre a verificare che siano corrette; Data Loss Prevention di nuova generazione, basato su baseline comportamentali e anomaly detection anziché su regole statiche e pattern matching; microsegmentazione Zero Trust, per limitare il blast radius di ogni compromissione quando l’attaccante è già dentro con credenziali valide; e validazione continua dei controlli di sicurezza, perché il Blue Report 2025 dimostra che l’efficacia si degrada rapidamente senza testing costante.

Indicazioni operative per il SOC: come rilevare il parassita digitale

Alla luce dei dati del Red Report 2026, i team SOC devono aggiornare le proprie capacità di rilevamento per intercettare i comportamenti specifici del parassita digitale. Ecco le aree prioritarie su cui concentrare gli sforzi, mappate sulle tecniche ATT&CK documentate nel report.

Monitoraggio degli accessi ai password store (T1555). L’accesso ai credential store dei browser (Chrome Login Data, Firefox logins.json) e ai keychain di sistema da parte di processi non autorizzati è il segnale più affidabile. È necessario monitorare gli accessi in lettura a questi file e generare alert quando il processo richiedente non è il browser stesso o un password manager legittimo. Le regole Sigma per T1555 sono disponibili nel repository pubblico SigmaHQ e devono essere testate – non solo deployate – contro il comportamento reale dell’ambiente.

Detection della process injection (T1055). Monitorare le chiamate API di Windows associate all’injection: CreateRemoteThread, NtMapViewOfSection, QueueUserAPC, e le varianti di VirtualAllocEx + WriteProcessMemory. La chiave è correlare queste chiamate con il processo sorgente: se un processo utente non privilegiato invoca CreateRemoteThread su un processo di sistema, l’alert ha alta probabilità di essere significativo.

Traffico outbound verso servizi cloud legittimi. Il caso SesameOp dimostra che il C2 può transitare interamente su API cloud. È necessario stabilire baseline del traffico verso endpoint come api.openai.com, management.azure.com, secretsmanager.amazonaws.com, e generare alert su deviazioni significative, in particolare quando il traffico proviene da processi o utenti che non hanno giustificazione operativa per interrogare questi servizi.

Rilevamento della sandbox evasion (T1497). Monitorare le query WMI relative a informazioni hardware (Win32_ComputerSystem, Win32_BIOS), le interrogazioni sulle configurazioni di rete con pattern riconducibili a fingerprinting di ambienti virtualizzati, e l’enumerazione di processi associati a strumenti di analisi (procexp, wireshark, x64dbg). Se un campione esegue queste query nelle prime fasi di esecuzione e poi diventa silente, il pattern è coerente con sandbox evasion.

Validazione delle regole di detection esistenti. Il Blue Report 2025 rivela che il 50% dei fallimenti di detection è causato da problemi nella raccolta log, non da assenza di regole. Prima di scrivere nuove regole, verificare che quelle esistenti funzionino: che i log arrivino effettivamente al SIEM, che le regole si attivino sui dati reali e che gli alert risultanti siano azionabili. Un’attività di detection rule validation anche trimestrale può colmare una parte significativa del gap documentato nel report.

Implicazioni normative: NIS2, DORA e il parassita digitale

Il passaggio dal ransomware distruttivo alla residenza silenziosa ha implicazioni dirette per il framework normativo europeo, e in particolare per gli obblighi di notifica che dal 15 gennaio 2026 sono pienamente operativi in Italia.

La Direttiva NIS2 (Direttiva UE 2022/2555), recepita in Italia con il D.Lgs. 138/2024, definisce all’articolo 23 (articolo 25 del decreto di recepimento) gli obblighi di notifica per gli incidenti “significativi”. Un incidente è significativo quando ha causato o è in grado di causare una grave perturbazione operativa dei servizi o perdite finanziarie per il soggetto interessato, oppure quando ha provocato o può provocare ripercussioni su altre persone fisiche o giuridiche causando perdite materiali o immateriali considerevoli. La procedura prevede una pre-notifica al CSIRT Italia entro 24 ore e una notifica dettagliata entro 72 ore dall’evidenza dell’incidente.

Il problema è che il parassita digitale è progettato per non generare mai un “incidente significativo” visibile. Se l’attaccante non cifra i file, non interrompe le operazioni e non lascia tracce evidenti, quando scatta l’obbligo di notifica? L’ACN, con la Determinazione 379907 del 19 dicembre 2025, ha definito categorie di incidenti significativi di base (IS-1 per perdita di riservatezza, IS-2 per perdita di integrità, IS-3 per perdita di disponibilità) – ma l’esfiltrazione silenziosa e graduale può sfuggire a queste categorie finché non viene scoperta, momento in cui il danno è già consolidato e la finestra di notifica può essere tecnicamente scaduta.

Il Regolamento di esecuzione della Commissione Europea specifica che un incidente è significativo anche quando ha causato o è in grado di causare l’esfiltrazione di segreti commerciali. Questo criterio è direttamente rilevante per il modello del parassita digitale, ma presuppone che l’organizzazione sia consapevole dell’esfiltrazione – una consapevolezza che, con un tasso di prevenzione dell’esfiltrazione al 3% e alert generati solo sul 14% dell’attività malevola, è tutt’altro che garantita.

Per le istituzioni finanziarie soggette al Regolamento DORA (Regolamento UE 2022/2554), il problema è ancora più acuto. DORA richiede capacità di rilevamento, risposta e reporting su incidenti ICT dimostrabili e verificabili (Capitolo III, articoli 17-23), con obblighi di classificazione degli incidenti e notifica alle autorità competenti. Il Blue Report 2025, nella sua analisi settoriale BFSI, ha rilevato che nonostante una copertura di log superiore alla media (67%), solo il 13% degli attacchi simulati nel settore finanziario genera un alert – quasi 7 attacchi su 8 passano inosservati. In un contesto regolamentare che richiede capacità di detection dimostrabili e resilienza operativa verificata, questo gap rappresenta un’esposizione sia operativa sia sanzionatoria.

Il rischio concreto è duplice: da un lato, le organizzazioni potrebbero essere in stato di compromissione prolungata senza saperlo e, di conseguenza, in violazione degli obblighi di notifica tempestiva; dall’altro, le autorità di vigilanza potrebbero valutare ex post che un incidente avrebbe dovuto essere notificato prima, con conseguenze sanzionatorie significative. L’ACN ha chiarito che anche la mancata notifica di un incidente che l’autorità ritiene a posteriori significativo costituisce una violazione della normativa.

L’AI nel Red Report 2026: meno hype, più tradecraft

Un aspetto del Red Report 2026 che merita attenzione è ciò che il report non ha trovato. Nonostante le aspettative diffuse, Picus Labs non ha osservato alcun aumento significativo di tecniche d’attacco genuinamente guidate dall’intelligenza artificiale. Il successo degli attaccanti continua a basarsi su tradecraft consolidato: Process Injection e Command and Scripting Interpreter rimangono tra le tecniche più osservate.

Dove l’AI compare, il suo ruolo resta circoscritto. Il malware LameHug, documentato nel Red Report 2026, interagisce con API di large language model solo per recuperare comandi predefiniti. Non è stato osservato alcun ragionamento autonomo o decision-making adattivo – si tratta di integrazione superficiale, non di un cambiamento strutturale nella meccanica degli attacchi. La backdoor SesameOp, pur sfruttando l’infrastruttura OpenAI, non utilizza alcuna capacità AI: impiega l’API come semplice canale di comunicazione.

Questo non significa che l’AI non rappresenti un rischio futuro – e altre fonti, come il caso documentato da Darktrace di malware generato da LLM osservato nella rete di honeypot CloudyPots con attività rilevata a partire da novembre 2025, suggeriscono che la convergenza è in atto. Significa però che, oggi, le organizzazioni che si concentrano ossessivamente sull’AI-powered malware trascurando le difese contro credential theft e persistence stanno combattendo la guerra sbagliata. Il parassita digitale non ha bisogno di intelligenza artificiale per restare invisibile: gli basta sfruttare il gap tra logging e alerting che già esiste nella maggior parte degli ambienti enterprise.

Prospettive: il 2026 come anno della validazione continua

Il Red Report 2026 non è un documento pessimistico. È un documento che impone una ricalibratura. Il messaggio strategico è chiaro: le organizzazioni hanno costretto gli avversari a evolversi, rendendo il ransomware tradizionale meno redditizio. Ma l’evoluzione risultante – il parassita digitale – richiede una risposta difensiva altrettanto sofisticata.

La direzione è inequivocabile: le valutazioni statiche e la copertura basata su assunzioni lasciano punti ciechi quando le minacce sono progettate per restare silenziose. La protezione delle organizzazioni richiede la validazione continua dei controlli di sicurezza contro il comportamento avversario reale – non contro scenari teorici, ma contro le tecniche documentate empiricamente in report come questo.

Questo si traduce in azioni concrete. Testare i controlli di detection contro le tecniche della top 10 ATT&CK del Red Report 2026. Verificare che le regole SIEM si attivino effettivamente su T1055, T1555, T1497. Simulare esfiltrazione dati low-and-slow e misurare se viene rilevata. Stabilire baseline comportamentali per l’accesso ai credential store e ai servizi cloud. Integrare l’approccio CTEM (Continuous Threat Exposure Management) nelle operazioni quotidiane, non come progetto una tantum ma come processo continuo.

Per i professionisti della sicurezza, il Red Report 2026 di Picus è un invito a guardare oltre l’alert. Il parassita digitale non bussa alla porta: è già dentro, silenzioso, paziente, e si nutre di ogni credenziale non protetta, di ogni policy di accesso non verificata, di ogni gap tra ciò che viene registrato e ciò che viene effettivamente analizzato.

Il ransomware come lo conoscevamo sta cedendo il trono. E il suo successore è molto più difficile da trovare.

https://www.ictsecuritymagazine.com/articoli/parassita-digitale/

L’art. 82 del GDPR riconosce il diritto al risarcimento del danno, materiale e immateriale, derivante da violazione del Regolamento europeo sulla protezione dei dati personali. La giurisprudenza italiana, consolidata dall’ordinanza della Cassazione n. 13073/2023, subordina tuttavia il risarcimento alla prova della “serietà” della lesione, escludendo il danno in re ipsa ed esigendo il superamento di una soglia minima di gravità.

In apparente contraddizione con detto orientamento, la Corte di giustizia dell’Unione europea – da ultimo con la sentenza C-655/23 del 4 settembre 2025 – ha ribadito che l’art. 82 GDPR non richiede alcuna soglia di rilevanza: anche la semplice perdita di controllo sui dati personali o il timore di un loro uso abusivo possono integrare un danno immateriale risarcibile, purché effettivamente dimostrati.

L’articolo esamina questa contraddizione tra i due orientamenti, analizza il regime probatorio applicabile, con particolare attenzione al principio di accountability e al modello dell’art. 2050 c.c., e approfondisce, attraverso i recenti provvedimenti del Garante Privacy nei casi Postel S.p.A. (2024) e Poste Vita S.p.A. (2025), quali standard di adeguatezza delle misure di sicurezza tecniche e organizzative possano risultare determinanti sia in sede amministrativa sia in sede civile.

Introduzione

L’interpretazione della giurisprudenza sulla responsabilità civile derivante dall’illecito trattamento dei dati personali disciplinata dall’art. 82 GDPR, si rivela contraddittoria alla luce di recenti sentenze domestiche ed europee. Sullo sfondo rimangono le sentenze fondate sul previgente art. 15 cod. privacy e l’accostamento all’art. 2050 c.c. (responsabilità per attività pericolose) che la dottrina dominante (anche e soprattutto con il prepotente avvento delle applicazioni di intelligenza artificiale) continua a ritenere applicabile.

In sintesi l’art. 2050 c.c. (responsabilità per esercizio di attività pericolosa) prevede un’inversione dell’onere della prova: il danneggiato deve provare danno e nesso causale, mentre il convenuto deve fornire la prova liberatoria di aver adottato tutte le misure idonee a evitare il danno. La dottrina civilistica ha ricostruito la natura dell’art. 2050 in termini non univoci (colpa lievissima/colpa presunta/semi‑oggettiva od oggettiva), ma convergendo sul particolare rigore della prova liberatoria e sulla funzione di bilanciamento tra utilità sociale di attività rischiose e tutela dei terzi. È inoltre valorizzata l’estensione dell’art. 2050 anche a omissioni «qualificate», quando il danno derivi dal mancato approntamento di misure preventive dovute.

Nel quadro previgente, l’art. 15 del Codice privacy richiamava espressamente l’art. 2050 c.c.; pur essendo stato abrogato, la giurisprudenza di legittimità ha ribadito il modello probatorio, affermando che il danneggiato deve provare danno e nesso causale, mentre sul convenuto grava la prova di aver adottato tutte le misure idonee ad evitare il danno.

Parte della dottrina osserva che l’art. 82 GDPR, pur senza richiamo espresso all’art. 2050 c.c., tende a riprodurne la logica funzionale: centralità della gestione del rischio e della capacità organizzativa del titolare (accountability) e conseguente severità della prova liberatoria. In questa prospettiva, l’accountability non è solo un principio di governance, ma diviene anche un criterio probatorio: la qualità della documentazione (audit trail), delle procedure e dei controlli può risultare decisiva nel superare – o non superare – la presunzione di imputabilità.

Il fondamento normativo: art 82 GDPR – interpretazione giurisprudenza italiana: “occorre la prova della serietà del danno”

Nel dibattito dottrinale, anche l’art. 82 GDPR è stato letto come una responsabilità «speciale», in cui il momento organizzativo (misure tecniche e organizzative, governance dei processi e dei fornitori, tracciabilità delle decisioni) diventa decisivo sia sul piano sostanziale sia sul piano probatorio. La giurisprudenza interna sembra convergere su questa interpretazione in continuità, pur con qualche discontinuità.

L’art. 82 GDPR prevede il diritto al risarcimento del danno (materiale o immateriale) causato da una violazione del Regolamento. La responsabilità viene differenziata fra Titolare e Responsabile del trattamento.

Il Titolare del trattamento coinvolto nel trattamento risponde per il danno cagionato dal suo trattamento che violi il regolamento. Il Responsabile del trattamento risponde per il danno causato dal trattamento solo se non ha adempiuto gli obblighi del regolamento specificatamente diretti ai responsabili del trattamento o ha agito in modo difforme o contrario rispetto alle legittime istruzioni del titolare del trattamento. Entrambi sono esonerati da responsabilità se dimostrano che l’evento dannoso non è loro in alcun modo imputabile.

Il Considerando 146 del GDPR ulteriormente precisa che “Il concetto di danno dovrebbe essere interpretato in senso lato alla luce della giurisprudenza della Corte di giustizia in modo tale da rispecchiare pienamente gli obiettivi del presente regolamento”; sicché “gli interessati dovrebbero ottenere pieno ed effettivo risarcimento per il danno subito”.

A fronte del dettato normativo appena descritto, la Cassazione (ord. 12 maggio 2023, n. 13073) ha chiarito e reinterpretato il senso di alcune anteriori posizioni espresse a proposito dell’art. 15 del previgente Codice della Privacy: “vige ancora il principio per cui il danno non può dirsi in re ipsa (v. Cass. Sez. 6-1 n. 17383-20, Cass. Sez. 3 n. 16133-14)”, La Corte prosegue evidenziando che il diritto al risarcimento è soggetto alla verifica della gravità della lesione e della serietà del danno, intesa come perdita di natura personale effettivamente patita dall’interessato. Questo principio si fonda sul bilanciamento con il principio di solidarietà sancito dall’art. 2 della Costituzione, cui consegue l’obbligo di tollerare la lesione minima.

In altre parole, occorre un danno di non lievissima entità ed in caso di danno non lieve occorre una prova rigorosa dello stesso, va da sé che non si può dar luogo al risarcimento se – pur in presenza di violazione del GDPR – l’interessato non ha subito alcun danno.

Anche il Tribunale civile di Oristano (sent. 176/2024), ha ribadito che il danno non patrimoniale da illecito trattamento dei dati personali è risarcibile solo se la lesione alla riservatezza è grave e concreta, non per la semplice violazione formale delle norme, e a condizione che la lesione superi la soglia di tolleranza prevista dal principio di solidarietà.

Il Tribunale di Oristano prosegue affermando che:“La legittimazione attiva al risarcimento del danno da violazione della privacy spetta esclusivamente al soggetto i cui dati personali sono stati illecitamente trattati, non estendendosi ai familiari che, pur subendo conseguenze dannose indirette, non hanno visto diffusi i propri dati identificativi. Ai fini della liquidazione equitativa del danno non patrimoniale da illecito trattamento dei dati personali possono trovare applicazione, con procedimento analogico, i criteri orientativi per la quantificazione del danno da diffamazione elaborati dalla giurisprudenza di merito.”

La sentenza del Tribunale ripete concetti espressi dalla Corte di legittimità, fornendo anche un valido parametro per l’eventuale quantificazione del danno di tipo non patrimoniale, mostrando simpatia per la quantificazione del danno operata in caso di diffamazione.

Le condizioni del risarcimento secondo la recente Corte di giustizia dell’Unione europea

La sintesi dell’interpretazione giurisprudenziale “europea” sull’art. 82 del GDPR è rappresentata dalla recente CGUE, sez. IV, 4 settembre 2025, causa C-655/23.

Alla Corte di giustizia dell’Unione europea era stato richiesto, dal Bundesgerichtshof (Corte federale di giustizia tedesca), una interpretazione dell’articolo 82, paragrafo 1, del GDPR, nel senso che nella nozione di «danno immateriale» contenuta in tale disposizione si dovessero ricomprendere anche sentimenti negativi provati dalla “persona interessata” a seguito di una comunicazione non autorizzata dei suoi dati personali ad un terzo, quali il timore o l’insoddisfazione, che sono suscitati da una perdita di controllo su tali dati, da una potenziale utilizzazione abusiva degli stessi o da un pregiudizio alla sua reputazione.

La Corte ha risposto in maniera netta ed analitica, precisando che la nozione di danno ai sensi dell’art. 82 GDPR, deve ricevere una definizione ricavata specificamente dal diritto dell’Unione, in autonomia rispetto ai diritti interni (v., in tal senso, sentenze del 25 gennaio 2024, MediaMarktSaturn, C‑687/21, EU:C:2024:72, punto 64, e del 4 ottobre 2024, Agentsia po vpisvaniyata, C‑200/23, EU:C:2024:827, punto 139 nonché giurisprudenza citata).

Quale premessa la Corte ha ribadito che la semplice violazione del Regolamento europeo non è sufficiente per conferire un diritto al risarcimento. Le condizioni che deve soddisfare l’interessato per ottenere il diritto al risarcimento sono:

• provare di aver subito un «danno» (materiale o immateriale);
• provare la violazione di una norma del regolamento da parte di Titolare o Responsabile del trattamento;
• provare il nesso di causalità tra tale danno e detta violazione.

Le tre condizioni erano già state fissate da numerose sentenze [sent. 4 maggio 2023, Österreichische Post (Danno immateriale inerente al trattamento di dati personali), C‑300/21, EU:C:2023:370, punti 32, 33, 37 e 42; sent. 4 ottobre 2024, Agentsia po vpisvaniyata, C‑200/23, EU:C:2024:827, punti da 140 a 142, nonché sent 4 ottobre 2024, Patērētāju tiesību aizsardzības centrs, C‑507/23, EU:C:2024:854, punti 24 e 25].

Fino a qui vengono ribaditi concetti cari anche alla giurisprudenza italiana. La discontinuità riguarda la questione della “serietà del danno”, illustrata in precedenza e ripetutamente ribadita da Cassazione e giudici di merito.

Risarcimento del danno immateriale anche in presenza di “semplice” paura o insoddisfazione a seguito di illecito trattamento

La Corte di giustizia dell’Unione europea era chiamata ad esprimere un parere sulla sussistenza del danno immateriale qualora vengano allegati e provati: “sentimenti negativi, come rabbia, contrarietà, insoddisfazione, inquietudine e paura”, che derivano dal “timore della divulgazione dei dati a terzi che lavorano nel medesimo settore, il fatto che una persona abbia appreso informazioni riguardo a circostanze per le quali vale una regola di discrezione, [nonché] l’umiliazione per il mancato accoglimento delle sue pretese salariali e per la conoscenza di tale circostanza da parte di terzi”.

Nel rispondere, la Corte precisa che l’art. 82 GDPR è sempre stato interpretato nel senso di non fissare livelli di gravità del pregiudizio subito dall’interessato. “La disposizione suddetta non esige che un danno immateriale fatto valere dall’interessato debba raggiungere una «soglia di rilevanza” perché tale danno possa essere risarcito (v. in tal senso, sentenze del 4 maggio 2023, Österreichische Post, C‑300/21, EU:C:2023:370, punto 51, nonché del 4 ottobre 2024, Agentsia po vpisvaniyata, C‑200/23, EU:C:2024:827, punti 147 e 149).

In secondo luogo, come rilevato dalla Commissione europea nelle sue osservazioni scritte, situazioni, quali quelle invocate nel procedimento principale, attinenti ad un “pregiudizio alla reputazione” derivante da una violazione di dati personali o ad una “perdita del controllo” su dati siffatti, figurano esplicitamente tra gli esempi di possibili danni che sono elencati nei considerando 75 e 85 del GDPR. In particolare, la Corte ha sottolineato che il legislatore dell’Unione ha inteso includere la semplice “perdita del controllo” sui dati personali nell’elenco esemplificativo dei “danni” o dei “pregiudizi” che possono essere subiti dalle persone interessate (considerando 85 del GDPR), quand’anche non si sia concretamente verificato un uso abusivo dei dati in questione.

Una siffatta perdita del controllo può essere sufficiente per causare un «danno immateriale», ai sensi dell’articolo 82, paragrafo 1, del GDPR, purché l’interessato dimostri di aver effettivamente subìto un danno di tal genere, fosse pure minimo, senza che tale nozione di «danno immateriale» esiga la dimostrazione dell’esistenza di tangibili conseguenze negative supplementari (v., in tal senso, sentenza del 4 ottobre 2024, Agentsia po vpisvaniyata, C‑200/23, EU:C:2024:827, punti 145, 150 e 156 nonché giurisprudenza citata).

Ancora, la Corte ha statuito che la paura, provata dall’interessato, che i suoi dati personali siano oggetto di utilizzazione abusiva in futuro, a seguito di una violazione del GDPR, è idonea a costituire, di per sé solo, un «danno immateriale», a condizione che tale timore, con le sue conseguenze negative, sia debitamente dimostrato, aspetto questo la cui verifica incombe al giudice nazionale adito [v., in tal senso, sentenze del 20 giugno 2024, PS (Indirizzo errato), C‑590/22, EU:C:2024:536, punti 32, 35 e 36, nonché del 4 ottobre 2024, Agentsia po vpisvaniyata, C‑200/23, EU:C:2024:827, punti 143, 144 e 155 nonché giurisprudenza citata].

Pertanto, sebbene i sentimenti menzionati, in particolare il timore o l’insoddisfazione, possano far parte dei rischi inerenti alla normale esperienza di vita, simili sentimenti negativi sono suscettibili di costituire un «danno immateriale», purché, conformemente al requisito dell’esistenza di un nesso di causalità, la persona interessata dimostri che prova sentimenti siffatti, con le loro conseguenze negative, proprio in ragione della violazione del suddetto regolamento di cui trattasi, come ad esempio una trasmissione non autorizzata dei suoi dati personali ad un terzo che ingeneri il rischio di un uso abusivo di questi ultimi, aspetto questo che deve essere valutato dai giudici nazionali aditi.

I principi sin qui esaminati – risarcibilità del danno immateriale anche in assenza di una soglia minima di gravità, sufficienza della perdita di controllo sui dati e del timore di un uso abusivo futuro – trovano un banco di prova particolarmente significativo nelle ipotesi in cui la violazione dei dati personali non derivi da una condotta diretta del titolare del trattamento, bensì dall’attività dolosa di soggetti terzi, come accade tipicamente negli attacchi ransomware. In queste fattispecie al tema della prova del danno si affianca quello, altrettanto decisivo, dell’adeguatezza delle misure di sicurezza adottate e della conseguente ripartizione dell’onere probatorio tra interessato e titolare.

Data breach derivante da attività dolosa altrui e misure di sicurezza: controllo sull’adeguatezza e onere della prova

A questo punto merita un approfondimento la questione della risarcibilità del danno in presenza di data breach provocato da attività dolosa di terze parti, come ad esempio nella fattispecie del ransomware. La sentenza C-340/21 (VB c. NAP) affronta in modo diretto il rapporto tra data breach, adeguatezza delle misure tecniche e organizzative (artt. 24 e 32 GDPR) e diritto al risarcimento (art. 82). La Corte ha chiarito che i giudici non possono dedurre automaticamente l’inadeguatezza delle misure dal solo fatto dell’accesso/divulgazione non autorizzati; occorre una valutazione concreta dell’adeguatezza.

La stessa decisione evidenzia che il titolare può essere chiamato a risarcire anche quando l’evento deriva da terzi, salvo prova della non imputabilità; comunque il timore di un potenziale uso abusivo dei dati può integrare un danno immateriale.

La dottrina ha letto questa linea come pienamente coerente con l’accountability: l’onere di dimostrare l’adeguatezza delle misure grava sul titolare e diventa centrale la documentazione delle scelte e dei presidi adottati ex ante.

Quali misure di sicurezza ed organizzative per sfuggire alla responsabilità: casi del Garante, Postel (2024) e Poste Vita (2025)

I provvedimenti del Garante costituiscono un osservatorio privilegiato per individuare, in concreto, cosa significhi «misure adeguate» e quale sia la soglia di diligenza esigibile.

Nel provvedimento del 4 luglio 2024 (Registro n. 572/2024; doc. web 10063782), relativo a un procedimento sanzionatorio contro Postel S.p.A. concluso con una importante sanzione a carico del titolare del trattamento (sanzione amministrativa pari a 900.000,00 euro), il Garante ha preso in esame un attacco ransomware rivendicato dalla cybergang “Medusa”, con esfiltrazione e pubblicazione nel dark web di file contenenti dati personali e perdita di disponibilità per alcuni file. Il provvedimento dà conto anche delle vulnerabilità sfruttate (CVE-2022-41040 e CVE-2022-41082) e dell’avvio del procedimento con contestazioni, tra l’altro, su artt. 5, 25, 28, 32 e 33 GDPR.

Il valore pratico del caso sta nel fatto che l’istruttoria si concentra su profili organizzativi tipici (gestione delle vulnerabilità e delle patch, processi interni, completezza e qualità della notifica e dei flussi informativi verso i titolari committenti), cioè esattamente sui profili che, in sede civile, possono incidere sulla prova liberatoria richiesta dall’art. 2050 c.c. e dall’art. 82 GDPR.

Un caso complementare riguarda il procedimento sanzionatorio contro Poste Vita S.p.A., avviato da un reclamo del 24 ottobre 2024 e definito con provvedimento del 10 luglio 2025 (Registro n. 389/2025; doc. web 10154110). Il Garante prende in esame una illecita comunicazione di dati relativi a polizze vita a un soggetto terzo non autorizzato, avvenuta tramite risposte a richieste pervenute via e-mail e apparentemente corredate da firma autografa e dettagli idonei a indurre in errore gli operatori.

All’esito dell’istruttoria, il Garante evidenzia che – in assenza, agli atti della compagnia, di un indirizzo e-mail fornito dall’interessata – la società avrebbe dovuto porre in atto ogni misura idonea a verificare l’effettiva rispondenza dell’indirizzo di posta elettronica all’identità della (presunta) cliente, prima di inviare documentazione e informazioni.

Il provvedimento rileva inoltre un profilo di ritardo nella notifica ex art. 33 GDPR, precisando che, a fronte del disconoscimento dell’indirizzo e-mail, il titolare aveva la “ragionevole evidenza” della compromissione, con conseguente obbligo di notificare senza ingiustificato ritardo e, ove possibile, entro 72 ore, richiamando le Linee guida EDPB 9/2022 sul concetto di “conoscenza” della violazione.

I provvedimenti del Garante sommariamente descritti possono svolgere una funzione di «standard setting» e risultare rilevanti anche in sede civile come elementi fattuali per valutare l’adeguatezza delle misure organizzative e di sicurezza e la richiesta prova liberatoria per sfuggire alla responsabilità civilistica.

Conclusioni

L’analisi condotta evidenzia una frattura significativa tra l’orientamento della giurisprudenza italiana e quello della Corte di giustizia dell’Unione europea in materia di risarcimento del danno immateriale per violazione del GDPR.

Da un lato, la Cassazione italiana, con l’ordinanza n. 13073/2023 confermata dai giudici di merito, richiede la prova della “serietà” della lesione (il danno non deve consistere in meri disagi o fastidi) come condizione necessaria per il risarcimento, applicando un filtro di gravità che affonda le radici nel principio di solidarietà sociale (art. 2 Cost.) e nella tradizione civilistica della tolleranza della lesione minima.

Dall’altro lato, la CGUE – con una giurisprudenza ormai consolidata attraverso le sentenze Österreichische Post (C-300/21), MediaMarktSaturn (C-687/21), Agentsia po vpisvaniyata (C-200/23) e, da ultimo, la causa C-655/23 del settembre 2025 – ha stabilito in modo inequivocabile che l’art. 82 GDPR non contempla alcuna soglia minima di rilevanza del danno. La semplice perdita di controllo sui propri dati personali, il timore fondato di un utilizzo abusivo, finanche sentimenti negativi quali paura o insoddisfazione, possono costituire danno immateriale risarcibile, a condizione che l’interessato ne fornisca dimostrazione e provi il nesso causale con la violazione.

Questa contraddizione non è puramente teorica. L’interpretazione del giudice italiano, apparentemente divergente da quello europeo, ha come conseguenza pratica quella di diminuire la possibilità di risarcimento del danno per l’interessato, con pregiudizio per l’uniformità di applicazione del GDPR. Tuttavia occorre ricordare il considerando 146 del Regolamento (citato nel primo paragrafo del presente articolo) che esplicitamente rimanda alla (sola) giurisprudenza della Corte di giustizia europea la facoltà di interpretazione del concetto di danno E’ pertanto ragionevole ritenere che la difformità oggi evidenziata possa essere ricomposta e che quindi anche la giurisprudenza italiana si adegui al modello descritto dalla Corte di giustizia dell’Unione Europea.

Sul versante dell’onere della prova, l’analisi dei provvedimenti sanzionatori del Garante Privacy, in particolare i casi Postel S.p.A. (provv. 4 luglio 2024) e Poste Vita S.p.A. (provv. 10 luglio 2025), conferma che il principio di accountability opera come vero e proprio criterio probatorio: la documentazione delle scelte organizzative, la tempestività nella gestione delle vulnerabilità, la qualità delle procedure di notifica e i flussi informativi interni costituiscono gli elementi sui quali il titolare del trattamento è chiamato a costruire la propria prova liberatoria, tanto in sede amministrativa quanto, come si è argomentato, in sede civile, secondo il modello dell’art. 2050 c.c.

Il quadro che emerge impone ai titolari e ai responsabili del trattamento un duplice livello di attenzione: non soltanto l’adozione di misure tecniche e organizzative adeguate al rischio, ma anche la loro rigorosa documentazione e tracciabilità, nella consapevolezza che l’accountability non è soltanto un obbligo di compliance, ma rappresenta lo strumento decisivo per resistere a una pretesa risarcitoria in sede giudiziaria. In attesa di un auspicabile allineamento della giurisprudenza italiana a quella europea – che appare, alla luce del primato del diritto dell’Unione, inevitabile – la gestione proattiva e documentata del rischio resta la migliore forma di prevenzione anche sul piano della responsabilità civile.

https://www.ictsecuritymagazine.com/articoli/art-82-gdpr/

Gli attori non statali filo-iraniani sfruttano i cyber proxies come strumenti strategici per proiettare potere, condurre operazioni cibernetiche e perseguire obiettivi politici regionali. Questo testo inaugura una serie di approfondimenti sul tema Cyber Proxies. Capacità Cibernetiche degli Attori Non Statali Filo-Iraniani, analizzando come l’Iran coordini reti di proxy, dall’organizzazione di Hezbollah e Hamas fino alle unità cyber dedicate, per espandere la propria influenza e influenzare dinamiche geopolitiche complesse. La lettura offre un quadro chiaro e dettagliato delle infrastrutture, delle strategie operative e delle metodologie impiegate, introducendo i lettori al mondo dei cyber proxies filo-iraniani.

Introduzione ai cyber proxies e attori non statali filo-iraniani

Nell’attuale panorama geopolitico si assiste ad una progressiva proliferazione di entità che, parallelamente agli stati, svolgono un ruolo significativo nella determinazione delle dinamiche internazionali e trasformando i vuoti di potere in opportunità. Allo stesso tempo, sempre più stati-nazione fanno uso di queste entità per supportare i propri interessi politici, economici e di sicurezza in tutto il mondo, talvolta mettendo in discussione i perimetri giuridici globali. Come accennato, sempre più spesso gli Stati demandano attività storicamente prerogative della compagine statale ad attori non statali di vario titolo, al punto da configurare dei veri e propri proxy.

Il concetto di proxy è ampiamente utilizzato in letteratura per indicare quell’insieme di entità che sono controllate ed agiscono per conto di un’altra entità gerarchicamente superiore. L’impiego di questi attori permette agli stati di raggiungere obiettivi nazionali limitando i costi, riducendo il rischio di conflitti diretti, appaltando a tutti gli effetti compiti ad organismi spesso tecnicamente preparati (e organizzati) e, dissipando la responsabilità delle loro azioni certe a un certo grado di distacco dalle azioni di questi attori nel caso fosse necessario negare mantenendo una plausibile negabilità. Questo significa che, nonostante questi attori perseguano precisamente le agende politiche degli stati padrone, quest’ultimi possano sempre smentire ogni tipo di responsabilità sulle azioni dei proxy.

Questo tipo di dinamica trova un terreno fertile nel panorama delle minacce, dove il concetto di operazione informatica offensiva mercenaria è ampiamente diffuso. Gli attori di minaccia offrono ad attori statali e non diverse tipologie di operazioni e strumenti “as a Service”.

Un esempio chiave in questo ecosistema è quello dei Ransomware-as-a-Service (RaaS), ovvero quell’insieme di attori di minaccia sviluppatori del ransomware che forniscono il ransomware (e talvolta anche l’infrastruttura e supporto tecnico) ad altri attori (detti “affiliati”) per svolgere attività di estorsione economica delle vittime. Ancora, un altro esempio è costituito dagli Initial Access Broker. Questi attori di minaccia sono specializzati nella compromissione iniziale e, una volta ottenuto l’accesso a reti aziendali (o delle istituzioni), rivendono questi accessi ad altri attori (esempio per la distribuzione di ransomware) o a vere e proprie entità statali (per svolgere attività di sorveglianza).

A questi si aggiungono tutta una serie di attori coinvolti nell’erogazione di:

• Phishing-as-a-Service: pacchetti completi per campagne di phishing che possono includere template, pagine clone di siti bancari o aziendali, strumenti per inviare mail massive. L’obiettivo è appaltare la parte di delivery della catena di attacco informatico.
• Malware-as-a-Service (MaaS): può essere intesa come versione malevola del Software-as-a-Service (SaaS). Esistono diversi market in cui è possibile acquistare strumenti malevoli pronti all’uso come trojan, spyware o RAT, completi di interfacce grafiche, pannelli di controllo e guide all’uso. Questi strumenti possono essere impiegati per lo spionaggio aziendale, la raccolta intelligence o per azioni distruttive.
• DDoS-as-a-Service: come i precedenti, ma in questo caso è possibile arruolare dei veri e propri attacchi DDoS contro le infrastrutture designate dell’acquirente (sito web o un server), per vendetta, competizione o semplice attivismo.

Parallelamente al mondo del cybercrime si inserisce quell’insieme di attori di minaccia direttamente sponsorizzati da attori statali per perseguire le proprie agende politiche. Questi attori possono condurre o contribuire (attivamente o passivamente) a operazioni informatiche offensive, di spionaggio o anche distruttive in funzione delle necessità dello Stato sponsor.

Questo li rende particolarmente preziosi nel raggiungimento di specifici bisogni informativi (favoriti anche dalla progressiva digitalizzazione delle pubbliche amministrazioni) o anche come parte integrata della strategia bellica di un paese. Questo tipo di attività ha tipicamente costi notevolmente inferiori rispetto agli strumenti di guerra convenzionale e tutte le criticità di un attacco frontale sul campo di battaglia. Come la maggior parte delle strategie del conflitto asimmetrico, si sposa perfettamente la sua caratteristica intrinseca: eludere la capacità muscolare dell’avversario per spostarla su un terreno di confronto più favorevole.

Inoltre, analogamente al fenomeno dei proxy nel mondo reale, questo fenomeno pone una nuova sfida per il diritto internazionale nel determinare precisamente i confini di responsabilità e di applicazione del diritto internazionale nel cyberspazio. Infatti, quando si tratta di operazioni clandestine o di sorveglianza, il processo di attribuzione è spesso molto complicato. Una volta individuato il cluster o l’attore di minaccia dietro le attività tracciate diventa ancora più complesso attribuire l’operazione a uno Stato sponsor. Questi attori potrebbero operare indipendentemente (es per attivismo politico) o essere assoldati in modo confidenziale da intermediari.

Proxy iraniani: asse della resistenza

Dalla rivoluzione khomeinista del 1979 e la conseguente nascita della Repubblica islamica, l’Iran si è proiettato nella scena medio orientale come una teocrazia sciita orientata a: espandere geopoliticamente ed ideologicamente la sua sfera di influenza e perpetrare una costante politica di destabilizzazione e contrasto verso Stati Uniti e alleati regionali. Infatti, in quarantacinque anni, la politica regionale dell’Iran è ruotata in modo persistente principalmente attorno tre obiettivi:

• cacciare gli Stati Uniti dal Medio Oriente,
• eliminare Israele, considerata una entità illegittima e principale avversario ideologico
• affermarsi come attore egemone nell’area.

Per perseguire queste ambizioni, l’Iran è riuscito a creare quello che viene definito un vero e proprio “Asse della Resistenza”, ovvero una rete di attori proxy che comprende Hamas nella Striscia di Gaza, Hezbollah in Libano, gli Houthi in Yemen e diverse milizie sciite in Iraq. Questo “asse” si configura come un vero e proprio strumento di proiezione di potenza regionale, coordinato dalle Forze Quds del Corpo delle Guardie della rivoluzione islamica (IRGC) ed alimentato attraverso un incessante flusso di erogazione di fondi, armamenti, addestramento e guida strategica.

In altre parole, la politica estera iraniana si regge su un equilibrio di deterrenza e proiezione indiretta, fondato su attori non-statali che moltiplicano la pressione su avversari regionali e potenze esterne. Sebbene singoli fronti (come in Siria e Libano) conoscano battute d’arresto e mutamenti, la vera capacità di Teheran è stata quella di ridisegnare costantemente l’ordine mediorientale attraverso la creazione di attori, partiti o milizie pronti ad allinearsi alla sua direzione politica e strategica.

Dagli anni ’80, l’IRGC ha sponsorizzato gruppi armati non statali in Afghanistan, Iraq, Libano, Territori Palestinesi, Yemen e altri paesi, fornendo loro addestramento, armamenti, dotazioni militari, denaro e, come vedremo in alcuni casi anche le competenze per dotarsi di apparati cyber offensivi. Sebbene alcuni di questi attori operino anche indipendentemente dall’Iran (e dagli altri), possono essere considerati a tutti gli effetti come parte di un ”asse della resistenza” sotto la direzione strategica iraniana, in chiave anti-occidentale e anti-israeliana. Infatti, sponsorizzando questi gruppi, l’obiettivo iraniano è stato quello di esportare la sua rivoluzione, ma allo stesso tempo, di scoraggiare le aggressioni dei paesi stranieri e del suo principale avversario Israele.

Il primo esperimento di proiezione extra-statale fu Hezbollah. Con l’aiuto siriano, la Forza Quds riuscì a strutturare un prototipo di organizzazione altamente specializzata, fortemente allineata all’ideologia e agli interessi politici iraniani, che condivideva un’ostilità endemica verso Stati Uniti e Israele. Dal 1982, le Forze Quds hanno addestrato, armato e finanziato un complesso insieme di milizie sciite nel Libano meridionale, da impiegare per liberare il paese dall’occupazione israeliana. Nel tempo Hezbollah, soprattutto grazie al finanziamento iraniano, oltre al ruolo di difensore del Libano dall’invasore, è riuscito a penetrare capillarmente nel territorio, sostituirsi progressivamente nel vuoto statale come fornitore di servizi essenziali ai cittadini fino a diventare parte attiva della politica nazionale.

Negli anni ’90, Hamas, nonostante emergesse come branca jihadista sunnita dei Fratelli Musulmani egiziani, redasse una carta formale che sanciva gli obiettivi di distruggere Israele. In questo periodo, il gruppo iniziò a sviluppare contatti di alto livello con l’Iran e ad acquisire notorietà partecipando all’intifada palestinese contro Israele, spingendo nel 1992 il governo israeliano a deportare in Libano 418 figure di spicco di Hamas. L’IRGC e Hezbollah ospitarono questi deportati e cominciarono ad addestrarli alle tattiche sulla base della strategia consolidata da Hezbollah e, l’Iran inizierà a finanziare il gruppo, permettendogli di strutturarsi come partner pragmatico dell’asse di resistenza iraniano[1].

In seguito alla Primavera araba del 2011, le Forza Quds spostarono le proprie competenze in Siria, formalmente a difesa dei santuari sciiti, ma di fatto fornendo aiuto all’ex-presidente siriano Bashar al-Assad a reprimere i disordini tra la popolazione a maggioranza sunnita. Quando scoppiò la guerra civile, la Forza Quds ed Hezbollah (e altre milizie proxy) svolsero un ruolo cruciale, combattendo in prima linea a fianco delle forze del regime siriano. Parallelamente, le rivolte arabe scatenarono la guerra civile anche in Yemen.

Le rivolte del 2011 saranno anche il contesto di affermazione di un altro membro dell’asse, gli Houthi. In seguito al rovesciamento del presidente yemenita Ali Abdullah Salih, l’Iran fornì il suo supporto al gruppo, permettendogli di prendere il controllo del governo a Sana’a[2]. In tale contesto, l’IRGC svolse un ruolo di primo piano nel supporto intelligence, di addestramento e armando il movimento ribelle Houthi contro le forze congiunte del governo del paese e l’Arabia Saudita[3].

Dal 2013, in risposta all’ascesa dello Stato Islamico, le Forze Quds aumentarono la loro presenza in Iraq e Siria. In Iraq ci fu una forte mobilitazione di miliziani sciiti, molti dei quali avevano già collaborato con le Forze Quds durante l’occupazione statunitense. Molte di queste milizie che giurarono fedeltà alla Guida Suprema fornirono un importante contributo (da partner tacito) agli Stati Uniti a respingere lo Stato Islamico. Tuttavia, questa “partnership” si concluse intorno al 2019 con la sconfitta dello Stato Islamico. Da quel momento gli Stati Uniti iniziarono a cercare di sopprimere la forte influenza regionale creata dall’Iran.

Infatti, a gennaio 2020 attraverso un attacco con drone gli Stati Uniti eliminarono Abu Mahdi al-Muhandis, vice capo delle Forze di Mobilitazione Popolare e Qasem Soleimani comandante della Forza Quds dal 1997, entrambi protagonisti dell’opera di contrasto dello Stato islamico. Dalla morte di Soleimani, l’Iran e i suoi alleati giurarono vendetta e il complesso di attori sponsorizzati intensificarono gli attacchi contro le forze della coalizione statunitense in Iraq e Siria.

Tra il 2016 e il 2022 l’asse della resistenza raggiunge la maturità. Dalla Striscia di Gaza al Golfo di Aden, gruppi alleati furono finanziati e armati come eserciti convenzionali. Inoltre, legami tra IRGC e la sua rete regionale di proxy diventano ancora più evidente nell’attacco del 7 ottobre 2023 contro Israele. Sebbene la Guida Suprema abbia negato ogni forma di coinvolgimento con l’attacco di Hamas, diverse fonti sostengono che l’Iran fosse a conoscenza dell’offensiva e che abbia contribuito a facilitarla attraverso i decenni di sostegno ai combattenti palestinesi.

Mentre Israele concentrava la sua offensiva su Gaza, Hezbollah apriva il fronte settentrionale, le milizie irachene colpivano basi statunitensi in Siria e gli Houthi minacciavano le rotte marittime. La direzione strategica iraniana fu ancora più chiara nell’aprile 2024, quando per la prima volta l’IRGC, in risposta al bombardamento israeliano all’ambasciata iraniana a Damasco, lanciò un attacco con circa 300 droni e numerosi missili balistici sul territorio israeliano.

Ad oggi, la rete di proxy costruita dall’IRGC in quattro decenni costituisce il fulcro della strategia iraniana. Questa infrastruttura gli consente un approccio flessibile, in grado di modulare il coinvolgimento in un conflitto, passare da un ruolo offuscato ad operazioni frontali, tenendo la guerra sempre distante dal suo territorio.

Questo significa che il baricentro del potere iraniano non è all’interno dei suoi confini nazionali ma è disseminato in una galassia di attori che agiscono a doppio filo tra autonomia operativa e fedeltà all’ideologia della Guida Suprema. Questo significa che per comprendere l’attribuzione e la previsione delle intenzioni politiche di questo paese, occorre tener conto della sua infrastruttura nel suo insieme, ma anche delle singole parti che la compongono. Complessivamente, la Repubblica islamica iraniana può contare sui seguenti attori proxy[4]:

• Bahrein: Brigate Al-Ashtar
• Iraq: Kata’ib Hezbollah, Organizzazione Badr, Asa’ib Ahl al-Haq, Hezbollah Harakat al-Nujaba e Kata’ib Sayyed al-Shuhada.
• Libano: Hezbollah
• Palestina: Hamas e Jihad islamica palestinese.
• Siria: Brigata Fatemiyoun, Brigata Zainabiyoun, Quwat al-Ridha e Brigata Baqir
• Yemen: movimento Houthi

Negli anni la rete costruita dall’Iran si è strutturata attraverso ingenti finanziamenti orientati innanzitutto a rafforzarne la forza militare e la capacità operativa, ma anche a consolidare la loro posizione infiltrandosi capillarmente come entità politiche ed economiche nei rispettivi paesi. A loro volta, questi attori sono riusciti nel tempo a strutturarsi e a generare diverse forme di entrate per sostentarsi, soprattutto quando questi finanziamenti subivano battute di arresto. Questo approccio ha permesso agli attori dell’asse della resistenza di poter operare senza soluzione di continuità nei settori formali e informali delle rispettive economie (a livello nazionale e transnazionale), spesso usufruendo della rete clientelare locale, eludendo le regolamentazioni e mantenendo l’impunità[5].

L’accesso a questi flussi finanziari diviene un pilastro dell’autorità dell’Asse, sia a livello nazionale che transnazionale. Infatti, l’interconnessione della rete gli ha consentito una fluida circolazione di denaro, armi, risorse e competenze attraverso i confini.

Questi trasferimenti transfrontalieri rafforzarono la resilienza alle pressioni esterne come le sanzioni, gli permettono di inserirsi in modo parassitario nell’economia degli Stati e, di svilupparsi in ambito di dotazioni e capacità militari. In ogni paese, imprenditori, burocrati governativi, funzionari locali e attori armati collaborarono per facilitare il trasferimento (sia virtuale che fisico) di denaro attraverso i confini. La rete impiegata per questi trasferimenti è composta da individui che operano sia nel settore formale (come banche, agenzie, servizi pubblici etc.), sia in quello informale (es. contrabbandieri di denaro).

Come accennato precedentemente, in seguito al celebre caso Stuxnet, l’Iran ha progressivamente rafforzato le proprie dotazioni e strutture delegate alle operazioni informatiche e di sorveglianza. Infatti, già nel 2015 il governo iraniano aveva aumentato il budget destinato alla cybersicurezza dell’1.200% in un biennio.

La letteratura esaminata mostra come questo investimento nella strutturazione di capacità cyber si sia esteso anche al suo “asse della resistenza”. La formazione e l’impiego di proxy nella cyberwar conferisce a Teheran un doppio vantaggio in termini strategici:

• Ampliamento di alleati coinvolti in azioni coerenti con gli obiettivi strategici iraniani;
• Un certo grado di deresponsabilizzazione a livello internazionale per le azioni compiute da questi attori;
• È possibile che le potenze straniere colpite decidano di non colpire obiettivi iraniani in seguito ad un attacco proveniente da uno di questi attori. Inoltre, non essendo attori statali, i loro asset rappresentano bersagli limitati in caso di rappresaglia da parte di un governo straniero.

Struttura e funzionamento dei cyber proxy di Hezbollah

Il primo proxy iraniano a strutturarsi come partner strategico anche nel dominio cyber sarà proprio Hezbollah. Le Forze Quds contribuirono fornendo formazione e dotazioni tecnologiche, alla nascita e strutturazione di una unità di controspionaggio informatico. Alcune fonti indicano che questa unità fosse localizzata nel quartiere meridionale di Dahieh, a Beirut, e disponesse di dotazioni informatiche simili a quelle dell’Università Sharif di Teheran. Dalla sua nascita, sotto la direzione dei Pasdaran, questa unità fu incaricata principalmente di raccogliere informazioni sulle istituzioni statali libanesi, straniere in particolare nei paesi del Golfo[6].

Questa sorta di partenariato cyber tra Iran e Hezbollah determinerà un’evoluzione significativa nello sviluppo delle capacità operative del proxy, poiché implica non solo la condivisione di competenze ma anche di infrastrutture cyber da impiegare come parte di un’alleanza per specifiche finalità d’interesse geopolitico.

Nel 2018, Carnegie Endowment for Peace, un think tank statunitense, segnalava come “ci fossero poche prove di un trasferimento diretto di strumenti informatici” tra l’Iran e Hezbollah. Dopo il crollo del califfato dello Stato Islamico, Hezbollah ha assunto il ruolo di organizzazione terroristica mediorientale più sofisticata e influente nel cyberspazio. Gli attacchi informatici condotti da Lebanese Cedar APT, come vedremo, hanno interessato numerosi paesi, infiltrandosi nelle reti attraverso strumenti e metodologie sofisticate e qualificando l’attore come uno delle minacce ibride più tecnologicamente avanzate al mondo.

Tra i proxy iraniani, Hezbollah ha una reputazione consolidata per le proprie PsyOps, che si sono rivelate cruciali nei conflitti del 2002, 2006 e anche recentemente. Il gruppo ha compreso l’importanza di documentare le proprie operazioni militari al punto di rendere celebre la frase “Se non hai filmato, non hai combattuto”. Hezbollah mantiene un’unità dedicata esclusivamente alla guerra psicologica specializzata nel gestire l’immagine pubblica di Hezbollah e dei suoi avversari. Inoltre, possiede un complesso sistema di giornali, social media, siti internet e programmazione televisiva che gli permettono sia di riverberare la propria propaganda (e quindi di socializzazione della popolazione), sia di alimentare il ventaglio operativo di guerra informativa.

A riprova dell’elevato livello di specializzazione, alcune fonti sostengono che, durante la pandemia di Covid-19, Hezbollah ha fornito corsi di formazione in materia di propaganda e disinformazione finalizzati a promuovere i propri interessi strategici. L’obiettivo, oltre quello di reperire fondi, sembra essere quello di ampliare l’influenza regionale dell’Iran, diffondendone la strategia espansiva attraverso la sponsorizzazione di attori non statali in Paesi instabili come l’Iraq. Infatti, molti degli “allievi” di Hezbollah in ambito cyber provengono dall’Iraq e sostengono il gruppo terroristico pro-iraniano iracheno Kata’ib Hezbollah[7].

Grazie all’importante dose di risorse fornite dall’Iran, Hezbollah ha nel tempo dato prova di elevate capacità cyber offensive, consentendogli importanti risultati in termini strategici. Nel 2006, durante la seconda guerra israelo-libanese, gli hacker israeliani hanno interrotto il servizio sui siti web del Partito di Dio. In risposta, gli hacker di Hezbollah hanno attacchi informatici contro siti web in diversi paesi che hanno supportato Israele durante la guerra[8]. Negli Stati Uniti rete sono riusciti ad appropriarsi di siti e canali di comunicazione in diverse località (dal Texas alla Virginia, fino a provider di hosting a Delhi, Montreal, Brooklyn e nel New Jersey) con l’obiettivo di trasmettere messaggi e contenuti di Al-Manar, principale emittente televisivo portavoce del gruppo (ancora in attiva).

Questa strategia, definita “whack-a-mole”: ogni volta che un sito collegato ad Al-Manar o ad altre piattaforme di propaganda di Hezbollah veniva chiuso (“whacked down”), ne compariva subito uno nuovo (“pops up”) su un altro server o con un diverso indirizzo IP. Un esempio è stato l’hijacking di una piccola società via cavo nel sud del Texas, avvenuto grazie a un “collegamento improprio” all’interno della catena di distribuzione di un aggregatore di contenuti satellitari a New York. In questo modo Hezbollah ha collegato il proprio traffico all’indirizzo IP dell’operatore texano, invitando via e-mail e blog a seguire i contenuti di Al-Manar su quel portale[9].

In definitiva, oggi l’asse della resistenza può contare non solo su una complessa infrastruttura di divisioni cyber dipendenti dallo Stato, ma anche su una serie di attori di minaccia, direttamente parte di divisioni, o associati ai principali attori non statali della rete. La letteratura esaminata mi ha permesso di individuare cinque principali attori di minaccia, a tutti gli effetti “sponsorizzati” da Hezbollah, Hamas e ribelli Houthi. Nelle sezioni successive andremo a ricostruire la storia delle attività di questi attori dalla loro nascita ad oggi, cercando di identificarne le intenzioni, le metodologie e gli strumenti tipicamente impiegati.

Come vedremo, questi cyber-proxy non costituiscono un’unica entità monolitica, ma una costellazione di gruppi altamente specializzati nell’uso del dominio cyber per svolgere attività di spionaggio e sabotaggio. L’elemento centrale è l’appartenenza ideologica che, pur con distinzioni religiose, trova nella sfera di influenza iraniana l’universo simbolico condiviso, spingendo tali gruppi ad agire come parte integrante del medesimo Asse della Resistenza. La capacità di adattarsi nel tempo e l’enorme supporto fornito dall’Iran per lo sviluppo di questo network rende questi attori uno strumento estremamente pericoloso che alimenta il panorama globale delle minacce.

	Lebanese Cedar	Gaza Cybergang	OilAlpha
Affiliation:	Hezbollah	Hamas	Houthi
Structure:	Threat actor	Group of Threat Actors (Molerats, Arid Viper, Wirte)	Threat actor
Firs seen:	2012	· Molerats 2012 · Arid Viper 2012 · Wirte 2018	2023
Targeted Regions:	Middle East, North America, UE.	Middle East.	Yemen, Saudi Arabia.
Common Vector of Infection:	Scanning server web.	Spear phishing, Smishing, Social network catfishing.	Smishing
Operational frequency:	Low-frequency but prolonged attacks over time, interspersed with long periods of inactivity.	High frequency	Growing since 2022, with potential for expansion.

Hezbollah cyber-unit: Lebanese Cedar

Threat actor name:	Lebanese Cedar
Aliases:	DeftTorero, Volatile Cedar, Dancing Salome.
Location:	Lebanon.
Motivation:	Political (espionage).
Threat actor type:	State-sponsored (Hezbollah).
Targeted Countries:	Afghanistan, Canada, Egypt, Europe, France, Germany, Iran, Israel, Jordan, Lebanon, Middle East, Palestine, Russia, Saudi Arabia, Turkey, UAE, United Kingdom, United States.
Target Industries:	Education, Government, Defense, finance, Telecommunication, Internet Service Provider, Media, Entertainment, Civil Services, Technology, Education.
Malware:	Explosive (RAT), Madi, Tempting Cedar, Caterpillar, Mamad Warning Sheller, SharPyShell, ASPXSpy, Devilzshell, Lazagne.
TTP:	Reconnaissance	T1590, T1595.002, T1595.003
	Initial Access	T1190
	Persistence	T1505.003
	Discovery	T1083
	Collection	T1213, T1005, T1105
	C&C	T1008

Lebanese Cedar, attivo almeno dal 2012, è probabilmente l’attore più sofisticato e meglio supportato di quelli presi in analisi. Per quanto riguarda la vittimologia, l’attore ha concentrato le sue attività di spionaggio prevalentemente nel Medio Oriente (Israele, Libano, Arabia Saudita, Giordania, Emirati), Nord America e in alcuni Paesi europei, soprattutto nei settori telecomunicazione e governativi.

A differenza dei cluster legati ad Hamas, Lebanese Cedar conta poche ma durature campagne, intervallate da lunghi periodi di silenzio. Il “basso profilo” mantenuto nel tempo gli ha permesso di esfiltrare dati per mesi, se non per anni, restando quasi del tutto invisibile alla stampa specializzata.

Dal 2022 non sono emerse ulteriori informazioni su questo attore di minaccia, ma si ritiene che continui a operare in linea con gli obiettivi strategici di Hezbollah. A gennaio 2024, la National Cyber Directorate (NCD) israeliana ha dichiarato che l’attacco condotto a novembre 2023 dall’attore AGRIUS (soggetto collegato al MOISE) contro il Safed Ziv Medical Center è avvenuto con il supporto di Lebanese Cedar. Tale evento suggerisce che il gruppo sia ancora attivo e che stia svolgendo un ruolo anche nel conflitto con Hamas, poiché lo scopo dell’operazione era interrompere le attività ospedaliere israeliane[10].

Catena di attacco e metodologie operative dei cyber proxies

Per quanto riguarda le catene di attacco tipicamente impiegate, fino al 2015, Lebanese Cedar ha sperimentato varie tecniche di ingegneria sociale attraverso la diffusione di documenti malevoli (prevalentemente PowerPoint) compressi in archivi RAR (e protetti da password). Questi documenti includevano una serie di immagini e contenuti esca di vario genere (come paesaggi con scritte motivazionali, immagini religiose o illusioni ottiche).

Una volta abilitato il contenuto dei file, veniva eseguito automaticamente il payload che recuperava e installava i componenti essenziali del backdoor. In questo periodo, la catena di attacco portava alla distribuzione di “Madi”, un dropper scritto in Delphi. Una volta eseguito il dropper, venivano caricati diversi componenti aggiuntivi con funzionalità infostealer per raccogliere credenziali, documenti e altri dati sensibili. Infine, il dropper caricava anche il backdoor vero e proprio, che includeva funzionalità di:

• Keylogging;
• Catturare screenshot a intervalli regolari o quando la vittima usa specifici servizi (come webmail, social network, messaggistica);
• Registrazione dell’audio via microfono;
• Recupero di vari tipi di file;
• Enumerazione dei dischi;
• Cancellazione di file.

È importante notare che le prime attività di questo attore non erano direttamente riconducibili a un attore specifico. Tuttavia, dal 2015, il pattern di selezione dei target ha iniziato a sovrapporsi in modo evidente a interessi geopolitici di Stati-nazione o gruppi politici, escludendo la pista di attori mossi da fini economici e portando gli analisti a collegare queste attività alla Cyber Unit di Hezbollah[11].

Dal 2015, la metodologia di infezione di Lebanese Cedar inizia a prendere forma, consolidandosi come il modello principale per gli attacchi successivi. La catena di attacco iniziava con un’attenta attività di information gathering, con l’obiettivo di personalizzare ogni infezione al target. In questo contesto l’attore cominciava lo scanning prendendo di mira i server web pubblicamente accessibili (come Atlassian Confluence o Oracle Web Application), con l’obiettivo di individuare (in modo sia automatico che manuale) vulnerabilità. Secondo i ricercatori è probabile che l’attore effettuasse le ricognizioni, usando strumenti pubblici di scansione come Shodan, Censys, ZoomEye. Successivamente vengono impiegati tool di brute force (GoBuster, DirBuster) per identificare directory esposte per installare la WebShell.

Spesso questi server erano impiegati per funzionalità aziendali comuni e la loro sicurezza veniva sacrificata in funzione della produttività, rendendoli un bersaglio facile per gli attaccanti. Inoltre, una volta preso il controllo di un server, questo può essere usato come punto di pivot per esplorare, identificare e attaccare ulteriori target all’interno della rete interna[12].

Tipicamente, una volta trovata una vulnerabilità sfruttabile, l’attore la usa per iniettare codice web shell nel server. La web shell viene poi utilizzata per controllare il server della vittima e per inoculare il RAT. Questo approccio, meno rumoroso del phishing, consente di mimetizzarsi nelle reti bersaglio per lunghi periodi, puntando ad esfiltrare informazioni di rilevanza strategica. Nel dettaglio, gli strumenti impiegati in queste campagne di spionaggio sono[13]:

• Explosive RAT (presente in diverse infezioni dal 2015);
• WebShell custom “Caterpillar” (principalmente dal 2019);
• WebShell open source come Mamad Warning Sheller[14], SharPyShell, ASPXSpy e devilzshell (dal 2019)

Una volta installata la webshell, l’attore esegue vari comandi per comprendere meglio il sistema compromesso e la rete circostante. Tra cui:

• Verifica della connettività (ping di siti esterni);
• Elenco di cartelle e file locali;
• Rilevamento dei privilegi utente;
• Enumerazione di utenti locali e di dominio;
• Individuazione dei siti web ospitati dal server;
• Enumerazione delle relazioni di trust del dominio.

Queste informazioni sono propedeutiche per le fasi successive dell’attacco e forniscono un contesto per caricare diversi strumenti. Dal 2020 la catena di attacco dell’attore è rimasta invariata. Tuttavia, l’analisi storica e la documentazione disponibile non hanno portato alla luce nuove rilevazioni di Explosive RAT, ma solo vecchi set di strumenti leggermente modificati, suggerendo un potenziale spostamento di Lebanese Cedar verso tecniche più fileless/LOLBINS e l’uso di strumenti offensivi noti/comuni disponibili su Internet (come ASPXSpy o devilzshell) utilizzati in versione originale o con piccole modifiche [15].

La variazione più significativa (ed unica eccezione) del modus operandi di Lebanese Cedar è stata individuata nella campagna del 2017. Un elemento interessante di questa campagna è stato proprio l’impiego di catene di infezione tipicamente adottate dagli attori associati ad Hamas[16].

In questo caso, la catena di infezione iniziava attraverso il tentativo di adescamento dei target su Facebook attraverso falsi profili di giovani donne attraenti. Una volta ottenuta la fiducia della vittima e spostato i toni della conversazione su tematiche “sessuali”, il catfish la invitava a installare una versione malevola dell’app di messaggistica “Kik Messenger”. Una volta interagito con il link, le vittime venivano indirizzate a un sito web di phishing e, successivamente ad installare l’APK dell’app trojanizzata. Una volta installato, l’APK richiede l’accesso ad una serie di autorizzazioni intrusive e all’installazione dello spyware.

Questa campagna è particolarmente importante nell’analisi di questo attore, in quanto l’infrastruttura impiegata confermò l’ipotesi che il gruppo fosse localizzato in Libano[17]. Tuttavia, secondo quanto riferito dai servizi segreti della Repubblica Ceca (BIS), alcuni dei server C2 erano in Repubblica Ceca. Inoltre, successivamente sono stati individuati altri server localizzati in varie parti dell’Unione Europea e negli Stati Uniti[18].

Questo approfondimento ha mostrato come l’Iran strutturi e utilizzi i cyber proxies per perseguire obiettivi strategici, dalla raccolta intelligence alle operazioni offensive cibernetiche, integrando attori non statali nell’Asse della Resistenza. Il lettore è invitato a proseguire con il prossimo articolo dedicato agli attori di minaccia di Hamas tra cui Gaza Cybergang, Molerats e Arid Viper per comprendere meglio le strategie operative dei proxy palestinesi. Per una visione completa, è possibile scaricare gratuitamente il white paper di Ivano Chiumarulo “Cyber Proxies. Capacità Cibernetiche degli Attori Non Statali Filo-Iraniani”, che raccoglie tutte le informazioni analizzate e ulteriori dettagli sul dominio cyber degli attori filo-iraniani.

Note

[1] https://www.washingtoninstitute.org/policy-analysis/how-iran-fuels-hamas-terrorism

[2] https://www.chathamhouse.org/2025/03/shape-shifting-axis-resistance/02-how-axis-was-formed-and-how-it-has-evolved

[3] https://www.cfr.org/backgrounder/irans-revolutionary-guards

[4] https://www.cfr.org/backgrounder/irans-revolutionary-guards

[5] https://www.chathamhouse.org/2025/03/shape-shifting-axis-resistance/03-uncovering-axiss-economic-support-networks

[6] https://nationalinterest.org/blog/techland-when-great-power-competition-meets-digital-world/how-iran-built-hezbollah-top-cyber/

[7] Ivi.

[8] Addis C. L., Blanchard C. M., Hezbollah: Background and Issues for Congress, 2010.

[9] https://web.archive.org/web/20220128225409/http://content.time.com/time/world/article/0,8599,1224273,00.html

https://time.com/archive/6939536/how-hizballah-hijacks-the-internet/

[10] https://oodaloop.com/analysis/ooda-original/critical-infrastructure-remains-the-brass-ring-for-cyber-attackers-in-2024/

[11] https://blog.checkpoint.com/security/volatilecedar/

[12] https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2015/03/20082004/volatile-cedar-technical-report.pdf

https://threatpost.com/volatile-cedar-apt-group-first-operating-out-of-lebanon/111895/

[13] Ivi.

[14] Mamad Warning Sheller è WebShell associata all’hacker Mamad Warning (o Bax 026”5), noto per attività di defacement di siti web (soprattutto governativi) in Medio Oriente, probabilmente affiliato al gruppo hacktivist iraniano “Persian Hacker”.

[15] https://nationalinterest.org/blog/techland-when-great-power-competition-meets-digital-world/how-iran-built-hezbollah-top-cyber/

[16] https://blog.avast.com/avast-tracks-down-tempting-cedar-spyware

[17] https://blog.avast.com/avast-tracks-down-tempting-cedar-spyware

[18] https://www.binarydefense.com/resources/threat-watch/hezbollahs-cyber-operations-killed-by-czech-authorities/

https://www.ictsecuritymagazine.com/articoli/cyber-proxies/

Le estensioni Chrome AI malevole stanno emergendo come uno dei vettori di compromissione più insidiosi nell’ecosistema enterprise, accanto al phishing tradizionale e alle tecniche di social engineering come ClickFix. La settimana tra l’11 e il 16 febbraio 2026 ha reso questa realtà difficile da contestare: in soli cinque giorni, tre campagne distinte e indipendenti hanno dimostrato che il browser non è più un semplice strumento di navigazione, ma un ambiente di esecuzione ad alto privilegio che gli attaccanti stanno imparando a sfruttare con precisione industriale.

Il 12 febbraio, i ricercatori di LayerX hanno rivelato la campagna AiFrame: almeno 30 estensioni Chrome mascherate da assistenti AI – con nomi come “Gemini AI Sidebar”, “AI Assistant”, “ChatGPT Translate” – che hanno compromesso oltre 260.000 utenti (con alcune testate che riportano cifre fino a 300.000), sottraendo credenziali, contenuto delle email e cronologia di navigazione. L’11 febbraio, Koi Security aveva documentato il primo add-in Outlook malevolo mai rilevato in natura – AgreeTo, un tool di scheduling abbandonato dal suo sviluppatore e rilevato da un attaccante che ne ha preso il controllo per rubare oltre 4.000 credenziali Microsoft. E nella stessa settimana, Koi Security ha smascherato anche VK Styles, una rete di cinque estensioni che aveva silenziosamente dirottato oltre 500.000 account VKontakte.

Tre campagne. Due ecosistemi diversi – Chrome e Outlook. Un unico pattern strutturale: la fiducia implicita che utenti e organizzazioni ripongono nei marketplace ufficiali è diventata l’arma principale degli attaccanti.

Questo articolo non è un bollettino di sicurezza. È l’analisi di come il modello di distribuzione delle estensioni browser sia diventato strutturalmente vulnerabile e di cosa questo significhi per chi difende reti aziendali nel 2026.

Il browser come superficie d’attacco privilegiata: perché le estensioni Chrome AI malevole funzionano

Per comprendere la gravità di quanto accaduto, occorre partire da un dato architetturale che la maggior parte dei professionisti della sicurezza conosce in teoria ma sottovaluta in pratica: le estensioni browser operano con privilegi che pochi altri componenti software possono vantare.

Un’estensione Chrome con i permessi giusti può leggere e modificare il contenuto di qualsiasi pagina web visitata dall’utente, accedere ai cookie di sessione, intercettare le richieste di rete, catturare il contenuto degli appunti e persino registrare audio attraverso l’API Web Speech. Il tutto in background, senza che l’utente noti nulla di anomalo. E la portata del fenomeno è tutt’altro che marginale: secondo il LayerX Enterprise Browser Extension Security Report 2025, il 99% dei dipendenti enterprise ha almeno un’estensione browser installata, il che rende questa superficie d’attacco virtualmente universale negli ambienti aziendali.

Nel framework MITRE ATT&CK, le tecniche sfruttate dalle campagne di febbraio 2026 si mappano con precisione: T1176 – Browser Extensions per l’installazione del componente malevolo, T1539 – Steal Web Session Cookie per l’esfiltrazione dei cookie di sessione, T1185 – Browser Session Hijacking per l’intercettazione in tempo reale del contenuto delle pagine autenticate, e T1557 – Adversary-in-the-Middle per l’architettura iframe che si interpone tra utente e servizio. Comprendere questa mappatura è essenziale per i SOC analyst che devono tradurre l’intelligence sulle minacce in regole di detection operative.

Secondo una ricerca di Cybernews, 86 delle 100 estensioni Chrome analizzate (selezionate tra le più diffuse e raccomandate) richiedono permessi classificabili come ad alto rischio al momento dell’installazione: scripting, accesso esteso agli host, monitoraggio delle tab. Un’analisi condotta da Incogni nel gennaio 2026 su 442 estensioni AI ha rilevato che il 52% raccoglie almeno un tipo di dato utente e il 29% raccoglie informazioni personali identificabili.

Il problema non risiede nei permessi in sé – molte estensioni legittime ne necessitano di ampi per funzionare correttamente. Il problema è che il modello di sicurezza del Chrome Web Store si basa su una revisione che avviene al momento della pubblicazione, non durante l’esecuzione. Ciò che viene ispezionato al momento dell’approvazione non corrisponde necessariamente a ciò che viene eseguito successivamente sul dispositivo dell’utente. Ed è esattamente questa asimmetria che la campagna AiFrame ha sfruttato con efficacia chirurgica.

AiFrame: l’architettura di una campagna coordinata

La campagna AiFrame scoperta da LayerX non è l’opera di un dilettante opportunista. È un’operazione coordinata, industriale nella sua organizzazione, che ha impiegato la tecnica dell’extension spraying – la pubblicazione simultanea di decine di estensioni con nomi e branding diversi ma con identica infrastruttura backend – per massimizzare la superficie di distribuzione e garantire la resilienza contro i takedown.

Tutte le estensioni identificate condividevano lo stesso codebase JavaScript, gli stessi permessi e comunicavano con un’unica infrastruttura backend ospitata sotto il dominio tapnetic[.]pro. L’estensione più diffusa, Gemini AI Sidebar, aveva raggiunto 80.000 installazioni prima della rimozione dal Chrome Web Store. Altre estensioni di rilievo includevano AI Sidebar (70.000 utenti), AI Assistant (60.000 utenti) e ChatGPT Translate (30.000 utenti).

Ma il dettaglio tecnico più rilevante riguarda l’architettura di esecuzione. Le estensioni non implementavano localmente alcuna funzionalità AI. Al loro posto, caricavano un iframe a schermo intero puntato verso sottodomini remoti dell’infrastruttura dell’attaccante – come claude[.]tapnetic[.]pro – che sovrapponeva una finta interfaccia alla pagina web corrente. Per l’utente, l’esperienza appariva identica a quella di un assistente AI legittimo. In realtà, l’intera interfaccia era controllata dall’attaccante, che poteva modificarne il comportamento in qualsiasi momento senza dover sottoporre aggiornamenti al Chrome Web Store.

Questa architettura è particolarmente insidiosa perché sfrutta un punto cieco fondamentale del processo di revisione: Google verifica il codice al momento della pubblicazione, ma il contenuto servito dagli iframe remoti può cambiare liberamente in qualsiasi momento successivo.

Come ha dichiarato la ricercatrice Natalie Zargarov di LayerX a eSecurity Planet, la campagna sfrutta la natura conversazionale delle interazioni con gli assistenti AI, che ha condizionato gli utenti a condividere informazioni dettagliate e sensibili in modo naturale. L’iframe malevolo intercettava questi dati prima ancora che raggiungessero qualsiasi servizio AI legittimo, creando di fatto un attacco man-in-the-middle invisibile tra l’utente e l’interfaccia che credeva autentica.

Cosa rubavano le estensioni Chrome AI malevole: un’analisi dei vettori di esfiltrazione

L’arsenale di raccolta dati della campagna AiFrame operava su quattro livelli distinti, ciascuno con obiettivi specifici.

Il primo livello riguardava l’estrazione del contenuto delle pagine. Le estensioni utilizzavano la libreria Readability di Mozilla per estrarre titoli, testo e metadati da qualsiasi sito visitato dall’utente, incluse pagine autenticate come home banking, pannelli di amministrazione cloud e piattaforme SaaS aziendali. Il contenuto estratto veniva trasmesso all’infrastruttura backend controllata dall’operatore della campagna.

Il secondo livello, forse il più dannoso dal punto di vista enterprise, era dedicato specificamente alla compromissione di Gmail. Quindici delle 30 estensioni includevano uno script di contenuto dedicato che si attivava su mail.google.com al caricamento del documento, iniettava elementi nell’interfaccia utente e utilizzava un MutationObserver per mantenere la persistenza e catturare continuamente il testo dei thread email. Persino le bozze non inviate potevano essere intercettate.

Il terzo livello coinvolgeva un meccanismo di riconoscimento vocale attivabile da remoto. Quando abilitato dall’operatore, questo modulo utilizzava l’API Web Speech del browser per registrare conversazioni reali dall’ambiente fisico dell’utente e generare trascrizioni, trasformando il computer compromesso in un dispositivo di sorveglianza ambientale.

Il quarto livello era la raccolta passiva e continua di credenziali, cookie di sessione e cronologia di navigazione, destinata ad alimentare il mercato degli infostealer e dei credential marketplace nel dark web.

Il risultato complessivo è che queste estensioni funzionavano come broker di accesso generalisti, capaci di raccogliere dati, monitorare il comportamento degli utenti ed evolvere silenziosamente nel tempo – esattamente la definizione che LayerX ha utilizzato nel proprio report.

AgreeToSteal: il primo add-in Outlook malevolo e il problema delle dipendenze dinamiche abbandonate

Se la campagna AiFrame ha dimostrato il rischio delle estensioni Chrome AI malevole distribuite attraverso marketplace ufficiali, il caso AgreeToSteal scoperto da Koi Security ha rivelato un rischio parallelo e forse ancora più subdolo: quello delle dipendenze dinamiche abbandonate.

AgreeTo era un add-in di scheduling per Outlook perfettamente legittimo, sviluppato da un programmatore indipendente e pubblicato nel Microsoft Office Add-in Store nel dicembre 2022. L’add-in funzionava, aveva buone recensioni e puntava a un URL ospitato su Vercel (outlook-one.vercel[.]app) da cui caricava la propria interfaccia. Quando lo sviluppatore ha abbandonato il progetto, l’URL su Vercel è diventato rivendicabile. Un attaccante lo ha rivendicato, vi ha installato un kit di phishing, e l’infrastruttura di Microsoft ha iniziato a servire la pagina malevola direttamente nella barra laterale di Outlook a chiunque avesse ancora l’add-in installato.

Gli add-in di Office non sono software scaricabili nel senso tradizionale. Sono essenzialmente URL che puntano a contenuti caricati nel prodotto Microsoft dal server dello sviluppatore. Questo significa che, come ha dichiarato Idan Dardikman, cofondatore e CTO di Koi Security, a The Hacker News, un add-in che è sicuro il lunedì può servire una pagina di phishing il martedì – o, come in questo caso, anni dopo. Microsoft verifica il manifest XML al momento della sottomissione, ma il contenuto effettivo può cambiare in qualsiasi momento senza ulteriore revisione.

Accedendo al canale di esfiltrazione dell’attaccante – un bot Telegram – i ricercatori di Koi hanno recuperato l’intera portata dell’operazione: oltre 4.000 credenziali Microsoft rubate, numeri di carte di credito e risposte a domande di sicurezza bancaria. L’attaccante stava attivamente testando le credenziali rubate nel momento in cui è stato scoperto e gestiva almeno una dozzina di kit di phishing aggiuntivi destinati a banche e provider di webmail.

Ciò che rende questo caso particolarmente significativo è che la vulnerabilità sfruttata non è tecnica in senso stretto: è architetturale. MDSec aveva identificato gli add-in di Office come superficie d’attacco già nel 2019, concludendo il proprio post con un avvertimento esplicito sulla possibilità che gli sviluppatori potessero distribuire add-in attraverso lo store ufficiale e sulle implicazioni di sicurezza di questa architettura. Sette anni dopo, AgreeTo è esattamente lo scenario che avevano previsto.

VK Styles e il pattern emergente: quando l’estensione diventa un’infrastruttura di comando

La terza campagna della “settimana nera” delle estensioni browser – VK Styles, scoperta sempre da Koi Security – aggiunge un ulteriore livello di complessità al quadro. Cinque estensioni Chrome mascherate da strumenti di personalizzazione per VKontakte (il social network russo da oltre 650 milioni di utenti) avevano silenziosamente dirottato oltre 500.000 account, mantenendo il controllo persistente per oltre sette mesi, da giugno 2025 a gennaio 2026.

La sofisticazione di questa campagna risiede nella sua architettura di command-and-control. Invece di comunicare con server esterni facilmente bloccabili, il malware utilizzava i tag metadata HTML di un profilo VKontakte come dead drop resolver – una tecnica mutuata dall’intelligence tradizionale in cui un punto di scambio apparentemente innocuo viene utilizzato come intermediario per nascondere le comunicazioni operative – celando gli URL dei payload di secondo stadio all’interno di contenuti che, per qualsiasi sistema di sicurezza, apparivano come normali metadati di un profilo social. Il codice malevolo era ospitato in un repository GitHub pubblico associato all’utente 2vk, con 17 commit documentati che mostravano un’evoluzione deliberata e sistematica delle funzionalità.

Come riportato nell’analisi di Koi Security, questa non è opera approssimativa: è un progetto software mantenuto con controllo di versione, testing e miglioramenti iterativi. Ogni aggiornamento ampliava le capacità del malware: manipolazione dei cookie CSRF per bypassare le protezioni di sicurezza di VK, iscrizione automatica delle vittime a gruppi controllati dall’attaccante (con probabilità del 75% a ogni sessione), reset forzato delle impostazioni dell’account ogni 30 giorni e tracciamento delle donazioni tramite l’API VK Donut per monetizzare direttamente le vittime.

Il contesto strutturale: un problema che non riguarda solo febbraio 2026

La concentrazione di eventi della seconda settimana di febbraio 2026 potrebbe dare l’impressione di un picco anomalo. In realtà, è la manifestazione visibile di un trend strutturale in accelerazione.

A dicembre 2024, un attacco alla supply chain aveva compromesso l’estensione Chrome di Cyberhaven, un’azienda di cybersecurity specializzata in data loss prevention. Un attacco di phishing aveva indotto uno sviluppatore a concedere l’accesso a un’applicazione OAuth malevola denominata “Privacy Policy Extension” – senza che le credenziali Google dello sviluppatore fossero effettivamente compromesse -, consentendo agli attaccanti di pubblicare una versione malevola dell’estensione che esfiltrò cookie e sessioni autenticate per circa 24 ore. L’incidente faceva parte di una campagna più ampia che aveva compromesso almeno 35 estensioni Chrome, esponendo oltre 2,6 milioni di utenti, come documentato dai ricercatori di Hunters Security e Sekoia.

A febbraio 2026, il ricercatore indipendente Q Continuum ha pubblicato un’analisi sistematica che ha identificato 287 estensioni Chrome coinvolte nell’esfiltrazione della cronologia di navigazione verso data broker, per un totale di 37,4 milioni di installazioni – circa l’1% dell’intera base utenti globale di Chrome. Le entità coinvolte nella raccolta dei dati spaziavano da Similarweb ad Alibaba Group, da ByteDance a numerosi broker di dati minori.

Secondo un’analisi di Barracuda Networks pubblicata il 25 febbraio 2026, le estensioni browser non sono più minacce marginali o fastidi di basso livello: sono ora un vettore di attacco scalabile, furtivo e capace di condurre sorveglianza su milioni di utenti, rubare dati sensibili e compromettere silenziosamente la sicurezza organizzativa. Uno studio condotto dalla Stanford University e dal CISPA Helmholtz Center for Information Security aveva già identificato migliaia di estensioni classificabili come security-noteworthy – contenenti malware, violazioni delle policy sulla privacy o vulnerabilità note – che rimanevano disponibili per anni, accumulando milioni di installazioni.

Estensioni Chrome AI malevole: perché il brand “intelligenza artificiale” è il cavallo di Troia perfetto

C’è un motivo specifico per cui la campagna AiFrame ha scelto di mascherarsi da assistente AI, e non è casuale. L’adozione massiva di strumenti come ChatGPT, Claude, Gemini e Grok ha creato un fenomeno comportamentale senza precedenti: gli utenti sono disposti a installare qualsiasi cosa prometta funzionalità AI, con una soglia di verifica significativamente più bassa rispetto ad altri tipi di software.

L’analisi di Incogni del gennaio 2026 su 442 estensioni AI nel Chrome Web Store ha documentato che il 42% utilizza il permesso di scripting – potenzialmente in grado di influenzare 92 milioni di utenti – e il 31,4% raccoglie contenuti dei siti web visitati. Tra le estensioni con oltre 2 milioni di download, anche strumenti legittimi e noti come Grammarly e QuillBot sono stati classificati come potenzialmente ad alto impatto sulla privacy, per la combinazione di dati raccolti e permessi richiesti – pur presentando, come nota Incogni, una bassa probabilità di utilizzo malevolo.

Il brand AI funziona come leva di fiducia perché opera su tre livelli psicologici simultanei. Il primo è l’urgenza dell’adozione: in un contesto lavorativo dove l’AI è percepita come vantaggio competitivo, il ritardo nell’adozione viene vissuto come rischio professionale. Il secondo è la normalizzazione della condivisione: le interfacce conversazionali addestrano gli utenti a condividere informazioni dettagliate – codice proprietario, documenti riservati, credenziali – come parte naturale del flusso di lavoro.

Il terzo è la fiducia nel marketplace: la presenza sul Chrome Web Store, con badge “Featured” e migliaia di recensioni, crea un’apparenza di legittimità che pochi utenti contestano. Alcune delle estensioni AiFrame erano addirittura contrassegnate come “Featured” dallo store, come evidenziato sia da LayerX che da Infosecurity Magazine, aumentando ulteriormente la fiducia degli utenti e accelerandone l’adozione.

Il modello di sicurezza rotto: “approva una volta, fidati per sempre”

Il filo rosso che collega AiFrame, AgreeToSteal e VK Styles non è il tipo di dati rubati o il vettore di distribuzione specifico. È un difetto architetturale comune a tutti i marketplace di estensioni e add-in: il modello “approva una volta, fidati per sempre”.

Google verifica il codice di un’estensione al momento della pubblicazione. Microsoft verifica il manifest XML di un add-in al momento della sottomissione. Ma nessuno dei due verifica sistematicamente che cosa viene effettivamente eseguito in seguito. Nel caso di AiFrame, il codice approvato era tecnicamente benigno: caricava un iframe. Il contenuto dell’iframe, controllato dall’attaccante, poteva cambiare in qualsiasi momento. Nel caso di AgreeToSteal, il manifest dell’add-in non era mai cambiato: era l’URL di destinazione a essere stato dirottato. Nel caso di VK Styles, i payload malevoli erano ospitati su un profilo VKontakte e un repository GitHub, completamente al di fuori del perimetro di monitoraggio del Chrome Web Store.

Come ha dichiarato Dardikman di Koi Security a The Hacker News, il problema strutturale è identico in tutti i marketplace che ospitano dipendenze remote dinamiche: approvazione una tantum e fiducia perenne. I dettagli specifici variano per piattaforma, ma il gap fondamentale che ha reso possibile AgreeToSteal esiste ovunque un marketplace verifichi un manifest al momento della sottomissione senza monitorare ciò che gli URL referenziati servono effettivamente in seguito.

Vale la pena osservare che Google non è rimasta inerte. La transizione da Manifest V2 a Manifest V3, avviata nel 2023 e progressivamente imposta nel Chrome Web Store, ha introdotto restrizioni significative: i background script persistenti sono stati sostituiti da service worker con ciclo di vita limitato, i permessi devono essere dichiarati esplicitamente e le capacità di intercettazione delle richieste di rete sono state ridotte.

In teoria, MV3 avrebbe dovuto ridurre drasticamente la superficie d’attacco delle estensioni. In pratica, la campagna AiFrame dimostra i limiti di questo approccio: spostando l’intera logica malevola in un iframe remoto caricato dal server dell’attaccante, l’estensione opera in un territorio che MV3 non è progettato per governare. Il codice esaminabile al momento della pubblicazione è minimo e tecnicamente benigno; è il contenuto servito a runtime dall’infrastruttura esterna che compie le azioni malevole. MV3 ha alzato l’asticella, ma non ha risolto il problema fondamentale delle dipendenze dinamiche non monitorate.

Questo non è un bug. È un difetto di progettazione che trasforma ogni estensione browser e ogni add-in Office in una potenziale backdoor dormiente, attivabile dall’attaccante nel momento che ritiene più opportuno.

Implicazioni operative per i professionisti della sicurezza

La domanda che ogni CISO dovrebbe porsi dopo la settimana dell’11-16 febbraio 2026 non è “come impedisco agli utenti di installare estensioni malevole” – una battaglia persa in partenza. La domanda corretta è: “tratto il browser come parte della superficie d’attacco enterprise con la stessa governance che applico agli endpoint e ai servizi cloud?”.

Le contromisure efficaci operano su diversi piani complementari.

Sul piano della governance delle estensioni, le organizzazioni devono implementare policy di allowlisting che consentano l’installazione solo di estensioni specificamente approvate. Chrome Enterprise offre controlli gestiti che permettono agli amministratori IT di curare liste di estensioni sicure, bloccare minacce note e rimuovere add-on compromessi. La revisione deve essere un processo continuo, non un’approvazione una tantum: ogni aggiornamento di un’estensione autorizzata dovrebbe innescare una nuova valutazione.

Sul piano del monitoraggio comportamentale, è necessario implementare soluzioni che osservino il comportamento delle estensioni in tempo reale – trasferimenti di dati anomali, comunicazioni frequenti con server esterni, alterazione delle impostazioni del browser – piuttosto che affidarsi esclusivamente alla reputazione al momento dell’installazione. Le estensioni vanno trattate come componenti software privilegiati che richiedono sorveglianza continua.

Sul piano della detection operativa, i SOC analyst dovrebbero implementare regole specifiche per identificare i pattern documentati in queste campagne. Per la campagna AiFrame, gli indicatori critici includono: connessioni in uscita verso il dominio tapnetic[.]pro e relativi sottodomini, la presenza di iframe full-screen iniettati da estensioni che sovrappongono contenuti remoti alle pagine web attive, e l’attivazione non autorizzata dell’API Web Speech da processi collegati a estensioni.

Per AgreeToSteal, l’indicatore principale è l’add-in con ID WA200004949 e connessioni verso outlook-one.vercel[.]app. Le regole Sigma per la detection di esfiltrazione via estensioni browser dovrebbero monitorare volumi anomali di traffico HTTPS in uscita correlati ai processi del browser, in particolare verso domini registrati di recente o con bassa reputazione, e l’accesso programmatico ai contenuti di Gmail (letture DOM ripetute su mail.google.com con pattern temporali regolari). La lista completa degli indicatori di compromissione per la campagna AiFrame è disponibile nel report tecnico di LayerX.

Sul piano della riduzione della superficie d’attacco, occorre valutare criticamente i permessi richiesti da ogni estensione. Un’estensione di presa appunti che richiede accesso a tutti i dati su tutti i siti web è un segnale d’allarme. Le wildcard nei permessi host dovrebbero essere bloccate salvo giustificazione documentata. L’accesso alle API sensibili come Web Speech, clipboard e storage dovrebbe essere limitato al minimo indispensabile.

Sul piano della protezione dell’identità, il caso AiFrame dimostra che i cookie di sessione rubati tramite estensioni malevole alimentano direttamente la catena infostealer – credential marketplace – attacco ransomware. L’adozione di autenticazione FIDO2/WebAuthn, la revoca automatica delle sessioni e il monitoraggio continuo delle sessioni attive diventano essenziali quando il browser è un vettore di compromissione primario.

Sul piano della gestione degli add-in Office, il caso AgreeToSteal impone un audit sistematico di tutti gli add-in installati in ambiente Microsoft 365, con attenzione particolare a quelli non più mantenuti dallo sviluppatore originale. Gli add-in abbandonati con URL potenzialmente rivendicabili rappresentano un rischio specifico che richiede inventariazione e bonifica proattiva.

La dimensione normativa: NIS2, DORA e la responsabilità dell’organizzazione

Le implicazioni di quanto documentato non sono esclusivamente tecniche. La direttiva NIS2, in vigore nell’Unione Europea, impone alle entità essenziali e importanti l’adozione di misure di gestione del rischio cybersecurity che comprendano la sicurezza della supply chain, inclusa la gestione delle vulnerabilità nei componenti software forniti da terze parti. Le estensioni browser installate sui dispositivi aziendali rientrano pienamente in questa definizione.

Il Regolamento DORA (Digital Operational Resilience Act), applicabile al settore finanziario europeo, richiede esplicitamente la gestione del rischio ICT legato a fornitori terzi e la verifica continua della resilienza operativa digitale. Un’estensione Chrome che esfiltra il contenuto delle email aziendali e le credenziali di accesso ai servizi cloud rappresenta un incidente che rientra negli obblighi di segnalazione previsti dal regolamento.

Per le organizzazioni soggette al GDPR, la raccolta non autorizzata di email, credenziali e cronologia di navigazione attraverso estensioni malevole costituisce una violazione dei dati personali che richiede notifica all’autorità di controllo entro 72 ore dalla scoperta. Il fatto che la compromissione sia avvenuta attraverso un componente software installato dall’utente non esime l’organizzazione dalla responsabilità: la mancata governance delle estensioni browser sui dispositivi aziendali può essere contestata come inadeguatezza delle misure tecniche e organizzative previste dall’articolo 32.

Prospettive e scenari evolutivi

La traiettoria delle estensioni Chrome AI malevole nel 2026 suggerisce tre sviluppi che i professionisti della sicurezza dovrebbero anticipare.

Il primo è la convergenza tra estensioni malevole e agenti AI. Con l’adozione crescente di agenti AI che operano attraverso il browser – navigando siti, compilando moduli, interagendo con servizi web – le estensioni malevole possono intercettare, manipolare o reindirizzare le azioni degli agenti. Un’estensione che modifica silenziosamente il contenuto di una pagina prima che un agente AI lo processi può avvelenare le decisioni a valle senza lasciare tracce visibili.

Il secondo è la weaponization dei marketplace come canale di distribuzione. Il modello AiFrame dimostra che i marketplace ufficiali possono essere utilizzati come infrastruttura di distribuzione affidabile per campagne malevole su larga scala. La combinazione di extension spraying, iframe remoti e aggiornamenti server-side crea un modello di attacco altamente resiliente che le attuali policy di revisione degli store non sono in grado di contrastare efficacemente.

Il terzo è l’estensione del pattern ad altri ecosistemi. AgreeToSteal ha dimostrato che il medesimo modello di attacco – dipendenze remote dinamiche il cui contenuto può cambiare dopo l’approvazione – si applica agli add-in di Microsoft Office, ai plugin degli IDE come Visual Studio Code e potenzialmente a qualsiasi piattaforma che distribuisca componenti con dipendenze esterne non monitorate.

Conclusione: il browser non è più un’applicazione – è un perimetro

La settimana dell’11-16 febbraio 2026 ha reso evidente ciò che molti professionisti della sicurezza sospettavano da tempo: il browser è diventato un ambiente di esecuzione ad alto privilegio che opera al di fuori della governance tradizionale di endpoint e rete. Le estensioni Chrome AI malevole della campagna AiFrame, il dirottamento dell’add-in Outlook AgreeToSteal e la compromissione di massa di VK Styles non sono incidenti isolati. Sono manifestazioni di un problema architetturale che riguarda l’intero ecosistema dei marketplace software: il modello “approva una volta, fidati per sempre” è strutturalmente incompatibile con un panorama di minacce in cui gli attaccanti possono modificare il comportamento di un componente approvato in qualsiasi momento successivo alla revisione.

Per i CISO e i responsabili della sicurezza, la lezione operativa è chiara: il browser va trattato come parte integrante della superficie d’attacco enterprise, con governance, visibilità e capacità di risposta equivalenti a quelle applicate agli endpoint e ai servizi cloud. Senza questo cambio di paradigma, strumenti apparentemente innocui di produttività e personalizzazione continueranno a trasformarsi in canali di compromissione persistente che operano in piena vista.

Le estensioni Chrome AI malevole non sono una minaccia emergente. Sono una minaccia strutturale che richiede una risposta strutturale.

Fonti principali

LayerX Security – AiFrame: Fake AI Assistant Extensions Targeting 260,000 Chrome Users (febbraio 2026)

Koi Security – AgreeToSteal: The First Malicious Outlook Add-In (febbraio 2026)

Koi Security – VK Styles: 500K Users Infected (febbraio 2026)

BleepingComputer – Fake AI Chrome Extensions with 300K Users (febbraio 2026)

The Hacker News – Malicious Chrome Extensions Caught Stealing Business Data (febbraio 2026)

The Hacker News – First Malicious Outlook Add-In Found (febbraio 2026)

eSecurity Planet – 260K Users Exposed in AI Extension Scam (febbraio 2026)

The Record – Over 500,000 VKontakte Accounts Hijacked (febbraio 2026)

Cyberhaven – Chrome Extension Security Incident (dicembre 2024)

Hunters Security – Chrome Extension Threat Campaign (gennaio 2025)

Sekoia – Targeted Supply Chain Attack Against Chrome Browser Extensions (marzo 2025)

Q Continuum – Spying Chrome Extensions: 287 Extensions (febbraio 2026)

Barracuda Networks – The Hidden Cybersecurity Risk in Browser Extensions (25 febbraio 2026)

Incogni – Ranking AI-Powered Chrome Extensions by Privacy Risk 2026 (gennaio 2026)

Cybernews – Chrome Extensions: Too Many Dangerous Permissions (2025)

Infosecurity Magazine – Fake AI Assistants in Google Chrome Web Store (febbraio 2026)

LayerX Security – Enterprise Browser Extension Security Report 2025 (aprile 2025)

Stanford University e CISPA – What is in the Chrome Web Store? Investigating Security-Noteworthy Browser Extensions (giugno 2024)

MDSec – Abusing Office Web Add-ins (gennaio 2019)

MITRE ATT&CK – T1176 Browser Extensions

MITRE ATT&CK – T1539 Steal Web Session Cookie

MITRE ATT&CK – T1185 Browser Session Hijacking

MITRE ATT&CK – T1557 Adversary-in-the-Middle

https://www.ictsecuritymagazine.com/articoli/estensioni-chrome-ai-malevole/

Negli ultimi tempi il threat hunting “hypothesis-driven” è diventato la forma più evoluta di difesa proattiva.

Non si tratta semplicemente di cercare indicatori nei log o di fare ricerche casuali in un SIEM, l’idea di fondo è proprio diversa: partire da un’ipotesi concreta su come potrebbe agire un avversario e verificare, in modo strutturato, se nei nostri sistemi esistano tracce compatibili con quel comportamento.

In questo approccio il Threat hunter non aspetta un alert dato da una console. Non reagisce: anticipa.

Parte da una domanda investigativa costruita sulla base di intelligence, conoscenza delle TTP di tutti i Threat Actor (noti e non noti) e la reale comprensione dell’infrastruttura aziendale. L’obiettivo non è trovare “qualcosa di strano”, ma cercare evidenze coerenti con uno scenario d’attacco plausibile, anche se mai ancora intercettato dai meccanismi di detection tradizionali.

Threat Hunting Hypothesis-Driven: l’evoluzione dell’hunting proattivo

La maturità di un programma di threat hunting non si costruisce in un giorno, è un percorso evolutivo piuttosto chiaro (e prolungato).

All’inizio, molte organizzazioni svolgono attività sporadiche, spesso legate a IOC statici o a esigenze spot. Il logging a disposizione è spesso limitato, le analisi sono manuali e guidate dal buon senso, di conseguenza, non esiste un processo formalizzato. In questa fase l’hunting è più un’iniziativa individuale che un servizio strutturato.

Con il tempo, però, l’approccio può maturare grazie ad esperienza e lesson learned (se viene svolto anch’esso in modo strutturato). L’Hunting Maturity Model (https://www.sans.org/tools/hunting-maturity- model) descrive questa evoluzione considerando diversi fattori: qualità e ampiezza delle fonti dati, formalizzazione delle ipotesi e scopes, competenze analitiche del team e integrazione con il detection engineering del SOC o dell’Incident Response Team.

Quando la maturità aumenta, crescono anche le fonti disponibili: endpoint telemetry, network data, identity logs, audit trail cloud. Framework come MITRE ATT&CK o MITRE D3FEND iniziano a essere usati per modellare le ipotesi e strutturare i report. Nei livelli più avanzati, l’hunting diventa ciclico, misurabile e integrato nel miglioramento continuo: ogni attività produce nuove regole, identifica gap di visibilità o rafforza la copertura esistente.

Un passaggio cruciale in questo percorso è l’abbandono dell’approccio “IOC driven” statico in favore di quello “TTP driven”. Gli indicatori sono fragili, cambiano rapidamente e possono essere facilmente aggirati. Le tecniche, invece, riflettono il modus operandi dell’avversario e tendono a essere più stabili nel tempo.

Ma lavorare sulle TTP richiede esperienza reale e conoscenza degli attori, esposizione a casi concreti, capacità di riconoscere varianti e polimorfismi delle tecniche durante attacchi effettivi.

Un hunting efficace non nasce nel vuoto. Senza intelligence, l’ipotesi rischia di essere astratta o scollegata dal contesto reale.

La Cyber Threat Intelligence fornisce il punto di partenza: attori attivi, campagne in corso, tecniche emergenti, pattern infrastrutturali. Tuttavia, il valore non sta nel report in sé, ma nella capacità di trasformarlo in una domanda operativa.

Se un report descrive l’abuso di token OAuth in ambienti cloud, non è sufficiente conoscere hash o domini. La domanda diventa: “Se un attore con queste capacità stesse operando nel nostro tenant, quali tracce comportamentali dovremmo osservare?”

Da qui nascono query su anomalie nei consensi applicativi, uso atipico di API, persistenza tramite service principal o comportamenti anomali su identity logs.

L’integrazione deve essere bidirezionale. La CTI alimenta l’hunting, ma i risultati dell’hunting evidenze, falsi positivi ricorrenti, nuove tecniche osservate devono a loro volta arricchire il ciclo di intelligence. Solo così si crea un ecosistema realmente dinamico.

Proviamo a vedere assieme un esempio applicato:

Un report CTI segnala che un gruppo sta abusando di service principal in Microsoft 365 per ottenere persistenza tramite permessi API elevati.

Il team di Threat Hunting parte da questa informazione e verifica creazioni recenti di service principal, assegnazioni anomale di privilegi e autenticazioni sospette. Durante l’analisi emergono però due aspetti inattesi: un’applicazione legittima che replica parte di quel comportamento (falso positivo ricorrente) e una tecnica non documentata di assegnazione temporanea dei permessi seguita da revoca immediata. Queste evidenze vengono condivise con il team CTI, che aggiorna il proprio dataset inserendo il nuovo pattern e riclassificando alcuni indicatori come deboli.

In questo modo l’intelligence genera l’hunting, ma è l’hunting stesso a renderla più precisa e aderente al contesto reale.

Il “TTP driven” hunting si basa su una struttura logica chiara:

• scope
• comportamento atteso
• artefatti generati
• fonti dati disponibili
• criteri di validazione

Prendiamo un caso classico: LSASS memory dumping. L’errore sarebbe cercare direttamente “Mimikatz” “mimi*”.

L’ipotesi corretta per questo tipo d’attività è più ampia: “Un attore che intende effettuare credential access potrebbe generare accessi sospetti al processo LSASS, creare handle privilegiati o produrre dump di memoria anomali.”

L’analisi si concentra quindi su eventi EDR relativi a process access, creazione di file dump, utilizzo inconsueto di API di debugging, e se il logging lo permette (difficile) valutare le syscalls utilizzate nella finestra temporale in scope. Non si cerca uno strumento specifico, ma un comportamento.

In scenari più complessi, ad esempio lateral movement tramite WebDAV combinato con NTLM relay in ambienti ibridi, l’ipotesi diventa molto più articolata. Non si cerca “ntlmrelayx”, ma si formula una correlazione comportamentale.

Nella mente del threat hunter potrebbe esserci una frase di questo tipo:

“Se un attore stesse tentando un relay NTLM via WebDAV, potremmo trovare autenticazioni NTLM anomale verso servizi interni, precedute da traffico WebDAV outbound atipico.”

L’attività di hunting si sposta quindi sulla correlazione temporale tra:

• richieste HTTP con metodo PROPFIND o traffico WebDAV inconsueto,
• autenticazioni NTLM verso target interni non usuali,
• accessi SMB o HTTP privi di signing

Anche in assenza di compromissione confermata, un’attività del genere può portare alla scoperta di debolezze strutturali: SMB signing non abilitato, Extended Protection non enforced, logging insufficiente. Il valore, quindi, non è solo individuare un attacco, ma rafforzare l’architettura.

Architettura e strumenti: la base tecnica

Un approccio hypothesis driven richiede una base dati coerente e realmente interrogabile. Se, ad esempio, i log di identity vengono conservati solo per 7 giorni, un’ipotesi su una persistenza di 30 giorni diventa semplicemente non verificabile. Allo stesso modo, un SIEM con parsing incompleto dei log cloud può impedire di correlare un’attività sospetta su Azure AD con un evento su endpoint, frammentando l’analisi.

In ambienti più complessi, un’architettura data lake-oriented consente di centralizzare log eterogenei (endpoint, network, SaaS, IaaS) e di normalizzarli. Questo permette, ad esempio, di testare un’ipotesi che correli autenticazioni anomale, creazione di nuove VM e traffico verso ASN a rischio in un’unica query, anziché tramite analisi manuali separate.

La scelta degli strumenti incide direttamente sulla profondità dell’hunting: senza EDR con visibilità su process tree e command-line, non è possibile validare ipotesi su tecniche di “living off the land”; senza NDR, un beacon a basso rumore su protocollo DNS può rimanere invisibile; senza strumenti di identity analytics, pattern di privilege escalation graduale possono sembrare attività amministrative legittime.

Anche il linguaggio di query è parte dell’architettura: un ambiente che supporta KQL o SPL con join efficienti e funzioni di aggregazione avanzate consente pivot rapidi e analisi iterative. Se invece il motore non gestisce correlazioni complesse o soffre di latenze elevate, l’hunting perde profondità e diventa superficiale.

Nei contesti più maturi, la disponibilità di modelli comportamentali e baseline storiche abilita analisi di deviazione reali: ad esempio, identificare un service account che accede per la prima volta a una risorsa sensibile fuori dal proprio perimetro abituale.

L’automazione accelera enrichment, contestualizzazione e raccolta di indicatori, ma non sostituisce il ragionamento. Quando l’ipotesi riguarda una tecnica emergente o un comportamento ambiguo, è la qualità dell’architettura sottostante retention, normalizzazione, capacità di correlazione a determinare se l’hunter potrà davvero dimostrarla o dovrà fermarsi a un sospetto.

Elementi infrastrutturali fondamentali per il Threat Hunting

• Retention adeguata dei log
  • almeno 6–12 mesi per identity, endpoint e cloud activities
• Normalizzazione e data modeling coerente tra fonti diverse
• Visibilità endpoint avanzata
  • process tree, command-line, registry, scheduled task, network connections
• Telemetria di rete est–ovest e north–south
  • con capacità di analisi comportamentale
• Logging completo del piano di controllo cloud
  • audit log, API call, IAM changes
• Identity telemetry dettagliata
  • token issuance, conditional access, MFA events, service principal activity
• Motore di query performante e flessibile
  • con supporto a join, aggregazioni e funzioni temporali
• Integrazione CTI strutturata
  • con indicator scoring e gestione della qualità degli IOC
• Capacità di enrichment automatizzato
  • WHOIS, passive DNS, reputation, asset context
• Baseline comportamentali e dataset storici
  • Anche se questo elemento solitamente è molto complesso da ottenere ed indica una grande maturità aziendale, per le analisi di deviazione strutturate resta un asset fondamentale

In assenza completa o parziale di questi elementi, l’hunting tende a ridursi a ricerca reattiva di indicatori; con essi, diventa un’attività esplorativa e realmente orientata alla scoperta.

Uno degli errori più comuni è considerare l’hunting un esercizio teorico. In realtà, ogni ciclo deve produrre risultati tangibili.

Gli output principali si possono ricondurre a tre categorie:

1. Compromissioni identificate
2. Miglioramenti al detection engineering
3. Aumento della visibilità del rischio

Anche un hunting che non rileva incidenti può avere grande valore. Ad esempio, può evidenziare che una tecnica ATT&CK non è coperta da alcuna telemetria disponibile.

La formalizzazione è fondamentale: descrizione dell’ipotesi, dataset analizzati, query utilizzate, risultati ottenuti e decisioni operative. Questo garantisce tracciabilità, auditability e, in contesti regolamentati, dimostrazione di due diligence.

Il threat hunting hypothesis-driven è, per natura, iterativo. Ogni attività alimenta la successiva.

Se un’ipotesi si rivela valida e genera una nuova detection rule (ad esempio implementata anche tramite Sigma o Yara), quella tecnica entra nel monitoraggio continuo, riducendo la necessità di future analisi manuali sullo stesso pattern.

Se emergono gap come l’assenza di logging su specifici eventi, questi devono tradursi in remediation tecnica. In questo modo l’hunting diventa uno strumento diretto di crescita della maturità complessiva.

Il feedback coinvolge anche il team: le tecniche analizzate, le query sviluppate e i casi reali diventano materiale per esercitazioni e tabletop, rafforzando il pensiero analitico e la capacità di modellare ipotesi.

Gli strumenti sono importanti, ma non sono l’elemento decisivo.

Un threat hunter efficace deve saper ragionare per ipotesi, evitare bias cognitivi e comprendere a fondo il funzionamento reale di sistemi operativi, protocolli di rete, Active Directory e workload cloud. Senza una chiara percezione del comportamento “normale” dell’infrastruttura, è impossibile riconoscere l’anomalia significativa.

Serve padronanza dei linguaggi di query, capacità di correlare fonti eterogenee e lettura critica della telemetria. Ma soprattutto serve metodo nel trasformare un insight di CTI o una TTP in una domanda tecnica verificabile sui dati.

Il valore del threat hunting non dipende solo dalla tecnologia adottata (anzi, la tecnologia in questi casi rappresenta solo una parte del valore legata a questo tipo d’attività). Il risultato, infatti, dipende dalla qualità analitica di chi la utilizza e dalla capacità dell’organizzazione di integrare l’hunting in un processo strutturato, misurabile e orientato al miglioramento continuo.

Stay Safe. Be Proactive.

https://www.ictsecuritymagazine.com/articoli/threat-hunting-hypothesis-driven/

La frode occupazionale nordcoreana assistita dall’intelligenza artificiale ha superato la soglia dell’episodio isolato. È diventata un’operazione industriale, sistematica, globale, e sorprendentemente efficace.

Nel luglio 2024, KnowBe4 – una delle aziende più note nel settore della security awareness – ha rivelato pubblicamente di aver assunto un ingegnere software che si è rivelato essere un operativo nordcoreano. Il candidato aveva superato quattro colloqui video, verifiche referenziali, background check. La sua foto era un’immagine stock modificata con AI. Quando il laptop aziendale è arrivato all’indirizzo indicato, il SOC team ha rilevato attività sospette: caricamento di malware, manipolazione dei file di sessione, esecuzione di software non autorizzato. Come ha scritto il CEO Stu Sjouwerman con disarmante onestà: se è successo a noi, può succedere a chiunque.

Un anno dopo, sappiamo che è successo a molti. A moltissimi. Secondo quanto riportato da Axios nell’agosto 2025, nove responsabili della sicurezza su nove intervistati hanno dichiarato di non aver ancora incontrato un’azienda Fortune 500 che non abbia inconsapevolmente assunto almeno un lavoratore IT nordcoreano. CrowdStrike, nel suo Threat Hunting Report 2025, ha documentato un incremento del 220% delle infiltrazioni nell’ultimo anno, con oltre 320 aziende compromesse – attività attribuita al cluster che l’azienda traccia come Famous Chollima, attivo almeno dal 2018. Google stessa ha ammesso alla RSA Conference di maggio 2025 di aver ricevuto candidature nordcoreane. SentinelOne idem. Il fenomeno non è un’anomalia: è una condizione strutturale del mercato del lavoro tecnologico remoto.

Ma è il Threat Intelligence Report di Anthropic dell’agosto 2025 ad aver introdotto la dimensione che trasforma questa minaccia da problema HR a questione di sicurezza nazionale e di paradigma: la dipendenza totale dall’AI. Gli operativi nordcoreani documentati da Anthropic non sono programmatori competenti che usano l’intelligenza artificiale per lavorare più velocemente. Sono persone che non sanno scrivere codice, non parlano inglese in modo professionale, non comprendono i riferimenti culturali americani – eppure mantengono impieghi a tempo pieno come ingegneri software in aziende Fortune 500. L’AI non amplifica le loro competenze: le sostituisce integralmente.

Questo articolo ricostruisce l’intero ciclo della frode occupazionale nordcoreana nell’era dell’AI – dalla costruzione dell’identità alla monetizzazione per i programmi di armamento – e ne analizza le implicazioni per chi deve ripensare i processi di hiring, compliance e sicurezza interna.

Dal Dipartimento 53 all’AI: lo shift paradigmatico

Per comprendere cosa l’AI ha cambiato, occorre prima comprendere cosa c’era prima.

La Corea del Nord ha reso la tecnologia informatica una priorità nazionale sotto Kim Jong Un a partire dal 2011. Secondo il National Intelligence Service sudcoreano, il personale nelle divisioni cyber della DPRK è cresciuto da 6.800 unità nel 2022 a 8.400 nel 2024, includendo infiltratori IT, ladri di criptovalute e hacker militari. Le operazioni IT fraudolente sono gestite dal Dipartimento 53 dell’Ufficio Generale di Ricognizione (RGB – Reconnaissance General Bureau), l’agenzia di intelligence militare nordcoreana, specializzato nell’evasione delle sanzioni attraverso il lavoro IT. Il programma opera in parallelo con i più noti gruppi cyber offensivi nordcoreani – Labyrinth Chollima (spionaggio), Stardust Chollima (furto finanziario) – ma con un mandato distinto: generazione di valuta estera attraverso l’impiego fraudolento.

Il modello tradizionale funzionava così: giovani selezionati venivano formati in scuole d’élite a Pyongyang e dintorni, acquisivano competenze tecniche reali nell’arco di anni, e venivano poi dispiegati in team di quattro o cinque persone in Cina, Russia, Nigeria, Cambogia, Emirati Arabi Uniti. Il collo di bottiglia era la formazione. Per generare un operativo funzionale servivano anni di investimento in addestramento specialistico, e la capacità formativa del regime era il vincolo operativo principale che limitava la scala delle operazioni.

L’AI ha eliminato quel vincolo.

Come ha sintetizzato il team di threat intelligence di Anthropic: non serve conoscere l’inglese, non serve conoscere il contesto culturale degli Stati Uniti, non servono competenze tecniche – perché l’AI può aiutarti a superare ciascuna di queste barriere. Il passaggio è da un modello training-intensive (formazione pluriennale d’élite) a un modello AI-augmented (operativi con competenze minime potenziati dall’assistenza AI in tempo reale). La capacità formativa del regime non è più il fattore limitante. Lo è la disponibilità di modelli linguistici sufficientemente capaci – una risorsa che, per definizione, è abbondante e in rapida crescita.

L’anatomia della frode: quattro fasi, un solo obiettivo

L’operazione di frode occupazionale nordcoreana nell’era dell’AI si articola in quattro fasi distinte, ciascuna trasformata in modo radicale dall’integrazione dell’intelligenza artificiale. La nomenclatura dei threat actor varia tra i vendor di threat intelligence: CrowdStrike traccia questa attività come Famous Chollima (precedentemente BadClone), Microsoft come Jasper Sleet (in precedenza Storm-0287), Secureworks come Nickel Tapestry, Mandiant/Google come UNC5267. Sebbene le tassonomie differiscano, i cluster si sovrappongono sostanzialmente nella descrizione delle tattiche e dell’infrastruttura operativa.

Fase 1 – Persona development: identità sintetiche su scala industriale

La prima fase è la costruzione dell’identità. Gli operativi utilizzano identità rubate o sintetiche di cittadini statunitensi, corredate da documentazione fraudolenta: passaporti, patenti, Social Security Number. Microsoft, nella sua analisi del cluster Jasper Sleet, ha documentato il ritrovamento di un repository contenente immagini migliorate con AI di sospetti operativi nordcoreani, insieme a curriculum, account email e infrastrutture VPN. Il report dettaglia l’uso di software di alterazione vocale e strumenti di video AI per mascherare l’identità durante i colloqui.

L’AI interviene a ogni livello di questo processo. Genera foto profilo professionali a partire da immagini stock (come nel caso KnowBe4, dove un’immagine stock è stata trasformata in una foto professionale convincente tramite AI). Crea profili LinkedIn coerenti con carriere plausibili. Produce portfolio tecnici su GitHub con progetti credibili. Elabora narrative professionali consistenti che reggono al vaglio dei recruiter. Un singolo operativo può gestire identità multiple: Google GTIG ha identificato un individuo che operava almeno 12 personae distinte contemporaneamente, candidandosi per ruoli in Europa e negli Stati Uniti, incluse posizioni nel settore della difesa e in enti governativi.

La rete di supporto comprende i “facilitatori” – cittadini statunitensi o di altri Paesi che gestiscono le cosiddette laptop farm: stanze piene di laptop aziendali, ciascuno associato a un’identità e a un’azienda diversa, controllati da remoto dagli operativi tramite strumenti RMM (Remote Monitoring and Management) come AnyDesk, RustDesk e Google Chrome Remote Desktop. Christina Marie Chapman, una donna dell’Arizona, ha gestito fino a 90 laptop contemporaneamente prima di essere condannata nel 2025 a otto anni di reclusione. Il DOJ ha annunciato nel giugno 2025 operazioni coordinate in 16 stati, con perquisizioni di 29 laptop farm, sequestro di 29 conti bancari e 21 siti web fraudolenti.

Fase 2 – Application e interview: l’esame che supera l’esaminatore

La seconda fase è il processo di selezione. È qui che la frode occupazionale nordcoreana raggiunge il suo paradosso più inquietante: candidati che non possiedono le competenze per il ruolo superano processi di selezione tecnica progettati per verificare esattamente quelle competenze.

I dati del report Anthropic rivelano la distribuzione dell’utilizzo di AI da parte degli operativi nordcoreani durante le interazioni documentate:

La concentrazione sul frontend (61%) non è casuale. I ruoli di sviluppo frontend – React, Vue.js, Angular – offrono tre vantaggi operativi specifici: sono tra le posizioni remote più richieste e disponibili nel mercato tech, producono output visivamente verificabili (un’interfaccia che funziona è una prova tangibile di competenza), e sono sufficientemente modulari da poter essere gestiti con assistenza AI per singoli componenti senza necessità di comprendere l’architettura complessiva del sistema.

Per superare i coding assessment, gli operativi si affidano all’AI in tempo reale. L’AI risolve problemi algoritmici, genera codice funzionale, e produce risposte tecniche convincenti. Ma il supporto non si limita all’aspetto tecnico: l’AI assiste anche nella comprensione dei riferimenti culturali americani – una necessità operativa che rivela la profondità della dipendenza. In un caso documentato, un operativo ha chiesto all’AI spiegazioni su cosa fosse un muffin. In un altro, su come rispondere a domande informali sui piani per il weekend.

Le strutture di interview sono spesso organizzate gerarchicamente. Come ha spiegato Trevor Hilligoss di SpyCloud Labs ad Axios: esiste una gerarchia, un gruppo di persone che sono gli intervistatori specializzati con competenze linguistiche in inglese. Quando ottengono l’assunzione, il ruolo viene trasferito a qualcuno che è uno sviluppatore. Quegli sviluppatori gestiscono spesso più impieghi e più identità simultaneamente.

Fase 3 – Employment maintenance: l’80% che sostiene la finzione

La terza fase è il mantenimento dell’impiego. Ed è forse la più rivelatrice, perché dimostra che la frode non si esaurisce con l’assunzione: richiede un sostegno continuo, sessione dopo sessione, giorno dopo giorno.

Secondo l’analisi di Anthropic, circa l’80% dell’utilizzo di AI da parte degli operativi nordcoreani è compatibile con il mantenimento di un impiego attivo: risolvere bug, implementare feature, rispondere a richieste dei colleghi, partecipare alle code review, gestire la comunicazione professionale quotidiana. Non si tratta di un uso sporadico o di un supporto marginale. È una dipendenza operativa totale: senza l’AI, queste persone non potrebbero svolgere il lavoro per cui sono pagate.

Come ha osservato Okta Threat Intelligence nella sua analisi dell’aprile 2025, l’AI generativa svolge un ruolo integrale nel modo in cui gli operativi nordcoreani ottengono e mantengono impieghi tecnici remoti. I servizi AI vengono utilizzati per gestire le comunicazioni di personae multiple e i loro numerosi account telefonici, di messaggistica istantanea, email e chat; per tradurre, trascrivere e riassumere comunicazioni; e per assistere nella produzione tecnica quotidiana.

Okta ha tracciato oltre 130 identità collegate a facilitatori e operativi DPRK, associandole a oltre 6.500 colloqui iniziali presso più di 5.000 aziende distinte fino alla metà del 2025. Il dato sulla percentuale di successo, per quanto limitato al campione analizzato, è allarmante: anche una piccola percentuale di candidature che raggiungono il secondo o terzo colloquio rappresenta una minaccia significativa, perché basta una singola assunzione compromessa – particolarmente in un ruolo remoto con accesso privilegiato – per consentire furti di dati, disruption di sistemi o danni reputazionali.

Un aspetto particolarmente insidioso è l’auto-disruption involontaria. Nel caso ribattezzato “Sneer Review” dalla comunità di sicurezza, operativi nordcoreani hanno chiesto all’AI di scrivere le proprie performance review aziendali – includendo inavvertitamente dettagli che descrivevano le attività criminali sottostanti. L’eccessiva dipendenza dall’AI genera errori operativi che, al momento, rappresentano una vulnerabilità sfruttabile. Ma come ha osservato l’analisi di IronScales, questa finestra di rilevamento è temporanea: man mano che gli operativi diventano più sofisticati nell’uso dell’AI, o l’AI diventa più capace di operational security, questo vantaggio difensivo svanisce.

Fase 4 – Revenue generation: centinaia di milioni per i programmi di armamento

La quarta fase è la monetizzazione. Ed è qui che la frode occupazionale nordcoreana trascende il perimetro del cybercrime e diventa una questione di sicurezza internazionale.

La dimensione finanziaria è documentata con granularità crescente. Secondo l’advisory congiunto del 2022 di FBI, Dipartimento di Stato e Dipartimento del Tesoro USA, i singoli lavoratori IT possono guadagnare fino a 300.000 dollari annui, generando collettivamente centinaia di milioni di dollari ogni anno per conto di entità designate, incluso il Ministero della Difesa nordcoreano.

Un dato più granulare proviene dall’incriminazione DOJ dell’11 dicembre 2024: 14 cittadini nordcoreani, dipendenti delle società controllate dal regime Yanbian Silverstar (Cina) e Volasys Silverstar (Russia), hanno generato almeno 88 milioni di dollari in sei anni (aprile 2017 – marzo 2023) attraverso impieghi IT fraudolenti presso aziende e organizzazioni non-profit statunitensi. Le due società impiegavano almeno 130 “IT Warriors” – lavoratori sottoposti a “socialism competitions” che premiavano chi generava il maggior fatturato. Ciascun imputato rischia fino a 27 anni di reclusione per cospirazione in violazione dell’International Emergency Economic Powers Act (IEEPA), frode telematica, riciclaggio e furto d’identità.

Il Dipartimento del Tesoro USA ha specificato nel novembre 2025 che i proventi vengono incanalati verso i programmi nucleari e balistici del regime – il governo nordcoreano trattiene fino al 90% degli stipendi. Non è un’astrazione: negli ultimi tre anni, i cybercriminali affiliati alla Corea del Nord hanno rubato oltre 3 miliardi di dollari, prevalentemente in criptovalute. Nel primo semestre 2025, secondo Chainalysis, gli hacker nordcoreani sono stati responsabili di furti per circa 1,5 miliardi di dollari su un totale globale di oltre 2 miliardi.

Il flusso finanziario segue percorsi multipli: stipendi incanalati attraverso conti bancari gestiti dai facilitatori, pagamenti in criptovaluta per oscurare origine e destinazione dei fondi, sfruttamento di piattaforme come Payoneer e Wise (già TransferWise) per i trasferimenti internazionali. Ma la frode occupazionale non genera solo reddito diretto. In un numero crescente di casi, come documentato da GTIG nell’aprile 2025, gli operativi licenziati hanno iniziato a praticare estorsione: minacciano di rilasciare dati proprietari e codice sorgente rubati durante l’impiego se le richieste di riscatto non vengono soddisfatte. L’incriminazione DOJ conferma questa escalation: più di un datore di lavoro ha subito danni per centinaia di migliaia di dollari dopo aver rifiutato il pagamento.

L’espansione globale: dall’America all’Europa, la frode occupazionale nordcoreana cambia geografia

La pressione investigativa statunitense ha prodotto un effetto collaterale prevedibile: la frode si è globalizzata.

Il report GTIG dell’aprile 2025 ha documentato un incremento significativo delle operazioni in Europa, con focus particolare su Germania, Portogallo e Regno Unito. Gli operativi si presentano come cittadini di Paesi diversi – Italia, Giappone, Malesia, Singapore, Ucraina, Vietnam – e vengono reclutati attraverso piattaforme come Upwork, Freelancer e Telegram. Nel Regno Unito, GTIG ha osservato un portafoglio diversificato di progetti: sviluppo web, bot development, sistemi di gestione dei contenuti, applicazioni blockchain e AI – inclusi smart contract Solana in Anchor/Rust e piattaforme di hosting token costruite con Next.js e CosmosSDK.

Per l’Europa, questa espansione assume una rilevanza strategica ulteriore. ENISA, nel suo Threat Landscape 2025, ha classificato le intrusioni cyber nordcoreane come la terza minaccia più significativa per i Paesi dell’UE – sopra l’Iran. Con l’avvio del piano ReArm Europe e l’impegno NATO al 5% di spesa per la difesa, le aziende europee del settore difesa e aerospazio diventano target ad alto valore non solo per la monetizzazione, ma per lo spionaggio industriale: almeno 12 personae nordcoreane sono state identificate da GTIG mentre cercavano attivamente impiego in entità del settore difesa e governativo europeo.

Il quadro normativo: NIS2, AI Act e regime sanzionatorio UE

Per le organizzazioni italiane ed europee, l’espansione della frode occupazionale nordcoreana introduce un intreccio di rischi normativi che merita un’analisi puntuale.

Regime sanzionatorio UE. Il Regolamento (UE) 2017/1509, che recepisce e amplia le risoluzioni del Consiglio di Sicurezza ONU, vieta esplicitamente la fornitura di servizi informatici alla DPRK e il congelamento dei beni di persone ed entità designate. L’articolo 52 proibisce la partecipazione consapevole e intenzionale ad attività che eludano le sanzioni.

Per le aziende europee che assumono inconsapevolmente operativi DPRK, il rischio risiede nella strict liability che caratterizza molti regimi sanzionatori: la mancata due diligence nell’identificazione del beneficiario effettivo dei pagamenti può configurare una violazione anche in assenza di dolo. A maggio 2024, il Consiglio ha ulteriormente ampliato le designazioni, portando il totale a 77 individui e 20 entità sanzionate autonomamente dall’UE. Negli Stati Uniti, l’Office of Foreign Assets Control (OFAC) del Tesoro applica un approccio analogo: le aziende che effettuano pagamenti a beneficio di entità DPRK – anche indirettamente, attraverso stipendi a operativi sotto falsa identità – si espongono a sanzioni civili e penali.

NIS2 (Direttiva UE 2022/2555). L’articolo 21 della direttiva, recepita in Italia con il D.lgs. 138/2024, impone obblighi stringenti di gestione del rischio che includono esplicitamente la sicurezza delle risorse umane (articolo 21, comma 2, lettera g) e la sicurezza della supply chain (articolo 21, comma 2, lettera d). L’assunzione inconsapevole di un operativo DPRK interseca entrambe le dimensioni.

Quanto agli obblighi di notifica, l’articolo 23 (articolo 25 nel D.lgs. 138/2024) richiede la segnalazione di incidenti significativi al CSIRT Italia. L’obbligo è operativo dal 15 gennaio 2026, secondo la Determina ACN n. 379887 del 19 dicembre 2025. Un incidente è significativo quando soddisfa almeno uno di due criteri alternativi (articolo 23, paragrafo 3): (a) ha causato o è in grado di causare una grave perturbazione operativa dei servizi o perdite finanziarie per il soggetto interessato; (b) si è ripercosso o è in grado di ripercuotersi su altre persone fisiche o giuridiche causando perdite materiali o immateriali considerevoli.

Il Regolamento di esecuzione della Commissione europea specifica ulteriormente: un incidente è significativo se, tra l’altro, ha causato o è in grado di causare una perdita finanziaria superiore a 500.000 euro o al 5% del fatturato annuo, oppure ha comportato un accesso non autorizzato a sistemi informativi sospettato di essere doloso.

È fondamentale una precisazione operativa: la mera scoperta di un operativo DPRK tra i dipendenti non attiva automaticamente l’obbligo di notifica. L’obbligo scatta se l’operativo ha effettivamente causato o è in grado di causare un impatto significativo – ad esempio attraverso esfiltrazione di dati sensibili, accesso non autorizzato a sistemi critici, o compromissione della disponibilità dei servizi. La valutazione è contestuale e richiede un’analisi dell’impatto effettivo, non della mera presenza dell’insider. Tuttavia, data la tendenza documentata all’estorsione post-licenziamento e all’esfiltrazione proattiva durante l’impiego, il rischio che la scoperta evolva in un incidente significativo è concreto e richiede una gestione proattiva.

AI Act (Regolamento UE 2024/1689). In un contesto in cui l’AI Act richiede governance e trasparenza nell’uso dei sistemi AI, la presenza di un operativo che utilizza AI non governata su infrastrutture aziendali crea una superficie di rischio normativo inedita. I sistemi AI utilizzati per la gestione delle risorse umane – inclusi screening e selezione dei candidati – sono classificati come “ad alto rischio” dall’Allegato III, con requisiti di conformità pienamente applicabili da agosto 2026.

Contagious Interview: l’altra faccia della medaglia nordcoreana

La frode occupazionale nordcoreana non opera in un vuoto. Si inserisce in un ecosistema più ampio di operazioni DPRK che include la campagna Contagious Interview, documentata da Unit 42 di Palo Alto Networks fin dal 2023 e attribuita al cluster Famous Chollima (che gestisce sia le operazioni di infiltrazione occupazionale sia la campagna Contagious Interview, pur con sotto-cluster distinti).

Se la frode occupazionale vede gli operativi nordcoreani candidarsi come lavoratori, Contagious Interview ribalta lo schema: gli operativi si fingono recruiter e attirano sviluppatori legittimi a installare malware mascherato da tool per colloqui o test di codifica. I vettori primari includono le famiglie malware BeaverTail (info-stealer JavaScript) e InvisibleFerret (backdoor Python). Le due campagne sono complementari e talvolta interconnesse. SentinelOne ha identificato oltre 230 vittime nel solo periodo gennaio-marzo 2025, con il numero reale probabilmente molto più elevato. La campagna ha continuato a evolversi: nel luglio 2025, Socket Research ha scoperto 67 nuovi pacchetti npm malevoli contenenti il malware loader XORIndex, con oltre 9.000 download complessivi – un attacco alla supply chain software che colpisce sviluppatori ignari.

Anthropic ha documentato nel suo report di agosto 2025 la disruption proattiva della campagna Contagious Interview sulla propria piattaforma: gli account associati sono stati identificati e bannati automaticamente prima che gli operativi potessero eseguire qualsiasi prompt. Questo intervento ha potenzialmente impedito lo sfruttamento di Claude per potenziare una campagna che ha successivamente compromesso oltre 140 vittime globali secondo la ricerca esterna di sicurezza.

La coesistenza di queste due campagne – una che infiltra le aziende attraverso il processo di assunzione, l’altra che colpisce gli sviluppatori attraverso falsi processi di selezione – crea un doppio vettore di minaccia che satura l’intero ecosistema del recruiting tecnologico.

Limiti dell’analisi e controargomentazioni

Un’analisi rigorosa della frode occupazionale nordcoreana AI-assisted richiede di considerare anche i limiti della narrazione e le controargomentazioni emerse dalla ricerca.

L’efficacia operativa reale è incerta. I dati disponibili documentano la scala delle candidature e delle assunzioni, ma offrono meno visibilità sulla qualità effettiva del lavoro prodotto. KnowBe4 ha riportato che l’operativo individuato non ha avuto accesso a dati sensibili grazie al rilevamento tempestivo del SOC team. Altre aziende hanno ammesso informalmente che il lavoro prodotto dagli operativi era sufficiente – a volte persino buono. La dipendenza dall’AI non implica necessariamente output scadente: implica che l’output non riflette competenze genuinamente possedute dall’operatore.

Le difese funzionano – quando implementate. L’incremento delle azioni del DOJ (cinque guilty plea e oltre 15 milioni di dollari in forfeiture solo nel novembre 2025), le sanzioni OFAC, e la crescente consapevolezza del settore privato stanno producendo risultati. Gli operativi incontrano difficoltà crescenti negli Stati Uniti, il che ha determinato lo spostamento verso l’Europa. La pressione funziona – ma sposta il problema anziché risolverlo.

L’AI è un amplificatore, non un creatore di minacce nuove. Come ha osservato il Google Threat Intelligence Group nel report di febbraio 2026, l’AI potenzia e accelera tecniche esistenti senza crearne di inedite. La frode occupazionale nordcoreana esisteva prima dell’AI generativa. L’AI l’ha resa più scalabile, più convincente e meno dipendente dalla formazione specialistica – ma il vettore fondamentale resta l’ingegneria sociale applicata al processo di assunzione, non una capacità tecnologica rivoluzionaria.

Il rischio dell’overreaction. Esiste il pericolo concreto che la risposta alla minaccia DPRK produca processi di hiring eccessivamente restrittivi che penalizzino candidati legittimi, in particolare quelli provenienti da contesti internazionali. Qualsiasi misura di mitigazione deve bilanciare sicurezza e inclusività, evitando forme di profilazione che sarebbero tanto inefficaci quanto discriminatorie.

Implicazioni operative: cosa deve cambiare nei processi di hiring e compliance

La frode occupazionale nordcoreana impone un ripensamento strutturale che attraversa HR, sicurezza informatica, compliance e governance aziendale.

Verifica dell’identità oltre il background check tradizionale. I background check convenzionali non sono progettati per rilevare identità sintetiche supportate da AI. L’FBI raccomanda di richiedere durante i colloqui video che il candidato compia gesti davanti al viso per verificare eventuali malfunzionamenti di video AI-generated.

Catturare immagini per confronto con incontri futuri è altrettanto critico, poiché in molti casi chi sostiene il colloquio non è la stessa persona che svolge poi il lavoro. Inviare l’hardware esclusivamente all’indirizzo presente nei documenti di identità – e richiedere documentazione aggiuntiva per qualsiasi richiesta di modifica dell’indirizzo – è una misura semplice ma efficace. La verifica deve includere anche il confronto delle credenziali con database di identità compromesse e la validazione incrociata dei dati fiscali (SSN negli USA, codice fiscale in Italia).

Monitoraggio comportamentale post-assunzione. La detection non può limitarsi alla fase di hiring. Pattern di accesso in orari anomali (lavoro notturno mascherato da fuso orario diverso), utilizzo di software RMM non autorizzato (AnyDesk, RustDesk – gli stessi strumenti documentati da CrowdStrike nelle indagini Famous Chollima), modifiche frequenti dei conti bancari per la ricezione dello stipendio, discrepanze tra geolocalizzazione dichiarata e reale – sono tutti indicatori che richiedono monitoraggio continuo e correlazione. CrowdStrike raccomanda specificamente di verificare che i dipendenti remoti appaiano in camera il più frequentemente possibile e di correlare i log di accesso con le informazioni di geolocalizzazione.

Policy BYOD e ambienti virtualizzati. GTIG ha evidenziato che gli operativi DPRK hanno identificato gli ambienti BYOD (Bring Your Own Device) come particolarmente vulnerabili, poiché spesso mancano di strumenti di endpoint detection e monitoraggio. Le organizzazioni che consentono BYOD per ruoli IT remoti devono valutare se i controlli di sicurezza siano adeguati a questo specifico profilo di minaccia. L’invio di dispositivi aziendali gestiti, con EDR preinstallato e policy di accesso condizionato, riduce significativamente la superficie di attacco.

Cross-functional response team. La risposta alla minaccia DPRK non può essere responsabilità esclusiva del CISO o dell’HR. Richiede un team interfunzionale che includa sicurezza informatica, risorse umane, ufficio legale, compliance e, nelle organizzazioni soggette a sanzioni o controlli all’esportazione, il responsabile export control. Come ha sottolineato Crowell & Moring nella sua analisi degli enforcement action del DOJ, le aziende che assumono inconsapevolmente operativi DPRK si espongono a rischi che spaziano dalle violazioni delle sanzioni OFAC (negli USA) e del Regolamento 2017/1509 (nell’UE) al furto di proprietà intellettuale, fino a potenziali responsabilità penali ai sensi dell’IEEPA.

Screening delle sanzioni. Il DOJ ha chiarito che la DPRK RevGen: Domestic Enabler Initiative perseguirà sia gli operativi nordcoreani sia chi fornisce loro supporto materiale, inclusi facilitatori che agiscono consapevolmente o meno. Per le aziende europee, questo si interseca con gli obblighi di due diligence della NIS2 sulla supply chain (articolo 21, comma 2, lettera d), con le normative antiriciclaggio applicabili (Direttiva UE 2015/849 e successive modifiche), e con il regime sanzionatorio UE sulla DPRK.

Lo scenario prossimo: la frode occupazionale nordcoreana come minaccia persistente

La traiettoria è chiara e non accenna a rallentare. Gli operativi nordcoreani stanno diventando più sofisticati nell’uso degli strumenti AI, espandendo le operazioni a nuove geografie, e diversificando le tattiche con l’aggiunta dell’estorsione post-licenziamento. Secondo CrowdStrike, viene segnalata circa una nuova assunzione nordcoreana sospetta al giorno tra i propri clienti – e nel 2024, quasi il 40% degli incidenti Famous Chollima gestiti da Falcon OverWatch ha comportato operazioni di insider threat attive, non semplice raccolta di stipendi.

La nascita di un’unità dedicata – il Research Center 227, una nuova struttura di ricerca AI all’interno dell’agenzia di intelligence nordcoreana – segnala l’intenzione del regime di costruire capacità AI proprietarie. Se e quando gli operativi DPRK potranno contare su modelli AI self-hosted, privi di guardrail e monitoraggio, l’ultimo meccanismo di rilevamento basato sul provider (quello che ha consentito ad Anthropic di identificare e documentare le operazioni) verrà meno.

La frode occupazionale nordcoreana non è un trend emergente da osservare con curiosità accademica. È un’operazione statale strutturata che genera centinaia di milioni di dollari per programmi nucleari, compromette la sicurezza delle infrastrutture tecnologiche occidentali, e sfrutta una vulnerabilità sistemica del mercato del lavoro remoto che nessun singolo attore – governativo o privato – può risolvere da solo.

Per i professionisti della sicurezza informatica, la lezione è duplice. Sul piano tattico, i processi di hiring devono essere trattati come una superficie di attacco, con controlli proporzionati al livello di accesso che il ruolo comporta. Sul piano strategico, la convergenza tra AI, geopolitica e cybercrime sta producendo minacce ibride che non rispettano i confini tradizionali tra sicurezza informatica, compliance normativa e intelligence – e che richiedono risposte altrettanto integrate.

L’AI ha eliminato il collo di bottiglia della formazione che per un decennio ha limitato le operazioni nordcoreane. Il prossimo collo di bottiglia – o la sua assenza – determinerà la scala di questa minaccia nei mesi e negli anni a venire.

Questo è il quarto articolo della serie “AI offensiva nella cybersecurity”. Il primo articolo ha introdotto il quadro generale delle minacce AI-driven e il framework normativo. Il secondo articolo ha ricostruito l’operazione GTG-2002 e il paradigma del vibe hacking. Il terzo articolo ha analizzato il no-code malware e il caso GTG-5004. Il prossimo articolo approfondirà le strategie di difesa AI-native contro le minacce AI-driven.

Fonti principali

Anthropic, Threat Intelligence Report: August 2025

Anthropic, Detecting and countering misuse of AI: August 2025 (PDF)

Google Threat Intelligence Group (GTIG), DPRK IT Workers Expanding in Scope and Scale, aprile 2025

Google Threat Intelligence Group (GTIG), AI Threat Tracker: Distillation, Experimentation, and Integration of AI for Adversarial Use, febbraio 2026

Microsoft Threat Intelligence, Jasper Sleet: North Korean remote IT workers’ evolving tactics, giugno 2025

CrowdStrike, Famous Chollima Adversary Profile

CrowdStrike, 2025 Threat Hunting Report, agosto 2025

Okta Threat Intelligence, How AI services power the DPRK’s IT contracting scams, aprile 2025

Okta Threat Intelligence, North Korea’s IT Workers expand beyond US big tech, settembre 2025

FBI/IC3, North Korean IT Worker Threats to U.S. Businesses – Public Service Announcement, luglio 2025

U.S. Department of Justice, Indictment of 14 North Korean Nationals – $88M IT Worker Scheme, dicembre 2024

U.S. Department of Justice, Coordinated Nationwide Actions to Combat North Korean Remote IT Workers, giugno 2025

U.S. Department of Justice, Nationwide Actions to Combat Illicit North Korean Government Revenue Generation, novembre 2025

U.S. Department of the Treasury, Sanctions against DPRK IT Worker Networks, novembre 2025

SentinelOne/SentinelLABS, Contagious Interview: North Korean Threat Actors Reveal Plans and Ops, settembre 2025

KnowBe4, How a North Korean Fake IT Worker Tried to Infiltrate Us, luglio 2024

ENISA, Threat Landscape 2025

Consiglio dell’Unione europea, Regolamento (UE) 2017/1509 – Misure restrittive DPRK

Commissione Europea, NIS2 Directive (Direttiva UE 2022/2555) e AI Act (Regolamento UE 2024/1689)

Crowell & Moring, From Deepfakes to Sanctions Violations: The Rise of North Korean Remote IT Worker Schemes

https://www.ictsecuritymagazine.com/articoli/frode-occupazionale-nordcoreana/

I jammer nelle carceri sono davvero la soluzione al problema dei telefoni cellulari non autorizzati? I dispositivi mobili rappresentano oggi una delle minacce più gravi alla sicurezza penitenziaria. Attraverso questi dispositivi, i detenuti coordinano traffici illeciti, impartiscono ordini a complici esterni, organizzano estorsioni e minacce a testimoni. Il fenomeno è in crescita esponenziale: i sequestri sono più che raddoppiati tra il 2022 e il 2024, passando da 1.084 a oltre 2.250 unità, mentre le modalità di introduzione si sono evolute con l’uso di droni, pacchi postali sofisticati e dispositivi miniaturizzati impossibili da individuare con i metal detector tradizionali.

In questo primo approfondimento a cura di Stefano Cangiano si ricostruisce la genesi della scelta dei jammer, analizzando il contesto storico, politico e operativo che portò all’adozione di questa tecnologia. Vengono esaminati i fattori che resero apparentemente ragionevole tale decisione: le pressioni mediatiche e sindacali, la necessità di una risposta rapida, i costi iniziali contenuti e la visibilità politica dell’intervento. Attraverso una cronologia dettagliata degli eventi dal 2018 al 2025, emerge però un quadro critico: investimenti largamente improduttivi, apparati che giacciono ancora imballati nei magazzini, e un sistema che si sta rivelando tecnicamente inadeguato di fronte all’evoluzione delle reti 4G e 5G.

Dati sui telefoni cellulari sequestrati in carcere: numeri, trend e reti criminali

Il fenomeno dei telefoni cellulari non autorizzati all’interno degli istituti penitenziari italiani è in costante e preoccupante crescita, e rappresenta oggi una delle sfide più complesse per l’amministrazione penitenziaria e per l’intero sistema della sicurezza nazionale. Dati interni del Dipartimento dell’Amministrazione Penitenziaria (DAP) mostrano che i sequestri di dispositivi mobili sono passati da circa 1.084 unità nel 2022 a oltre 2.250 nel 2024, con un aumento superiore al 100% in soli due anni. Questo trend esponenziale, oltre a indicare l’efficacia e la capillarità delle reti criminali nel far entrare telefonini occultati attraverso canali sempre più sofisticati, mette in luce l’impossibilità strutturale di contenere il fenomeno con semplici controlli manuali o perquisizioni periodiche.

Le modalità di introduzione dei dispositivi si sono evolute nel tempo, passando dai tradizionali metodi di occultamento durante i colloqui con i familiari a tecniche sempre più ingegnose: droni che sorvolano i cortili di passeggio, pacchi postali con doppi fondi, corruzione del personale, e persino il lancio di piccoli involucri oltre le mura perimetrali. La miniaturizzazione dei dispositivi ha ulteriormente complicato le operazioni di contrasto: oggi esistono telefoni delle dimensioni di un accendino, perfettamente funzionanti e dotati di connettività 4G, praticamente impossibili da individuare con i metal detector tradizionali.

L’impiego di telefoni di contrabbando consente ai detenuti di coordinare traffici illeciti con una facilità impensabile fino a pochi anni fa. Attraverso questi dispositivi vengono impartiti ordini a complici all’esterno, organizzate estorsioni ai danni di commercianti e imprenditori, gestite piazze di spaccio e persino pianificate intimidazioni a testimoni e magistrati. L’interazione con i social network ha aggiunto una dimensione ulteriore al problema: sono documentati casi di boss mafiosi che continuavano a gestire i propri profili Facebook dal carcere, inviando messaggi minacciosi e mantenendo viva la propria presenza simbolica nel territorio di riferimento.

In molti casi, le chiamate vengono effettuate in piena notte o in momenti di massima distrazione del personale, rendendo quasi impossibile l’intervento tempestivo. La carenza cronica di organico che affligge il sistema penitenziario italiano – con rapporti agente-detenuto tra i più sfavorevoli d’Europa – contribuisce a creare finestre di opportunità che i detenuti più scaltri sanno sfruttare con precisione quasi scientifica. Il problema assume inoltre rilievo di sicurezza nazionale quando cellule criminali o terroristiche cercano di contattare vittime o pianificare azioni esterne sfruttando la paradossale “libertà comunicativa” garantita dal carcere.

Jammer nelle carceri: cosa sono e perché sono stati adottati

Per arginare questo rischio, molte amministrazioni hanno valutato o implementato dispositivi di jamming, ossia disturbatori di segnale radio in grado di inibire le comunicazioni GSM, LTE e Wi-Fi. La promessa di questi apparati è apparentemente semplice: creare una “bolla” elettromagnetica attorno all’istituto penitenziario che renda impossibile qualsiasi comunicazione cellulare. Tuttavia, come emergerà nei capitoli successivi, queste soluzioni presentano criticità significative su più fronti, tali da renderle non solo inefficaci ma potenzialmente dannose.

Sul piano dell’inefficacia tecnica, i jammer non coprono in modo omogeneo tutte le bande di frequenza, lasciano inevitabili “zone d’ombra” dovute alla conformazione architettonica degli edifici, e richiedono costosi aggiornamenti per seguire l’evoluzione delle reti 4G/5G. I rischi operativi sono altrettanto rilevanti: questi dispositivi bloccano indiscriminatamente anche le linee di emergenza (112/118), le comunicazioni istituzionali del personale di polizia penitenziaria, e possono interferire con dispositivi medici salvavita come pacemaker e defibrillatori impiantabili. Non meno importanti sono i vincoli legali: in Italia i jammer sono vietati fuori da ambiti strettamente autorizzati e possono configurare i reati di “interruzione di pubblico servizio” (art. 340 c.p.) e di “installazione di apparecchiature per impedire comunicazioni altrui” (art. 617-bis c.p.).

Di fronte a queste criticità, emerge con forza la necessità di soluzioni alternative che superino la logica del disturbo indiscriminato in favore di un approccio più intelligente e mirato. I rilevatori di attività radio cellulare basati su analisi passiva dello spettro rappresentano oggi la frontiera più promettente. Tali sistemi non emettono segnali di disturbo, monitorano costantemente tutte le bande in uplink, catalogano ogni burst di traffico dati o voce, e permettono di localizzare con precisione il punto di trasmissione, consentendo interventi mirati e tempestivi.

Nel seguito di questo articolo esploreremo in dettaglio perché i jammer sono una risposta sbagliata, analizzando i loro limiti tecnici, operativi e normativi; i vantaggi dei rilevatori SDR passivi, con particolare attenzione a come funzionano, come interpretano i segnali e come si integrano nel complesso ecosistema della sicurezza penitenziaria; e infine un case study di un progetto sperimentale condotto in ambiente isolato, che dimostra concretamente l’efficacia del rilevamento passivo in condizioni analoghe a quelle di un vero istituto di pena.

Breve storia dei jammer nelle carceri

Le ragioni della scelta iniziale

Nel contesto temporale in cui maturò la decisione (2018), la scelta del Dipartimento dell’Amministrazione Penitenziaria di ricorrere ai jammer rispondeva a una combinazione di fattori concreti e contingenti che meritano di essere analizzati con attenzione per comprendere come si sia giunti alla situazione attuale. L’utilizzo di disturbatori di segnale appariva, in quel momento storico, come la soluzione più rapida da implementare per fronteggiare un fenomeno percepito come emergenziale, caratterizzato da un incremento costante dei sequestri di telefoni cellulari e da una crescente attenzione mediatica sul tema delle comunicazioni illecite dal carcere.

I jammer offrivano un approccio apparentemente “chiavi in mano”, con tempi di installazione relativamente brevi, costi iniziali contenuti e una promessa di efficacia immediata sulle tecnologie allora prevalenti, in particolare GSM e prime reti LTE. In un quadro segnato da forte pressione politica e sindacale – con i sindacati di polizia penitenziaria che denunciavano quotidianamente l’impossibilità di garantire la sicurezza con gli strumenti disponibili – tale scelta consentiva inoltre all’amministrazione di dimostrare un intervento visibile, facilmente comunicabile all’opinione pubblica e coerente con una linea di fermezza nei confronti della criminalità organizzata.

Il contesto politico dell’epoca non può essere sottovalutato. La questione delle comunicazioni illecite dal carcere era diventata un tema caldo nel dibattito pubblico, alimentato da inchieste giornalistiche che documentavano come boss mafiosi continuassero a gestire i propri affari criminali dalle celle di massima sicurezza. La pressione per una risposta immediata e visibile era fortissima, e i jammer sembravano offrire esattamente questo: una soluzione tecnologica tangibile, un investimento dimostrabile, un’azione concreta da poter esibire di fronte alle critiche.

A ciò si aggiungeva la limitata maturità, in quegli anni, di soluzioni alternative basate su analisi passiva dello spettro radio e sistemi di rilevazione selettiva. Queste tecnologie, pur esistendo già in ambito militare e di intelligence, richiedevano competenze altamente specialistiche raramente disponibili nel contesto dell’amministrazione penitenziaria, infrastrutture dedicate con costi di implementazione significativi, e soprattutto un cambio di paradigma operativo non immediato per un’organizzazione tradizionalmente orientata a soluzioni hardware piuttosto che a sistemi di analisi e intelligence.

In questo quadro si collocano anche le posizioni espresse pubblicamente dal Procuratore Nicola Gratteri, figura di riferimento nel contrasto alla ‘ndrangheta e voce autorevole nel dibattito sulla sicurezza penitenziaria. Gratteri, pur denunciando più volte l’inefficacia complessiva delle misure adottate e i ritardi strutturali dello Stato nel contrasto alle comunicazioni illecite dal carcere, ha in diverse occasioni riconosciuto l’utilità dei jammer almeno come strumento temporaneo nei reparti di alta sicurezza. In interviste e audizioni pubbliche, il Procuratore ha infatti sottolineato come, in assenza di soluzioni tecnologicamente più avanzate e strutturate, i jammer potessero rappresentare una risposta transitoria per limitare le comunicazioni dei detenuti più pericolosi, in attesa di un approccio più organico e duraturo.

Tali posizioni contribuiscono a chiarire come il tema dell’impiego dei jammer non sia riconducibile a una contrapposizione ideologica tra “falchi” e “colombe”, ma vada letto come il risultato di scelte contingenti, maturate in un contesto emergenziale e sotto la spinta di pressioni multiple. Oggi quel contesto appare superato dall’evoluzione tecnologica e dalla disponibilità di strumenti più efficaci, selettivi e sostenibili nel lungo periodo.

Cronologia dei jammer nelle carceri italiane: investimenti e fallimenti

La storia dell’adozione dei jammer nelle carceri italiane si snoda attraverso alcune tappe fondamentali che meritano di essere ricostruite con precisione documentale, anche per comprendere l’entità degli investimenti pubblici che rischiano oggi di rivelarsi largamente improduttivi.

Il 17 ottobre 2018 segna l’avvio formale della gara d’appalto per l’acquisto dei primi apparati jammer, con la firma del decreto da parte del Direttore generale Buffa e un ordinativo iniziale di circa 47 unità destinate agli istituti di massima sicurezza. La scelta di partire dai reparti ad alta sicurezza rispondeva a una logica di priorità: era lì che si concentravano i detenuti più pericolosi, i boss mafiosi e i terroristi per i quali l’isolamento comunicativo rappresentava un obiettivo strategico primario.

La documentazione di riferimento, non più accessibile attraverso l’archivio online del Ministero della Giustizia (che rende consultabili solo gli atti pubblicati a partire dal 2020), è ricostruita attraverso fonti DAP e Il Sole 24 Ore nel documento disponibile presso POLPENUIL – Blocco telefoni carcere jammer.

Nel maggio 2019 si procede alla consegna e installazione dei dispositivi in vari istituti ad alta sicurezza, accompagnata da un programma di formazione per gli operatori. Questa fase ha rivelato immediatamente alcune criticità: la complessità degli apparati richiedeva competenze tecniche che il personale penitenziario non possedeva, e l’integrazione con le infrastrutture esistenti si rivelava più problematica del previsto. Sono stati necessari interventi di adeguamento impiantistico, con costi aggiuntivi non previsti nel budget iniziale (Circolare acquisizione sistemi jammer).

Tra agosto e settembre 2023 vengono condotte prove pilota in 20 strutture, mirate a verificare l’efficacia dei sistemi su reti 4G e a condurre test preliminari su bande 5G, ormai in fase di diffusione capillare sul territorio nazionale. Da queste sperimentazioni emergono zone d’ombra significative e criticità tecniche che mettono in discussione l’intera strategia: i jammer, progettati per tecnologie ormai superate, faticano a contrastare le nuove frequenze, mentre la conformazione architettonica degli istituti – spesso edifici storici con muri spessi e strutture metalliche – crea sacche di copertura irregolare (Resoconto Camera dei Deputati).

Nel gennaio 2025 prende avvio la sperimentazione di un sistema alternativo di filtraggio passivo, volto a superare i problemi sanitari e di interferenza non selettiva che avevano caratterizzato l’esperienza con i jammer. L’abbandono di fatto del sistema jammer, dopo anni di investimenti largamente inutilizzati e con apparati che giacciono in molti casi ancora imballati nei magazzini degli istituti, è documentato da diverse fonti giornalistiche che parlano esplicitamente di “rottamazione” di un sistema mai realmente entrato in funzione (HuffPost e Ristretti Orizzonti).

Le ragioni dell’adozione

Le motivazioni che portarono alla scelta dei jammer possono essere ricondotte a quattro fattori principali, che vale la pena analizzare nel dettaglio per comprendere la razionalità (sia pure limitata) di quella decisione.

In primo luogo, le pressioni mediatiche e sindacali. Le segnalazioni frequenti di contatti illeciti tra detenuti e organizzazioni criminali esterne avevano creato un clima di urgenza che richiedeva risposte immediate. I media riportavano con cadenza quasi quotidiana episodi di boss che continuavano a impartire ordini dal carcere, di estorsioni coordinate via cellulare, di minacce a pentiti e testimoni. I sindacati di polizia penitenziaria denunciavano l’impossibilità di svolgere efficacemente il proprio lavoro senza strumenti tecnologici adeguati. La pressione convergente di questi attori rendeva politicamente insostenibile l’inazione.

In secondo luogo, la rapidità di implementazione. I jammer costituivano una soluzione apparentemente pronta all’uso, con tempi di installazione contenuti rispetto a sistemi passivi o reti di sorveglianza RF più sofisticate. In un contesto di emergenza percepita, la possibilità di “fare qualcosa subito” aveva un valore politico e comunicativo che superava considerazioni più ponderate sull’efficacia di lungo periodo.

Il costo iniziale contenuto rappresentava un terzo elemento di attrattiva. L’investimento per singolo apparato risultava inferiore a quello richiesto per infrastrutture di monitoring e analisi dati, che avrebbero comportato non solo l’acquisto di hardware sofisticato ma anche la formazione di personale specializzato, la creazione di sale operative dedicate, e costi di manutenzione e aggiornamento continuativi.

Infine, la visibilità politica. L’adozione dei jammer veniva percepita come un intervento risolutivo e “intransigente” contro l’illegalità nel carcere, facilmente comunicabile all’opinione pubblica. Un annuncio del tipo “abbiamo installato sistemi di disturbo in tutti i penitenziari di massima sicurezza” aveva un impatto mediatico immediato, molto più di discorsi complessi su sistemi di analisi dello spettro e algoritmi di rilevazione.

Cosa sono i jammer

Prima di procedere all’analisi delle criticità, è opportuno chiarire con precisione cosa siano i jammer e come funzionino dal punto di vista tecnico. I jammer sono dispositivi di disturbo radio progettati per emettere segnali nelle bande di frequenza utilizzate dai telefoni cellulari, creando un “rumore” elettromagnetico che impedisce la connessione tra il terminale e le celle di rete.

Le frequenze interessate includono tipicamente la banda 900 MHz (GSM), 1800 MHz (DCS), 2100 MHz (UMTS/3G), e nelle versioni più recenti anche le bande 800 MHz, 1800 MHz e 2600 MHz del 4G/LTE, fino ai 3,5 GHz necessari per disturbare le comunicazioni 5G. Il principio di funzionamento è relativamente semplice: il jammer emette un segnale di potenza superiore a quello della cella telefonica legittima sulla stessa frequenza, “sovrastando” il segnale utile e rendendo impossibile al telefono stabilire o mantenere una connessione.

Questa semplicità concettuale nasconde però una complessità operativa significativa. Per essere efficace, un jammer deve coprire tutte le bande utilizzate dagli operatori attivi sul territorio, deve emettere con potenza sufficiente a superare il segnale delle celle (che può variare significativamente in funzione della posizione geografica dell’istituto), e deve farlo in modo uniforme su tutta l’area da proteggere. Ognuno di questi requisiti presenta sfide tecniche non banali, come vedremo nel capitolo successivo.

L’aspetto più critico è che i jammer agiscono in modo totalmente indiscriminato: bloccano qualsiasi tipo di comunicazione RF nell’area di copertura, senza possibilità di distinguere fra traffico legale (comunicazioni del personale, sistemi di emergenza, dispositivi medici) e traffico illegale (telefoni dei detenuti). Questa caratteristica intrinseca rappresenta il limite fondamentale della tecnologia e la ragione principale per cui essa si sta rivelando inadeguata.

Questo primo approfondimento ha ricostruito la storia dell’adozione dei jammer nelle carceri italiane, dalla gara d’appalto del 2018 fino alla loro sostanziale dismissione nel 2025. Abbiamo visto come la scelta di questi dispositivi rispondesse a pressioni contingenti e a una logica emergenziale, offrendo una soluzione apparentemente rapida ed efficace per contrastare le comunicazioni illecite dei detenuti.
Tuttavia, come emerso dall’analisi cronologica e dalle evidenze documentali, i jammer si sono rivelati una risposta inadeguata: apparati progettati per tecnologie ormai superate, zone d’ombra significative nella copertura, costi aggiuntivi non previsti e criticità operative che hanno portato di fatto all’abbandono del sistema.

Nel prossimo articolo della serie approfondiremo in dettaglio i limiti tecnici, operativi e normativi dei jammer. Per una trattazione completa e approfondita del tema, Stefano Cangiano dal titolo “Jammer nelle carceri: limiti, rischi e alternative”.

https://www.ictsecuritymagazine.com/articoli/jammer-comunicazioni/

La Gen AI sta ridisegnando i confini della professione legale, ponendo l’Avvocatura europea di fronte a una scelta ineludibile: governare il cambiamento o subirne le conseguenze. In questo scenario, la Guida del CCBE sull’uso dell’intelligenza artificiale generativa da parte degli avvocati rappresenta la bussola con cui orientarsi tra obblighi normativi, principi deontologici e nuove opportunità operative.

Con l’entrata in vigore nell’ottobre 2025 della Legge n.132/2025 [1], per i professionisti, inclusi gli avvocati, si è sancito un nuovo esplicito onere informativo nei confronti dei clienti riguardo all’eventuale utilizzo di sistemi di IA nelle loro prestazioni[2].

Non di meno, a livello di regolamentazione UE a partire dal 2 febbraio 2025, l’IA Act – (Regolamento UE n. 2024/1689[3]) ha richiesto che tutte le Organizzazioni garantiscano che il proprio personale possieda conoscenze adeguate sull’IA, indipendentemente dal fatto che esse partecipino alla catena del valore dell’IA come fornitori o utenti (c.d. deployers).

In attuazione di ciò, in ambiente forense e per l’Italia, il CNF (Consiglio Nazionale Forense) – organismo istituzionale di vertice dell’Avvocatura italiana[4] – si è reso protagonista di una serie di iniziative importanti, finalizzate a garantire un uso consapevole e responsabile dei sistemi di IA in ambiente professionale forense.

In particolare, il CNF:

• ha elaborato un apposito schema di informativa che gli Avvocati possono adottare in adempimento all’obbligo di trasparenza nei confronti del Cliente;
• ha avviato una consultazione preliminare di mercato ex 77 D.Lgs. 36/2023[5] per l’acquisizione di servizi di IA destinati al supporto dell’attività professionale legale;
• ha recepito e diffuso la Guida del CCBE Conseil des Barreaux Européens (Consiglio degli Ordini Forensi d’Europa) sull’uso etico e trasparente dell’Intelligenza artificiale generativa da parte degli avvocati.

In questa sede, si ripropongono in chiave sintetica i principali passaggi di tale Guida secondo le interpretazioni del CNF, a valere quale fonte di natura autoregolamentare per l’utilizzo dei sistemi di IA, che ha come finalità dichiarata quella di “aumentare la consapevolezza su cosa sia in particolare la GenAI, illustrarne gli usi attuali nella pratica e mettere in evidenza opportunità e rischi potenzialmente connessi al suo impiego in ambiente professionale forense”[6].

La Guida può essere un utile supporto per Avvocati, Ordini e Associazioni forensi, Studi Legali e Organizzazioni professionali, per promuovere un uso responsabile dei sistemi di IA e GenAI.

Introduzione alla Guida CCBE – rimandi a fonti integrative

Il CCBE rappresenta oltre 1 milione di Avvocati europei attraverso i rispettivi Ordini nazionali di 45 Paesi; nell’ottobre 2025, ha emanato il documento “CCBE guide on the use of generative AI by Lawyers”.

Una Linea Guida (di seguito anche solo Guida) è volta ad illustrare all’avvocatura europea i concetti fondamentali in materia di IA e le sue evoluzioni, con enunciazione dei principali obblighi che si impongono in caso di ricorso a strumenti di IA e di GenAI nell’esercizio dell’attività forense.

Di seguito lo Schema della Guida CCBE:

CCBE Guide on the use of generative AI by Lawyers SCHEMA DELL’ ARTICOLATO
Art.1	Introduction
Art.2	AI – The basics 2.1. Key Characteristics of generative AI 2.2. How is generative AI legally defined? 2.3. Regulatory approces to GenAI
Art. 3	Generativa AI in legal practice – take up, benefits and risks 3.1. Take up of GenAI tools by lawyera 3.2. Benefits of generativa AI in legal practice 3.3. Risks of using generati AI 3.3.1. Privacy and data protection 3.3.2. Hallucinations 3.3.3. Bias and sycophancy 3.3.4. Lack of transparency 3.3.5. Intellectual property and related rights 3.3.6. Cybersecurity 3.3.7. Fraud
Art. 4	The use of genrative AI in legal practice and lawyers’ professional obligatione 4.1. Confidentiality 4.2. Professional Competence 4.3. Independence 4.4. Transparency and information to the client 4.5. Conflict of interest
Art. 5	Considerations for the future
Art. 6	Conclusion
Annex 1 -Resources on the use of generative AI by lawyers and/or judical professionals

Il rilievo del documento, non è solo nel suo contenuto testuale, ma anche nel richiamo a numerose fonti che – a livello nazionale, europeo ed internazionale ne integrano le previsioni e che costituiscono riferimento imprescindibile per un utilizzo corretto e consapevole dell’IA in ambiente forense[7].

Per l’Italia, spicca il rimando alla Carta dei principi per un uso consapevole di strumenti di intelligenza artificiale in ambiente forense – HOROS a cura del Consiglio dell’Ordine degli Avvocati (COA) di Milano (Dicembre 2024)[8].

Frutto del lavoro della Commissione Informatica del Consiglio, la Carta dei principi HOROS di Milano:

• è il primo disciplinare legale italiano che orienta nell’uso consapevole e sicuro delle nuove tecnologie, in chiave integrata con il diritto;
• persegue l’obiettivo di sviluppare un efficace modello di intervento in ambito forense, in conformità alle Linee Guida “Avvocati Europei nell’era di Chatgpt” – Fédération des Barreaux d’Europe di Giugno 2024 ed in allineamento al Regolamento UE sull’IA.

“HOROS”- La Carta dei principi del COA di Milano (brevi cenni)

La Carta dei principi per un uso consapevole di strumenti di intelligenza artificiale in ambiente forense– HOROS del COA di Milano risponde ora alle nuove esigenze di innovazione, ora alla necessità di garantire che la rivoluzione tecnologica rappresentata dall’IA (certamente foriera di grandi potenzialità, ma non di meno fonte di rischi concreti) non intacchi i fondamenti etici e deontologici della professione. Alla base della Carta sono in primis i principi generali di legalità, correttezza, trasparenza e responsabilità. Ciò in quanto (rif. parte introduttiva della Carta): “le tecnologie impiegate devono essere conformi alle normative europee e nazionali vigenti e l’uso dell’IA deve sempre essere finalizzato al miglioramento della qualità del servizio legale, senza compromettere i diritti e la fiducia dei clienti. Ogni adozione di IA deve essere attentamente per garantire che gli strumenti scelti siano adatti e proporzionati agli scopi specifici per cui ne è stato ipotizzato l’utilizzo”. Segue la declinazione dei seguenti principi specifici: Ø Dovere di competenza: l’uso consapevole dell’IA richiede che il professionista mantenga e sviluppi con continuità competenze tecnologiche; comprendendone funzionalità, limiti e rischiosità, evitando la dipendenza da risultati automatizzati; Ø Trasparenza dell’uso dell’IA: è fatto obbligo di informare il cliente dell’uso dell’IA, del possibile impatto sul servizio fornito, descrivendo metodi e tecnologie utilizzate; con informativa anche sulla possibilità di valutare validità ed affidabilità dei risultati; Ø Centralità della decisione umana: il professionista ha il compito di intervenire attivamente per valutare criticamente i risultati prodotti dall’IA, assicurando sia l’adeguatezza delle tecnologie IA adottate, sia che il loro processo di elaborazione non risulti negativamente condizionato dagli algoritmi (ciò significa applicare un “esame umano” al risultato IA per garantirne adeguatezza, accuratezza, conformità a principi etici e legali e per prevenire errori, pregiudizi, bias o decisioni ingiuste forieri di possibili ricadute significative sulla vita delle presone coinvolte); Ø Protezione dei dati e riservatezza: l’uso dell’IA deve avvenire nel pieno rispetto dei principi fondamentali di protezione dei dati personali di cui al GDPR, in allineamento agli approcci di “privacy by design” e “privacy by default” e con previsione di Data Protection Impact Assessment (DPIA) ove prevista dalla normativa applicabile; Ø Sicurezza informatica: l’adozione di strumenti IA richiede un’attenzione particolare alla sicurezza informatica per garantire che i dati trattati siano protetti e che i sistemi utilizzati siano sicuri ed affidabili; Ø Valutazione del rischio dell’utilizzo di sistemi di IA: il professionista è tenuto a: i) una valutazione su base continua dei rischi legati all’uso IA nel proprio ambito di attività; ii) adozione di azioni correttive (AC) in presenza di rischi significativi, così da mitigarli tempestivamente; iii) documentare le misure adottate; iv) verificare periodicamente l’efficacia delle AC intraprese per garantirne uso responsabile e conforme alla normativa vigente; v) informare in modo adeguato e trasparente Cliente e Stakeholder; Ø Diversità e sostenibilità ambientale: l’uso dell’IA deve avvenire nel rispetto dei principi di diversità, sostenibilità ambientale e non discriminazione; promuovendone un approccio responsabile; Ø Formazione continua e Re-skilling: il professionista è tenuto a partecipare a corsi di aggiornamento delle proprie competenze in materia di nuove tecnologie, protezione e dati e sicurezza informatica, nonché sui relativi rischi ed implicazioni legali; Ø Tutela del diritto d’autore: è fatto obbligo di garantire la conformità alla normativa a tutela di copyright, PI e diritti d’autore nell’uso di IA generativa di opere, contenuti, immagini.

Al documento del COA Milano, hanno fatto seguito altri provvedimenti Ordinistici nazionali.

Meritano una menzione:

• il “Breve Vademecum per Avvocati sull’utilizzo dell’intelligenza artificiale” emanato nel Dicembre 2024 dalla Commissione Procedura Civile del COA di Roma, che integra il quadro normativo vigente in materia di IA con indicazioni pratiche per l’uso dei sistemi in ambiente forense;
• il “Promemoria sulle principali norme deontologiche da rispettare nell’uso dell’IA” del 29 Ottobre 2025, a cura del COA di Genova che specifica i principali obblighi e doveri di deontologia applicabili e da osservarsi, per un corretto utilizzo di IA in ambiente professionale.[9]

IA e GenAI nel quadro regolamentare di rango normativo applicabile

Come chiarisce la Guida CCBE, caratteristica principale che distingue i sistemi di intelligenza artificiale generativa (Generativa AI, o GenAI) dagli altri sistemi di IA è la capacità di produrre nuovi contenuti, sotto forma di testo, immagini, audio o video.

Come tutti i sistemi di IA, anche i modelli di GenAI sono basati su macchine, operano con gradi variabili di autonomia e deducono dagli input ricevuti come generare l’output; tuttavia la GenAI presenta proprie peculiarità, ossia:

• per la maggior parte dei modelli, utilizza tecniche di deep learning (apprendimento profondo), in particolare reti neurali per elaborare e produrre dati;
• funziona analizzando i dati di input nel loro contesto e riconoscendo schemi ricorrenti, in modo da generare nuovi output coerenti con il tono, lo stile e l’argomento desiderati;
• sa adattarsi a diversi stili espressivi (ad es. quelli artistici, narrativi o musicali);
• si basa su principi probabilistici, fondati sulla matematica della probabilità e della statistica;
• evolve costantemente attraverso processi iterativi di addestramento su dataset di grandi dimensioni e diversificati (all’aumentare e al variare dei dati a cui sono esposti, la loro capacità di generare contenuti si modifica di conseguenza).

Nella legislazione UE (in particolare nella nell’IA Act) non si rinviene una specifica definizione di GenAI; essa è considerata, ora come una sottocategoria dei “sistemi di IA”, ora come un “sistema di IA ad uso generale”/ “modello di IA per finalità generali” (i.e. general -pourpose AI system, rif. art.3, Regolamento n. 1689/2024/UE).

Sistema di IA (definizione OCSE ripresa all’art.3 IA Act)	E’ un sistema automatizzato progettato per funzionare con livelli di autonomia variabili e che può presentare adattabilità dopo la diffusione e che, per obiettivi espliciti o impliciti, deduce dall’input che riceve come generare output quali previsioni, contenuti, raccomandazioni o decisioni che possono influenzare ambienti fisici o virtuali.
Modello di IA per finalità generali (art.3 IA Act)	E’ un sistema di IA basato su un modello di IA per finalità generali e che ha la capacità di perseguire varie finalità, sia per uso diretto che per integrazione in altri sistemi di IA.

Dal punto di vista regolamentare, esistono leggi che disciplinano direttamente specifici aspetti dell’IA, e vi sono molte altre normative che si applicano indirettamente ai sistemi di IA (ad es. quelle in materia di privacy e protezione dei dati, istruzione, occupazione e ricerca medica).

Quadro normativo nazionale ed europeo sull’uso della Gen AI

La normativa più conosciuta nel contesto sovranazionale è la già citata Legge sull’IA dell’Unione Europea, adottata nel 2024 ed entrata in vigore nell’Agosto dello stesso anno; che istituisce un quadro normativo basato sul rischio, applicabile a tutti i fornitori e utilizzatori di sistemi di IA nel mercato dell’Unione, indipendentemente dalla loro provenienza.

L’ IA Act classifica i relativi sistemi in 4 categorie, ognuna soggetta a differenti livelli di obblighi e regolamentazione; prevede inoltre regole specifiche per i sistemi GPAI (Generale Purpose AI – AI per finalità generali) sottoponendoli a obblighi di trasparenza e documentali più severi per i modelli con capacità elevate.

Categorie di rischio associate ai sistemi di IA – IA Act
1	ALTO RISCHIO	Sistemi soggetti a numerosi requisiti (i.e. valutazioni di conformità, trasparenza, supervisione umana, qualità dei dati, registrazione in un database dell’UE); vi rientra anche l’uso di IA nel sistema giudiziario.
2	RISCHIO LIMITATO	Obblighi di trasparenza (ad es. informare gli utenti quando interagiscono con un sistema di IA o quando i contenuti sono generati artificialmente, come nei deepfake).
3	RISCHIO MINIMO	Riguarda la maggior parte dei sistemi di IA che non sono soggetti a requisiti aggiuntivi oltre a quelli di normativa generale UE.
4	RISCHIO INACCETTABILE	Afferisce a tutte le pratiche vietate (es. social scoring, manipolazione comportamentale, identificazione biometrica non autorizzata in luoghi pubblici).

Negli Stati Uniti, l’approccio è ibrido; combina ordini esecutivi federali, regolamenti settoriali e leggi statali (in particolare in Colorado e California).

A livello internazionale, la Convenzione quadro del Consiglio d’Europa sull’intelligenza artificiale, i diritti umani, la democrazia e lo Stato di diritto[10] – formalmente adottata il 17 Maggio 2024 dal Comitato dei Ministri del Consiglio d’Europa – costituisce il primo trattato internazionale giuridicamente vincolante in materia di IA.

La Convenzione:

• mira a garantire che le attività di IA siano conformi ai diritti umani, ai principi democratici e allo Stato di diritto, includendo temi come: dignità e autonomia umana, uguaglianza e non discriminazione; privacy e protezione dei dati, trasparenza e supervisione, responsabilità, sicurezza e innovazione affidabile;
• è finalizzata a garantire che ogni fase del ciclo di vita dei sistemi di IA (progettazione, addestramento e utilizzo) rispetti i principi e valori di cui sopra;
• impone obblighi proporzionati ai potenziali rischi dell’IA per i diritti umani;
• si applica alle attività IA svolte dalle Autorità pubbliche o da soggetti privati che agiscono per loro conto (per il settore privato gli Stati aderenti alla Convenzione possono scegliere se applicare direttamente gli obblighi o adottare misure alternative equivalenti).

Rilevano poi a livello UE e come fonti riferite specificatamente al contesto giudiziario:

• la Carta etica europea sull’uso dell’intelligenza artificiale nei sistemi giudiziari e nel loro contesto adottata dalla Commissione UE per l’efficienza della giustizia (CEPEJ), Consiglio d’Europa 2018,
• varie Linee guida per Professionisti della giustizia e per Avvocati (di cui in parte si è già detto nei paragrafi che precedono).

In ogni caso, la CCBE nella sua Guida chiarisce che “l’uso dell’IA (inclusa la GenAI) da parte degli Avvocati resta soggetto agli obblighi professionali vigenti nelle rispettive giurisdizioni, oltre che alle leggi generali applicabili”.

Declinazioni applicative dell’IA in ambiente forense – benefici e rischi

Tra i principali benefici riconosciuti ai sistemi di IA diffusi in ambiente forense, la Guida CCBE indica quelli di:

• maggiore efficienza operativa (ad es. creazione automatizzata di documenti, analisi rapida di grandi volumi di materiali per una comunicazione più snella al cliente);
• miglioramento e potenziamento della ricerca legale (ad es. reperibilità più rapida e accurata di giurisprudenza pertinente, analisi di banche dati o individuazione di tendenze giuridiche);
• migliore qualità del lavoro (ad es. riduzione di errori, verifica della conformità e standardizzazione dei processi);

con conseguenti ricadute positive anche in termini di:

• risparmi di costi e tempi di produzione;
• ottimizzazione delle risorse;
• riduzione dei tempi di trattazione di casi giudiziari;
• possibilità di concentrarsi su attività qualitative piuttosto che ripetitive.

Anche nella relazione con il Cliente, il ricorso ai sistemi di IA presenta potenziali vantaggi per l’Avvocato, consentendo tempi di risposta più rapidi, stime di costo più accurate, migliore supporto operativo e di affiancamento, facilitazioni nell’accesso alla giustizia da parte di soggetti attualmente sottoserviti.

Poiché poi anche i fornitori di sistemi di IA hanno incrementato in modo significativo la produzione di nuovi modelli pensati specificatamente per le peculiarità di uno Studio legale, le soluzioni di IA vengono oggi commercializzate in modo diffuso e come strumenti specializzati per i Professionisti del diritto, con l’obiettivo di consentire pratiche di lavoro più rapide ed efficienti (rif. a strumenti di ricerca e redazione addestrati su dati giuridici o collegati a banche dati legali).

Tuttavia, la Guida CCBE non si limita ai benefici ed ai trend di mercato, ma individua anche e soprattutto i principali rischi che l’utilizzo dell’IA prospetta al legale, per rapporto agli obblighi che gli si impongono per normativa anche di stampo ordinistico e di deontologia applicabile.

Di seguito, la sintesi dei principali rischi collegati all’uso dei sistemi di IA nell’operatività legale:

ALLUCINAZIONI	L’IA può generare risposte fattualmente inesatte o illogiche (imputabili a possibili cause e fattori quali: limitazioni nei dati di addestramento, natura probabilistica dei modelli di IA, incomprensioni di contesto, eccessiva generalizzazione, generazione di dati di sintesi). Con il rischio – nel contesto dei servizi legali – di giurisprudenza completamente fittizia, cause o decisioni giudiziarie inesistenti, attribuzione erronea di citazioni a giudici o studiosi del diritto, oppure di argomentazioni giuridiche apparentemente plausibili ma interamente inventate. Sussistono anche: il rischio di interpretazioni giuridiche fittizie, di principi giuridici inventati, di rappresentazioni scorrette dello stato del diritto vigente in specifiche giurisdizioni, o ancora di falsi collegamenti o correlazioni tra concetti giuridici.
BIAS E ADULAZIONE (SYCOPHANCY – COMPIACENZA)	Bias e compiacenza nella GenAI: il concetto si riferisce a errori sistematici o rappresentazioni distorte che emergono dai dati di addestramento, dal design/dalla progettazione del modello o dai processi algoritmici seguiti dai sistemi di IA (imputabili al fatto che i modelli di IA vengono addestrati su enormi insiemi di dati che riflettono modelli di comunicazione umana, nei quali l’accordo e il rinforzo positivo sono presenti, così che l’IA può dare priorità alla generazione di risposte concilianti o gradire all’utente, piuttosto che a informazioni accurate, critiche o bilanciate); i bias possono riprodurre o amplificare pregiudizi sociali esistenti, generando risultati ingiusti o inaccurati, o ancora produrre output fuorvianti o distorti. Adulazione nella GenAI: indica la tendenza dei sistemi di IA (in particolare dei Modelli Linguistici di Grandi Dimensioni – LLM), a generare risposte che si allineano a preferenze o a bias percepiti dell’utente; concordando eccessivamente o fornendo riscontri eccessivamente positivi. In questo modo, l’IA può privilegiare risposte compiacenti anziché informazioni accurate o critiche, con il rischio di output fuorvianti o squilibrati.
MANCANZA DI TRASPARENZA	Attualmente, quasi tutti i sistemi di GenAI presentano il fenomeno della c.d. “scatola nera” (o black box), tale per cui i processi di ragionamento interni sono opachi e difficili da interpretare. Persino gli sviluppatori ed i fornitori di tali sistemi non sono in grado di spiegare pienamente come vengono prodotti gli output. Per gli Avvocati, ciò rende più difficile verificare l’accuratezza e l’affidabilità dei contenuti generati dall’IA con il rischio di compromettere la qualità di consulenze legali/degli atti prodotti. Si aggiungono rischi per la riservatezza delle informazioni del Cliente, ove fornite ai sistemi di IA (ad es. quando i dati vengano archiviati, riutilizzati o incorporati involontariamente nell’addestramento del sistema; con il rischio di violazione del segreto professionale).
VIOLAZIONE DELLA PROPRIETA’ INTELLETTUALE E DIRITTI CONNESSI	La titolarità dei dati (di input e di output) è tra le principali preoccupazioni nell’uso della GenAI. Dati protetti da copyright o non autorizzati possono infatti essere utilizzati per addestrare gli strumenti di IA, con il rischio di violazioni del diritto d’autore qualora i dati di input (in ingresso) contenenti opere protette producano dati di output (in uscita) riconoscibili. Inoltre, possono sorgere criticità legate alle clausole di titolarità contenute nei termini del servizio o nei contratti di licenza. Con problematiche ancora più rilevanti, ove i fornitori di GenAI invochino la tutela del segreto industriale (trade secret protection) per non divulgare informazioni sul funzionamento dei propri sistemi.
MANCANZA DI SICUREZZA	L’IA può introdurre o aggravare rischi di sicurezza informatica, compresa la possibilità che attori malevoli sfruttino vulnerabilità del sistema (tra i rischi più rilevanti sono quelli di phishing, di prompt injection (i.e. inserimento subdolo di istruzioni/comandi specifici durante la fase di imput con l’obiettivo di manipolare o aggirare restrizioni imposte, così da indurre il sistema a eseguire attività altrimenti vietate o limitate), di data poisoning (i.e. di corruzione di dati o fonti) o di model poisoning (i.e. “velenamento” del modello), compromettendo il comportamento e l’output del sistema.
VIOLAZIONE DI DATI PERSONALI	I sistemi di GenAI si basano su enormi insiemi di dati (dataset) per il loro addestramento, il che comporta il rischio che gli utenti che interagiscono con tali strumenti per compiti specifici, possano, senza rendersene conto, fornire dati di input che vengono poi riutilizzati per riaddestrare il modello. Può anche accadere che tali dati vengano utilizzati dai fornitori o distributori per i dataset di addestramento, ovvero che gli stessi soggetti abbiano accesso ai dati di input o agli output generati durante il funzionamento dei sistemi. In assenza di informazioni chiare e trasparenti da parte dei gestori dei sistemi, si rischia quindi che le persone possano esporre involontariamente loro informazioni riservate o dati sensibili, senza essere pienamente consapevoli dei rischi potenziali.
FRODE	I sistemi di IA possono includere deepfake[11], identità sintetiche o situazioni di impersonation (i.e. sostituzioni di persona, manipolazione di sistemi di riconoscimento facciale, furti d’identità e produzione di documenti falsi) o generare truffe automatizzate dalla stessa IA; con possibili danni reputazionali per l’Avvocato o con divulgazione non lecita di informazioni sensibili.

Con specifico riferimento al dovere di indipendenza, la Guida CCBE ricorda l’obbligo del Professionista di mantenimento dell’obiettività professionale.

I principali rischi da contenere sono quelli derivanti dai fenomeni di bias e compiacenza (sycophancy), descritti in precedenza.

Per il legale che ricorre ai sistemi di IA nella professione, può verificarsi il caso di interiorizzarli inconsciamente, esponendosi a possibili influenze nei giudizi o nei comportamenti e – per i casi più estremi- di indebolire il dovere di fornire una consulenza imparziale.

Ancora, possono verificarsi situazioni di dipendenza eccessiva dagli output generati dall’IA, che possono condurre a una forma di “compiacenza automatica” (automation complacency) e alla sostituzione del giudizio umano con conclusioni automatizzate.

Il dovere di trasparenza impone all’Avvocato che utilizza sistemi di IA nell’attività di difesa o assistenza al Cliente, l’obbligo di informarlo preventivamente consentendogli di esprimere eventuali riserve o condizioni, o di opporvisi.

A beneficio del lettore, si fornisce di seguito lo schema di informativa, su modello CNF.

Informativa sull’utilizzo di strumenti di Intelligenza Artificiale Documento predisposto ai sensi dell’art. 13 – L. 23 settembre 2025 n. 132 Disposizioni in materia di professioni intellettuali. Il sottoscritto avv. _________________________ con Studio in ______________________ via _______________________ Ai sensi dell’art. 13 della legge 132/2025 informa ₋ che nel corso dell’esecuzione dell’incarico conferito sia in sede giudiziale che stragiudiziale, ove ritenuto utile, potrebbe ricorrere all’impiego di sistemi di Intelligenza Artificiale (“I.A.”), per svolgere attività strumentali e/o di supporto all’attività professionale; ₋ che l’utilizzo dei sistemi di Intelligenza Artificiale (“I.A.”) avverrà sempre nel pieno rispetto delle disposizioni del Regolamento UE n. 2016/679 (GDPR) e dei doveri deontologici che regolano la professione forense al fine di garantire la tutela della privacy e della riservatezza del cliente e della parte assistita; ₋ che, in particolare, l’Intelligenza Artificiale (“I.A.”) sarà impiegata esclusivamente per funzioni di supporto alla attività professionale, quali, a titolo meramente esemplificativo, la gestione di attività organizzative e di segreteria, la ricerca normativa e giurisprudenziale, l’analisi preliminare di documenti e la predisposizione di bozze o sintesi; ₋ che il risultato derivato dai sistemi di Intelligenza Artificiale (“I.A.”) sarà oggetto di una verifica attenta e accurata da parte dell’avvocato, sia in sede di generazione del prodotto che di controllo delle fonti. Luogo ____________, data ___/___/_____ Sottoscrizione dell’Avvocato _______________________ Il sottoscritto ____________________ dichiara di essere stato reso edotto delle indicazioni sopra riportate e di averne pienamente compreso il significato. Sottoscrizione del cliente _______________________

Trova applicazione anche l’obbligo di evitare conflitti di interesse, in quanto i sistemi di IA possono essere addestrati su – o avere accesso a – informazioni riservate provenienti da più Clienti dello stesso Studio Legale; con la conseguente possibilità di condivisione involontaria di informazioni o di conflitti di interesse effettivi o potenziali.

Gli Avvocati devono inoltre rispettare i principi di:

• dignità e onore della professione legale (i.e. l’uso di output non verificati, potenzialmente contenenti informazioni errate, false o fuorvianti può minare la fiducia nella capacità dell’Avvocato di fornire una consulenza competente e affidabile);
• lealtà verso il Cliente (i.e. l’uso di output non verificati, può pregiudicare gli interessi del Cliente),
• integrità personale e rispetto dello Stato di diritto,
• corretta amministrazione della giustizia.

Gli Avvocati che utilizzano contenuti generati dall’IA senza un’adeguata verifica possono essere soggetti a sanzioni disciplinari o procedimenti per negligenza professionale; con conseguente pregiudizio per gli interessi e la fiducia del Cliente, oltre che per la reputazione dell’Avvocato.

Conclusioni

La Guida CCBE non nasce per rispondere a una moda tecnologica, ma a una trasformazione strutturale che sta ridefinendo le modalità dell’esercizio della professione forense. Ignorarla non è più una scelta neutrale.

Il vero nodo non è tecnico, ma culturale. I sistemi di GenAI non sostituiscono il giudizio dell’Avvocato, ma lo mettono alla prova in modo nuovo; richiedono una vigilanza più attiva, una capacità critica più affinata, una responsabilità più consapevole. Il rischio più insidioso non è l’allucinazione del modello, bensì la possibile “superficialità” di chi lo utilizza e che vi ricorre senza un adeguato livello di consapevolezza e di controllo.

È in questo spazio – tra l’output dell’algoritmo e la supervisione vigile ed attenta dell’Avvocato – che si gioca la qualità della consulenza legale dei prossimi anni. Presidiarlo con competenza, trasparenza e rigore deontologico non è un onere aggiuntivo: è, oggi più che mai, il cuore dell’aspettativa che il Cliente ripone nei confronti del Professionista e dello Studio legale.

Note

[1] I.e. Legge 23 Settembre 2025 n.132 (Disposizioni e deleghe del Governo in materia di Intelligenza Artificiale) pubblicata in GURI 25 Settembre 2025 n.223.

[2] Letteralmente, per previsione dell’art. 13 (Disposizioni in materia di professioni intellettuali) della Legge: “L’utilizzo di sistemi di intelligenza artificiale nelle professioni intellettuali è finalizzato al solo esercizio delle attività strumentali e di supporto all’attività professionale e con prevalenza del lavoro intellettuale oggetto della prestazione d’opera. Per assicurare il rapporto fiduciario tra professionista e cliente, le informazioni relative ai sistemi di intelligenza artificiale utilizzati dal professionista sono comunicate al soggetto destinatario della prestazione intellettuale con linguaggio chiaro, semplice ed esaustivo”.

[3] I.e. Regolamento del Parlamento europeo e del Consiglio, 13 Giugno 2024 n. 1689/2024/UE che stabilisce regole armonizzate sull’IA e modifica i Regolamenti n. 1689/2024/UE (CE) n.300/2008/UE, n.167/2013/UE, n.2018/858/UE, n.2018/1139/UE e n.2019/2144/UE e le direttive n.2014/90/UE e 2000/1828/UE – Anche IA Act o Regolamento sull’’Intelligenza Artificiale, pubblicato in GUUE 12 Luglio 2024 n. L 2024/1689.

[4] Istituito per tutelare i diritti della categoria forense, garantire il rispetto della deontologia forense e collaborare con il Ministero della Giustizia, il CNF ha sede a Roma ed esercita funzioni giurisdizionali, disciplinari e consultive. Gestisce l’Albo degli Avvocati abilitati al patrocinio dinanzi alle giurisdizioni superiori (Corte di Cassazione), giudica sui reclami disciplinari adottati dai Consigli dell’Ordine territoriali e promuove la formazione continua e le scuole forensi.

[5] I.e. Decreto Legislativo 31 Marzo 2023 n.36 (Codice dei contratti pubblici in attuazione dell’art. 1 L.21 giugno 2022 n.78 recante delega al Governo in materia di contratti pubblici come integrato e modificato dal D.Lgs. 31 dicembre 2024 n.209), pubblicato in GURI 31 Marzo 2023 n.77 SO n.12.

[6] Entrambi i documenti sono reperibili sul sito COA Milano al seguente link: https://www.ordineavvocatimilano.it/it/news/guida-del-ccbe-sulluso-dellintelligenza-artificiale-generativa-da-parte-degli-avvocati/p100-n2963.

[7] In tal senso sono i rimandi di cui all’Allegato 1 della Guida CCBE strutturato in ordine alfabetico e per Nazione, Paese o Istituzione di riferimento (i.e. Argentina, Australia, Belgio, Brasile, Canada, Cina, Colombia, Repubblica Ceca, Emirati Arabi Uniti, Estonia, Francia, Irlanda, Italia, Malesia, Nuova Zelanda, Nigeria, Polonia, Repubblica del Sud Africa, Singapore, Spagna, Svezia, Regno Unito, Stati Uniti, CJEU -Corte di giustizia UE, FBE – Federazione Europea degli Ordini Forensi, Consiglio d’Europa, IBA – Associazione Internazionale degli Avvocati , ABA – Associazione Americana degli Avvocati – UNESCO).

[8] La Carta è reperibile sul sito del COA Milano al seguente link: https://www.ordineavvocatimilano.it/it/news/la-carta-dei-principi-per-un-uso-consapevole-dei-sistemi-di-intelligenza-artificiale-in-ambito-forense/p100-n2587

[9] I.e. Articoli CDF- Codice Deontologico Forense di riferimento: Artt. 14 e 15 (Dovere di competenza e di aggiornamento); Att. 10 e 26 (Dovere di diligenza e di indipendenza); Artt. 13 e 28 (Dovere di riservatezza, Segreto professionale); Artt. 27 (Dovere di informazione e trasparenza verso il cliente); Art. 17 (Decoro e Comunicazione professionale); Art. 50 (Dovere di verità).

[10] Oltre ai 46 Stati Membri del Consiglio d’Europa, la Convenzione è aperta alla firma di tutti i Paesi del mondo e mira a stabilire norme comuni per un’IA affidabile. Vi aderiscono, Stati Uniti, Andorra, Georgia, Islanda, Norvegia, Moldavia, San Marino, Regno Unito, Israele ed UE.

[11] Nella Guida CCBE si legge anche sul punto che: “Così come oggi è possibile creare deepfake di personaggi pubblici, in futuro potrebbe diventare possibile realizzate deepfake di interi Studi legali con lo scopo di trarre in inganno i Clienti. Potrebbero inoltre essere falsificate le identità di persone che gli Avvocati devono verificare nell’ambito dell’attività di due diligence”. Occorre quindi riflettere su questi ulteriori possibili rischi per il legale, per contrastarli con misure preventive efficaci.

https://www.ictsecuritymagazine.com/articoli/gen-ai-guida-ccbe/