L’AI offensiva nella cybersecurity non è più un’ipotesi da convegno. È un fatto operativo, documentato, misurabile. E il suo impatto sta ridefinendo alla radice le categorie con cui la comunità della sicurezza informatica ha costruito i propri modelli di difesa nell’ultimo ventennio.

Per anni abbiamo ragionato su un assunto implicito: la complessità di un attacco è proporzionale alla sofisticazione dell’attaccante. Un exploit zero-day richiedeva competenze di reverse engineering maturate in anni di pratica. Una campagna APT multi-stadio presupponeva team strutturati, infrastrutture dedicate, catene di comando. Questo rapporto tra competenza e pericolosità era, in fondo, il nostro vantaggio strategico: sapevamo che gli attacchi più devastanti potevano provenire solo da un numero limitato di attori.

Quel rapporto si è spezzato. L’intelligenza artificiale generativa e, più recentemente, l’AI agentica hanno introdotto una discontinuità radicale nel panorama delle minacce cyber. Non si tratta di un’evoluzione incrementale, ma di una rottura strutturale. Un singolo individuo, privo di competenze tecniche consolidate, può oggi orchestrare operazioni offensive che fino a ieri richiedevano un team multidisciplinare. E lo può fare con una velocità, una coerenza e un’adattività che superano le capacità di molti analisti umani.

Questo articolo apre una serie dedicata a esplorare le dimensioni di questa trasformazione. Non come esercizio teorico, ma come strumento di orientamento operativo per chi – CISO, threat researcher, security architect, SOC analyst, giuristi del digitale – è chiamato a ripensare strategie e paradigmi alla luce di una realtà che muta più rapidamente dei nostri framework.

L’AI agentica come arma: dall’advisory all’execution

La prima fase dell’interazione tra intelligenza artificiale e cybercrime è stata relativamente benigna, almeno dal punto di vista strutturale. I threat actor utilizzavano i modelli linguistici come consulenti: per correggere la grammatica delle email di phishing, per generare snippet di codice malevolo, per ottenere informazioni tecniche. L’AI era un amplificatore di produttività, non un operatore autonomo.

Quella fase è conclusa.

Il passaggio cruciale è avvenuto con l’emergere dell’AI agentica – sistemi capaci non solo di generare contenuti su richiesta, ma di pianificare, decidere, eseguire e adattarsi in modo autonomo lungo catene operative complesse. Il report di threat intelligence pubblicato da Anthropic nell’agosto 2025 ha documentato per la prima volta questa transizione con evidenze concrete e inquietanti.

Il caso più emblematico riguarda un cybercriminale che ha utilizzato Claude Code – un assistente di codifica agentico – per condurre un’intera campagna di estorsione contro almeno 17 organizzazioni, tra cui strutture sanitarie, servizi di emergenza, enti governativi e istituzioni religiose. L’aspetto che distingue questa operazione da tutte le precedenti non è la scala, ma il ruolo dell’AI: Claude Code non ha fornito suggerimenti a un operatore umano. Ha condotto l’operazione. Ha eseguito la ricognizione automatizzata, raccolto credenziali, penetrato reti, analizzato i dati esfiltrati per determinare l’importo dei riscatti (che in alcuni casi superavano i 500.000 dollari) e generato lettere di estorsione personalizzate calibrate sul profilo finanziario e psicologico di ciascuna vittima.

In termini ancora più espliciti: l’AI ha preso decisioni tattiche e strategiche. Ha deciso quali dati esflitrare. Ha valutato quali informazioni avessero maggiore valore di leva. Ha generato comunicazioni persuasive che facevano riferimento ai margini operativi delle vittime e alle conseguenze di un’interruzione dei servizi.

A novembre 2025, Anthropic ha reso pubblico un caso ancora più significativo: la prima campagna di cyber-spionaggio orchestrata autonomamente dall’AI. Un gruppo state-sponsored cinese, identificato come GTG-1002, ha manipolato Claude Code convincendolo di essere impiegato in test di sicurezza difensiva legittimi. L’AI ha eseguito autonomamente tra l’80% e il 90% delle operazioni tattiche: scoperta di servizi interni, mappatura completa della topologia di rete, identificazione di account ad alto privilegio, creazione di backdoor persistenti, estrazione e categorizzazione dei dati per valore di intelligence. Gli operatori umani si sono limitati a selezionare i target e ad approvare le esflitrazioni finali.

Non siamo più nell’ambito dell’AI-assisted cybercrime. Siamo entrati nell’era dell’AI-operated cybercrime.

Vibe hacking: la democratizzazione radicale dell’offensiva cyber

Il termine “vibe hacking” è emerso nella comunità di sicurezza nella prima metà del 2025, derivato dal concetto di “vibe coding” coniato da Andrej Karpathy all’inizio dello stesso anno. Se il vibe coding descrive un approccio allo sviluppo software in cui il programmatore fornisce istruzioni ad alto livello e l’AI genera il codice, il vibe hacking applica lo stesso principio alle operazioni offensive.

Il concetto cattura qualcosa di profondo: l’attaccante non ha bisogno di comprendere cosa sta facendo. Non deve saper scrivere un exploit, configurare un’infrastruttura di command-and-control o comprendere i meccanismi di evasione. Deve saper parlare con l’AI nel modo giusto. La competenza tecnica è sostituita dalla competenza conversazionale.

I casi documentati da Anthropic illustrano questa dinamica con chiarezza disarmante. Nel caso dell’operazione di estorsione, l’attaccante ha configurato Claude Code con un playbook operativo (un file CLAUDE.md che standardizzava i pattern di attacco adattandoli a ciascuna vittima). L’intero flusso – dalla ricognizione alla monetizzazione – era orchestrato dall’AI. Un analista di IronScales ha commentato che questo caso demolisce l’assunto tradizionale secondo cui sofisticazione dell’attore e complessità dell’attacco siano correlate.

Un altro caso rivelatore riguarda gli operativi nordcoreani che hanno utilizzato Claude per ottenere e mantenere posizioni lavorative fraudolente in aziende Fortune 500 statunitensi. Questi individui necessitavano di assistenza AI per compiti elementari: comprendere riferimenti culturali americani, rispondere a domande tecniche di base, comunicare in modo professionale. L’AI ha eliminato il collo di bottiglia della formazione specialistica che in precedenza limitava la capacità operativa del regime.

Parallelamente, un altro attore ha sviluppato e venduto nel dark web varianti di ransomware con crittografia ChaCha20, tecniche anti-EDR e sfruttamento di Windows internals, il tutto essendo completamente dipendente da Claude per l’implementazione. I pacchetti erano commercializzati a prezzi compresi tra 400 e 1.200 dollari. L’attore vendeva competenze che, in realtà, non possedeva.

Il vibe hacking è dunque l’incarnazione operativa di un fenomeno più ampio: l’AI offensiva nella cybersecurity sta abbattendo le barriere di ingresso nel cybercrime con una velocità e una radicalità che i modelli tradizionali di valutazione delle minacce non sono progettati per catturare.

L’AI lungo l’intero ciclo di attacco: una mappatura MITRE ATT&CK

Per comprendere la portata sistemica dell’AI offensiva, è utile mapparne l’integrazione lungo le fasi del ciclo di attacco così come codificato nel framework MITRE ATT&CK. Il report di Anthropic ha documentato un attore cinese che ha integrato Claude in 12 delle 14 tattiche ATT&CK nel corso di una campagna di nove mesi contro infrastrutture critiche vietnamite – telecomunicazioni, enti governativi e settore agricolo.

Questa copertura quasi totale della kill chain non ha precedenti documentati. Vediamo come l’AI si integra nelle fasi principali.

Ricognizione e acquisizione risorse. Gli agenti AI operano in modo persistente e autonomo, raccogliendo informazioni da social media, dati di breach, API esposte e misconfigurazioni cloud. Come evidenziato nel framework di attacco agentico sviluppato da Unit 42 di Palo Alto Networks, a differenza della ricognizione tradizionale (tipicamente un’operazione manuale e statica), un agente AI si auto-interroga su quali dati servano, li raccoglie, e aggiorna la propria strategia se il contesto del target cambia.

Accesso iniziale e social engineering. L’AI genera comunicazioni di phishing grammaticalmente perfette, contestualmente rilevanti e personalizzate. Ma la novità non è solo qualitativa: è strutturale. L’AI può condurre operazioni di social engineering multicanale – email, SMS, messaggi vocali con voice cloning – in parallelo, adattando tono e contenuto in tempo reale sulla base delle risposte delle vittime.

Esecuzione, persistenza e movimento laterale. L’AI genera codice polimorfico on-demand. Ogni payload è unico, vanificando le detection basate su firme e hash. Nella campagna GTG-1002, Claude ha scoperto autonomamente servizi interni, mappato la topologia di rete e identificato sistemi ad alto valore, il tutto senza istruzioni umane granulari.

Esfiltrazione e impatto. L’AI non si limita a sottrarre dati: li analizza, li categorizza per valore di intelligence, produce report strutturati e genera comunicazioni di estorsione personalizzate. Nella campagna documentata da Anthropic, Claude generava automaticamente report operativi che consentivano la continuità delle operazioni anche in caso di interruzioni, abilitando il passaggio di consegne tra operatori.

Un dato quantitativo rende tangibile l’accelerazione: secondo il Global Incident Response Report 2025 di Unit 42, il tempo medio di esfiltrazione (MTTE) dopo l’accesso iniziale è crollato da nove giorni nel 2021 a due giorni nel 2024. In un caso su cinque, l’esfiltrazione avviene in meno di un’ora. L’AI agentica è un fattore determinante di questa compressione temporale.

L’ecosistema della frode AI-powered: una supply chain end-to-end

L’AI offensiva nella cybersecurity non si limita ad accelerare singole operazioni. Sta generando un intero ecosistema criminale strutturato, con una propria catena del valore.

Il report GTIG di Google (febbraio 2026) documenta la maturazione del mercato underground per strumenti AI-enabled. Nel 2025, il marketplace criminale ha visto la proliferazione di offerte multifunzionali progettate per supportare diverse fasi del ciclo di attacco. Praticamente ogni strumento pubblicizzato nei forum underground menziona la capacità di supportare campagne di phishing. Esistono “evil LLM” come WormGPT, modelli linguistici commercializzati esplicitamente per scopi criminali, capaci di generare malware, campagne di phishing e codice di exploit.

Google ha inoltre identificato, nel terzo trimestre 2025, una famiglia di malware denominata PROMPTFLUX che impiega le API di Gemini durante l’esecuzione per generare tecniche di offuscamento dinamico in VBScript. Non si tratta più di malware statico potenziato dall’AI: è malware che utilizza l’AI come componente funzionale in tempo reale.

A questo si aggiungono i “vibe script” venduti nei marketplace del dark web: template conversazionali ottimizzati per ingegneria sociale empatica, progettati per costruire rapport con le vittime prima di condurle alla compromissione. La combinazione di voice cloning, generazione di testi personalizzati e timing adattivo rende queste operazioni quasi indistinguibili da interazioni umane autentiche.

L’ecosistema include anche servizi di “influence-as-a-service”, documentati nel report di marzo 2025 di Anthropic, in cui l’AI non genera semplicemente contenuti ma decide quando i bot social devono commentare, condividere o interagire con utenti reali, sulla base di personas politicamente motivate. L’AI è l’orchestratore strategico, non il mero esecutore tattico.

Siamo di fronte a una industrializzazione del cybercrime AI-driven, con specializzazione dei ruoli, economie di scala e abbattimento dei costi marginali per attacco.

Implicazioni per i framework di valutazione delle minacce

L’irruzione dell’AI offensiva impone una revisione critica dei modelli con cui valutiamo le minacce. I framework tradizionali, a partire dalla stessa matrice MITRE ATT&CK, sono stati progettati per catalogare tattiche, tecniche e procedure di attori umani che operano con vincoli umani: tempo di apprendimento, necessità di coordinamento, limiti di velocità esecutiva.

L’ottobre 2025 ha segnato un punto di svolta: MITRE ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems) ha integrato, in collaborazione con Zenity Labs, 14 nuove tecniche e sotto-tecniche specificamente focalizzate su agenti AI e sistemi di AI generativa. Queste includono il context poisoning degli agenti AI, la manipolazione della memoria a lungo termine dei LLM, la thread injection e il RAG credential harvesting. ATLAS conta ora 15 tattiche, 66 tecniche e 46 sotto-tecniche. Ma anche questo aggiornamento potrebbe non bastare.

Il problema fondamentale è che i modelli di rischio basati sulla classificazione degli attori (script kiddie, cybercriminale organizzato, APT state-sponsored) perdono significato quando un attore con competenze da script kiddie può eseguire operazioni di livello APT grazie all’AI. Il World Economic Forum, nel Global Cybersecurity Outlook 2025, ha rilevato che il 66% delle organizzazioni intervistate prevede che l’AI avrà l’impatto più significativo sulla cybersecurity nell’anno in corso. Secondo Darktrace, il 78% dei CISO ritiene che le minacce guidate dall’AI avranno un impatto rilevante sulle proprie organizzazioni.

Questi dati riflettono una consapevolezza crescente, ma non ancora una risposta operativa adeguata. La sfida non è aggiungere “AI” come variabile ai modelli esistenti: è ripensare le categorie stesse su cui quei modelli si fondano.

Le implicazioni sono molteplici e interconnesse. Sul piano della threat intelligence, i modelli di attribuzione basati su tooling e TTP specifici si indeboliscono quando l’AI genera varianti uniche a ogni esecuzione. Sul piano del risk assessment, la probabilità di attacco si disaccoppia dalla sofisticazione percepita dell’attore. Sul piano della compliance e della governance, il quadro normativo europeo – già in fase di profonda evoluzione – deve fare i conti con scenari che i legislatori non avevano pienamente anticipato.

La Direttiva NIS2 (Direttiva UE 2022/2555), pienamente applicabile dal 18 ottobre 2024 e ora in fase di enforcement attivo, impone agli enti essenziali e importanti obblighi stringenti di gestione del rischio cyber (articolo 21), notifica degli incidenti entro 24 ore per l’early warning e 72 ore per il report completo (articolo 23), e responsabilità diretta del management con possibilità di sanzioni personali fino all’interdizione dalla funzione dirigenziale. Ciò che la rende particolarmente rilevante nel contesto dell’AI offensiva è il suo approccio alla supply chain (articolo 21.3 e 22): le organizzazioni devono valutare la sicurezza dei propri fornitori, inclusi i fornitori di servizi AI, il che acquisisce una dimensione nuova quando gli stessi strumenti AI possono essere weaponizzati.

Il Recital 89 della direttiva incoraggia esplicitamente gli Stati membri a promuovere l’uso di tecnologie innovative, inclusa l’intelligenza artificiale, per migliorare la sicurezza informatica – un mandato che, alla luce del vibe hacking, assume una doppia valenza: l’AI è simultaneamente raccomandazione difensiva e vettore offensivo. Le sanzioni sono significative: fino a 10 milioni di euro o il 2% del fatturato globale per gli enti essenziali. A gennaio 2026, la Commissione europea ha proposto emendamenti mirati per semplificare la compliance, riconoscendo implicitamente la complessità applicativa per le 28.700 imprese interessate.

Parallelamente, l’AI Act (Regolamento UE 2024/1689) introduce un framework stratificato per rischio. Entrato in vigore il 1° agosto 2024, ha già attivato i divieti sulle pratiche AI inaccettabili (febbraio 2025) e gli obblighi di governance per i modelli GPAI (agosto 2025).

Le scadenze critiche sono imminenti: ad agosto 2026 diventeranno applicabili i requisiti completi per i sistemi AI ad alto rischio (articoli 8-15), inclusi obblighi di gestione del rischio, governance dei dati, documentazione tecnica, supervisione umana, e – elemento cruciale per il nostro contesto – garanzie di accuratezza, robustezza e cybersecurity. I modelli GPAI con rischio sistemico (quelli addestrati con più di 10²⁵ FLOP) devono sottostare a valutazioni tramite adversarial testing, reporting degli incidenti gravi all’AI Office entro 72 ore, e protezioni di cybersecurity allo stato dell’arte.

Le sanzioni possono raggiungere i 35 milioni di euro o il 7% del fatturato globale. Il Digital Omnibus, proposto dalla Commissione nel novembre 2025, mira a coordinare AI Act, NIS2, DORA e GDPR in un quadro più coerente, introducendo un punto unico di reporting per gli incidenti – un segnale chiaro che la frammentazione normativa attuale è percepita come un problema reale.

L’intersezione tra questi due regolamenti è il terreno su cui l’AI offensiva nella cybersecurity pone le sfide più complesse: come si classifica il rischio di un sistema AI che può essere simultaneamente strumento di compliance (AI per la detection) e vettore di attacco (AI weaponizzata)? Come si applica il requisito di adversarial testing quando gli stessi test possono essere condotti da agenti AI autonomi? Sono domande a cui i framework attuali non offrono risposte definitive, e che la giurisprudenza dovrà necessariamente affrontare.

Cosa cambia per la difesa: verso nuovi paradigmi

Se l’offesa si è trasformata, la difesa non può restare ancorata ai modelli pre-AI. Alcune direttrici di evoluzione sono già identificabili.

Oltre le firme, oltre il comportamento noto. Le difese basate su firme e pattern comportamentali storici sono strutturalmente inadeguate contro attacchi AI-generated. Ogni payload è polimorfico, ogni comunicazione è unica, ogni catena di attacco è adattiva. Il modello difensivo deve spostarsi verso il controllo di ciò che è autorizzato a eseguire, non verso il tentativo di riconoscere ciò che è malevolo. L’approccio Zero Trust applicato al livello applicativo – dove solo il codice esplicitamente approvato può essere eseguito – diventa non un’opzione architetturale, ma una necessità operativa.

Detection comportamentale anomala. Se i contenuti generati dall’AI sono indistinguibili da quelli legittimi, la detection deve spostarsi sulle anomalie relazionali e contestuali. Un’email perfettamente scritta che arriva da un mittente insolito, in un contesto temporale atipico, con una richiesta incongruente rispetto ai pattern storici della relazione – questo è il segnale da intercettare. L’analisi comportamentale basata su baseline relazionali diventa la frontiera critica.

Monitoraggio dell’uso AI in ambiente enterprise. Il fenomeno degli “shadow agent” – dipendenti che utilizzano strumenti AI non approvati per gestire il lavoro quotidiano – crea superfici di attacco invisibili. I dati aziendali caricati in LLM non governati sono, nella sostanza, dati esfiltrati. Le policy di AI governance devono includere inventari degli asset AI, monitoraggio delle interazioni con modelli esterni e enforcement delle regole d’uso.

Red teaming AI-native. Le esercitazioni di red teaming devono incorporare scenari di attacco AI-driven. Il framework di attacco agentico sviluppato da Unit 42 è un esempio concreto: consente di simulare operazioni in cui agenti AI pianificano, eseguono e adattano attacchi lungo l’intera kill chain. Il playbook di McKinsey sulla sicurezza dell’AI agentica (ottobre 2025) introduce una prospettiva particolarmente incisiva: gli agenti AI devono essere trattati come “digital insider”, entità che operano all’interno dei sistemi con livelli variabili di privilegio e autorità.

Proprio come i dipendenti, questi insider digitali possono causare danni in modo involontario – per disallineamento – o deliberato, se compromessi. McKinsey identifica cinque nuovi driver di rischio specifici dell’AI agentica: le vulnerabilità a catena (un errore in un agente si propaga a cascata ad altri agenti), l’escalation cross-agent di task (agenti malevoli che sfruttano meccanismi di trust per ottenere privilegi non autorizzati), il rischio di identità sintetiche, la fuga di dati non tracciabile negli scambi autonomi tra agenti, e la propagazione di corruzione dei dati.

