Sicurezza AI: i router LLM diventano il punto debole della supply chain (caso LiteLLM)

Una ricerca sistematica di UC Santa Barbara, UC San Diego, Fuzzland e World Liberty Financial ha analizzato 428 router commerciali e gratuiti, individuando intermediari che riscrivono attivamente le tool-call degli agenti di coding ed esfiltrano credenziali. L’incidente LiteLLM del marzo 2026 conferma, su scala industriale, che la minaccia non è più teorica.

Sicurezza AI a rischio: perché i router LLM stanno diventando il nuovo punto debole negli attacchi informatici

Ogni volta che un agente LLM, un Claude Code, un Codex o un Cursor, invia una richiesta a un provider di modelli, il traffico attraversa quasi sempre uno o più intermediari applicativi. Si chiamano router, o API gateway, e aggregano decine di provider dietro un’unica interfaccia compatibile con OpenAI. Gestiscono fallback, bilanciamento di carico e ottimizzazione dei costi; un singolo cambio di base URL e una nuova chiave API bastano per instradare un’intera flotta di agenti attraverso un servizio terzo.

La scelta è così banale che, in molte organizzazioni, viene presa al livello di una configurazione di sviluppo. Il fatto che, una volta puntato quel percorso, il client non abbia alcun modo di verificare crittograficamente cosa abbia davvero prodotto il modello a monte è un dettaglio che, fino a poco tempo fa, quasi nessuno ha considerato.

Un gruppo di ricercatori guidato da Hanzhi Liu (UC Santa Barbara), con Chaofan Shou (Fuzzland), Hongbo Wen (UCSB), Yanju Chen (UC San Diego), Ryan Jingyang Fang (World Liberty Financial) e Yu Feng (UCSB), ha deciso di misurarlo. Il paper «Your Agent Is Mine» (arXiv:2604.08407v1, cs.CR, 9 aprile 2026) è il primo studio sistematico sull’ecosistema dei router LLM visti come confine di fiducia della supply chain dell’IA. Il risultato è meno rassicurante del previsto.

Un man-in-the-middle “legittimo” nella sicurezza AI

Il modello di minaccia formalizzato dagli autori parte da un’osservazione architetturale semplice: il router, per sua natura, termina la sessione TLS lato client e ne apre una nuova verso il provider. Occupa quindi una posizione di man-in-the-middle applicativo non accidentale, ma intenzionalmente configurata dall’utente. Nessun TLS downgrade, nessuna forgery di certificati: basta che il client abbia puntato l’endpoint a quel servizio. Da lì il router vede in chiaro tool definition, prompt di sistema, chiavi API, output dei tool e, soprattutto, le tool-call che l’agente sta per eseguire. Può leggerle, trattenerle, riscriverle o fabbricarle ex novo.

La chain-integrity, notano gli autori, è una proprietà del tipo weakest link: in una catena di k hop (utente -> rivenditore -> aggregatore -> OpenRouter -> provider, tanto per restare su uno scenario realistico), un singolo router malevolo in qualunque posizione è sufficiente a compromettere l’intera traiettoria. Gli hop onesti a valle non possono né rilevare né annullare la modifica, perché non hanno alcun riferimento alla risposta originale prodotta dal provider.

Attacchi hacker AI: le 4 tecniche che sfruttano i router LLM

Su questa base, il team costruisce una tassonomia di quattro classi. Le due primitive di base sono AC-1, ovvero response-side payload injection, in cui il router riscrive gli argomenti JSON di una tool-call dopo che il modello ha risposto ma prima che il client la esegua, e AC-2, ovvero passive secret exfiltration, in cui il router si limita a leggere il traffico e a conservare asincronamente chiavi API, PAT GitHub, token AWS, chiavi private Ethereum, chiavi PEM.

A queste si aggiungono due varianti di evasione adattiva. AC-1.a (dependency-targeted injection) sostituisce nel comando di installazione un nome di pacchetto legittimo con un typosquat preregistrato su PyPI o npm, lasciando invariato il resto della riga di comando e ingannando così le approval UI basate sui domini. L’esempio che figura nel paper è istruttivo: pip install requests
viene riscritto in pip install reqeusts
, una singola lettera invertita, un pacchetto preregistrato dall’attaccante, una dipendenza che viene memorizzata nella cache locale e reimportata in ogni sessione futura.

Un foothold di supply chain durevole ottenuto in uno scambio JSON. AC-1.b (conditional delivery) attiva la riscrittura solo quando un predicato di sessione è verificato: dopo N richieste benigne, per client in modalità autonoma (cosiddetta YOLO, in cui l’agente esegue i tool senza chiedere conferma comando per comando), in determinate finestre orarie o per progetti scritti in linguaggi target. Il predicato vive server-side, è opaco al client, e rende strutturalmente inadeguato qualunque audit black-box di lunghezza finita.

Il punto architetturale, sottolineano gli autori, è che questi attacchi sono ortogonali alla prompt injection: non modificano il ragionamento del modello, agiscono sul layer JSON a valle dell’inferenza. Si compongono con le difese lato modello anziché sostituirle.

Vulnerabilità reali: cosa succede dentro i router LLM

Il dataset combina due popolazioni. La prima è costituita da 28 router a pagamento acquistati da Taobao, Xianyu e vetrine Shopify, mercati dove, come documentato da inchieste precedenti di ChinaTalk, alcuni negozi accumulano oltre 30 000 ordini ripetuti solo per la rivendita di accesso API. La seconda è composta da 400 router gratuiti raccolti da community pubbliche, link in chiaro e dump di configurazione. La maggior parte è costruita sui due template open source più diffusi, sub2api (circa 11 000 stelle su GitHub) e new-api (25 400 stelle, 1,25 milioni di pull da Docker Hub), il cui fork a monte one-api ne conta altre 30 500 con 1,19 milioni di pull.

Testati con una pipeline automatizzata che genera tool-call realistiche a partire da TerminalBench 2.0 e le esegue in sandbox monitorate, i numeri sono i seguenti: 1 router a pagamento e 8 gratuiti iniettano attivamente codice malevolo nelle risposte, riscrivendo comandi o dipendenze prima della consegna al client; 17 router gratuiti generano attività AWS successiva attribuibile a credenziali canary di ricerca osservate in transito; 1 router drena ETH da una chiave privata Ethereum predisposta come esca.

Due router implementano già in produzione logiche di evasione adattiva: uno attiva la riscrittura solo dopo cinquanta chiamate pulite, un altro la riserva a sessioni in modalità YOLO e a progetti scritti in Rust o Go. Logica operativa, non esotica, sufficiente a lasciar passare puliti gli smoke test superficiali e a eseguire il rewrite solo su sessioni di alto valore.

Caso LiteLLM: il primo grande attacco alla supply chain AI

La parte più inquietante è che uno scenario analogo è già avvenuto alla scala di un progetto di riferimento. Tra le 10:39 UTC e le 16:00 UTC del 24 marzo 2026, due versioni compromesse del pacchetto Python litellm, la 1.82.7 e la 1.82.8, sono rimaste pubblicate su PyPI, caricate direttamente dal gruppo noto come TeamPCP dopo aver ottenuto le credenziali PyPI del maintainer attraverso una precedente compromissione di Trivy, lo scanner di vulnerabilità open source usato nella CI/CD di LiteLLM stessa.

La campagna complessiva è tracciata dal CVE-2026-33634 (CVSS v4.0 Base 9,4, CVSS v3.1 Base 8,8, CWE-506 Embedded Malicious Code), formalmente assegnato alla vulnerabilità di Trivy che ha fatto da testa di ponte, e successivamente inserita dalla CISA nel catalogo Known Exploited Vulnerabilities.

I pacchetti LiteLLM contenevano un credential stealer embedded nel file proxy_server.py ed esfiltravano verso un dominio di typosquatting (models.litellm[.]cloud); la versione 1.82.8 aggiungeva inoltre un file litellm_init.pth che veniva eseguito a ogni invocazione dell’interprete Python sull’host, indipendentemente dall’import esplicito di LiteLLM. Endor Labs ha descritto il payload come un credential harvester su chiavi SSH, credenziali cloud, secret Kubernetes, wallet di criptovaluta e file .env, accompagnato da un toolkit di lateral movement Kubernetes e da una backdoor systemd persistente (sysmon.service).

I clienti di LiteLLM Cloud e quelli che usavano l’immagine Docker ufficiale LiteLLM Proxy non sono stati impattati, perché quelle pipeline pinnano le dipendenze in requirements.txt
; a essere colpiti sono stati chi ha eseguito pip install litellm
senza pin di versione nella finestra di esposizione e chi aveva LiteLLM come dipendenza transitiva non pinnata, ad esempio tramite framework di agenti, server MCP o orchestrator LLM.

LiteLLM non è un caso limite: secondo i dati riportati da Snyk e Zscaler ThreatLabz, il pacchetto viene scaricato circa 3,4 milioni di volte al giorno ed è integrato nelle pipeline di produzione di migliaia di organizzazioni. Wiz, nella propria analisi dell’incidente, riporta che litellm è presente nel 36 per cento di tutti gli ambienti cloud osservati. L’episodio ha dimostrato, in un contesto produttivo reale, esattamente la primitiva su cui il paper UCSB costruisce il suo threat model: una volta compromesso il pipeline delle richieste di un router ampiamente deployato, ogni tool-call, chiave API e prompt di sistema in transito è esposto alla riscrittura o all’estrazione, senza necessità di rompere il TLS o i pesi del modello.

Perché anche i router “sicuri” possono essere compromessi

Il cuore politico del paper è però la terza sezione empirica: i due studi di poisoning. L’idea è che i router apparentemente benigni possano essere trascinati nello stesso perimetro di attacco non perché cambi il gestore, ma perché la catena a monte viene inquinata.

Nel primo esperimento i ricercatori hanno pubblicato intenzionalmente una chiave OpenAI di ricerca su forum cinesi, gruppi WeChat e Telegram frequentati da operatori di relay. Una sola chiave ha processato cento milioni di token GPT-5.4 e più di sette sessioni Codex distinte. In almeno una di quelle sessioni, precisano gli autori, sono state osservate più credenziali distinte transitare dietro la stessa chiave condivisa; un pattern compatibile sia con il riuso diretto da parte dell’operatore del router sia con il riuso all’interno di una catena di relay più lunga.

Nel secondo esperimento il team ha deployato decoy volutamente deboli: istanze claude-relay-service vulnerabili su venti domini, e istanze Sub2API e CLIProxyAPI con password deboli su venti indirizzi IP. I decoy hanno ricevuto oltre 40 000 tentativi di accesso non autorizzati da 147 IP distinti con sei fingerprint JA3 unici, hanno servito circa due miliardi di token GPT-5.4 e 5.3-codex, hanno esposto all’incirca tredici gigabyte di traffico downstream in chiaro e hanno raccolto 99 credenziali distinte su 440 sessioni Codex e 398 progetti o host.

Qui arriva il dato che dovrebbe interessare chiunque si occupi di governance dell’IA generativa in azienda. Di quelle 440 sessioni, tutte esponevano almeno un percorso di esecuzione shell riscrivibile, e 401 giravano già in modalità YOLO, cioè con l’auto-approvazione dei tool attivata lato client. Per 401 sessioni su 440, l’AC-1.b sofisticato con predicati di sessione non sarebbe nemmeno servito: sarebbe bastata la versione più grezza dell’iniezione di payload. L’autonomia del client, in altre parole, è già da sola la superficie di attacco.

Come difendersi dagli attacchi AI oggi

Gli autori implementano anche Mine, un proxy di ricerca che porta in produzione tutte e quattro le classi di attacco contro quattro framework pubblici (OpenClaw, OpenCode, Codex di OpenAI, Claude Code di Anthropic) e, soprattutto, tre difese immediatamente deployabili senza cooperazione del provider. Mine non viene distribuito pubblicamente: nell’appendice etica gli autori motivano la scelta come una valutazione classica di ricerca dual-use.

La prima difesa è un policy gate fail-closed sui tool ad alto rischio: blocca ogni campione AC-1 e AC-1.a del benchmark sintetico con un tasso di falsi positivi dell’1 per cento e un costo di decisione mediano di 2,3 microsecondi. Difesa robusta sul perimetro comportamentale ingenuo, ma non a prova di avversario consapevole: sullo stesso benchmark, se l’attaccante ospita il payload su un dominio già in allowlist o pre-posiziona uno stager locale da richiamare in seguito, il gate viene bypassato nel cento per cento dei casi. Lo si consideri quindi un filtro grossolano per i workflow più ovvi, non una linea di difesa completa.

La seconda è una anomaly detection sulle risposte, basata su Isolation Forest e cinque feature (punteggio di rischio shell, frequenza del tool nella sessione, entropia degli argomenti, pattern sospetti di secret, deviazione dallo schema). A un budget di falsi positivi del 6,7 per cento intercetta l’89 per cento dei payload AC-1, il 50 per cento degli AC-1.a e circa il 51 per cento degli AC-1.b. Utile come strumento di prioritizzazione della review, non come gate di blocco. L’ablation presentata nell’appendice mostra che il grosso del segnale deriva dal punteggio di rischio shell: rimuoverlo fa precipitare la detection di AC-1 al 17,6 per cento, a conferma che il detector è essenzialmente un filtro sintattico specializzato su una classe di comandi.

La terza è un log di trasparenza append-only che registra body di richiesta e risposta, URL del router, metadati TLS e hash dei byte grezzi della risposta dopo redazione dei secret. Non previene nulla, ma costa circa 12 MB ogni mille sessioni (1,26 KB per entry) e consente, a posteriori, di delimitare l’esposizione quando una chiave o un operatore vengono considerati sospetti. È il tipo di controllo che, nell’ottica di un SOC, chiude il ciclo di incident response senza cambiare il modello di fiducia.

Il limite attuale della sicurezza AI: manca la verifica delle risposte

Nessuno di questi tre controlli autentica l’origine. Un router che si mantenga all’interno degli allowlist locali e sappia evitare pattern troppo evidenti può comunque alterare la semantica dei tool-call senza che il client abbia modo di accorgersene. La conclusione degli autori è esplicita: chiudere la falla richiede una busta firmata dal provider, un oggetto JSON canonicalizzato (nell’appendice C del paper ne è proposta una struttura ispirata a DKIM, RFC 6376, e alla canonicalizzazione JCS di RFC 8785) che contenga identità del provider, modello, contenuto, tool-call con argomenti nativi, nonce del client, finestra di validità e firma Ed25519. Nessun provider di tool-use e nemmeno la specifica MCP attuale espongono oggi un meccanismo simile.

Sicurezza informatica aziende: cosa fare subito

Fino a quando quel meccanismo non esisterà, la conseguenza operativa per CISO, CTO e team DevSecOps è immediata. Il trust boundary reale di un agente LLM non coincide con il router che l’utente ha scelto di configurare: coincide con il più debole router presente nell’intera catena a valle, con ogni credenziale precedentemente trapelata che qualcuno lungo quella catena stia ancora riutilizzando e con il livello di autonomia che il client ha lasciato attivo. Una sessione YOLO su un endpoint gratuito pescato in un gruppo Telegram non è un power user che sa quel che fa: è una superficie di attacco su cui, alla luce dei dati appena pubblicati, è già stato scritto abbastanza per non considerarla più teorica.

Sul piano delle policy aziendali, il paper suggerisce alcune scelte che difficilmente potranno essere rimandate a lungo. L’inventario degli endpoint LLM effettivamente usati da sviluppatori e agenti interni va fatto con lo stesso rigore con cui si inventariano i provider cloud, e non può fermarsi al router di primo livello: deve seguire, dove possibile, l’intera catena di relay.

Le modalità autonome dei coding agent richiedono un contenimento attivo, ovvero sandbox, devcontainer o macchine dedicate con accesso di rete limitato a una lista di host fidati; questo è del resto anche l’orientamento esplicitato da Anthropic nella propria documentazione «Safe YOLO» per Claude Code, che raccomanda l’uso di --dangerously-skip-permissions
solo all’interno di container senza accesso a Internet. Le chiavi che transitano sui router non devono essere a lunga durata: sono token scoped a scadenza breve, ruotati su incidente e, dove il vendor lo supporta, emessi per singolo task.

E per i tool a più alto rischio, quelli che chiamano Bash, run_command
, pip install
, npm install
, cargo add
, un policy gate lato client con allowlist esplicita di domini e pacchetti è, pur con tutti i suoi limiti, un investimento dall’ottimo rapporto costo-beneficio rispetto alle alternative odierne.

Conclusione: la nuova frontiera degli attacchi AI

Il messaggio di fondo del lavoro di Liu e colleghi è che la supply chain degli agenti LLM non comincia al provider del modello e non finisce al client: passa per uno strato di intermediari che oggi il mercato tratta come trasporto trasparente e che, per come è fatto, non può esserlo. Renderlo verificabile è un problema di standard, non di buone pratiche.

Condividi sui Social Network:

https://www.ictsecuritymagazine.com/notizie/sicurezza-ai-router-llm/




E-evidence, l’Italia chiude il cerchio: cosa cambia davvero con i d.lgs. 215 e 216 del 2025

Con i decreti legislativi 30 dicembre 2025, n. 215 e n. 216, pubblicati nella Gazzetta Ufficiale n. 11 del 15 gennaio 2026, l’Italia ha imboccato il tratto finale di attuazione del pacchetto europeo sulle prove elettroniche (E-evidence). Due testi, due tempi, un unico obiettivo: rendere operativo sul territorio nazionale un modello di acquisizione transfrontaliera dei dati digitali che, dal 18 agosto 2026, cambierà in modo strutturale il rapporto fra autorità giudiziarie, prestatori di servizi e cittadini. Il 7 aprile 2026, a poche settimane dall’operatività, l’Ufficio del Massimario della Corte di Cassazione ha pubblicato la Relazione n. 25/2026, a firma della dott.ssa Caterina Brignone, che offre la prima lettura sistematica del quadro attuativo nazionale.

La posta in gioco si misura con un dato ricorrente nei documenti della Commissione europea: circa l’85% delle indagini penali nell’Unione coinvolge prove elettroniche, e in una quota significativa dei casi quei dati sono conservati in uno Stato diverso da quello in cui il reato è stato commesso. Fino a ieri, per raggiungerli, le procure dovevano attivare canali di assistenza giudiziaria lenti e spesso scoordinati. L’e-evidence package nasce per scardinare questa asimmetria fra la velocità del dato e la lentezza del diritto.

Due pilastri europei, scadenze a incastro

Il pacchetto si compone del regolamento (UE) 2023/1543 e della direttiva (UE) 2023/1544, entrambi del 12 luglio 2023 e pubblicati nella Gazzetta Ufficiale dell’Unione il 28 luglio dello stesso anno. La scelta di procedere con un doppio strumento riflette una divisione del lavoro precisa: da un lato le regole di procedura, direttamente applicabili negli ordinamenti nazionali; dall’altro l’architettura di compliance imposta ai prestatori di servizi, che richiede interventi adattivi di ciascuno Stato membro. È un tassello di quella più ampia convergenza normativa europea in materia di sicurezza digitale in cui si inseriscono anche NIS2, DORA e CER.

