C’è un paradosso silenzioso al cuore dell’economia digitale contemporanea. Le API (Application Programming Interface) sono l’infrastruttura nervosa che tiene in vita ogni transazione bancaria, ogni ordine di e-commerce, ogni scambio di dati sanitari, ogni richiesta di un’applicazione mobile. Sono invisibili all’utente finale, onnipresenti nel codice, fondamentali per qualunque modello di business digitale. Eppure, proprio questa ubiquità le rende il bersaglio preferito degli attaccanti moderni e, troppo spesso, il punto più trascurato dell’intera catena della sicurezza informatica.

I numeri aiutano a comprendere la dimensione del problema. Secondo il Cloudflare Radar 2025 Year in Review, l’analisi più autorevole e aggiornata disponibile, basata sull’osservazione diretta di una rete globale presente in oltre 330 città, le API rappresentano oggi più della metà di tutto il traffico web dinamico, con un’incidenza in costante crescita.

Akamai, su un campione diverso di traffico internet, stima la quota fino all’83%. Nel solo 2025, le API hanno generato oltre 11.000 bollettini di sicurezza, pari al 17% di tutte le vulnerabilità software pubblicamente divulgate in un anno. Il traffico malevolo diretto verso le API è cresciuto del 681% nell’arco degli ultimi anni, secondo il Wallarm 2026 API ThreatStats Report. Quasi il 99% delle organizzazioni ha dichiarato di aver subito almeno un incidente legato alla sicurezza delle API negli ultimi dodici mesi. Non si tratta di statistiche marginali: è la fotografia di un’infrastruttura critica sotto assedio sistematico, e di un settore che stenta ancora a rispondere con adeguata consapevolezza.

Un bersaglio su misura per gli attaccanti

Cosa rende le API un vettore così attraente? La risposta sta nella loro natura strutturale. A differenza delle applicazioni web tradizionali, un’API non ha una “porta d’ingresso” visibile: non ha un login, non ha un CAPTCHA, non ha l’interfaccia grafica che un essere umano deve attraversare. È progettata per essere consumata da macchine, e le macchine non faticano a sparare decine di migliaia di richieste al secondo. Un’organizzazione che espone API pubbliche riceve in media 10.000 attacchi al giorno. Le API GraphQL, sempre più diffuse per la loro flessibilità, hanno visto un incremento del 140% nei tentativi di abuso nel corso del 2025.

La semplicità di attacco è altrettanto allarmante. Secondo il Wallarm 2026 API ThreatStats Report, il 97% delle vulnerabilità API è sfruttabile con una singola richiesta HTTP. Il 98% è classificato come facile o banale da sfruttare. Il 59% non richiede nemmeno autenticazione. Il 30% ha già exploit pubblici disponibili nel momento stesso in cui la vulnerabilità viene divulgata. Questa combinazione di alta diffusione, alta sfruttabilità e bassa complessità trasforma le API in un terreno di caccia privilegiato per attori di ogni livello, dai criminali opportunistici alle APT sofisticate.

A questo si aggiunge la questione del rilevamento. Solo il 21% delle organizzazioni dichiara di avere capacità solide nell’identificare attacchi a livello API. Appena il 13% riesce a prevenire più del 50% degli attacchi. Gli strumenti tradizionali come i Web Application Firewall (WAF) si rivelano inadeguati: il 53% delle organizzazioni ne riconosce apertamente i limiti nella rilevazione di frodi a livello API. Siamo di fronte a un disallineamento strutturale tra la superficie esposta e le difese disponibili.

L’OWASP API Security Top 10: una mappa delle fragilità

Dal 2019, l’Open Worldwide Application Security Project pubblica la propria lista delle vulnerabilità API più critiche. La versione aggiornata al 2023, oggi il riferimento di settore, riflette un’evoluzione significativa del panorama delle minacce. L’88% degli attacchi reali sfrutta almeno una delle vulnerabilità elencate, il che rende questa tassonomia uno strumento di prioritizzazione imprescindibile per qualunque team di sicurezza.

API1:2023 – Broken Object Level Authorization (BOLA) rimane, a distanza di anni, la vulnerabilità più sfruttata nelle API. Si manifesta quando un endpoint espone dati di un oggetto senza verificare che l’utente autenticato abbia effettivamente il diritto di accedervi. Un attaccante che conosce o indovina l’identificatore di un record (un numero d’ordine, un ID paziente, un codice cliente) può semplicemente cambiarlo nella richiesta e accedere ai dati altrui. La logica è elementare; l’impatto, devastante.

API2:2023 – Broken Authentication aggrega tutte le debolezze legate alla gestione dell’identità: password deboli, token JWT mal configurati, assenza di blocco su tentativi multipli, meccanismi di reset insicuri. In questa categoria rientrano anche i frequenti errori nella gestione dei segreti: chiavi API hard-coded nel codice sorgente, token esposti in repository pubblici, credenziali condivise tra ambienti di produzione e sviluppo. Un caso emblematico, divulgato nel dicembre 2024 dal team TRIAD di CloudSEK: la scoperta di oltre 30.000 workspace Postman accessibili pubblicamente, contenenti token di accesso attivi, chiavi API reali e payload con dati sanitari e credenziali aziendali di organizzazioni in settori che vanno dalla finanza all’abbigliamento sportivo.

API3:2023 – Broken Object Property Level Authorization (BOPLA) è una novità della lista 2023, nata dalla fusione di due categorie precedenti (Excessive Data Exposure e Mass Assignment). Riconosce che il problema non è solo chi può accedere a un oggetto, ma anche quali proprietà di quell’oggetto possono essere lette o modificate. Un utente che riesce a modificare un campo come role: admin in una richiesta PUT sta sfruttando esattamente questa vulnerabilità.

API4:2023 – Unrestricted Resource Consumption riguarda la mancanza di limiti efficaci sull’uso delle risorse: assenza di rate limiting, nessun controllo sulla dimensione dei payload, nessun tetto alle query su database o ai servizi di terze parti a pagamento. Gli attacchi DDoS diretti alle API sono cresciuti del 200% nel 2025. In assenza di throttling, un attaccante può paralizzare un servizio o generare costi operativi insostenibili attraverso richieste massive e automatizzate.

API5:2023 – Broken Function Level Authorization (BFLA) colpisce quando la distinzione tra funzioni amministrative e funzioni utente non è enforcement a livello backend. Se un’API non verifica il livello di privilegio richiesto per ciascun endpoint, un utente ordinario potrebbe invocare endpoint di amministrazione semplicemente conoscendone il path.

API6:2023 – Unrestricted Access to Sensitive Business Flows è la vulnerabilità più sottile e difficile da rilevare automaticamente. Non riguarda un bug tecnico, ma l’assenza di protezione contro l’uso massiccio e automatizzato di flussi di business legittimi: acquisto di biglietti, creazione di account, pubblicazione di contenuti. Un bot che acquista in millisecondi tutti i posti di un concerto sta sfruttando questa categoria, e nessuno scanner tradizionale lo individuerà.

API7:2023 – Server-Side Request Forgery (SSRF) è una novità del 2023. Si verifica quando un’API recupera risorse remote senza validare l’URI fornito dall’utente, consentendo a un attaccante di instradare richieste verso sistemi interni, servizi di metadata cloud o endpoint protetti da firewall.

API8:2023 – Security Misconfiguration è il contenitore di una casistica vastissima: CORS permissivi, header di sicurezza assenti, messaggi di errore verbosi che rivelano la struttura interna, TLS non configurato, porte di debug esposte in produzione. I cloud provider registrano misconfigurazioni API in oltre il 30% dei casi di breach.

API9:2023 – Improper Inventory Management riguarda le cosiddette shadow API, un tema che merita un approfondimento dedicato per la rilevanza che ha assunto negli ultimi anni, come illustrato nel paragrafo seguente.

API10:2023 – Unsafe Consumption of APIs è l’unica voce della lista che capovolge la prospettiva: non riguarda i rischi di essere un provider di API, ma quelli di essere un consumer. Un’applicazione che consuma API di terze parti senza validarne l’output, senza limitare i dati elaborati e senza considerare la possibilità di un provider compromesso, eredita automaticamente le vulnerabilità di quell’ecosistema.

Il problema delle shadow API: quello che non sai che esiste

Tra tutte le sfide della sicurezza API, la gestione delle API non documentate, denominate shadow API o zombie API, è probabilmente la più sistemica e la più sottovalutata. Le shadow API sono endpoint reali, attivi, raggiungibili dalla rete, che non compaiono in nessun inventario ufficiale, non sono soggetti a test di sicurezza, non sono monitorati da nessun team. Possono essere API di vecchie versioni dimenticate durante una migrazione, endpoint di sviluppo mai rimossi in produzione, integrazioni create da team interni senza passare per il processo formale di release.

I numeri dicono che le shadow API rappresentano oltre il 20% dell’inventario API totale nelle organizzazioni enterprise. Le istituzioni finanziarie gestiscono in media 601 API e una parte rilevante di queste sfugge a qualsiasi governance attiva. Un caso paradigmatico del 2025 è quello di Stripe: attaccanti hanno individuato un endpoint legacy (/v1/sources) ancora collegato ai sistemi di validazione pagamenti, privo dei controlli di sicurezza delle API moderne, e lo hanno sfruttato per condurre una campagna massiva di card skimming su almeno 49 e-commerce compromessi. L’endpoint era un residuo dell’architettura precedente, scarsamente documentato e ignorato nei security audit. Non una vulnerabilità zero-day: un oggetto dimenticato.

Quello di Stripe non è un caso isolato. Il breach di Optus del settembre 2022 ha esposto i dati personali di quasi 10 milioni di clienti australiani, quasi un terzo della popolazione del paese, attraverso un’API priva di autenticazione rimasta accessibile da internet per circa tre mesi. Secondo l’analisi dell’Australian Communications and Media Authority (ACMA), un errore di codifica introdotto nel 2018 aveva reso inefficaci i controlli di accesso su un sottodominio, e il problema era rimasto non rilevato nonostante una correzione parziale applicata nel 2021 sul dominio principale. L’attaccante non aveva bisogno di strumenti sofisticati: l’API non richiedeva alcuna autenticazione, e i customer ID erano numerici e incrementali, rendendoli banalmente enumerabili.

Il breach che nel 2022 ha colpito Twitter è spesso descritto in modo impreciso. Non si trattava di un’API legacy dimenticata, ma di un bug introdotto nell’aggiornamento del codice di giugno 2021: la vulnerabilità consentiva a chiunque di sottomettere un numero di telefono o un indirizzo e-mail all’API della piattaforma e ricevere in risposta l’ID dell’account Twitter associato, anche quando l’utente aveva esplicitamente configurato le impostazioni di privacy per impedire questa correlazione.