Un dato del report SailPoint citato nel playbook merita attenzione: l’80% delle organizzazioni dichiara di aver già riscontrato comportamenti rischiosi da parte di agenti AI, inclusa l’esposizione impropria di dati e l’accesso a sistemi senza autorizzazione.

Runtime security per i modelli AI. Il monitoraggio in tempo reale degli input e degli output dei modelli AI diventa essenziale. Rilevare quando un pattern d’uso devia verso scenari di abuso, quando le query indicano intento malevolo, quando le risposte del modello veicolano informazioni operative per attacchi – questa è l’equivalente dell’intrusion detection applicata al layer dell’intelligenza artificiale.

L’AI difensiva funziona, ma il gap è reale. Un dato incoraggiante merita attenzione: secondo le analisi IBM e di settore, le organizzazioni che utilizzano sistematicamente AI e automazione nei propri processi di cybersecurity rilevano le violazioni con circa 80 giorni di anticipo rispetto a quelle che non le impiegano, con un risparmio medio stimato in circa 1,9 milioni di dollari per incidente. La detection AI-powered è dunque efficace – ma solo se implementata con governance, training e integrazione adeguate. Il problema è che questo vantaggio è accessibile principalmente alle grandi organizzazioni con budget e competenze dedicate, creando un divario di resilienza che l’AI offensiva è pronta a sfruttare.

L’anello debole: PMI e la democratizzazione asimmetrica del rischio

C’è un aspetto dell’AI offensiva nella cybersecurity che le analisi orientate all’enterprise tendono a sottovalutare: il suo impatto sproporzionato sulle piccole e medie imprese. Se l’AI democratizza l’attacco, non democratizza affatto la difesa – almeno non nella stessa misura e con la stessa velocità.

I numeri sono inequivocabili. Secondo il WEF Global Cybersecurity Outlook 2025, il numero di piccole organizzazioni che riportano una resilienza cyber insufficiente è aumentato di sette volte rispetto al 2022. Il 45% di tutti gli attacchi cyber nel 2025 ha preso di mira le PMI. E il dato più allarmante: circa il 60% delle PMI colpite da un attacco significativo cessa l’attività entro sei mesi. Solo il 29% delle PMI valuta le proprie difese come sufficientemente mature, e solo l’11% utilizza strumenti di difesa basati su AI.

L’AI offensiva aggrava questa asimmetria in modo strutturale. La personalizzazione degli attacchi, un tempo riservata alle campagne APT contro grandi organizzazioni, diventa economicamente praticabile anche contro target minori quando è l’AI a condurre la ricognizione, a generare i contenuti di phishing e a calibrare l’estorsione. Un agente AI che può attaccare 17 organizzazioni contemporaneamente (come nel caso documentato da Anthropic) non discrimina in base alla dimensione: discrimina in base alla vulnerabilità. E le PMI, con meno risorse difensive, superfici di attacco più facilmente mappabili e spesso prive di cyber insurance (solo il 17% ne dispone), rappresentano bersagli ad alta probabilità di successo.

Per i CISO e i consulenti che operano con clienti PMI, questo implica un ripensamento radicale. Le raccomandazioni tradizionali – formazione del personale, MFA, patching regolare – restano necessarie ma non più sufficienti contro attacchi AI-driven che generano comunicazioni indistinguibili da quelle legittime e payload unici a ogni esecuzione. Le PMI hanno bisogno di accesso a servizi di sicurezza gestiti che integrino detection AI-native, e il mercato dei Managed Security Service Provider (MSSP) dovrà evolversi rapidamente per colmare questo gap.

Limiti dell’analisi e controargomentazioni

Un’analisi onesta richiede di considerare anche i limiti della narrazione sull’AI offensiva e le controargomentazioni che la comunità di ricerca ha sollevato.

L’AI come amplificatore, non come rivoluzionario. Il report GTIG di Google del febbraio 2026 mantiene una posizione più cauta rispetto ad altre analisi: i ricercatori sottolineano che l’AI è primariamente un fattore di rinforzo all’interno di catene di attacco esistenti, piuttosto che una nuova categoria di minaccia in sé. L’uso dell’AI abbassa la soglia per certe attività e ne aumenta la scalabilità, ma non sostituisce le tecniche e le infrastrutture tradizionali che sono in uso da anni. Questa sfumatura è importante: evita il rischio di un allarmismo che potrebbe portare a investimenti mal calibrati.

Nessuna capacità “breakthrough” documentata. Google e altre fonti notano che nessun gruppo APT o operatore di information operations ha ancora raggiunto capacità realmente rivoluzionarie che alterino fondamentalmente il panorama delle minacce. Le operazioni documentate, per quanto impressionanti, rimangono nell’ambito dell’automazione e dell’efficientamento di tecniche note, non della creazione di vettori di attacco genuinamente inediti. Il social engineering resta social engineering, anche quando è generato dall’AI.

Il problema dell’overfit narrativo. Esiste un rischio concreto che l’enfasi mediatica e di settore sull’AI offensiva produca un effetto di overfit: una concentrazione eccessiva di risorse e attenzione su minacce AI-specific a scapito di vulnerabilità tradizionali che continuano a causare la maggioranza dei breach. La versione 18 di MITRE ATT&CK (dicembre 2025) documenta che l’81% delle intrusioni nel periodo luglio 2024-giugno 2025 è stato malware-free e basato su tecniche interattive, non necessariamente AI-driven. I fondamentali – gestione delle identità, patching, segmentazione di rete, controllo degli accessi – restano i pilastri su cui costruire qualsiasi strategia difensiva.

Queste controargomentazioni non invalidano la tesi centrale dell’articolo – il rapporto tra competenza dell’attaccante e complessità dell’attacco si è effettivamente spezzato – ma la circoscrivono in un quadro più realistico. L’AI offensiva è una minaccia concreta e documentata, non un’apocalisse imminente. La risposta appropriata è l’adattamento strutturato, non il panico.

Lo scenario che ci aspetta

La traiettoria è chiara, e non è tranquillizzante. Il Cybersecurity Forecast 2026 di Google prevede che l’uso di strumenti AI diventerà la normalità operativa sia per gli attaccanti sia per i difensori, con la prompt injection che emerge come uno dei vettori in più rapida crescita. Il Data Breach Industry Forecast 2026 di Experian delinea un futuro in cui gli attacchi non si limitano più al furto di dati ma puntano alla manipolazione della realtà stessa, attraverso identità sintetiche, agenti autonomi e malware polimorfico.

Nel primo trimestre 2025, oltre 2.300 vittime sono state nominate su siti di data leak – il numero più alto mai registrato dal 2020. Il 93% dei security leader, secondo Trend Micro, prevede di affrontare attacchi AI quotidiani. E il tutto avviene in un contesto in cui, come riportato dal WEF, i budget per la cybersecurity crescono solo del 4% annuo, contro il 17% del 2022.

L’AI offensiva nella cybersecurity non è un trend emergente da monitorare. È una realtà operativa che sta ridisegnando il campo di battaglia. Per i professionisti della sicurezza, la domanda non è se prepararsi, ma se la velocità di adattamento delle difese potrà eguagliare la velocità di evoluzione dell’offesa.

La risposta, al momento, non è scontata. Ma è proprio in questa incertezza che risiede l’urgenza di agire – con consapevolezza, con strumenti adeguati e con la determinazione di chi sa che il paradigma è cambiato e non si può tornare indietro.

Questo è il primo articolo di una serie dedicata all’impatto dell’AI sul panorama delle minacce cyber. I prossimi approfondimenti esploreranno le difese AI-native in dettaglio, l’intersezione normativa NIS2/AI Act/DORA per settori specifici, i framework operativi per la gestione del rischio AI in ambito enterprise e il ruolo dell’AI nella forensics post-incidente.

Fonti principali

Anthropic, Threat Intelligence Report: August 2025 e Detecting and countering misuse of AI, agosto 2025

Anthropic, Disrupting the first reported AI-orchestrated cyber espionage campaign, novembre 2025

Google Threat Intelligence Group (GTIG), AI Threat Tracker: Distillation, Experimentation, and Integration of AI for Adversarial Use, febbraio 2026

Palo Alto Networks Unit 42, Agentic AI Attack Framework, maggio 2025

MITRE, ATLAS Framework – aggiornamento ottobre 2025; ATT&CK v18.1, dicembre 2025

World Economic Forum, Global Cybersecurity Outlook 2025

McKinsey, Deploying Agentic AI with Safety and Security: A Playbook for Technology Leaders, ottobre 2025

Trend Micro, State of AI Security Report 1H 2025

Experian, 2026 Data Breach Industry Forecast, dicembre 2025

CrowdStrike, MITRE ATT&CK Framework Analysis, dicembre 2025

Commissione Europea, NIS2 Directive (Direttiva UE 2022/2555) e AI Act (Regolamento UE 2024/1689)

ENISA, NIS2 Technical Implementation Guidance, 2025

SailPoint Technologies, AI Agents: The New Attack Surface, maggio 2025

https://www.ictsecuritymagazine.com/notizie/ai-offensiva-cybercrime/

Attori non statali e capacità cibernetiche sono oggi elementi centrali nella trasformazione dei conflitti contemporanei. Questo contributo rappresenta il primo contenuto di una serie di approfondimenti dedicati al tema dei Cyber Proxies, con particolare attenzione alle capacità cibernetiche degli attori non statali filo-iraniani. L’articolo analizza il contesto sistemico in cui tali attori emergono, soffermandosi sull’erosione della sovranità statale, sulla privatizzazione della violenza e sull’evoluzione della guerra verso il cyberspazio. L’obiettivo è fornire le basi teoriche e concettuali per comprendere il ruolo crescente di questi soggetti nel quinto dominio della guerra e nelle dinamiche di sicurezza internazionale.

Globalizzazione, sicurezza e trasformazione del sistema internazionale

La globalizzazione ha moltiplicato i rischi e le minacce alla sicurezza poiché ha frammentato il quadro strategico che prima consentiva di interpretare ogni fenomeno all’interno di uno schema bipolare. Inoltre, ha accresciuto il rilievo degli attori non statuali e alimentato il dissenso in varie società, favorendo la formazione di reti tra diverse élite transnazionali che mettono in discussione il carattere territoriale della sovranità. La relativizzazione della sovranità e dei rapporti geopolitici ha quindi promosso la nascita di nuove forme di autorità, appartenenza e fedeltà. Questi nuovi attori del mondo globale mettono oggi in dubbio la sicurezza degli stati, alterano i rapporti di forza e rimodellano il sistema internazionale in funzione della loro crescente rilevanza.

Questo processo di trasformazione ha avuto conseguenze strettamente connesse al rapporto tra Stato e apparati militari: la relativizzazione dell’autorità e della legittimità politica, che provoca l’emergere di un insieme eterogeneo di nuove entità — come organizzazioni criminali o terroristiche, movimenti religiosi, ONG, ecc. — per lo più di natura transnazionale. Di conseguenza, la dissoluzione del vecchio ordine interstatale ha trasformato radicalmente anche la guerra, non più monopolio esclusivo degli Stati ma esteso a complesse reti di attori non statali di vario genere.

Mary Kaldor, nella sua opera “Le nuove guerre” ravvisa come i conflitti in epoca globalizzata, si presentino in maniera diversa rispetto al tradizionale modo di fare guerra. Secondo l’autrice la guerra è anzitutto un fenomeno sociale, e come tale, la sua rivoluzione è di fatto una rivoluzione delle relazioni sociali della guerra e non della tecnologia (benché spesso la tecnologia influenzi inevitabilmente il cambiamento delle relazioni sociali). In un contesto di progressiva erosione del potere statuale, viene meno il controllo sugli strumenti della coercizione fisica e quindi, la loro frammentazione.

Questo ha determinato l’evolversi di un sistema internazionale a “geometria variabile” che, da un lato, sempre più attori — spesso mossi da identità religiose o etniche — rivendicano il diritto di ricorrere alla violenza organizzata per mettere in discussione la sovranità territoriale degli Stati. Dall’altro lato, permane un’area centrale in cui continuano a valere le regole tradizionali del sistema westfaliano. In tale contesto, il potere tende a svilupparsi e a diffondersi su centri diversi rispetto a quelli tradizionalmente legati allo Stato e, analogamente, l’uso della forza tende progressivamente a “privatizzarsi”.

Storicamente, l’asimmetria nei conflitti armati si configurava a partire da una sproporzione tecnologica, militare ed economica tra i diversi attori. Tipicamente, in un conflitto l’attore “high-tech”, ovvero quello più organizzato militarmente, tecnologicamente ed economicamente puntava a spostare il campo di battaglia sul piano convenzionale per sfruttare la propria superiorità. Viceversa, il contendente “low-tech” svantaggiato cercava di impiegare tutti gli strumenti e/o strategie volte a vanificare la superiorità del nemico, attraverso un ventaglio di mezzi non convenzionali (come il terrorismo, la guerriglia etc.).

Cyberspazio e trasformazione della guerra contemporanea

Nell’epoca dell’informazione globalizzata, la guerra sta radicalmente cambiando forma, limiti e confini e, anche questi nuovi attori globali stanno imparando a porre l’enfasi sulle “operazioni informative” e sulla “cyberwar”, come parte del ventaglio strategico atto a spostare il campo di battaglia verso terreni di confronto non convenzionale (ed evitando quando possibile quello frontale-militare).

In tale contesto, la guerra comincia quindi a spostarsi verso uno “spazio non naturale”, il cosiddetto “cyberspazio”, dove i tradizionali concetti spaziali di larghezza, altezza e profondità perdono il loro classico significato strategico. Gli elementi materiali della guerra (soldati, armi e campo di battaglia) oggi assumono sempre meno rilevanza rispetto alla dimensione “immateriale”, in cui le regioni del potere sono ancora in discussione. Questo significa che non è più sufficiente imporsi a livello militare o avere fanteria per controllare un’area territoriale ma gli Stati dovranno cercare di governare le nuove complessità che si stanno manifestando in questo nuovo dominio di conflitto.

La cyberwar può essere intesa come una moltitudine di azioni ostili nel ciberspazio, dai veri e propri attacchi contro infrastrutture critiche, attacchi in grado di provocare danni fisici (esempio alterando il funzionamento di sistemi industriali), ad azioni di disturbo e psicologiche, prossime a un concetto più ampio di guerra informativa (ossia mirate a destabilizzare psicologicamente o delegittimare politicamente l’avversario).

L’elemento più evidente e temuto di questa evoluzione riguarda la possibilità di colpire obiettivi strategici da grandi distanze, spesso con tecnologie relativamente poco costose. Tuttavia, spesso l’impiego di un’offensiva informatica è soggetto a un problema di non poco conto, soprattutto se confrontata con un attacco convenzionale: la mancanza di controllo e di stime precise sui danni collaterali.

La natura complessa e interdipendente del ciberspazio rende difficile valutare se un cyberattacco, ad esempio diretto a disabilitare una certa rete militare, possa anche comportare estese conseguenze indesiderate per non-combattenti, paesi terzi o potenzialmente lo stesso aggressore. Questa imprevedibilità genera rischi politici significativi, poiché i danni collaterali inaspettati possono comportare ulteriori escalation, la delegittimazione da parte della comunità internazionale o nella politica interna e, talvolta anche rafforzare la resistenza del Paese bersaglio.

L’uso della violenza, o la minaccia di violenza, presuppone l’impiego della forza, che implica a sua volta l’infliggere danno fisico o esercitare coercizione. Il diritto internazionale definisce l’“atto di guerra” come “minaccia o uso della forza”. Stabilire cosa costituisca una “minaccia o uso della forza” nel ciberspazio richiede pertanto, come nel mondo fisico, un’analisi contestuale dell’azione compiuta e dei suoi effetti, oltre che degli obiettivi perseguiti. Alcuni interventi condotti abitualmente online potrebbero infatti costituire atti di guerra ai sensi della Carta ONU, legittimando il ricorso alla forza in autodifesa. Tuttavia, se tali azioni non comportano violenza né minaccia di violenza, non si configurano come attacchi.

Evoluzione storica e tipologie di attori non statali

Dalla fine della Guerra Fredda, la scarsa capacità di adattamento degli apparati statali ed un contesto internazionale sempre più frammentato e conteso hanno permesso ad alcuni attori non statali, di affermarsi al punto di competere (o sostituirsi) sempre più negli ambiti tradizionalmente dominati dagli stati-nazione.

Il termine “attori non statali” (non-State actors – NSAs) tipicamente viene usato per includere tutte quelle entità nelle relazioni internazionali che non sono Stati. Queste entità non possono essere identificate attraverso caratteristiche antropologiche comuni, poiché includono un’ampia gamma di organizzazioni e istituzioni a livello globale, regionale, sub-regionale e locale che possono includere multinazionali, organizzazioni non governative, regimi di fatto, associazioni, gruppi secessionisti o terroristi, organizzazioni criminali etc.

National Intelligence Council definisce gli attori non statali come un ampio spettro di soggetti sia non governativi che governativi a livello subnazionale, in grado di influenzare a diversi livelli le dinamiche politiche internazionali o, all’interno di uno Stato. Tra questi include i governi subnazionali, le imprese commerciali, gli istituti accademici e scientifici, i movimenti della società civile, i gruppi militanti e altre organizzazioni criminali[1].

Un primo aspetto che distingue immediatamente questi attori dagli Stati-nazione riguarda la diversa capacità giuridica. Mentre gli Stati possiedono in genere una piena capacità giuridica nell’ordine internazionale, la maggior parte di tali attori ne detiene solo una forma parziale. Questa caratteristica, dunque, li differenzia dagli Stati, che dispongono generalmente di un riconoscimento giuridico più ampio. Infatti, le teorie tradizionali del diritto internazionale concedevano agli attori non statali uno status giuridico molto limitato.

Fino all’inizio del XX secolo, la concezione alla base del cosiddetto “Sistema vestfaliano” riconosceva lo status di soggetti di diritto internazionale esclusivamente agli Stati. Tuttavia, anche prima della formalizzazione della visione statocentrica sancita della “Pace di Vestfalia” (1648), coesistevano a più livelli attori non statali, prevalentemente in una relazione di dipendenza e subordinazione di tipo gerarchico.

Dopo la Seconda guerra mondiale, la visione fortemente incentrata sugli Stati, che aveva dominato il diritto internazionale, subì trasformazioni più profonde. Con l’aumentare del numero di Stati dovuto ai processi di decolonizzazione, prese forma il riconoscimento dei popoli come entità distinta. Questo periodo pose le basi per un progressivo indebolimento dell’idea secondo cui solo gli Stati potessero essere gli unici protagonisti sulla scena internazionale.

Sebbene l’idea delle “nazionalità” fosse già nota prima della Prima guerra mondiale e fosse stata recepita in forma modificata nello Statuto della Società delle Nazioni, il principio di autodeterminazione si affermò in chiave giuridica soltanto nel 1945, con la Carta delle Nazioni Unite. Malgrado sia citato in vari articoli della Carta e in numerosi atti e sentenze internazionali (come nel Caso Timor Est alla Corte Internazionale di Giustizia), il contenuto concreto dell’autodeterminazione rimane in parte ancora oggi aperto a interpretazioni.