Il cuore operativo del regolamento sono due strumenti giudiziari, destinati a entrare nel lessico quotidiano degli operatori: l’ordine europeo di produzione (EPOC) e l’ordine europeo di conservazione (EPOC-PR). Il primo consente all’autorità giudiziaria di uno Stato membro di richiedere direttamente al fornitore di servizi, anche se stabilito altrove nell’Unione, la trasmissione di dati elettronici già esistenti. Il secondo ha funzione preservativa: impone al provider di congelare i dati per un massimo di sessanta giorni, prorogabili di ulteriori trenta, in attesa di un successivo ordine di produzione o di una rogatoria. I tempi di risposta sono stringenti: dieci giorni in via ordinaria, otto ore nei casi di emergenza.

La direttiva, dal canto suo, costringe ogni prestatore che offre servizi nell’Unione a dotarsi di un interlocutore fisico nel territorio UE, sotto forma di stabilimento designato o di rappresentante legale. Senza questa figura, gli ordini europei non avrebbero un destinatario certo e il meccanismo si svuoterebbe di efficacia.

Le scadenze europee si muovono su due livelli da non confondere: entro il 18 febbraio 2026 gli Stati membri devono recepire la direttiva e notificare alla Commissione le disposizioni sulle sanzioni; entro il 18 agosto 2026 devono essere rese operative le designazioni da parte dei prestatori che offrono servizi nell’Unione a quella data, mentre i nuovi provider dispongono di sei mesi dall’avvio dell’attività (articolo 3, paragrafo 6 della direttiva).

La data del 18 agosto 2026 coincide, non a caso, con la data di applicazione del regolamento (articolo 34, paragrafo 2). Il regolamento, entrato in vigore il 18 agosto 2023, diventa quindi pienamente operativo tre anni dopo, in un sistema finalmente completo di destinatari.

Il doppio binario italiano: prima il “chi”, poi il “come”

La legge di delegazione europea 2024, legge 13 giugno 2025, n. 91, ha programmato l’implementazione disegnando un cronoprogramma simmetrico a quello dei due strumenti europei. Agli articoli 7 e 19 ha introdotto principi e criteri direttivi per il recepimento, rispettivamente, della direttiva e del regolamento.

Il Governo ha scelto una via a due tappe: un primo decreto, il 215/2025, orientato a rispettare la scadenza del 18 agosto 2025, data entro la quale gli Stati membri dovevano notificare alla Commissione le autorità competenti ex articolo 31 del regolamento; un secondo decreto, tuttora in iter (lo schema è stato approvato in esame preliminare dal Consiglio dei Ministri il 22 dicembre 2025), che completerà l’adeguamento dell’ordinamento interno. In parallelo, il d.lgs. 216/2025 ha recepito la direttiva, fissando sul suolo italiano il perimetro degli obblighi a carico dei prestatori.

Il d.lgs. 215/2025, a seguito della pubblicazione in Gazzetta Ufficiale del 15 gennaio 2026, è entrato in vigore il 30 gennaio 2026. La Relazione dell’Ufficio del Massimario della Cassazione articola la propria analisi in tre parti: quadro europeo della prova digitale, attuazione nazionale del pacchetto con il modello processuale degli ordini europei, ricadute organizzative e prospettive di sistema. Una lettura di riferimento, destinata a orientare la prassi nei mesi che precedono l’ingresso a regime del meccanismo, che si affianca al primo commento di Claudio De Lazzaro già circolato in dottrina.

D.lgs. 216/2025: il pre-requisito di sistema

Il primo decreto legislativo che conviene leggere, dal punto di vista dei provider, non è il 215 ma il 216. Stabilisce infatti la condizione abilitante di tutto ciò che verrà dopo: senza stabilimento designato o rappresentante legale, nessun ordine europeo potrà essere legittimamente ricevuto ed eseguito.

L’obbligo grava su una platea ampia: operatori di comunicazione elettronica, registrar di nomi di dominio, assegnatari di numerazione IP, prestatori di servizi della società dell’informazione che consentono comunicazioni fra utenti o ne conservano i dati.

In termini concreti: cloud provider, piattaforme di messaggistica, social network, servizi over-the-top, fornitori di hosting, marketplace e simili. Sono invece espressamente esclusi dall’ambito di applicazione i prestatori di servizi finanziari (banche, assicurazioni, intermediari, servizi di pagamento, consulenza sugli investimenti), che non saranno quindi chiamati a designare stabilimenti o a nominare rappresentanti ai fini del pacchetto e-evidence, e non potranno essere destinatari di EPOC o EPOC-PR. Una scelta non priva di conseguenze, che riflette la decisione del legislatore europeo di tenere il comparto finanziario al riparo da questo circuito, in attesa di strumenti dedicati.

L’autorità centrale nazionale, quella a cui i prestatori devono notificare l’avvenuta designazione, è stata individuata nel Ministero dell’interno e, in particolare, nell’organo per la sicurezza e la regolarità dei servizi di telecomunicazione di cui all’articolo 7-bis del decreto-legge 144/2005, convertito dalla legge 155/2005. La notifica va effettuata entro trenta giorni dalla designazione o nomina; i dati di contatto e la lingua accettata saranno poi pubblicati sul sito della rete giudiziaria europea in materia penale e sul portale del Ministero della giustizia. Per un approfondimento sull’articolato del decreto rinviamo al dossier del Senato sull’Atto del Governo n. 330.

Il decreto chiude il cerchio con due previsioni che meritano attenzione: la responsabilità solidale fra prestatore, stabilimento designato e rappresentante legale in caso di inottemperanza, pensata per impedire il rimpallo di responsabilità fondato sull’asserita mancanza di procedure interne adeguate; e un regime sanzionatorio speciale, regolato dall’articolo 7, che si affianca e non si sovrappone alle sanzioni penali eventualmente applicabili. Un’architettura che, sul piano della compliance, impone al prestatore di trattare la figura del rappresentante legale non come un adempimento formale, ma come nodo critico del proprio modello organizzativo.

D.lgs. 215/2025: chi emette, chi riceve, chi controlla

Il 215 è il decreto che traccia la mappa delle autorità italiane coinvolte, sia in fase attiva (emissione) sia in fase passiva (ricezione ed esecuzione di ordini provenienti da altri Stati membri). La relazione illustrativa al Senato chiarisce che si tratta di un primo step di implementazione, concepito per rispettare la scadenza di notifica alla Commissione e in attesa del decreto complementare.

La logica di fondo ricalca fedelmente la graduazione delle garanzie prevista dal regolamento, che distingue quattro categorie di dati lungo una scala di invasività crescente:

  • dati relativi agli abbonati (articolo 3, punto 9);
  • dati richiesti al solo scopo di identificare l’utente (punto 10);
  • dati relativi al traffico (punto 11);
  • dati relativi al contenuto (punto 12).

Alle prime due categorie corrispondono garanzie più snelle; alle ultime due, presidi più rigorosi. Il decreto traduce questa scala nel linguaggio del processo penale italiano. Nel corso delle indagini preliminari, per gli ordini di produzione relativi ai dati degli abbonati e di identificazione provvede il pubblico ministero; per i dati di traffico e di contenuto, il giudice per le indagini preliminari. Per l’ordine di conservazione, trattandosi di un “congelamento” preliminare e non di un’apprensione, provvede sempre il pubblico ministero in via esclusiva, qualsiasi sia la natura del dato.

Nei casi di emergenza, definiti all’articolo 3, punto 18 del regolamento come situazioni di minaccia imminente alla vita, all’integrità fisica o a un’infrastruttura critica, gli ufficiali di polizia giudiziaria possono emettere l’ordine con efficacia immediata, trasmettendolo al pubblico ministero entro quarantotto ore per la convalida, a sua volta da adottare entro le successive quarantotto ore con decreto motivato.

Per le fasi successive alle indagini preliminari, la competenza coincide con quella del giudice che procede, su richiesta del pubblico ministero, della persona offesa, dell’indagato, dell’imputato o delle parti private. Il regolamento consente infatti anche alla difesa di sollecitare l’emissione di un EPOC, aprendo uno spazio nuovo di iniziativa difensiva che, a regime, potrebbe modificare in profondità la geografia dell’acquisizione della prova digitale nel procedimento penale.

Un presidio di sistema non marginale è la clausola di inutilizzabilità sancita all’articolo 2, comma 7: i dati acquisiti con un ordine europeo di produzione emesso fuori dai casi o in mancanza delle condizioni previste dal regolamento e dal decreto non possono essere utilizzati nel procedimento.

La “procedura accelerata”: una novità senza precedenti

Uno dei profili più interessanti del 215 è l’articolo 4, che introduce una procedura accelerata destinata a operare fuori dai casi di emergenza tipici definiti dal regolamento, ma in situazioni d’urgenza che impongono comunque una decisione tempestiva. Secondo la stessa relazione illustrativa, si tratta di un modulo che non trova precedenti nella legge processuale nazionale.

Il meccanismo è quello della previa convalida: il pubblico ministero (per ottenere i dati di traffico o di contenuto) o l’ufficiale di polizia giudiziaria (per i dati degli abbonati e di identificazione) emette l’ordine, la cui efficacia è però sospesa fino alla convalida dell’autorità superiore. L’ordine è trasmesso entro ventiquattro ore dall’emissione; il giudice per le indagini preliminari (nel primo caso) o il pubblico ministero (nel secondo) decide sulla convalida entro le successive quarantotto ore.

Un’architettura che si distingue per tempistiche da quella della procedura d’emergenza, disegnata con un modulo 48+48. La base normativa si rinviene nell’articolo 4, paragrafo 1, lettera b) e paragrafo 2, lettera b) del regolamento, che lascia agli Stati margine di manovra per definire autorità e procedure in casi urgenti. L’Italia ha sfruttato questo spazio per disegnare un percorso speditivo destinato a coprire quella zona grigia in cui l’emergenza tipizzata non sussiste, ma l’attesa dei tempi ordinari rischierebbe di compromettere l’indagine.

Coordinamento investigativo: DNA, Procura generale, Eurojust

Il decreto non trascura il profilo del coordinamento. Quando l’ordine riguarda delitti rientranti nella competenza distrettuale rafforzata (articoli 51, commi 3-bis e 3-quater, e 371-bis, comma 4-bis, c.p.p., nonché i delitti di cui all’articolo 118-bis delle norme di attuazione del codice di procedura penale), copia del certificato EPOC o EPOC-PR è trasmessa alla Procura nazionale antimafia e antiterrorismo o al Procuratore generale presso la Corte d’appello. Dove operino i meccanismi di coordinamento europeo, l’informazione è trasmessa anche al membro nazionale di Eurojust, ai sensi dell’articolo 21, paragrafo 5 del regolamento (UE) 2018/1727.

È una previsione tutt’altro che marginale. Per la prima volta, un flusso investigativo digitale così denso di dati, spesso relativi a soggetti stranieri o transnazionali, viene canalizzato fin dall’origine verso gli organi di coordinamento nazionali ed europei. Per i CISO delle aziende destinatarie di ordini, questo significa che ogni EPOC ricevuto potrebbe avere, a monte, un’operazione di respiro europeo di cui il prestatore è solo una tessera.

Fase passiva: chi riceve gli ordini stranieri

Simmetricamente, il 215 disciplina la competenza interna per la ricezione e l’esecuzione di ordini emessi da autorità di altri Stati membri. La scelta del legislatore è quella della procura distrettuale: è il procuratore della Repubblica presso il tribunale del capoluogo del distretto in cui lo stabilimento designato o il rappresentante legale sono stabiliti a ricevere le notifiche e a gestire l’esecuzione degli ordini di produzione per dati abbonati e identificativi e degli ordini di conservazione. Per gli ordini di produzione relativi a dati di traffico o di contenuto la competenza si sposta sul GIP dello stesso tribunale, coerentemente con la graduazione delle garanzie.

Quanto alla trasmissione amministrativa degli ordini e delle notifiche, l’articolo 5 individua nel Ministero della giustizia l’autorità centrale cui fare riferimento ai sensi dell’articolo 4, paragrafo 6 del regolamento.

Per gestire l’articolo 17 del regolamento, che regola i casi in cui il prestatore solleva un’obiezione motivata per contrasto con obblighi di diritto di un paese terzo, il decreto individua due percorsi alternativi di riesame: il tribunale del riesame delle misure reali se l’ordine è stato emesso o convalidato dal giudice, il GIP se è stato emesso o convalidato dal pubblico ministero.

L’onda lunga sul diritto interno: art. 132 Codice Privacy e il nuovo art. 263-bis c.p.p.

Forse il segmento più sottovalutato del 215, ma quello con l’impatto sistemico più ampio, è l’articolo 9. Qui il legislatore ha compiuto una serie di interventi di coordinamento sull’ordinamento interno, con due effetti principali.

Il primo riguarda l’articolo 132 del Codice Privacy (d.lgs. 196/2003), la disposizione cardine sulla conservazione e l’acquisizione del traffico telefonico e telematico.

Il testo viene riscritto in più punti: si introduce la possibilità di acquisire i dati di traffico anche per agevolare le ricerche di un latitante condannato con sentenza definitiva a pena non inferiore a quattro mesi, in coerenza con l’articolo 5 del regolamento; si estende il potere di ordinare la conservazione dei dati al pubblico ministero, che diventa così titolare di uno strumento “domestico” simmetrico all’EPOC-PR europeo; si uniforma la disciplina dei dati telefonici e telematici, eliminando un’asimmetria del vecchio comma 4-ter non più giustificata. Il parere del Garante Privacy del 25 settembre 2025 aveva già auspicato questo coordinamento, sottolineando la necessità di evitare fratture fra disciplina europea e disciplina domestica della data retention.

Il secondo intervento è l’introduzione di un nuovo articolo nel codice di procedura penale, il 263-bis c.p.p., che disciplina la conservazione dei dati relativi al contenuto, la categoria che l’articolo 132 del Codice Privacy, per sua vocazione, non copriva. Il pubblico ministero può ordinarne la conservazione; la polizia giudiziaria può provvedervi in via d’urgenza, con convalida successiva. Per la prima volta l’ordinamento italiano ha uno strumento nominato e disciplinato per “congelare” i contenuti delle comunicazioni in attesa dell’acquisizione vera e propria, saldando un vuoto che, nella prassi, veniva coperto con strumenti atipici e non sempre solidi in fase dibattimentale.

Che cosa devono fare, in concreto, i provider

Per i responsabili della sicurezza e i legal compliance manager delle aziende che offrono servizi in UE, il calendario si è fatto serrato. Tre sono i fronti da presidiare entro l’estate del 2026.

Il primo è organizzativo: individuare o costituire uno stabilimento designato nell’Unione (se il gruppo vi ha sede) oppure nominare un rappresentante legale. La scelta non è neutra: il rappresentante andrà dotato di poteri e risorse effettive per rispondere a ordini con scadenze di dieci giorni, o di otto ore in emergenza. Significa processi interni, playbook di risposta, SLA con il resto del gruppo, procedure di escalation.

Il secondo è tecnologico: collegarsi al sistema informatico decentrato, istituito dall’articolo 19 del regolamento, attraverso cui transiteranno in forma elettronica tutti gli ordini, i moduli EPOC ed EPOC-PR e i dati richiesti. Gli atti di esecuzione che ne definiscono le specifiche tecniche sono previsti dall’articolo 25, e l’obbligo di utilizzare il sistema decorre un anno dopo la loro adozione. I costi di integrazione gravano sui prestatori; le opportunità di rimborso previste dall’articolo 14 riguardano le spese di esecuzione, non quelle infrastrutturali, e sono subordinate alla disciplina interna dello Stato di emissione. La tempistica di otto ore per le emergenze richiede processi automatizzati di ricerca, estrazione e trasmissione dei dati, non improvvisazioni.

Il terzo è di data governance: mappare con precisione le categorie di dati detenute (abbonati, identificativi, traffico, contenuto) secondo la tassonomia dell’articolo 3 del regolamento, e garantire la capacità di rispondere selettivamente. Un’acquisizione indifferenziata esporrebbe l’azienda sia al rischio di contestazioni in sede di riesame europeo sia a profili GDPR tutt’altro che banali.

Il calendario che conta

Per orientarsi, sintetizziamo le date chiave:

  • 15 gennaio 2026: pubblicazione in Gazzetta Ufficiale dei d.lgs. 215 e 216/2025;
  • 30 gennaio 2026: entrata in vigore del d.lgs. 215/2025;
  • 18 febbraio 2026: scadenza per il recepimento della direttiva 2023/1544 da parte degli Stati membri e per la notifica alla Commissione delle disposizioni sanzionatorie;
  • 7 aprile 2026: pubblicazione della Relazione n. 25/2026 dell’Ufficio del Massimario della Corte di Cassazione;
  • 18 agosto 2026: termine entro cui i prestatori di servizi che offrono servizi nell’Unione devono aver designato lo stabilimento o nominato il rappresentante legale, e contestuale data di applicazione del regolamento 2023/1543. Per i nuovi prestatori che iniziano a offrire servizi dopo il 18 febbraio 2026, il termine è di sei mesi dall’avvio dell’attività.

In mezzo, un secondo decreto legislativo, complementare al 215, è atteso per completare il quadro. L’Italia, a quel punto, sarà uno dei ventisette nodi attivi di un sistema di cooperazione giudiziaria che, per la prima volta, azzera le distanze fra autorità inquirente e prestatore, ovunque questo sia stabilito in Europa. Un’infrastruttura giuridica che, se funzionerà come progettata, ridefinirà in profondità il modo in cui si costruisce la prova digitale nel procedimento penale. Se non funzionerà, resterà comunque il cambiamento più ambizioso tentato dall’Unione in materia di cooperazione penale dall’ordine di indagine europeo in poi.

Condividi sui Social Network:

https://www.ictsecuritymagazine.com/cyber-crime/e-evidence-italia-d-lgs-215-216/




Gestire il rischio cyber oggi: il modello Cyber Resilience Lifecycle di ReeVo

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

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

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

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

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

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

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

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

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

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

Condividi sui Social Network:

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




AI Act, l’Unione Europea bandisce le “nudify apps”

L’Europa annuncia un passo in avanti sul contrasto al Deepfake Porn: il 26 marzo 2026 il Parlamento UE ha varato una misura che intende colpire le cosiddette nudify apps, nate per generare o alterare immagini di persone reali tramite l’intelligenza artificiale e creare contenuti espliciti senza il loro consenso.

Nello specifico si tratta di un emendamento all’AI Act, parte del più generale processo di revisione noto come Digital Omnibus e avviato nel novembre 2025 allo scopo dichiarato di semplificare e aggiornare la normativa comunitaria alla luce del rapido sviluppo delle tecnologie digitali.

Come già avvenuto in altri campi, l’intelligenza artificiale ha avuto un impatto dirompente anche sulla diffusione di contenuti sessualmente espliciti. Oltre a trasformare l’industria legale dell’intrattenimento per adulti, l’estrema accessibilità degli strumenti che usano l’AI per produrre materiale pornografico a partire da immagini o video di persone inconsapevoli (inclusi minorenni) sta abilitando forme di abuso sempre più pervasive.