Il bug fu segnalato tramite bug bounty in gennaio 2022 e corretto subito dopo; era però già stato sfruttato da almeno dicembre 2021. Un threat actor aveva creato un database di 5,4 milioni di profili, incluse informazioni private come numeri di telefono e indirizzi e-mail, poi venduto online e infine diffuso gratuitamente. Ulteriori analisi rivelarono che la stessa vulnerabilità era stata sfruttata su scala molto più ampia, portando a un dataset finale di oltre 200 milioni di account.

In entrambi i casi, come nel caso Stripe, la catena causale è identica: controlli insufficienti, endpoint dimenticati o alterati, nessun monitoraggio, nessun alert.

Breach recenti: leggere gli incidenti come segnali

L’analisi dei 60 breach API divulgati nel 2025, condotta da Wallarm nel 2026 API ThreatStats Report, restituisce un quadro per settori e categorie: software (15%), piattaforme AI (15%), vendor di cybersecurity (13%), SaaS (8%), automotive (7%), cloud services (7%). Mappati sulla tassonomia OWASP, la broken authentication è responsabile del 52% degli incidenti, mentre l’unsafe consumption di API di terze parti spiega il 27%.

Tra gli episodi più rilevanti del 2025: API di terze parti hanno esposto milioni di record presso il fornitore di servizi creditizi 700Credit; debolezze nell’autenticazione delle API Qantas hanno permesso accessi di massa non autorizzati; credenziali rubate e permessi API eccessivi hanno abilitato transazioni fraudolente su SwissBorg; server MCP esposti hanno fatto trapelare infrastrutture di agent AI su larga scala. A maggio 2025 un hacker con lo pseudonimo “ByteBreaker” ha pubblicato su forum underground la presunta raccolta di dati relativi a 1,2 miliardi di account Facebook tramite abuso di API.

Meta ha negato si tratti di un breach nuovo, sostenendo che il dataset reimpacchetti dati già divulgati nel 2021; i ricercatori di Cybernews e Hackread hanno rilevato incongruenze strutturali nella dimensione dichiarata e sovrapposizioni significative con il leak precedente. Il claim resta pertanto non verificato indipendentemente, ma l’episodio conferma il modello di sfruttamento delle API come vettore di data harvesting massivo.

Il filo conduttore è sempre lo stesso: non exploit sofisticati, non attori nation-state con capacità eccezionali, ma debolezze fondamentali (autenticazione assente o debole, autorizzazione non granulare, endpoint dimenticati, terze parti non verificate) sfruttate con strumenti automatizzati alla portata di qualunque attore.

DevSecOps e la sicurezza by design: integrare prima che sia tardi

La risposta sistemica al problema della sicurezza API non può essere post-hoc. Applicare controlli di sicurezza su API già in produzione è costoso, inefficace e spesso destinato a fallire. La strada maestra è l’integrazione della sicurezza nel ciclo di vita dello sviluppo, in quello che il settore definisce approccio DevSecOps oppure, più recentemente, shift-left security.

In pratica, questo significa che il processo di sviluppo deve includere: modellazione delle minacce nella fase di design (identificare le attack surface prima di scrivere codice); revisione del codice orientata alla sicurezza (con particolare attenzione alla gestione dei segreti, alla sanitizzazione degli input, alla corretta implementazione dell’autenticazione); test automatizzati di sicurezza nelle pipeline CI/CD (SAST per il codice sorgente, DAST per le API deployate, test specifici contro le vulnerabilità OWASP); e monitoraggio continuo in produzione, con alerting su anomalie comportamentali che potrebbero segnalare tentativi di exploitation.

Questo approccio richiede che la sicurezza non sia responsabilità esclusiva di un team separato, ma venga distribuita attraverso l’intera organizzazione di sviluppo. I developer devono conoscere le vulnerabilità OWASP API Top 10. I team di prodotto devono includere requisiti di sicurezza nelle specifiche. I team di infrastruttura devono garantire che le pipeline espongano segnali di sicurezza rilevabili. Tuttavia, secondo il 2025 State of API Security Report di Traceable AI, basato su oltre 1.500 professionisti IT e cybersecurity, solo il 14% delle organizzazioni ha attualmente una strategia formale di API posture governance. Il gap tra l’ambizione del DevSecOps e la sua attuazione pratica rimane ampio.

Un nodo critico è rappresentato dall’adozione dell’AI generativa nello sviluppo software. La pratica del cosiddetto vibe coding, generare codice API con assistenti AI senza un’adeguata revisione critica, è diventata pervasiva. Secondo Akamai, l’AI-assisted coding è associato a un aumento di misconfigurazioni, impostazioni predefinite insicure e vulnerabilità trascurate nelle API generate. Il 65% delle organizzazioni considera la GenAI un rischio da serio a estremo per la sicurezza delle proprie API. La velocità di sviluppo che l’AI permette amplifica proporzionalmente la superficie esposta se non è accompagnata da un’eguale accelerazione dei controlli di sicurezza.

PSD2, Open Banking e DORA: la sicurezza delle API come obbligo regolatorio

Nel settore finanziario, la sicurezza delle API non è solo una questione tecnica: è un obbligo normativo con conseguenze legali misurabili. La Direttiva PSD2 ha imposto alle banche europee di esporre API dedicate ai Third-Party Provider (TPP), ovvero fintech autorizzate a offrire servizi di pagamento e aggregazione di conti, con requisiti stringenti di Strong Customer Authentication (SCA), dynamic linking e identificazione tramite certificati eIDAS. In questa architettura aperta, ogni vulnerabilità su un’API bancaria è potenzialmente una violazione dei dati del cliente, una frode abilitata dalla piattaforma e una sanzione per la banca emittente.

Le penali per non conformità possono raggiungere il 4% del fatturato annuo o 5 milioni di euro, applicando il criterio più alto. Ma il quadro si è ulteriormente complicato. Con l’accordo politico su PSD3/PSR raggiunto a novembre 2025 e l’adozione formale attesa nel primo semestre 2026, cui seguirà un periodo di transizione di 21 mesi verso l’implementazione completa prevista intorno al 2027, le banche europee si trovano ora a navigare obblighi paralleli e crescenti: responsabilità ampliata per le frodi da impersonificazione, verifica obbligatoria del beneficiario (Verification of Payee), autenticazione a doppia inerenza e benchmark di performance API più severi.

Parallelamente, DORA (il Digital Operational Resilience Act, entrato pienamente in vigore il 17 gennaio 2025) ha unificato il regime di incident reporting per il settore finanziario. L’EBA ha formalmente abrogato le proprie linee guida PSD2 sulla notifica degli incidenti, sostituendole con il framework DORA. Questo cambiamento non è meramente amministrativo: significa che un breach su un’API Open Banking deve ora essere gestito attraverso il prisma della resilienza operativa digitale, con obblighi di notifica armonizzati e un orizzonte di governance che abbraccia l’intera catena tecnologica, incluse le terze parti. Va notato che questa convergenza risolve parzialmente, ma non elimina, la tensione strutturale tra PSD2 (che spinge verso l’apertura dei dati) e il GDPR (che impone la protezione dei dati personali).

Come documentato in uno studio peer-reviewed pubblicato su MDPI nel gennaio 2026, i requisiti sovrapposti di consenso e protezione dei dati creano ancora incertezza nella governance e nell’allocazione delle responsabilità tra banche e TPP, anche alla luce del quadro normativo europeo DORA e NIS2.

Sul piano tecnico, il framework FAPI 2.0 (Financial-grade API Security Profile) ha raggiunto la propria specifica finale nel febbraio 2025, diventando il riferimento per l’implementazione sicura di API ad alto valore. FAPI 2.0 richiede l’uso di Pushed Authorization Requests (PAR), PKCE per tutti i client e token sender-constrained tramite mTLS o DPoP. Il 75% delle banche europee ha già adottato lo standard NextGenPSD2 del Berlin Group.

PCI DSS 4.0.1, diventata l’unica versione attiva dall’aprile 2025, è il primo standard PCI a citare esplicitamente le API come oggetto di controlli di sicurezza: il Requisito 6.4.2 impone soluzioni automatizzate davanti alle API pubbliche per rilevare e prevenire attacchi; il Requisito 6.3.2 richiede un inventario completo di tutto il software custom incluse le API. La non conformità comporta sanzioni tra 5.000 e 100.000 dollari al mese.

La frammentazione persistente nella qualità delle implementazioni rimane una fonte di rischio documentata dalla stessa Commissione Europea, che ha rilevato significative discrepanze negli standard API tra istituti diversi: un problema che PSD3 punta a risolvere attraverso benchmark di performance più stringenti e l’eliminazione definitiva del fallback allo screen scraping.

Verso una maturità sistemica: cosa manca ancora

Osservando il panorama nel suo insieme, la distanza tra il livello di esposizione e il livello di maturità difensiva delle organizzazioni appare strutturalmente preoccupante. Il 57% delle organizzazioni ha subito un breach API negli ultimi due anni, con il 73% di queste che ne ha subiti tre o più. Il 41% dichiara cinque o più episodi. Si tratta di fallimenti sistemici, non di incidenti episodici.

La risposta richiede un cambio di paradigma su più livelli. Primo, il problema della visibilità: non è possibile proteggere ciò che non si conosce. La discovery continua delle API, incluse le shadow API, deve diventare una funzione operativa permanente, non un esercizio periodico. Secondo, il problema della governance: le organizzazioni devono trattare ogni API come un asset critico, con un ciclo di vita documentato, un responsabile identificato, test di sicurezza automatizzati e metriche di esposizione misurabili. Terzo, il problema della cultura: finché la sicurezza API è percepita come un vincolo tecnico imposto a posteriori, anziché come una proprietà architettonica costruita ab initio, il divario tra attaccanti e difensori continuerà ad ampliarsi.

Le previsioni per il 2026 non lasciano spazio all’ottimismo passivo. Akamai stima che le API diventeranno il vettore dominante per i breach a livello applicativo, potenzialmente responsabili di più della metà di tutti gli attacchi alle applicazioni. Il Model Context Protocol, l’infrastruttura che collega gli agenti AI alle API esterne, ha già accumulato 315 vulnerabilità documentate nel 2025, pari al 14,4% di tutte le vulnerabilità AI, con una crescita del 270% tra il secondo e il terzo trimestre. L’interconnessione crescente tra sistemi AI agentici e API di business apre una superficie d’attacco che oggi non è ancora pienamente compresa né adeguatamente presidiata.

Conclusione

Le API sono, nel senso più letterale, i punti di connessione dell’economia digitale. Sono ciò che permette a una banca di condividere i dati di un cliente con un’app fintech, a un ospedale di integrare i referti con un sistema di telemedicina, a una supply chain di coordinare ordini e spedizioni in tempo reale. La loro sicurezza non è un problema tecnico tra gli altri: è una condizione necessaria per la fiducia digitale su cui si regge l’intero ecosistema.

