C’è una verità scomoda che chiunque abbia mai operato in un SOC durante un incidente reale conosce bene: nessun corso, nessuna certificazione, nessuna slide può replicare la pressione di un attacco in corso. La differenza tra sapere e saper fare, in cybersecurity, si manifesta esattamente nel momento peggiore, quando i sistemi smettono di rispondere, i log sono incompleti, le comunicazioni interne si inceppano e il CISO chiede aggiornamenti ogni cinque minuti.

La formazione tradizionale, quella basata su aule, manuali e quiz di verifica, ha un merito innegabile: trasferisce conoscenza. Ma la conoscenza da sola non basta. Costruire un piano di risposta agli incidenti è diverso dall’eseguirlo sotto pressione. Leggere un playbook è cosa diversa dal seguirlo quando metà del team è in videoconferenza di crisi e l’altra metà sta ancora cercando di capire il vettore iniziale di compromissione.

È da questa consapevolezza che nasce il paradigma della formazione immersiva, che nel 2026 si è pienamente affermato: un approccio che non si limita a insegnare la teoria della risposta agli incidenti, ma simula le condizioni in cui quella risposta deve avvenire. Cyber range, esercitazioni tabletop avanzate, ambienti live-fire a scala nazionale sono strumenti che stanno ridisegnando il modo in cui le organizzazioni, i team SOC e gli incident responder si preparano all’evento che, prima o poi, arriverà. Come abbiamo già analizzato, nel 2026 la simulazione come strumento formativo ha fatto un salto qualitativo netto.

Cosa si intende per cyber range: architettura di un campo di addestramento digitale

Un cyber range è, nella sua essenza, un ambiente virtualizzato o ibrido che riproduce fedelmente infrastrutture IT e OT reali, tra cui reti aziendali, sistemi SCADA, ambienti cloud e dispositivi endpoint, all’interno del quale è possibile lanciare e subire attacchi senza alcun rischio per i sistemi di produzione.

La distinzione tra un cyber range e un semplice laboratorio di sicurezza sta nella complessità e nella fedeltà della simulazione. Un laboratorio può includere alcune macchine virtuali per esercitarsi su specifiche tecniche. Un cyber range replica la stratificazione di una vera infrastruttura critica, inclusi gli errori di configurazione, le interdipendenze tra sistemi e i limiti di visibilità tipici di una rete reale, e vi inserisce un team che deve operare esattamente come farebbe di fronte a un incidente vero.

I cyber range più evoluti integrano oggi diversi livelli di complessità: scenari tecnici che testano le capacità di rilevamento, contenimento e analisi forense; livelli strategici che coinvolgono decision maker chiamati a valutare l’impatto operativo e le opzioni di risposta; dimensioni legali e di comunicazione, perché un incidente reale genera sempre la necessità di notificare le autorità, gestire la comunicazione pubblica e valutare le implicazioni normative.

Questa architettura multi-livello è esattamente ciò che distingue la formazione immersiva da qualsiasi altra forma di preparazione: non allena singole competenze tecniche, ma la capacità del team di funzionare come sistema integrato sotto pressione.

Il panorama europeo: dalle esercitazioni nazionali ai grandi esercizi multinazionali

L’Europa dispone oggi di un ecosistema di esercitazioni cyber tra i più strutturati al mondo, con due pilastri che meritano attenzione particolare.

Cyber Europe: l’esercitazione pan-europea di ENISA

Organizzata dall’Agenzia dell’Unione Europea per la Cybersicurezza (ENISA) con cadenza biennale dal 2010, Cyber Europe è la più grande e complessa esercitazione di gestione delle crisi informatiche a livello europeo. La serie conta a oggi sette edizioni completate: Cyber Europe 2026 sarà l’ottava, pianificata per giugno 2026, con l’obiettivo di rafforzare la preparedness cyber delle infrastrutture critiche dell’UE. Quest’anno l’esercitazione si concentrerà sul settore dei trasporti, in particolare sui sottosettori ferroviario e marittimo identificati come ad alta criticità dalla NIS2.

La scelta del settore non è casuale. Secondo i dati analizzati nell’ultimo ENISA Threat Landscape, i trasporti rappresentano il secondo settore più colpito nel 2024, con l’11% del totale degli incidenti cyber e il 15% di quelli diretti verso l’UE. Il rapporto ENISA NIS360 2024 segnala inoltre che il settore marittimo si trova nella cosiddetta risk zone di maturità-criticità, mentre quello ferroviario ne è al limite: due settori con elevata criticità e margini significativi di miglioramento della postura cyber.

L’edizione precedente, Cyber Europe 2024 (settima della serie), si era svolta il 19 e 20 giugno in formato ibrido, con coordinamento del Centro di Controllo delle Esercitazioni di Atene. L’esercitazione ha simulato attacchi su larga scala alle infrastrutture energetiche europee in un contesto di tensione geopolitica con una nazione fittizia, testando la capacità di risposta e gestione della crisi su scala continentale.

Secondo l’After Action Report ENISA, Cyber Europe 2024 ha coinvolto circa 5.000 partecipanti, tra cui oltre 1.000 esperti operativi, provenienti dai settori energetico, delle infrastrutture digitali, della pubblica amministrazione e dalle istituzioni UE, con la partecipazione di 30 agenzie nazionali di cybersicurezza degli Stati membri UE e dei Paesi EFTA.

L’ACN italiana era tra i partecipanti. Il Direttore Generale Bruno Frattasi ha sottolineato come le esercitazioni siano parte integrante della Strategia Nazionale di Cybersicurezza 2022-2026, che alla misura 38 prevede periodiche esercitazioni interministeriali anche in ambito Perimetro di sicurezza nazionale.

Locked Shields: il live-fire exercise più complesso al mondo

Se Cyber Europe è l’esercitazione della gestione delle crisi, Locked Shields, organizzato dal NATO Cooperative Cyber Defence Centre of Excellence (CCDCOE) di Tallinn, è la massima espressione del live-fire training: attacchi reali, in tempo reale, su infrastrutture virtualizzate di scala nazionale, gestite dal cyber range operato dalla CR14 Foundation.

L’edizione 2025, svoltasi dal 5 al 9 maggio, ha visto quasi 4.000 esperti cyber da 41 nazioni impegnati a difendere più di 8.000 sistemi virtuali contro oltre 8.000 attacchi sofisticati, con 17 Blue Team multinazionali formati per rafforzare la cooperazione tra paesi. L’esercitazione ha raggiunto questo livello di complessità partendo da soli quattro paesi e 60 partecipanti nel 2010: quindici anni di crescita continua, rispecchiata nella scala degli organizzatori, con 450 pianificatori e sviluppatori e più di 25 partner industriali coinvolti nell’edizione 2025.

Lo scenario ha incluso tensioni geopolitiche, violazioni della sovranità e attacchi informatici su larga scala. Tra le innovazioni introdotte nel 2025: infrastruttura cloud-based, scenari con tematiche di quantum computing nel track di strategic decision-making, narrative guidate da AI su tutti i track principali e un sistema di punteggio ridisegnato per premiare collaborazione e resilienza.

Locked Shields 2026, svoltasi a Tallinn dal 20 al 24 aprile, ha riunito circa 4.000 partecipanti da 41 nazioni, organizzati in 16 squadre multinazionali. Il primo posto è stato conquistato dal team congiunto Lettonia-Singapore, seguito a pari merito dalle squadre Francia-Svezia e Germania-Austria-Lussemburgo-Svizzera.

L’edizione ha ampliato il segmento cloud, integrato sistemi aggiuntivi e introdotto una nuova categoria di Critical Special Systems a supporto degli sforzi di difesa nazionale, mentre sul fronte della ricerca interna l’obiettivo era avvicinarsi ulteriormente a un Blue Team completamente automatizzato.

Ciò che rende Locked Shields unico non è solo la scala: è la filosofia. L’esercitazione simula un conflitto cyber realistico su larga scala, testando capacità tecniche, operative e strategiche insieme alle capacità decisionali sotto pressione, e incorpora dimensioni legali e di comunicazione per forgiare quella mentalità da situazione di crisi che costringe i team a pensare rapidamente, adattarsi a minacce impreviste e collaborare con strutture di altri paesi.

Il panorama italiano: tra eccellenza pubblica e offerta privata

L’Italia dispone di un ecosistema di formazione immersiva articolato su tre livelli: quello istituzionale (con ACN e strutture universitarie), quello industriale (con i grandi player del settore difesa e cybersecurity) e quello emergente delle PMI e delle accademie specializzate.

Sul versante istituzionale, Cyber 4.0, il Centro di Competenza nazionale ad alta specializzazione per la cyber security con sede a Roma, include tra le proprie attività corsi erogati attraverso l’utilizzo di cyber range e strumenti di formazione immersiva, capaci di generare scenari complessi di cyber warfare entro cui eseguire sessioni pratiche. Il Centro è partner di Leonardo Cyber Academy nell’organizzazione di Cyber Shield, una competizione immersiva sviluppata sulle piattaforme di cyber range di Leonardo che simula le attività di analisi e gestione di un incidente di cybersecurity reale in formato a squadre con percorsi a difficoltà crescente.

HWG Sababa, tra i principali managed security provider italiani, premiata con cinque riconoscimenti ai Global InfoSec Awards 2026 durante la RSAC Conference, ha scelto un approccio non convenzionale alla formazione con il Cyber Bus: portare la formazione immersiva fuori dalle aule tradizionali, direttamente nei luoghi in cui la sicurezza digitale è realmente necessaria, tra cui aziende, scuole e pubbliche amministrazioni. Il metodo formativo si fonda su simulazioni pratiche, scenari realistici e momenti di confronto che pongono le persone al centro dell’interazione.

Sul versante globale dei cyber range as-a-service, Cloud Range ha ottenuto il riconoscimento Gold nella categoria Cyber Readiness and Validation dei 2026 Cybersecurity Excellence Awards. La piattaforma consente alle organizzazioni di misurare le capacità di team, processi, tecnologie e sistemi AI in condizioni che replicano un attacco reale, attraverso ambienti live-fire che coprono IT, OT/ICS, cloud e infrastrutture ibride.

IBM X-Force Cyber Range, attivo dal 2016 con oltre 17.000 leader aziendali formati, propone simulazioni gamificate che affrontano competenze tecniche, di leadership e di comunicazione per team di sicurezza, dirigenti e consigli di amministrazione, con facility fisiche a Cambridge (Massachusetts), Washington DC, Ottawa (in partnership con l’Università di Ottawa) e Bangalore.

Il programma è progressivamente stato esteso, con l’apertura nel marzo 2024 di un range dedicato alle agenzie federali e alle infrastrutture critiche americane, affiancando i format immersivi fissi con esperienze virtuali e mobile.

I modelli di esercitazione: una tassonomia operativa

La formazione immersiva non è un format unico. Esiste una progressione logica di modelli, ciascuno adatto a obiettivi e livelli di maturità diversi.

Tabletop Exercise (TTX). È il modello più accessibile: una sessione facilitata in cui i partecipanti, tra cui dirigenti, responsabili IT, legali e comunicazione, discutono verbalmente come risponderebbero a un incidente presentato dallo scenario. Non richiede infrastrutture tecniche, ma è straordinariamente efficace per identificare lacune nei processi decisionali, nella catena di comando e nei flussi di comunicazione. Il suo limite strutturale è che simula le discussioni, non le azioni.

Functional Exercise. Un gradino sopra: i team eseguono le proprie funzioni reali in risposta a uno scenario simulato, attivando procedure operative, comunicando con le autorità e coordinando la risposta. Non si toccano i sistemi reali, ma si esercitano i comportamenti organizzativi, i processi di escalation e le interfacce con i soggetti esterni, incluse le notifiche alle autorità competenti.

Live-fire Exercise su cyber range. Il livello più avanzato: attacchi reali contro infrastrutture virtualizzate, con team che rispondono in tempo reale. Qui si testano le competenze tecniche vere, dal rilevamento di intrusioni all’analisi forense, dal contenimento all’eradicazione, in condizioni di pressione autentica. È il formato adottato da Locked Shields, e la massima espressione di questo approccio formativo.

Red/Blue/Purple Team Exercise. Un modello che si integra con i cyber range: il Red Team (attaccante) testa le difese del Blue Team (difensore), mentre il Purple Team favorisce la condivisione delle conoscenze tra le due parti. La variante Purple è particolarmente utile per accelerare il miglioramento delle capacità di detection, riducendo il tempo che normalmente separa l’identificazione di una tecnica offensiva dalla sua integrazione nelle regole di rilevamento difensivo.

La scelta del modello dipende dalla maturità dell’organizzazione, dagli obiettivi formativi e dalle risorse disponibili. Un’organizzazione che non ha mai condotto un TTX non è pronta per un live-fire exercise su cyber range: i due strumenti non si escludono, ma si costruiscono l’uno sull’altro in una progressione logica.

Costi, benefici e il calcolo che le organizzazioni evitano di fare

Il tema dei costi è spesso usato come alibi per rimandare la formazione immersiva. Vale la pena affrontarlo con onestà.