Deepfake Porn: un fenomeno in crescita allarmante

Il termine deepfake può indicare ogni tipologia di contenuto audiovisivo digitale creato e/o alterato mediante AI.

Sebbene si tratti di un’attività teoricamente lecita, è noto già da anni come ciò possa prestarsi a numerosi utilizzi illeciti.

Una specifica tipologia è infatti rappresentata dal deepnude, che parte dall’immagine di una persona reale per generarne altre di natura esplicita.
La stragrande maggioranza di tali contenuti rappresenta corpi femminili in scenari sessuali: secondo le Nazioni Unite, “deepfake pornography made up 98% of all deepfake videos online and 99% depicted women, according to a 2023 report”.

Il medesimo report registra una crescita superiore al 500% dei video deepfake circolanti a partire dal 2019, evidenziando quanto gli strumenti necessari a crearli siano ormai “widely available, usually free, and require very little technical expertise”.

Come in altri casi di Technology Facilitated Gender-based Violence (TFGBV) – in particolare nella categoria dell’Image Based Sexual Abuse (IBSA) – una volta pubblicati i contenuti sono quasi impossibili da rimuovere; “once posted, AI generated content can be replicated endlessly, saved to private devices and shared across platforms, making it nearly impossible to fully remove”.

Le persone coinvolte rischiano di soffrire gravi effetti psicologici ed emotivi, nonché professionali e reputazionali, in conseguenza dell’essere state associate a materiali pornografici diffusi online.

Cosa sono le nudify apps?

Nell’ambito del Deepfake Porn, si è sviluppato un fiorente mercato dedicato ad app e software che in poche mosse consentono di “denudare” una persona partendo da un’immagine in cui appaia parzialmente o completamente vestita.

Sebbene tale possibilità esistesse già da diversi anni, la massiccia diffusione di strumenti semplici e gratuiti (o comunque a prezzi molto accessibili) ha trasformato una realtà marginale in un fenomeno dilagante: secondo una ricerca condotta dal Centre for Countering Digital Hate, il solo GROK avrebbe prodotto – in un periodo di osservazione di appena 10 giorni – ben 3 milioni di immagini sessualmente esplicite e 23.000 contenuti relativi ad abusi su minori.

Più di recente, la Internet Watch Foundation (IWF) ha pubblicato i risultati di un’indagine che conferma come nel 2025 siano stati diffusi migliaia di “AI-generated images and videos of realistic child sexual abuse”.

Anche in questo caso, è evidente come la circolazione di immagini a carattere intimo che rappresentano minori reali e riconoscibili rischi di avere effetti devastanti sulla loro sicurezza presente e futura.

Le normative sul Deepfake Porn nel mondo

Mentre la creazione e la diffusione di immagini ritraenti minori sono severamente proibite ovunque, i contenuti che mostrano soggetti adulti sono rimasti a lungo in una “zona grigia” sul piano legale.

Soltanto negli ultimi anni, anche in seguito al clamore mediatico creatosi intorno ad alcune “vittime eccellenti” – come la cantante Taylor Swift – molti Paesi hanno iniziato ad adottare normative per contenere questo fenomeno e sanzionare i responsabili.

Vediamone le principali.

Regno Unito: già dal 2023, l’Online Safety Act proibisce la diffusione di immagini esplicite manipolate digitalmente, senza tuttavia rivolgersi in modo specifico alla creazione di contenuti mediante AI; per colmare tale lacuna, nel 2025 il Data (Use and Access) Act ha previsto come reato “to create or request the creation of non-consensual intimate images”.

Corea del Sud: alla luce di oltre 800 casi in un solo anno, nel 2024 il governo di Seoul ha adottato una delle normative più rigorose al mondo in tema di deepfake, vietando i contenuti espliciti generati tramite AI e prevedendo fino a 3 anni di carcere per chi detenga o visioni tali contenuti, nonché fino a 7 per chi li generi a fini di distribuzione.

Singapore: nello stesso anno sono state introdotte pene severe per i responsabili di truffe o estorsioni conseguenti alla creazione di deepfake a natura sessuale, sulla scorta di numerosi scandali verificatisi nei mesi precedenti.

Stati Uniti: il “Take It Down Act” (Tools to Address Known Exploitation by Immobilizing Technological Deepfakes on Websites and Networks) del 2025 criminalizza la pubblicazione non consensuale di immagini intime, citando esplicitamente i deepfakes; entro il 19 maggio 2026, ogni piattaforma che ospiti contenuti creati dagli utenti deve dotarsi di sistemi per la segnalazione e rimozione di materiali espliciti creati senza il consenso delle persone ritratte.

Messico: sempre nel 2025, il Congresso ha approvato una legge che prevede fino a 5 anni di carcere (e significative sanzioni pecuniarie) per chiunque crei o diffonda senza consenso materiali a contenuto sessuale manipolati tramite l’AI, includendo espressamente ogni applicazione, programma o tecnologia capace di alterare o modificare fotografie, file audio, video o qualsiasi altro materiale grafico.

Brasile: a marzo 2026, il codice penale è stato aggiornato per includere nuove sanzioni nei confronti di chi alteri l’immagine o la voce di una persona mediante l’uso di AI o altre tecnologie; per i siti o piattaforme che consentano la pubblicazione di materiali espliciti così prodotti, sono previste multe fino al 2% del fatturato annuale.

Molti altri Paesi – come l’Australia o il Canada – hanno annunciato di star elaborando simili normative, confermando la percezione globale del Deepfake porn come minaccia concreta ed estremamente attuale.

Anche la nuova UN Cybercrime Convention prevede per gli Stati contraenti l’obbligo di criminalizzare la condivisione di Non-Consensual Intimate Imagery (NCII), includendo le immagini di persone reali create o modificate dall’intelligenza artificiale; e l’Unione Europea aveva già provveduto ad adottare alcune misure di contrasto.

Il divieto di deepnudes: direttiva europea e legge italiana

In effetti la Direttiva (UE) 2024/1385, adottata nel 2024 e dedicata al contrasto della violenza contro le donne, proibisce “creating and distributing pornographic material digitally altered to make it appear that a person is involved without their consent”.

Un’ipotesi che – pur non menzionando esplicitamente gli strumenti basati sull’AI – potrebbe applicarsi anche ai contenuti generati dalle nudify apps.

Tuttavia, come noto, le direttive non sono immediatamente applicabili negli Stati membri; al contrario richiedono passaggi applicativi che non tutti i componenti dell’Unione hanno ancora compiuto, portando a una disparità di tutele tra i vari Paesi UE.

Inoltre la direttiva subordina l’illiceità dei deepfake alla circostanza che siano idonei a provocare seri danni (“likely to cause serious harm”), lasciando un ampio margine interpretativo circa la valutazione di tali requisiti.

Analogamente, in Italia l’art. 612 quater c.p. (introdotto dalla legge n. 132/2025) punisce con la reclusione fino a cinque anni “chiunque cagiona un danno ingiusto ad una persona, cedendo, pubblicando o altrimenti diffondendo, senza il suo consenso, immagini, video o voci falsificati o alterati mediante l’impiego di sistemi di intelligenza artificiale”.

La scelta di mutuare dalla direttiva l’elemento del “danno ingiusto” rischia così di limitare l’applicabilità della norma italiana, lasciando alla vittima l’onere della prova in merito agli effetti dell’abuso.

Ulteriori profili di rischio dei Deepnudes

Oltre alle citate conseguenze psicologiche e reputazionali, un deepfake diffuso sul web può esporre la persona ritratta ad attenzioni indesiderate (e potenzialmente pericolose), mettendo a repentaglio la sua sicurezza fisica ed emotiva.

Ma i deepnude hanno già dimostrato di comportare ulteriori profili di rischio: è il caso delle finte app che promettono di creare gratuitamente materiali erotici, in realtà utilizzate da gruppi cyber criminali per indurre gli utenti a scaricare contenuti malevoli con cui sottrarre le loro credenziali per poi condurre attacchi informatici mirati.

I deepfake possono altresì potenziare i casi di sextortion, dove immagini o video intimi generalmente ottenuti con l’inganno sono utilizzati per ricattare qualcuno al fine di estorcere denaro (di solito in criptovalute) o di farsi inviare ulteriori immagini private, minacciando in caso contrario di pubblicarli online.

E anche laddove i materiali in questione vengano creati o modificati artificialmente, non è difficile immaginare come una persona potrebbe finire per cedere al ricatto sull’onda del timore per la propria reputazione personale e professionale.

Conclusioni: contro il Deepfake abuse serve più consapevolezza

Alla luce dei molteplici profili di rischio evidenziati, nonché della rapidità con cui si evolvono le tecnologie, sembra utopico ipotizzare che il solo strumento normativo – tanto a livello nazionale quanto sovranazionale – possa risultare sufficiente ad arginare il fenomeno deepfake.

Risultano senz’altro utili i tentativi di coinvolgere le aziende nella prevenzione degli abusi basati sull’AI; ma difficilmente i colossi tech rinunceranno ai relativi lauti guadagni, al più limitandosi a prevedere meccanismi di age verification e segnalazione/rimozione dei contenuti illegali che tuttavia, proprio come i rimedi giurisdizionali, intervengono quando il danno si è già verificato.

Allo stesso modo, le possibili contromisure tecniche – come il watermarking delle immagini – rischiano di rivelarsi presto superate dall’evoluzione degli strumenti digitali.

Fondamentale, allora, è impegnarsi nel costruire una cultura del consenso a partire dalle giovani generazioni, creando consapevolezza circa i pericoli e le gravi conseguenze potenzialmente derivanti dalla creazione e diffusione di materiali non consensuali online, affinché lo sviluppo delle tecnologie non divenga sempre più uno strumento per ledere la dignità delle persone.

Profilo Autore

Con una laurea in Giurisprudenza conseguita presso l’Università degli Studi Roma Tre – seguita da un dottorato di ricerca in Economia e Diritto delle Relazioni Internazionali – Irene Salvi è docente in diversi Master e Corsi formativi, nonché giornalista pubblicista e ricercatrice indipendente sul tema dell’intersezione tra diritti individuali, libertà civili e tecnologie digitali.

Dal 2020 è consigliera di una rete internazionale attiva nel contrasto alla violenza di genere; nel 2025 ha partecipato al PRIN-PNRR “Gendering Internet. Violence, Resilience and Empowerment in digital spaces” (GIVRE), condotto dalla Sapienza insieme a Università di Padova e Link University, primo progetto di ricerca sul fenomeno della violenza digitale di genere in Italia.

Condividi sui Social Network:

https://www.ictsecuritymagazine.com/articoli/ai-act-nudify-apps/




Iran nel cyberspazio: operazioni ibride tra Medio Oriente, infrastrutture OT e Cloud Microsoft 365

L’escalation cyber iraniana del primo trimestre 2026 rivela una strategia a doppio vettore: la compromissione degli ambienti cloud delle organizzazioni israeliane e il sabotaggio di sistemi industriali critici negli Stati Uniti. Un modello operativo che ridefinisce il confine tra guerra cinetica e conflitto digitale.

Quello che emerge dai report pubblicati tra la fine di marzo e i primi giorni di aprile 2026 non è un episodio isolato, ma un pattern operativo strutturato. Check Point Research ha tracciato una campagna di password spraying contro ambienti Microsoft 365 in Medio Oriente, condotta da un threat actor riconducibile all’Iran in tre ondate distinte il 3, il 13 e il 23 marzo 2026, colpendo oltre 300 organizzazioni in Israele e più di 25 negli Emirati Arabi Uniti.

Parallelamente, il joint advisory AA26-097A del 7 aprile 2026, firmato da CISA, FBI, NSA, EPA, Dipartimento dell’Energia e US Cyber Command, ha confermato che attori APT affiliati all’Iran stanno attivamente compromettendo PLC Rockwell Automation/Allen-Bradley esposti su internet nei settori Energy, Water and Wastewater Systems e Government Services negli Stati Uniti, con casi documentati di disruption operativa e perdite finanziarie.

Letti separatamente, i due filoni potrebbero sembrare incidenti scollegati. Analizzati insieme, configurano una strategia ibrida di rara coerenza tattica, coerente con quanto già documentato nei 30 giorni di cyber warfare iraniano seguito al 28 febbraio 2026.

Il vettore cloud: 300 organizzazioni israeliane nel mirino

Secondo l’analisi di Check Point Research, la campagna ha colpito oltre 300 organizzazioni israeliane e più di 25 negli EAU, con attività simile osservata contro target in USA, Europa, Regno Unito e Arabia Saudita. Tra i gruppi iraniani noti per questa tecnica figurano Peach Sandstorm e Gray Sandstorm, entrambi con un’ampia storia documentata di password spraying contro ambienti Microsoft 365.

Sul piano dell’attribuzione è importante mantenere la precisione: Microsoft ha valutato che Peach Sandstorm (APT33) opera per conto dell’Islamic Revolutionary Guard Corps (IRGC). Gray Sandstorm (già DEV-0343) è invece descritto come un cluster che agisce verosimilmente a supporto degli interessi iraniani, senza che nei documenti primari pubblici sia stata confermata un’affiliazione esplicita a una specifica agenzia governativa, distinzione rilevante per chi svolge threat intelligence operativa.

Il settore più colpito in Israele è quello municipale, seguito dalla tecnologia (63 tentativi), dalla logistica e trasporti (32), dalla sanità (28) e dal manifatturiero (28). Check Point valuta con moderata confidenza che il targeting delle municipalità israeliane sia correlato alle città colpite da attacchi missilistici iraniani nel corso di marzo, suggerendo che la campagna sia stata progettata per supportare la valutazione dei danni da bombardamento e le operazioni cinetiche in corso.

Sul piano tecnico, il modus operandi è caratterizzato da una sofisticazione deliberatamente contenuta. Durante la fase di scansione, l’attore ha usato nodi Tor exit con rotazione frequente, inviando richieste con un user agent costruito per simulare Internet Explorer 10 su Windows 7. Una volta ottenute credenziali valide, gli attaccanti si autenticano tramite range IP VPN commerciali di Windscribe (185.191.204.X) e NordVPN (169.150.227.X) geolocalizzati in Israele, aggirando le restrizioni geografiche e riducendo il rischio di alert legati ad accessi stranieri.

Il vettore OT: PLC industriali e sistemi SCADA

Secondo l’advisory CISA AA26-097A, almeno da marzo 2026 un gruppo APT affiliato all’Iran ha disrupted il funzionamento di PLC distribuiti in più settori critici statunitensi, tra cui Government Services and Facilities, Water and Wastewater Systems ed Energy. Alcune vittime hanno subito interruzioni operative e perdite finanziarie. Gli attori hanno usato indirizzi IP esteri per accedere a PLC Rockwell Automation/Allen-Bradley esposti su internet, sfruttando software di configurazione legittimi come Studio 5000 Logix Designer per creare connessioni accettate ai dispositivi target, tra cui CompactLogix e Micro850.

Il traffico malevolo è stato osservato sulle porte 44818, 2222, 102, 22 e 502, associate a protocolli OT di diversi vendor, con implicazioni che si estendono potenzialmente oltre i dispositivi Rockwell, inclusi i sistemi Siemens S7 diffusi in Europa e Asia.

Il metodo di accesso non richiede vulnerabilità zero-day: la debolezza sfruttata è di natura architetturale. Come analizzato da Picus Security in relazione all’advisory, i PLC erano esposti su internet senza adeguata segmentazione di rete, controlli di autenticazione o hardening. Le tre azioni difensive più efficaci non richiedono budget: rimuovere le interfacce ICS da internet, cambiare le credenziali di default e bloccare le porte dei protocolli industriali al perimetro.

In un precedente analogo, il gruppo CyberAv3ngers, affiliato all’IRGC Cyber Electronic Command, aveva già compromesso PLC Unitronics nei sistemi idrici statunitensi nel novembre 2023. La campagna attuale rappresenta un’evoluzione di quel playbook su scala maggiore, con dispositivi più diffusi nelle infrastrutture critiche nordamericane. Rockwell Automation aveva già pubblicato il proprio security advisory SD1771 il 20 marzo 2026, esortando i clienti a disconnettere i controller da internet: una linea guida che si allinea quasi perfettamente al messaggio del joint advisory CISA, suggerendo che la campagna fosse già nota al settore privato prima della divulgazione pubblica.

Il ransomware come arma ibrida

Un terzo livello di questa strategia riguarda l’integrazione del ransomware nelle operazioni statali iraniane. Nel marzo 2026, Halcyon ha rivelato che l’amministratore del ransomware Sicarii ha esortato gli operatori filo-iraniani a usare il Baqiyat 313 Locker (BQTlock), attivo con motivazioni pro-palestinesi contro EAU, USA e Israele dal luglio 2025. Secondo Check Point, “le campagne ransomware stanno sfumando il confine tra estorsione criminale e sabotaggio sponsorizzato dallo Stato.”

A fine febbraio 2026, un’organizzazione sanitaria statunitense è stata colpita da Pay2Key, gruppo ransomware iraniano con legami governativi riconducibile al cluster Fox Kitten (noto anche come Lemon Sandstorm, PARISITE, Pioneer Kitten e UNC757). La variante impiegata presenta capacità di evasione e anti-forensics migliorate rispetto alle campagne del luglio 2025. In questo caso non è stata rilevata esfiltrazione di dati, una deviazione dal classico schema del double extortion che suggerisce come l’obiettivo prioritario fosse la disruption operativa più che il guadagno economico.

La dimensione geopolitica: il cyberspazio come teatro del conflitto

Questa campagna non può essere letta al di fuori del suo contesto. Secondo Recorded Future Insikt Group, il targeting della campagna cloud è correlato alle città colpite da missili iraniani, con le operazioni cyber progettate per supportare la valutazione dei danni da bombardamento e le attività cinetiche in corso. Come abbiamo già documentato nell’analisi di Operation Epic Fury e Roaring Lion, il dominio cyber è diventato il secondo fronte attivo del conflitto sin dal 28 febbraio 2026.

Il dato europeo non è trascurabile. Sia la campagna cloud sia il profilo di targeting OT dell’advisory CISA indicano una superficie d’attacco che supera i confini del Medio Oriente. Il targeting di porte associate a protocolli Siemens, Rockwell e Modbus indica che la minaccia è potenzialmente estesa a qualsiasi sistema OT esposto su internet, inclusi quelli capillarmente diffusi nelle infrastrutture critiche europee.

Il quadro macro è confermato dal World Economic Forum: secondo il Global Cybersecurity Outlook 2026, il 64% delle organizzazioni globali tiene oggi conto degli attacchi cyber motivati geopoliticamente nelle proprie strategie di mitigazione del rischio, mentre il 91% delle organizzazioni di maggiori dimensioni ha modificato la propria strategia di cybersecurity in risposta alla volatilità geopolitica.

Implicazioni per le organizzazioni europee e italiane