Il paradosso è che questa centralità non si traduce ancora in un’attenzione proporzionale. Le organizzazioni investono in perimetri, in endpoint protection, in SIEM sofisticati e lasciano le API senza inventario, senza test, senza monitoraggio. Solo il 14% ha una strategia formale di governance. Meno di una su cinque riesce a rilevare con sufficiente efficacia gli attacchi che la colpiscono. Gli attaccanti hanno capito dove si trova il valore. La domanda è se le organizzazioni abbiano la stessa chiarezza sul proprio tallone d’Achille e, soprattutto, se abbiano la volontà di trasformare quella consapevolezza in azione prima che sia il prossimo breach a farlo decidere per loro.

https://www.ictsecuritymagazine.com/articoli/sicurezza-delle-api/

L’Open Source Intelligence non è mai stata soltanto una questione di strumenti. È sempre stata, prima di tutto, una questione di metodo: la capacità di trasformare frammenti di informazione pubblica in conoscenza operativa, passando attraverso raccolta, correlazione, verifica e interpretazione. Per decenni, questo processo ha richiesto pazienza, rigore analitico e una buona dose di creatività umana. Oggi, l’intelligenza artificiale sta comprimendo in minuti ciò che richiedeva giorni, e sta aprendo possibilità analitiche che fino a poco tempo fa appartenevano alla fantascienza. Ma sta anche consegnando le stesse capacità a chi ha interesse a fare danno.

Questo è il doppio binario su cui si muove l’AI-OSINT nel 2026: uno strumento di straordinaria utilità difensiva e, al tempo stesso, un moltiplicatore di forza per gli avversari. Capire entrambe le facce non è un esercizio teorico, è una necessità pratica per chiunque lavori nel campo della sicurezza.

Il problema del volume: quando i dati superano la capacità umana

Al cuore dell’OSINT è sempre stata la capacità di usare dati pubblici per risolvere un’indagine, ma oggi il volume ha superato di gran lunga ciò che qualsiasi analista umano può realisticamente gestire. Il web indicizzato, il dark web, i social media, i registri pubblici, le immagini satellitari commerciali, le blockchain, i repository di codice aperti: la superficie informativa disponibile cresce in modo esponenziale, e con essa il rischio che segnali rilevanti si perdano nel rumore.

Secondo un’analisi peer-reviewed condotta da Riccardo Ghioni, Mariarosaria Taddeo e Luciano Floridi dell’Oxford Internet Institute, pubblicata sulla rivista AI & Society nel 2023, l’OSINT costituisce oggi tra l’80 e il 90 per cento di tutte le attività di intelligence condotte dalle forze dell’ordine e dai servizi di sicurezza in Occidente. Questo dato, già significativo, diventa ancora più rilevante se si considera che la mole di dati pubblicamente accessibili continua ad aumentare. L’analista umano, per quanto esperto, incontra un limite fisico invalicabile.

Il mercato globale dell’OSINT riflette questa centralità crescente: secondo Global Market Insights, il settore era valutato 12,7 miliardi di dollari nel 2025 e si prevede raggiunga i 133,6 miliardi entro il 2035, con un tasso di crescita annuo composto del 26,7%. Una traiettoria che segnala un’adozione sistematica, non più sperimentale, in governi, aziende e organizzazioni di sicurezza di tutto il mondo.

Con il calo del costo della potenza di calcolo e la sofisticazione crescente degli algoritmi, quantità sempre maggiori di dati possono essere acquisiti ed elaborati in tempo quasi reale. L’AI non sostituisce il ragionamento dell’analista: abbatte il collo di bottiglia che precede quel ragionamento, liberando risorse cognitive per le fasi a più alto valore aggiunto.

Cosa cambia con i modelli linguistici di grandi dimensioni

L’introduzione dei Large Language Model (LLM) nella toolchain OSINT ha segnato un salto qualitativo rispetto alle generazioni precedenti di automazione. Non si tratta più soltanto di parser e crawler: i modelli linguistici possono leggere, riassumere, tradurre, correlare e suggerire percorsi di indagine su testi non strutturati provenienti da fonti eterogenee.

Lo Stimson Center, nel webinar del 26 marzo 2026 organizzato congiuntamente dallo Strategic Foresight Hub e dall’Energy, Water, and Sustainability Program, ha esaminato come i sistemi guidati dall’AI stiano trasformando la pratica OSINT allargandone le applicazioni attraverso sicurezza, governance e sviluppo sostenibile, analizzando in particolare le pipeline che alimentano modelli di analisi con dati da social media e immagini satellitari, e i sistemi di machine learning che classificano e mappano eventi globali in tempo reale.

Il contributo dei modelli linguistici si articola su più livelli. In fase di raccolta, automatizzano la strutturazione di dati grezzi eterogenei rendendoli immediatamente utilizzabili per analisi successive. In fase di verifica, permettono di confrontare più fonti simultaneamente, incrociare affermazioni e segnalare contraddizioni: un analista che indaga su un profilo sospetto può usare strumenti AI per confrontare nomi utente, biografie e attività in tempo reale, identificando istantaneamente le discrepanze. In fase di esplorazione, suggeriscono nuovi percorsi investigativi quando le piste sembrano esaurite.

La capacità multilingue merita un cenno a parte. L’OSINT operata su scala globale si scontra sistematicamente con la barriera linguistica: la maggior parte dei segnali di interesse non è in inglese. I modelli linguistici attuali trattano questa barriera come una variabile secondaria, non come un ostacolo strutturale. Per approfondire il ruolo dell’AI nella cybersecurity difensiva si rimanda agli approfondimenti della redazione.

Il lato oscuro: i threat actor e l’OSINT potenziata dall’AI

Ogni capacità difensiva ha la sua controparte offensiva. L’AI applicata all’OSINT non fa eccezione, e i dati disponibili nel 2026 disegnano un quadro preoccupante ma anche, almeno per ora, parzialmente rassicurante nelle sue proporzioni effettive.

Per gli attori sostenuti da governi, i modelli linguistici di grandi dimensioni sono diventati strumenti essenziali per la ricerca tecnica, la definizione dei target e la rapida generazione di contenuti di phishing sofisticati. Il report trimestrale di Google GTIG del 12 febbraio 2026 documenta come gruppi legati a Corea del Nord, Iran, Cina e Russia abbiano operazionalizzato l’AI nella seconda metà del 2025, coprendo attività di oltre 57 gruppi APT distinti provenienti da almeno sedici paesi.

Il meccanismo è preciso: i threat actor usano l’AI per accelerare la reconnaissance e trasformare informazioni pubblicamente disponibili in piani di attacco pronti all’uso. Invece di passare manualmente in rassegna siti web, profili social, dati di breach e tracce tecniche, possono usare strumenti AI per sintetizzare grandi volumi di OSINT in note di targeting operative.

Gli LLM possono servire come moltiplicatori strategici durante la fase di reconnaissance, consentendo agli attori malevoli di profilare rapidamente target ad alto valore, identificare i decisori chiave nei settori della difesa e mappare le gerarchie organizzative, passando dalla reconnaissance iniziale al targeting attivo con velocità e scala prima impossibili.

Una precisazione fondamentale è però indispensabile per leggere correttamente questo scenario: GTIG specifica chiaramente che i threat actor stanno sperimentando con l’AI ottenendo guadagni di produttività, ma non stanno ancora sviluppando capacità genuinamente nuove che alterino in modo fondamentale il panorama delle minacce. L’AI agisce come acceleratore della tradecraft esistente, non come generatore di capacità radicalmente diverse.

Il blog Microsoft Security del 6 marzo 2026 ha documentato una dinamica ulteriore: sebbene non ancora osservata su larga scala, la sperimentazione con sistemi di AI agentici segnala un potenziale cambiamento nella tradecraft, dove flussi di lavoro supportati dall’AI assistono sempre più il processo decisionale iterativo e l’esecuzione di compiti, indicando un adattamento più rapido e una maggiore resilienza nelle intrusioni future. In particolare, il gruppo nordcoreano Coral Sleet ha già sviluppato un flusso di lavoro completamente AI-assistito per la creazione di lure, il provisioning di infrastrutture e il testing di payload.

Il termine agentico merita una definizione precisa. A differenza dei modelli linguistici reattivi, i sistemi di AI agentici si basano sugli stessi modelli sottostanti ma sono integrati in flussi di lavoro che perseguono obiettivi nel tempo, pianificando passi, invocando strumenti, valutando risultati e adattando il comportamento senza continui interventi umani.

Ancora più recentemente, al RSAC 2026 di aprile, Microsoft ha presentato dati che mostrano come l’AI stia riducendo le frizioni lungo l’intero ciclo di vita dell’attacco, aiutando i threat actor a fare ricerche più velocemente, scrivere lure migliori, generare o effettuare il debug di malware e triagare i dati rubati. Rimane tuttavia ancora un operatore umano nel ciclo che controlla le campagne, senza AI pienamente autonoma o agentiva che gestisca gli attacchi in modo indipendente.

Il paradosso della disinformazione: l’AI come problema e come soluzione

Esiste una tensione profonda al cuore dell’AI-OSINT che merita di essere nominata esplicitamente. L’AI genera contenuti sintetici in quantità e qualità crescenti, rendendo la verifica dell’informazione sempre più difficile. Al tempo stesso, l’AI è lo strumento principale che abbiamo per operare quella verifica su scala.

Secondo Blackdot Solutions, la disinformazione generata dall’AI e i deepfake rendono più difficile che mai fidarsi di ciò che si vede online. Nel 2026, i professionisti OSINT si trovano ad affrontare un bisogno ancora maggiore di verificare l’autenticità delle informazioni, poiché gli attori malevoli usano strumenti avanzati per manipolare i media e creare identità false convincenti. Sarà cruciale per le organizzazioni assicurarsi che i propri analisti siano addestrati a riconoscere i contenuti generati dall’AI; in caso contrario, rischiano di facilitare involontariamente attività criminali.

La conseguenza pratica è che la catena di verifica dell’OSINT non può più appoggiarsi soltanto sull’analisi semantica del contenuto: deve includere l’analisi della provenienza, della coerenza interna, della contestualizzazione storica e del confronto con fonti primarie di natura diversa. La verifica delle informazioni sulla proprietà effettiva di aziende, per esempio, richiede di confrontare quanto emerge da fonti online con registri societari di fonte ufficiale.

Questo introduce un rischio di concentrazione: chi ha accesso alle fonti migliori e agli strumenti più affidabili costruisce un vantaggio informativo strutturale rispetto a chi ne è privo. La democratizzazione dell’OSINT resa possibile dall’AI porta con sé, paradossalmente, una nuova forma di asimmetria. Il tema si intreccia strettamente con quello della threat intelligence e disinformazione già affrontato sulle pagine di questa rivista.