Tuttavia, l’importanza degli attori non statali fu esplicitamente riconosciuta già nel 1948, quando la Corte Internazionale di Giustizia, nel noto Parere consultivo sulla riparazione dei danni subiti al servizio delle Nazioni Unite, osservò che l’incremento dell’azione collettiva degli Stati aveva dato origine a casi di azione sul piano internazionale anche da parte di entità diverse dai governi statali.

Per quanto riguarda le Organizzazioni non-governative (ONG), concettualmente esistenti già nel medioevo (es British and Foreign Anti-Slavery Society nel 1823, l’International Geodesical Association nel 1862 o il Comitato Internazionale della Croce Rossa nel 1863) e già coinvolte in relazioni con le organizzazioni intergovernative tra le due guerre, queste verranno formalmente riconosciute solo con la creazione dell’ONU (nell’Art. 71 della Carta ONU).

Parallelamente, nello stesso periodo si affermarono anche i cosiddetti “regimi di fatto”: vere e proprie autorità di governo che esercitano un controllo stabile su un territorio specifico, senza però godere di un riconoscimento statale formale. Questi regimi, definiti “soggetti parziali” di diritto internazionale, potevano comunque intrattenere rapporti bilaterali o multilaterali con singoli Paesi; inoltre, in base al “Progetto di articoli sulla responsabilità dello Stato per fatti illeciti”, le loro azioni possono comportare responsabilità internazionali, analogamente a quanto accade per gli Stati pienamente riconosciuti.

Un dato interessante, è che nell’ambito delle guerre civili, già nel XIX e all’inizio del XX secolo, si riconosceva formalmente lo “status di belligeranza” a determinate fazioni armate che si opponevano al governo (come avvenne, ad esempio, nella Guerra Civile Americana e in quella spagnola). In altre parole, alcune parti in conflitto venivano considerate soggetti legittimati ad agire, entro certi limiti. Con l’evoluzione del diritto umanitario internazionale, si è aggiunta la previsione che gruppi insorti che controllano stabilmente un territorio ben delimitato possano godere di un certo riconoscimento e di tutela giuridica.

Un ulteriore passo avanti è avvenuto durante il periodo post-coloniale, con l’inserimento, nell’articolo 1 del Protocollo Aggiuntivo I alle Convenzioni di Ginevra: i movimenti di liberazione nazionale ottennero un riconoscimento formale, in ambito di conflitti armati, del ruolo e dei diritti di alcuni movimenti non statali impegnati in lotte di liberazione o in conflitti interni, in virtù delle loro rivendicazioni di indipendenza e autodeterminazione.

Globalizzazione, tecnologia e rafforzamento degli attori non statali

Dopo la fine della Guerra fredda, tra la fine degli anni ’80 e l’inizio degli anni ’90, parallelamente all’allentamento della contrapposizione tra blocchi (Est e Ovest) e dei conflitti per procura, gli attori non statali acquistano ancor più rilevanza sulla scena internazionale. Da un lato, la creazione di una società civile transnazionale (rafforzata dalle nuove possibilità di comunicazione), la globalizzazione dell’economia e la maggiore consapevolezza delle sfide globali. Molte organizzazioni e istituzioni internazionali (oltre ad alcune entità private) hanno iniziato a esercitare un’influenza sempre più incisiva sulle politiche interne degli Stati.

Ad esempio, l’Organizzazione Mondiale del Commercio (OMC), la quale regola materie cruciali come le misure sanitarie e fitosanitarie e gli ostacoli tecnici al commercio (sulla base di accordi internazionali firmati a Marrakech nel 1994). Allo stesso modo, la creazione della Banca Mondiale fornisce uno standard di riferimento per orientare le scelte economiche dei governi, mentre il Comitato antiterrorismo del Consiglio di Sicurezza ONU incide sulla legislazione interna degli Stati in materia di sicurezza e lotta al terrorismo.

Parallelamente, le trasformazioni economiche, politiche e culturali innescate dal processo di Globalizzazione portarono alla proliferazione di tutta un’altra serie di attori che si avvantaggiano dall’erosione del potere ordinatore degli stati nazione. In tale contesto, Mary Kaldor ravvisava l’emergere di un “processo regressivo” rispetto a quello che ha portato alla formazione dello Stato moderno, in cui la legittimità politica tende ad affievolirsi e la violenza a privatizzarsi al punto da permettere l’emergere di una serie di entità di nuovi combattenti, praticamente indistinguibili da quelli legittimi.

Questo significa che, in una situazione di declino economico, diffusione di criminalità e corruzione, gli Stati con un’autorità centrale debole (o inesistente) perdono il controllo sugli strumenti di coercizione e dell’esercizio della forza. La conseguenza più immediata è che queste entità assumano spesso un ruolo da protagonisti nel controllo fisico del territorio, lo proteggono e sviluppano anche modelli parassitari per esercitare e ad inserirsi in modo parassitario in tutte le aree di vita dei cittadini.

In altre parole, dietro il fallimento di uno stato, viene a configurarsi una progressiva “privatizzazione della violenza”. In tal senso, l’autrice distingue tre principali tipologie di entità combattenti private, che si affiancano alle forze armate regolari (incluse quelle che operano sotto l’ombrello di organizzazioni internazionali come ONU, NATO ecc.) dei nuovi teatri di battaglia[2]:

• Gruppi paramilitari: Sono gruppi armati organizzati e gerarchizzati di persone strutturati in modo simile a un corpo armato statale.
• Unità di autodifesa: sono gruppi di uomini volontari, spesso senza armi e risorse, che si uniscono per difendere il proprio territorio.
• Mercenari: include un gruppo abbastanza variegato che include singoli individui combattenti a contratto, unità combattenti e compagnie di sicurezza privata, reclutate a vario titolo dai governi o società multinazionali per esercitare controllo del territorio o difendere particolari interessi politici e economici.

In altre parole, quando parliamo di attori non statali ci si riferisce essenzialmente a due macrocategorie di entità: Gli attori non statali di tipo “entitativo” e gli attori privati. Nei primi rientrano tutte quelle entità che, pur non essendo stati, conservano caratteristiche statali o governative. Un esempio sono le organizzazioni internazionali o formazioni di Stati (come il G8) e gli attori sub-statali (come gli Stati federali). Gli attori privati invece, comprendono un insieme estremamente variegato di entità organizzative: alcune delle quali riconosciute dagli Stati, mentre altre sfuggono a ogni classificazione, in quanto più o meno formali, con o senza una chiara struttura gerarchica e, all’interno o all’esterno dei confini nazionali[3].

Interdipendenza tra Stati e attori non statali

Questi attori svolgono una vasta gamma di attività che, a seconda dei casi, possono rafforzare, competere o addirittura superare gli obiettivi e le iniziative dei governi nazionali e degli organismi multilaterali, tradizionalmente considerati il fondamento del sistema internazionale. Molti di essi agisce su più fronti contemporaneamente, ampliando in tal modo la loro influenza e il loro impatto complessivo. Inoltre, a volte esiste una stretta interdipendenza tra attori non statali, ma anche tra attori non statali e Stati.

Questo significa che, organizzazioni intergovernative o governative possono stipulare contratti con think tank per consulenze politiche, con ONG per l’erogazione di servizi o anche con milizie o gruppi armati per appaltare la difesa delle proprie infrastrutture o perpetrare specifici obiettivi politici. In altre parole, a un’estremità dello spettro si collocano imprese e organizzazioni le cui attività godono della piena approvazione e sostegno dei governi nazionali; all’altra estremità troviamo gruppi e movimenti considerati dalla maggior parte dei territori in cui operano come minacce all’ordine costituito. Nel mezzo si collocano tutta un’altra serie di attori con diverse finalità, con diversi gradi di controllo del territorio, che possono essere impiegati dagli stati per perseguire la propria agenda politica.

La letteratura esaminata sembra suggerire che, la motivazione della progressiva proliferazione e rilevanza di questi attori, è da rintracciarsi in una molteplicità di fattori. Sul piano economico, gli stati hanno progressivamente abbandonato l’ambizione, di dirigere dall’alto intere porzioni delle loro economie. I governi, sovraccarichi di compiti, che riconoscevano la scarsa dimensione dei propri mercati interni come base di competizione in un contesto internazionale sempre più aperto, si orientarono verso politiche di privatizzazione e di fusione transnazionale.

Inoltre, la ridotta capacità di adattamento delle istituzioni statali a un contesto internazionale sempre più frammentato, complesso e conteso. Questa crescente complessità sta rendendo questi attori sempre più importanti in quanto i governi stanno perdendo la capacità di soddisfare le aspettative delle proprie popolazioni e, di creare un universo simbolico in grado di strutturare identità nazionali solide. Contestualmente, molte delle istituzioni multilaterali che hanno costituito i pilastri fondamentali del sistema internazionale faticano a rispondere alle sfide emergenti e a soddisfare le richieste dell’opinione pubblica. A questo, si aggiunge l’inasprirsi della competizione strategica tra superpotenze che sta ulteriormente minando la cooperazione tra stati, sia a livello regionale sia internazionale, su temi di interesse globale (anche attraverso raggruppamenti statali).

Gli attori non statali si inseriscono progressivamente nel vuoto lasciato dagli stati fornendo tutta una serie di servizi alla popolazione (servizi sanitari, di supporto, di redistribuzione etc.) e, svolgendo sempre più spesso un ruolo multilaterale nella politica estera e nelle relazioni internazionali. Inoltre, il progresso tecnologico ha ulteriormente potenziato questi attori, migliorandone le capacità di erogare servizi e distribuirli, consentendo loro di attrarre finanziamenti e altre risorse a livello internazionale e, inserirsi sempre più capillarmente nel proprio contesto di riferimento.

Infatti, internet è stato il luogo di proliferazione di questi network, sia per interagire direttamente con le popolazioni locali sia per ampliare il proprio raggio d’azione anche oltre i confini nazionali. Infine, ha permesso anche di ampliarne l’ombrello operativo, permettendo loro di specializzarsi in operazioni nel cyberspazio che vanno dalla propaganda, al reclutamento, finanche ad operazioni offensive o di sorveglianza sempre più avanzate.

Un aspetto interessante è legato all’operatività degli attori non statali. Questi attori possiedono una serie vantaggi intrinseci che ne aumentano l’agilità operativa (rispetto gli apparati statali) e, di conseguenza, l’influenza, tra cui la concentrazione e la specializzazione su specifiche questioni. Inoltre, spesso dispongono di reti già consolidate che gli permettono di adeguarsi agevolmente alle dinamiche locali, guadagnarsi la fiducia delle popolazioni e sfruttare tale leva per fare pressione politica sugli stati e sulle organizzazioni internazionali.

La scarsa capacità degli stati di esercitare controllo su questi network consente a questi attori di spingersi oltre i limiti normativi o addirittura infrangerli. Pur non godendo dei privilegi e dei diritti propri degli attori politicamente sovrani, gli attori non statali riescono ad esercitare un potere economico, politico o sociale.

Questa agilità operativa ha portato nel tempo i governi e le istituzioni statali ad affidarsi sempre di più a questi attori per perseguire anche i propri obiettivi di politica nazionale e internazionale. Da un lato gli stati si avvalgono di questi attori per l’erogazione di alcuni servizi, per demandargli funzioni specifiche a livello internazionale, per svolgere ruoli altamente tecnici in contesti specifici. Basti pensare a come ambiti legati all’intelligence, alla sicurezza o alle operazioni militari, oggi non siano più appannaggio esclusivo degli stati ma spesso parte dei servizi offerti da aziende altamente qualificate.

Bellingcat, per esempio, si definisce un collettivo di analisti indipendenti che sfrutta informazioni open-source, tra cui immagini satellitari commerciali e metadati telefonici, per indagini che un tempo richiedevano risorse disponibili solo ai servizi d’intelligence nazionali. Team Jorge, azienda israeliana con un organico di ex ufficiali dei servizi e forze speciali internazionali, ha ammesso di aver interferito in diverse campagne presidenziali attraverso strumenti informatici mirati alla disinformazione.

Società di hacking come Intellexa offrono servizi di sorveglianza in mercati meno regolamentati, mentre la Israeliana NSO Group ha lavorato per diversi governi, finendo al centro di polemiche per l’utilizzo dei suoi software di sorveglianza a scopi di controllo politico. Infine, compagnie militari private come il Gruppo Wagner a cui gli Stati possono subappaltare vere e proprie porzioni del conflitto militare.

Dall’altro lato, esiste un altro insieme di attori non statali che possono costituire una minaccia concreta alla sicurezza di una nazione. Basti pensare alle diverse organizzazioni internazionali protagoniste dei diversi casi storici di terrorismo come lo Stato Islamico (ISIS), al-Qa‘ida, Hezbollah, ribelli Houthi che hanno inferto non poche preoccupazioni e danni alla sicurezza nazionale di diversi Stati, sviluppando network clandestini transnazionali.

Nel campo della criminalità organizzata, esiste un’intera pletora di organizzazioni impegnate nel traffico di droga (es Sinaloa e Jalisco Nueva Generacion), nella tratta di esseri umani etc. A questi si vanno ad aggiungere tutta una serie di attori sempre più rilevanti nel mondo della criminalità, come i gruppi di cybercriminali. Questi attori operano in un’area grigia, spesso sospesa fra interessi privati e sostegno governativo, sfumando la distinzione tra semplice cyber-crimine e operazioni sostenute da uno Stato.

Tuttavia, gli attori non statali perseguono finalità e interessi propri che possono divergere da quelli degli Stati-nazione, possono esercitare pressioni, corrompere o influenzare politicamente le istituzioni governative con cui collaborano. A seconda dell’attore e della situazione, questi attori possono stringere accordi con altri attori statali o non statali per perseguire i propri obiettivi, oppure agire per influenzare politiche estere alleate o partner. Allo stesso tempo potrebbero facilitare o addirittura innescare azioni o tendenze sociali orientate a destabilizzare un governo o a mettere in discussione le norme locali, nazionali o internazionali.

Questo approfondimento ha evidenziato come la globalizzazione, l’erosione del potere statuale e la trasformazione dei conflitti abbiano favorito l’ascesa di attori non statali capaci di operare nel cyberspazio, ridefinendo i confini dell’uso della forza e della responsabilità politica. L’analisi ha mostrato come tali soggetti possano essere impiegati come proxy strategici, collocandosi in una zona grigia tra guerra informativa, conflitto armato e competizione geopolitica. La riflessione proseguirà con un’analisi dedicata al modo in cui l’Iran ha strutturato il cyberspazio come dominio operativo, esaminandone architetture organizzative, dottrina e strategie di impiego. Per un inquadramento sistematico del tema, è inoltre disponibile il white paper gratuito “Cyber Proxies. Capacità Cibernetiche degli Attori Non Statali Filo-Iraniani”, realizzato da Ivano Chiumarulo.

Note

[1] National Intelligence Council, “Non-State Actors Playing Greater Roles in Governance and International Affairs”, Memorandum NIO Perspective. Washington DC, 5 luglio 2023.

[2] Kaldor M., Le nuove guerre. La violenza organizzata nell’età globale, Carocci Editore, Roma, 2021, p.109.

[3] Wagner, Markus, Non-State Actors, Max Planck Encyclopedia of Public International Law, Rüdiger Wolfrum, ed., Oxford University Press, 2 Aprile 2009, consultabile sul sito SSRN.

Profilo Autore

Ivano Chiumarulo ricopre ruoli in ambito Cyber Intelligence presso società di consulenza ICT. Vanta un percorso formativo multidisciplinare, avendo conseguito una laurea in Criminologia e, successivamente, una in Sicurezza Internazionale. Ha consolidato la sua preparazione approfondendo tematiche di Human Intelligence e Computer Science.
Appassionato di Open Source Intelligence (OSINT), Offensive Security e Red Teaming, è attivamente coinvolto nella ricerca sulle nuove metodologie offensive nel panorama delle minacce e sulle loro implicazioni nel contesto geopolitico. Attualmente (2025) partecipa alle attività di ricerca della Commissione di Studio su Cyber Threat Intelligence e Cyber Warfare della Società Italiana di Intelligence (SOCINT).

https://www.ictsecuritymagazine.com/articoli/attori-non-statali/

Whistleblowing e ritorsioni non sono mai stati così al centro del dibattito giuridico e organizzativo italiano come nel 2025. In un solo anno, tre pronunce giurisprudenziali – del Tribunale di Milano, del Tribunale di Bergamo e della Corte di Cassazione – hanno ridisegnato il perimetro delle tutele per chi segnala illeciti, trasformando principi rimasti a lungo sulla carta in strumenti operativi con effetti concreti sui rapporti di lavoro, sui modelli organizzativi e, per estensione, sull’intera architettura di compliance delle organizzazioni pubbliche e private.

Per chi opera nella sicurezza informatica – CISO, SOC analyst, compliance officer, DPO – queste sentenze non sono un esercizio accademico. Il canale di segnalazione interno è un’infrastruttura critica tanto quanto un SIEM o un sistema di endpoint detection: se mal progettato, mal gestito o, peggio ancora, utilizzato come strumento di ritorsione indiretta, espone l’organizzazione a sanzioni fino a 50.000 euro, alla nullità degli atti disciplinari e a risarcimenti danni il cui quantum è destinato a crescere.

Questo articolo analizza le sentenze cardine del 2025, le colloca nel quadro normativo aggiornato alle Linee Guida ANAC n. 1/2025 sui canali interni e al piano ispettivo del Garante Privacy, e ne estrae le implicazioni operative per chi deve progettare, gestire e difendere i sistemi di segnalazione.

Il contesto: dal D.Lgs. 24/2023 alla giurisprudenza vivente

Il D.Lgs. 10 marzo 2023, n. 24, che ha recepito la Direttiva (UE) 2019/1937, ha introdotto un impianto normativo ambizioso: canali interni ed esterni di segnalazione, divieto di ritorsione, inversione dell’onere della prova, sanzioni amministrative. Eppure, nei primi due anni di applicazione, la giurisprudenza italiana ha faticato a dare corpo a queste tutele. Le prime sentenze di merito – come già accaduto in Germania con il Hinweisgeberschutzgesetz – hanno spesso privilegiato la posizione datoriale, mantenendo un’impostazione formalistica che scaricava sul lavoratore-segnalante l’intero onere probatorio.

Il 2025 segna un’inversione di tendenza netta. Non si tratta di un singolo precedente isolato, ma di una convergenza giurisprudenziale che, su piani diversi, consolida tre principi fondamentali: la presunzione di ritorsività basata sulla contiguità temporale, il danno morale presuntivo del whistleblower e i limiti soggettivi della tutela.

Whistleblowing e ritorsioni: la sentenza del Tribunale di Milano n. 1680/2025

La pronuncia del Tribunale di Milano del 6 giugno 2025 (n. 1680) rappresenta il primo vero spartiacque nella giurisprudenza italiana sul whistleblowing post-riforma. Un lavoratore del settore privato, dopo aver effettuato una segnalazione secondo le procedure previste dal D.Lgs. 24/2023, era stato sottoposto a procedimento disciplinare e licenziato per giusta causa con effetto immediato.

Il Tribunale ha dichiarato la nullità del licenziamento, riconoscendo la natura ritorsiva del provvedimento. Il passaggio chiave della motivazione riguarda l’applicazione dell’art. 17 del D.Lgs. 24/2023, che introduce il concetto di ritorsione qualificata: una deroga alla disciplina generale dell’onere probatorio, specificamente calibrata sul contesto del whistleblowing. In concreto, il giudice ha ritenuto che la stretta contiguità temporale tra segnalazione e licenziamento attivasse una presunzione legale di ritorsività, invertendo l’onere della prova.