L’implementazione di un cyber range proprietario, con hardware dedicato, software di orchestrazione e scenari sviluppati su misura, richiede investimenti significativi, nell’ordine delle centinaia di migliaia di euro per soluzioni enterprise complete. È una soglia che giustifica la scelta di piattaforme cloud-based o di servizi gestiti, dove il costo si trasforma in un canone operativo accessibile anche a organizzazioni medie.

Il beneficio va misurato non solo in termini di competenze acquisite, ma di rischio ridotto. Secondo l’IBM Cost of a Data Breach Report 2025, che ha analizzato 600 organizzazioni colpite da violazioni tra marzo 2024 e febbraio 2025, il costo medio globale di un data breach è di 4,44 milioni di dollari, in calo del 9% rispetto ai 4,88 milioni del 2024 grazie a detection più rapida abilitata da strumenti AI.

Le organizzazioni che fanno uso estensivo di AI e automazione nella propria sicurezza hanno risparmiato in media 1,9 milioni di dollari per violazione e hanno ridotto il ciclo di vita della violazione di 80 giorni. Nello stesso rapporto, le organizzazioni che avevano costituito un team di incident response e testato regolarmente il proprio piano IR hanno registrato tempi di risposta più rapidi e costi inferiori rispetto a quelle che non avevano fatto né l’uno né l’altro.

Il nesso causale è diretto: formare i team in ambienti simulati equivale a testare i piani di risposta, e testare i piani di risposta riduce l’impatto economico degli incidenti reali.

C’è poi un beneficio meno quantificabile ma non meno reale: la coesione del team. Un esercizio di cyber range rivela come funziona davvero un team sotto pressione, chi guida, chi si blocca, dove si creano colli di bottiglia comunicativi. Questi elementi raramente emergono nei corsi tradizionali e sono invece determinanti nella gestione di un incidente reale.

L’integrazione con NIS2: dalla compliance alla preparedness operativa

Con il 2026, l’Italia è entrata nella fase decisiva dell’implementazione della Direttiva NIS2 (D.Lgs. 138/2024). Le implicazioni per la formazione sono dirette e cogenti, e il quadro normativo continua a evolversi.

Il 20 gennaio 2026, la Commissione europea ha proposto emendamenti mirati alla NIS2 per aumentare la chiarezza giuridica e semplificare la compliance, con misure che interesseranno circa 28.700 aziende, di cui 6.200 micro e piccole imprese. Il perimetro viene ampliato ai provider di wallet digitali e agli operatori di infrastrutture sottomarine. Il quadro normativo è dunque in movimento, e le organizzazioni già in percorso di adeguamento dovranno tenerne conto nell’aggiornamento dei propri piani.

Sul fronte italiano, tra le principali novità della Direttiva figura l’obbligo di formazione continua per i componenti degli organi di gestione: non un semplice corso una tantum, ma aggiornamenti a cadenza regolare che vedono i CdA coinvolti in prima linea. La sicurezza informatica cessa di essere un tema delegabile ai soli team tecnici e diventa elemento strutturale della governance aziendale.

Le Linee Guida NIS – Specifiche di base pubblicate dall’ACN il 4 settembre 2025 hanno individuato, all’Appendice C, undici documenti strategici che devono essere formalmente approvati dagli organi apicali, tra cui il piano di gestione del rischio, i piani di business continuity e disaster recovery, il piano di risposta agli incidenti e il piano di formazione in materia di sicurezza informatica.

Il 24 dicembre 2025 è stata pubblicata la Determinazione ACN n. 379907/2025, che ha aggiornato e consolidato le misure di sicurezza di base e i criteri per gli incidenti significativi sostituendo la precedente Determinazione n. 164179/2025 del 14 aprile 2025. Entrata in vigore il 15 gennaio 2026, da quella data è pienamente operativo l’obbligo di notifica degli incidenti significativi al CSIRT Italia.

L’obbligo di adozione delle misure di sicurezza è invece fissato a ottobre 2026, a 18 mesi dall’inserimento nell’elenco nazionale NIS. Da quella data l’ACN potrà avviare le attività ispettive, transitando dalla fase di accompagnamento alla fase di verifica vera e propria. Per una mappa completa delle scadenze e degli adempimenti tecnici, si rimanda alla nostra guida agli adempimenti NIS2.

Il punto critico è questo: NIS2 non prescrive un numero di ore di formazione né un tipo specifico di esercitazione. Prescrive la sostanza, ovvero che le organizzazioni siano effettivamente preparate a rilevare, gestire e notificare gli incidenti. La formazione immersiva è lo strumento più diretto per dimostrare, anche in sede ispettiva, che questa preparazione esiste e viene mantenuta nel tempo.

Come integrare la formazione immersiva nel piano annuale: un approccio pratico

La costruzione di un programma di formazione immersiva che risponda agli obblighi NIS2 e generi valore operativo reale segue una logica progressiva.

Il punto di partenza è la valutazione della maturità attuale: dove si trovano i gap più significativi, nella detection, nel contenimento, nella comunicazione interna, nel coordinamento con le autorità? Questa valutazione orienta la scelta del modello di esercitazione più adatto e alimenta direttamente il piano di formazione in materia di sicurezza informatica che le Linee Guida ACN richiedono tra i documenti da approvare formalmente dagli organi apicali.

Per le organizzazioni che si avvicinano per la prima volta alla formazione immersiva, un tabletop exercise ben progettato su uno scenario realistico, come un ransomware che blocca i sistemi operativi o un’esfiltrazione di dati via fornitore compromesso, è il punto di partenza ideale. Richiede poche risorse, coinvolge il management e produce una lista di gap da colmare che diventa la roadmap per i passi successivi.

Il passo successivo è un functional exercise che attivi i processi reali di incident response: notifica al CSIRT Italia nei termini previsti dalla Determinazione ACN 379907/2025, comunicazione alla direzione, coordinamento con il team legale. Questo livello rivela le criticità procedurali che il tabletop non può intercettare.

Solo a questo punto il live-fire exercise su cyber range ha senso: i team che lo affrontano hanno già validato i propri processi e possono concentrarsi sul testare le competenze tecniche in condizioni di pressione autentica.

La frequenza ideale è almeno un’esercitazione tabletop per semestre, un functional exercise annuale e un cyber range exercise ogni uno o due anni. Per le organizzazioni classificate come soggetti essenziali, che operano in settori ad alta criticità come energia, sanità, infrastrutture digitali e trasporti, la frequenza dovrebbe essere superiore, anche in ragione dei requisiti più stringenti previsti dalla Determinazione ACN.

Una riflessione finale: la preparazione come investimento culturale

C’è una tensione irrisolta nel modo in cui molte organizzazioni affrontano la formazione in cybersecurity: la trattano come un costo da minimizzare piuttosto che come un investimento da ottimizzare. Il risultato è che si acquistano certificazioni, si compilano moduli di compliance, si aggiornano i piani di incident response e poi questi piani restano nei cassetti fino al momento in cui qualcuno si trova davvero a dover gestire un incidente.

Nel 2026 il gap di competenze nella cybersecurity non si è chiuso: si è ampliato, perché la velocità di evoluzione delle minacce e delle tecnologie supera sistematicamente la velocità di formazione dei professionisti. I cyber range e la formazione immersiva non sono la risposta definitiva a questo problema strutturale, ma sono lo strumento più efficace per ridurre la distanza tra quello che i team sanno e quello che sono in grado di fare quando conta davvero.

La cultura della preparedness non si costruisce con una singola esercitazione annuale. Si costruisce con la ripetizione, con il feedback strutturato, con la capacità di apprendere dagli errori commessi in un ambiente sicuro invece che durante un incidente reale. Si costruisce, in altre parole, esattamente come si costruisce qualsiasi altra competenza operativa ad alto rischio: attraverso la pratica deliberata, sistematica e rigorosa.

I team che saranno davvero pronti all’incidente reale non sono quelli che hanno fatto il corso giusto. Sono quelli che hanno già vissuto, almeno una volta, la pressione di un attacco, anche se simulato, e sanno cosa fare quando arriva quello vero.

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

Mag 04, 2026 Redazione Attacchi, In evidenza, News, RSS, Vulnerabilità 0

---

CISA ha inserito Copy Fail tra le vulnerabilità sfruttate attivamente, segnalando che la falla viene già usata in attacchi reali per ottenere privilegi di root su sistemi Linux non aggiornati. Il bug, archiviato come CVE-2026-31431, riguarda il sottosistema crittografico del kernel Linux e consente a un utente locale non privilegiato di modificare in modo controllato la page cache di file leggibili, inclusi binari setuid-root come /usr/bin/su. In pratica, una presenza iniziale anche limitata sul sistema può essere trasformata in controllo completo della macchina.

Perché Copy Fail è così pericolosa

Copy Fail non è una vulnerabilità remota autonoma: per sfruttarla serve già la possibilità di eseguire codice sul sistema. Questo però non la rende meno grave. In molti scenari moderni, soprattutto in cloud, CI/CD, ambienti multi-tenant e Kubernetes, l’esecuzione di codice non privilegiato è una condizione frequente. Un job malevolo in una pipeline, un container compromesso, un accesso SSH a basso privilegio o una web shell possono diventare il punto di partenza per una escalation immediata a root.

La criticità è amplificata dalla portata del bug. Secondo CERT-EU, la vulnerabilità interessa le principali distribuzioni Linux con kernel costruiti a partire dal 2017, mentre Microsoft cita tra gli ambienti impattati Red Hat, SUSE, Ubuntu e AWS Linux, oltre a un impatto potenziale su larga parte dei workload cloud Linux e dei cluster Kubernetes.

Il cuore tecnico: AF_ALG, algif_aead e page cache

La vulnerabilità si trova in algif_aead, il componente che espone agli utenti lo stack crittografico AEAD del kernel attraverso socket AF_ALG. AF_ALG è un’interfaccia legittima: consente ai processi user space di usare primitive crittografiche implementate nel kernel. Il problema nasce da un’ottimizzazione introdotta nel 2017, pensata per rendere alcune operazioni più efficienti attraverso elaborazioni “in-place”, cioè usando gli stessi buffer come sorgente e destinazione.

Quell’ottimizzazione ha introdotto una condizione anomala nella gestione delle strutture scatterlist, usate dal kernel per descrivere aree di memoria non necessariamente contigue. In presenza di una specifica combinazione di operazioni, pagine appartenenti alla page cache possono finire dentro una destinazione considerata scrivibile. Il risultato è che un utente non privilegiato può ottenere una primitiva di scrittura limitata ma controllata: quattro byte alla volta dentro la cache di un file leggibile.

Perché quattro byte bastano per ottenere root

A prima vista, una scrittura di quattro byte può sembrare troppo piccola per avere conseguenze serie. In realtà, nel contesto giusto è sufficiente. L’exploit pubblico mostra come sia possibile colpire un binario setuid-root, cioè un eseguibile che, quando viene lanciato, opera con privilegi elevati. Se l’attaccante modifica in memoria alcune istruzioni del binario, può far sì che l’esecuzione produca una shell con privilegi di root.

La sequenza sfrutta la combinazione tra socket AF_ALG e la system call splice(). Quest’ultima consente di spostare dati tra file descriptor senza copiarli nello spazio utente, ed è proprio questa interazione con la page cache a rendere possibile l’attacco. Il payload non modifica il file su disco: altera la copia in memoria che il kernel usa per servire le letture successive. Quando il binario viene eseguito, il sistema legge la versione corrotta presente in cache e l’attaccante ottiene l’effetto desiderato.

Il dettaglio più insidioso: la modifica non resta sul disco

Uno degli aspetti più pericolosi di Copy Fail è la sua natura in-memory. La pagina corrotta non viene marcata come “dirty” per la scrittura su disco, quindi il file originale rimane apparentemente intatto. Questo significa che controlli basati su checksum del file system o strumenti che confrontano i binari su disco possono non rilevare la modifica.

In termini pratici, l’attaccante può alterare temporaneamente il comportamento di un binario privilegiato senza lasciare la classica traccia di una modifica persistente al file. La compromissione avviene nella memoria del kernel, ma l’effetto è immediatamente visibile a livello di sistema perché la page cache è ciò che viene effettivamente consultato quando il file viene letto o eseguito.

Container, cloud e CI/CD: gli ambienti più esposti

La falla è particolarmente rilevante negli ambienti containerizzati. La page cache è condivisa a livello host, quindi una primitiva di corruzione della cache può avere conseguenze oltre il confine apparente del container. Secondo l’analisi tecnica pubblicata dai ricercatori, lo stesso meccanismo può attraversare boundary container perché il target reale non è il file system isolato visto dal container, ma la page cache gestita dal kernel dell’host.

Questo rende Copy Fail molto pericolosa in scenari Kubernetes e CI/CD, dove è normale eseguire codice proveniente da repository, build, test automatici o workload temporanei. Un attaccante che riesce a introdurre codice in un runner di build o in un container con privilegi minimi può usare la vulnerabilità per scalare a root sull’host, con conseguenze dirette su segreti, immagini, pipeline, credenziali cloud e altri workload presenti nello stesso ambiente. Microsoft evidenzia proprio i rischi di container breakout, compromissione multi-tenant e movimento laterale.

L’exploit è affidabile e già pubblico