L’elemento umano: insostituibile, non residuale

Di fronte all’accelerazione tecnologica, si genera spesso una retorica della sostituzione che merita di essere corretta con precisione. Nonostante i progressi tecnologici, il giudizio e l’esperienza umana continueranno a definire i processi OSINT di maggior successo. La migliore difesa contro l’attività criminale guidata dall’AI sarà la combinazione di automazione intelligente e investigatori qualificati, in grado di validare i risultati e garantire gli standard etici.

Il punto non è che gli analisti umani siano superiori ai sistemi AI nei task di elaborazione massiva: non lo sono, e fingere il contrario sarebbe controproducente. Il punto è che l’AI tende a ottimizzare per pattern già noti, mentre l’analista umano è capace di riconoscere l’anomalia che non ha precedenti, di costruire contestualizzazioni che richiedono comprensione culturale profonda, di prendere decisioni in condizioni di ambiguità radicale.

Affidarsi esclusivamente all’AI per la totalità di un’indagine è rischioso a causa delle tendenze alla distorsione e alle allucinazioni. L’esperienza umana rimane cruciale per l’analisi contestualizzata, la verifica e il processo decisionale etico. Bilanciare correttamente l’efficienza dell’AI con l’intuizione umana sarà la chiave del successo nel 2026 e negli anni a venire.

La metafora più utile non è quella della sostituzione ma quella dell’amplificazione: l’AI amplifica le capacità degli analisti preparati e amplifica i limiti di quelli non preparati. Investire nella formazione degli operatori diventa, in questo contesto, una priorità tanto strategica quanto l’investimento negli strumenti.

Verso l’OSINT agentiva: cosa ci aspetta

Il 2026 segna un punto di transizione, non un punto di arrivo. La traiettoria tecnologica indica chiaramente la direzione: sistemi OSINT sempre più autonomi, capaci di monitorare superfici informative in continuo, aggiornare modelli di rischio in tempo reale e produrre intelligence azionabile senza intervento umano nelle fasi di raccolta e prima elaborazione.

Strumenti come Taranis AI navigano attraverso diverse fonti di dati per raccogliere articoli non strutturati, utilizzano il Natural Language Processing e l’AI per migliorare la qualità del contenuto e supportano la condivisione collaborativa di threat intelligence tramite integrazione con MISP. Non si tratta di prototipi di laboratorio, ma di sistemi operativi open source che ridisegnano già oggi il flusso di lavoro degli analisti.

La dimensione etica e di governance non è accessoria a questa trasformazione, ne è parte costitutiva. La convergenza tra AI e OSINT solleva importanti preoccupazioni in termini di governo, implicazioni etiche, legali e sociali, con la necessità di supervisione crescente a fronte di strumenti di analisi sempre più avanzati che richiedono poca o nessuna supervisione continua. Domande come: chi è responsabile delle conclusioni prodotte da un sistema AI-OSINT? Come si gestisce il falso positivo che innesca un’azione operativa? Come si bilancia la capacità di raccolta con il rispetto della privacy degli individui non coinvolti in attività illecite? Queste domande non hanno ancora risposte consolidate, ma richiedono risposte urgenti.

Conclusione: lucidità senza ingenuità

L’AI-OSINT non è una moda tecnologica né una promessa lontana. È una realtà operativa che sta già ridisegnando le pratiche di intelligence, sicurezza e investigazione in tutto il mondo. La sfida per i professionisti della sicurezza non è decidere se adottarla, ma come farlo con lucidità.

Lucidità significa riconoscere le capacità reali senza sovrastimarle: l’AI non elimina l’errore, lo sposta e lo trasforma. Significa comprendere che ogni strumento che rafforza il difensore sta, potenzialmente, rafforzando anche l’offensore: la simmetria dell’accesso è una caratteristica strutturale delle tecnologie generative. Significa anche tenere a mente che, come confermano sia Google GTIG che Microsoft, l’AI agisce oggi come acceleratore della tradecraft esistente e non come generatore di capacità radicalmente nuove: un dato che non va sottovalutato, ma nemmeno usato per abbassare la guardia.

Chi si occupa di sicurezza sa già che il vantaggio non si costruisce su un singolo strumento, ma sulla capacità di integrare strumenti, metodi e giudizio critico in un sistema coerente. L’AI è uno strumento potente. Usarlo bene è, ancora, una questione umana.

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

L’industria della compravendita di dati personali, le tecniche di people search e social media intelligence, i rischi per la sicurezza individuale e le contromisure per chi opera ad alto rischio.

L’ecosistema invisibile che conosce tutto di te

C’è un’industria da quasi 300 miliardi di dollari che non conosci ma che ti conosce molto bene. Sa dove abiti, dove hai abitato in passato, il nome dei tuoi familiari, il numero di targa della tua automobile, la tua storia creditizia, le tue preferenze politiche e, in alcuni casi, il percorso che percorri ogni mattina per andare al lavoro. Non è un servizio di intelligence governativo: è il mercato dei data broker, un ecosistema miliardario e sostanzialmente privo di controllo che opera nell’ombra del web commerciale, trasformando l’identità digitale di centinaia di milioni di persone in una merce negoziabile.

Il mercato globale dei data broker è stato valutato a 294 miliardi di dollari nel 2025, con proiezioni di crescita fino a 315 miliardi nel 2026, in espansione costante trainata dalla domanda di dati arricchiti in tempo reale da parte di settori che vanno dalla pubblicità digitale alla sanità, dalla finanza alla difesa.

La questione non è più teorica. Il 14 giugno 2025, Vance Boelter, 57 anni, ha ucciso la deputata statale del Minnesota Melissa Hortman e suo marito Mark nella loro abitazione, ferendo nella stessa notte il senatore statale John Hoffman e sua moglie. Nel suo SUV le autorità hanno trovato notebook con i nomi di oltre 45 funzionari statali e federali, con gli indirizzi di casa annotati accanto a ciascun nome, e una lista di 11 specifici siti di data broker, con annotazioni su quali fossero gratuiti e quante informazioni richiedessero per restituire dati dettagliati sugli individui ricercati. Non si trattava di un’operazione sofisticata: era intelligence pronta all’uso, venduta legalmente sul mercato aperto.

Il caso non è il primo del genere. Nel luglio 2020, un attaccante si presentò all’abitazione della giudice federale Esther Salas e aprì il fuoco, uccidendo il figlio Daniel Anderl e ferendo il marito. In risposta a quell’episodio, il Congresso americano approvò una legge che vieta ai data broker di rivendere informazioni personali identificabili dei giudici federali, senza tuttavia estendere tale protezione alla generalità degli individui.

Questo è il punto di partenza di ogni riflessione seria sul tema: la privacy non è un’illusione perché qualcuno l’ha violata. È un’illusione perché abbiamo collettivamente costruito un’infrastruttura progettata per renderla tale.

Anatomia di un mercato: chi sono i data broker

I data broker sono aziende che raccolgono, aggregano, elaborano e rivendono informazioni personali provenienti da fonti eterogenee: registri pubblici (atti catastali, cartelle esattoriali, registri elettorali, documenti giudiziari), piattaforme di social media, programmi fedeltà della grande distribuzione, app mobile, moduli di garanzia prodotto, tracciatori web e cookie. La grande maggioranza delle persone non sa che questa industria esiste, né che i propri dati vengono compravenduti. Eppure, poiché le informazioni trattate dai broker sono tecnicamente di pubblico dominio, l’attività non è illegale.

Il mercato si articola in tre segmenti principali, spesso sovrapposti.

Il primo è costituito dai people search engine: Spokeo, Whitepages, BeenVerified, Intelius. Sono i più accessibili e raschiano continuamente registri pubblici (registrazioni elettorali, atti di proprietà, documenti giudiziari) combinandoli con dati commerciali per costruire profili individuali completi. Per pochi euro, chiunque può acquistare nome completo, storico degli indirizzi, numero di telefono e nomi di conviventi e parenti.

Il secondo segmento comprende i data aggregator e gli enrichment provider, un livello più sofisticato orientato al mercato business-to-business: Acxiom, LexisNexis Risk Solutions, Equifax (nella sua divisione commerciale), TransUnion. Vendono «profili arricchiti» a istituzioni finanziarie, compagnie assicurative, agenzie pubblicitarie e, come documentato, ad agenzie governative.

Le forze dell’ordine possono acquisire dati di localizzazione senza ottenere mandati giudiziari, acquistandoli da broker commerciali. I criminali informatici acquistano dati personali per eseguire attacchi di social engineering mirati: con profili dettagliati possono costruire messaggi convincenti che fanno riferimento a dettagli personali specifici, aumentando drasticamente i tassi di successo rispetto a campagne generiche. I gruppi ransomware utilizzano i data broker per trovare bersagli da colpire con spear phishing e per ottenere contatti da name-dropping nelle email, rendendole più credibili.

Il terzo segmento, il più critico sul piano della sicurezza, è quello ibrido tra aggregazione di dati e intelligenza artificiale applicata al riconoscimento biometrico. Il caso emblematico è Clearview AI.

Clearview AI: quando il volto diventa una chiave di ricerca

Clearview AI rappresenta il caso più perturbante nell’intera storia del data brokerage. Fondata nel 2017, l’azienda ha sviluppato un sistema proprietario di web scraping che ha indicizzato immagini fotografiche provenienti da miliardi di pagine web pubbliche (profili social, forum, siti di notizie) costruendo un database biometrico facciale senza precedenti. Al 21 gennaio 2026, Clearview AI ha aggiornato la propria documentazione ufficiale dichiarando che il database conta ormai oltre 70 miliardi di immagini, ciascuna indicizzata tramite marker biometrici facciali che consentono di identificare qualsiasi persona rilevata in una fotografia, restituendo al ricercatore tutte le altre immagini pubblicamente disponibili di quello stesso individuo, i link alle pagine sorgente e i relativi metadati.

Il modello di business è semplice quanto inquietante: chiunque disponga di accesso alla piattaforma può caricare una fotografia di un individuo sconosciuto, scattata per strada, in un ristorante o a una manifestazione pubblica, e ottenere in pochi secondi la sua identità completa, i profili social e ogni immagine pubblica disponibile sul web. La preoccupazione fondamentale riguarda la natura non revocabile dei dati biometrici: a differenza di un numero di previdenza sociale o di un numero di carta di credito, i dati biometrici non possono essere resettati se finiscono nelle mani di un attore malevolo.

In Europa, il caso ha generato una risposta regolamentare articolata. Le autorità di Francia, Grecia, Italia e Paesi Bassi hanno imposto sanzioni per circa 100 milioni di euro complessivi a Clearview per le sue pratiche invasive. Il Garante italiano ha irrogato una multa di 20 milioni di euro nel febbraio 2022, la sanzione massima prevista dal GDPR per i casi non parametrati al fatturato, ordinando contestualmente la cancellazione di tutti i dati relativi a cittadini italiani e la nomina di un rappresentante nell’Unione europea.