Il primo livello di rischio riguarda le aziende che operano in settori esposti a tensioni geopolitiche regionali: energia, difesa, trasporti, finanza. Il pattern di targeting iraniano segue logiche di intelligence strategica, non solo di opportunismo, e le organizzazioni europee che hanno rapporti commerciali o tecnologici con i paesi nel mirino possono diventare vettori secondari di accesso.

Il secondo livello riguarda le infrastrutture OT. In Italia, come negli altri paesi europei, la superficie di attacco sui sistemi industriali rimane ampia. La resilienza IT/OT nell’ambito NIS2 impone requisiti di sicurezza più stringenti per i settori critici, ma il percorso di implementazione è ancora in corso per molte organizzazioni. Il Decreto Legislativo 138 del settembre 2024 ha recepito la direttiva in Italia: la semplicità del vettore OT documentato nell’advisory CISA, che non richiede zero-day ma solo PLC accessibili da internet, dovrebbe essere un campanello d’allarme immediato per qualsiasi responsabile della sicurezza operativa.

Il terzo livello riguarda l’identità cloud. Un attacco di password spraying non necessita di malware avanzato per causare danni: una sola password debole può garantire a un avversario un accesso duraturo a un workspace cloud che il personale utilizza quotidianamente. Il monitoraggio delle identità è diventato importante quanto il monitoraggio degli endpoint per le organizzazioni che dipendono da Microsoft 365.

Le contromisure prioritarie

Per gli ambienti cloud Microsoft 365, le misure raccomandate da Check Point Research includono: monitorare i log di accesso per identificare pattern di password spraying con molteplici tentativi falliti da un’unica sorgente; applicare conditional access con geo-fencing e blocco dei nodi Tor; abilitare l’MFA per tutti gli utenti con controlli più stringenti per i ruoli privilegiati; conservare i log di audit per le investigazioni post-compromissione. Il blocco dei range IP associati a Windscribe e NordVPN già noti in questa campagna rappresenta una misura di contenimento efficace nel breve termine.

Per gli ambienti OT, CISA raccomanda di rimuovere immediatamente i PLC dall’esposizione diretta su internet collocandoli dietro gateway sicuri e firewall; per i dispositivi Rockwell, impostare lo switch fisico del controller in modalità run; verificare nei log la presenza di traffico sospetto sulle porte OT, in particolare proveniente da hosting provider esteri; abilitare SSH Dropbear come indicatore di compromissione, dal momento che è stato impiegato dagli attaccanti per mantenere l’accesso remoto ai sistemi compromessi.

Conclusioni: la guerra ibrida è già presente

La campagna iraniana del primo trimestre 2026 è un caso di studio per l’intero settore. Il suo valore analitico non sta nella sofisticazione tecnica, ma nella coordinazione tra vettori multipli e simultanei (cloud M365, PLC/SCADA, ransomware), nella sua integrazione con operazioni cinetiche in corso e nella capacità di proiettare pressione geopolitica ben oltre il teatro di conflitto originario.

Per i professionisti della sicurezza, questo significa che il threat modeling non può più prescindere dalla dimensione geopolitica. Comprendere chi attacca, perché e in quale contesto internazionale è diventato parte integrante della valutazione del rischio, tanto quanto l’analisi delle vulnerabilità tecniche. Il confine tra IT security e national security non è mai stato così sottile.

Condividi sui Social Network:

https://www.ictsecuritymagazine.com/notizie/iran-cyberspazio-war/




Supply Chain Attack nordcoreano, Contagious Interview prende di mira gli sviluppatori: 1.700 pacchetti malevoli in cinque ecosistemi open source

Un’operazione di supply chain attack attribuita a gruppi hacker nordcoreani ha raggiunto una scala senza precedenti: oltre 1.700 pacchetti malevoli distribuiti contemporaneamente su cinque dei principali registri open source globali, progettati per colpire sviluppatori software in tutto il mondo attraverso strumenti di uso quotidiano. La campagna, denominata Contagious Interview e monitorata dai ricercatori di Socket Security dal 2024, ha compiuto il 7 aprile 2026 un salto qualitativo significativo: per la prima volta, la stessa infrastruttura di staging e gli stessi pattern di distribuzione sono stati replicati in parallelo su npm, PyPI, Go Modules, crates.io e Packagist.

Supply Chain Attack nordcoreano: una fabbrica di pacchetti malevoli a scala industriale

Socket ha documentato che il cluster individuato in questa tornata comprende dodici pacchetti malevoli confermati e due pacchetti “dormienti”, caricati sotto alias GitHub tra cui golangorg, aokisasakidev e aokisasakidev1, con una rete di supporto operante sotto i profili maxcointech1010 e maxcointech0000.

L’elenco completo dei pacchetti identificati per ecosistema, secondo il report del ricercatore Kirill Boychenko di Socket, è il seguente: su npm i pacchetti dev-log-core, logger-base, logkitx, pino-debugger, debug-fmt e debug-glitz; su PyPI i pacchetti logutilkit, apachelicense, fluxhttp e license-utils-kit; nel registro Go i moduli github.com/golangorg/formstash e github.com/aokisasakidev/mit-license-pkg; nel registro Rust il pacchetto logtrace; nel registro PHP Packagist il pacchetto golangorg/logkit.

La scelta dei nomi non è casuale: i pacchetti erano progettati per impersonare strumenti di sviluppo legittimi come debug, debug-logfmt, pino-debug, baraka, license, http, libprettylogger e openlss/func-log, funzionando silenziosamente come malware loader. Questo schema è perfettamente coerente con quanto già documentato da ICT Security Magazine nell’analisi sulla supply chain software e i 454.000 pacchetti malevoli del 2025: la fiducia implicita nei registri pubblici è diventata l’arma più efficiente a disposizione degli attaccanti statali.

Il meccanismo di infezione: loader a due stadi invisibili al momento dell’installazione

Il malware nascosto è progettato in modo da non eseguirsi durante l’installazione del pacchetto, rendendo più difficile il rilevamento da parte degli strumenti di sicurezza tradizionali.

I loader recuperano un downloadUrl dall’infrastruttura controllata dagli attaccanti (in particolare dall’endpoint apachelicense[.]vercel[.]app), riscrivono i link di condivisione di Google Drive in formato di download diretto, scaricano archivi ZIP come ecw_update.zip e consegnano payload di secondo stadio specifici per piattaforma. Questi payload si rivelano essere malware con capacità di infostealer e remote access trojan (RAT), in grado di sottrarre credenziali, portafogli di criptovalute e garantire accesso persistente ai sistemi compromessi.

Il coordinamento cross-ecosistema è l’elemento più significativo: lo stesso cluster ha pubblicato i pacchetti su cinque registri diversi riutilizzando la stessa logica di staging, la stessa infrastruttura e gli stessi pattern di riuso delle persona. Questo indica che gli attaccanti possono continuare a portare lo stesso design di loader in nuovi registri con sole modifiche minori al codice.

Chi c’è dietro Contagious Interview: UNC1069, BlueNoroff e il link con Axios

L’attacco è attribuito a un threat actor a motivazione finanziaria noto come UNC1069, che si sovrappone ai gruppi BlueNoroff, Sapphire Sleet e Stardust Chollima. La Security Alliance (SEAL) ha dichiarato di aver bloccato 164 domini collegati a UNC1069 che impersonavano servizi come Microsoft Teams e Zoom tra il 6 febbraio e il 7 aprile 2026.

UNC1069 opera campagne di social engineering a bassa pressione e multi-settimana su Telegram, LinkedIn e Slack, impersonando contatti noti o brand credibili, o sfruttando accessi ad account aziendali e personali precedentemente compromessi, prima di consegnare un link fraudolento a una riunione Zoom o Microsoft Teams, utilizzato per veicolare lure di tipo ClickFix con conseguente esecuzione di malware su Windows, macOS e Linux.

La campagna si inserisce in un contesto più ampio di attacchi alla supply chain software da parte nordcoreana: tra le operazioni parallele figura anche l’avvelenamento del popolare pacchetto npm Axios per distribuire un impianto chiamato WAVESHAPER.V2, dopo aver preso il controllo dell’account npm del maintainer del pacchetto tramite una campagna di social engineering su misura.

Microsoft ha analizzato in dettaglio la campagna Contagious Interview, confermando come gli attori nordcoreani a motivazione finanziaria stiano evolvendo attivamente il loro toolset e la loro infrastruttura, usando domini che si spacciano per istituzioni finanziarie statunitensi e applicazioni di videoconferenza per il social engineering, con una chiara continuità nel comportamento e nell’intento.

Il modello “factory”: una minaccia sistematica e scalabile

Socket descrive Contagious Interview come una minaccia supply chain che adotta un modello a fabbrica, ben dotata di risorse, prolifica e sistematica, che tratta npm, PyPI e VS Code come canali di accesso iniziale rinnovabili verso ambienti di sviluppo e, sulla base delle indagini attuali, estende lo stesso playbook a Go Modules, crates.io e Packagist. Il totale di oltre 1.700 pacchetti malevoli tracciati è riferito all’attività complessiva della campagna a partire dal gennaio 2025.

Per comprendere la portata strutturale del problema, è utile fare riferimento all’analisi già pubblicata su ICT Security Magazine sull’avvelenamento di LiteLLM e la supply chain Python per sviluppatori AI, che descrive lo stesso schema operativo replicato da TeamPCP su cinque ecosistemi in meno di un mese. Contagious Interview applica la medesima logica su scala ancora più ampia e con risorse statali.

Le implicazioni per le organizzazioni: NIS2 e la responsabilità sulle dipendenze

La campagna Contagious Interview ha conseguenze dirette sul piano della compliance normativa. Come approfondito nell’articolo di ICT Security Magazine sugli ecosistemi digitali sotto attacco, NIS2 e gli SBOM, la NIS2 impone alle organizzazioni in scope di valutare la postura di sicurezza dei fornitori diretti e dei service provider, inclusi i componenti open source integrati nelle pipeline di sviluppo. Un pacchetto npm installato da un developer in un ambiente CI/CD è, a tutti gli effetti, un componente della supply chain soggetto a questa valutazione.

Il Cyber Resilience Act (CRA) europeo, in via di implementazione, introdurrà obblighi specifici per i produttori di software che incorporano componenti open source, rendendo la tracciabilità delle dipendenze tramite Software Bill of Materials (SBOM) non più una raccomandazione ma un requisito operativo verificabile.

Raccomandazioni operative per i team di sviluppo

Socket, che ha segnalato tutti i pacchetti malevoli identificati ai registri interessati e presentato richieste di rimozione per gli account GitHub associati, ha ottenuto la rimozione di logtrace da crates.io (con advisory tracciato come RUSTSEC-2026-0081), il blocco dei moduli Go identificati da parte del Go Security team, e la rimozione dei pacchetti aokisasakidev da npm.

Le raccomandazioni pratiche sono le seguenti: trattare come ad alto rischio i pacchetti di utilità che contattano infrastrutture remote, recuperano un downloadUrl, riscrivono link di cloud storage, scaricano archivi, decodificano contenuti remoti o avviano interpreti da funzioni helper; bloccare le versioni delle dipendenze dirette e transitive, fissando hash specifici nelle pipeline CI/CD; esaminare con attenzione i pacchetti appena pubblicati o con pochi download prima dell’adozione; eseguire i pacchetti sospetti in ambienti sandbox prima che raggiungano workstation di sviluppatori o sistemi CI; verificare i maintainer account tramite autenticazione a due fattori e monitorare i trasferimenti di ownership sui pacchetti critici.

Al momento della pubblicazione del report di Socket, alcuni pacchetti erano già stati rimossi dai registri, ma altri erano ancora attivi. Questo sottolinea la necessità di non affidarsi esclusivamente alle misure di sicurezza dei registry, ma di implementare controlli propri a livello di pipeline.

Condividi sui Social Network:

https://www.ictsecuritymagazine.com/notizie/supply-chain-attack-nordcorea/




APT28 e la campagna FrostArmada: come il GRU russo ruba credenziali Microsoft senza installare malware

Il gruppo di spionaggio russo APT28, noto anche come Fancy Bear, Forest Blizzard e Storm-2754 e riconducibile all’85° Centro Principale dei Servizi Speciali (GTsSS), Unità militare 26165 del GRU, ha condotto una campagna di cyber-spionaggio su scala globale compromettendo migliaia di router domestici e per piccoli uffici. L’operazione, denominata FrostArmada dai ricercatori di Black Lotus Labs (Lumen Technologies), ha permesso di sottrarre in modo silenzioso credenziali di accesso e token OAuth di Microsoft 365, senza che le vittime ricevessero alcun segnale di allarme tradizionale.

La campagna è stata resa pubblica il 7 aprile 2026 contestualmente all’advisory del National Cyber Security Centre (NCSC) del Regno Unito, nell’ambito di un’operazione internazionale coordinata tra autorità di law enforcement e aziende private.

Il meccanismo: DNS hijacking senza malware

La campagna su larga scala è stata denominata FrostArmada da Black Lotus Labs, con Microsoft che la descrive come uno sforzo per sfruttare dispositivi SOHO vulnerabili allo scopo di dirottare il traffico DNS e abilitare la raccolta passiva di dati di rete.

Sin dal 2024 e fino al 2026, APT28 ha configurato Virtual Private Server (VPS) per operare come server DNS malevoli. Questi VPS ricevevano volumi elevati di richieste DNS originate da router precedentemente compromessi tramite vulnerabilità note. Le impostazioni DHCP/DNS dei dispositivi venivano sovrascritte in modo da includere indirizzi IP controllati dall’attaccante, propagando le nuove configurazioni ai dispositivi della rete interna.

Quando gli utenti richiedevano i domini target, il traffico veniva reindirizzato verso un nodo adversary-in-the-middle (AitM), dove le credenziali venivano raccolte ed esfiltrate. L’unico segnale visibile per l’utente finale sarebbe stato un avviso per certificato TLS non valido.

I target del gruppo APT28 e la portata dell’operazione FrostArmada

L’attività risulta iniziata in forma limitata già a partire da maggio 2025, con una fase di compromissione su larga scala avviata da agosto. Al picco, nel dicembre 2025, oltre 18.000 indirizzi IP unici provenienti da almeno 120 paesi comunicavano con l’infrastruttura di APT28. I target primari includevano agenzie governative, ministeri degli affari esteri, forze dell’ordine e provider email e cloud di terze parti distribuiti in Africa settentrionale, America centrale, Sud-Est asiatico ed Europa.

Microsoft ha rilevato oltre 200 organizzazioni e 5.000 dispositivi consumer impattati dall’infrastruttura DNS malevola di Forest Blizzard, precisando che la telemetria non ha indicato compromissioni di asset o servizi di proprietà Microsoft.

Le operazioni di DNS hijacking sono state valutate come opportunistiche: APT28 ha preso di mira un ampio bacino di vittime, filtrando progressivamente i risultati per individuare utenti di potenziale interesse sotto il profilo dell’intelligence.

La vulnerabilità sfruttata

Uno dei modelli router sfruttati da APT28 è il TP-Link WR841N, presumibilmente attraverso la CVE-2023-50224, una vulnerabilità che consente a un attaccante non autenticato di ottenere credenziali memorizzate tramite richieste HTTP GET appositamente predisposte. Una volta ottenute le credenziali del router, l’attore inviava una seconda richiesta HTTP GET per modificare le impostazioni DNS DHCP del dispositivo, impostando il server DNS primario su un indirizzo IP malevolo e mantenendo il server secondario originale come fallback.

L’operazione di smantellamento

L’FBI ha condotto un’operazione tecnica autorizzata dall’autorità giudiziaria per mettere in sicurezza i router compromessi, rimuovendo i resolver di APT28 tramite DNS reset e ripristinando la connessione a resolver legittimi forniti dagli ISP. I comandi inviati ai router hanno anche permesso all’FBI di raccogliere prove sull’attività del gruppo. Per garantire che l’operazione non alterasse le funzionalità ordinarie dei dispositivi né raccogliesse dati degli utenti, il governo ha condotto test estensivi su firmware e hardware dei router TP-Link interessati.

Il DoJ ha precisato che gli utenti possono rimuovere eventuali modifiche residue eseguendo un ripristino alle impostazioni di fabbrica.

Il contesto geopolitico

APT28 è lo stesso gruppo responsabile della violazione del Comitato Nazionale Democratico statunitense nel 2016. L’NCSC ha precedentemente attribuito ad APT28 gli attacchi informatici al Bundestag tedesco nel 2015, che hanno incluso furto di dati e la compromissione degli account email di parlamentari e del Vice Cancelliere, nonché il tentato attacco all’Organizzazione per la Proibizione delle Armi Chimiche (OPCW) nell’aprile 2018, finalizzato a ostacolare le analisi indipendenti sulle armi chimiche impiegate dal GRU nel Regno Unito.

Le implicazioni: perché questo attacco è diverso

La campagna FrostArmada introduce un cambio di paradigma importante nella threat intelligence: il compromesso avviene a livello di infrastruttura di rete, non di endpoint. Non esiste un payload da rilevare, nessun processo anomalo da monitorare, nessun comportamento sospetto sul dispositivo dell’utente finale. L’attacco è invisibile agli strumenti EDR tradizionali e ai controlli di sicurezza perimetrali che non analizzano il traffico DNS in uscita.

Microsoft ha osservato che APT28 potrebbe sfruttare la posizione AitM acquisita per obiettivi aggiuntivi, tra cui attacchi denial of service e il deployment di malware.

Raccomandazioni operative

L’advisory NCSC fornisce indicazioni concrete per ridurre la superficie di attacco, riprese anche da Bleeping Computer con dettagli sull’operazione tecnica di smantellamento:

Sostituire i router che non ricevono più aggiornamenti di sicurezza dal produttore; mantenere il firmware sempre aggiornato all’ultima versione disponibile; non esporre le interfacce di gestione dei router su Internet; abilitare l’autenticazione a più fattori (MFA) su tutti gli account potenzialmente esposti a credential theft; monitorare le impostazioni DNS dei dispositivi di rete per rilevare modifiche non autorizzate; formare gli utenti a non ignorare gli avvisi relativi a certificati TLS non validi.

Il caso FrostArmada è un promemoria significativo del fatto che la sicurezza informatica aziendale non può prescindere dalla protezione dell’infrastruttura di rete di base, compresi i dispositivi SOHO sempre più presenti negli ambienti di lavoro ibrido e negli uffici periferici.

Condividi sui Social Network:

https://www.ictsecuritymagazine.com/notizie/apt28-frostarmada-microsoft/




LinkedIn come arma: dal phishing allo spionaggio di Stato

LinkedIn è oggi molto più di una piattaforma professionale. Per criminali comuni, gruppi APT e agenzie di intelligence straniere è diventata uno degli strumenti offensivi più versatili e difficili da contrastare nel panorama della cybersecurity. La ragione è strutturale: la piattaforma aggrega oltre un miliardo di profili autenticati, dati professionali pubblici, relazioni fiduciarie consolidate e accesso diretto a figure ad alto valore. Tutto questo avviene in un ambiente che la maggior parte delle organizzazioni non monitora con la stessa attenzione riservata alla posta elettronica.