Il rischio operativo è aumentato dalla disponibilità di un proof-of-concept pubblico. I ricercatori di Theori/Xint hanno descritto un exploit Python molto compatto, indicato come capace di ottenere root su Ubuntu 24.04 LTS, Amazon Linux 2023, RHEL 10.1 e SUSE 16. BleepingComputer riporta che lo stesso script viene descritto come affidabile anche su distribuzioni Linux distribuite dal 2017 con kernel vulnerabile.

La presenza di un PoC funzionante cambia il profilo di rischio. Non serve più che gli attaccanti ricostruiscano il bug partendo dalla patch o dalla descrizione tecnica: possono partire da codice già disponibile e adattarlo ai propri contesti. L’inserimento nel catalogo KEV di CISA conferma che il problema non è più solo teorico o da laboratorio, ma riguarda attività osservate nel mondo reale.

Mitigazione: aggiornare il kernel e ridurre la superficie

La risposta prioritaria è l’aggiornamento del kernel alle versioni corrette fornite dalla propria distribuzione. CERT-EU ha indicato Copy Fail come vulnerabilità ad alta gravità e ha raccomandato di dare priorità agli ambienti più esposti, in particolare nodi Kubernetes e runner CI/CD che eseguono workload non fidati.

In attesa delle patch, le organizzazioni dovrebbero valutare mitigazioni di hardening sugli ambienti dove utenti o workload non privilegiati possono eseguire codice. L’obiettivo è ridurre la possibilità di usare AF_ALG e le primitive necessarie all’attacco, monitorare l’uso anomalo di socket AF_ALG e rafforzare il controllo dei workload che possono accedere a binari setuid. Sysdig suggerisce che la creazione sospetta di socket AF_ALG, soprattutto da processi non riconducibili a tool legittimi di cifratura o gestione crypto, può diventare un segnale utile per la detection runtime.

---

• AF_ALG, algif_aead, CI/CD Security, CISA KEV, container breakout, Copy Fail, CVE-2026-31431, kernel Linux vulnerability, Kubernetes security, Linux root exploit, page cache Linux, privilege escalation Linux, setuid root, vulnerabilità Linux

---

---

https://www.securityinfo.it/2026/05/04/cisa-avvisa-copy-fail-sfruttata-per-root-sui-sistemi-linux/?utm_source=rss&utm_medium=rss&utm_campaign=cisa-avvisa-copy-fail-sfruttata-per-root-sui-sistemi-linux

Trellix, fra i principali fornitori globali di soluzioni Extended Detection and Response, ha reso noto di aver subito un accesso non autorizzato a una porzione del proprio repository di codice sorgente. La nota, pubblicata sul sito istituzionale dell’azienda, è essenziale ma inequivocabile e arriva in una fase in cui la sicurezza dei vendor di cybersecurity è tornata al centro dell’agenda regolatoria europea.

Nel comunicato pubblicato sul sito ufficiale, Trellix dichiara di aver «recentemente identificato» l’intrusione, di aver coinvolto senza indugio esperti forensi esterni e di aver notificato l’incidente alle autorità di law enforcement. Allo stato attuale dell’investigazione, l’azienda afferma di non aver riscontrato alcuna evidenza che il processo di rilascio o di distribuzione del codice sia stato compromesso, né che il codice esposto sia stato sfruttato in attacchi attivi.

Trellix, cosa è stato comunicato e cosa resta opaco

Il testo diffuso da Trellix lascia in sospeso elementi che, in un’investigazione ancora aperta, sono dirimenti per misurare il perimetro reale del danno. Come riporta Security Affairs, l’azienda non ha precisato l’identità dei threat actor, la finestra temporale durante la quale è stato mantenuto l’accesso, né la natura esatta dei dati esposti. Il comunicato si limita ad anticipare che ulteriori dettagli verranno condivisi con la comunità di sicurezza al termine delle verifiche.

Sul piano industriale, il bersaglio è di assoluto rilievo. Nata a gennaio 2022 dalla fusione tra McAfee Enterprise e FireEye sotto Symphony Technology Group, Trellix offre soluzioni di endpoint security, email security, threat intelligence e incident response a imprese e amministrazioni in tutto il mondo. La superficie di esposizione potenziale, in termini di clienti finali integrati con i prodotti del gruppo, è dunque tutt’altro che marginale.

Perché un repository di codice sorgente è un bersaglio strategico

La compromissione di un repository di codice sorgente rappresenta uno degli scenari più sensibili nell’ecosistema della cybersecurity, e lo è a maggior ragione quando il bersaglio è un’azienda che produce software di sicurezza. Il codice è la blueprint tecnica del prodotto: chi vi accede non deve ipotizzare dove cercare le vulnerabilità, ma può leggerle direttamente nelle logiche implementative, nelle API interne, nelle credenziali eventualmente lasciate hard coded dai team di sviluppo e nelle euristiche di rilevamento utilizzate dai motori di protezione.

Anche in assenza di manomissioni rilevate sui binary distribuiti, l’esposizione del codice fornisce ad avversari sofisticati un valore di intelligence di lungo periodo: insight sulle tecniche di rilevamento, possibili percorsi di detection evasion, mappatura delle integrazioni con gli ambienti dei clienti. Il rischio non è quindi tanto immediato quanto strategico, in linea con i modus operandi tipicamente attribuiti agli attori nation state.

E’ necessario mette a fuoco tre vettori specifici. Il primo è la possibilità di sviluppare tecniche di detection evasion attraverso l’analisi della logica interna e delle euristiche del prodotto. Il secondo è l’accelerazione nella scoperta di debolezze e di edge case nei controlli difensivi. Il terzo è il valore di intelligence aggiuntivo per chi intenda colpire ambienti integrati con prodotti Trellix. Nessuno dei tre richiede, per concretizzarsi, una manomissione preventiva della build pipeline: la sola lettura del codice basta.

Una sequenza di precedenti, dal caso SolarWinds in poi

L’episodio si colloca in una sequenza che, negli ultimi anni, ha colpito alcuni dei vendor di sicurezza e dei fornitori tecnologici più rilevanti a livello globale. Come ricostruisce The Hacker News, incidenti analoghi hanno interessato in passato Microsoft, Okta e LastPass.

Nel marzo 2022 il gruppo Lapsus$ rivendicò l’esfiltrazione di codice sorgente di prodotti Microsoft, fra cui Bing, Cortana ed Exchange. Due anni più tardi, nel marzo 2024, Microsoft confermò con depositi 8-K presso la SEC che il gruppo Midnight Blizzard, attribuito al servizio di intelligence estera russo (SVR), aveva avuto accesso a parti dei propri repository di codice sorgente e ad alcuni sistemi interni, dopo l’iniziale compromissione di account di posta corporate. La memoria del settore richiama poi la violazione di SolarWinds del 2020, con l’inserimento del backdoor Sunburst nella build pipeline di Orion e la successiva distribuzione fraudolenta tramite canali ufficiali; l’attacco a Kaseya nel 2021; le esfiltrazioni subite da LastPass nel 2022; le ripetute violazioni di Okta tra 2022 e 2023.

La logica dell’attaccante è economica prima ancora che tecnica. Violare un fornitore che protegge centinaia o migliaia di clienti significa rendere potenzialmente accessibile l’intero perimetro a valle, con un rapporto sforzo-beneficio incomparabilmente più favorevole rispetto a una compromissione individuale. È la dinamica che ha reso strutturale il rischio di supply chain nel comparto cyber e che, sul versante regolatorio, alimenta la richiesta di garanzie più stringenti sui processi interni dei vendor. Su ICT Security Magazine, l’analisi degli attacchi alla supply chain software ha già documentato come, nel 2025 e nel 2026, il fenomeno abbia raggiunto dimensioni quantitative inedite, con centinaia di migliaia di pacchetti malevoli e operazioni state-sponsored di portata sistemica.

Le implicazioni per la secure software supply chain e il quadro normativo

Il caso Trellix rilancia la riflessione sulla secure software supply chain applicata agli stessi fornitori di sicurezza. Il Cyber Resilience Act dell’Unione europea, Regolamento (UE) 2024/2847, è entrato in vigore il 10 dicembre 2024. Gli obblighi di segnalazione delle vulnerabilità attivamente sfruttate e degli incidenti gravi si applicheranno dall’11 settembre 2026, mentre gli obblighi a regime, compresi quelli relativi al Software Bill of Materials, decorreranno dall’11 dicembre 2027. Per le violazioni più gravi è prevista una sanzione massima fino a 15 milioni di euro o al 2,5 per cento del fatturato annuo globale.

Il SBOM, disciplinato dall’articolo 13 e dall’Allegato I del Regolamento, dovrà essere prodotto in formato machine-readable e coprire almeno le dipendenze di primo livello, restando parte integrante della documentazione tecnica e fornito alle autorità di vigilanza su richiesta. Per un’analisi operativa su come implementare un SBOM conforme al CRA, ICT Security Magazine ha pubblicato una guida dedicata che ricostruisce workflow, formati (SPDX e CycloneDX), strumenti open source e integrazione nelle pipeline di vulnerability management.

In questo scenario, audit del Secure Development Lifecycle, code signing robusto, monitoraggio continuo dei repository, gestione delle identità privilegiate e segregazione degli ambienti di sviluppo cessano di rappresentare best practice opzionali per diventare requisiti minimi di credibilità di mercato. Il presupposto è semplice: la posture interna di un vendor di sicurezza non è un fatto privato, ma una componente diretta del rischio dei suoi clienti.

Per le organizzazioni che utilizzano soluzioni Trellix, e più in generale per chi si affida a piattaforme XDR e di endpoint protection, la postura prudenziale resta quella indicata da Integrity360: nessuna azione emergenziale è richiesta in questa fase, ma è essenziale applicare con costanza gli aggiornamenti rilasciati dal vendor, monitorare i comportamenti anomali negli ambienti integrati con i prodotti Trellix e mantenere un’architettura di sicurezza fondata sul principio della defense in depth.

Conclusione analitica

L’episodio Trellix non si misura sull’entità del codice esposto, al momento non quantificabile pubblicamente, ma sul segnale che invia al mercato. La comunicazione tempestiva, l’attivazione di forensi esterni e il coinvolgimento delle autorità descrivono un modello di gestione che, sul piano reputazionale, è ormai un’aspettativa più che un’eccezione. Resta tuttavia aperto il nodo sostanziale: se anche un vendor di sicurezza con risorse di livello enterprise può subire un accesso non autorizzato a un repository, la vera variabile competitiva non è più la presunta inviolabilità, ma la qualità dei processi di rilevamento, contenimento e trasparenza. È in questa cornice che andrà letta, nelle prossime settimane, la pubblicazione dei dettagli tecnici annunciata dall’azienda.

https://www.ictsecuritymagazine.com/notizie/trellix-violazione-codice/

C’è una domanda che i professionisti della sicurezza informatica si pongono con crescente frequenza: quando un attacco viene rivendicato da un gruppo che si autodefinisce “hacktivista”, chi sta davvero premendo il tasto? La risposta, nel 2026, è raramente univoca. E questa ambiguità non è accidentale: è progettuale.

Il panorama della conflittualità digitale si è trasformato radicalmente nell’arco di pochi anni. Non vi è più una netta separazione tra operazioni di Stato, criminalità organizzata e attivismo politico. Al loro posto si è affermato un modello ibrido, fluido, deliberatamente opaco: quello dei cyber mercenari e dei cosiddetti patriotic hackers, attori formalmente non statali ma funzionalmente allineati agli interessi di governi che li tollerano, li finanziano, li dirigono o, nella migliore delle ipotesi per chi subisce l’attacco, semplicemente non li fermano.

La zona grigia come dottrina

Per comprendere il fenomeno, occorre smettere di ragionare in categorie binarie. La distinzione tra “hacker di Stato” e “hacktivista indipendente” è ancora utile sul piano teorico, ma sempre meno praticabile sul piano operativo.

Il caso russo è il più documentato. La Chatham House, in un’analisi del marzo 2026, descrive l’ecosistema di cyber proxy russi come uno spettro di attori che operano con diversi gradi di direzione statale, sponsorizzazione o semplice allineamento con gli obiettivi del Cremlino. Alcuni proxy sono stati collegati direttamente ai servizi di intelligence come il GRU, altri sono sponsorizzati a distanza di sicurezza, altri ancora sono semplicemente tollerati perché le loro azioni coincidono con la linea strategica di Mosca. Il vantaggio di questa struttura è evidente: l’uso di proxy garantisce alla Russia la negazione plausibile, complica l’attribuzione degli attacchi e aiuta lo Stato, così come i singoli attori, a sfuggire alle sanzioni internazionali.

Non si tratta di una particolarità russa. Russia, Cina e Iran si avvalgono sistematicamente di organizzazioni hacktiviste come strumenti per mascherare la propria agenda strategica: destabilizzare gli Stati Uniti e altri Paesi occidentali, proiettare influenza regionale e imporre costi asimmetrici agli avversari. Secondo le stime di CACI, il 75-80% delle minacce informatiche che prendono di mira le nazioni occidentali è oggi riconducibile ad attori sponsorizzati dagli Stati, in particolare quelli sostenuti da Russia, Iran e Cina. Il restante 20-25%, pur apparentemente indipendente, è spesso guidato da motivazioni politiche strutturalmente allineate agli obiettivi delle potenze che ne beneficiano.