La multa rimane non pagata e i dati degli italiani sono ancora presenti nei server di Clearview: il Commissario del Garante Guido Scorza ha dichiarato nel 2025 di stare lavorando con la Federal Trade Commission americana per notificare formalmente la sanzione e aprire un canale di enforcement bilaterale.

Di fronte all’incapacità delle autorità amministrative di riscuotere le sanzioni, l’organizzazione per i diritti digitali noyb ha depositato nell’ottobre 2025 una denuncia penale contro Clearview AI e i suoi dirigenti in Austria, sfruttando le disposizioni del GDPR che consentono agli Stati membri di prevedere sanzioni penali. Se la denuncia dovesse avere successo, i dirigenti di Clearview AI potrebbero rischiare il carcere ed essere ritenuti personalmente responsabili, in particolare in caso di viaggio in Europa.

Le autorità europee per la protezione dei dati non sono riuscite finora a far valere le proprie sanzioni nei confronti dell’azienda americana, consentendole di eludere di fatto la legge. Il 19 febbraio 2026, la Corte d’Appello della British Columbia ha respinto il ricorso di Clearview AI, confermando che l’azienda è soggetta alle leggi canadesi sulla privacy nonostante abbia abbandonato il mercato canadese durante le indagini.

Il paradosso finale è rivelatorio: in febbraio 2026 il 1° Comando delle Forze Speciali dell’Esercito americano, i Green Berets, ha rinnovato il contratto con Clearview AI per un potenziale impegno quadriennale, con documentazione contrattuale che specifica l’accesso a circa 50 miliardi di immagini e un’accuratezza minima del 98%. Clearview è ora definita nei documenti ufficiali del Pentagono non più un complemento sperimentale, ma un componente consolidato dell’architettura di intelligence delle operazioni speciali.

OSINT offensivo: l’intelligence che non ha bisogno di hacker

L’OSINT (Open Source Intelligence) è la disciplina di raccolta e analisi di informazioni provenienti da fonti pubblicamente accessibili. Come abbiamo approfondito in questo magazine nel nostro articolo dedicato al ruolo dell’OSINT nella sicurezza, nella sua forma difensiva si tratta di uno strumento fondamentale per i team di sicurezza: nel 2026 questa pratica è diventata una capacità core per i threat analyst e i security leader, in grado di supportare il threat modeling, il rilevamento di credenziali trapelate e la mappa delle esposizioni esterne di un’organizzazione.

Ma lo stesso arsenale di tecniche e strumenti, nelle mani sbagliate o in assenza di vincoli etici, diventa OSINT offensivo: un processo sistematico di raccolta di intelligence su individui a scopo di danneggiamento, coercizione, stalking o attacco mirato. Le tecniche operative principali che un analista OSINT e le sue tecniche conoscono nella versione difensiva trovano un corrispettivo diretto nella versione offensiva.

Il footprinting digitale consiste nella ricerca sistematica del target su motori di ricerca, social network (LinkedIn, Facebook, Instagram, X/Twitter), siti professionali, registri camerali e catastali, elenchi telefonici e archivi di notizie. Un analista OSINT esperto può costruire un profilo completo di un individuo in meno di un’ora utilizzando solo strumenti gratuiti.

Il reverse image search e riconoscimento facciale sfrutta il caricamento di una fotografia pubblica su motori di ricerca visivi o su piattaforme come Clearview AI per risalire all’identità di un individuo e aggregare tutte le sue immagini pubbliche, ricostruendo movimenti, relazioni e abitudini.

Il metadata harvesting è una tecnica spesso sottovalutata: ogni foto scattata con uno smartphone contiene metadati EXIF che possono includere coordinate GPS precise, modello del dispositivo, data e ora. Le immagini pubblicate sui social raramente vengono «purificate» di questi dati. Gli stalker usano la cosiddetta GEOINT (intelligenza geospaziale) per identificare catene montuose, insegne di negozi o architetture uniche nello sfondo dei selfie e determinare la posizione del soggetto con precisione sorprendente.

Il cross-referencing e de-anonimizzazione sfrutta la correlazione di dati provenienti da fonti diverse (un nickname usato su Reddit con un indirizzo email di un forum di nicchia, un profilo LinkedIn e un documento pubblico) per de-anonimizzare persone che credono di essere irrintracciabili.

Il data enrichment via broker API è la fase finale: i dati raccolti liberamente vengono arricchiti acquistando profili da data broker, ottenendo l’indirizzo fisico, la storia abitativa, i numeri di telefono e i nomi dei familiari conviventi.

Il risultato è quello che i professionisti della sicurezza chiamano un dossier completo: un documento strutturato che, nelle mani di un attore malevolo, è sufficiente per pianificare un attacco di spear phishing altamente personalizzato, uno stalking fisico, un’operazione di doxing o, nel peggiore dei casi, un’aggressione fisica.

I rischi reali: doxing, stalking, attacchi mirati

Le conseguenze dell’OSINT offensivo alimentato dai data broker non sono astratte. Sono misurabili, documentate e in crescita esponenziale.

Il doxing automatizzato e potenziato dall’AI. Gli strumenti di data scraping automatizzato consentono agli attori malevoli di assemblare profili personali con sforzo minimo. I media sintetici, inclusi il voice cloning e la manipolazione delle immagini, hanno abilitato false segnalazioni e impersonificazioni sempre più convincenti. Il 2025 ha visto avvertimenti dell’FBI e dei principali organi di informazione riguardo all’uso crescente di questi strumenti in campagne di harassment organizzato.

La frontiera più recente è la convergenza tra data broker e Large Language Model: storicamente il doxing richiedeva un effort significativo (navigare in oscuri siti di people search, incrociare registri pubblici, pagare piccole tariffe a vari data broker). I chatbot AI hanno rimosso questo attrito: addestrati su dataset massicci raschiati dal web aperto, incluso il contenuto di migliaia di siti di data broker, un modello linguistico mal configurato o deliberatamente abusato può diventare un motore di aggregazione OSINT in tempo reale.

Il doxing come arma politica e sociale. Circa 11,7 milioni di adulti americani (il 4% della popolazione) sono stati vittime di doxing e una persona su sei conosce un amico o un familiare che lo è stato. Il 57% degli americani evita di condividere opinioni politiche online per paura di essere colpito da operazioni di doxing. Il fenomeno si manifesta in forme sempre più organizzate: campagne di blacklisting che mettono a rischio impieghi, status legali e incolumità fisica dei bersagli.

Lo stalking fisico digitalmente potenziato. La disponibilità di informazioni di contatto sensibili pone rischi specifici per coloro che vengono presi di mira a causa della loro professione (giudici, ufficiali di polizia, procuratori, altri dipendenti governativi) nonché per le vittime di violenza domestica, che rischiano di vedere la propria nuova residenza rintracciata tramite data broker.

Gli attacchi mirati a executive e professionisti ad alto rischio. Il Security Executive Council documenta 424 incidenti di targeting di executive nel periodo 2003-2025, con la frequenza degli incidenti che ha già raddoppiato i totali del 2024 entro ottobre 2025, segnando il livello più alto mai registrato. Un terzo di tutti gli incidenti si è concluso con un ferito o una vittima. L’85% degli incidenti è di natura fisica. I profili sono costruiti attraverso data broker e poi usati per personalizzare phishing, impersonificazione e, in casi estremi, attacchi fisici programmati.

Il quadro regolatorio: avanzamenti strutturali e lacune persistenti

Sul piano normativo, il 2026 segna un momento di svolta significativo almeno per la California. Il 1° gennaio 2026, la California Privacy Protection Agency ha lanciato il Delete Request and Opt-Out Platform (DROP): un servizio pubblico senza precedenti che consente ai residenti californiani di inviare una singola richiesta di cancellazione a tutti i data broker registrati in California, completamente gratuita. I data broker sono obbligati a iniziare a processare le richieste a partire dal 1° agosto 2026, rinnovando la cancellazione ogni 45 giorni.

Sul piano regolatorio più ampio, le leggi di «seconda generazione» che vanno oltre i diritti dei consumatori per regolare i data broker, la trasparenza algoritmica e il processo decisionale automatizzato prolifereranno nel 2026. I temi di enforcement si concentreranno sul profiling algoritmico opaco, sui fallimenti di trasparenza dei data broker e sulle richieste di cancellazione non gestite correttamente.

In Europa, il GDPR fornisce una protezione strutturalmente più robusta, ma la sua applicabilità agli attori extra-UE rimane la debolezza cruciale, come dimostra paradigmaticamente il caso Clearview. Preoccupazioni di sicurezza nazionale sono emerse anche in relazione a broker che vendono informazioni su veterani e manifestanti ad avversari stranieri: l’Office of the Director of National Intelligence ha riconosciuto formalmente che questa industria può minacciare le libertà civili e la sicurezza dei cittadini americani.

Contromisure per individui ad alto rischio

La protezione dalla sorveglianza commercializzata non è un problema che si risolve con un singolo strumento o un’unica azione. Per i profili ad alto rischio, la protezione più efficace connette la rimozione dai data broker con il monitoraggio OSINT, la soppressione dell’indicizzazione e la competenza di sicurezza umana. Va considerato che anche le migliori soluzioni manuali o basate su script raggiungono un’efficacia di rimozione del 68-70%, lasciando circa uno su tre profili intatto: poiché i data broker ri-aggregano e ri-pubblicano continuamente le informazioni, anche le rimozioni riuscite richiedono manutenzione continua.

Le misure concrete si articolano su quattro livelli.

Riduzione proattiva della superficie d’attacco digitale. Audit periodico della propria presenza online: verificare cosa appare cercando il proprio nome sui principali motori di ricerca, identificare i profili sui people search engine e inviare richieste di opt-out o rimozione individuali. In Europa, gli interessati possono esercitare il diritto alla cancellazione ex art. 17 GDPR direttamente verso i data broker che trattano dati personali. Il processo richiede persistenza: i dati vengono periodicamente ri-aggregati.

Separazione tra identità fisica e identità digitale. Per professionisti ad alto rischio (magistrati, giornalisti, dirigenti aziendali, figure politiche) è essenziale che l’indirizzo fisico di residenza non sia associabile all’identità pubblica. Ciò implica l’uso di caselle postali private o servizi di domiciliazione per le comunicazioni ufficiali, l’utilizzo di indirizzi di agenti registrati per partite IVA e società e la revisione sistematica di tutti i documenti pubblici (registri catastali, visure camerali) che possono rivelare la residenza effettiva.