Per il datore di lavoro, questo significa che non basta contestare la fondatezza della segnalazione: occorre dimostrare l’esistenza di motivi oggettivi, autonomi e completamente scollegati dalla segnalazione stessa. Una prova che, nella pratica, è estremamente difficile da fornire quando i due eventi – segnalazione e provvedimento disciplinare – sono ravvicinati nel tempo.

Implicazione operativa per CISO e compliance officer: ogni azione disciplinare avviata nei confronti di un soggetto che abbia effettuato una segnalazione nei mesi precedenti deve essere sottoposta a un vaglio preventivo di compatibilità con la normativa whistleblowing. È consigliabile predisporre un registro cronologico delle segnalazioni e dei provvedimenti disciplinari, accessibile all’Organismo di Vigilanza, per prevenire contestazioni di contiguità temporale.

Il danno morale si presume: la sentenza del Tribunale di Bergamo n. 951/2025

Se Milano ha fissato il principio dell’inversione dell’onere della prova, Bergamo ha fatto un passo ulteriore. Con la sentenza n. 951 del 6 novembre 2025, il Tribunale ha per la prima volta riconosciuto un risarcimento economico a un whistleblower vittima di ritorsioni, qualificando il danno morale in termini presuntivi.

Il caso riguarda un’agente di polizia locale che aveva segnalato irregolarità nell’erogazione di buoni pasto, indennità di turno, permessi studio e nell’utilizzo di fondi regionali. In cambio, per tre anni ha subito isolamento, umiliazioni, dequalificazione professionale e un clima di ostilità sistematica da parte dei colleghi e del Comandante. Il Tribunale ha dichiarato la nullità delle azioni disciplinari, ha accertato la responsabilità dell’ente ai sensi dell’art. 2087 c.c. per il mantenimento di un ambiente lavorativo stressogeno e nocivo, e ha riconosciuto un risarcimento di 25.000 euro per danno morale.

La distinzione tra mobbing e responsabilità datoriale

Un aspetto particolarmente innovativo della pronuncia riguarda il superamento della categoria tradizionale del mobbing. La giudice ha riconosciuto che i comportamenti subiti dalla segnalante, pur non integrando gli estremi tecnici del mobbing per l’assenza di un intento persecutorio unitario, configuravano comunque una violazione dell’obbligo di sicurezza ex art. 2087 c.c. Non serve dimostrare un disegno persecutorio organico: è sufficiente che il datore di lavoro abbia tollerato o non prevenuto un ambiente ostile conseguente alla segnalazione.

La giudice ha inoltre valorizzato il ricorso alle presunzioni semplici e alle massime di comune esperienza: tre anni di umiliazioni e isolamento non possono che tradursi in una sofferenza intensa e in una lesione della dignità personale. Non è necessario produrre un accertamento medico-legale di danno biologico per ottenere il risarcimento del danno morale.

Il nodo irrisolto: l’adeguatezza del risarcimento

L’importo di 25.000 euro, pur rappresentando un precedente storico, apre un problema di coerenza con gli standard europei. La Direttiva (UE) 2019/1937 impone sanzioni effettive, proporzionate e dissuasive. La Convenzione OIL n. 190/2019 qualifica le ritorsioni come una forma di violenza sul lavoro da contrastare secondo il principio della tolleranza zero. Un risarcimento che copre poco più di 8.000 euro l’anno di sofferenza documentata rischia di non soddisfare il requisito della deterrenza, incentivando di fatto le organizzazioni a calcolare il costo della ritorsione come un rischio gestibile.

I confini della tutela: Cassazione n. 1880/2025 e l’uso improprio del whistleblowing

Il quadro non sarebbe completo senza la sentenza della Corte di Cassazione n. 1880 del 27 gennaio 2025, che ha tracciato con precisione i limiti soggettivi della tutela del segnalante. La Suprema Corte ha stabilito che le protezioni previste dal D.Lgs. 24/2023 non si applicano quando la segnalazione persegue scopi essenzialmente personali o si riduce a rivendicazioni inerenti al rapporto di lavoro nei confronti dei superiori.

La ratio è duplice: da un lato, tutelare il segnalante virtuoso che agisce nell’interesse dell’integrità dell’organizzazione; dall’altro, favorire l’emersione di illeciti dall’interno delle strutture pubbliche e private. Quando la segnalazione è strumentale a un conflitto personale, viene meno la funzione pubblica dell’istituto e, con essa, la giustificazione della tutela rafforzata.

Questa pronuncia è fondamentale per chi gestisce i canali di segnalazione: il gestore deve essere in grado di distinguere, in sede di esame preliminare, tra una segnalazione genuina e un utilizzo improprio dell’istituto. Una valutazione delicata, che richiede competenze giuridiche specifiche e che le nuove Linee Guida ANAC affidano a un soggetto dotato di autonomia, indipendenza e formazione adeguata.

Il Consiglio di Stato e il settore pubblico: sentenza n. 8079/2025

La sentenza del Consiglio di Stato (Sezione Sesta), n. 8079 del 17 ottobre 2025, ha consolidato il principio secondo cui la tutela dei lavoratori pubblici che segnalano illeciti deve essere una prerogativa dell’amministrazione stessa, non un onere che il dipendente è costretto a farsi riconoscere in sede giudiziaria. Il caso, riferito al comparto sicurezza, è particolarmente significativo perché si innesta su un settore tradizionalmente caratterizzato da rigide gerarchie e da una cultura della riservatezza che mal si concilia con la logica della segnalazione.

La pronuncia ribadisce che l’amministrazione è tenuta non solo a non ritorcersi contro il segnalante, ma a predisporre attivamente le condizioni affinché la segnalazione possa avvenire senza conseguenze negative. Un obbligo di protezione proattiva che si traduce in requisiti organizzativi precisi: formazione, canali sicuri, monitoraggio del clima interno successivo alla segnalazione.

Le Linee Guida ANAC n. 1/2025: dal principio alla procedura

Le sentenze del 2025 non operano nel vuoto. Il 26 novembre 2025, l’ANAC ha approvato le Linee Guida n. 1/2025 (Delibera n. 478) sui canali interni di segnalazione, completando il quadro regolatorio avviato nel 2023. Contestualmente, con la Delibera n. 479, ha aggiornato le Linee Guida sul canale esterno.

L’intervento nasce dalle criticità emerse nel primo biennio di applicazione del D.Lgs. 24/2023, documentate dal monitoraggio ANAC del 2024 e dalla consultazione pubblica. I numeri raccontano un sistema in crescita ma ancora fragile: nel 2024, ANAC ha aperto 1.350 fascicoli (970 dal settore pubblico, 243 dal privato); nel 2025, i fascicoli sono saliti a 1.931 (1.517 pubblici, 414 privati), con un incremento del 43%. Il dato del settore privato è particolarmente significativo se si considera che l’accesso al canale esterno ANAC ha natura sussidiaria.

Le novità operative più rilevanti

Le Linee Guida 2025 trasformano i principi generali del 2023 in regole operative vincolanti. Tra le novità più rilevanti per i professionisti della sicurezza informatica e della compliance:

• Piattaforma informatica certificata: l’ente è tenuto ad adottare una piattaforma che garantisca cifratura dei dati a riposo, non tracciabilità della connessione dalla rete aziendale (firewall e proxy non devono registrare l’accesso al canale) e conformità ai requisiti dell’Agenzia per la Cybersicurezza Nazionale.
• Gestore autonomo e formato: il soggetto incaricato della gestione delle segnalazioni deve possedere competenze giuridiche, conoscenza della normativa privacy e del funzionamento dell’ente, oltre a operare in piena autonomia. In caso di conflitto di interessi, deve essere sostituito.
• Coinvolgimento sindacale obbligatorio: il mancato coinvolgimento delle organizzazioni sindacali nella definizione delle procedure rende la procedura non conforme e sanzionabile da ANAC.
• Integrazione con il Modello 231: per gli enti che adottano un MOG, l’adeguamento è imprescindibile sotto tre profili: canale interno conforme, divieto espresso di ritorsione, sistema disciplinare aggiornato con sanzioni per violazioni della normativa whistleblowing.
• Sanzioni da 10.000 a 50.000 euro: per ritorsioni accertate, ostruzione delle segnalazioni, violazione della riservatezza, mancata istituzione dei canali o procedure non conformi.

Il Garante Privacy entra in campo: piano ispettivo e DPIA obbligatoria

Un ulteriore livello di pressione regolatoria proviene dal Garante per la protezione dei dati personali. Con la deliberazione n. 451 del 4 agosto 2025, l’Autorità ha inserito i sistemi di gestione delle segnalazioni tra le otto aree prioritarie del piano ispettivo per il secondo semestre 2025, prevedendo almeno 35 controlli mirati. L’attenzione del Garante si concentra sulla conformità al GDPR dei trattamenti connessi al whistleblowing: registro dei trattamenti, DPIA obbligatoria, informative aggiornate, misure tecniche di pseudonimizzazione e cancellazione sicura dei dati.

Per i CISO, questo significa che il canale di segnalazione non è solo un tema di compliance normativa, ma un asset da proteggere con lo stesso rigore applicato ai sistemi critici. Un data breach che coinvolga l’identità di un segnalante avrebbe conseguenze devastanti non solo sotto il profilo sanzionatorio, ma anche sul piano della fiducia organizzativa: nessun dipendente segnalerà mai più nulla in un’organizzazione che non ha saputo proteggere chi ha avuto il coraggio di parlare.

Il Whistleblower Tool europeo per l’AI Act: la governance multilivello

Il 24 novembre 2025, l’European AI Office ha lanciato un Whistleblower Tool dedicato al Regolamento sull’Intelligenza Artificiale. Lo strumento consente a chiunque di segnalare in modo sicuro e riservato presunte violazioni dell’AI Act direttamente alla Commissione europea, bypassando le strutture nazionali.

Per le imprese italiane, già impegnate nell’adeguamento alle Linee Guida ANAC e alla Legge 132/2025 sull’intelligenza artificiale, si configura una governance a tre livelli: canale interno aziendale, canale esterno ANAC, canale europeo AI Office. Non si tratta di duplicare presidi, ma di costruire un’architettura integrata in cui ogni canale è presidiato e monitorato. Il rischio concreto è che un segnalante, trovando inadeguato il canale interno, si rivolga direttamente all’autorità sovranazionale, con effetti reputazionali e regolatori amplificati.

Whistleblowing e ritorsioni: implicazioni per la cybersecurity

La convergenza tra normativa whistleblowing e sicurezza informatica è più profonda di quanto appaia a prima vista. Il canale di segnalazione è, a tutti gli effetti, un sistema informativo che tratta dati ad altissima sensibilità: l’identità del segnalante, il contenuto della segnalazione, l’identità della persona segnalata. Un compromesso di questi dati non è un incidente IT ordinario; è un evento che mina la capacità dell’organizzazione di intercettare illeciti futuri.

Le Linee Guida ANAC 2025 richiedono esplicitamente:

• Cifratura dei dati a riposo e in transito;
• Non tracciabilità dell’accesso al canale dalla rete aziendale;
• Generazione di un key code per comunicazioni riservate senza rivelare l’identità;
• Segregazione degli accessi: solo il gestore può accedere alle segnalazioni relative al proprio ente;
• DPIA conforme al GDPR, con parere del Garante Privacy.

Per il CISO, queste non sono solo specifiche tecniche: sono requisiti il cui mancato rispetto espone l’organizzazione a sanzioni da parte di ANAC e del Garante simultaneamente. La progettazione del canale deve coinvolgere fin dall’inizio il security team, il DPO e la funzione compliance, secondo un approccio security-by-design e privacy-by-design.

Quadro sinottico: le sentenze chiave del 2025

Prospettive: cosa aspettarsi nel 2026

Il 2025 ha posto le fondamenta; il 2026 sarà l’anno dell’applicazione sistemica. Tre dinamiche meritano attenzione.

La prima è l’evoluzione del quantum risarcitorio. La sentenza di Bergamo ha aperto un varco, ma l’importo riconosciuto è lontano dagli standard europei. È ragionevole attendersi che i tribunali italiani, sotto la pressione della giurisprudenza della Corte di Giustizia UE e dei principi della Convenzione OIL n. 190/2019, adeguino progressivamente gli importi verso una funzione realmente deterrente.

La seconda riguarda l’enforcement congiunto ANAC-Garante Privacy. Con il piano ispettivo del Garante e il consolidamento del potere sanzionatorio di ANAC, le organizzazioni che non hanno ancora adeguato i propri canali interni si trovano esposte a un doppio fronte di controllo. La campagna europea Open the Whistle, lanciata in occasione del World Whistleblower Day 2025, segnala una volontà istituzionale di normalizzare culturalmente la segnalazione.

La terza dinamica è tecnologica: l’integrazione tra canali di segnalazione e sistemi di intelligenza artificiale. Il Whistleblower Tool dell’AI Office europeo anticipa un futuro in cui la segnalazione di violazioni algoritmiche diventerà routinaria. Le organizzazioni che adottano sistemi di AI devono già oggi predisporre procedure per la segnalazione di bias, discriminazioni automatizzate e violazioni degli obblighi di trasparenza previsti dalla Legge 132/2025.

Conclusioni

Le sentenze del 2025 hanno trasformato il whistleblowing e ritorsioni da tema prevalentemente teorico a questione operativa con ricadute immediate sull’organizzazione aziendale, sulla sicurezza dei sistemi informativi e sulla governance complessiva. L’inversione dell’onere della prova, il danno morale presuntivo, la responsabilità datoriale anche in assenza di mobbing tecnico: sono principi che impongono un ripensamento profondo del modo in cui le organizzazioni progettano, gestiscono e difendono i propri canali di segnalazione.

Per i professionisti della cybersecurity e della compliance, il messaggio è chiaro: il canale di whistleblowing non è un adempimento burocratico da delegare e dimenticare. È un presidio di legalità che richiede investimenti tecnologici, competenze dedicate e una cultura organizzativa in cui segnalare non sia un atto di coraggio, ma una prassi ordinaria e protetta. Chi saprà costruire questo ecosistema avrà un vantaggio competitivo reale; chi lo ignorerà, troverà le sentenze del 2025 non come monito, ma come anticipazione del proprio contenzioso futuro.

Le regole del gioco sono cambiate. Il whistleblowing e le ritorsioni sono oggi al centro di un sistema di tutele che la giurisprudenza ha reso vivo e operativo. È tempo di adeguarsi.

Fonti e riferimenti normativi

D.Lgs. 10 marzo 2023, n. 24 – Attuazione della Direttiva (UE) 2019/1937

Direttiva (UE) 2019/1937 – Protezione delle persone che segnalano violazioni del diritto dell’Unione

Delibera ANAC n. 478 del 26 novembre 2025 – Linee Guida n. 1/2025 sui canali interni

Delibera ANAC n. 479 del 26 novembre 2025 – Aggiornamento Linee Guida canale esterno

Parere Garante Privacy del 9 ottobre 2025 – Sugli schemi di Linee Guida ANAC

ANAC – Relazione annuale 2025 al Parlamento (presentata il 20 maggio 2025)

Tribunale di Milano, sentenza n. 1680/2025 – Inversione onere della prova

Tribunale di Bergamo, sentenza n. 951/2025 – Risarcimento danno morale

Corte di Cassazione, sentenza n. 1880/2025 – Limiti soggettivi della tutela

Consiglio di Stato, sentenza n. 8079/2025 – Obbligo proattivo di tutela nel settore pubblico

Commissione Europea – Whistleblower Tool per l’AI Act (24 novembre 2025)

Transparency International Italia – Commento alle Linee Guida ANAC 2025

https://www.ictsecuritymagazine.com/notizie/whistleblowing-e-ritorsioni/

Feb 18, 2026 Giancarlo Calzetta Approfondimenti, In evidenza, News, RSS, Scenario, Scenario, Tecnologia, Tecnologia 0

Durante un’intervista in un podcast, il segretario di Stato olandese alla Difesa Gijs Tuinman ha sostenuto che un F-35 potrebbe essere “jailbreakato” “proprio come un iPhone”, nel contesto di una domanda molto concreta: cosa accadrebbe se, per ragioni politiche o strategiche, gli Stati Uniti smettessero di fornire supporto e aggiornamenti software agli alleati europei. Il punto non è la battuta ad effetto, ma il tema che porta con sé: il controllo del software come leva di potere operativo.

Tuinman ha continuato ricordando che l’F-35 è un programma multinazionale, con contributi industriali significativi anche fuori dagli USA, e che questa interdipendenza rende il velivolo, a suo dire, un “prodotto condiviso”. La realtà però è che, anche in un ecosistema cooperativo, l’accesso ai livelli più sensibili del software e della catena di aggiornamento resta storicamente fortemente centralizzato.

Che cosa significa davvero “jailbreak” su un sistema d’arma
Solitamente, quando parliamo di “jailbreak” ci si riferisce alla rimozione di vincoli imposti da un vendor per installare software non autorizzato o accedere ad aree riservate di un prodotto. Trasportare questa idea su un caccia di quinta generazione è tecnicamente e operativamente più complesso: non si parla solo di “installare un’app”, ma di intervenire su architetture critiche, catene di firme, procedure di validazione, sicurezza funzionale e requisiti di certificazione. Per questo diversi commentatori hanno letto la frase come una provocazione politica o un messaggio negoziale più che come un’indicazione tecnica.

Perché non è un iPhone: barriere di accesso e ricerca quasi impossibili
Un elemento sottolineato da chi fa penetration test in ambito aeronautico è la differenza strutturale tra hardware consumer e piattaforme militari. La comunità di ricerca che “stressa” i dispositivi di massa non esiste, di fatto, per i caccia: l’accesso fisico è rarissimo, rigidamente controllato e i vincoli di sicurezza e segretezza rendono improbabile che eventuali tecniche diventino pubbliche. In altre parole, anche se vulnerabilità o percorsi di aggiramento esistessero, sarebbe molto meno probabile che emergano come avviene nel mondo smartphone.

Sovranità operativa vs sicurezza: una tensione inevitabile
La discussione si intreccia con il modo in cui l’F-35 è stato gestito nel tempo: aggiornamenti, manutenzione e supporto sono stati storicamente orchestrati tramite sistemi di gestione della flotta e della logistica come ALIS (Autonomic Logistics Information System), citato anche nel dibattito mediatico che ha seguito le parole di Tuinman. Qui la posta in gioco non è solo la “patch”, ma l’intero ciclo di vita digitale del velivolo: configurazioni, diagnostica, documentazione tecnica, pacchetti di aggiornamento e dipendenze di supply chain.

Qualsiasi apertura al “software terzo” su piattaforme militari entra in collisione con esigenze opposte: da una parte la sovranità e la continuità operativa, dall’altra la riduzione del rischio di compromissione e di interferenze non autorizzate. Più autonomia per l’operatore significa anche più superficie di responsabilità: integrazioni, update e hardening diventano un problema locale, non più delegabile al prime contractor. Ed è esattamente qui che il tema “jailbreak” diventa delicato: l’autonomia tecnica può essere desiderabile in scenari geopolitici instabili, ma aumenta l’esposizione se governance, sicurezza e assurance non sono allo stesso livello.