Come analizzato in un approfondimento su attori non statali pubblicato su queste pagine, la globalizzazione ha frammentato il quadro strategico tradizionale, favorendo l’ascesa di soggetti capaci di operare nel cyberspazio come proxy strategici, collocandosi in una zona grigia tra guerra informativa, conflitto armato e competizione geopolitica.

Killnet e il modello “Wagner Digitale”

Nessun gruppo incarna meglio questa metamorfosi di Killnet. Nato come collettivo di hacktivisti filo-russi nel contesto dell’invasione dell’Ucraina, si è reso noto per una serie di campagne Distributed Denial of Service (DDoS) contro infrastrutture di governi e aziende in Europa e negli Stati Uniti: tra queste, nel gennaio 2023, una serie di attacchi contro siti tedeschi in risposta alla decisione di Berlino di fornire carri armati all’Ucraina. Il fondatore del gruppo, noto con lo pseudonimo Killmilk, ha dichiarato di voler trasformare Killnet in una “private military hacking company”, riorganizzandola sotto il nome Black Skills e iniziando ad accettare commissioni da entità private e pubbliche.

Il modello dichiarato di ispirazione è rivelatore. Killmilk ha preso a riferimento la Wagner Private Military Company, i mercenari paramilitari di Evgeny Prigozhin, per costruire un equivalente digitale, con unità di HR, formazione e operazioni su larga scala. Come Wagner operava nelle zone grigie del conflitto armato convenzionale, Black Skills ambisce a operare nella zona grigia del conflitto digitale: mercenari per elezione, non per necessità ideologica.

Come ha sottolineato Flashpoint in più occasioni, Killnet è sempre rimasto un gruppo principalmente motivato finanziariamente, che ha sfruttato l’esposizione mediatica offerta dall’ecosistema mediatico filo-Cremlino per promuovere i propri servizi di DDoS-for-hire. Il nazionalismo era, almeno in parte, una strategia di marketing. Con la svolta mercenaria dichiarata, quella maschera è caduta. Ciò che rimane è un blueprint operativo che altri gruppi possono replicare.

La replicazione è già in atto. Nel marzo 2025 è emerso un nuovo collettivo, denominato IT Army of Russia, che comunica attraverso il forum cybercriminale Duty-Free e un canale Telegram con oltre 800 iscritti, pubblica presunte violazioni di siti ucraini, sottrae dati e recluta insider operativi nelle infrastrutture critiche ucraine. Le operazioni sono coordinate attraverso un bot Telegram che incoraggia gli utenti a fornire intelligence militare e a suggerire nuovi obiettivi. Il ciclo si ripete e si moltiplica.

L’IT Army of Ukraine: hacktivismo sanzionato dallo Stato

Sul fronte opposto si colloca un esperimento altrettanto rivoluzionario, e altrettanto problematico sul piano del diritto internazionale. L’IT Army of Ukraine è una forza cibernetica volontaria e crowdsourced, istituita il 26 febbraio 2022 e annunciata da Mykhailo Fedorov, Ministro della Trasformazione Digitale dell’Ucraina, attraverso Twitter. Il canale Telegram coordinato raggiunse rapidamente oltre 300.000 iscritti entro marzo 2022, tra professionisti IT, volontari amatoriali e osservatori internazionali, diventando la prima milizia digitale pubblicamente organizzata impiegata come componente formale della difesa nazionale in un conflitto armato maggiore.

Nel corso del 2022, l’IT Army ha condotto operazioni offensive contro i siti della Borsa di Mosca, Sberbank, il Ministero degli Esteri russo, Gazprombank e l’infrastruttura di rete di Loesk, utility elettrica che alimenta l’Oblast di Leningrado. Secondo ricercatori specializzati, la struttura pubblica dell’IT Army ha progressivamente ceduto spazio a un nucleo interno più ristretto, composto da personale dell’intelligence e della difesa ucraina, che ha guidato operazioni più sofisticate e mirate.

L’IT Army ha ispirato imitatori su entrambi i fronti. Gruppi filo-russi, tra cui NoName057(16), hanno adottato il modello di coordinamento crowdsourced in senso inverso, orchestrando campagne DDoS contro governi NATO, istituzioni finanziarie europee e operatori di infrastrutture critiche.

Nel luglio 2025, il collettivo NoName057(16) è stato oggetto dell’Operation Eastwood, coordinata da Europol ed Eurojust: l’operazione ha portato allo smantellamento di oltre 100 server, a due arresti in Francia e in Spagna, all’emissione di sette mandati d’arresto internazionali (sei dei quali dalla Germania contro cittadini russi) e a 24 perquisizioni condotte in Germania, Lettonia, Spagna, Italia, Cechia, Polonia e Francia. Cinque profili sono stati pubblicati sul sito EU Most Wanted. Il gruppo ha ripreso le operazioni già il giorno successivo, rivendicando nuovi attacchi contro siti governativi tedeschi.

Il caso dell’IT Army solleva questioni giuridiche irrisolte. Poiché il gruppo si dichiara indipendente dalle forze armate ucraine e i suoi volontari non indossano una divisa, non rientrano formalmente nella categoria di combattenti. Se tuttavia contribuiscono, anche marginalmente, allo sforzo bellico militare ucraino, diventano potenzialmente un obiettivo legittimo per le forze russe. La smilitarizzazione formale non equivale a neutralità operativa.

Iran: il modello Layered dell’ecosistema proxy

Mentre il conflitto russo-ucraino ha reso familiare il fenomeno dei cyber proxy, è nel contesto mediorientale che il modello ha raggiunto la sua espressione più sofisticata. L’Iran ha costruito un ecosistema informatico deliberatamente stratificato: attori Advanced Persistent Threat (APT) sponsorizzati dallo Stato, appartenenti al Corpo delle Guardie della Rivoluzione Islamica (IRGC) e al Ministero dell’Intelligence (MOIS), costituiscono il vertice operativo, affiancati da gruppi collegati all’IRGC nello strato intermedio, e da una base ampia di attori ideologicamente motivati al livello più basso. Questa architettura rispecchia la più ampia dottrina militare iraniana della “difesa avanzata”: la proiezione di potere attraverso proxy e asset deniabili, piuttosto che attraverso l’impiego diretto di forze regolari.

Il caso del gruppo CyberAv3ngers è paradigmatico. Al momento degli attacchi contro sistemi di controllo industriale nel settore idrico statunitense nel 2023, il gruppo si presentava come hacktivista ideologicamente motivato. Nel giro di un mese, il Dipartimento del Tesoro statunitense ha sanzionato sei funzionari dell’IRGC-CEC (Cyber-Electronic Command) per aver diretto le operazioni. Gli hacktivisti erano agenti statali fin dall’inizio.

Il pattern è stato confermato a scala più ampia dopo l’operazione militare congiunta USA-Israele del 28 febbraio 2026 contro l’Iran. Nel giro di ore, oltre 60 gruppi hacktivisti filo-iraniani si sono mobilitati, formando una struttura coordinata denominata “Electronic Operations Room”. Come documentato dal Threat Brief di Unit 42 di marzo 2026, un’analisi di DomainTools Investigations ha descritto le attività attribuite ai tre principali gruppi operativi iraniani, Homeland Justice, Karma/KarmaBelow80 e Handala Hack, come “un unico ecosistema di influenza informatica coordinata” allineato al MOIS, con persona che “funzionano come veneer operativi intercambiabili applicati a una capacità sottostante coerente”. Non tre gruppi distinti: una sola struttura con tre maschere.

Questa architettura distribuita ha dimostrato una resilienza notevole. Anche dopo che il quartier generale della Cyber Warfare dell’IRGC a Teheran è stato bombardato nel corso del conflitto, i proxy e gli hacktivisti filo-iraniani hanno continuato a operare con efficacia. La decentralizzazione non è un limite organizzativo: è una scelta dottrinale, in linea con la “difesa a mosaico”, che progetta la resilienza contro gli attacchi decapitanti attraverso la distribuzione strutturale delle capacità. Resecurity ha documentato la formazione dell’”Islamic Resilience Cyber Axis“, una coalizione di gruppi coordinati attraverso canali Telegram e forum del dark web, tra cui Cyber Islamic Resistance, Fatimion Cyber Team, Cyber Fattah, DieNet e Sylhet Gang.

Il caso Stryker: la guerra che entra in sala operatoria

L’11 marzo 2026, alle 3:30 del mattino (ora della costa est degli Stati Uniti), il gruppo Handala, persona hacktivista operata da Void Manticore, il principale strumento offensivo cibernetico del MOIS iraniano, ha colpito Stryker Corporation, colosso della tecnologia medicale con sede a Kalamazoo, Michigan. L’attacco non ha impiegato malware nel senso classico del termine: i threat actor hanno compromesso le credenziali amministrative dell’ambiente Microsoft Intune di Stryker e hanno sfruttato la funzione nativa di remote wipe della piattaforma per cancellare in remoto oltre 200.000 dispositivi, tra server, laptop e smartphone, in 79 Paesi, rendendo inutilizzabili gli endpoint nel giro di minuti. Migliaia di dipendenti hanno assistito in tempo reale alla cancellazione dei propri device aziendali e personali.

Come documentato da KrebsOnSecurity, Stryker ha confermato una “disruption globale della propria rete Microsoft” e ha avviato procedure di business continuity, isolando i sistemi e coinvolgendo il team di incident response Unit 42 di Palo Alto Networks, oltre all’FBI, alla CISA, al White House National Cyber Director e all’HHS. L’indagine ha successivamente identificato un file malevolo utilizzato per eseguire comandi nascondendo l’attività ai sistemi di rilevamento, confermato però come privo di capacità di propagazione interna o esterna.

L’impatto è stato immediato e concreto. Negli ospedali del Maryland, il sistema LIFENET di Stryker per la trasmissione di elettrocardiogrammi è risultato “non funzionale nella maggior parte dello Stato”, costringendo i clinici a ricorrere a consulto radio verbale. Alcune chirurgie sono state cancellate per indisponibilità degli impianti Stryker. Il Dipartimento di Giustizia statunitense ha confermato, in un affidavit contro gli hacker iraniani, che l’attacco “ha avuto un impatto diretto sui servizi di emergenza medica e sugli ospedali nel Maryland”. Stryker ha comunicato alla SEC che l’incidente ha avuto un impatto materiale sui risultati del primo trimestre 2026.

La motivazione dichiarata da Handala era geopolitica: l’attacco è stato presentato come ritorsione per un attacco missilistico statunitense su una scuola elementare iraniana, e come risposta alla percezione di Stryker come “azienda a radici sioniste”, in ragione dell’acquisizione, nel 2019, della società israeliana OrthoSpace. Stryker non produce armamenti, non opera nel settore della difesa e non ha alcun ruolo diretto nel conflitto. È nel mirino perché americana, perché opera in settori rilevanti per la tenuta sociale e perché colpirla produce effetti dimostrativi che travalicano il danno tecnico. Il bersaglio è simbolico quanto strategico.

Il problema dell’attribuzione: una crisi strutturale

Il nodo più critico dell’intero fenomeno è l’attribuzione. Non si tratta di una difficoltà tecnica destinata a essere risolta con strumenti migliori: è una crisi strutturale, resa tale per disegno.

L’elevata soglia giuridica necessaria per attribuire la condotta di attori non statali a uno Stato significa che Russia, Iran e altri beneficiari evadono spesso la responsabilità per le operazioni dei propri proxy nell’ambito dei tradizionali framework di responsabilità statale internazionale. Il diritto internazionale è stato costruito pensando agli Stati come attori unitari, con confini definiti di competenza e accountability. I cyber proxy lo sfruttano sistematicamente, operando in uno spazio giuridico che non prevede forme equivalenti a quelle previste per i mercenari convenzionali o i combattenti stranieri.

Sul piano tecnico, i gruppi utilizzano infrastrutture condivise, si scambiano strumenti, adottano le stesse tecniche degli attori criminali convenzionali e, soprattutto, rivendicano o negano selettivamente la paternità delle operazioni a seconda della convenienza strategica del momento. Come ha documentato Lawfare in un’analisi approfondita, i servizi di intelligence russi hanno creato proprie false persona hacktiviste, tra cui XakNet, Solntsepek e Cyber Army of Russia Reborn, per nascondere le proprie operazioni cibernetiche dirette dietro il velo dell’hacktivismo.

Il Global Cybersecurity Outlook 2026 del World Economic Forum ha rilevato che il 91% delle organizzazioni con più di 100.000 dipendenti ha modificato la propria strategia di cybersicurezza in risposta alla volatilità geopolitica, e che il 64% include oggi gli attacchi informatici con motivazione geopolitica, come la disruption di infrastrutture critiche o lo spionaggio, nella propria strategia complessiva di gestione del rischio.

Le aziende occidentali nel mirino geopolitico

Il caso Stryker non è isolato: è il caso più documentato di una tendenza strutturale. Le imprese private, anche quelle lontane dai settori tradizionalmente sensibili, sono diventate obiettivi geopolitici per ragioni che non hanno nulla a che fare con le loro vulnerabilità tecniche intrinseche o con il valore dei loro dati.