Igiene operativa su social media e metadati. È necessario configurare tutti gli account in modalità privata come impostazione predefinita, disabilitare la geolocalizzazione nelle applicazioni fotografiche, rimuovere i metadati EXIF dalle immagini prima della pubblicazione (tramite strumenti come ExifTool o le funzioni integrate nei sistemi operativi) ed evitare di pubblicare informazioni che rispondano alle domande di sicurezza tipiche (nome da nubile, istituto scolastico, nome dell’animale domestico). Le immagini dovrebbero essere controllate per i riferimenti a punti di riferimento fisici: gli stalker usano l’intelligenza geospaziale per identificare catene montuose, insegne di negozi o architetture uniche nello sfondo dei selfie e determinare la posizione del soggetto.

Monitoraggio continuo e risposta agli incidenti. La protezione non è un’azione una tantum ma un processo continuativo. È opportuno impostare Google Alert sul proprio nome e sulle varianti dello stesso, monitorare periodicamente i risultati di ricerca immagini inversa e, per i profili più esposti, valutare servizi specializzati di executive protection digitale che combinino rimozione dai data broker, monitoraggio del dark web e intelligence OSINT difensiva. Un’esposizione incompleta può creare un falso senso di sicurezza: un individuo che crede che i propri dati personali siano stati rimossi può essere meno vigile riguardo all’esposizione residua, mentre gli attori che prendono di mira persone di alto valore sono abili nel trovare esattamente ciò che gli strumenti automatizzati hanno mancato.

Conclusione: la privacy come scelta di sistema

Il mercato dei data broker non è un’anomalia del capitalismo digitale. È la sua espressione più coerente: la trasformazione dell’identità umana in un asset negoziabile, in assenza di regole che impongano costi reali a chi commercia in questo asset. La tendenza strutturale è chiara: l’OSINT diventerà sempre più automatizzato, più continuo e più integrato con i sistemi di rilevamento e risposta. L’intelligenza artificiale aiuterà a stabilire priorità tra i segnali, identificare correlazioni deboli e ridurre il rumore. Regolatori e organizzazioni richiederanno simultaneamente una maggiore responsabilità riguardo all’uso dei dati aperti.

La consapevolezza individuale è necessaria ma non sufficiente. Le contromisure tecniche aiutano, ma operano su un terreno strutturalmente sfavorevole: ogni dato rimosso oggi può essere ri-aggregato domani da una fonte diversa. La vera soluzione è sistemica. Richiede che la regolamentazione imponga obblighi di trasparenza, limiti all’aggregazione, diritti di cancellazione effettivamente eseguibili anche nei confronti di attori extra-UE, e sanzioni proporzionali al danno causato, non solo nei confronti delle violazioni eclatanti, ma nei confronti del modello di business stesso.

Fino ad allora, l’intelligence è in vendita. E chiunque può comprarla.

https://www.ictsecuritymagazine.com/articoli/data-broker-osint/

Cyber Resilience Act obblighi 2026: il 2026 segna una fase decisiva nell’attuazione del regolamento europeo sulla cibersicurezza, con l’avvio dei primi adempimenti operativi per fabbricanti, importatori e distributori. Le nuove regole riguardano la gestione delle vulnerabilità, la notifica degli incidenti e la conformità dei prodotti digitali, introducendo responsabilità concrete già prima della piena applicazione del quadro normativo. L’articolo analizza le principali scadenze e l’impatto reale della normativa sulle imprese europee.

Il Regolamento (UE) 2024/2847 è entrato in vigore il 10 dicembre 2024, ma il 2026 segna il primo grande banco di prova operativo per fabbricanti, importatori e distributori: due scadenze, quella di giugno e quella di settembre, anticipano il regime completo del 2027 e introducono obblighi già oggi sanzionabili. Ecco cosa cambia davvero.

Il CRA in sintesi: perché è una svolta normativa

Il Cyber Resilience Act, ufficialmente Regolamento (UE) 2024/2847, è la prima legislazione a livello di tutta l’Unione Europea che introduce norme comuni di cibersicurezza per i produttori e gli sviluppatori di prodotti con elementi digitali, coprendo sia la componente hardware sia quella software.

L’obiettivo non è solo sanzionatorio. Il CRA introduce requisiti obbligatori di cibersicurezza per i fabbricanti, che riguardano la pianificazione, la progettazione, lo sviluppo e la manutenzione dei prodotti. Tali obblighi devono essere rispettati in ogni fase della catena del valore.

Per capire la portata della riforma, basta guardare ai numeri che l’hanno motivata. Il costo globale stimato del cybercrimine era pari a 5,5 trilioni di euro nel 2021, con molti prodotti digitali che presentano vulnerabilità diffuse e ricevono aggiornamenti di sicurezza insufficienti o incoerenti, esponendo utenti e società a rischi significativi.

Cyber Resilience Act obblighi 2026: calendario di applicazione e tre tappe

Il CRA non è entrato in vigore tutto in una volta. La struttura temporale è articolata in tre momenti distinti, ciascuno con obblighi specifici.

Il Regolamento 2024/2847 si applica dall’11 dicembre 2027, ma l’Articolo 14, sugli obblighi di segnalazione delle vulnerabilità da parte dei fabbricanti, si applica a decorrere dall’11 settembre 2026. Il Capo IV, sulla notifica degli organismi di valutazione della conformità agli articoli da 35 a 51, si applica invece a decorrere dall’11 giugno 2026.

Il 2026, dunque, non è un anno di transizione passiva: è l’anno in cui gli obblighi operativi cominciano a produrre effetti giuridici concreti.

11 giugno 2026: entra in vigore il Capitolo IV

L’11 giugno 2026 entra in vigore il Capitolo IV del CRA, che disciplina la notificazione degli organismi di valutazione della conformità.

Questa disposizione ha implicazioni dirette sulla struttura del mercato europeo della certificazione. Gli organismi che intendono operare come valutatori di conformità per i prodotti con elementi digitali devono essere ufficialmente notificati dalle autorità nazionali competenti entro questa data. Si tratta di un passaggio abilitante: senza un sistema di organismi notificati operativo, i produttori delle categorie più critiche non potrebbero completare il percorso di valutazione richiesto dal regolamento per l’accesso al mercato UE.

Per le aziende coinvolte, questo significa dover verificare con anticipo se l’organismo di certificazione prescelto abbia già avviato o completato il processo di notifica nel proprio Stato membro.

11 settembre 2026: gli obblighi di segnalazione diventano vincolanti

La scadenza più impattante del 2026 è quella di settembre. Il Regolamento (UE) 2024/2847 si applica a partire dall’11 dicembre 2027, mentre l’Articolo 14, riguardante gli obblighi di segnalazione dei fabbricanti, si applica a decorrere dall’11 settembre 2026.

Le tempistiche di notifica previste dall’Articolo 14 seguono una struttura a cascata, confermata dalla pagina ufficiale della Commissione europea dedicata agli obblighi di comunicazione del CRA.

I fabbricanti devono presentare un allarme rapido entro 24 ore dal momento in cui vengono a conoscenza della vulnerabilità e una notifica completa entro 72 ore. Una relazione finale deve essere presentata entro 14 giorni dalla disponibilità di una misura correttiva per le vulnerabilità attivamente sfruttate, ed entro un mese per gli incidenti gravi.

Un dettaglio procedurale rilevante riguarda il canale di notifica. I fabbricanti riferiscono attraverso la piattaforma unica di comunicazione del CRA (Single Reporting Platform). La notifica è indirizzata al CSIRT dello Stato membro in cui il fabbricante ha il proprio stabilimento principale e, salvo circostanze particolarmente eccezionali, le informazioni sono messe a disposizione simultaneamente dell’ENISA.

La conformità a questi obblighi di segnalazione si intreccia con quanto già previsto dalla Direttiva NIS2, che impone regimi analoghi di notifica degli incidenti agli operatori di settori critici. Le aziende soggette a entrambe le normative dovranno coordinare i propri processi interni per evitare duplicazioni e garantire la coerenza delle segnalazioni verso i diversi destinatari istituzionali.

Cosa devono fare i fabbricanti: gli obblighi strutturali

Anche se la piena applicabilità è prevista per il 2027, gli obblighi strutturali del CRA richiedono una preparazione che deve partire ora. Il regolamento introduce obblighi fondamentali: i produttori devono incorporare la sicurezza informatica nei loro prodotti fin dalla fase di sviluppo, fornendo prodotti configurati per essere sicuri di default; rimangono responsabili della sicurezza del prodotto per tutto il suo ciclo di vita; devono effettuare un’autovalutazione o ricorrere a una terza parte per dimostrare la propria conformità; e devono comunicare chiaramente le caratteristiche di sicurezza e le buone pratiche d’uso ai clienti finali.

Sul fronte della gestione delle vulnerabilità, il CRA richiede ai fabbricanti una gestione strutturata delle vulnerabilità per l’intero periodo di assistenza del prodotto, pari ad almeno cinque anni o alla durata d’uso prevista se inferiore, con l’obbligo di creare e mantenere una SBOM (Software Bill of Materials) con le dipendenze di primo livello.

Le norme tecniche armonizzate: le scadenze del 2026

Un aspetto spesso sottovalutato riguarda lo sviluppo degli standard tecnici armonizzati, senza i quali la dimostrazione sistematica della conformità al CRA risulta più complessa. La data limite per l’adozione delle norme orizzontali di tipo A e delle norme di tipo B per la gestione delle vulnerabilità è prevista entro il 30 agosto 2026. Le norme di tipo C per le singole categorie di prodotti devono essere disponibili entro il 30 ottobre 2026, mentre le norme di tipo B per le misure tecniche seguiranno entro il 30 ottobre 2027.

CEN, CENELEC ed ETSI sono i principali organismi incaricati di sviluppare questi standard su mandato della Commissione, nell’ambito della richiesta di normazione M/606 che comprende 41 norme a supporto del CRA.

Prodotti importanti e critici: le categorie ad obblighi rafforzati

Il 1° dicembre 2025 è stato pubblicato nella Gazzetta ufficiale dell’UE il Regolamento di esecuzione (UE) 2025/2392, che include la descrizione tecnica delle categorie di prodotti con elementi digitali importanti (Allegato III) e critici (Allegato IV) del CRA. I prodotti importanti con elementi digitali sono suddivisi in Classe I, che comprende ad esempio sistemi di gestione delle password, sistemi di gestione delle informazioni e sistemi operativi, e Classe II.

Per i prodotti rientranti in queste classi, la valutazione di conformità non può essere autocertificata: è obbligatorio il ricorso a un organismo notificato terzo, rendendo la scadenza dell’11 giugno 2026 ancora più strategica sul piano operativo.

Il quadro sanzionatorio: tre livelli distinti

Il testo autentico dell’Articolo 64 del Regolamento (UE) 2024/2847 articola le sanzioni su tre livelli di gravità crescente.