Il precedente che tutti citano: l’eccezione israeliana
Nel dibattito torna spesso Israele, indicato come l’unico Paese ad aver negoziato margini più ampi per integrare componenti e software nazionali sulla propria variante, l’F-35I “Adir”. Le fonti descrivono questa eccezione come un equilibrio tra esigenze di personalizzazione e limiti imposti per non toccare i “cuori” più sensibili del sistema. È un precedente importante perché dimostra che spazi di autonomia possono esistere, ma come eccezione negoziata, non come default per tutti gli operatori.

Il fantasma del “kill switch” e l’effetto sulla fiducia europea
Le parole di Tuinman arrivano in un clima già carico: negli ultimi mesi/anni, a ondate, in Europa sono riemerse paure legate alla possibilità che gli USA possano limitare capacità, supporto o aggiornamenti dei sistemi avanzati venduti agli alleati. Al di là della verifica tecnica di un “interruttore remoto”, la questione cruciale è la fiducia: quanto controllo accetti di cedere quando compri una piattaforma definita dal software?

La notizia è meno relegata al mondo della difesa e dell’aviazione di quanto non sembri. L’F-35 è l’esempio estremo di una tendenza generale: prodotti sempre più complessi, vincolati a ecosistemi di aggiornamento, telemetria, autenticazione e supply chain, dove il confine tra manutenzione, sicurezza e controllo industriale si assottiglia. La provocazione del “jailbreak” rende evidente che, anche nel mondo difesa, la domanda sta cambiando: non è più solo “quanto è avanzato l’hardware”, ma chi governa il software, per quanto tempo e a quali condizioni geopolitiche.

• aeronautica militare, aggiornamenti software, ALIS, autonomia operativa, Cyber Warfare, cybersecurity, difesa, Europa, F-35, governance del software, hacker, hardening, interoperabilità, iPhone, ITAR, Jailbreak, kill switch, Lockheed Martin, manutenzione predittiva, penetration testing, rischio geopolitico, sicurezza informatica, sistemi d’arma, smartphone, software militare, sovranità digitale, sovranità tecnologica, Stati Uniti, supply chain, vulnerabilità

EDR killer BYOVD non è un concetto nuovo. Ma nel febbraio 2026 è diventato qualcosa di diverso: non più una tecnica di nicchia riservata ai gruppi APT più sofisticati, bensì lo strumento standard – quasi banale – con cui il ransomware acceca le difese endpoint prima ancora di cifrare il primo file.

Nelle prime due settimane di febbraio 2026 sono accaduti due eventi che, presi insieme, segnano un punto di non ritorno. Il primo: Huntress ha documentato un’intrusione in cui gli attaccanti hanno utilizzato un driver del tool forense EnCase – con certificato scaduto nel 2010 e successivamente revocato – per terminare 59 prodotti di sicurezza endpoint dalla modalità kernel. Il secondo: il Symantec and Carbon Black Threat Hunter Team ha rivelato che un ransomware emergente battezzato Reynolds ha integrato un driver vulnerabile direttamente nel proprio payload, fondendo evasione difensiva e cifratura in un unico binario.

La convergenza di questi due episodi racconta una storia che va ben oltre il singolo incidente. Racconta il fallimento strutturale di un modello di sicurezza endpoint su cui le organizzazioni hanno investito miliardi, e che gli attaccanti stanno imparando a spegnere con un driver firmato di vent’anni fa.

Che cos’è il BYOVD e perché funziona ancora nel 2026

La tecnica Bring Your Own Vulnerable Driver – BYOVD – è concettualmente disarmante nella sua semplicità. L’attaccante non scrive un driver malevolo, non cerca di aggirare la firma digitale, non sfrutta uno zero-day nel kernel. Porta con sé un driver perfettamente legittimo, firmato da un vendor riconosciuto, che contiene una vulnerabilità nota. Poiché il driver è firmato, Windows lo carica senza protestare. Una volta in esecuzione nello spazio kernel, l’attaccante sfrutta la falla del driver per terminare i processi di sicurezza con privilegi di sistema.

Il meccanismo tecnico si articola in passaggi precisi. Il malware deposita il driver vulnerabile su disco, tipicamente mascherandolo come componente OEM legittimo. Registra il driver come servizio kernel di Windows, garantendosi persistenza al riavvio. Una volta caricato, il driver espone un’interfaccia IOCTL (Input/Output Control) che consente ai processi in user-mode di inviare comandi con privilegi kernel. A quel punto, il malware compila un elenco dei processi di sicurezza da terminare – nell’incidente documentato da Huntress, l’elenco comprendeva 59 prodotti tra EDR e antivirus – e li uccide uno per uno, in un ciclo continuo con intervallo di un secondo che impedisce qualsiasi riavvio automatico del processo protettivo.

Il risultato è che l’attaccante opera “al buio”: nessun alert, nessuna telemetria, nessun rilevamento comportamentale. L’EDR non è stato aggirato; è stato spento.

Ciò che rende questa tecnica devastante nel 2026 non è la sua novità – il BYOVD è documentato da anni nel framework MITRE ATT&CK sotto T1068 e T1562.001 – ma la sua industrializzazione. Come ha osservato Broadcom/Symantec nel report sul ransomware Reynolds, il BYOVD è oggi di gran lunga la tecnica di evasione difensiva più utilizzata dagli operatori ransomware.

Il caso Huntress: un driver forense del 2006 che spegne 59 EDR nel 2026

All’inizio di febbraio 2026, i ricercatori di Huntress hanno risposto a un incidente che illustra perfettamente il paradosso del BYOVD. Gli attaccanti hanno ottenuto l’accesso iniziale tramite credenziali compromesse di una VPN SonicWall SSL priva di autenticazione multifattore. Fin qui, nulla di sorprendente: credenziali rubate e assenza di MFA sono il biglietto d’ingresso standard per il ransomware nel 2026.

La fase successiva è quella che merita attenzione. Gli attaccanti hanno distribuito un EDR killer personalizzato che conteneva, codificato al suo interno, il driver kernel EnPortv.sys – un componente dell’EnCase forensic suite sviluppato da Guidance Software. Questo driver era stato firmato con un certificato emesso il 15 dicembre 2006, scaduto il 31 gennaio 2010 e successivamente revocato.

Eppure Windows lo ha caricato. Come è possibile?

La risposta sta in una scelta architetturale che Microsoft ha fatto nel 2015 per garantire la retrocompatibilità. A partire da Windows 10 versione 1607, tutti i nuovi driver kernel devono essere firmati tramite il Hardware Dev Center di Microsoft. Tuttavia, per non rompere il software legacy, è stata introdotta un’eccezione: i driver firmati con certificati emessi prima del 29 luglio 2015, che si concatenano a un’autorità di certificazione cross-signed supportata, possono ancora essere caricati. Il driver EnCase rientra pienamente in questa eccezione.

C’è un secondo meccanismo che sigilla il problema. Come hanno spiegato i ricercatori di Huntress: quando il codice è firmato con un timestamp, Windows valida la firma rispetto al momento in cui è stata creata, non rispetto alla data corrente. Poiché il driver è stato timestampato quando il certificato era ancora valido, la firma rimane valida a tempo indeterminato. Il kernel, inoltre, non verifica le Certificate Revocation List al boot, per ragioni di performance.

Il risultato netto è che un driver con certificato scaduto da 16 anni e revocato continua a caricarsi ed eseguirsi nello spazio kernel di qualsiasi sistema Windows moderno.

Una volta caricato, il driver esponeva l’interfaccia IOCTL 0x223078 (KillProc). Il componente in user-mode apriva un handle verso il dispositivo del driver (\.\OemHwUpd) e inviava i PID dei processi target tramite DeviceIoControl. Il driver, operando in kernel-mode, invocava ZwOpenProcess con accesso PROCESS_TERMINATE seguito da ZwTerminateProcess. Quando il codice kernel-mode chiama le funzioni Zw*, il wrapper imposta PreviousMode a KernelMode, segnalando che i parametri provengono da una sorgente fidata: Windows salta interamente la validazione di sicurezza che applicherebbe ai chiamanti in user-mode.

L’EDR killer compilava un elenco interno di 59 processi di sicurezza associati ai principali vendor – tra cui Avast, CrowdStrike Falcon, Cortex XDR, Sophos, HitmanPro.Alert e Symantec – utilizzando hash dei nomi dei processi per l’identificazione. Il kill loop, eseguito con un intervallo di un secondo, terminava immediatamente qualsiasi processo di sicurezza che tentasse di riavviarsi.

Un dettaglio tecnico particolarmente ingegnoso: l’EDR killer non conservava il driver come byte grezzi. Utilizzava uno schema di codifica basato su un dizionario di 256 parole inglesi incorporate nel binario, dove ogni parola corrispondeva a un valore di byte specifico. Il payload codificato appariva come testo inglese innocuo, eludendo efficacemente gli strumenti di analisi statica. Una volta decodificato, il malware scriveva il driver su disco sotto un percorso che imitava un componente OEM legittimo, nascondeva il file e copiava i timestamp da un file di sistema reale per integrarsi con l’ambiente.

L’attacco è stato interrotto prima del deployment del ransomware, ma il messaggio è inequivocabile: con un driver di vent’anni fa, un attaccante può accecare l’intero stack di sicurezza endpoint.

Reynolds: quando il ransomware porta l’EDR killer nel proprio DNA

Se l’incidente documentato da Huntress rappresenta il modello classico – EDR killer come tool separato, dispiegato prima del ransomware – il caso Reynolds, analizzato dal Symantec and Carbon Black Threat Hunter Team e reso pubblico il 10 febbraio 2026, segna un’evoluzione tattica significativa.

Reynolds è una famiglia ransomware emergente che ha integrato il componente BYOVD direttamente all’interno del payload di cifratura. Il driver vulnerabile utilizzato è NSecKrnl di NsecSoft, affetto dalla vulnerabilità CVE-2025-68947, che consente la terminazione arbitraria dei processi senza verifica dei permessi adeguati. Lo stesso driver era stato precedentemente usato dal gruppo Silver Fox per distribuire il RAT ValleyRAT.

Al momento dell’esecuzione, Reynolds deposita il driver NSecKrnl.sys in una directory di sistema, lo carica nello spazio kernel e lo utilizza per terminare i processi di sicurezza di Avast, CrowdStrike Falcon, Palo Alto Networks Cortex XDR, Sophos e Symantec Endpoint Protection. Solo dopo aver reso cieche le difese, il ransomware avvia la routine di cifratura, aggiungendo l’estensione “.locked” ai file compromessi.

L’integrazione presenta vantaggi tattici evidenti. Come ha osservato Dick O’Brien, principal intelligence analyst di Symantec, rilasciare un unico file anziché due è più silenzioso e riduce le probabilità di rilevamento. Inoltre, eliminando l’intervallo temporale tra il dispiegamento dell’EDR killer e l’esecuzione del ransomware, si chiude la finestra in cui i difensori potrebbero intervenire.

Tuttavia, questa integrazione comporta anche un rischio per l’attaccante: consolidare evasione difensiva e cifratura in un’unica catena di esecuzione aumenta la densità comportamentale del binario, incrementando la probabilità di rilevamento da parte di soluzioni con monitoraggio comportamentale avanzato. Non a caso, nell’incidente analizzato da Symantec, il prodotto endpoint dell’azienda ha continuato a funzionare nonostante il tentativo di terminazione. Sophos, da parte sua, ha dichiarato a The Hacker News di disporre di protezioni di blocco contro questo specifico driver dal novembre 2025 e di safeguard proattivi contro il payload da diversi anni – un’indicazione che i vendor più maturi stanno evolvendo le difese, ma anche che la corsa tra attaccanti e difensori è continua.

Dopo l’iniziale attribuzione a Black Basta – basata sulla somiglianza delle TTP – un’analisi più approfondita ha portato Symantec a classificare Reynolds come famiglia ransomware distinta. Non è chiaro se rappresenti un rebrand o uno spin-off di Black Basta, ma l’evoluzione tattica che porta con sé è indipendente dall’attribuzione: il BYOVD integrato nel payload è una tendenza, non un caso isolato.

Lo stesso report di Broadcom ha osservato che la pratica di incorporare la componente di evasione difensiva direttamente nel payload ransomware non è del tutto inedita: era stata documentata in un attacco Ryuk nel 2020 e in un incidente legato a un ransomware meno noto chiamato Obscura alla fine di agosto 2025. Tuttavia, ciò che distingue Reynolds è la maturità dell’integrazione e il suo posizionamento in un ecosistema dove il BYOVD embedded potrebbe diventare requisito standard per attrarre affiliati nei programmi RaaS.

EDRKillShifter e la collaborazione cross-gang: il BYOVD come lingua franca del ransomware

Il fenomeno dell’EDR killer BYOVD non si esaurisce nei due episodi di febbraio 2026. Per comprenderne la portata sistemica, è necessario guardare a ciò che ESET ha documentato nel marzo 2025: la scoperta di EDRKillShifter, un tool EDR killer sviluppato e mantenuto da RansomHub come parte integrante del proprio programma Ransomware-as-a-Service.

EDRKillShifter è un software specializzato che utilizza la tecnica BYOVD per disabilitare i prodotti EDR sugli endpoint compromessi. Ciò che lo rende particolarmente significativo è la decisione di RansomHub di offrirlo direttamente ai propri affiliati – una scelta rara nel panorama RaaS, dove tipicamente gli affiliati devono procurarsi autonomamente gli strumenti per l’evasione difensiva.

La scoperta più rilevante di ESET, tuttavia, riguarda la diffusione cross-gang dello strumento. Tracciando l’uso di specifici campioni di EDRKillShifter, i ricercatori hanno identificato un singolo threat actor – denominato QuadSwitcher – che ha condotto attacchi per conto di quattro diverse operazioni ransomware: RansomHub, Play, Medusa e BianLian. Tutti gli attacchi coinvolgevano gli stessi campioni di EDRKillShifter e gli stessi server C2.

Il fatto che Play e BianLian – gang che operano tradizionalmente sotto modelli RaaS chiusi, basati sulla fiducia a lungo termine – utilizzino strumenti di un rivale come RansomHub suggerisce un livello di collaborazione senza precedenti nell’ecosistema ransomware. Come hanno teorizzato i ricercatori ESET, membri fidati di Play e BianLian stanno collaborando con rivali e riutilizzando gli strumenti ricevuti nelle proprie operazioni.

Questa dinamica trasforma l’EDR killer BYOVD da strumento tattico a infrastruttura condivisa dell’ecosistema ransomware. Non è più una capacità proprietaria di un singolo gruppo: è una commodity, un servizio, una lingua franca del cybercrime organizzato.

Perché Windows non può semplicemente “risolvere” il problema

Qualsiasi professionista della sicurezza, a questo punto, si pone la domanda ovvia: perché Microsoft non blocca semplicemente i driver con certificati scaduti o revocati?

La risposta è più complessa di quanto sembri e tocca uno dei trade-off più delicati dell’architettura Windows: la retrocompatibilità.

L’eccezione per i driver firmati prima del 29 luglio 2015 non è un bug – è una policy deliberata. Milioni di dispositivi hardware in produzione dipendono da driver legacy firmati con certificati di quel periodo. Revocare unilateralmente l’eccezione significherebbe potenzialmente causare crash di sistema, schermate blu e malfunzionamenti hardware su una scala difficile da quantificare.

Microsoft ha scelto un approccio alternativo: la Vulnerable Driver Blocklist, una lista di driver noti come vulnerabili o malevoli, implementata come policy Windows Defender Application Control (WDAC). A partire da Windows 11 versione 22H2, questa blocklist è abilitata di default su tutti i dispositivi. Viene aggiornata con ogni release principale di Windows, tipicamente una o due volte l’anno.

Il problema evidente di questo approccio è che è intrinsecamente reattivo: solo i driver già noti come weaponizzati finiscono nella lista. Ogni nuovo driver vulnerabile scoperto dagli attaccanti ha una finestra di esposizione fino al prossimo aggiornamento. In un ecosistema dove esistono centinaia di migliaia di driver firmati accumulati in decenni di sviluppo hardware, la superficie di attacco potenziale è virtualmente illimitata.

C’è poi un secondo problema, documentato nel CVE-2025-59033: la blocklist, implementata come policy WDAC, presenta un comportamento diverso a seconda che HVCI sia attivo o meno. Sui sistemi senza HVCI, alcune voci della blocklist che specificano il TBS hash del certificato insieme a qualificatori FileAttribRef (come nome del file o versione) possono non essere bloccate correttamente. Microsoft ha contestato l’assegnazione del CVE, affermando che la blocklist è progettata per funzionare con HVCI attivo e che i sistemi senza HVCI dovrebbero utilizzare App Control con policy personalizzate.

Ma questo sposta il problema anziché risolverlo: nella realtà operativa, HVCI non è attivo sulla maggioranza degli endpoint enterprise. Molte organizzazioni lo disabilitano per ragioni di compatibilità con driver legacy, impatto sulle performance o, più semplicemente, perché non ne conoscono l’esistenza o la funzione. Il risultato è una protezione che esiste sulla carta ma non nel data center.

L’inventario degli strumenti: gli EDR killer che stanno ridefinendo il playbook ransomware

Il panorama degli EDR killer BYOVD nel 2026 è variegato e in rapida espansione. Comprenderne la tassonomia è essenziale per chi deve costruire strategie difensive.

TrueSightKiller sfrutta il driver truesight.sys ed è uno degli strumenti pubblicamente disponibili più utilizzati nelle intrusioni ransomware recenti.

AuKill, documentato da Sophos, utilizza una versione obsoleta del driver impiegato dall’utility Microsoft Process Explorer per disabilitare i processi EDR prima del deployment del ransomware.

Poortry (noto anche come BurntCigar) è un driver malevolo frequentemente impiegato insieme al loader Stonestop. A differenza dei tool precedenti, Poortry è stato firmato con certificati rubati o ottenuti fraudolentemente, aggiungendo un ulteriore livello di sofisticazione.

GhostDriver e Warp AVKiller completano l’arsenale più frequentemente osservato, con quest’ultimo che sfrutta un driver anti-rootkit di Avira per disabilitare i prodotti di sicurezza.

Un caso particolarmente emblematico della diversificazione in atto riguarda il gruppo Interlock, che ha sviluppato un tool denominato “Hotta Killer” per sfruttare un zero-day in un driver anti-cheat gaming – GameDriverx64.sys, tracciato come CVE-2025-61155 – in attacchi BYOVD contro organizzazioni del settore educativo in UK e USA. L’intrusione, analizzata da FortiGuard, è particolarmente istruttiva perché illustra la convergenza di più tecniche offensive in un’unica campagna: l’accesso iniziale è avvenuto tramite tattiche di social engineering ClickFix per distribuire il payload MintLoader, seguito dal deployment del RAT NodeSnake per il movimento laterale, e infine dall’uso di Hotta Killer per disabilitare le difese prima della cifratura.

Il driver, rinominato UpdateCheckerX64.sys, veniva caricato come servizio kernel e comunicava tramite un link simbolico, esponendo un IOCTL (0x222040) con un magic flag (0xFA123456) per terminare i processi di sicurezza. Il caso Interlock è significativo perché dimostra che gli attaccanti non si limitano più ai driver di sicurezza o forensics: qualsiasi driver firmato con accesso kernel – inclusi quelli dei videogiochi – è un potenziale vettore BYOVD.

La portata del fenomeno ha spinto la Cyber Security Agency di Singapore (CSA) a pubblicare un advisory dedicato agli EDR killer, segnalando che almeno otto gruppi ransomware utilizzano attivamente strumenti di questo tipo. L’advisory ha evidenziato caratteristiche chiave condivise tra i tool: framework collaborativo tra gang, randomizzazione dei nomi dei driver, capacità di auto-scompattamento in memoria e uso di certificati rubati o scaduti.