Come sottolinea il World Economic Forum, le industrie high-tech, anche quelle al di fuori della zona di conflitto attiva, sono nel mirino, poiché la distanza geografica non offre alcuna protezione. Bersagliare le organizzazioni private consente agli attori statali di indebolire i rivali indirettamente senza innescare un’immediata escalation politica: il costo del conflitto viene scaricato sul settore privato, mentre lo Stato mantiene la negazione plausibile.

Nel 2026, la distinzione tra sicurezza nazionale e sicurezza aziendale continua a erodersi. Le organizzazioni private giocano sempre più un ruolo nella difesa degli interessi nazionali, che lo vogliano o no. Le tensioni geopolitiche definiscono le decisioni di targeting, i tempi delle campagne e l’intensità operativa. Organizzazioni attive in settori o regioni sensibili, o semplicemente percepite come simbolicamente rappresentative di un Paese avversario, si trovano ad affrontare un rischio elevato sulla base del contesto geopolitico piuttosto che delle proprie azioni specifiche.

Questo implica una trasformazione profonda nel modo in cui le aziende devono concepire la propria esposizione al rischio. Come osserva il WEF, ogni Chief Information Security Officer (CISO) è diventato, di fatto, un attore geopolitico: non perché lo abbia scelto, ma perché il contesto lo ha reso tale.

Cosa fare: verso una resilienza consapevole

Di fronte a uno scenario così complesso, la risposta difensiva non può essere esclusivamente tecnica. Occorre integrare l’analisi geopolitica nel processo di risk management, un cambiamento di paradigma che va ben oltre l’aggiornamento dei sistemi di rilevamento.

Sul piano operativo, le raccomandazioni convergono su alcuni principi fondamentali. Il primo è comprendere la propria posizione nel panorama geopolitico globale: quali governi potrebbero avere interesse a colpire la propria organizzazione, in quale scenario e con quale obiettivo simbolico o strategico. Il secondo è adottare architetture zero-trust che non presuppongano l’integrità di alcuna componente della catena di fornitura, comprese le piattaforme di gestione dei dispositivi: il caso Stryker ha dimostrato che uno strumento legittimo di IT management può essere trasformato in un’arma. Il terzo è investire in threat intelligence contestualizzata, capace di distinguere l’opportunismo criminale dalle campagne state-aligned con logiche proprie. Il quarto è partecipare attivamente ai meccanismi di condivisione delle informazioni tra settori e tra Paesi.

Sul piano normativo, il lavoro non è meno urgente. Come conclude la Chatham House, le risposte tattiche dell’Occidente all’attività informatica dei proxy ostili devono essere sostituite da un approccio strategico che integri leve principali, amplificatori e politiche abilitanti di lungo periodo. Il diritto internazionale deve evolvere per includere la responsabilità degli Stati che tollerano i propri proxy digitali, analogamente a quanto già avviene per i mercenari convenzionali e i combattenti stranieri in zona di guerra.

Sul tema, vale la pena leggere l’analisi della guerra ibrida e difesa integrata NATO pubblicata su ICT Security Magazine, che delinea il quadro dottrinale entro cui si inserisce questo tipo di minacce e le risposte istituzionali in corso di definizione.

Conclusione: cyber mercenari, la guerra senza fronti

I cyber mercenari e gli hacktivisti allineati agli Stati non sono un’anomalia del paesaggio digitale contemporaneo. Sono il suo volto più coerente con la realtà geopolitica: rappresentano la risposta razionale di potenze che vogliono proiettare capacità offensive senza assumersi la responsabilità formale delle proprie azioni, in un dominio, il cyberspazio, che ancora non dispone di un diritto internazionale cogente per governarle.

Il confine tra guerra e pace, tra operazione militare e crimine informatico, tra attore statale e mercenario digitale, è diventato una zona di attrito permanente. In questo spazio operano Killnet e Black Skills, Handala e il suo ecosistema MOIS, IT Army of Russia e NoName057(16): non come fenomeni separati, ma come manifestazioni diverse di una stessa logica strategica, quella dell’ambiguità come arma.

Per le organizzazioni occidentali, la lezione è scomoda ma necessaria: in un conflitto ibrido, non esistono osservatori neutrali. Esistono bersagli che non lo sanno ancora. La consapevolezza di questa condizione è il primo passo, indispensabile anche se non sufficiente, verso una resilienza all’altezza della complessità del presente.

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

Apr 30, 2026 Redazione Attacchi, In evidenza, News, RSS 0

---

La compromissione della supply chain software continua a evolvere, e l’operazione “Mini Shai-Hulud” rappresenta uno dei casi più interessanti e pericolosi osservati negli ultimi mesi. L’analisi pubblicata da Wiz evidenzia come un numero limitato di pacchetti npm compromessi sia stato sufficiente per attivare una catena di infezione capace di propagarsi tra ambienti di sviluppo, pipeline CI/CD e repository GitHub, con un livello di automazione sempre più sofisticato. L’attacco è partito ieri, 29 aprile, ma ancora oggi sono stati identificati degli npm compromessi.

Ricordiamo che l’ecosistema SAP, e in particolare il Cloud Application Programming Model, rappresenta uno dei contesti più diffusi nelle aziende enterprise. Colpire questo layer significa entrare direttamente nei processi di sviluppo che alimentano applicazioni critiche di business.

L’ingresso nella supply chain: pacchetti legittimi, codice malevolo

L’attacco si basa su una tecnica ormai consolidata nel mondo npm: la pubblicazione di versioni “trojanizzate” di pacchetti legittimi. Nel caso specifico, alcuni moduli SAP sono stati modificati introducendo uno script di preinstallazione che viene eseguito automaticamente durante l’installazione delle dipendenze. Questo dettaglio è fondamentale. Il codice malevolo non viene eseguito dopo il deploy, ma nel momento stesso in cui lo sviluppatore installa le dipendenze; quindi, all’interno di ambienti fidati come workstation locali o pipeline automatizzate.

Lo script avvia un processo in più fasi. Inizialmente viene scaricato un runtime esterno, nel caso specifico Bun, utilizzato per eseguire un payload fortemente offuscato. Questo payload, di dimensioni superiori agli 11 MB, rappresenta il cuore dell’operazione: un framework completo per il furto di credenziali e la propagazione.

Il vero obiettivo: le credenziali degli sviluppatori

A differenza di molte campagne tradizionali, l’obiettivo principale non è l’esecuzione diretta di codice malevolo sui sistemi finali, ma la raccolta sistematica di credenziali. Il malware è progettato per estrarre token e chiavi da molteplici fonti: GitHub, npm, ambienti cloud come AWS, Azure e GCP, fino a Kubernetes e vari browser. Del resto, le credenziali rappresentano oggi la chiave di accesso più efficace per compromettere infrastrutture complesse, perché consentono di muoversi lateralmente senza attivare controlli di sicurezza tradizionali.

I dati raccolti vengono cifrati e inviati verso repository GitHub controllati dagli attaccanti. Un elemento particolarmente interessante è che spesso questi repository vengono creati utilizzando le credenziali delle stesse vittime, trasformando ogni account compromesso in un ulteriore nodo di distribuzione.

Il salto di qualità rispetto ad attacchi precedenti sta nella capacità di auto-propagazione. Il malware utilizza i token raccolti per modificare repository GitHub, inserire workflow malevoli e pubblicare nuove versioni compromesse dei pacchetti.

Questo comportamento avvicina Mini Shai-Hulud a un worm, capace di espandersi autonomamente all’interno dell’ecosistema software. In alcuni casi, il codice introduce configurazioni malevole anche negli strumenti di sviluppo, come file di configurazione per ambienti come Visual Studio Code, che attivano nuovamente il payload quando il repository viene aperto.

Il risultato è una persistenza difficile da individuare. Non si tratta solo di un’infezione temporanea, ma di una contaminazione che può riattivarsi nel tempo attraverso strumenti legittimi utilizzati quotidianamente dagli sviluppatori.

Un elemento apparentemente rassicurante è la durata limitata dell’esposizione. I pacchetti compromessi sono rimasti disponibili per poche ore prima di essere rimossi e sostituiti con versioni pulite. Tuttavia, questo non riduce il rischio. Al giorno d’oggi, le pipeline CI/CD scaricano automaticamente dipendenze aggiornate e anche una finestra temporale ridotta è sufficiente per introdurre codice malevolo in ambienti produttivi o di sviluppo, da cui l’attaccante può poi espandersi. Questo aspetto evidenzia una criticità strutturale: la velocità dei processi DevOps amplifica l’impatto delle compromissioni della supply chain, riducendo il tempo disponibile per intercettarle.

Continuità con le campagne Shai-Hulud precedenti

L’operazione si inserisce in una serie di campagne già osservate negli ultimi mesi, tutte riconducibili al nome Shai-Hulud. Le analisi indicano similitudini nelle tecniche e negli strumenti utilizzati, suggerendo una continuità operativa o almeno un riutilizzo di codice e metodologie.

Rispetto alle versioni precedenti, Mini Shai-Hulud introduce miglioramenti significativi, tra cui cifratura avanzata dei dati esfiltrati e nuove tecniche di persistenza. Inoltre, emerge un elemento particolarmente rilevante: l’uso di strumenti legati allo sviluppo assistito da AI come vettori di esecuzione, segnale di come anche questi ambienti stiano diventando parte della superficie di attacco.

---

---

---

https://www.securityinfo.it/2026/04/30/mini-shai-hulud-la-supply-chain-sap-colpita-da-un-simil-worm/?utm_source=rss&utm_medium=rss&utm_campaign=mini-shai-hulud-la-supply-chain-sap-colpita-da-un-simil-worm

Apr 29, 2026 Giancarlo Calzetta Approfondimenti, Attacchi, In evidenza, News, RSS, Scenario, Scenario, Tecnologia, Tecnologia 0

---

Stanno arrivando, ma non nascono già pronti. Stiamo parlando degli agenti AI progettati per compiere attacchi informatici. Sebbene si legga in giro che sono già in uso e sembri una tragedia, la realtà è che la tragedia deve ancora arrivare. Al momento gli attacchi basati su agenti AI sono all’inizio della loro carriera e vengono rintuzzati abbastanza facilmente. In futuro, però, non sarà così e allora sia la benvenuta una ricerca pubblicata da Cisco Talos Intelligence Group  che mostra come la stessa AI possa essere utilizzata per ribaltare completamente il paradigma difensivo, trasformando i sistemi vulnerabili in trappole intelligenti. Il concetto alla base è tanto semplice quanto interessante: utilizzare modelli generativi per creare honeypot capaci non solo di simulare vulnerabilità, ma di interagire dinamicamente con gli attaccanti, adattandosi al loro comportamento in tempo reale.

Dalla difesa passiva alla deception attiva

Gli honeypot non sono certo una novità. Da anni vengono utilizzati per attirare attaccanti e studiarne le tecniche, ma tradizionalmente si tratta di sistemi statici, limitati nella loro capacità di simulare ambienti reali. La ricerca di Talos introduce un cambio di paradigma: grazie all’AI, gli honeypot diventano sistemi dinamici in grado di mascherarsi come infrastrutture vulnerabili credibili e interagire con l’attaccante in modo realistico.

Il risultato è un livello di inganno molto più sofisticato. L’attaccante non si trova più davanti un sistema “finto” facilmente riconoscibile, ma un ambiente che reagisce, risponde e si evolve. L’architettura descritta da Talos si basa su tre componenti chiave, che insieme costruiscono un sistema di difesa completamente nuovo.

Il primo elemento è un listener di rete che accetta connessioni e simula la presenza di un servizio vulnerabile. Il secondo è una vulnerabilità “pilotata”, progettata per concedere accesso controllato all’attaccante e mantenerlo all’interno dell’ambiente di analisi. Il terzo, e più innovativo, è il layer di intelligenza artificiale, che interpreta le azioni dell’attaccante e genera risposte coerenti, mantenendo viva l’illusione.

Questo approccio consente di creare sistemi altamente scalabili. A differenza degli honeypot tradizionali, che richiedono configurazioni manuali complesse, quelli basati su AI possono essere distribuiti rapidamente e replicati su larga scala, adattandosi automaticamente ai diversi scenari di attacco.

Il bersaglio sono gli agenti AI malevoli

Uno degli aspetti più interessanti della ricerca riguarda il target di queste trappole: non tanto gli hacker umani, quanto gli agenti autonomi basati su modelli linguistici. Questi agenti, sempre più diffusi, sono progettati per automatizzare attività offensive come la scansione delle vulnerabilità, l’esecuzione di exploit e la raccolta di informazioni. Il problema è che operano con una velocità e una scala difficili da gestire con i sistemi di difesa tradizionali.

Gli honeypot AI-driven permettono invece di intercettare questi agenti, studiarne il comportamento e raccogliere intelligence in tempo reale, offrendo una visibilità senza precedenti su una nuova classe di minacce emergenti.

Il valore principale di questi sistemi non è, infatti, solo difensivo, ma soprattutto analitico. Interagendo con gli attaccanti, gli honeypot intelligenti consentono di raccogliere informazioni dettagliate sulle tecniche utilizzate, sugli strumenti impiegati e sulle logiche decisionali degli agenti AI.

Il rischio della “gamification” della difesa