La non conformità ai requisiti essenziali di cibersicurezza di cui all’Allegato I e agli obblighi degli articoli 13 e 14 è soggetta a sanzioni amministrative pecuniarie fino a 15.000.000 euro o, se l’autore del reato è un’impresa, fino al 2,5% del fatturato mondiale totale annuo dell’esercizio precedente, se superiore.

La non conformità agli obblighi relativi a rappresentanti autorizzati, importatori, distributori, dichiarazione di conformità, marcatura CE, documentazione tecnica e valutazione di conformità è soggetta a sanzioni fino a 10.000.000 euro o, se l’autore del reato è un’impresa, fino al 2% del fatturato mondiale totale annuo. Un terzo livello, fino a 5.000.000 euro o l’1% del fatturato, si applica per informazioni inesatte o fuorvianti fornite alle autorità.

Le sanzioni previste devono essere effettive, proporzionate e dissuasive. Spetta agli Stati membri fissare le norme nazionali di applicazione nel rispetto di questi massimali europei.

Il CRA nel contesto normativo europeo

Il Cyber Resilience Act non opera in isolamento. Il CRA si colloca all’interno di un quadro normativo europeo in continua evoluzione e trova un forte punto di connessione con il Cybersecurity Act, che definisce il sistema europeo di certificazione della sicurezza informatica, e con la Direttiva NIS2, che impone obblighi di gestione dei rischi e notifiche di incidenti a numerosi settori strategici.

Il biennio 2026-2027 concentra l’entrata in vigore di sei normative chiave: NIS2, Cyber Resilience Act, DORA, AI Act, nuovo Regolamento Macchine e Data Act. Per le aziende italiane ed europee, questa sovrapposizione di scadenze rende necessario un approccio integrato alla compliance, evitando di trattare ciascun regolamento come un percorso separato.

Sul tema dell’interazione tra il CRA e il più ampio quadro di governance della cybersecurity europea, ICT Security Magazine ha approfondito le implicazioni del DORA e dell’AI Act per le organizzazioni italiane, offrendo un riferimento utile per chi deve gestire più obblighi normativi in parallelo.

Cosa fare adesso

Per chi produce, importa o distribuisce prodotti con elementi digitali, il 2026 non è un anno di attesa. Le priorità operative da affrontare oggi riguardano la mappatura del portafoglio prodotti rispetto alle categorie del Regolamento di esecuzione (UE) 2025/2392; la verifica dello stato di notifica degli organismi di valutazione della conformità nel proprio Stato membro entro l’11 giugno; la predisposizione di processi interni per la rilevazione e la notifica delle vulnerabilità entro le tempistiche dell’Articolo 14, ovvero 24 ore per l’allarme rapido, 72 ore per la notifica completa, 14 giorni per il rapporto finale sulle vulnerabilità attivamente sfruttate e 30 giorni per gli incidenti gravi; e infine l’avvio della SBOM per tutti i prodotti con dipendenze software rilevanti.

Il Cyber Resilience Act non chiede alle aziende di essere perfette il giorno dell’applicazione: chiede di essere pronte. E la distanza tra i due traguardi si misura in mesi, non in anni.

https://www.ictsecuritymagazine.com/articoli/cyber-resilience-act-obblighi-2026/

C’è una minaccia che non compare nei log di sicurezza, non genera alert sulle dashboard SIEM e non viene discussa nei consigli di amministrazione. Eppure erode la resilienza delle organizzazioni con una costanza che molti attori malevoli si sognerebbero: è il burnout dei professionisti della cybersecurity. Un fenomeno strutturale, non episodico, che nel 2025 e nel 2026 ha raggiunto dimensioni tali da rendere indifferibile una risposta sistemica.

I numeri di una crisi annunciata

I dati più recenti disegnano uno scenario allarmante. Il report The Human Cost of Vigilance di Sophos, condotto su 5.000 professionisti IT e cybersecurity in 17 paesi nel primo trimestre del 2025, ha rilevato che il 76% degli intervistati ha sperimentato cyber fatigue o burnout in modo costante, frequente o occasionale nell’arco del 2024. Il 69% ha dichiarato che il fenomeno è peggiorato rispetto all’anno precedente. Il 39% ha ammesso una riduzione della propria produttività lavorativa, il 33% un calo dell’engagement, mentre il 46% ha riferito un’ansia aumentata rispetto al rischio di cyberattacchi e violazioni dei dati.

Il report State of Cyber Risk and Exposure 2025 di Bitsight, basato su un campione di oltre 1.000 professionisti della sicurezza, ha fotografato una realtà analoga: il 47% ha dichiarato di vivere qualche grado di burnout, con oltre uno su dieci che descrive la propria condizione come acuta, vale a dire prossima all’abbandono della professione. Il report Voice of the CISO 2025 di Proofpoint si allinea su cifre simili: il 63% dei CISO ha vissuto o osservato direttamente episodi di burnout nel corso dell’anno.

I dati più aggiornati provengono dal 2026 State of the Cybersecurity Workforce Report di Seemplicity, condotto da Sapio Research su 300 responsabili della sicurezza negli Stati Uniti nel gennaio 2026 e pubblicato il 3 marzo. La ricerca documenta che i professionisti cyber lavorano in media 10,8 ore straordinarie settimanali oltre al contratto, il che equivale a una sesta giornata lavorativa. Il 45% supera le 11 ore extra a settimana, il 20% ne lavora più di 16 aggiuntive. Il 44% dichiara che il proprio ruolo è emotivamente più spossante che gratificante, una percentuale che sale al 56% tra i responsabili di livello C.

Non si tratta di statistiche isolate. Il 2026 SANS | GIAC Cybersecurity Workforce Research Report, presentato all’RSAC 2026 su un campione di 947 professionisti, responsabili HR e decision maker di sei regioni globali, documenta che il 61% delle organizzazioni registra un aumento dello stress nei team di sicurezza negli ultimi due anni. I principali fattori citati: sovraccarico di lavoro e sottodimensionamento degli organici (46%), vincoli di budget (40%) e complessità crescente delle minacce (40%).

Le cause strutturali: molto oltre la stanchezza

Sarebbe riduttivo leggere il burnout nella cybersecurity come semplice affaticamento da lavoro eccessivo. Le sue radici affondano in condizioni strutturali che nessuna misura di welfare aziendale può sanare da sola.

Alert fatigue: il paradosso della sorveglianza continua

Il Security Operations Center (SOC) è l’ambiente in cui la crisi si manifesta con maggiore intensità. La ricerca pubblicata sull’ACM Computing Surveys identifica quattro macro-cause di alert fatigue nel SOC: l’alto ritmo di generazione degli alert, il volume assoluto di notifiche, l’elevata percentuale di falsi positivi e la varietà crescente delle tipologie di minaccia, che rende rapidamente obsolete le regole di rilevamento basate su firme statiche.

I numeri operativi parlano da soli. Secondo l’AI SOC Market Landscape 2025, le organizzazioni affrontano in media 960 alert di sicurezza al giorno, con le realtà che superano i 20.000 dipendenti che ne gestiscono più di 3.000. Il SANS 2025 SOC Survey conferma che il 66% dei team non riesce a tenere il passo con i volumi in arrivo.

Una ricerca di Trend Micro, citata nell’analisi ACM, rileva che il 51% dei team SOC si sente sopraffatto dal volume degli alert, con gli analisti che spendono oltre il 25% del loro tempo a gestire falsi positivi. Il 40% degli alert non viene mai analizzato, mentre il 61% dei team ha ammesso di aver ignorato notifiche che si sono poi rivelate critiche.

L’effetto è pernicioso: l’analista si desensibilizza. Il segnale reale si perde nel rumore. E quella desensibilizzazione non è un’anomalia comportamentale: è una risposta adattiva del sistema nervoso umano a un input cognitivo insostenibile. Palo Alto Networks ricorda un caso emblematico: nella violazione Target del 2013, gli strumenti di sicurezza avevano rilevato correttamente il malware, ma gli analisti SOC, sepolti dagli alert, non avevano dato priorità ai segnali critici. Il danno fu la sottrazione di dati da oltre 40 milioni di carte di pagamento.

Understaffing e carichi asimmetrici

La carenza strutturale di talenti amplifica ogni altra causa. Il Cybersecurity Workforce Study 2024 di ISC2, condotto su un campione record di 15.852 professionisti, documenta che il 67% delle organizzazioni segnalava carenze di personale nei team di sicurezza, con un gap globale di posizioni scoperte pari a 4,8 milioni di ruoli a livello mondiale, in crescita del 19% rispetto all’anno precedente. Il report ISC2 del 2025, pubblicato a dicembre, rileva un leggero miglioramento nei livelli di organico, ma segnala per la prima volta che il problema della carenza di skill ha superato quello del puro headcount: il 59% dei professionisti indica lacune critiche o significative di competenze, contro il 44% dell’anno precedente.

La ricerca di Bitsight rileva una dinamica particolarmente rilevante: i team più piccoli sono doppiamente più esposti al burnout rispetto a quelli ben strutturati. Ma anche nei programmi ben dotati di risorse, quasi un professionista su quattro manifesta segnali di esaurimento. L’equazione è impietosa: meno personale significa carichi maggiori su chi resta, il che accelera il turnover, che a sua volta aggrava la carenza, in un ciclo autoalimentante.

Aspettative irrealistiche e cultura dell’eroismo

Un terzo vettore, spesso sottovalutato, è culturale. La cybersecurity esige una vigilanza paragonabile a quella dei controllori di volo o dei medici d’urgenza: un singolo errore può avere conseguenze catastrofiche e tracciabili. Questa responsabilità genera un carico emotivo che va ben oltre il volume di lavoro misurabile. Chi entra in questo settore lo fa spesso con forte motivazione identitaria, vale a dire con la consapevolezza di proteggere infrastrutture critiche, dati sensibili, vite umane. Quella stessa motivazione diventa combustibile per il burnout quando le condizioni organizzative non reggono il peso di quelle aspettative.

A questo si aggiunge un fenomeno emergente che James Lyne, CEO di SANS Institute, ha denominato AI fry: l’adozione massiccia di strumenti di intelligenza artificiale, pensata per alleviare i carichi di lavoro, produce paradossalmente un aumento del burnout attraverso il continuo cambio di contesto cognitivo. Come ha dichiarato Lyne all’RSAC 2026: «I rarely talk to teams that aren’t running some version of 100%». Le organizzazioni stanno sovrapponendo responsabilità di AI governance ai team di sicurezza senza ridisegnare i ruoli. Come ha osservato Ravid Circus, CPO di Seemplicity, a Help Net Security nel marzo 2026: aggiungere AI oversight senza riprogettare l’organizzazione accelera il burnout. È l’organigramma stesso che deve essere ripensato.

L’impatto sulla postura di sicurezza aziendale