Quello che segue è un censimento ragionato delle tecniche malevole documentate da ricercatori di sicurezza nell’ultimo anno, organizzato per livello di sofisticazione e natura dell’attore.

  1. Phishing via notifiche false: l’esca del recruiter

L’attacco più diffuso e recente è anche quello strutturalmente più insidioso nella sua semplicità. Il 31 marzo 2026, il team Cofense Phishing Defense Center ha pubblicato l’analisi di una campagna attiva in cui gli attaccanti inviano email che replicano con precisione le notifiche ufficiali di LinkedIn. Font, logo, formattazione e oggetto del messaggio sono identici agli originali. Il pretesto è una fantomatica opportunità di lavoro: un messaggio da un presunto recruiter di un’azienda reputabile, con invito urgente a rispondere.

Cliccando, l’utente non raggiunge LinkedIn, ma una pagina di login contraffatta. Il dominio impiegato nella campagna osservata era inedin[.]digital, scelto perché a una lettura rapida si confonde con il dominio legittimo. L’indirizzo email del mittente, khanieteam[.]com, è anch’esso fraudolento, attivo da pochi giorni al momento dell’analisi. I campioni osservati da Cofense erano scritti in lingua cinese e tradotti dai ricercatori.

Enrico Silverio, threat researcher al Cofense Phishing Defense Center, definisce questa campagna come «un promemoria che gli attori delle minacce continuano a evolversi in sofisticazione tecnica e persistenza, elaborando schemi altamente convincenti per sfruttare la fiducia e la curiosità umana».

L’urgenza, in questo contesto, non è un dettaglio: è la leva psicologica centrale. Silverio ricorda inoltre che gli attaccanti «pulled individuals’ home addresses, generated Google Maps screenshots, and inserted them into extortion emails to increase credibility», a conferma di quanto le campagne siano diventate personalizzate e difficili da riconoscere. Il tema dell’abuso di LinkedIn per la distribuzione di malware è approfondito nell’analisi pubblicata su ICT Security Magazine dedicata al malware veicolato tramite LinkedIn, che illustra le tecniche utilizzate dai gruppi APT per compromettere i reclutatori stessi.

  1. Phishing via commenti pubblici: la moderazione come pretesto

Una variante documentata a gennaio 2026 da Cybernews e Security Magazine sfrutta i commenti pubblici della piattaforma invece delle email. Account bot si spacciano per LinkedIn stessa, pubblicando commenti sotto i post degli utenti in cui si afferma che il profilo è stato temporaneamente ristretto per violazioni delle policy. Il messaggio invita a cliccare un link per presentare ricorso, spesso utilizzando il legittimo shortener lnkd.in di LinkedIn per mascherare la destinazione.

Chance Caldwell, Senior Director del Phishing Defense Center di Cofense, descrive questa tecnica come una «troubling evolution in social engineering tactics», in cui gli attaccanti si integrano direttamente in spazi digitali considerati affidabili e sfruttano la fiducia degli utenti mimando comunicazioni legittime. Max Gannon, Cyber Intelligence Team Manager di Cofense, sottolinea che la corretta applicazione dell’AI ha reso possibile creare a scala account che impersonano LinkedIn stesso, una soglia operativa un tempo impraticabile.

Il fattore AI è determinante: l’automazione consente di inondare le sezioni commenti a una velocità che supera ampiamente la capacità di moderazione manuale della piattaforma. LinkedIn ha confermato di essere a conoscenza della campagna, precisando che non comunica mai violazioni di policy attraverso commenti pubblici.

  1. Messaggi diretti con RAT: quando il DM diventa un vettore di intrusione

La terza tecnica è significativamente più sofisticata ed è stata documentata da ReliaQuest a gennaio 2026 in una campagna mirata a executive aziendali e amministratori IT. Il vettore non è l’email, ma il messaggio diretto su LinkedIn, a riprova che il phishing si è ormai emancipato dall’inbox.

L’attacco inizia con un DM che indirizza la vittima al download di un archivio auto-estraente WinRAR (SFX). Una volta aperto, l’archivio decomprime quattro componenti: un PDF reader legittimo open source, una DLL malevola mascherata con lo stesso nome di un file benigno usato dal PDF reader, un interprete Python portable e un file RAR utilizzato come esca per far apparire la cartella legittima. I nomi dei file sono personalizzati in base al ruolo o settore della vittima, con titoli come Upcoming_Products.pdf o Project_Execution_Plan.exe, per aumentare le probabilità che vengano aperti.

La tecnica impiegata è il DLL sideloading: il PDF reader carica automaticamente la DLL malevola al momento dell’esecuzione, eludendo l’endpoint security. Il malware installa poi una chiave Run nel registro di sistema per garantirsi persistenza a ogni avvio, esegue uno strumento di hacking open-source offuscato in Base64 direttamente in memoria (senza scrivere file su disco) e tenta ripetutamente di connettersi a un server di comando e controllo (C2). Il comportamento è compatibile con il deploy di un Remote Access Trojan per accesso persistente e furto di dati.

Come rileva The Hacker News nell’analisi della campagna, ReliaQuest sottolinea un problema strutturale: quando un account viene segnalato su LinkedIn, non è possibile vedere quali altri utenti dell’organizzazione siano stati colpiti dallo stesso messaggio. A differenza dell’email, non esiste modo di richiamare o mettere in quarantena il messaggio già inviato. Non ci sono regole modificabili né mittenti bloccabili. Si può segnalare l’account, ma probabilmente l’attaccante ha già ottenuto ciò che cercava.

  1. AiTM con redirect chain su servizi legittimi: eludere ogni filtro

La campagna più tecnicamente avanzata tra quelle di matrice criminalizzata è stata intercettata e analizzata da Push Security tra ottobre e novembre 2025. La vittima riceveva un link via DM LinkedIn relativo a una falsa opportunità di investimento: un invito a entrare nel consiglio di amministrazione di un fondo chiamato “Common Wealth”, presentato come un’iniziativa in Sud America in partnership con una fantomatica entità denominata AMCO.

Dopo aver cliccato, l’utente veniva reindirizzato tre volte (attraverso un open redirect di Google, poi a un dominio intermedio) prima di raggiungere una landing page personalizzata che imitava un portale di condivisione documenti, ospitata su firebasestorage.googleapis.com di Google. Come annunciato dalla press release ufficiale di Push Security del 30 ottobre 2025, la catena di redirect sfruttava servizi cloud legittimi (Google, Firebase, Microsoft Dynamics) per mascherare la destinazione dei link malevoli.

Gli attaccanti hanno impiegato Cloudflare Turnstile come protezione anti-bot per impedire l’analisi automatizzata delle pagine di phishing, e tecniche di offuscamento del codice per eludere i filtri basati su reputazione dei domini. La pagina finale era un sito Microsoft contraffatto di tipo AiTM (Adversary-in-the-Middle), progettato per intercettare le sessioni e bypassare l’autenticazione multifattore. Nessun gateway email, nessun URL scanner, nessuna threat intelligence feed avrebbe potuto rilevarlo: l’attacco viveva interamente nel browser dell’utente. Come riportato da BleepingComputer nella copertura originale della campagna, tra i domini malevoli impiegati figuravano boardproposalmeet[.]com e sqexclusiveboarddirect[.]icu.

  1. Lazarus Group: LinkedIn come piattaforma per finanziare il regime nordcoreano

Il livello più preoccupante di abuso di LinkedIn è quello state-sponsored. Il gruppo Lazarus, la principale unità cyber della Corea del Nord, utilizza la piattaforma come vettore primario di attacchi con obiettivi duplici: spionaggio industriale e furto di criptovalute per finanziare il programma nucleare di Pyongyang.

La campagna denominata “graphalgo”, attiva dall’inizio di maggio 2025 e analizzata da ReversingLabs nel febbraio 2026, vedeva sviluppatori avvicinati su LinkedIn, Facebook e Reddit con offerte di lavoro false nel settore blockchain e crypto, da parte di una società fittizia denominata Veltrix Capital (dominio veltrixcap[.]org, registrato ad aprile 2025). Come riportato da The Hacker News, ai candidati veniva chiesto di dimostrare le proprie competenze eseguendo un progetto che conteneva, tra le dipendenze, pacchetti malevoli pubblicati su npm e PyPI. Il pacchetto bigmathutils aveva superato le 10.000 installazioni nella versione pulita prima che venisse rilasciata la versione contenente il payload malevolo: una pazienza tattica che permette di accumulare fiducia prima di colpire.

Il malware deployato era un RAT cross-platform (in JavaScript, Python e VBScript) capace di enumerare processi, esfiltrare file, eseguire comandi arbitrari e controllare la presenza dell’estensione MetaMask nel browser per individuare wallet di criptovaluta. Parallelamente, la campagna Contagious Interview vedeva Lazarus impersonare reclutatori di aziende reali (inclusa Fireblocks stessa) per condurre finti colloqui tecnici durante i quali i candidati venivano istruiti a clonare repository GitHub e installare pacchetti npm che innescavano l’infezione.

Il CEO di Fireblocks, Michael Shaulov, che ha lavorato con LinkedIn e le forze dell’ordine per rimuovere quasi una dozzina di profili fake legati alla campagna, ha descritto l’evoluzione degli attaccanti nordcoreani a CNBC: «Nel 2017 e 2018 era relativamente facile identificarli per gli errori grammaticali. Ora sembrerebbe che si siano laureati a Oxford». L’accelerazione è attribuita direttamente all’AI: «It’s clear that the attackers have become way more sophisticated and way harder to detect because of AI».

  1. Spionaggio di Stato: la Cina e i falsi recruiter contro NATO e UE

Il 28 marzo 2026, una fonte di sicurezza europea ha confermato ad AFP quello che i servizi di intelligence occidentali sospettavano da anni: la Cina ha utilizzato profili falsi su LinkedIn per raccogliere informazioni sensibili da dipendenti di istituzioni NATO e dell’Unione Europea. L’operazione, attribuita al Ministero per la Sicurezza dello Stato cinese (MSS), ha preso di mira decine di funzionari attraverso account fittizi che si presentavano come recruiter.

Uno dei profili più attivi utilizzava il nome “Kevin Zhang”, presentandosi come responsabile di una fittizia società di Hong Kong chiamata “Oriental Consulting”. I recruiter iniziavano richiedendo report a pagamento su temi geopolitici, per poi sollecitare informazioni non pubbliche o classificate. I funzionari di Francia, Belgio e Regno Unito reclutati ricevevano compensi da poche centinaia a diverse migliaia di dollari. Gli argomenti di maggiore interesse includevano le sanzioni UE contro la Cina e la strategia NATO in Asia, in particolare riguardo a Taiwan.

La ministra belga della Giustizia Annelies Verlinden ha dichiarato ad AFP che attraverso questa operazione «a great deal of important information and intelligence may have reached China», aggiungendo che internet è diventato un terreno fertile per le grandi potenze che cercano di reclutare agenti.

Non si tratta di un caso isolato. L’utilizzo di LinkedIn da parte del MSS cinese è documentato almeno dal 2014: nel 2023, l’ex capo dell’intelligence estera francese ha rivelato che Beijing avrebbe già avviato in quell’anno un’operazione massiva di spionaggio tramite social media. Nel dicembre 2017, il BfV tedesco aveva individuato oltre 10.000 cittadini tedeschi contattati da profili falsi che prendevano di mira politici e dirigenti aziendali. A novembre 2025, MI5 ha identificato due profili LinkedIn: Amanda Qiu (BR-YR Executive Search) e Shirly Shen (Internship Union), entrambe operative del MSS impegnate a costruire relazioni con parlamentari britannici.

L’agenzia ha avvertito che i profili falsi cinesi ricorrono frequentemente all’archetipo di una giovane donna con nome anglicizzato. Le implicazioni di questa campagna per le istituzioni europee sono discusse anche nell’analisi sullo spionaggio digitale nell’era dell’intelligenza artificiale pubblicata su ICT Security Magazine, che contestualizza le operazioni del MSS nel quadro più ampio della competizione geopolitica per il controllo dell’informazione.

Il problema strutturale: un blind spot nelle difese aziendali

Distribuendo payload malevoli attraverso LinkedIn e altre piattaforme social, gli attaccanti sfruttano sistematicamente i punti ciechi nelle protezioni di cybersecurity delle organizzazioni, che spesso non coprono questi canali con la stessa attenzione riservata alla posta elettronica. Secondo Push Security, il 34% degli attacchi di phishing intercettati nell’ultimo periodo è arrivato attraverso canali non-email, tra cui social media, app di messaggistica, inserzioni pubblicitarie malevole e comunicazioni in-app. Come rilevato nel report di Push Security sul phishing 2025, LinkedIn DM e Google Search rappresentano i due canali non-email più sfruttati dagli attaccanti.

Il paradosso è che LinkedIn, proprio perché è una piattaforma percepita come affidabile e professionale, abbassa strutturalmente la soglia di guardia degli utenti. Nessuno si aspetta di essere attaccato su una piattaforma dove si gestiscono relazioni lavorative verificate. Ed è esattamente questa aspettativa che gli attaccanti, dai gruppi criminali agli APT statali, hanno imparato a monetizzare.

Raccomandazioni operative

Per i team di sicurezza aziendali, le evidenze raccolte suggeriscono di integrare nelle policy di sicurezza e nei programmi di security awareness training moduli specifici dedicati alle minacce su piattaforme social. È necessario trattare qualsiasi link o archivio ricevuto via LinkedIn DM con la stessa cautela riservata agli allegati email sospetti, non aprire mai archivi SFX o eseguibili condivisi durante processi di selezione senza verifica indipendente dell’identità del mittente, e verificare sempre l’URL del mittente nelle notifiche LinkedIn prima di cliccare. Va ricordato, infine, che LinkedIn non comunica mai restrizioni di account attraverso commenti pubblici o link in email non sollecitate.

Condividi sui Social Network:

https://www.ictsecuritymagazine.com/notizie/linkedin-cybercrime/




Cyber-guerra Iran-USA-Israele: operazione Epic Fury e Roaring Lion, il più grande attacco informatico della storia

La cyber-guerra Iran-USA-Israele che si è aperta il 28 febbraio 2026 non è un’escalation come le altre. È il primo conflitto su larga scala in cui le operazioni cibernetiche hanno preceduto, accompagnato e amplificato quelle cinetiche in modo strutturale e documentato. L’Operazione Epic Fury (denominazione statunitense) e l’Operazione Roaring Lion (denominazione israeliana) hanno colpito oltre 1.250 obiettivi militari iraniani nelle prime 48 ore. Ma prima che un singolo missile lasciasse il tubo di lancio, lo U.S. Cyber Command era già il first mover: le operazioni cyber hanno aperto la strada a tutto il resto.

Il risultato è stato la dimostrazione più eclatante nella storia della cybersecurity di cosa significhi cyber dominance, e di quanto sia fragile il confine tra pace e guerra nel dominio digitale.

Un’operazione cyber senza precedenti

Le quattro ore che hanno cambiato la dottrina militare

Secondo l’analisi pubblicata da Lawfare, il nucleo dell’offensiva cyber si è consumato in circa quattro ore, prima che il regime iraniano imponesse il blackout totale di internet. In quella finestra temporale, la coalizione ha ottenuto risultati straordinari.

Il generale Dan Caine, presidente dei Joint Chiefs of Staff, ha dichiarato in conferenza stampa che le operazioni spaziali e cyber coordinate hanno effettivamente interrotto le comunicazioni e le reti sensoriali iraniane, privando l’avversario della capacità di osservare, coordinare e rispondere. L’obiettivo dichiarato era disorientare e confondere il nemico.

Ciò che emerge dal reporting di fonti multiple – Financial Times, Unit 42, CSIS – è un’operazione a strati multipli che ha colpito simultaneamente diversi livelli dell’infrastruttura iraniana.

Livello 1 – Infrastruttura di rete. La connettività internet iraniana è crollata tra l’1 e il 4% dei livelli normali la mattina del 28 febbraio 2026, secondo le rilevazioni di Unit 42. L’attacco ha interessato routing BGP, infrastruttura DNS e sistemi SCADA/ICS, come documentato da AttackIQ. Non si è trattato di un semplice DDoS: è stata un’operazione multi-vettore progettata per isolare il Paese dal resto del mondo digitale.

Livello 2 – Intelligence e sorveglianza. Il Financial Times ha rivelato che l’intelligence israeliana monitorava da anni la rete di telecamere stradali di Teheran, utilizzandola per tracciare i movimenti delle guardie del corpo di Khamenei e di altri alti funzionari. Un’operazione cyber parallela ha interrotto il sistema di telefonia mobile nell’area del compound di Khamenei, impedendo al suo staff di sicurezza di ricevere avvertimenti sull’attacco imminente. Questa capacità, come ha sottolineato l’analisi di Lawfare, è il risultato di anni di costruzione di un’architettura di intelligence comprensiva focalizzata su Teheran, basata su SIGINT, cyber espionage e HUMINT.

Livello 3 – Operazioni informative. L’app religiosa iraniana BadeSaba, con oltre 5 milioni di download, è stata compromessa per inviare messaggi di propaganda direttamente ai cittadini e al personale militare. Il primo messaggio recitava: “L’aiuto è arrivato.” Un secondo era indirizzato specificamente al personale delle forze armate, invitandolo a deporre le armi o unirsi alle forze di liberazione. Come ha osservato su X lo specialista iraniano Hamid Kashfi, l’app è estremamente popolare e richiede l’accesso alla geolocalizzazione dell’utente per fornire orari di preghiera accurati. La compromissione aveva quindi un doppio valore: intelligence sulla posizione di milioni di utenti e operazione psicologica in tempo reale.

Livello 4 – Disruption dei media e del C2. L’agenzia di stampa statale iraniana IRNA e diversi siti governativi sono stati compromessi tramite hijacking. Le comunicazioni di comando e controllo dell’IRGC sono state interrotte durante le ore critiche di apertura dell’operazione, secondo il reporting di AttackIQ.

Il paradosso della finestra temporale

L’analisi di Lawfare evidenzia un paradosso fondamentale: più l’operazione cyber è efficace, più breve è la sua finestra di utilità. Circa quattro ore dopo l’inizio degli attacchi, il regime iraniano ha imposto un blackout internet a livello nazionale – una risposta che l’Iran adotta abitualmente anche durante il dissenso interno. Il blackout ha eliminato simultaneamente sia le capacità offensive della coalizione nel cyberspazio sia quelle degli stessi apparati statali iraniani.

Questo produce una lezione dottrinale di enorme importanza per i pianificatori militari e i professionisti della cybersecurity: la cyber dominance è un asset a tempo determinato. Una volta impiegata, il suo effetto si consuma rapidamente – ma nei conflitti moderni, quelle prime ore possono determinare l’esito dell’intera campagna.

Il confronto con il precedente ucraino

Il parallelo più immediato è con l’invasione russa dell’Ucraina nel febbraio 2022, quando l’attacco al sistema satellitare Viasat e i wiper malware (HermeticWiper, IsaacWiper, CaddyWiper) accompagnarono le prime ore dell’offensiva cinetica. Tuttavia, la scala dell’operazione contro l’Iran segna un salto qualitativo significativo.