L’adozione di AI anche lato difesa apre però scenari complessi. Se da un lato gli honeypot intelligenti consentono di ingannare gli attaccanti, dall’altro introducono una dinamica di escalation tecnologica. Gli attaccanti potrebbero a loro volta migliorare i propri agenti per riconoscere e aggirare queste trappole, dando vita a una sorta di “corsa agli armamenti” tra AI difensive e offensive.

Questo porta a un punto chiave: la sicurezza informatica sta evolvendo verso un modello in cui macchine attaccano macchine e altre macchine cercano di ingannarle. Per le organizzazioni, questo scenario implica un cambiamento profondo nell’approccio alla sicurezza. Non è più sufficiente proteggere i perimetri tradizionali o monitorare eventi sospetti. Serve una strategia capace di affrontare minacce automatizzate, veloci e adattive.

Gli honeypot basati su AI rappresentano una possibile risposta, perché permettono di trasformare l’infrastruttura da bersaglio passivo a sistema attivo di difesa e intelligence. Tuttavia, la loro efficacia dipenderà dalla capacità di integrarli in architetture più ampie, che includano detection avanzata, risposta automatizzata e analisi comportamentale.

---

---

---

https://www.securityinfo.it/2026/04/29/honeypot-intelligenti-come-lai-viene-usata-per-ingannare-gli-attaccanti-automatizzati/?utm_source=rss&utm_medium=rss&utm_campaign=honeypot-intelligenti-come-lai-viene-usata-per-ingannare-gli-attaccanti-automatizzati

Websites for some of the world’s most prestigious universities are serving explicit porn and malicious content after scammers exploited the shoddy record-keeping of the site administrators, a researcher found recently.

The sites included berkeley.edu, columbia.edu, and washu.edu, the official domains for the University of California, Berkeley, Columbia University, and Washington University in St. Louis. Subdomains such as hXXps://causal.stat.berkeley.edu/ymy/video/xxx-porn-girl-and-boy-ej5210.html, hXXps://conversion-dev.svc.cul.columbia[.]edu/brazzers-gym-porn, and hXXps://provost.washu.edu/app/uploads/formidable/6/dmkcsex-10.pdf. All deliver explicit pornography and, in at least one case, a scam site falsely claiming a visitor’s computer is infected and advising the visitor to pay a fee for the non-existent malware to be removed. In all, researcher Alex Shakhov said, hundreds of subdomains for at least 34 universities are being abused. Search results returned by Google list thousands of hijacked pages.

A handful of hijacked columbia.edu subdomains listed by Google

One of the sites redirected by a UC Berkeley subdomain.

Hijacking a university’s good name

Shakhov, founder of SH Consulting, said that the scammers—which a separate researcher has linked to a known group tracked as Hazy Hawk—are seizing on what amounts to a clerical error by site administrators of the affected universities. When they commission a subdomain such as provost.washu.edu, they create a CNAME record, which assignes a subdomain to a “cononical” domain. When the subdomain is eventually decommissioned—something that happens frequently for various reasons—the record is never removed. Scammers like Hazy Hawk then swoop in by hijacking the old record.

With that, they have now hijacked that university’s subdomain. Given the reputations universities have, search queries then flow to the top of Google’s results.

https://arstechnica.com/security/2026/04/why-are-top-university-websites-serving-porn-it-comes-down-to-shoddy-housekeeping/

Immagina di svegliarti al mattino circondato dal blu profondo dell’oceano. Sottili lame di luce filtrano dalle pareti trasparenti mentre, decine di metri sopra di te, onde silenziose si infrangono contro la superficie.

Sei in Vanguard, un habitat sottomarino all’avanguardia, progettato per ospitare esseri umani in missioni prolungate sul fondo del mare. Ma tra sensori, sistemi di supporto vitali e comunicazione digitale, c’è una domanda che emerge in tutta la sua urgenza: come si protegge un mondo sommerso da un attacco informatico?

“Il mare, una volta che ha lanciato il suo incantesimo, ti tiene per sempre nella sua rete di meraviglia.”

Jacques Cousteau

Cybersecurity negli habitat sottomarini: proteggere infrastrutture e dati in ambienti estremi

A metà del Novecento, Jacques Cousteau fu un pioniere visionario dell’esplorazione marina. Sognava una convivenza armoniosa tra l’uomo e il mondo sommerso, affrontando sfide che andava- no ben oltre i limiti tecnologici del suo tempo.

Oggi, più di mezzo secolo dopo, quel sogno prende forma grazie a habitat avanzati come Vanguard: progettato dall’azienda DEEP, entrerà in fase di sperimentazione alla fine del 2025.

E come ogni ambiente complesso e isolato, anche questo richiede l’implementazione di tecnologie avanzate: sensori ambientali, sistemi di supporto vitale, monitoraggio medico, comunicazioni in tempo reale con la superficie.

Questi sistemi costituiscono punti critici potenzialmente vulnerabili. Un cyberattacco potrebbe non solo compromettere dati sensibili, ma anche mettere a rischio la continuità operativa di missioni sottomarine.

Le vene invisibili del Pianeta

Storicamente, uno dei punti più critici (e spesso trascurati) nella cybersecurity oceanica è rappresentato dai cavi sottomarini, veri e propri “tubi digitali” che trasportano oltre il 95% del traffico globale di Internet. Collegano continenti, finanziano economie, trasmettono dati militari. E sono vulnerabili.

Negli ultimi anni, diversi incidenti lo hanno dimostrato.

• Novembre 2024 – incidente del Mar Baltico: due cavi sottomarini (il C-Lion1, che collega la Finlandia alla Germania, più un altro tra Lituania e Svezia) sono stati danneggiati. Le autorità sospettano un possibile sabotaggio, con l’attenzione rivolta verso una nave cargo cinese, la Yi Peng 3, presente nell’area al momento degli incidenti.
• 2022 – taglio dei cavi sottomarini in Francia: in due diverse occasioni (ad aprile e a ottobre) dei cavi di telecomunicazione sottomarini nel sud della Francia sono stati intenzionalmente tagliati, causando interruzioni significative nei servizi Internet. Questi atti deliberati hanno sollevato preoccupazioni sulla sicurezza delle infrastrutture sottomarine.
• Febbraio 2024 – danni ai cavi vicino a Taiwan: due cavi sottomarini che collegano Taiwan alle isole Matsu sono stati tagliati, isolando digitalmente circa 14.000 residenti per sei settimane. Le autorità taiwanesi hanno accusato due navi cinesi di aver causato i danni, sollevando timori di sabotaggio deliberato.

La sicurezza comincia dall’infrastruttura

Per garantire la sicurezza informatica di un ambiente subacqueo, l’intera infrastruttura digitale deve essere progettata pensando alla resilienza e alla ridondanza. Ogni elemento, dalle connessioni cablate ai sistemi embedded, richiede una progettazione specifica e certificata, incentrata sul concetto di “Zero Trust”: fidarsi di nessuno, verificare tutto.

Per esempio, un elemento critico spesso trascurato è quello della supply chain: l’uso di hardware custom embedded in ambienti estremi porta con sé il rischio di componenti compromessi già nella fase di produzione. È fondamentale attuare processi rigorosi di verifica, certificazione e audiing dei fornitori e di ogni componente, dalla fase di progettazione fino all’installazione. Le minacce sottese alla supply chain sono tra le più difficili da individuare, perché agiscono nell’ombra, a volte per anni.

Inoltre, l’uso di sistemi legacy o di software non aggiornato spesso mantenuto per motivi di compatibilità con l’hardware subacqueo può introdurre vulnerabilità ed exploit noti. L’approccio “secure by design” deve essere adottato fin dalle prime fasi della progettazione, prevedendo aggiornamenti sicuri e verificabili anche in ambienti dove il collegamento alla rete non è continuo.

Dati sotto pressione

Mentre i tecnici a terra osservano flussi di dati salire dalla profondità, ci si chiede: dove finiscono queste informazioni? Come vengono trattate?

I dati generati da un habitat sottomarino sono una miniera di valore: parametri medici, segnali ambientali, tracciati di comunicazione, log di sistema, così come i dati confidenziali che vengono elaborati dai ricercatori. Alcuni sono soggetti a normati- ve quali il GDPR, altri rientrano in regimi di controllo strategico. L’archiviazione deve quindi rispettare criteri rigidi, con cifratura end-to-end, backup resilienti e politiche di conservazione adeguate.

Inoltre, considerando che gli “abitanti” del Vanguard vivranno per settimane (e in futuro mesi) in ambienti isolati, avranno giustamente la possibilità di navigare su Internet, guardare serie su Netflix, ascoltare musica o fare videochiamate con amici e familiari.

Ma offrire questi servizi apparentemente banali in un habitat sommerso pone sfide di cybersecurity cruciali. È infatti fondamentale che questo tipo di traffico (ricreativo, personale, non mission-critical) sia completamente segregato dalle reti operative e dai sistemi vitali dell’habitat.

In termini tecnici, questo implica l’adozione di una Network Segmentation rigorosa, che isola fisicamente o logicamente le seguenti classi di rete:

• Rete Operativa (OT) – sistemi vitali, ambientali, medicali, comando locale;
• Rete Missione (IT) – strumenti scientifici, raccolta dati, comunicazioni strategiche;
• Rete Ricreativa (User Internet) – accesso web, streaming, email personali, VOIP, app

L’isolamento può essere implementato tramite reti segmentate (VLAN), preferibilmente con l’impiego di router fisicamente separati, con link dedicati. È anche importante che l’hardware della rete ricreativa sia indipendente da quello critico: eventuali Wi-Fi personali, ad esempio, non devono condividere access point con sistemi tecnici.

E se la connessione con la superficie si interrompe? Nel mondo sommerso, la resilienza è un requisito vitale. Se un cavo si guasta, o se una boa viene danneggiata, il sistema deve continuare a operare. Linee di backup satellitari, logiche di failover, controllo locale dei sistemi: tutto deve contribuire a un obiettivo comune, ossia evitare che un guasto tecnico si trasformi in un’emergenza operativa.

Ma, ancora più importante, nessuno da terra deve poter prendere il controllo completo dell’habitat. Il comando resta in loco, nelle mani di chi vive in fondo al mare ogni giorno.

Da terra serve invece una piattaforma di monitoraggio centralizzata, capace di accorgersi in tempo reale di potenziali anomalie.

Minacce ibride e sabotaggi fisici

La sicurezza subacquea non è solo digitale. Un attacco fisico può precedere o accompagnare un’intrusione informatica. Esistono scenari di rischio dove operatori ostili potrebbero piazzare micro-sonde, intercettare segnali o persino sabotare una struttura con mezzi remoti.

Le boe di superficie, ad esempio, sono il punto più esposto. Una boa compromessa può essere usata per accedere ai sistemi interni o trasmettere dati alterati.

Inoltre, la comunicazione subacquea ha vincoli fisici molto severi: a differenza dell’aria o dello spazio, l’acqua è un mezzo ostile alla propagazione dei segnali elettromagnetici, in particolare delle onde radio ad alta frequenza. Già pochi metri sotto la superficie, queste onde vengono assorbite o distorte a causa della conducibilità salina, rendendo le classiche tecnologie wireless (come Wi-Fi e GPS) praticamente inutili.

Si usano quindi cavi, comunicazione ottica (laser subacquei) o comunicazione acustica. Quest’ultima soluzione – che può funzionare a profondità elevate – apre a una serie di rischi di cybersecurity unici, come Spoofing acustico (trasmettere segnali acustici falsi imitando comandi legittimi), Jamming (saturare la banda acustica con rumo- re artificiale), o Packet injection acustica (inserire pacchetti acustici malevoli nel flusso legittimo).

L’habitat Vanguard è progettato per trasmettere i dati tramite cavi ad alta capacità che lo collegano a boe e, poi, a una base operativa sulla terraferma. Questo sistema è vantaggioso rispetto a comunicazioni wireless (acustiche o ottiche) per:

• larghezza di banda superiore e minore latenza;
• maggiore stabilità in condizioni marine variabili;
• possibilità di trasportare contemporaneamente alimentazione elettrica e dati.

Tuttavia, questa soluzione porta con sé rischi cyber unici.

• Compromissione fisica del cavo: un attore ostile potrebbe tagliare, intercettare o manipolare fisicamente il cavo (es. installazione di una sonda passiva). Questo tipo di at- tacco può isolare completamente l’habitat, ritardare l’invio di dati critici, consentire l’intercettazione di informazioni.
• Intercettazione passiva del traffico: utilizzando apparecchiature altamente specializzate, un attore potrebbe “ascoltare” il traffico che passa nel cavo, specialmente se in rame o fibra ottica con scarsa
• Attacchi Man-In-The-Middle tramite relay compromesso: un attore ostile potrebbe interporre un relay (es. sulla boa di superficie), manipolando i dati in transito (falsi comandi, alterazione di messaggi).

Per mitigare queste minacce è fondamentale implementare contromisure mirate, ad esempio:

• autenticazione bidirezionale tra l’habitat e superficie, per assicurare che ogni pacchetto provenga e sia destinato solo a entità riconosciute e autorizzate;
• crittografia a livello di payload, che protegge non solo il canale di trasmissione ma anche i contenuti interni di ciascun messaggio, impedendo accessi non autorizzati anche in caso di intercettazione della connessione;
• monitoraggio comportamentale basato su intelligenza artificiale, in grado di apprendere i pattern normali di funzionamento del sistema e rilevare automaticamente eventuali deviazioni o segnali anomali, anche se non ancora classificati come minacce note.
• watermarking digitale e tecniche di firma crittografica, per verificare l’integrità e la paternità dei dati ricevuti, impedendo la manipolazione o l’iniezione di pacchetti contraffatti lungo il percorso.

Governance e lacune normative

Attualmente non esiste un quadro normativo internazionale specifico per la cybersicurezza degli habitat sottomarini.

Il diritto del mare, così come gli standard di sicurezza informatica tradizionali (es. NIST, ISO 27001), non affronta in modo esplicito le sfide legate alla protezione digitale di ambienti subacquei abitati.

A meno che gli habitat non vengano installati in acque territoriali, il mare è ancora terra (o meglio, acqua) di nessuno. Quale Stato è responsabile in acque internazionali? Chi stabilisce la proprietà dei dati raccolti? Come si gestisce un attacco sot- to giurisdizioni multiple? Temi oggi dibattuti anche dalle Nazioni Unite, nei contesti di governance degli “oceani digitali”.

Il futuro è già sommerso… e ancora tutto da scrivere

Quello che stiamo progettando oggi non è solo un laboratorio sottomarino: è un prototipo di civiltà. Un ambiente sicuro, intelligente, connesso. E come ogni società, anche questa deve proteggere il proprio spazio, fisico e digitale.

La cybersicurezza negli habitat subacquei non è un dettaglio tecnico: è la condizione necessaria per vivere il mare in modo sicuro e sostenibile. Perché nel blu profondo, dove ogni errore può essere vitale, solo la prevenzione fa davvero respirare.

Ma c’è un’altra consapevolezza da tenere ben presente: siamo pionieri. Nessuno ha mai costruito un’infrastruttura digitale che può ospitare esseri umani sul fondo del mare, in un ambiente tanto ostile quanto affascinante. Ogni requisito, ogni misura di sicurezza che oggi progettiamo, è frutto di deduzioni e simulazioni – ma non esiste ancora un “manuale” per la cybersicurezza subacquea.

È per questo che il progetto Vanguard è un progetto in evoluzione. Le sfide che ci attendono potrebbero non assomigliare a quelle che oggi immaginiamo. Potremmo dover ripensare tutto: dalla crittografia alla gestione energetica, dall’accesso ai dati alla protezione da nuove forme di attacco.

L’unica certezza è l’incertezza. E la nostra forza sta proprio nella capacità di adattarci, di imparare dagli imprevisti. In questo senso, la cybersicurezza non è solo una barriera difensiva: è un processo dinamico, una mentalità progettuale, una cultura della responsabilità che ci accompagnerà lungo tutto il viaggio.

E quel viaggio è appena iniziato.

Scopri di più consultando il white paper “Quaderni di Cyber Intelligence #8”, dove troverai analisi avanzate, case study e prospettive strategiche dedicate alle infrastrutture critiche, alla geopolitica digitale e alla governance della dimensione subacquea.

https://www.ictsecuritymagazine.com/articoli/cybersecurity-negli-habitat-sottomarini/

C’è un momento preciso in cui la complessità regolatoria smette di essere un problema dei legal team e diventa un rischio operativo di primo livello. Quel momento è adesso, e la sua geometria è più sottile di quanto molti abbiano compreso.

Con DORA pienamente applicabile dal 17 gennaio 2025, NIS2 recepita negli ordinamenti nazionali con diversi gradi di completezza e l’EU AI Act che ha già reso cogenti il divieto delle pratiche AI inaccettabili (dal 2 febbraio 2025) e gli obblighi sui modelli GPAI (dal 2 agosto 2025), mentre la scadenza principale per i sistemi AI ad alto rischio standalone si avvicina al 2 agosto 2026, le organizzazioni operanti nel mercato unico europeo navigano un paesaggio normativo di complessità inedita.

Regulatory Collision: il nuovo rischio sistemico che i board non hanno ancora prezzato

Il termine “regulatory collision” cattura con precisione la dinamica in gioco: non si tratta di tre obblighi che coesistono ordinatamente in compartimenti separati, ma di tre sistemi normativi che convergono sugli stessi asset, gli stessi processi e gli stessi momenti di crisi, generando regimi di compliance sovrapposti, governati però da logiche di interazione giuridicamente precise e, per molti CISO e board, ancora mal comprese.

Questa imprecisione non è accademica. Costa denaro, tempo e, nei casi peggiori, esposizione personale dei vertici aziendali.

La geometria della sovrapposizione: tre regimi, tre logiche

Per comprendere dove e come le tre normative si intersecano, è necessario mapparne le architetture concettuali fondamentali.

NIS2 (Direttiva 2022/2555) opera su una logica di protezione dell’infrastruttura critica e della continuità dei servizi essenziali e importanti. Il suo baricentro è la resilienza sistemica del tessuto digitale europeo: chi eroga servizi critici deve gestire il rischio cyber in modo strutturato, notificare gli incidenti significativi e rispondere della propria postura di sicurezza lungo tutta la supply chain.

La direttiva estende il perimetro in modo radicale rispetto a NIS1, coprendo in Europa oltre 100.000 entità, e introduce con questa cogenza la responsabilità personale dei vertici aziendali per le violazioni degli obblighi di cybersecurity governance. I settori finanziari figurano esplicitamente nell’Allegato I come entità essenziali. Ma qui entra in gioco un principio giuridico fondamentale che l’analisi non può eludere, come approfondito anche nell’analisi sulla convergenza normativa pubblicata su queste pagine.

DORA (Regolamento 2022/2554) opera su una logica di resilienza operativa digitale specifica per il settore finanziario. È un regolamento, non una direttiva, il che significa applicazione diretta e uniforme in tutti gli Stati membri. Copre 20 categorie di entità finanziarie e stabilisce per ognuna un framework articolato su cinque pilastri: ICT risk management, incident reporting, resilience testing (inclusi i TLPT, i Threat-Led Penetration Testing), gestione del rischio di terze parti ICT e information sharing. Crucialmente, il Considerando 16 di DORA stabilisce: “This Regulation constitutes lex specialis with regard to Directive (EU) 2022/2555.” Questo non è un dettaglio tecnico-giuridico marginale: è la chiave di volta dell’intera architettura di compliance per le entità finanziarie.

L’EU AI Act (Regolamento 2024/1689) opera su una logica di gestione del rischio proporzionale alla pericolosità dei sistemi AI. La classificazione per livelli, pratiche inaccettabili, alto rischio, rischio limitato e rischio minimo, determina gli obblighi applicabili.

Per i sistemi AI ad alto rischio elencati nell’Allegato III, gli obblighi includono: conformità a standard tecnici armonizzati, registrazione in database europei, valutazioni di conformità pre-market, trasparenza e monitoraggio post-mercato (Art. 72) e notifica dei serious incident alle autorità di sorveglianza (Art. 73). Nel settore finanziario, i sistemi AI usati per credit scoring, fraud detection, valutazione del merito creditizio e gestione del rischio ricadono tipicamente nella categoria ad alto rischio dell’Allegato III. La scadenza per conformarsi a questi obblighi è il 2 agosto 2026, a soli quattro mesi dalla presente pubblicazione.

Il principio lex specialis: cosa cambia davvero per le entità finanziarie

Comprendere con esattezza come questi tre framework si intersecano è la competenza più critica che un CISO o un membro del board debbano sviluppare oggi. Ed è qui che molte analisi, anche autorevoli, peccano di imprecisione.

Per le entità finanziarie coperte da DORA, il quadro è il seguente: DORA è lex specialis rispetto a NIS2. Ciò significa che gli obblighi NIS2 in materia di ICT risk management, incident reporting, supervisione e enforcement sono sostituiti da quelli DORA, non cumulabili con essi. Una banca che subisce un incidente ICT grave non è tenuta a effettuare una doppia notifica, una a Banca d’Italia o BCE sotto DORA e una ad ACN/CSIRT Italia sotto NIS2 per il medesimo evento. Notifica sotto DORA all’autorità competente e adempie agli obblighi del Regolamento. La Commissione Europea ha pubblicato nel settembre 2023 apposite linee guida (Decisione C(2023) 6373) sull’applicazione dell’articolo 4(1) e (2) di NIS2, che chiariscono questa interfaccia.

Questo non significa che NIS2 sia irrilevante per le entità finanziarie. La direttiva può ancora applicarsi in aree non coperte da DORA, inclusi alcuni aspetti della supply chain security che esulano dall’ICT, elementi di sicurezza fisica e obblighi di registrazione. Rimane inoltre pienamente applicabile ai fornitori di servizi ICT non designati come Critical Third-Party Providers (CTPP) sotto DORA: la banca può essere esente da certe obbligazioni NIS2, ma il suo cloud provider può esservi pienamente soggetto.

La vera regulatory collision per le entità finanziarie non è dunque DORA contro NIS2 per le stesse obbligazioni: è DORA contro EU AI Act. Due regolamenti, entrambi direttamente applicabili, che convergono sugli stessi asset quando questi sono sistemi AI integrati nelle operazioni finanziarie. Questa sovrapposizione non è risolta da alcun principio di lex specialis: i due regolamenti sono distinti per oggetto e si cumulano, come analizzato in dettaglio anche nella guida alla DORA compliance operativa.

Per i fornitori ICT che servono sia entità finanziarie sia altri settori, e per le entità essenziali non finanziarie come energia, sanità e infrastrutture digitali, la situazione è invece quella del classico schema triple threat: NIS2 si applica interamente e si cumula con l’AI Act se l’entità utilizza sistemi AI nell’erogazione dei servizi critici, e con DORA se fornisce ICT a soggetti finanziari.

Lo scenario del singolo incidente: la collisione reale

Con questa mappa corretta in mente, è possibile seguire la traiettoria di un incidente reale attraverso i framework applicabili.

Si consideri un istituto di credito medio-grande che subisce un attacco alla supply chain, con compromissione di un componente software di un fornitore ICT critico. Il componente è integrato nel sistema di fraud detection basato su machine learning, classificato come sistema AI ad alto rischio ai sensi dell’Allegato III dell’AI Act. L’incidente provoca un’interruzione parziale del servizio di pagamento per quattro ore, con impatto su circa 80.000 clienti.

Sotto DORA, l’entità deve classificare l’incidente come grave se supera le soglie degli RTS adottati dalle ESA, in questo scenario quasi certamente sì, visto l’impatto su clienti, l’interruzione di una funzione critica e il vettore supply chain. La struttura di notifica è articolata in tre fasi: notifica iniziale entro quattro ore dalla classificazione come grave, e comunque entro 24 ore dal rilevamento; report intermedio entro 72 ore dall’invio della notifica iniziale; report finale entro un mese dalla classificazione. Parallelamente, l’entità avvia la procedura di gestione del rischio verso il fornitore ICT compromesso, verificando la conformità contrattuale ai sensi dell’Art. 30 e valutando le strategie di exit.

Sotto l’EU AI Act, il provider e/o il deployer del sistema di fraud detection devono valutare se l’incidente configura un serious incident ai sensi dell’Art. 3(49), ossia un malfunzionamento che ha causato o poteva causare danni significativi. In caso affermativo, la notifica alle autorità di sorveglianza del mercato è obbligatoria ai sensi dell’Art. 73. Il processo di monitoraggio post-mercato (Art. 72) deve documentare l’evento nel registro tecnico del sistema. Devono essere valutati eventuali impatti sulla conformità tecnica del modello: compromissione dei dati di training, alterazione dei parametri, degradazione della performance decisionale.

Sotto NIS2, come chiarito, l’entità finanziaria coperta da DORA è esente dagli obblighi di incident reporting NIS2 per lo stesso evento. La direttiva rimane però rilevante per il fornitore ICT compromesso, che è probabilmente soggetto a NIS2 come entità essenziale o importante nel settore delle infrastrutture digitali, e deve notificare ad ACN/CSIRT Italia entro 24 ore (notifica preliminare), entro 72 ore (notifica completa con valutazione iniziale dell’incidente) e produrre il report finale entro un mese dall’invio della notifica completa.

Questo scenario rivela la complessità reale: non tre notifiche obbligatorie parallele per la stessa entità finanziaria sullo stesso incidente, ma due regimi che si cumulano genuinamente per quell’entità (DORA e AI Act) e un terzo che si applica in modo asimmetrico lungo la supply chain (NIS2 per il fornitore). La gestione di questa asimmetria, sapere esattamente chi deve notificare cosa a chi, in quale sequenza temporale e con quali contenuti, è già sufficientemente complessa da richiedere processi di incident response radicalmente ripensati.

La liability personale: il cambio di paradigma che i board devono metabolizzare

Fino a pochi anni fa, la non conformità normativa in ambito cyber era essenzialmente un rischio organizzativo: sanzioni all’entità, danni reputazionali, contenziosi. I dirigenti potevano mantenere una distanza gestibile tra la propria responsabilità personale e le violazioni tecniche avvenute nelle funzioni operative. Tutti e tre i framework regolatori convergono nel disfare questa distanza.