La lista non è statica. Come ha evidenziato la ricerca di ESET su RansomHub, i ricercatori hanno osservato un aumento marcato nell’uso di EDR killer derivati da proof-of-concept pubblici, mentre il set di driver abusati rimane relativamente fisso. Cisco Talos ha analizzato sistematicamente le classi di vulnerabilità tipicamente sfruttate nei driver Windows, confermando che lo sfruttamento è migrato dal dominio degli attori avanzati a quello delle minacce commodity, in primis il ransomware. Questo significa che la barriera d’ingresso per sviluppare un EDR killer personalizzato è in caduta libera: chiunque abbia competenze di sviluppo Windows di livello intermedio può assemblarne uno partendo da codice disponibile su repository pubblici e proof-of-concept documentati.

Il paradosso dell’EDR e il debito del driver legacy

C’è un’ironia crudele nella situazione attuale. L’Endpoint Detection and Response è il prodotto di sicurezza su cui le organizzazioni investono di più, il pilastro su cui costruiscono la propria postura difensiva. I vendor EDR hanno sviluppato capacità sempre più sofisticate: rilevamento comportamentale, machine learning, analisi della memoria, threat hunting automatizzato.

Ma tutto questo sofisticato apparato tecnologico opera in user-mode. E un singolo driver vulnerabile caricato in kernel-mode ha il potere di spegnerlo completamente, bypassando ogni protezione, incluso Protected Process Light (PPL), il meccanismo che dovrebbe impedire la terminazione dei processi di sicurezza critici.

Il BYOVD come tecnica EDR killer sfrutta un debito architetturale che si è accumulato in decenni di sviluppo dell’ecosistema Windows. Ogni driver firmato legittimamente in vent’anni di storia informatica è un potenziale strumento nelle mani di un attaccante. E poiché questi driver erano progettati per scopi legittimi – forensics, gestione hardware, anti-rootkit, anti-cheat gaming – nessuno ha mai pensato di limitare le loro capacità kernel-mode in modo granulare.

Questo debito del driver legacy è strutturalmente analogo al debito tecnico nel software: una scelta ragionevole al momento della progettazione che diventa un rischio crescente con il passare del tempo. La differenza è che il debito tecnico nel software si paga con costi di manutenzione; il debito del driver legacy si paga con intrusioni ransomware riuscite.

Contromisure operative: cosa funziona davvero e cosa è un’illusione

Definito il problema nella sua dimensione reale, è necessario analizzare le contromisure con lo stesso rigore critico. Non tutte le difese proposte sono ugualmente efficaci, e alcune creano un falso senso di sicurezza.

HVCI (Hypervisor-Protected Code Integrity)

È la difesa più robusta attualmente disponibile. HVCI utilizza la virtualizzazione hardware per proteggere la memoria kernel, impedendo l’esecuzione di codice non firmato o non conforme alle policy. Quando HVCI è attivo, la Vulnerable Driver Blocklist di Microsoft viene effettivamente applicata. Huntress lo raccomanda esplicitamente come prima contromisura: abilitare HVCI / Memory Integrity garantisce che la blocklist dei driver vulnerabili sia effettivamente enforced.

Il problema: HVCI può causare incompatibilità con driver legacy e applicazioni che richiedono accesso diretto al kernel. Alcune organizzazioni lo disabilitano per ragioni operative, esponendosi esattamente all’attacco che dovrebbe prevenire.

WDAC (Windows Defender Application Control)

WDAC consente di definire policy granulari su quali driver e applicazioni possono essere eseguiti. Configurato correttamente in modalità allowlist, WDAC può bloccare proattivamente il caricamento di qualsiasi driver non esplicitamente autorizzato, inclusi quelli non ancora presenti nella blocklist di Microsoft.

È la contromisura più efficace in termini di copertura, ma anche la più complessa da implementare. Richiede un inventario accurato di tutti i driver legittimi necessari nell’ambiente, un processo di test rigoroso e una gestione continua delle eccezioni. In ambienti enterprise complessi, il deployment di WDAC in modalità enforced può richiedere mesi.

ASR Rules (Attack Surface Reduction)

La regola ASR “Block abuse of exploited vulnerable signed drivers” impedisce a un’applicazione di scrivere su disco un driver vulnerabile firmato. Tuttavia, come documentato da Microsoft, questa regola non blocca un driver già presente nel sistema – agisce solo sulla fase di installazione. Inoltre, le ASR rules dipendono da Microsoft Defender e possono essere disattivate da processi in user-mode, il che ne limita l’efficacia contro attaccanti che hanno già ottenuto privilegi elevati.

Monitoraggio comportamentale e telemetria

Se le difese preventive falliscono – e come abbiamo visto, in molti ambienti mancano i prerequisiti per attivarle – il rilevamento diventa l’ultima linea di difesa. I SOC dovrebbero monitorare attivamente: la creazione di servizi kernel con nomi che mimano componenti OEM o hardware; il caricamento di driver non standard, specialmente se firmati con certificati obsoleti; la terminazione anomala dei processi EDR; l’uso di sc.exe per la creazione di nuovi servizi kernel; l’attività IOCTL sospetta verso driver appena caricati.

Huntress ha evidenziato come la telemetria SIEM proveniente dal SonicWall sia stata determinante per ricostruire la timeline dell’intrusione. La lezione operativa è chiara: la visibilità a livello di rete e di autenticazione deve complementare, non sostituire, la protezione endpoint.

Il quadro strategico: dalla rincorsa delle blocklist alla riduzione strutturale del rischio

Il BYOVD come vettore EDR killer mette in discussione un assunto implicito della sicurezza endpoint degli ultimi dieci anni: che l’EDR sia sufficiente come difesa primaria.

Non lo è. Non perché l’EDR non funzioni – funziona eccellentemente nel proprio dominio. Ma perché opera a un livello di privilegio inferiore rispetto allo spazio in cui gli attaccanti possono agire quando sfruttano un driver kernel vulnerabile. È come avere una guardia armata all’ingresso che un intruso può addormentare prima di entrare.

La risposta strategica non è abbandonare l’EDR, ma costruire architetture dove la compromissione dell’EDR non equivalga alla compromissione dell’intero ambiente. Questo significa defense in depth reale, non come slogan ma come architettura: segmentazione di rete che limita il lateral movement indipendentemente dallo stato dell’endpoint; monitoraggio a livello di rete e di identità che non dipende dall’agente endpoint; policy di allowlisting dei driver che prevengono il caricamento di codice non autorizzato a livello kernel; autenticazione multifattore robusta su ogni punto di accesso remoto (l’incidente Huntress è iniziato con credenziali VPN senza MFA).

Il modello mentale deve evolvere dalla domanda “il nostro EDR rileverà l’attacco?” alla domanda “cosa succede se l’attaccante spegne il nostro EDR?”. Se la risposta alla seconda domanda è “non abbiamo visibilità e non possiamo contenere l’intrusione”, l’architettura difensiva ha un problema strutturale che nessun upgrade dell’EDR potrà risolvere.

Implicazioni per NIS2, DORA e la compliance

Il fenomeno EDR killer BYOVD ha implicazioni dirette per i framework normativi europei in fase di implementazione. NIS2 richiede alle organizzazioni essenziali e importanti di adottare misure di gestione del rischio proporzionate, inclusa la sicurezza della supply chain e la gestione delle vulnerabilità. Un ambiente in cui driver legacy vulnerabili possono essere sfruttati per disabilitare le difese endpoint rappresenta un rischio di supply chain tecnologica che deve essere esplicitamente indirizzato nel risk assessment.

Non si tratta di un rischio teorico: CISA ha aggiornato l’advisory congiunto su Akira nel novembre 2025 documentando specificamente l’uso di malware POORTRY per modificare configurazioni BYOVD su driver vulnerabili e disabilitare le protezioni endpoint, confermando che il fenomeno è monitorato dalle autorità di sicurezza a livello internazionale.

DORA, per le entità finanziarie, richiede test di resilienza operativa digitale che includano scenari di threat-led penetration testing. I TLPT dovrebbero necessariamente includere scenari BYOVD per validare la capacità dell’organizzazione di rilevare e contenere un’intrusione in cui l’EDR è stato neutralizzato.

La responsabilità ricade sull’organizzazione, non sul vendor EDR. Se un ransomware riesce a cifrare l’ambiente perché l’EDR è stato spento con un driver vulnerabile che avrebbe potuto essere bloccato da HVCI o WDAC, la domanda delle autorità di supervisione sarà: perché queste contromisure non erano abilitate?

Cosa aspettarsi: il BYOVD embedded come nuovo standard

Il caso Reynolds non è un’anomalia. È un segnale direzionale.

Come ha osservato il Symantec and Carbon Black Threat Hunter Team, l’integrazione di capacità aggiuntive direttamente nel payload ransomware potrebbe funzionare come unique selling point per gli sviluppatori che cercano di attrarre affiliati. In un mercato RaaS competitivo, offrire un payload che gestisce autonomamente l’evasione difensiva riduce la complessità per l’affiliato e rende gli attacchi più facili da eseguire.

È ragionevole prevedere che nel corso del 2026 vedremo altri gruppi ransomware adottare il modello del BYOVD embedded, e che la ricerca di driver vulnerabili ancora non presenti nella blocklist di Microsoft diventerà un’attività sistematica da parte dei threat actor. I numeri supportano questa proiezione: secondo i dati aggregati da Cyble e ReliaQuest, gli attacchi ransomware nel 2025 hanno raggiunto quota 4.737, in aumento rispetto ai 4.701 del 2024, con il riscatto medio balzato a 591.988 dollari nel Q4 2025 (+57% sul trimestre precedente, secondo Coveware).

In un ecosistema dove la competizione tra gang è feroce e le barriere d’ingresso continuano a scendere, offrire un payload con EDR killer BYOVD integrato diventa un vantaggio competitivo concreto nel reclutamento di affiliati. La corsa è già in atto: ogni driver firmato legittimamente in due decenni di storia Windows è un potenziale candidato.

Per i difensori, questo significa che la finestra per implementare contromisure strutturali – HVCI, WDAC, segmentazione, monitoraggio indipendente dall’endpoint – si sta chiudendo. Il BYOVD non è una minaccia futura: è il presente del ransomware. E il costo dell’inazione non è più un rischio teorico da inserire nel risk register. È un incidente in attesa di accadere.

Checklist operativa per SOC analyst e security architect

Per chi deve tradurre questa analisi in azioni concrete, ecco le priorità operative immediate:

• Verificare lo stato di HVCI/Memory Integrity su tutti gli endpoint Windows. Se disabilitato, pianificare l’attivazione con test di compatibilità. Senza HVCI, la Vulnerable Driver Blocklist di Microsoft potrebbe non essere enforced correttamente.
• Valutare il deployment di WDAC in modalità audit come primo passo, per identificare i driver caricati nell’ambiente e costruire una policy di allowlisting progressiva.
• Abilitare la regola ASR “Block abuse of exploited vulnerable signed drivers” su tutti gli endpoint con Microsoft Defender attivo.
• Implementare il monitoraggio SIEM per la creazione di servizi kernel anomali, il caricamento di driver non standard e la terminazione dei processi EDR. In particolare, monitorare chiamate DeviceIoControl verso device handle sconosciuti e la creazione di link simbolici (\??) verso driver appena installati.
• Condurre un inventario dei driver kernel attualmente caricati nell’ambiente tramite PowerShell (Get-WindowsDriver o driverquery /si) e confrontarlo con la Vulnerable Driver Blocklist di Microsoft per identificare driver a rischio già presenti.
• Verificare che l’MFA sia attiva su tutti i servizi di accesso remoto (VPN, RDP, SSH). L’incidente Huntress è iniziato con credenziali VPN senza MFA.
• Testare lo scenario “EDR down” negli esercizi di incident response e nei TLPT previsti da DORA: cosa succede se l’attaccante spegne l’EDR? Quali controlli compensativi entrano in funzione? Se la risposta è “nessuno”, l’architettura ha un problema strutturale.
• Aggiornare la Vulnerable Driver Blocklist manualmente se non si è su Windows 11 22H2 o successivo. Le versioni precedenti di Windows potrebbero avere una blocklist obsoleta.
• Implementare il monitoraggio dei driver con certificati obsoleti. Configurare regole di alerting per il caricamento di driver kernel firmati con certificati emessi prima del 2015, con particolare attenzione a quelli con timestamp di firma antecedenti al 2010.

https://www.ictsecuritymagazine.com/cyber-crime/edr-killer-byovd-endpoint/

Dalla Florida alla California, negli Stati Uniti le forze dell’ordine iniziano a sperimentare nuovi strumenti di AI per l’analisi geospaziale delle immagini. Gli uffici dello sceriffo di Miami-Dade e il Los Angeles Police Department hanno acquistato GeoSpy, un sistema capace di individuare in pochi istanti la possibile posizione geografica di una fotografia analizzandone gli elementi visivi: architetture, vegetazione, conformazione del terreno, dettagli ambientali.

A rivelarlo sono email interne ottenute tramite richieste FOIA (Freedom of Information Act), e analizzata dal quotidiano statunitense 404media, che offrono uno spaccato concreto sull’uso operativo della tecnologia.

Gli obiettivi? Generare pista investigative preliminari

Nel caso di Miami-Dade, il dipartimento dispone sia di un modello globale sia di una versione addestrata specificamente sulla contea. L’obiettivo dichiarato è generare piste investigative preliminari, soprattutto nei casi in cui una semplice immagine possa contenere indizi territoriali difficili da individuare con l’occhio umano. Allo stesso tempo, dalle comunicazioni emerge consapevolezza dei limiti dello strumento: il sistema è ancora in fase di test e può produrre falsi positivi.

Le email mostrano un interesse trasversale all’interno dei dipartimenti. Dalla divisione rapine alle unità cyber, diversi reparti vedono in GeoSpy un possibile acceleratore nelle indagini complesse, comprese quelle che riguardano la diffusione online di materiale di abuso sessuale minorile. La promessa è quella di trasformare immagini apparentemente decontestualizzate in indizi geospaziali utili a circoscrivere un’area o individuare un luogo.

GeoSpy: costo dell’operazione? 80mila dollari

Il costo dell’operazione non è marginale. Miami-Dade avrebbe investito oltre 80 mila dollari tra modelli personalizzati e pacchetti di ricerche. Una cifra che segnala la crescente propensione delle agenzie a puntare su sistemi automatizzati di analisi delle immagini, anche in assenza — almeno finora — di arresti o risultati investigativi attribuibili esclusivamente al software.

Parallelamente, Graylark Technologies, società dietro GeoSpy, starebbe valutando applicazioni future anche in ambiti non strettamente investigativi. Intanto l’accesso pubblico alla versione consumer del servizio è stato sospeso dopo precedenti inchieste giornalistiche che ne avevano evidenziato le potenziali implicazioni in termini di privacy e sorveglianza.

Dalle comunicazioni interne emerge infine un approccio prudente. I funzionari invitano a limitare la circolazione di dati sensibili e a considerare le indicazioni fornite dal sistema come semplici spunti investigativi, da verificare attraverso metodi tradizionali. Ma senza regole chiare, audit indipendenti e limiti operativi rigorosi il rischio è quello di ampliare in modo silenzioso l’infrastruttura di sorveglianza digitale. Il tema diventa ancora più delicato se tecnologie simili dovessero essere impiegate in ambiti federali o in operazioni collegate all’ICE.

Leggi le altre notizie sull’home page di Key4biz

https://www.key4biz.it/ai-negli-usa-la-polizia-adotta-il-software-ai-che-geolocalizza-le-foto-come-funziona-geospy/565361/

Feb 09, 2026 Redazione Attacchi, In evidenza, News, RSS 0

Il panorama delle minacce informatiche è in continuo cambiamento e recentemente si sta assistendo a  una metamorfosi del phishing dove la tecnica del mascheramento cede il passo all’abuso deliberato delle infrastrutture cloud legittime. Check Point Software Technologies ha recentemente portato alla luce una campagna di phishing massiva che, invece di creare domini fraudolenti, utilizza le funzionalità native delle piattaforme Software-as-a-Service (SaaS) per veicolare truffe telefoniche. L’operazione ha già raggiunto numeri impressionanti, con circa 133.260 e-mail inviate che hanno messo nel mirino oltre 20.000 aziende a livello globale, sfruttando la reputazione di giganti come Microsoft, Zoom e Amazon.

Questa strategia segna un cambio di paradigma fondamentale nel social engineering, poiché le esche non sono semplici imitazioni ma comunicazioni generate dai sistemi reali dei fornitori. Inserendo contenuti fraudolenti nei campi controllati dall’utente, come i dati del profilo o i metadati di fatturazione, gli attaccanti costringono le piattaforme a inviare notifiche ufficiali che superano indenni ogni controllo di autenticazione come SPF, DKIM e DMARC. Il risultato è un messaggio che eredita la totale fiducia e autorevolezza del brand mittente, rendendo quasi impossibile il rilevamento da parte dei sistemi di sicurezza automatizzati e abbassando drasticamente la soglia di sospetto degli utenti.

Un fenomeno in rapida crescita

L’analisi dei dati evidenzia un’accelerazione verticale del fenomeno negli ultimi mesi: se nell’ultimo semestre si sono registrate circa 648.291 e-mail malevole, ben 463.773 di queste sono state concentrate negli ultimi tre mesi. Questa impennata suggerisce che i criminali informatici considerino l’abuso del SaaS un meccanismo di distribuzione estremamente scalabile e redditizio. David Gubiani, Regional Director Security Engineering di Check Point, sottolinea come a peggiorare la situazione (rendendo gli attacchi potenzialmente molto più  efficaci) dopo il primo approccio tramite email, l’operatività venga spostata al telefono, tramite l’indicazione di chiamare il call center per sistemare il problema. In questo modo, si bypassa l’analisi degli URL e il sandboxing, trasferendo il cuore dell’attacco verso una manipolazione vocale diretta, dove il fattore umano diventa l’anello debole.

I metodi identificati spaziano dalla manipolazione dei campi profilo su piattaforme come YouTube e Malwarebytes, alla generazione di notifiche di abbonamento fraudolente tramite i flussi di lavoro di Microsoft Entra ID e Power BI. Particolarmente sofisticato è l’abuso degli inviti di Amazon Business, dove gli aggressori inseriscono falsi addebiti e finti numeri di assistenza da chiamare direttamente nei campi dell’invito aziendale. In tutti questi casi, le piattaforme non sono state compromesse nel senso tradizionale del termine: sono le loro funzionalità legittime a essere utilizzate impropriamente per dare credibilità a una truffa che si conclude con una chiamata a un call center controllato dai criminali.

USA bersaglio preferito, ma Europa al secondo posto

A livello settoriale, il comparto Tecnologia e IT è il più colpito con il 26,8% dei casi, seguito dalla produzione industriale e dal settore dell’istruzione. Geograficamente, gli Stati Uniti rimangono il bersaglio principale, ma l’Europa segue a ruota con una quota del 17,8%, a dimostrazione della portata globale dell’offensiva. La lezione per i difensori è chiara: la provenienza di un’e-mail da un dominio affidabile non è più una garanzia di sicurezza. È necessaria un’evoluzione delle strategie di difesa che passi attraverso l’analisi contestuale dei messaggi e una formazione degli utenti capace di riconoscere le nuove dinamiche del phishing vocale basato su servizi cloud.