In Ucraina, le operazioni cyber russe ebbero un impatto limitato sulla connettività complessiva del Paese e non impedirono alla leadership ucraina di comunicare e coordinare la difesa.

In Iran, la connettività nazionale è stata ridotta all’1-4% in poche ore – un livello di disruption che non ha precedenti in conflitti tra Stati. Inoltre, la compromissione di app consumer (BadeSaba), reti di telecamere urbane e sistemi di telefonia mobile in un’unica operazione integrata dimostra un livello di preparazione e di penetrazione dell’infrastruttura avversaria che va ben oltre quanto osservato nel teatro ucraino.

La risposta: 60 gruppi hacktivisti, il fronte cyber si allarga

L’Electronic Operations Room e la coalizione delle sigle

La reazione nel dominio cyber non si è fatta attendere. Secondo Unit 42, al 2 marzo 2026 erano attivi circa 60 gruppi hacktivisti, inclusi collettivi pro-russi che si sono uniti al fronte. Il 28 febbraio stesso è stata costituita una struttura di coordinamento denominata Electronic Operations Room.

Un’analisi di Rescana ha documentato, tra il 28 febbraio e il 2 marzo 2026, ben 149 attacchi DDoS hacktivisti che hanno colpito 110 organizzazioni in 16 Paesi. La maggioranza degli attacchi si è concentrata in Kuwait (28%), Israele (27,1%) e Giordania (21,5%), con il settore governativo che ha rappresentato quasi il 48% degli obiettivi.

Tra i gruppi più attivi identificati da Unit 42, SOCRadar e CloudSEK:

  • Handala Hack – collegato al Ministero dell’Intelligence iraniano (MOIS), è la persona più prominente nel panorama hacktivista iraniano. Ha rivendicato compromissioni di aziende energetiche israeliane, dei sistemi di distribuzione carburante giordani, e ha minacciato funzionari israeliani con doxxing e minacce di morte, segnalando uno sconfinamento verso l’intimidazione psicologica e fisica.
  • FAD Team (Fatimiyoun Cyber Team) – ha rivendicato l’accesso non autorizzato a sistemi SCADA/PLC in Israele e in altri Paesi, inclusi sistemi di controllo di oltre 24 dispositivi appartenenti a una società di servizi di sicurezza israeliana. Il gruppo si concentra su wiper malware e distruzione permanente dei dati.
  • Dark Storm Team – collettivo pro-palestiniano e pro-iraniano specializzato in DDoS su larga scala, che ha colpito istituzioni finanziarie e siti web israeliani.
  • Keymous+ e DieNet – responsabili di quasi il 70% dell’intera attività di attacco DDoS documentata nei primi giorni del conflitto, secondo i dati di Radware.
  • Gruppi pro-russi come NoName057(16) e Z-Pentest – quest’ultimo ha rivendicato, tra il 28 febbraio e il 2 marzo, la compromissione di diverse entità statunitensi, inclusi sistemi ICS/SCADA e reti CCTV.

Una nota di cautela è doverosa: molte di queste rivendicazioni vanno valutate con scetticismo critico. L’analisi di Symantec ha riscontrato che alcune rivendicazioni di alto profilo – come il presunto attacco di Handala a Saudi Aramco – si basavano su documenti già in circolazione, suggerendo operazioni informative o psicologiche più che compromissioni reali. Anche Sophos ha sottolineato che i gruppi iraniani hanno talvolta sovrastimato le proprie capacità, pur rimanendo attori capaci. La distinzione tra DDoS temporaneo, defacement, esfiltrazione reale di dati e compromissione profonda di infrastrutture è fondamentale per calibrare correttamente la risposta difensiva.

Oltre il DDoS: wiper, ransomware e targeting ICS/OT

La cyber-guerra Iran-USA-Israele non si limita ai DDoS. Flashpoint ha identificato una massiccia campagna #OpIsrael che coinvolge attori pro-russi e pro-iraniani nella quale i sistemi di controllo industriale israeliani sono stati presi di mira direttamente. Il Fatimiyoun Electronic Team, secondo il Washington Institute, starebbe conducendo attacchi contro aziende energetiche e finanziarie occidentali con l’obiettivo di dispiegare wiper malware.

Una campagna di phishing particolarmente insidiosa ha distribuito l’APK malevolo RedAlert, mascherato da applicazione ufficiale di allerta emergenza, progettato per la sorveglianza e l’esfiltrazione di dati dai dispositivi mobili.

La pre-posizione: MuddyWater era già dentro

Seedworm nelle reti statunitensi

Uno degli sviluppi più significativi per comprendere la dimensione strategica di questa cyber-guerra è la scoperta, pubblicata il 5 marzo 2026 dal team Symantec e Carbon Black Threat Hunter di Broadcom, che il gruppo APT iraniano MuddyWater (noto anche come Seedworm) era attivo nelle reti di diverse organizzazioni statunitensi sin dall’inizio di febbraio 2026 – settimane prima dell’inizio delle operazioni cinetiche.

Le vittime includono una banca statunitense, un aeroporto, organizzazioni non governative negli USA e in Canada, e le operazioni israeliane di una società software fornitrice dell’industria della difesa e aerospaziale. I ricercatori hanno identificato un backdoor fino ad allora sconosciuto, denominato Dindoor, basato sul runtime Deno per l’esecuzione di codice JavaScript e TypeScript, firmato digitalmente con un certificato intestato a “Amy Cherne”. Un secondo backdoor Python, Fakeset, è stato trovato sulle reti dell’aeroporto e dell’ONG, firmato con certificati legati a Seedworm.

Come ha commentato Denis Calderone, CTO di Suzu Labs, all’outlet SC Media: la guerra cyber non è iniziata quando le bombe hanno cominciato a cadere. Era già in corso a febbraio. Il fatto che MuddyWater disponesse di tooling nuovo e operativo prima dell’inizio del conflitto cinetico rivela il livello di preparazione del gruppo.

Ulteriore conferma è arrivata dal collettivo di threat intelligence indipendente Ctrl-Alt-Intel, che ha ottenuto accesso a un’infrastruttura di MuddyWater ospitata nei Paesi Bassi, scoprendo un vasto arsenale di framework C2 personalizzati, script, log e dati delle vittime, con l’exploitation di oltre una dozzina di CVE, incluse vulnerabilità SQL injection precedentemente sconosciute, come riportato da Help Net Security.

Pyroxene, Bauxite, Parisite: la pipeline verso l’OT

L’analisi di HSToday mette in evidenza tre gruppi iraniani che operano lungo una kill chain strutturata verso gli ambienti di Operational Technology (OT):

  • Pyroxene (allineato all’IRGC, sovrapposizione con UNC1549 secondo Mandiant) – sta conducendo operazioni di mapping nella kill chain ICS di Stage 2 all’interno delle reti di fornitori e contractor nei settori difesa, aviazione ed energia, utilizzando tenant Microsoft Azure vittima-specifici come infrastruttura C2.
  • Bauxite (operante sotto la persona CyberAv3ngers) – ha già superato la fase dell’accesso per raggiungere gli effetti: avrebbe compromesso oltre 400 dispositivi OT tramite il malware IOControl, secondo fonti di settore, manipolando PLC Unitronics presso impianti idrici statunitensi. Il CISA aveva già emesso un advisory dedicato alle attività di CyberAv3ngers contro dispositivi Unitronics nel dicembre 2023, confermando il pattern di targeting ICS da parte di questo gruppo.
  • Parisite (noto come Pioneer Kitten/Fox Kitten) – funziona come Initial Access Broker per questo ecosistema, sfruttando VPN esposte e dispositivi edge per compromettere ambienti IT di operatori di infrastrutture critiche, per poi vendere o trasferire l’accesso ad attori statali e affiliati ransomware. Dragos ha osservato direttamente Parisite fornire accessi successivamente utilizzati in operazioni dirette verso ambienti OT.

Il punto cruciale: il seam IT-to-OT non è una vulnerabilità teorica. È un percorso di exploitation attivo e documentato.

Le TTP iraniane nel framework MITRE ATT&CK

Per i SOC analyst e i threat hunter, è utile mappare le tecniche osservate nel conflitto corrente sul framework MITRE ATT&CK. Le TTP dominanti degli APT iraniani attivi in questa fase includono:

  • T1566 – Phishing e T1566.001 – Spearphishing Attachment: vettore iniziale privilegiato da MuddyWater (campagna Dindoor) e APT42, con documenti Office armati e campagne RedAlert APK.
  • T1078 – Valid Accounts: sfruttamento di credenziali legittime rubate, tecnica cardine per Parisite/Fox Kitten nell’accesso iniziale a reti di infrastrutture critiche.
  • T1190 – Exploit Public-Facing Application: exploitation di VPN, dispositivi edge e applicazioni esposte, documentata sia per Parisite che per MuddyWater.
  • T1059.007 – Command and Scripting Interpreter: JavaScript: il backdoor Dindoor utilizza il runtime Deno per eseguire comandi, una scelta tecnica insolita che indica evoluzione del tooling.
  • T1071.001 – Application Layer Protocol: Web Protocols: utilizzo di servizi cloud legittimi (Azure, Wasabi, Backblaze) come infrastruttura C2, rendendo il traffico malevolo indistinguibile da quello aziendale.
  • T1567 – Exfiltration Over Web Service: tentativo di esfiltrazione verso bucket Wasabi Technologies tramite Rclone, osservato nella campagna contro la società software.
  • T0831 – Manipulation of Control (ICS): la manipolazione dei PLC Unitronics da parte di Bauxite/CyberAv3ngers rappresenta un’operazione ICS di Stage 2 nella kill chain Dragos/SANS.

Questo mapping non è esaustivo, ma fornisce ai team difensivi un riferimento immediato per verificare la copertura delle proprie detection rule rispetto alle tecniche più attive in questo specifico contesto di minaccia.

Le lezioni operative per i CISO

Sei azioni immediate

La combinazione delle raccomandazioni di Unit 42, HSToday, eSentire e delle analisi di settore converge su sei azioni prioritarie.

  1. Isolare i dispositivi OT esposti a internet. In particolare PLC Unitronics e qualsiasi dispositivo ICS accessibile dall’esterno. La campagna di Bauxite/CyberAv3ngers ha dimostrato che gli attaccanti iraniani hanno già la capacità e la volontà di manipolare sistemi di controllo industriale.
  2. Auditare e terminare le sessioni VPN di contractor inutilizzate. Parisite/Fox Kitten opera esattamente come un Initial Access Broker, sfruttando VPN e dispositivi edge di fornitori nei settori difesa, aviazione ed energia. Ogni sessione VPN non terminata di un contractor è una porta aperta.
  3. Abilitare alerting sulle anomalie nelle API cloud. Pyroxene utilizza tenant Azure vittima-specifici come C2. Il monitoraggio delle chiamate API verso servizi cloud come Azure, AWS e GCP, in particolare quelle che attraversano il confine IT-OT, è fondamentale.
  4. Conservare almeno una copia dei dati critici in modalità air-gapped. Il wiper malware è lo strumento privilegiato delle operazioni distruttive iraniane – dalla campagna contro l’Albania nel 2022 alle attuali minacce del FAD Team.
  5. Implementare il blocco geografico degli IP dove possibile. Questo non è sufficiente di per sé – gli attaccanti utilizzano proxy e VPN – ma riduce la superficie d’attacco per gli strumenti automatizzati a bassa sofisticazione che rappresentano la maggioranza del volume.
  6. Preparare un piano di comunicazione per la gestione delle rivendicazioni. Come sottolinea Unit 42, i gruppi hacktivisti spesso esagerano la portata dei loro attacchi. Avere una procedura per validare e rispondere alle rivendicazioni – distinguendo tra accesso effettivo e compromissione di sistema – è fondamentale per evitare il panico e il danno reputazionale.

La domanda scomoda sull’OT

La lezione più profonda di questa cyber-guerra Iran-USA-Israele riguarda la sicurezza OT. Dragos ha documentato che il percorso dall’accesso IT alla compromissione OT è un pathway attivo e verificato, non un rischio ipotetico. Per i CISO europei e italiani – in particolare nei settori energia, trasporti e manifatturiero – questo significa porsi tre domande urgenti, come suggerisce l’analisi di HSToday:

  • Chi ha l’autorità di disconnettere da internet i nostri asset OT più critici con brevissimo preavviso?
  • Quanto velocemente possiamo terminare tutti gli accessi di terze parti nel nostro ambiente?
  • Abbiamo visibilità sui servizi cloud che i nostri fornitori utilizzano per gestire i nostri sistemi?

Se la risposta a una di queste domande è “non lo so”, il livello di esposizione è significativo.

Il quadro strategico: cyber come strumento asimmetrico

La dottrina iraniana dopo il blackout

L’analisi di Halcyon evidenzia un aspetto strutturale della cyber capability iraniana che questo conflitto rende ancora più rilevante: la convergenza tra operazioni statali e attività criminale. Il modello iraniano prevede che operatori statali monetizzino gli accessi ottenuti attraverso campagne governative tramite estorsione, mantenendo una plausible deniability.

Questo è particolarmente rilevante perché, come valutato dal CSIS, con le capacità convenzionali gravemente degradate dalle operazioni cinetiche, il cyber rappresenta ora lo strumento asimmetrico più accessibile per la ritorsione iraniana. La degradazione della connettività internet ha temporaneamente ostacolato la capacità di coordinamento degli APT operanti dall’interno dell’Iran, ma Unit 42 avverte che la degradazione dei comandi potrebbe anche portare ad autonomia tattica per le cellule operative al di fuori dei confini iraniani, con potenziali deviazioni dai pattern precedentemente stabiliti.

CISA sotto stress

Un fattore aggravante, documentato da CNBC, è che la principale agenzia cyber statunitense – CISA – si trova in condizioni operative ridotte. Al momento della pubblicazione, il sito web dell’agenzia riportava un ultimo aggiornamento al 17 febbraio a causa di un lapse in federal funding, con la cancellazione di valutazioni di sicurezza, formazione e altri impegni. Secondo CNBC, l’agenzia avrebbe perso circa un terzo dei suoi dipendenti dal cambio di amministrazione, e il suo direttore temporaneo sarebbe stato riassegnato ad altra divisione del DHS. Se confermato, questo scenario crea un vuoto di coordinamento proprio nel momento in cui la minaccia è più elevata.

Lo spettro della ritorsione a lungo termine

Il precedente storico è chiaro. Dopo l’uccisione del generale Soleimani nel 2020, i gruppi iraniani hanno lanciato ondate di wiper attack, campagne di credential harvesting e operazioni di spionaggio contro infrastrutture critiche occidentali. Come sottolinea AttackIQ, lo stesso playbook si sta dispiegando ora, ma con strumenti significativamente più capaci. Gruppi come MuddyWater, APT35/Charming Kitten, OilRig/APT34 e Agrius hanno trascorso anni a perfezionare il loro tradecraft.

La scoperta da parte di ESET nel dicembre 2025 del nuovo backdoor MuddyViper di MuddyWater, indirizzato verso infrastrutture critiche israeliane ed egiziane, e la campagna Operazione Olalampo di febbraio 2026 che ha dispiegato backdoor AI-assisted contro i settori energia e marittimo nell’area MENA, confermano che questi gruppi rimangono operativamente attivi e in evoluzione.

Prospettive: la nuova normalità della guerra ibrida

Questa cyber-guerra Iran-USA-Israele ha reso concreta una serie di scenari che la comunità di cybersecurity discuteva in termini teorici. Non è più una questione di se le operazioni cyber accompagneranno i conflitti cinetici, ma di come difendersi in un contesto dove la guerra nel cyberspazio precede, accompagna e sopravvive a quella sul campo.

Per l’Europa – e per l’Italia in particolare, con la sua esposizione sia come hub energetico mediterraneo sia come Paese con basi NATO e rappresentanze diplomatiche dei Paesi coinvolti – il messaggio è chiaro: la sicurezza delle infrastrutture critiche non è più un esercizio di compliance, ma una questione di resilienza nazionale.

Come ha osservato Scott McKinnon, CSO di Palo Alto Networks per UK e Irlanda, al Mobile World Congress di Barcellona: ogni volta che c’è un conflitto, c’è sempre una risposta. Non vengono usati solo i sistemi di difesa e di attacco fisici, ma anche armamenti collaterali nel cyberspazio.

La cyber-guerra Iran-USA-Israele è il primo banco di prova della guerra ibrida su scala globale. Non sarà l’ultimo.

Condividi sui Social Network:

https://www.ictsecuritymagazine.com/notizie/cyber-guerra-iran-usa-israele/




Il trattamento dei dati sanitari

Questo articolo fa parte della serie legata al tema della cybercriminalità nel settore sanitario, un percorso di analisi che intreccia sanità digitale, protezione dei dati e sicurezza informatica. L’attenzione si concentra sul concetto di dati sanitari, considerati il nucleo più sensibile della privacy. Essi, infatti, non solo riflettono la condizione clinica di un individuo, ma ne svelano la dimensione più intima, richiedendo tutele rafforzate sia sul piano normativo che tecnologico.

Così la Dr.ssa Salvadori Angelica, consigliere dell’Ordine dei Medici Chirurghi e Odontoiatri della Provincia di Torino:

La prima cosa che faccio quando arrivo in studio è accendere il computer. E con questo gesto apro, in qualche modo inconsapevole, una finestra, anzi una porta attraverso la quale, nel corso della giornata, i dati dei miei pazienti potranno essere disseminati in molte direzioni. […] Ad esempio, mi metto in collegamento con il SAR (Sistema di Accoglienza Regionale) della Regione Piemonte e il SAC (Sistema di Accoglienza Centrale) quando compilo in modalità informatica una ricetta dematerializzata contenente prescrizioni farmaceutiche e specialistiche, mi collego con AURA (Archivio Unico Regionale degli Assistiti della Regione Piemonte) se emerge l’esigenza di un aggiornamento dell’anagrafe degli assistiti, mi connetto con l’INPS (Istituto Nazionale della Previdenza Sociale) quando rilascio un certificato di malattia, oppure con l’INAIL (Istituto Nazionale per l’Assicurazione contro gli Infortuni sul Lavoro) se devo certificare un infortunio lavorativo, con il CSI Piemonte (Consorzio per il Sistema Informativo) se devo vedere l’esito di un tampone per Covid 19, se devo richiederne uno, se devo verificare l’inizio o la fine di una quarantena o di un isolamento, se devo vedere se un paziente è vaccinato. E questo vale non solo per me, medico di medicina generale, ma per tutti i medici convenzionati con il SSN, per i medici specialisti ospedalieri e, per alcuni aspetti, anche per i medici liberi professionisti.Se i medici, forse, non sempre sono consapevoli di tutto quello che mettono in moto, viene da chiedersi: e i cittadini? Hanno una percezione corretta di tutte le strade che possono prendere i loro dati sanitari?”.[1]

Nel discorrere del primo capitolo si è potuto constatare come, grazie alle potenzialità offerte dall’innovazione tecnologica, i dati sanitari stiano acquisendo sempre maggior impiego nel mondo contemporaneo: dalla ricerca medica e farmaceutica alla gestione dei servizi sanitari pubblici e privati.[2]