NIS2, all’Art. 20, stabilisce che gli organi di gestione delle entità essenziali e importanti devono approvare le misure di gestione dei rischi cyber, supervisionarne l’attuazione e seguire una formazione specifica. La responsabilità personale dei membri degli organi di gestione è esplicitamente prevista: l’Art. 32(5) consente alle autorità nazionali di sospendere temporaneamente dirigenti apicali delle entità essenziali e di vietare loro di ricoprire funzioni manageriali nella stessa entità in caso di violazioni gravi. Per le entità importanti, previsioni analoghe sono contenute nell’Art. 33(5). L’Italia ha recepito questa impostazione nel D.Lgs. 138/2024, come documentato nell’analisi sugli adempimenti NIS2 e scadenze 2026.

DORA, all’Art. 5, assegna all’organo di gestione la piena responsabilità del framework di ICT risk management: definirlo, approvarlo, supervisionarne l’attuazione e risponderne. Il Considerando 45 chiarisce che i management body devono mantenere un “ruolo pivotale e attivo” nel guidare il framework di ICT risk management e la strategia di resilienza digitale. L’Art. 5(4) specifica che i membri del management body devono attivamente mantenersi aggiornati con conoscenze e competenze sufficienti per comprendere e valutare il rischio ICT. Non è una buona pratica: è un obbligo giuridico.

L’AI Act, agli Artt. 9 e 17, richiede che i sistemi ad alto rischio siano dotati di sistemi di risk management e quality management supervisionati da persone con la necessaria autorità e responsabilità organizzativa.

Le sanzioni previste dall’Art. 99 si articolano su tre livelli: fino a 35 milioni di euro o il 7% del fatturato globale per le violazioni delle pratiche AI vietate (Art. 5, le fattispecie più gravi, come il social scoring e la sorveglianza biometrica di massa); fino a 15 milioni di euro o il 3% del fatturato globale per le violazioni degli obblighi relativi ai sistemi AI ad alto rischio, che è la fattispecie rilevante per entità finanziarie che utilizzano sistemi di fraud detection o credit scoring; fino a 7,5 milioni di euro o l’1% per le informazioni inesatte o fuorvianti alle autorità.

I singoli dirigenti non sono destinatari diretti delle sanzioni pecuniarie dell’AI Act, ma l’attribuzione di responsabilità organizzativa è sufficientemente specifica da generare esposizioni personali significative nei regimi di responsabilità civile e, in taluni ordinamenti nazionali, penale.

Il CISO che cerca di “portare il rischio cyber al board” non sta più perseguendo una best practice: sta adempiendo a obblighi normativi la cui inosservanza espone i singoli amministratori a conseguenze personali dirette sotto tre distinti framework.

Perché i framework GRC tradizionali non reggono

La risposta istintiva di molte organizzazioni alla complessità regolatoria è stata la costruzione di silo di compliance paralleli. Ogni silo produce la propria documentazione, i propri processi, i propri report. Questo approccio era già subottimale nella fase precedente. Nell’attuale configurazione normativa è strutturalmente inadeguato, per tre ragioni.

La prima è la duplicazione cognitiva del rischio. Un fornitore di servizi cloud che serve entità finanziarie ed è contemporaneamente provider di un sistema AI ad alto rischio è soggetto a DORA (contrattualmente, come fornitore ICT), a NIS2 (direttamente, come entità essenziale nell’infrastruttura digitale) e all’AI Act (come provider di sistemi AI ad alto rischio). Le valutazioni di rischio che alimentano questi tre framework traggono dati dagli stessi asset sottostanti: frammentarle produce incoerenze, contraddizioni documentali e lacune che nessun silo individuale è attrezzato a vedere.

La seconda è la crisi di coordinamento in incidente. Un incidente grave attiva procedure parallele sotto regimi diversi, con scadenze temporali ravvicinate e parzialmente divergenti. Se i team responsabili non sono integrati e non sanno esattamente a chi notificare cosa, l’organizzazione rischia di perdere scadenze, produrre comunicazioni incoerenti verso autorità diverse e creare documentazione post-incidente che potrebbe essere usata contro di essa in sede di enforcement.

La terza è la cecità sistemica sui rischi compositi emergenti. Il punto di intersezione più pericoloso non è negli scenari già noti, ma in quelli non ancora immaginati. Un sistema AI che ottimizza la gestione della liquidità, alimentato da dati provenienti da un fornitore ICT critico, operante su infrastruttura cloud soggetta a NIS2: la compromissione parziale di questo sistema attraversa simultaneamente il perimetro DORA (rischio ICT per un’entità finanziaria), il perimetro AI Act (sistema ad alto rischio compromesso) e il perimetro NIS2 (fornitore infrastrutturale). I GRC tradizionali non sono costruiti per vedere questi rischi compositi prima che si materializzino.

La risposta architetturale necessaria è quella che la letteratura emergente chiama Unified GRC: una struttura in cui il rischio viene valutato una sola volta rispetto a tutti i regimi applicabili, le soglie di escalation sono armonizzate, i processi di notifica coordinati e la documentazione progettata per soddisfare requisiti multipli con il minimo di ridondanza.

L’intelligenza artificiale come moltiplicatore ricorsivo di complessità

C’è un’ironia strutturale nella situazione attuale: le organizzazioni usano sistemi AI per gestire la complessità operativa e di compliance, mentre l’AI Act introduce nuovi obblighi che riguardano, tra le altre cose, proprio i sistemi AI usati nelle funzioni critiche.

Uno strumento di GRC basato su AI che supporta la gestione del rischio operativo di un’entità finanziaria è potenzialmente un sistema ad alto rischio ai sensi dell’AI Act, se supporta decisioni relative alla gestione del rischio o al credito (fattispecie previste nell’Allegato III), e un asset ICT critico ai sensi di DORA, se integrato nei processi operativi dell’entità. Lo strumento usato per gestire la compliance è esso stesso soggetto a compliance multipla. La ricorsività è reale e richiede che le organizzazioni adottino un approccio esplicito alla governance dei sistemi AI interni, non soltanto di quelli esposti verso i clienti.

Più in generale, l’integrazione di AI nelle operazioni critiche amplia la superficie di rischio attraverso vettori nuovi: adversarial attacks sui modelli, data poisoning non rilevato, model drift silenzioso. Crea inoltre dipendenze da fornitori di modelli che rientrano nel perimetro di sorveglianza DORA se classificati come fornitori ICT di terze parti, e nell’oversight diretto delle ESA se designati CTPP. L’AI Act richiede che questi rischi siano documentati e mitigati nel registro tecnico; DORA richiede che le dipendenze contrattuali siano strutturate secondo clausole minime specifiche; NIS2 richiede che la supply chain sia valutata sistematicamente dal fornitore ICT soggetto alla direttiva. Tre framework, tre angolature sul medesimo rischio sottostante, come approfondito anche nell’analisi sull’EU AI Act GPAI.

Un’agenda pratica per CISO e board

Mappatura precisa dei regimi applicabili per tipologia di entità. Il primo passo, prima di qualsiasi gap analysis, è determinare con precisione giuridica quale combinazione di framework si applica alla propria organizzazione: DORA primario con AI Act addizionale per le entità finanziarie che usano AI; NIS2 con AI Act per le entità essenziali non finanziarie che utilizzano sistemi AI; NIS2 e DORA per i fornitori ICT che servono sia financial entities sia altri settori. Questa mappatura non può essere delegata a logica di default: richiede competenza giuridico-regolatoria specifica, tenendo presente che, come illustrato nell’analisi sull’implementazione NIS2 in Europa, la trasposizione nei diversi ordinamenti nazionali introduce ulteriori variabili.

Ridisegno dei piani di incident response per la complessità composita. I playbook di risposta agli incidenti devono essere aggiornati per gestire scenari di rischio composito, identificando per ciascun tipo di evento le obbligazioni di notifica applicabili, le scadenze precise, le autorità destinatarie e le responsabilità assegnate. Per le entità finanziarie: chi notifica sotto DORA, e quali aspetti dell’evento richiedono attivazione parallela degli obblighi AI Act nel caso in cui un sistema AI ad alto rischio sia coinvolto?

Priorità assoluta all’AI Act entro agosto 2026. Per tutte le organizzazioni che utilizzano sistemi AI ad alto rischio (Allegato III), e il settore finanziario è tra i più esposti, la scadenza del 2 agosto 2026 per la piena compliance con gli obblighi di risk management, documentazione tecnica, conformity assessment e monitoraggio post-mercato non è più un orizzonte lontano: al momento della pubblicazione di questo articolo mancano meno di quattro mesi. Le organizzazioni non ancora a regime devono considerarlo una priorità critica e urgente.

Revisione delle clausole contrattuali con fornitori ICT e AI. DORA prescrive requisiti minimi stringenti per i contratti con fornitori ICT critici (Art. 30). L’AI Act aggiunge obblighi specifici nella catena di responsabilità tra provider e deployer. NIS2 richiede valutazioni della supply chain per i fornitori soggetti alla direttiva. Le clausole contrattuali esistenti devono essere revisionate per soddisfare tutti i framework pertinenti alla specifica relazione contrattuale.

Formazione del board come sostanza, non adempimento. NIS2 (Art. 20) e DORA (Art. 5 e Considerando 45) richiedono che i vertici abbiano una comprensione genuina dei rischi ICT e AI. I programmi di board education che si limitano a una sessione annuale superficiale non sono adeguati né normativamente né operativamente. Il board deve comprendere la logica delle tre normative, la natura della loro interazione e le implicazioni della propria liability personale con profondità sufficiente a prendere decisioni informate e a supervisionare attivamente i rischi.

Conclusione: la maturità regolatoria come vantaggio competitivo

La regulatory collision tra DORA, NIS2 e EU AI Act non è un problema temporaneo. È una caratteristica strutturale del nuovo paesaggio normativo europeo, che riflette la complessità genuina dei sistemi tecnologici moderni: sistemi che sono contemporaneamente infrastruttura critica, asset operativo finanziario e sistema intelligente decisionale, non governabili da un solo framework senza perdere pezzi fondamentali del quadro di rischio.

La complessità reale, tuttavia, è diversa da come spesso viene rappresentata. Non è una sovrapposizione caotica e indifferenziata di obblighi identici, ma una struttura di interazioni giuridicamente precise: lex specialis dove applicabile, cumulo genuino dove necessario. Questa struttura richiede competenza per essere navigata, non semplificazione. Confondere le due cose produce compliance costosa e inutilmente ridondante in alcuni punti e pericolosamente lacunosa in altri.

Le organizzazioni che investiranno in una visione integrata e giuridicamente precisa del rischio regolatorio, costruendo le capacità di governance, i processi e le architetture tecniche necessarie a vedere il rischio nella sua dimensione composita reale, trasformeranno la compliance in qualcosa di più di un obbligo: in un segnale di maturità organizzativa che il mercato, i regolatori e i propri clienti sanno sempre meglio leggere.

La convergenza regolatoria non è la fine del problema. È l’inizio di una nuova concezione della resilienza.

L’analisi riflette una prospettiva editoriale indipendente basata sull’analisi dei testi normativi ufficiali, degli RTS e ITS adottati dalle Autorità di Vigilanza Europee e della letteratura giuridica disponibile alla data di pubblicazione. Le indicazioni non costituiscono parere legale.

https://www.ictsecuritymagazine.com/articoli/regulatory-collision/

There is no practical benefit for Kyber developers to have chosen a PQC key-exchange algorithm. The Kyber ransom note gives victims one week to respond. Quantum computers capable of running Shor’s algorithm—the series of mathematical equations that allow the breakage of RSA and ECC (elliptic curve cryptography)—are, at a minimum, three years away and likely much further.

A Kyber variant that targets systems running VMware,  meanwhile, claims to use ML-KEM as well. Rapid7 said its look under the hood revealed that, in fact, it uses RSA with 4096-bit keys, a strength that will take even longer for Shor’s algorithm to break. Anna Širokova, a Rapid7 senior security researcher and the author of Tuesday’s post, said the use or claimed use of ML-KEM is likely just a branding gimmick and that implementing it required relatively little work by Kyber developers.

In an email, Širokova wrote:

First, it’s marketing to the victim. “Post-quantum encryption” sounds a lot scarier than “we used AES,” especially to non-technical decision-makers who might be evaluating whether to pay. It’s a psychological trick. They’re not worried about someone breaking the encryption a decade from now. They want payment within 72 hours.

Second, implementation cost is low. Kyber1024 libraries (renamed to ML-KEM) are available and well-documented. Ransomware doesn’t encrypt your files directly with Kyber1024. That would be slow. Instead, it:

1. Generates a random AES key
2. Encrypts your files with that AES key (fast)
3. Encrypts that AES key with Kyber1024 (so only the attacker can decrypt it)

In Rust, there are already libraries that do Kyber1024. The developer just adds it to their dependencies and calls a function to wrap the key.

Despite the hype, Kyber suggests that PQC is attracting the attention of less technically inclined attorneys and executives deciding how to respond to ransom demands. Kyber developers are hoping the impression that the encryption has overwhelming strength will sway people to pay.

https://arstechnica.com/security/2026/04/now-even-ransomware-is-using-post-quantum-cryptography/