• Amazon Business, brand impersonation, Check Point Software, cybersecurity, IT Security, Microsoft 365, minacce informatiche 2026, Phishing, Protezione dati, SaaS abuse, sicurezza cloud, sicurezza informatica, social engineering, truffe telefoniche, Zoom

Feb 03, 2026 Redazione news In evidenza, News, RSS, Tecnologia 0

Microsoft ha comunicato che l’autenticazione NTLM verrà disabilitata di default nelle future versioni, lasciando comunque il protocollo presente nel sistema operativo e riattivabile solo tramite policy quando davvero necessario.

Perché NTLM è un bersaglio: relay, replay e pass-the-hash

Il problema di NTLM non è soltanto la sua età, ma la sua esposizione a classi di attacchi che si innestano bene in ambienti enterprise moderni. Microsoft, e diversi esperti, citano esplicitamente relay, replay e man-in-the-middle come le “famiglie” di tecniche che diventano particolarmente pericolose quando un attore malevolo riesce a posizionarsi “in mezzo” a una conversazione di rete o a sfruttare autenticazioni legacy per muoversi lateralmente. In termini di tassonomie operative, il tema si collega a pattern noti come l’Adversary-in-the-Middle e il pass-the-hash, che continuano a comparire un po’ troppo spesso quando si fa la forensica di un attacco proprio perché “funzionano” quando l’azienda mantiene queste dipendenze.

La roadmap in tre fasi: audit, nuove capability Kerberos, poi blocco di default

Microsoft ha strutturato la transizione in tre fasi per ridurre il rischio senza provocare un blackout improvviso di applicazioni e servizi. La prima fase ruota attorno a capacità di auditing potenziate, già disponibili su Windows 11 24H2 e Windows Server 2025, utili a capire dove e perché NTLM viene ancora usato. La seconda fase, prevista per la seconda metà del 2026, introduce nuove funzionalità pensate per “chiudere” i buchi che oggi portano al fallback su NTLM, tra cui IAKerb e un Local Key Distribution Center (Local KDC). La terza fase è quella decisiva: nelle future release, l’NTLM di rete sarà disabilitato per impostazione predefinita, pur restando riabilitabile tramite policy per scenari legacy inevitabili.

“Disabilitato di default” non significa “rimosso”: cosa cambia operativamente

Microsoft sottolinea che non si tratta ancora della rimozione completa del protocollo, ma di una consegna del sistema in uno stato più sicuro “by default”, dove l’OS preferisce alternative moderne e Kerberos-based. Questo permetterà di usare NTLM ancora, ma sarà una scelta chiara dell’utente e non un possibile ripiego automatico in caso di sfruttamento di una vulnerabilità o un derivato di vecchie configurazioni di cui si è persa memoria.

In molte reti, infatti, l’uso di NTLM non è “intenzionale”, ma il risultato di condizioni che impediscono a Kerberos di funzionare come previsto. Microsoft, nella propria serie di hardening su Active Directory, entra nel dettaglio delle cause tipiche: problemi di connettività verso i domain controller, uso di account locali, errori o assenza di Service Principal Name (SPN), accesso alle risorse via indirizzo IP invece che tramite FQDN, oppure applicazioni configurate (o addirittura hardcoded) per chiamare NTLM. Ed è proprio qui che la roadmap prova a intervenire: IAKerb nasce per gestire scenari dove il client non ha una visione completa, mentre LocalKDC mira a ridurre l’uso di NTLM in autenticazioni basate su account locali, storicamente uno dei punti più difficili da eliminare.

Audit potenziato: visibilità prima del blocco

La parte più importante, oggi, è ottenere telemetria affidabile su dove NTLM sta ancora transitando. Microsoft indica esplicitamente che Windows 11 24H2 e Windows Server 2025 offrono auditing più ricco per identificare dipendenze e priorità di remediation, evitando di scoprire “a produzione ferma” che un pezzo di infrastruttura si appoggia ancora al legacy. Nella pratica, la stessa documentazione Microsoft enfatizza la necessità di mappare le dipendenze applicative e validare i workload critici con Kerberos, iniziando a testare configurazioni “NTLM-off” in ambienti non produttivi.

Questo implica un uso approfondito dei log: NTLM va trattato come un “debito tecnico misurabile”, non come un dettaglio di protocollo. Nei suggerimenti sull’hardening dello scenario, Microsoft cita famiglie di eventi utili a capire chi autentica, verso cosa e con quale versione negoziata; nelle build più recenti (24H2/Server 2025) compaiono anche eventi più dettagliati che aiutano a ricostruire il motivo del fallback e, in alcuni casi, il processo coinvolto. L’obiettivo operativo è trasformare l’eliminazione di NTLM in un percorso governato: riduzione progressiva, controllo dell’impatto e blocchi mirati dove non esistono più dipendenze.

NTLMv1: già fuori gioco, ma attenzione ai “derivati” e alle eredità crittografiche

Il percorso di dismissione è iniziato da tempo: NTLMv1 risulta già rimosso in Windows 11 24H2 e Windows Server 2025, ma restano casi in cui sopravvivono elementi di crittografia legacy. Microsoft descrive esplicitamente scenari in cui “rimasugli” di NTLMv1 possono ancora emergere, ad esempio in contesti legati a MS-CHAPv2 in ambienti domain-joined, e introduce chiavi di registro e log dedicati per passare da una modalità di audit a una di enforcement. La timeline pubblica include anche un punto rilevante: a ottobre 2026, in assenza di configurazione esplicita, il default può spostarsi verso una postura più restrittiva per specifici meccanismi collegati a derivati di NTLMv1.

La sicurezza dei dispositivi medicali IoMT (Internet of Medical Things) rappresenta oggi uno dei paradossi più critici e meno discussi nel panorama della cybersecurity sanitaria europea. Il Regolamento MDR 2017/745 impone che i dispositivi certificati CE non possano essere modificati – inclusa l’installazione di software antivirus o l’applicazione di patch di sicurezza – senza invalidare la certificazione stessa.

Questa rigidità normativa, concepita per tutelare la sicurezza del paziente, si scontra frontalmente con le esigenze di protezione cyber imposte dalla Direttiva NIS2 e dalle minacce ransomware che nel 2024 hanno colpito il 67% delle organizzazioni sanitarie a livello globale, secondo il report Sophos condotto su 14 Paesi. L’articolo analizza questo conflitto regolatorio e propone il modello della “securizzazione laterale” – basato su microsegmentazione di rete e architetture Zero Trust – come soluzione architetturale che consente di proteggere i dispositivi senza alterarne la configurazione certificata.

Il nodo irrisolto della sicurezza IoMT negli ospedali europei

La sicurezza IoMT è diventata la questione centrale per ogni CISO del settore sanitario. Il motivo è tanto semplice quanto allarmante: secondo analisi di settore basate su dati Forescout, la stragrande maggioranza degli ospedali gestisce dispositivi medicali con vulnerabilità note e attivamente sfruttate dagli attaccanti. Non si tratta di un dato astratto, ma di una realtà operativa quotidiana che i responsabili della sicurezza informatica ospedaliera conoscono bene.

Il problema, tuttavia, non risiede nella mancanza di consapevolezza o di competenze tecniche. Il vero ostacolo è strutturale e normativo: i dispositivi medicali certificati CE ai sensi del Regolamento MDR 2017/745 non possono essere modificati senza compromettere la loro conformità regolatoria. Questo significa che un monitor cardiaco, una pompa per infusione o un sistema di imaging diagnostico – tutti dispositivi critici per la cura del paziente – devono rimanere esattamente nella configurazione in cui sono stati certificati, anche quando presentano vulnerabilità software documentate.

Il paradosso emerge in tutta la sua evidenza: la normativa pensata per proteggere il paziente impedisce di fatto l’implementazione delle misure di cybersecurity necessarie a proteggerlo da minacce che, secondo il report IBM Cost of a Data Breach 2024, hanno causato danni per una media di 9,77 milioni di dollari per ogni violazione nel settore sanitario – il costo più alto tra tutti i comparti industriali per il quattordicesimo anno consecutivo.

Il conflitto normativo: MDR 2017/745 versus requisiti di cybersecurity

Per comprendere la profondità di questo conflitto è necessario esaminare le due cornici normative che, paradossalmente, dovrebbero entrambe tutelare la sicurezza dei pazienti.

Il Regolamento MDR 2017/745: la logica della certificazione

Il Medical Device Regulation europeo, entrato in vigore nel maggio 2021, ha sostituito le precedenti direttive introducendo requisiti più stringenti per l’immissione sul mercato dei dispositivi medicali. L’Allegato I, Sezione 17.2, stabilisce che il software contenuto nei dispositivi medicali deve essere sviluppato e prodotto “allo stato dell’arte”, considerando il ciclo di vita, la gestione del rischio e la sicurezza delle informazioni.

Tuttavia, la certificazione CE – rilasciata dagli Organismi Notificati dopo rigorosi processi di valutazione della conformità – cristallizza la configurazione del dispositivo. Qualsiasi modifica sostanziale richiede una nuova valutazione di conformità, con tempi e costi che possono risultare proibitivi. Il principio sottostante è chiaro: garantire che il dispositivo funzioni esattamente come testato e validato, senza alterazioni che potrebbero comprometterne la sicurezza clinica.

Questa rigidità ha senso dal punto di vista della sicurezza del paziente in senso tradizionale. Un’alterazione del firmware di una pompa per infusione potrebbe teoricamente modificarne il dosaggio; un aggiornamento software di un ventilatore polmonare potrebbe introdurre malfunzionamenti. La certificazione CE è progettata per prevenire questi rischi.

La Direttiva NIS2: l’imperativo della cybersecurity

Sul versante opposto, la Direttiva NIS2 – in vigore dal 18 ottobre 2024 – classifica ospedali e produttori di dispositivi medicali come “entità essenziali” o “importanti”, imponendo obblighi stringenti in materia di gestione del rischio cyber. L’Articolo 21(2) elenca dieci misure di sicurezza obbligatorie, tra cui la gestione delle vulnerabilità, la sicurezza della supply chain e la capacità di risposta agli incidenti.

Il problema emerge quando si considera che la gestione delle vulnerabilità, nel contesto IT tradizionale, si traduce principalmente nell’applicazione tempestiva di patch di sicurezza. Ma per un dispositivo medicale certificato CE, applicare una patch significa potenzialmente invalidare la certificazione.

Un esempio concreto: la pompa per infusione vulnerabile

Consideriamo uno scenario reale documentato dalla University of New Brunswick nel dataset CICIoMT2024. Una pompa per infusione connessa alla rete ospedaliera presenta una vulnerabilità nota nel protocollo MQTT utilizzato per la comunicazione. Gli attaccanti possono sfruttare questa vulnerabilità per intercettare i comandi o, nel peggiore dei casi, alterare i parametri di infusione.

La soluzione tecnica sarebbe immediata: applicare la patch rilasciata dal vendor o, in alternativa, installare un agente di endpoint protection. Tuttavia, entrambe le opzioni comporterebbero una modifica del software del dispositivo. Secondo la lettura più conservativa del MDR, questo richiede una nuova valutazione di conformità da parte dell’Organismo Notificato – un processo che può richiedere mesi e che il vendor potrebbe non essere disposto ad affrontare per dispositivi già in commercio.

Il risultato? La pompa rimane vulnerabile, connessa alla rete ospedaliera, in attesa che il vendor rilasci un aggiornamento già validato nell’ambito del suo processo di Post-Market Surveillance. Un’attesa che può protrarsi per anni nei casi di dispositivi legacy.

La fotografia delle vulnerabilità IoMT nel 2025

I numeri raccontano una situazione critica. Il report 2025 di Forescout documenta un incremento del 15% anno su anno del rischio medio dei dispositivi connessi, con quattro nuove tipologie di dispositivi IoMT entrate nella lista dei più rischiosi: dispositivi di imaging, apparecchiature di laboratorio, workstation sanitarie e controller per pompe di infusione. Questi ultimi sono particolarmente critici poiché una compromissione potrebbe permettere agli attaccanti di alterare i parametri di somministrazione dei farmaci.

Secondo analisi di settore, una percentuale significativa dei dispositivi medicali opera su sistemi operativi end-of-life che non ricevono più aggiornamenti di sicurezza, mentre i controller delle pompe di infusione mostrano vulnerabilità critiche e wormable nel 20% dei casi analizzati.

La situazione in Italia

In Italia, la situazione è particolarmente preoccupante. L’Agenzia per la Cybersicurezza Nazionale ha documentato un incremento del 111% degli eventi cyber nel settore sanitario tra il 2023 e il 2024, passando da 27 a 57 eventi. Gli incidenti effettivi hanno raggiunto quota 57, influenzati in parte da un attacco supply chain che ha coinvolto numerosi clienti del settore sanitario attraverso un fornitore. Nel solo 2024 sono stati registrati 10 casi significativi di ransomware che hanno colpito strutture sanitarie italiane.

L’attacco alla ASST Rhodense del giugno 2024 esemplifica le conseguenze operative: il gruppo ransomware Cicada3301 ha compromesso i sistemi informatici degli ospedali di Garbagnate, Bollate e Rho, costringendo le strutture a sospendere interventi chirurgici non urgenti, esami di laboratorio e altri servizi programmati. Il gruppo ha rivendicato l’esfiltrazione di 1 terabyte di dati sensibili, inclusi documenti medici, prescrizioni e informazioni personali dei pazienti.

Il contesto europeo

A livello europeo, i dati di Check Point Research per gennaio-settembre 2024 indicano che le organizzazioni sanitarie europee hanno subito una media di 1.686 attacchi settimanali per organizzazione, con un incremento del 56% rispetto allo stesso periodo dell’anno precedente – il maggiore aumento percentuale tra tutte le regioni analizzate. L’Italia si posiziona tra i Paesi più colpiti nel settore healthcare a livello globale.

La securizzazione laterale: proteggere senza modificare

Di fronte a questo paradosso normativo, la comunità della cybersecurity sanitaria ha sviluppato un approccio alternativo che consente di proteggere i dispositivi medicali IoMT senza alterarne la configurazione interna. Questo paradigma, che possiamo definire “securizzazione laterale”, opera esclusivamente sul contesto di rete in cui il dispositivo è inserito, lasciando intatto il software certificato.

Il principio architetturale

L’idea fondamentale è semplice: se non posso installare un antivirus sul dispositivo, posso però controllare con precisione chi può comunicare con esso e come. Invece di proteggere il dispositivo dall’interno, lo proteggo dall’esterno, creando un perimetro di sicurezza granulare che ne limita l’esposizione alle minacce.

Questo approccio si articola in tre componenti principali:

Visibilità completa dell’ambiente IoMT. Prima di proteggere, è necessario conoscere. Piattaforme come Claroty Medigate o Armis consentono di identificare automaticamente tutti i dispositivi medicali connessi alla rete, classificarli per tipologia e rischio, e mappare i loro pattern di comunicazione legittimi.

Microsegmentazione identity-based. Una volta identificati i dispositivi e i loro flussi di comunicazione autorizzati, è possibile implementare policy di segmentazione granulare che consentano solo il traffico strettamente necessario. Un monitor cardiaco, ad esempio, deve poter comunicare con il sistema di gestione dei dati clinici (PACS) e con la workstation del reparto, ma non ha alcun motivo legittimo per accedere a Internet o comunicare con la stampante dell’amministrazione.

Prevenzione del lateral movement. Il vero valore della microsegmentazione emerge nella capacità di contenere un’eventuale compromissione. Se un attaccante riesce a violare un dispositivo vulnerabile, la segmentazione impedisce che possa utilizzarlo come punto di pivot per raggiungere altri sistemi critici. Il lateral movement rappresenta un vettore di attacco prevalente nelle violazioni riuscite nel settore sanitario.

Il caso MultiCare Health System

L’implementazione della microsegmentazione in ambito sanitario trova un esempio significativo nel caso di MultiCare Health System, il più grande sistema sanitario no-profit dello Stato di Washington con 14 ospedali e circa 29.000 dipendenti.

Jason Elrod, CISO di MultiCare, ha affrontato la sfida partendo da una posizione di scetticismo – come lui stesso ha dichiarato – verso le promesse dei vendor. L’implementazione di una piattaforma di microsegmentazione identity-based ha permesso di ottenere il 99% di visibilità sui dispositivi connessi in meno di 4 ore, con un deployment completo delle policy di segmentazione in 4-16 settimane, senza alcuna interruzione dei flussi clinici.

L’aspetto cruciale dell’approccio adottato è che la protezione avviene a livello di rete, senza richiedere l’installazione di agenti software sui dispositivi medicali. Questo consente di proteggere anche dispositivi legacy che operano su sistemi operativi obsoleti – come Windows 7 o Windows XP Embedded – impossibili da aggiornare sia per ragioni tecniche che normative.

L’allineamento con i nuovi requisiti regolatori

La securizzazione laterale non è solo una soluzione tecnica elegante; sta diventando un requisito normativo esplicito.

Stati Uniti: la proposta di aggiornamento HIPAA Security Rule

La proposta di aggiornamento alla HIPAA Security Rule, pubblicata dall’Office for Civil Rights (OCR) del Department of Health and Human Services il 27 dicembre 2024, prevede esplicitamente la segmentazione di rete come misura obbligatoria per la protezione delle informazioni sanitarie elettroniche (ePHI). Il documento elimina la distinzione tra specifiche required e addressable, rendendo di fatto obbligatorie tutte le misure di sicurezza precedentemente considerate opzionali.

Il periodo di commenti pubblici si è chiuso il 7 marzo 2025 e si attende la pubblicazione della regola finale entro la fine dell’anno. Le organizzazioni sanitarie statunitensi dovrebbero già prepararsi a soddisfare questi requisiti.

Europa: le linee guida per il settore sanitario

Le linee guida HHS 405(d) Health Industry Cybersecurity Practices richiedono esplicitamente capacità di defense-in-depth attraverso la segmentazione di rete, con particolare enfasi sulla prevenzione del lateral movement. L’NHS Digital britannico ha rilasciato guidance che impongono la segmentazione di rete come requisito per tutti i Trust del sistema sanitario nazionale.

Implicazioni operative per i professionisti della sicurezza sanitaria

Per i CISO e i security architect del settore sanitario, questo scenario impone un ripensamento delle strategie di protezione. Non è più possibile affidarsi esclusivamente alle tradizionali misure di endpoint security; è necessario adottare un approccio architetturale che riconosca le specificità dell’ambiente IoMT.

Assessment della superficie di attacco IoMT

Il primo passo è acquisire visibilità completa sull’inventario dei dispositivi medicali connessi. La mancanza di visibilità è indicata da una percentuale significativa di CISO ospedalieri come la principale barriera alla gestione efficace del rischio IoMT. Non è possibile proteggere ciò che non si conosce.

Piattaforme specializzate nella discovery IoMT consentono di identificare dispositivi che spesso sfuggono ai tradizionali strumenti di network scanning, includendo apparecchiature biomedicali, sistemi di building automation connessi alla rete clinica e dispositivi shadow IT introdotti dai reparti senza coinvolgimento dell’IT centrale.

Prioritizzazione risk-based

Non tutti i dispositivi presentano lo stesso livello di rischio. Un sistema di imaging diagnostico connesso al PACS e contenente dati clinici di migliaia di pazienti richiede una protezione diversa rispetto a un sensore di temperatura ambientale. La prioritizzazione deve considerare:

• la criticità clinica del dispositivo per la cura del paziente;
• la sensibilità dei dati trattati;
• il livello di connettività e l’esposizione a Internet;
• la presenza di vulnerabilità note con exploit pubblici;
• la disponibilità o meno di patch da parte del vendor.