La materia inerente alla protezione dei dati sanitari è stata definita “diritto inquieto”[3], vi è difatti una tensione che caratterizza i dati sanitari stessi: meritevoli da un lato di massima protezione e riservatezza, e dall’altro di una calibrata circolazione per esigenze di sanità pubblica (si pensi alla destinazione ai fini di ricerca). A tale poi già complesso bilanciamento si aggiunge il problema della sicurezza rispetto a possibili attacchi informatici che possono mettere a rischio tanto la privacy degli individui quanto la tutela della salute pubblica.

Occorrerà comunque dapprima inquadrare ontologicamente le categoria dei dati idonei a rivelare lo stato di salute.

Alquanto nota è difatti la formula che consente di qualificare i dati sanitari come “nocciolo (o nucleo) duro” della privacy, locuzione utilizzata da chi rileva come essi si collochino “nel cerchio concentrico più interno” o, se si vuole, all’estremo più elevato della “scala delle durezze”[4] della protezione dei dati personali, risultando invero capaci di far intravedere, quando non di svelare del tutto, la sfera più riservata della persona.[5]

Ed è proprio dalla loro alta sensibilità che si ricava la necessità di una maggior tutela nel trattamento rispetto a quello indirizzato ad altre tipologie di dati, in quanto, se non correttamente svolto, potrebbe ingenerare rischi significativi per il rispetto dei diritti e delle libertà fondamentali dell’individuo, esponendo quest’ultimo a potenziali discriminazioni, stigmatizzazioni e classificazioni.

Il quadro normativo di riferimento è sicuramente esteso, ad ogni modo come fonti principali si possono indicare il Regolamento (UE) 2016/679 del Parlamento europeo e del Consiglio per come relativo alla protezione delle persone fisiche con riguardo al trattamento dei dati personali, nonché alla libera circolazione di tali dati, anche meglio noto come GDPR (General Data Protection Regulation), che abroga la direttiva 95/46/CE;[6] a cui si aggiunga il decreto legislativo 30 giugno 2003, n. 196 (Codice in materia di protezione dei dati personali, conosciuto anche come Codice della privacy), aggiornato ed integrato con le modifiche introdotte dal decreto legislativo del 10 agosto 2018, n. 101, quale recante disposizioni per l’adeguamento della normativa nazionale al regolamento (UE) anzidetto. [7]

Prima di affrontare la spinosa questione della protezione dei dati personali si vogliono fissare alcune preliminari definizioni, guardando innanzitutto alle disposizioni del Regolamento 2016/679/UE.

L’art. 4, par. 1, n. 1 del testo normativo sopradetto infatti chiarisce come per dato personale si debba intendere: “qualsiasi informazione riguardante una persona fisica identificata o identificabile («interessato»); si considera identificabile la persona fisica che può essere identificata, direttamente o indirettamente, con particolare riferimento ad un identificativo come il nome, un numero di identificazione, dati relativi all’ubicazione, un identificativo online o ad uno o più elementi caratteristici della sua identità fisica, fisiologica, genetica, psichica, economica, culturale o sociale”.

Entro l’ampia categoria dei dati personali si rinviene poi il sottoinsieme dei cosiddetti “dati particolari” (ex dati sensibili, nel vecchio codice privacy), definiti dall’art. 9 del GDPR come: “dati personali che rivelino l’origine razziale o etnica, le opinioni politiche, le convinzioni religiose o filosofiche, o l’appartenenza sindacale, nonché dati genetici, dati biometrici intesi a identificare in modo univoco una persona fisica, dati relativi alla salute o alla vita sessuale o all’orientamento sessuale della persona”.

Si noti come i dati relativi alla salute figurino proprio fra i dati particolari, cioè quei dati la cui conoscenza da parte di altri può recare un grave pregiudizio per l’interessato.

Addentrandosi ancora più nel dettaglio della normativa il Considerando 35 del GDPR puntualizza come fra i dati inerenti alla salute dovrebbero rientrare :

tutti i dati riguardanti lo stato di salute dell’interessato che rivelino informazioni connesse allo stato di salute fisica o mentale passata, presente o futura dello stesso. […] Le informazioni risultanti da esami e controlli effettuati su una parte del corpo o una sostanza organica, compresi i dati genetici e i campioni biologici; e qualsiasi informazione riguardante, ad esempio, una malattia, una disabilità, il rischio di malattie, l’anamnesi medica, i trattamenti clinici o lo stato fisiologico o biomedico dell’interessato, indipendentemente dalla fonte, quale, ad esempio, un medico o altro operatore sanitario, un ospedale, un dispositivo medico o un test diagnostico in vitro”.

Si comprende allora il motivo per cui i dati sanitari, ipersensibili, espressivi della più autentica essenza della privatezza, siano proprio quella tipologia di dati ad andare a beneficiare di una maggior tutela accordata dall’ordinamento, per come espressa in: misure di garanzia rafforzate, presupposti di liceità del trattamento particolarmente stringenti, stretta indispensabilità a fini informativi, divieto di divulgazione, e si intuirà altresì la ragione per cui siano necessitanti di una protezione rafforzata rispetto a tutti quei rischi di intrusione ed accesso indebito, alterazione e manipolazione connessi a possibili attacchi cibernetici indirizzabili ai sistemi informativi sanitari.[8]

Principi cardine sulla protezione dei dati sanitari

Appurato come in ambito medico, ossia in qualsiasi struttura ospedaliera, RSA, ambulatorio del medico di base o del libero professionista, ad esser trattati sistematicamente siano soprattutto dati “particolari”, si volgerà ivi lo sguardo alle disposizioni che vanno a disciplinarne le specifiche modalità di trattamento.

Preliminarmente tuttavia si passeranno in rassegna i sei principi generali, in tema di trattamento dei dati personali, elencati all’art. 5 del GDPR, quali presupposti fondamentali attorno a cui orbitano tutti i meccanismi di protezione dei dati.

In primis si annoveri il principio definito di liceità, correttezza e trasparenza (lawfulness, fairness and transparency), in nome del quale si richiede che i dati “vengano trattati in modo lecito, corretto e trasparente nei confronti degli interessati”, ciò implica dunque che qualsiasi informazione ad essi inerente sia accessibile e di facile comprensione, grazie all’utilizzo di un linguaggio chiaro e semplice, nonché che gli interessati abbiano contezza dell’identità dei titolari del trattamento (ossia dei soggetti che per l’appunto trattano i dati personali) e delle finalità del trattamento stesso.

Calando tale principio nel panorama sanitario si può richiamare quanto previsto dall’Accordo Stato-Regioni sulla telemedicina del 17 dicembre 2020, il quale prevede specifici oneri informativi nei confronti dei pazienti soggetti a servizi di telemedicina fra cui: una completa descrizione della gestione dei dati, dei diritti dell’assistito, delle modalità di contatto, nonché un elenco aggiornato dei responsabili del trattamento.[9]

Il secondo principio invece è relativo alla limitazione delle finalità (purpose limitation) dei dati, si rilevi come questi siano “raccolti per finalità determinate, esplicite e legittime”, per cui non sarà consentito trattarli successivamente in modo non compatibile con le finalità previamente delineate. Si tenga comunque presente che eventuali ulteriori trattamenti per finalità di pubblico interesse, di ricerca scientifica, storica o a fini statistici non sono considerati incompatibili con le finalità iniziali e risultano pertanto consentiti.

Il terzo principio è la c.d. minimizzazione dei dati (data minimisation), in ragione del quale questi ultimi dovranno essere “adeguati, pertinenti e limitati a quanto necessario rispetto alle finalità per le quali sono trattati”.

L’accuratezza poi (accuracy) è il quarto principio ed implica la necessità di garantire che i dati personali siano adeguatamente accurati ed aggiornati, ove necessario, adottando tutte le misure ragionevoli necessarie per cancellarli o rettificarli tempestivamente qualora inesatti rispetto alle finalità per cui vengono trattati.

Il quinto principio suole indicare la c.d. limitazione della conservazione (storage limitation), per cui i dati saranno “conservati in una forma che consenta l’identificazione degli interessati per un arco di tempo non superiore al conseguimento delle finalità per le quali sono trattati”. Una eventuale conservazione per periodi di tempo più lunghi sarà consentita unicamente per finalità di interesse pubblico, di ricerca scientifica, storica o a fini statistici. Le politiche di data retention, previste specificatamente dal nostro ordinamento, disciplinano infatti numerosi e differenziati tempi di conservazione per quanto concerne la documentazione sanitaria: sarà pertanto compito dell’operatore sanitario (pubblico o privato) dover identificare la natura della documentazione e conseguentemente la normativa di riferimento applicabile.

Per esemplificare, l’iconografia radiologica conta ad oggi un periodo di archiviazione di dieci anni, viceversa le cartelle cliniche, gli esami di laboratorio, i referti vedono un obbligo di conservazione illimitato nel tempo, in quanto rappresentanti atto ufficiale, indispensabile a garantire la certezza del diritto, nonché quale preziosa fonte documentaria per le ricerche di carattere storico sanitario.[10]

Il sesto ed ultimo principio riguarda infine l’integrità e la riservatezza dei dati (integrity and confidentiality), ciò implicherà che vengano adottate tutte le misure tecniche ed organizzative adeguate per garantire un livello di sicurezza proporzionato al rischio di varia probabilità e gravità per i diritti e le libertà delle persone fisiche, inclusa la protezione contro “trattamenti non autorizzati o illeciti, la perdita, la distruzione o il danno accidentale”.

A titolo esemplificativo, si richiami l’elencazione all’art 32 par.1 del GDPR relativamente alle misure che possono essere adottate ed implementate al fine di garantire la sicurezza dei digital data, fra cui:

  1. La pseudonimizzazione dei dati personali, ovvero una metodologia che si pone l’obiettivo di “allontanare” il dato dalla persona, rendendone così complessa la stessa riferibilità (senza tuttavia romperne il legame, a cui mirano invece le tecniche di anonimizzazione);[11]
  2. La cifratura dei dati, volta a rendere i dati personali incomprensibili a chiunque non sia autorizzato ad accedervi tramite una apposita chiave di lettura idonea a decriptarne l’informazione;
  3. La capacità di assicurare, su base permanente, la riservatezza, l’integrità, la disponibilità ed altresì la resilienza dei sistemi e dei servizi di trattamento;
  4. La capacità di ripristinare tempestivamente la disponibilità e l’accesso dei dati personali in caso di incidente fisico o tecnico;
  5. L’auditing, espressione volta ad indicare una procedura atta a testare, verificare, e valutare regolarmente l’efficacia delle misure tecniche e organizzative concretamente adottate.[12]

Si badi bene, il legislatore non entra nel dettaglio, anzi quello fornito risulta pressoché un elenco generale, poiché è fondamentale che la security stessa venga garantita da soluzioni ritagliate nel modo più personale possibile rispetto alle specificità del soggetto da proteggere. Non pare essere dunque “codardia legislativa”, ma diretta conseguenza dell’assunto secondo cui se il titolare del trattamento deve essere accountable allora dovrà parimenti essere libero di ritagliarsi il “vestito” di sicurezza che ritiene necessario per la propria struttura.

Il principio di accountability

Il medesimo art. 5 del GDPR, al secondo paragrafo, enuncia il principio di responsabilizzazione (o accountability), in assenza del quale i sei principi cardine previamente elencati non potrebbero esser attuati: sarà infatti precipua responsabilità del titolare del trattamento[13] predisporre e mettere in atto specifiche soluzioni tecniche e organizzative che rendano il trattamento lecito, corretto, trasparente, adeguato, limitato nel tempo, pertinente ed effettuato per finalità legittime; così come sarà sua stessa responsabilità risponderne e “render conto” dell’efficacia delle misure concretamente impiegate e dei risultati così ottenuti.

Pertanto la figura apicale di una data struttura (si pensi ad un Direttore sanitario), tenuto conto della natura del dato, del suo ambito di applicazione (nell’erogazione di servizi di cura, in un progetto di ricerca etc.), del contesto (limitatamente alla propria struttura, od in condivisione con altre), delle finalità del trattamento, dei rischi per i diritti e le libertà delle persone fisiche, dovrà adottare misure tecniche ed organizzative adeguate, ossia parametrate al livello di rischio rilevato. Le anzidette misure poi, ex art. 24 GDPR, dovranno essere “riesaminate ed aggiornate qualora necessario”, introducendo così il principio fondamentale della ciclicità della sicurezza, quale perimetro altamente dinamico da dover revisionare periodicamente nel tempo, al fine di ottenerne un sempre maggiore perfezionamento. [14]

Non vi è dubbio sul fatto che venga in tal modo a delinearsi un sistema di adeguamento al GDPR fortemente accentrato sulla figura del titolare del trattamento: data la riconosciuta difficoltà di esercizio dei diritti dell’interessato[15], essendo egli spesso propenso a rilasciare i propri dati con leggerezza o con carenza di consapevolezza, viene spostato il baricentro della responsabilità sul titolare del trattamento e sulla necessità che le operazioni di trattamento stesse siano “GDPR compliant”.[16]

Ed è proprio così che il concetto di accountability si collega con quelli di prevenzione e proattività, inglobando il saper agire d’anticipo, pianificando, mediante policy e tecnologie efficaci, quanto necessario per evitare i rischi di compromissione dei dati. Fare ciò significa, ex art. 25 GDPR, operare una valutazione del rischio e del suo contenimento attraverso tecniche di protezione “fin dall’avvio del trattamento” (c.d. privacy by default) e “per impostazione predefinita” (c.d. privacy by design): tali espressioni puntualizzano come la privacy degli interessati dovrà essere tutelata fin dall’inizio, cioè dalle fasi di ideazione e progettazione del servizio, e che non potranno esser trattati dati personali ulteriori rispetto a quelli minimi indispensabili per la specifica finalità del trattamento.[17]

Tali ragionamenti, per ciò che ivi più interessa, possono certo essere calati in ambito sanitario: i software, i dispositivi e le procedure utilizzati nella sanità digitale dovranno essere rispettosi della normativa in tema di protezione dei dati. Pertanto una corrispondenza di telemedicina fra medico e paziente con l’uso di sistemi non sicuri, come i social o la posta elettronica, costituisce di per sé una procedura a rischio, violante le regole sulla protezione dei dati, ed in quanto tale sanzionabile dall’Autorità Garante per la protezione dei dati.

Allora i sanitari, e le strutture che offrono servizi di telemedicina, hanno il precipuo dovere di gestire i rischi derivanti dal trattamento dei dati personali dei pazienti, optando per quelle soluzioni operative che offrano le migliori garanzie di proporzionalità, efficacia, sicurezza, e rispetto dei diritti della persona.[18]

Si voglia, già in questa sede, anticipare l’assoluto rilievo dell’innestare una cultura della (cyber)sicurezza mediante una adeguata formazione del personale medico, ed è così invero che recita l’articolo 32 comma 4 del GDPR: “Il titolare del trattamento ed il responsabile del trattamento fanno sì che chiunque agisca sotto la loro autorità e abbia accesso a dati personali non tratti tali dati se non è istruito in tal senso dal titolare medesimo.”

Si pensi ad una struttura sanitaria complessa (da un poliambulatorio ad un grande ospedale), in questa stessa gli operatori a trattare dati sanitari sono indubbiamente molteplici, ad ogni modo comunque tutti dovranno essere a conoscenza circa le procedure da seguire ed i conseguenti probabili rischi insiti nel trattamento di dati sensibili, in particolar modo alla luce delle sempre più frequenti compromissioni degli archivi e sistemi digitali sanitari.

Il Data Protection Officer

Anche la designazione di un Responsabile della protezione dati (da qui in avanti indicato come DPO, acronimo inglese per Data Protection Officer) rientra nell’approccio responsabilizzante delineato dal GDPR, in linea col principio di accountability.

Tale figura professionale, designata dal titolare o dal responsabile[19] del trattamento, si presenta quale un consulente esperto, dotato di un’approfondita conoscenza della normativa e delle prassi in tema di gestione dei dati personali, nonché dello specifico settore di riferimento in cui si trova ad operare.

La nomina del DPO si presenta come obbligatoria, ex art. 37 del GDPR, ogniqualvolta il trattamento sia effettuato da una autorità pubblica o da un organismo pubblico, nonché quando le attività principali del titolare o del responsabile del trattamento consistano nel trattare, su larga scala, categorie particolari di dati personali (quali per l’appunto sono i dati inerenti alla salute).

Questo non significa che ogni medico sia obbligato a designare un DPO: il singolo professionista o il medico di base non trattano dati “su vasta scala”, diversamente il problema si pone per gli studi in cui operano più medici e così anche per una Azienda sanitaria, un ospedale privato, una residenza sanitaria assistenziale, tutti si doteranno di tale figura dotata di competenze giuridiche, informatiche, nonché di risk management, la cui responsabilità sarà quella di osservare, valutare ed organizzare la gestione del trattamento dei dati personali (e dunque la loro protezione), affinché questi ultimi siano trattati nel rispetto delle normative privacy europee e nazionali.

L’art. 39 del GDPR opera poi una dettagliata elencazione delle principali funzioni del DPO, fra cui:

  1. Informare e fornire una consulenza al titolare o al responsabile del trattamento in merito agli obblighi derivanti del Regolamento europeo;
  2. Sorvegliare l’attuazione del Regolamento europeo, come anche vigilare sull’applicazione delle politiche del titolare del trattamento in materia di protezione dei dati personali, comprese l’attribuzione delle responsabilità, la sensibilizzazione e la formazione del personale che partecipa ai trattamenti;
  3. Fornire, se richiesto, un parere in merito alla valutazione d’impatto sulla protezione dei dati e sorvegliarne il concreto svolgimento. Essendo la valutazione d’impatto un processo volto a valutare la necessità e proporzionalità di un determinato trattamento e a gestirne gli eventuali rischi, il titolare del trattamento si consulterà preventivamente col DPO su tematiche quali: condurre o meno la valutazione stessa, quale specifica metodologia sia da adottare, quali salvaguardie e misure di sicurezza siano da applicare al fine di attenuare i rischi per i diritti delle persone interessate;
  4. Fungere da punto di contatto per il Garante per la protezione dei dati personali e controllare che sia dato seguito alle richieste del Garante stesso.

Ancora, al secondo paragrafo l’art. 39 del GDPR con una formula prettamente di chiusura: “Nell’eseguire i propri compiti il responsabile della protezione dei dati considera debitamente i rischi inerenti al trattamento, tenuto conto della natura, dell’ambito di applicazione, del contesto e delle finalità del medesimo”, in sostanza con tale disposizione di portata generale si chiede al DPO di delineare un ordine di priorità nell’attività svolta e di concentrarsi sulle questioni che presentino maggiori rischi in termini di protezione dei dati.[20]

Il registro delle attività di trattamento

Rientrante a sua volta nel concetto di accountability risulta essere anche il cosiddetto Registro delle attività di trattamento, novità introdotta dall’art. 30 del GDPR.