Il burnout non è una questione di risorse umane. È una questione di rischio operativo. La catena di conseguenze che collega l’esaurimento dei professionisti alla vulnerabilità delle organizzazioni è documentata e misurabile.

Il report Sophos Human Cost of Vigilance documenta che il burnout riduce la produttività nel 39% dei casi e l’engagement nel 33%. Ma le conseguenze più gravi sono operative. Il 2026 SANS | GIAC Workforce Research Report documenta un dato diretto e inequivocabile: il 27% delle organizzazioni ha subìto violazioni reali come conseguenza diretta del gap di competenze e capacità nei team. Non di strumenti inadeguati, dunque, ma di persone esaurite, sopraffatte o assenti. Le lacune di skill producono anche ritardi nei progetti (57% delle organizzazioni), rallentamenti nella risposta agli incidenti (47%) e ridotta capacità di monitoraggio (42%).

Il Verizon 2025 Data Breach Investigations Report, basato sull’analisi di oltre 22.000 incidenti e 12.195 violazioni confermate, il dataset più ampio della storia del report, documenta che il ransomware è presente nel 44% delle violazioni (in crescita dal 32% dell’anno precedente) e che il coinvolgimento di terze parti è raddoppiato al 30%. Questi dati segnalano una superficie di attacco in rapida espansione che richiede team reattivi e lucidi, due qualità che il burnout erode sistematicamente.

Il Cost of a Data Breach Report 2025 di IBM, condotto dal Ponemon Institute su 600 organizzazioni globali tra marzo 2024 e febbraio 2025, fissa a 4,44 milioni di dollari il costo medio globale di una violazione e a 241 giorni la durata media del ciclo vita dell’incidente, il valore più basso da nove anni grazie all’adozione diffusa di AI e automazione. Le organizzazioni che non adottano questi strumenti, spesso proprio quelle con team sottorganico e sopraffatti, sperimentano tempi superiori ai 200 giorni, con costi medi che sfiorano i 5,49 milioni di dollari.

L’analista che ignora un alert perché ne ha già visti diecimila simili in settimana non sta fallendo come professionista: sta rispondendo razionalmente a un sistema progettato male. Il fallimento è organizzativo, non individuale.

Strategie di risposta: oltre il welfare aziendale

Le risposte efficaci al burnout nella cybersecurity richiedono un approccio a più livelli, che integri soluzioni tecnologiche, ridisegno dei processi e trasformazione culturale.

Automazione intelligente e SOAR di nuova generazione

La prima linea di difesa contro l’alert fatigue è tecnologica. Come approfondito su ICT Security Magazine nell’articolo dedicato alla security automation, le piattaforme SOAR (Security Orchestration, Automation and Response) nascono per automatizzare i task ripetitivi del SOC: triage degli alert, enrichment dei dati, lookup di threat intelligence, risposta iniziale agli incidenti. L’obiettivo è sottrarre all’analista il lavoro meccanico per restituirgli spazio cognitivo per le decisioni ad alto valore.

Le piattaforme di nuova generazione, basate su AI agentiva anziché su playbook statici, rappresentano un salto qualitativo rispetto ai sistemi tradizionali. Come sintetizza la ricerca pubblicata sull’ACM Computing Surveys, i SOC di sesta e settima generazione si muovono verso un ecosistema di collaborazione uomo-macchina in cui l’AI gestisce autonomamente correlazione, classificazione e risposta ai pattern ricorrenti, lasciando agli analisti i casi anomali, complessi o ad alto impatto strategico.

I sistemi che adottano AI-powered investigation raggiungono una copertura del 100% degli alert analizzati rispetto al 40-60% dei modelli tradizionali, con riduzioni documentate dei falsi positivi superiori al 70% nelle prime settimane di deployment. Il report IBM 2025 quantifica il vantaggio economico: le organizzazioni che utilizzano estensivamente AI e automazione nelle operazioni di sicurezza risparmiano in media 1,9 milioni di dollari sui costi di violazione e riducono il ciclo vita delle breach di 80 giorni.

Outsourcing SOC e modelli MDR

Non tutte le organizzazioni hanno la massa critica per costruire e mantenere un SOC interno di qualità. Per molte realtà, specialmente quelle medio-grandi che faticano a competere con le big tech nell’attrarre talenti, il ricorso a servizi di sicurezza gestiti (MSSP, MDR) non è una scorciatoia ma una scelta strategicamente razionale. Il report Sophos indica esplicitamente i servizi MDR come uno dei fattori più efficaci nel ridurre la cyber fatigue dei team interni.

Il trasferimento delle operazioni di monitoraggio continuativo a provider specializzati riduce il carico sui team interni, che possono concentrarsi su governance, architettura di sicurezza e gestione del rischio strategico. Questa redistribuzione dei ruoli, se ben progettata, non indebolisce la security posture: la rafforza, perché assegna ciascuna attività alla struttura che può sostenerla in modo sostenibile.

Ridisegno organizzativo e gestione del carico cognitivo

Le misure tecnologiche sono necessarie ma non sufficienti. Il problema del burnout nella cybersecurity è anche un problema di design organizzativo. Come analizzato su ICT Security Magazine nell’articolo sulle security operations aziendali, la tensione tra automazione massiva e mantenimento delle competenze umane è uno dei nodi irrisolti delle organizzazioni più mature.

La ricerca di Bitsight identifica nella visibilità sul rischio, vale a dire nella capacità di vedere, comprendere e priorizzare le minacce, il fattore che più di ogni altro correla con la resilienza psicologica dei team. Le organizzazioni dotate di asset discovery e risk monitoring strutturato mostrano un tasso di burnout del 44%, contro il 63% di quelle che ne sono prive. Sapere su cosa concentrarsi riduce l’ansia da omissione, quella paura costante di aver tralasciato qualcosa di critico, che è uno dei principali motori dell’esaurimento.

Sul piano operativo, il SANS 2025 SOC Survey ha rilevato che il 79% delle organizzazioni operative H24 sperimenta picchi di alert fatigue nelle transizioni di turno. Un dato che indica dove intervenire con processi strutturati di handover e contestualizzazione. Il monitoraggio sistematico dei carichi di lavoro degli analisti, la rotazione dei turni e la definizione esplicita di escalation path contribuiscono a distribuire la responsabilità e a ridurre il peso della vulnerabilità individuale percepita.

Cultura e responsabilità manageriale

L’ultimo, e forse più difficile, fronte di intervento è culturale. Il report Seemplicity 2026 rileva che il 43% dei CISO non riesce a prendere ferie senza accumulare stress aggiuntivo al rientro, e il 32% sperimenta regolarmente l’ansia anticipatoria della settimana lavorativa. Come ha sintetizzato Ravid Circus di Seemplicity: «This isn’t a talent retention story. It’s a system failure. The people aren’t leaving, but the system is breaking around them».

Invertire questo dato richiede che la leadership aziendale riconosca il burnout come un rischio operativo e non come un problema HR, inserendolo nel framework di gestione del rischio con la stessa serietà riservata alle minacce esterne. Questo significa metriche di benessere monitorate nei KPI di sicurezza, budget dedicati al dimensionamento adeguato dei team e una cultura che valorizzi la segnalazione precoce del sovraccarico anziché penalizzarla.

Cybersecurity burnout: una questione di sistema, non di resilienza individuale

È tentante leggere il burnout nella cybersecurity come un problema di persone che non reggono la pressione. È una lettura sbagliata e pericolosa. I professionisti della sicurezza affrontano un lavoro di guardia permanente su sistemi in costante espansione, in un panorama di minacce che si fa più sofisticato ogni anno, con organici spesso inadeguati, in un settore che non ammette errori e non dimentica quelli commessi.

Il vero rischio sistemico non è che qualcuno lasci la professione, anche se i dati sul turnover restano preoccupanti. È che migliaia di persone restino al loro posto, esaurite e desensibilizzate, gestendo le infrastrutture critiche di aziende, ospedali e istituzioni pubbliche con una frazione dell’attenzione che il loro lavoro richiede. Il SANS 2026 Workforce Report documenta con precisione questa escalation: tra le organizzazioni con significative lacune di skill, il 47% registra un aumento del burnout, il 57% subisce ritardi nei progetti critici e il 42% vede ridursi le proprie capacità di monitoraggio. Non è un problema di singoli individui: è una degradazione sistemica della security posture.

Il burnout dei team di sicurezza è una vulnerabilità. Una vulnerabilità che non compare nei rapporti di risk assessment, non viene patchata negli aggiornamenti software, non è nominata esplicitamente nei quadri normativi NIS2 o DORA. Ma che gli attaccanti, implicitamente e strutturalmente, sfruttano ogni giorno.

Affrontarla non è un atto di generosità verso i propri dipendenti. È un imperativo di sicurezza.

https://www.ictsecuritymagazine.com/articoli/cybersecurity-burnout/

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/

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

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

La zona grigia come dottrina

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

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

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

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

Killnet e il modello “Wagner Digitale”

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

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

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

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

L’IT Army of Ukraine: hacktivismo sanzionato dallo Stato

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

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

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

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

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

Iran: il modello Layered dell’ecosistema proxy

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

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

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

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

Il caso Stryker: la guerra che entra in sala operatoria

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

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

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

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

Il problema dell’attribuzione: una crisi strutturale

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

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

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

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

Le aziende occidentali nel mirino geopolitico

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

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

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

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

Cosa fare: verso una resilienza consapevole

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

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

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

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

Conclusione: cyber mercenari, la guerra senza fronti

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

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

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

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

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.

Profilo Autore

Con oltre vent’anni di esperienza nel campo della cybersecurity, Matteo Perazzo ha sviluppato competenze trasversali in settori quali Banche, Assicurazioni, Telecomunicazioni, Infrastrutture Critiche e Difesa.
Dopo aver guidato un team di sicurezza informatica in Italia, si è trasferito nel Regno Unito per ricoprire il ruolo di Technical Director, maturando esperienza su mercati internazionali che includono Nord Europa e Medio Oriente.
Oggi è Cybersecurity Lead per DEEP, azienda specializzata in esplorazioni oceaniche e costruzione di habitat sottomarini. Parallelamente, è membro dell’UK Cyber Security Council, dove contribuisce alla definizione di standard e linee guida di cybersecurity a livello nazionale.

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

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

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

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

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

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

La geometria della sovrapposizione: tre regimi, tre logiche

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

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

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

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

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

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

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

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

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

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

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

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

Lo scenario del singolo incidente: la collisione reale

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Perché i framework GRC tradizionali non reggono

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

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

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

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

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

L’intelligenza artificiale come moltiplicatore ricorsivo di complessità

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

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

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

Un’agenda pratica per CISO e board

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

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

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

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

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

Conclusione: la maturità regolatoria come vantaggio competitivo

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

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

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

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

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

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