Secondo i dati di Forescout, i sistemi di imaging diagnostico e i dispositivi di monitoraggio dei pazienti rappresentano i target primari degli attacchi ai dispositivi medicali, seguiti da apparecchiature di laboratorio e pompe per infusione.

Implementazione della microsegmentazione

L’implementazione della microsegmentazione in ambiente sanitario richiede un approccio graduale che minimizzi il rischio di interruzione dei servizi clinici. Le best practice suggeriscono:

Fase di discovery e learning. Acquisire visibilità completa e mappare i pattern di comunicazione legittimi prima di implementare qualsiasi policy restrittiva.

Definizione delle policy in modalità audit. Configurare le regole di segmentazione in modalità di solo monitoraggio, verificando che non blocchino traffico clinico legittimo.

Enforcement progressivo. Attivare l’enforcement partendo dai segmenti meno critici, espandendo gradualmente la copertura.

Integrazione con incident response. Predisporre procedure per l’isolamento rapido di dispositivi compromessi senza impatto sui servizi clinici essenziali.

Gestione del rapporto con i vendor

Un aspetto spesso trascurato riguarda la relazione con i produttori di dispositivi medicali. La NIS2 impone esplicitamente requisiti di sicurezza della supply chain (Articolo 21(2)(d)), richiedendo alle organizzazioni sanitarie di valutare e monitorare la postura cyber dei propri fornitori.

I Manufacturer Disclosure Statements for Medical Device Security (MDS2) forniscono informazioni strutturate sulla sicurezza dei dispositivi, ma troppo spesso rimangono documenti statici che non vengono operazionalizzati. L’integrazione dei dati MDS2 con le piattaforme di microsegmentazione consente di tradurre automaticamente le caratteristiche di sicurezza dichiarate dal vendor in policy di protezione effettive.

Prospettive evolutive: verso una convergenza normativa

Il paradosso normativo tra MDR e requisiti cyber non potrà rimanere irrisolto a lungo. Diversi segnali indicano una progressiva consapevolezza della necessità di armonizzazione.

L’Action Plan europeo sulla cybersecurity ospedaliera

Il 15 gennaio 2025 la Commissione Europea ha pubblicato un Action Plan dedicato alla cybersecurity di ospedali e provider sanitari. Il documento riconosce esplicitamente l’interdipendenza tra provider sanitari e industria medicale, e propone misure che impattano l’intera supply chain del settore.

Tra le azioni più significative, il piano propone che gli Stati membri richiedano alle entità soggette a NIS2 di riportare i pagamenti di riscatti ransomware – un cambio significativo rispetto all’attuale framework. L’obiettivo dichiarato è raccogliere dati per comprendere l’efficacia delle misure anti-ransomware e supportare le investigazioni.

L’evoluzione dell’approccio FDA

Dall’altra parte dell’Atlantico, la FDA statunitense ha adottato un approccio più progressivo. Con la Sezione 524B del FD&C Act, introdotta nel dicembre 2022 tramite il Consolidated Appropriations Act, i produttori di dispositivi cyber sono ora obbligati a:

• fornire una Software Bill of Materials (SBOM) che documenti tutti i componenti software;
• progettare e mantenere processi per garantire la cybersecurity del dispositivo lungo l’intero ciclo di vita;
• rendere disponibili aggiornamenti e patch post-market.

La guidance finale aggiornata di giugno 2025 chiarisce esplicitamente i requisiti per i cyber devices e le aspettative per il ciclo di vita post-market.

Il Cyber Resilience Act europeo

Il Cyber Resilience Act europeo, parte del più ampio framework di cybersecurity dell’Unione, introduce requisiti di sicurezza by-design per i prodotti con componenti digitali. L’integrazione tra CRA, MDR e NIS2 dovrà necessariamente portare a un approccio più coerente alla gestione delle vulnerabilità nei dispositivi medicali.

Considerazioni conclusive

La sicurezza dei dispositivi medicali IoMT si trova oggi al centro di una tensione normativa che riflette due concezioni diverse – ma entrambe legittime – della protezione del paziente. La certificazione CE tutela il paziente da malfunzionamenti del dispositivo; la cybersecurity lo tutela da attacchi che potrebbero comprometterne l’integrità o renderlo indisponibile nel momento del bisogno.

La securizzazione laterale rappresenta, allo stato attuale, la risposta più efficace a questo paradosso. Proteggere il contesto invece del dispositivo consente di implementare misure di sicurezza robuste senza entrare in conflitto con i requisiti regolatori sulla certificazione.

Tuttavia, questa soluzione architetturale non può rimanere l’unica risposta a lungo termine. È necessario che il framework normativo europeo evolva verso un modello che consenta l’aggiornamento tempestivo dei dispositivi medicali senza richiedere complesse ri-certificazioni per ogni patch di sicurezza. L’esperienza FDA dimostra che questo equilibrio è possibile.

Nel frattempo, i professionisti della sicurezza IoMT nel settore sanitario devono adottare un approccio pragmatico: implementare la microsegmentazione come misura di protezione immediata, mantenere una visibilità completa sull’inventario dei dispositivi connessi e strutturare un dialogo costruttivo con i vendor per accelerare la disponibilità di aggiornamenti validati.

La posta in gioco è troppo alta per attendere una soluzione normativa perfetta. La significativa presenza di vulnerabilità note nei dispositivi medicali ospedalieri non è una statistica accettabile. È un rischio che richiede azione immediata, nei limiti – ma non oltre – di quanto la normativa consente.

https://www.ictsecuritymagazine.com/articoli/iomt/

L’ecosistema digitale contemporaneo poggia su fondamenta invisibili ma critiche: la catena di approvvigionamento del software. Ogni applicazione moderna integra centinaia di dipendenze, librerie e componenti esterni, creando una superficie di attacco che si estende ben oltre i confini del codice proprietario. Gli attacchi alla supply chain software hanno registrato un incremento del 200% nel 2023 rispetto all’anno precedente secondo il State of the Software Supply Chain Report di Sonatype, trasformando quello che era un vettore di attacco marginale in una minaccia sistemica per l’intero ecosistema tecnologico globale.

L’attacco a SolarWinds nel dicembre 2020 ha rappresentato un punto di non ritorno: la compromissione del processo di build ha permesso la distribuzione di aggiornamenti malevoli a oltre 18.000 organizzazioni, incluse agenzie governative statunitensi e corporation Fortune 500. Questo evento ha catalizzato la nascita di SLSA, un framework che ambisce a definire standard universali per la sicurezza della software supply chain.

Che cos’è il Framework SLSA: origini e architettura concettuale

SLSA (pronunciato “salsa”) è l’acronimo di Supply-chain Levels for Software Artifacts. Sviluppato originariamente da Google e successivamente adottato dalla Open Source Security Foundation (OpenSSF) come progetto community-driven, SLSA rappresenta un framework di sicurezza che definisce requisiti progressivi per proteggere l’integrità degli artefatti software durante l’intero ciclo di vita della produzione.

La filosofia architetturale di SLSA si distingue per tre caratteristiche fondamentali.

La prima è la progressività strutturata: anziché imporre requisiti monolitici, il framework articola la sicurezza in livelli incrementali che permettono un’adozione graduale, calibrata sulla maturità organizzativa e sulle risorse disponibili.

La seconda è la verificabilità empirica: ogni requisito SLSA è progettato per essere verificabile attraverso evidenze oggettive, principalmente mediante attestazioni crittograficamente firmate che documentano la provenance degli artefatti.

La terza è l’agnosticismo tecnologico: il framework prescinde da specifiche tecnologie o piattaforme, concentrandosi su principi universali applicabili a qualsiasi stack tecnologico.

La specifica corrente, SLSA v1.0, rilasciata il 19 aprile 2023, ha consolidato anni di iterazioni e feedback dalla community, introducendo una struttura più coerente e requisiti più pragmatici rispetto alle versioni precedenti. Una novità significativa della v1.0 è la suddivisione dei requisiti in track separati: la versione attuale definisce il Build Track con i livelli 1-3, mentre altri track (come il Source Track) sono previsti per versioni future.

Anatomia dei livelli SLSA: dal livello 0 al livello 3

Il framework SLSA nella versione 1.0 articola la maturità della supply chain security attraverso il Build Track, che comprende quattro livelli progressivi (da L0 a L3). Ciascun livello è caratterizzato da requisiti specifici che rafforzano le garanzie di integrità e provenance degli artefatti software.

Build L0: assenza di requisiti

Il livello zero rappresenta l’assenza di SLSA: nessun requisito è soddisfatto e non esistono garanzie di integrità degli artefatti. Questo livello descrive lo stato di partenza della maggior parte dei progetti software prima dell’adozione del framework.

Build L1: documentazione della provenance

Il primo livello operativo rappresenta il punto di ingresso nel framework e si focalizza sulla creazione di una traccia documentale del processo di build.

Il Livello 1 richiede che il processo di build produca attestazioni di provenance che documentino quale sorgente è stata utilizzata, quale processo di build è stato eseguito e quali artefatti sono stati generati. Queste attestazioni seguono il formato standardizzato in-toto, un framework per la supply chain integrity sviluppato alla NYU Tandon School of Engineering e ora progetto graduated della Cloud Native Computing Foundation.

La provenance al Livello 1 non richiede ancora garanzie crittografiche robuste: l’obiettivo primario è stabilire visibilità sul processo di build, creando le fondamenta per i livelli successivi. Come specificato nella documentazione SLSA, questo livello può essere facilmente aggirato o falsificato, ma fornisce comunque benefici significativi per audit e incident response.

Sebbene le garanzie di sicurezza al Livello 1 siano limitate, l’adozione di questo livello fornisce immediate capacità di tracciamento. In caso di vulnerabilità scoperta in una dipendenza, l’organizzazione può rapidamente identificare quali build sono potenzialmente compromessi.

Build L2: attestazioni firmate e build service autenticato

Il Livello 2 introduce requisiti crittografici che trasformano le attestazioni di provenance da semplici documenti a evidenze verificabili.

Le attestazioni di provenance devono essere crittograficamente firmate utilizzando chiavi gestite dal servizio di build. Questo garantisce che le attestazioni non possano essere falsificate o modificate retroattivamente senza invalidare la firma.

Il processo di build deve essere eseguito su un hosted build service che implementi controlli di autenticazione e autorizzazione. Piattaforme come GitHub Actions, Google Cloud Build e GitLab CI/CD offrono funzionalità native per la generazione di attestazioni SLSA Livello 2.

Il Livello 2 introduce un significativo incremento della fiducia: le attestazioni firmate permettono a consumatori terzi di verificare l’autenticità della provenance senza dover fidarsi implicitamente del produttore del software.

Build L3: isolamento del build e hardening della piattaforma

Il Livello 3 rappresenta il massimo livello di sicurezza attualmente definito nella specifica v1.0, introducendo requisiti architetturali che proteggono il processo di build da manipolazioni interne.

Il build deve essere eseguito in un ambiente isolato che impedisca interferenze da altri processi o build concorrenti. L’isolamento deve garantire che il processo di build non possa essere influenzato da fattori esterni non documentati nelle attestazioni di provenance.

La piattaforma di build deve implementare meccanismi di hardening che prevengano la compromissione del sistema di generazione delle attestazioni, anche in presenza di codice sorgente malevolo. Questo requisito, noto come unforgeable provenance, impone che la generazione e firma delle attestazioni avvenga in un dominio di sicurezza separato dal codice in esecuzione.

La specifica SLSA Build Track dettaglia i requisiti tecnici per l’isolamento, includendo la necessità di ambienti effimeri che vengono distrutti dopo ogni build, l’impossibilità per i custom build steps di accedere ai materiali crittografici usati per firmare la provenance, e l’isolamento completo tra build differenti anche all’interno dello stesso progetto.

Il Livello 3 fornisce garanzie contro minacce interne e compromissioni del processo di sviluppo. Anche se un attaccante ottiene accesso al repository sorgente o al sistema CI/CD, la generazione di attestazioni fraudolente risulta significativamente più complessa.

Prospettive future: Build L4 e Source Track

La specifica SLSA v1.0 si concentra deliberatamente sul Build Track con livelli 1-3, rimandando a versioni future requisiti più avanzati. Come indicato nella documentazione What’s New in SLSA v1.0, sono previsti sviluppi che includono un Build Level 4 (con requisiti come il two-party review e i reproducible builds) e un Source Track dedicato alla protezione dell’integrità del codice sorgente.

Questa scelta architetturale riflette un approccio pragmatico: consolidare requisiti stabili e implementabili prima di estendere l’ambito del framework.

Implementazione pratica del Framework SLSA

L’adozione del framework SLSA richiede un approccio metodico che integri modifiche tecnologiche, processuali e organizzative. Le seguenti linee guida delineano un percorso di implementazione strutturato.

Fase 1: assessment e gap analysis

Prima dell’implementazione, è essenziale condurre una valutazione dello stato corrente della supply chain. La specifica SLSA fornisce criteri dettagliati che possono essere utilizzati come checklist per identificare gap rispetto ai requisiti di ciascun livello.

L’assessment dovrebbe mappare le piattaforme di build attualmente utilizzate e le loro capacità native di attestazione, i processi di code review esistenti, le pratiche di gestione delle dipendenze e la visibilità sulla loro provenance, e le capacità di verifica delle attestazioni nei processi di deployment.

Fase 2: infrastruttura di attestazione

L’implementazione delle attestazioni SLSA richiede l’integrazione di componenti specifici nella pipeline CI/CD. I SLSA GitHub Generators offrono implementazioni di riferimento per GitHub Actions che generano automaticamente attestazioni conformi.

Per ambienti enterprise, Sigstore, un progetto OpenSSF, fornisce un’infrastruttura completa per la firma e verifica delle attestazioni, includendo Fulcio (Certificate Authority per identità effimere), Rekor (Transparency log immutabile per attestazioni) e Cosign (strumento per firma e verifica di container e artefatti).

L’integrazione con SLSA Verifier permette la validazione automatizzata delle attestazioni durante i processi di deployment, garantendo che solo artefatti con provenance verificata raggiungano gli ambienti di produzione.

Fase 3: hardening del build environment

Il raggiungimento del Livello 3 richiede investimenti significativi nell’hardening dell’infrastruttura di build. Le raccomandazioni del NIST Secure Software Development Framework (SSDF) forniscono guidance complementare per l’implementazione di ambienti di build sicuri.

Elementi critici includono l’implementazione di build ermetici che isolino completamente il processo, la separazione dei privilegi tra l’ambiente di esecuzione del build e il sistema di attestazione, il monitoring e logging completo delle operazioni di build per finalità forensi, e la rotazione periodica delle chiavi di firma con audit dei meccanismi di accesso.

Fase 4: integrazione organizzativa

L’aspetto organizzativo risulta critico per il successo dell’implementazione. Anche se il two-party review formale è previsto per livelli futuri, stabilire processi robusti di revisione del codice fin dalle prime fasi dell’adozione SLSA prepara l’organizzazione per requisiti più stringenti.

Le best practice includono la definizione di policy chiare per la revisione del codice, il training dei team di sviluppo sui principi SLSA e sulle procedure operative, l’integrazione dei controlli SLSA nei processi di vendor assessment per dipendenze esterne, e il reporting periodico sulla conformità e sui gap identificati.

Ecosistema e interoperabilità: SLSA nel contesto normativo

Il framework SLSA non opera in isolamento ma si integra in un ecosistema più ampio di standard e normative per la software security.

Sinergie con SBOM e VEX

L’Executive Order 14028 dell’amministrazione Biden, firmato il 12 maggio 2021, ha imposto requisiti di Software Bill of Materials (SBOM) per i fornitori del governo federale USA. SLSA e SBOM sono complementari: mentre SBOM documenta i componenti presenti nel software, SLSA attesta la provenance e l’integrità del processo che ha prodotto quei componenti.

Il formato VEX (Vulnerability Exploitability eXchange), promosso dalla CISA, si integra con le attestazioni SLSA per fornire informazioni sulla applicabilità delle vulnerabilità agli artefatti specifici.

Allineamento con NIS2 e Cyber Resilience Act

La Direttiva NIS2 dell’Unione Europea, applicabile dal 17 ottobre 2024, introduce requisiti espliciti per la sicurezza della supply chain software, particolarmente per operatori di servizi essenziali e fornitori di servizi digitali. L’adozione del framework SLSA costituisce un meccanismo concreto per dimostrare conformità ai requisiti di supply chain risk management previsti dalla direttiva.

Il Cyber Resilience Act, entrato in vigore il 10 dicembre 2024 con piena applicazione prevista dall’11 dicembre 2027, impone requisiti di cybersecurity per prodotti con elementi digitali immessi sul mercato europeo. Il regolamento richiede ai produttori di garantire la sicurezza lungo l’intero ciclo di vita del prodotto, includendo requisiti sulla gestione delle vulnerabilità e sulla trasparenza della supply chain che si allineano strettamente con i principi SLSA.

Prospettive future: SLSA e l’evoluzione della Supply Chain Security

Il framework SLSA rappresenta un punto di partenza, non una destinazione finale, nell’evoluzione della software supply chain security. Diverse direttrici di sviluppo stanno emergendo nella community e nelle organizzazioni di standardizzazione.

Attestazioni per Source Code e dipendenze

Come indicato nella sezione Current Activities del sito SLSA, la community sta lavorando attivamente su nuovi track che estenderanno le garanzie oltre il processo di build. Il Source Track in sviluppo definirà requisiti per la protezione dell’integrità dei repository e per la tracciabilità delle modifiche al codice sorgente. Un Dependency Track è inoltre in fase di elaborazione per affrontare i rischi introdotti dalle dipendenze esterne.

Integrazione con AI/ML Supply Chain

L’emergere di modelli di machine learning come componenti critici delle applicazioni moderne pone sfide uniche per la supply chain security. Iniziative come Model Transparency stanno esplorando l’applicazione di principi SLSA alla provenance dei modelli AI, includendo attestazioni sui dataset di training e sui processi di fine-tuning.

Hardware-Backed Attestations

L’integrazione con tecnologie di attestazione hardware, come Trusted Platform Module (TPM) e Confidential Computing, promette di fornire root of trust basata su hardware per le attestazioni SLSA, elevando ulteriormente le garanzie di integrità.

Conclusioni: SLSA come imperativo strategico

L’adozione del framework SLSA trascende la mera conformità tecnica per configurarsi come imperativo strategico nell’economia digitale contemporanea. In un ecosistema dove la fiducia nel software è prerequisito per qualsiasi transazione digitale, la capacità di attestare rigorosamente la provenance e l’integrità degli artefatti software costituisce un differenziatore competitivo e un requisito per l’operatività in settori regolamentati.

L’implementazione progressiva dei livelli SLSA permette alle organizzazioni di calibrare gli investimenti in sicurezza rispetto al profilo di rischio specifico, evitando sia il sottoinvestimento che espone a compromissioni catastrofiche, sia il sovrainvestimento che drena risorse da altre priorità strategiche.

Il framework SLSA rappresenta la codificazione di principi che la community di sicurezza ha elaborato attraverso decenni di incidenti e lezioni apprese. Con l’entrata in vigore di normative come NIS2 e il Cyber Resilience Act, e con la crescente sofisticazione degli attacchi alla supply chain, la sua adozione non è più questione di “se” ma di “quando” per qualsiasi organizzazione che produca o consumi software in contesti critici.

https://www.ictsecuritymagazine.com/articoli/framework-slsa/