Quest’ultimo altro non è che lo strumento attraverso il quale il titolare e il responsabile del trattamento documentano in forma scritta, anche elettronica, le principali informazioni relative alle attività di trattamento e alle misure di garanzia adottate, in base alle finalità perseguite ed ai profili di rischio rilevati, al fine di poter poi dimostrare all’Autorità di controllo (il Garante per la protezione dei dati) di aver adempiuto correttamente alla propria funzione di protezione dei dati personali.

Per quanto concerne propriamente l’ambito sanitario la regolare tenuta del Registro delle attività di trattamento risulta quale obbligo per tutti gli operatori sanitari (singoli professionisti sanitari, medici di medicina generale, ospedali privati, case di cura, farmacie, parafarmacie, Aziende Sanitarie appartenenti al S.S.N. etc.).

Per analizzarne nel dettaglio il contenuto minimo si guardi alla elencazione fornita all’art. 30 del Regolamento, in base al quale il Registro conterrà:

  1. Il nome e i dati di contatto del titolare del trattamento;
  2. Le finalità del trattamento (come “trattamento dei dati del paziente per l’erogazione della specifica prestazione sanitaria”);
  3. Una descrizione delle categorie di interessati (ad esempio “pazienti”) e circa le categorie di dati personali (quali dati anagrafici, dati biometrici etc.);
  4. Le categorie di destinatari a cui i dati personali sono stati o saranno comunicati (si pensi ad un laboratorio analisi);
  5. Ove possibile, i termini ultimi previsti per la cancellazione delle diverse categorie di dati;
  6. Ove possibile, una descrizione generale circa le misure di sicurezza tecniche ed organizzative adottate (quali security policy, sistemi di intrusion detection etc.).

Potrà ad ogni modo esser riportata nel registro qualsiasi informazione che il titolare od il responsabile ritengano utile dover indicare (come le valutazioni di impatto effettuate o le modalità di raccolta del consenso seguite).

Standard internazionali per la sicurezza dei dati: ISO 27001

Come si è potuto osservare poc’anzi la normativa europea pone in capo ai titolari e responsabili del trattamento dei dati numerosi adempimenti, fra i quali assume notevole rilievo l’adozione di “misure tecniche e organizzative adeguate per garantire un livello di sicurezza adeguato al rischio”.

Così infatti dispone l’art. 32 del GDPR cercando di guidare la scelta di tale misure in base al principio di adeguatezza, nonché “tenendo conto dello stato dell’arte e dei costi di attuazione, nonché della natura, dell’oggetto, del contesto e delle finalità del trattamento, come anche del rischio di varia probabilità e gravità per i diritti ed anche le libertà delle persone fisiche”.

Essendo tali ultime formule pressoché generali, l’esigenza attuale risulta quella di fornire ai titolari e ai responsabili del trattamento degli strumenti concreti per individuare e scegliere idonee misure di sicurezza ed essere in grado di dimostrane la pratica adozione.[21]

Nel classificare invero le misure di sicurezza adottabili il GDPR opera un riferimento a due categorie di misure: quelle tecniche e quelle organizzative, diversamente dalla letteratura del settore[22] che invece distingue in: misure volte a garantire la sicurezza organizzativa (quali procedure di gestione di data breaches), quelle relative alla sicurezza logica e tecnologica (quali sistemi di autenticazione, antimalware, firewall, monitoraggi, scansioni delle vulnerabilità), e quelle relative alla sicurezza fisica (si pensi alla sicurezza degli edifici e degli archivi, al controllo degli accessi ed alla sicurezza ambientale). L’obiettivo di tutte le anzidette misure sarà comunque quello di assicurare la riservatezza, l’integrità, la disponibilità e la resilienza dei sistemi e dei servizi informativi.

Con l’obiettivo di agevolare la specifica scelta delle misure di sicurezza concretamente adottabili da parte del titolare e del responsabile del trattamento soccorrono sul piano internazionale le c.d. normative ISO, ossia norme tecniche sviluppate dalla International Organization for Standardization riportanti linee guida che un determinato soggetto dovrà andare a rispettare per l’ottenimento di una certificazione valida sul piano internazionale, attestante la conformità del soggetto stesso (persona fisica, ente pubblico o privato) a specifici parametri di valutazione.

Fra la molteplici norme ISO, si può qui porre in evidenza la ISO 27001 quale standard internazionale per la sicurezza delle informazioni, creata al fine di definire i requisiti atti a stabilire, implementare, mantenere e migliorare un sistema di gestione della sicurezza delle informazioni. [23]

Nei suoi contenuti presenta infatti un insieme di best practices, utili per sviluppare ed accrescere la capacità delle organizzazioni di gestire i rischi legati alla protezione dei dati, la ISO 27001 è invero molto specifica nel raccogliere, nel suo cosiddetto annex A, un vero e proprio catalogo di misure da adottare per contrastare nonché mitigare i rischi di perdita, modifica, divulgazione non autorizzata od accesso ai dati personali trattati.

Non sarebbe del tutto errato pensare quindi alla normativa GDPR e alla ISO 27001 alla stregua di un sistema integrato in ambito di sicurezza dei dati, d’altronde è lo stesso Considerando 100 del GDPR ad incoraggiare “l’istituzione di meccanismi di certificazione” che possano consentire di valutare il livello di protezione dei dati prodotti e dei servizi.

Ed ancora, è l’art. 24, comma 3 del GDPR a specificare come l’adesione ai codici di condotta ed alle certificazioni approvate, proprio come la ISO 27001, possa essere considerata come un elemento dimostrativo circa la conformità ed il rispetto degli obblighi del titolare del trattamento, in ossequio allo stesso principio di accountability.

Purtuttavia pare ovvio sottolineare come la garanzia di una certificazione non reciderà mai del tutto il rischio di verificazione di eventi dannosi relativi alla sicurezza dei dati, come peraltro si constaterà a seguire in ambito sanitario, ma al massimo andrà ad attenuarne le possibilità ed eventualità di accadimento e, conseguentemente, le relative responsabilità per tutti coloro che trattano i dati e le informazioni.

Condizioni di liceità del trattamento in ambito sanitario

Rimane tuttora da chiarire cosa si debba intendere con la precisa locuzione “trattamento dei dati”, di qui la definizione fornita dall’art. 4 del GDPR: “Qualsiasi operazione o insieme di operazioni, compiute con o senza l’ausilio di processi automatizzati ed applicate a dati personali o insiemi di dati personali, come la raccolta, la registrazione, l’organizzazione, la strutturazione, la conservazione, l’adattamento o la modifica, l’estrazione, la consultazione, l’uso, la comunicazione mediante trasmissione, diffusione o qualsiasi altra forma di messa a disposizione, il raffronto o l’interconnessione, la limitazione, ed altresì la cancellazione o la distruzione”.

Si può evidenziare peraltro come una operazione di trattamento si articoli in differenti fasi: una preliminare (raccolta e registrazione), una di elaborazione (selezione, impiego), una di circolazione (o diffusione), ed infine una residuale (conservazione, cancellazione).

Si vuole sottolineare come l’art. 9 del GDPR ponga un divieto generale al trattamento di intere categorie particolari di dati, fra cui figurano proprio i dati relativi alla salute: “È vietato trattare dati personali che rivelino l’origine razziale o etnica, le opinioni politiche, le convinzioni religiose o filosofiche, o l’appartenenza sindacale, nonché trattare dati genetici, dati biometrici intesi ad identificare in modo univoco una persona fisica, dati relativi alla salute o alla vita sessuale o all’orientamento sessuale della persona”.

Tuttavia tale divieto non è certo assoluto, in quanto in presenza di tutta una serie di condizioni di liceità, espressamente elencate dallo stesso testo normativo, tale preclusione non opera.

Per ciò che ivi interessa, il trattamento dei dati sanitari sarà considerato lecito laddove avvenga: per finalità di medicina preventiva, diagnosi, assistenza o terapia sanitaria o sociale (cosiddetta “finalità di cura”); per motivi di interesse pubblico nel settore della sanità pubblica (si pensi alla gestione di emergenze sanitarie nazionali, od alla protezione da gravi minacce per la salute a carattere transfrontaliero); ed ancora a fini di archiviazione nel pubblico interesse, di ricerca scientifica, storica o a fini statistici.

Vale la pena soffermarsi su come di fatto il GDPR superi così la precedente cornice normativa “consensocentrica” (propria del d.lgs. 196/2003, Codice privacy): diversamente dal passato infatti, non dovrà più esser richiesto il consenso del paziente per il trattamento di dati in ambito sanitario, purché si tratti di dati specificatamente necessari alle “finalità di cura” previste dal Regolamento Ue (prevenzione, diagnosi etc.) e che le relative attività siano effettuate da un professionista sanitario soggetto al segreto professionale.

Così, per esemplificare, persegue una finalità di cura l’infermiere che effettua una valutazione dei parametri vitali di un paziente al momento dell’accesso in pronto soccorso, come anche il cardiologo che raccoglie l’anamnesi necessaria alla corretta refertazione di un elettrocardiogramma; lo specialista che annota i dati biometrici del paziente in vista di un intervento chirurgico, come pure, in senso ampio, un direttore sanitario di una struttura pubblica che procede alla archiviazione di dati per studi statistici finalizzati tutela della salute collettiva.[24]

Ovvio è, ma vale la pena specificarlo, che non si deve qui confondere il consenso prestato al trattamento dei dati sanitari, col consenso ai trattamenti sanitari stessi: è quest’ultimo infatti a costituire il presupposto di legittimità dell’operato medico, andando ad “assorbire” il primo consenso, che non risulta più pertanto necessario.

D’altronde un professionista sanitario dovrà necessariamente venire a conoscenza di tutta una serie di dati identificativi e clinici (anamnesi, farmaci assunti etc.) per l’esecuzione di un trattamento sanitario, ed egli stesso, d’altra parte, nel trattare il paziente andrà a generare tutta un’altra serie di dati (referti, lastre etc.), dal momento poi che la semplice raccolta e consultazione di dati ne costituisce per definizione un trattamento, per un medico risulterà inevitabile, nello svolgimento delle sue funzioni, trattare costantemente i dati personali dei pazienti.

Si segnali ancora come ai trattamenti “per finalità di cura” siano comunque equiparati anche i trattamenti operati tramite applicazioni mediche, quando la finalità perseguita è quella di fornire cura al paziente, tramite un servizio di telemedicina, telesorveglianza o telemonitoraggio.

È evidente inoltre come tale dispensa dall’ottenimento del consenso non opererà laddove i trattamenti dei dati dei pazienti avvengano per finalità diverse da quelle strettamente di cura (si pensi a fini promozionali, commerciali o di fidelizzazione della clientela).

Residuano ad ogni modo alcuni casi in cui i dati sanitari possono essere trattati esclusivamente con il consenso della persona interessata quali: come si diceva nel primo capitolo, la possibilità di accesso al FSE (fascicolo sanitario elettronico), l’adesione a servizi di refertazione online, oppure l’utilizzo di apps mediche, quando il trattare i dati del paziente afferisce, solo in senso lato, alla cura di quest’ultimo, ma non è ad essa strettamente necessario (si pensi ad una applicazione che fornisce indicazioni su come migliorare la qualità del sonno), in tal caso il titolare del trattamento dovrà trattare i dati previa acquisizione del consenso dell’utente interessato.

Si può concludere evidenziando come l’approvazione del GDPR abbia indubbiamente contribuito a richiamare l’attenzione degli operatori sanitari sui temi della privacy e della protezione dei dati, in quanto strettamente connessi ai profili della sicurezza delle cure e di dignità del paziente. Come evidenziato infatti dal Garante, nella sua relazione annuale al Parlamento dell’anno 2018,[25] eventuali carenze in ambito di sicurezza dei dati personali possono avere effetti oltremodo deleteri negli stessi processi di erogazione dei trattamenti medici, rappresentando causa di disfunzioni, rallentamenti ed errori sanitari, fonti di potenziale responsabilità della struttura sanitaria, obbligata così a risarcirne i danni conseguenti.

L’obbiettivo di questi due preliminari capitoli voleva essere il presentare la digitalizzazione della sanità quale occasione senza precedenti di sviluppo ed innovazione, da dover senza dubbio promuovere per una sempre maggiore efficienza ed universalità delle cure, e per una migliore programmazione della spesa sanitaria. Tuttavia suddetta digital health dovrà realizzarsi all’interno di un progetto di politiche pubbliche organico e lungimirante di governance sanitaria, che promuova una condivisione selettiva dei dati sanitari, con le dovute cautele, al fine di minimizzarne i rischi cibernetici e le conseguenti possibili lesioni alla sfera personale della riservatezza e della dignità dei pazienti.[26]

La sanità digitale, pur rappresentando un’occasione di sviluppo e innovazione, espone inevitabilmente a rischi di compromissione dei sistemi informativi e alla minaccia crescente della cybercriminalità. Proprio a questo tema sarà dedicato il prossimo articolo della serie, che introdurrà la rivoluzione digitale e l’innovazione criminale, approfondendo le nuove forme di criminalità tecnologica.

Per approfondire, invitiamo a leggere il white paper gratuito di Maria Vittoria Zucca dal titolo La cybercriminalità nel settore sanitario: anamnesi, diagnosi e prognosi di una ‘patologia’ informatica”.

Fonti:

[1] A. Salvadori, “Deontologia e tutela 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. 9-10.

[2] ANITEC-ASSINFORM (Associazione italiana per l’Information and Communication Technology), Una data strategy per la Sanità italiana, a cura del gruppo di lavoro Digital Transformation in Sanità di Anitec-Assinform, Maggio 2022, p. 20.

[3] Intervento di A. Soro, ex-presidente dell’Autorità Garante per la protezione dei dati personali, “Tracciamento contagi coronavirus, ecco i criteri da seguire”, in Agenda Digitale, 29 Marzo 2020.

[4] L’immagine della scala delle durezze, diffusamente ripresa nella dottrina che si è occupata di privacy, si deve a Stefano Rodotà. Cfr. S. Rodotà, “Persona, riservatezza, identità. Prime note sistematiche sulla protezione dei dati personali”, in Rivista critica del diritto privato, anno XV, 1997, pp. 583-609.

[5] F. Di Ciommo, “Il trattamento dei dati sanitari tra interessi individuali e collettivi”, in R. Pardolesi (a cura di), La privacy sanitaria, vol. II, Giuffrè editore, Milano, 2003, vol. II, p. 239.

[6] Regolamento (Ue) 2016/679 del Parlamento e del Consiglio, relativo alla “protezione delle persone fisiche con riguardo al trattamento dei dati personali, nonché alla libera circolazione di tali dati”, del 27 Aprile 2016, che abroga la Direttiva 95/46/CE (Regolamento generale sulla protezione dei dati), per il testo normativo nella sua completezza si rimanda al sito internet: eur-lex.europa.eu/legal-content/IT/TXT/HTML/?uri=CELEX:32016R0679.

[7] Decreto legislativo 30 Giugno 2003, n. 196, recante il “Codice in materia di protezione dei dati personali”, integrato con le modifiche introdotte dal decreto legislativo 10 Agosto 2018, n. 101, recante “Disposizioni per l’adeguamento della normativa nazionale alle disposizioni del regolamento (Ue ) 2017/679 del Parlamento e del Consiglio, relativo alla protezione delle persone fisiche con riguardo al trattamento dei dati personali.

[8] Intervento di P. Stanzione, Presidente dell’Autorità garante per la protezione dei dati personali, “Sicurezza del dato sanitario e condivisione”, in Panorama, 18 Febbraio 2022.

[9] Il documento Indicazioni nazionali per l’erogazione di prestazioni di telemedicina è stato approvato dalla Cabina di regia del NSIS nella seduta del 28 ottobre 2020 ed è stato adottato con Accordo in Conferenza Stato Regioni del 17 dicembre 2020 (Repertorio atti n.215/CSR).

[10] NETPATROL, op. cit. supra a nota 17, p. 8.

[11] G. D’Acquisto, M. Naldi, Big Data e Privacy by Design. Anonimizzazione, Pseudonimizzazione e Sicurezza, Giappichelli Editore, Torino, 2017.

[12] A. Antonilli, op. cit. supra a nota 3, p. 92.

[13] Per “titolare del trattamento” si rimandi all’art 4 del GDPR: “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 […]”.

[14] P. Perri (intervento), durante il Webinar “Conoscere e prevenire gli attacchi cyber in sanità”, tenutosi in data 30 giugno 2021.

[15] Per “interessato” si intenda la persona fisica alla quale si riferisce il dato personale.

[16] D. Poletti, “Comprendere il Reg. UE 2016/679: Un’introduzione”, in A. Mantelero, D. Poletti (a cura di), Regolare la tecnologia: il Reg. UE 2016/679 e la protezione dei dati personali. Un dialogo fra Italia e Spagna, Pisa University Press, 2018, pp. 9-19.

[17] A. Cortesi, “L’art. 25 del GDPR: dalla privacy by default al principio di minimizzazione o necessità nel trattamento dei dati personali”, in Interlex: rivista di diritto, tecnologia, informazione, 2017.

[18] NETPATROL, op. cit. supra a nota 17, p. 9.

[19] Per “responsabile del trattamento” si rimanda all’art. 4 del GDPR: “la persona fisica o giuridica, l’autorità pubblica, il servizio o altro organismo che tratta dati personali per conto del titolare del trattamento.”

[20] “Linee guida sui responsabili della protezione dei dati”, WP243 rev. 01, adottate dal Gruppo di lavoro articolo 29 in materia di protezione dei dati personali, versione emendata ed adottata il 5 aprile 2017.

[21] R. Riccio, “Le misure di sicurezza tra GDPR e ISO 27001: due normative a confronto e i possibili scenari prospettabili”, in Cyberlaws: free legal database and blog, 9 Gennaio 2019.

[22] G. Butti, A. Piamonte, GDPR: nuova privacy. La conformità su misura, Iter editore, Milano, 2017.

[23] ISO/IESC 27001: 2013, “Information technology – Security techniques – Information Security – Managements systems – Requirements”.

[24] G. Chiarini, “Privacy: come cambia il dato normativo”, in E-Health: innovazione e tecnologia in ospedale, vol. 72, 2019, pp. 66-69.

[25] La Relazione del Garante per la protezione dei dati sanitari al Parlamento del 2018 è reperibile qui.

[26] P. Stanzione, intervento cit. supra, a nota 32.

Profilo Autore

Maria Vittoria Zucca, laureata con lode in Giurisprudenza presso l’università degli Studi di Trento, è attualmente dottoranda nel Programma di Dottorato di Interesse Nazionale in Cybersecurity, con istituzione capofila la Scuola IMT Alti Studi di Lucca, ed è affiliata alla Scuola Superiore Sant’Anna, presso l’Istituto Dirpolis (Diritto, Politica e Sviluppo).
La sua attività di ricerca si concentra sulla prevenzione, l’indagine ed il contrasto della criminalità informatica, includendo le discipline del diritto penale dell’informatica e della criminologia digitale. Su questi temi è autrice di diverse pubblicazioni scientifiche e partecipa regolarmente a conferenze nazionali e internazionali.

Condividi sui Social Network:

https://www.ictsecuritymagazine.com/articoli/dati-sanitari/