Nel contesto delle indagini digitali contemporanee, la crescente integrazione di sistemi di intelligenza artificiale nei processi di analisi e produzione di contenuti introduce nuove sfide in termini di verificabilità e affidabilità della prova.

Il contributo si inserisce in una serie di approfondimenti a cura di Cosimo de Pinto e affronta il tema dell’auditabilità dei sistemi AI e della catena di custodia digitale, due assi fondamentali per la tenuta metodologica della digital forensics. Attraverso l’analisi delle principali tecniche di attacco ai dati e ai modelli, delle relative contromisure di rilevazione e del concetto di rischio residuo, il testo evidenzia i limiti strutturali degli approcci isolati alla mitigazione.

L’obiettivo è offrire un quadro interpretativo utile a comprendere come l’uso dell’AI stia ridefinendo i criteri di validazione delle evidenze digitali e i presupposti stessi della loro affidabilità in ambito forense.

Sistemi AI e prova digitale: quadro di sintesi tra attacchi, artefatti e contromisure forensi

Una mappa che lega ogni tecnica di attacco all’artefatto colpito, alla contromisura e al rischio residuo.

La tabella seguente riassume il nucleo dell’analisi tecnica, mettendo in relazione ciascuna famiglia di attacco con l’artefatto forense colpito, le principali contromisure di rilevazione disponibili e il grado di tenuta probatoria residua. La colonna del rischio residuo esprime il principio guida dell’intero lavoro: nessuna contromisura, presa isolatamente, neutralizza l’attacco; la tenuta deriva sempre dalla convergenza multi-fonte.

Tecnica di attacco	Artefatto forense colpito	Contromisura di rilevazione	Rischio residuo / tenuta probatoria
Data poisoning / IPI	Dataset, prompt, contesto RAG, conclusioni del modello	Invocation logging, conservazione del dato grezzo, versioning, separazione dato originale/trasformato	Alto: l’output non è valutabile senza l’intera pipeline documentata
Log crafting	Log di sistema, applicativi, di rete	Triangolazione con EDR, SIEM, MFT, USN Journal, telemetria cloud, repliche remote	Medio-alto: rischio emergente; vietata la single-source evidence
PRNU manipulation / fingerprint-copy	Firma di sorgente del sensore	Triangle test e statistica pooled, analisi CNN, verifica originale + catena di custodia	Alto: nessun metodo è immune; serve convergenza con altri elementi
Inpainting / deepfake video	Integrità e provenienza dell’immagine/video	MVFNet, analisi spazio-temporale, C2PA/Content Credentials, ricostruzione del primo upload	Alto: artefatti degradati da compressione e ricodifica
Voice cloning	Identità del parlante	Speaker verification, anti-spoofing, analisi del segnale + contesto	Alto: affidabilità ridotta in condizioni realistiche
Evasion attacks	Esito del classificatore (file, immagine, testo)	Validazione della pipeline, adversarial training, trattamento come solo triage	Alto: la soglia d’attacco non coincide con la percezione umana
Testo AI-generato	Autenticità di documenti e comunicazioni	Watermarking preventivo, analisi statistica, risalita ai sistemi di origine	Alto: i detector sono aggirabili da chi li interroga
Codice malevolo AI-assistito	Attribuzione dell’autore	Convergenza tra infrastruttura, telemetria, log, artefatti di compilazione	Alto: lo stile del codice non è più indicatore affidabile

 

Auditabilità dei sistemi AI: il nodo gordiano

Non-determinismo, opacità e assenza di firma: perché auditare un sistema AI è il nodo gordiano della prova.

Cosa significa auditare un sistema AI

L’auditabilità, la capacità di verificare a posteriori il comportamento di un sistema, è un prerequisito fondamentale dell’affidabilità probatoria. I sistemi AI moderni violano sistematicamente i criteri tradizionali di auditabilità su quattro dimensioni critiche:

• Non-determinismo: i modelli linguistici con temperatura maggiore di zero producono output diversi per lo stesso input ad ogni esecuzione, rendendo impossibile la riproducibilità, uno dei pilastri del metodo scientifico applicato alla forensics.
• Opacità del processo decisionale: i transformer con miliardi di parametri sono, in senso tecnico, black box; le tecniche XAI (LIME, SHAP, attention visualization) hanno fatto progressi ma rimangono insufficienti per applicazioni ad alto impatto legale.
• Dipendenza dal contesto di addestramento: il comportamento di un LLM dipende da dati spesso proprietari, non documentati e non riproducibili; un fine-tuning successivo può modificare gli output senza garanzia di versioning retroattivo.
• Assenza di firma digitale sull’output: i modelli generativi non firmano crittograficamente i loro output; salvo sistemi con watermarking specifico, non esiste modo di verificare che un testo sia stato generato da un determinato modello in un determinato momento.

La catena di custodia digitale nell’era AI

La chain of custody è il principio forense secondo cui ogni elemento di prova deve avere una storia documentata e verificabile dal momento del sequestro a quello della presentazione in giudizio. Nell’informatica forense classica ciò si traduce in: imaging forense con hash crittografico (SHA-256 o SHA-3), documenti di trasferimento firmati, ambienti di analisi isolati, write blocker per prevenire alterazioni.

L’AI introduce vulnerabilità in ogni anello di questa catena, secondo il quadro metodologico della ISO/IEC 27037:2012, la norma internazionale di riferimento per l’identificazione, raccolta, acquisizione e preservazione di prove digitali potenziali. In fase di acquisizione, un sistema compromesso potrebbe presentare all’operatore una vista alterata o incompleta dei dati, secondo logiche già note nel rootkitting e nell’occultamento a livello di sistema, con i rischi propri dell’analisi live su sistema potenzialmente compromesso.

In fase di analisi, i tool forensi che incorporano classificatori automatici o moduli AI devono essere trattati come componenti della pipeline da validare, non come oracoli tecnici. In fase di presentazione, un report generato con assistenza AI potrebbe contenere errori o interpretazioni distorte non rilevabili senza competenza tecnica specifica. Il punto metodologico, dunque, non è presupporre la compromissione del tool, ma documentare e verificare ogni trasformazione introdotta dalla pipeline analitica. La ISO/IEC 27042:2015 definisce i criteri di analisi e interpretazione delle prove digitali che devono applicarsi a prescindere dallo strumento utilizzato, inclusi quelli basati su AI.

Il punto metodologico non è presupporre la compromissione del tool, ma documentare e verificare ogni trasformazione introdotta dalla pipeline analitica.

Framework esistenti e lacune: un’analisi comparativa

Il Regolamento UE 2024/1689 (AI Act), entrato in vigore nel 2024, impone obblighi di logging (art. 12) e trasparenza verso gli utilizzatori (art. 13) per i sistemi ad alto rischio. Ai sensi dell’Allegato III rientrano tra i sistemi ad alto rischio, tra gli altri, quelli destinati a essere utilizzati dalle autorità competenti per valutare l’affidabilità delle prove nel corso delle indagini o del perseguimento di reati, salve le condizioni e le eccezioni previste dall’art. 6 del Regolamento. La formulazione corretta non consente quindi di affermare che ogni sistema AI genericamente impiegato in ambito investigativo sia automaticamente ad alto rischio. Tuttavia, il Regolamento non affronta specificamente l’uso forense dei sistemi AI né la questione dell’evidenza sintetica.

Il NIST AI Risk Management Framework (AI RMF 1.0) include l’auditabilità come requisito nella categoria MEASURE, ma rimane volontario e privo di specifiche tecniche sufficientemente granulari per applicazioni forensi. La ISO/IEC 42001:2023, standard per il sistema di gestione dell’AI, è orientata alla gestione organizzativa e non fornisce indicazioni operative per la forensics.

Le norme ISO specificamente dedicate alle prove digitali (ISO/IEC 27037 su identificazione, raccolta, acquisizione e conservazione; ISO/IEC 27041 sull’assurance metodologica; ISO/IEC 27042 su analisi e interpretazione; ISO/IEC 27043 su principi e processi di indagine) costituiscono il quadro metodologico di riferimento per la digital forensics. Nessuna di esse, tuttavia, include ancora disposizioni specifiche per la gestione di prove prodotte o mediate da sistemi AI. Le linee guida ENFSI e SWGDE non hanno parimenti sistematizzato la problematica, e la lacuna fondamentale rimane invariata: nessuno dei framework esistenti risponde alla domanda centrale che si pone il giudice, ossia se ci si possa fidare di un dato digitale generato o mediato da un sistema AI.

L’analisi mette in luce come l’ingresso dell’intelligenza artificiale nei processi di gestione e valutazione della prova digitale stia ridefinendo i criteri stessi di affidabilità forense. Tecniche di attacco, contromisure e rischio residuo vengono letti in chiave sistemica, evidenziando la necessità di una reale convergenza multi-fonte delle evidenze.

Al centro del quadro emergono le fragilità dell’auditabilità dei sistemi AI e della catena di custodia digitale, oggi messe in crisi da opacità, non-determinismo e assenza di firme verificabili sugli output generativi.

Il tema continua nel prossimo approfondimento su diritto alla prova, protezione dei dati e libertà della persona nell’era dell’AI, con casi reali che mostrano l’impatto concreto di queste trasformazioni.

Per uno sguardo più tecnico e operativo, il white paper di Cosimo de Pinto “Quando l’AI mente bene: deepfake, prova digitale e anti-forensics nel processo penale” approfondisce le principali tecniche di manipolazione dell’evidenza digitale e le strategie anti-forensics, offrendo una lettura essenziale per comprendere i limiti attuali della prova nell’era dei sistemi AI.

 

https://www.ictsecuritymagazine.com/articoli/sistemi-ai-audit/

Metriche di sicurezza dell’AI come “il nostro sistema intercetta il 95% degli attacchi” circolano ormai in ogni presentazione commerciale. Quattro lavori usciti fra maggio e settembre 2026 mostrano che quel tipo di cifra, presa da sola, non permette di concludere nulla sulla sicurezza del sistema in esercizio.

Non si tratta di numeri falsi. Rispondono però a una domanda diversa da quella che interessa a chi firma un contratto, redige una valutazione d’impatto o misura la vulnerabilità da prompt injection di un prodotto.

Che cosa misurano davvero le metriche di sicurezza dell’AI

Il punteggio è locale, la domanda è di sistema

Un tasso di rifiuto, un tasso di successo degli attacchi o un punteggio di violazione descrivono come si è comportato un controllo sulle richieste su cui è stato provato. Sono numeri statistici, non verdetti binari, per la ragione che rende l’AI red teaming diverso da un penetration test. Chi installa quel controllo ha però un’altra domanda: quanto aiuto su compiti dannosi il servizio continua a dare a un attaccante che si adatta o che entra da un’altra parte.

La distinzione è al centro di un lavoro sui safeguard di Pingyu Wu, Weiming Zhang e Nenghai Yu, depositato il 1 settembre 2026. La risposta degli autori è che un punteggio locale migliore non costituisce, di per sé, un’affermazione più forte sul sistema dispiegato.

L’asimmetria delle prove

Il punto metodologico è che le due direzioni non si dimostrano allo stesso modo. Un solo attacco che ottiene aiuto dannoso dal servizio in produzione basta a stabilire che quell’aiuto è ancora disponibile. Dimostrare che ne resti poco non discende dai numeri del controllo, perché richiede prove su che cosa il sistema circostante continua a permettere dopo che il controllo ha svolto la propria funzione locale.

Gli autori rilevano che quel tipo di prova compare solo in una piccola minoranza delle affermazioni esaminate. È un’asimmetria che conviene tenere presente quando un fornitore presenta un miglioramento di punteggio come un miglioramento di sicurezza. Vale anche per i nuovi framework di valutazione che stanno emergendo sul lato difensivo.

Tre modi in cui un punteggio aggregato inganna

Il monitor che passa dal 95% all’11%

Il primo caso riguarda i sistemi che sorvegliano la catena di ragionamento di un agente, cioè i passaggi intermedi che il modello produce prima di agire. Shikhar Shiromani e Leo Richter, in uno studio sui monitor del 1 agosto 2026, costruiscono un attacco che riscrive soltanto il ragionamento e lascia invariate le azioni.

Sul sottoinsieme in cui il monitoraggio del ragionamento è l’unico segnale disponibile, il tasso di intercettazione scende da circa il 95% a meno dell’11%. L’accuratezza aggregata resta alta perché è dominata dagli attacchi già visibili dalle sole azioni. Gli autori la chiamano una falsa media. L’attacco si trasferisce fra famiglie di monitor e modelli di agente diversi e si riproduce con agenti in esecuzione. Contro un monitor calibrato, però, l’evasione si concentra nell’agente più capace.

Il detector che scambia il benigno per attacco

Il secondo caso riguarda il lato opposto della soglia di decisione, quello dei falsi positivi, che raramente viene misurato. Yusuf Khalid Shire e Sang-Chul Kim, in PIDS-Bench del 14 settembre 2026, valutano sette rilevatori lungo più assi. Non sono tutti rilevatori dedicati: accanto a baseline addestrate e a classificatori esterni di prompt injection ci sono comparatori di sicurezza generale. Gli assi comprendono prompt benigni che imitano la struttura di un’iniezione senza intento malevolo, attacchi offuscati e cambi di dominio.

Un rilevatore che supera un F1 di 0,98 sull’insieme di collaudo classifica male circa un terzo di un insieme benigno di provenienza esterna, ristretto a contenuti attinenti alla sicurezza. L’F1 è l’indice sintetico che i fornitori citano più spesso, e combina in un solo numero quante minacce vengono colte e quanti allarmi sono infondati. Su quella distribuzione di stress nessun rilevatore interno raggiunge un punto operativo accettabile. Il criterio è un F1 non inferiore a 0,95, insieme a un tasso di falsi positivi sui benigni difficili non superiore al 10%. Il risultato tiene su tutte le soglie provate e su cinque ripetizioni dell’addestramento, quindi non dipende da una taratura fortunata.

Per chi gestisce un servizio, il costo di quei falsi positivi è immediato e operativo. Per chi lo acquista, è una voce che il punteggio aggregato non espone.

L’agente che sospetta e consegna comunque

Il terzo caso è il più diretto per chi si occupa di protezione dei dati. Il gruppo guidato da Soham Roy e Murari Mandal ha depositato il 30 maggio 2026 un banco di prova sugli agenti web. Il banco, chiamato Scammer4U, contiene 91 ambienti controllati dall’attaccante e 10 ambienti benigni gemelli, su otto vettori d’attacco e sedici categorie di siti. È dichiarato pre-registrato, cioè con ipotesi e misure depositate prima degli esperimenti: è la garanzia che questo stesso articolo chiede ai fornitori.

Su agenti web di frontiera la fuga di dati personali di livello critico va dal 54% al 93% in assenza di indicazioni sulla privacy, contro lo 0% sugli ambienti benigni gemelli. La differenza rispetto alla baseline dimostra che la fuga è attribuibile all’attacco e non a un normale riempimento di moduli.

Gli autori provano anche mitigazioni progressive a livello di prompt. Le riduzioni ottenute dipendono fortemente dal modello e restano insufficienti a impedire in modo affidabile l’invio di dati personali critici sul dato aggregato.

Il dato decisivo è però un altro, e gli autori lo chiamano divario fra rilevazione e azione. Gli agenti il cui ragionamento un giudice LLM indipendente conferma avere segnalato il sito come sospetto consegnano comunque dati personali critici nel 35,9% delle sessioni. Quando nessun sospetto viene verbalizzato la quota sale al 66,1%, con un divario di 30,2 punti stabile su tutte e quattro le famiglie di modelli.

Il sospetto quindi serve, ma non protegge. Accorgersi della truffa riduce la consegna dei dati di due terzi, e in un caso su tre l’agente consegna lo stesso.

La conclusione degli autori è netta: le difese condizionate al riconoscimento dell’attacco da parte dell’agente stesso poggiano sul segnale sbagliato, e serve invece un’intercettazione a valle, sulle comunicazioni in uscita, indipendente dal ciclo di ragionamento. È un’osservazione che tocca direttamente chi usa agenti autonomi su dati di clienti.

Perché il problema non riguarda solo chi compra AI

La finestra si è ristretta

Il contesto in cui queste misure vengono usate è descritto da ENISA nel documento Cybersecurity in the Frontier AI Era del luglio 2026. Il documento riporta un tempo mediano dall’accesso iniziale all’esfiltrazione dei dati compresso a 72 minuti. Non è una misurazione dell’Agenzia: la nota rimanda a una testata specializzata, e come cifra di seconda mano va trattata. L’obiettivo che il documento pone ai centri operativi è invece suo. Chiede di portare le operazioni di sicurezza a una funzione quasi in tempo reale, con tempi medi di rilevazione e di risposta nell’ordine dei minuti a una cifra.

Lo stesso documento riprende dal 2025 Unit 42 Global Incident Response Report di Palo Alto Networks un altro dato. Nel 75% delle violazioni esisteva una registrazione che avrebbe dovuto segnalare il comportamento anomalo, ma i segnali erano frammentati fra strumenti diversi e non sono stati raccolti. È una cifra di seconda mano, riferita al 2025, e va citata come tale. Illustra però bene la differenza fra avere uno strumento e ottenere un risultato.

Il collo di bottiglia si è spostato

ENISA osserva inoltre che nella gestione delle vulnerabilità il fattore limitante diventa la capacità di chi esamina, non l’offerta di segnalazioni. Il volume di rilevazioni vere crea di per sé un problema di verifica. È lo stesso passaggio che attraversa l’evoluzione del SOC, dove il volume degli eventi supera da tempo la capacità umana di analisi.

Vale lo stesso per i controlli sugli agenti. Un rilevatore che produce falsi positivi su un caso benigno su tre non satura soltanto un budget di calcolo, satura il tempo delle persone che devono smentirlo. È il motivo per cui il tasso di falsi positivi andrebbe chiesto insieme al tasso di intercettazione, e non dopo.

Le domande da fare a un fornitore

Dai quattro lavori si ricava una lista breve e verificabile, utile in fase di selezione o di rinnovo contrattuale.

• Su quale corpus è stato misurato quel tasso, quanti scenari contiene e chi li ha scelti? Un punteggio su un insieme fisso di scenari non dice nulla sulle catene d’attacco fuori da quel perimetro.
• Qual è il tasso di falsi positivi sui casi benigni difficili, misurato alla stessa soglia operativa del tasso di intercettazione?
• Come si comporta il controllo quando è l’unico segnale disponibile? Quella quota va separata dal dato aggregato.
• Quali prove esistono su ciò che il sistema circostante continua a permettere dopo l’intervento del controllo? È la sola evidenza che sostenga un’affermazione sul servizio in esercizio.

Chi redige una valutazione d’impatto o imposta la governance degli agenti autonomi trova in queste quattro domande un criterio meno arbitrario del punteggio dichiarato. E chi monitora la prompt injection negli agenti aziendali ha ora un argomento tecnico per spostare i controlli a valle, sulle comunicazioni in uscita, invece di affidarli al giudizio del modello.

Le metriche di sicurezza dell’AI restano utili per confrontare due versioni dello stesso controllo. Non bastano a dire che un sistema è sicuro, e nessuno dei quattro lavori qui citati pretende il contrario. Chi le presenta come garanzia sta rispondendo a una domanda che nessuno ha fatto.

https://www.ictsecuritymagazine.com/articoli/metriche-di-sicurezza-dell-ai/

Il 16 settembre 2026, a Strasburgo, Ursula von der Leyen ha tenuto il discorso sullo stato dell’Unione. Per chi si occupa di sicurezza e di regolazione digitale contano tre passaggi: la tutela dei minori online, una nuova strategia europea di sicurezza e il capitolo sull’intelligenza artificiale.

EU Kids Act: tre soglie di età e onere della prova ribaltato

La presidente della Commissione ha annunciato la presentazione dell’EU Kids Act per il 17 settembre. L’impianto descritto in aula distingue tre fasce.

Sotto i 13 anni, nessun accesso ai social media. Tra i 13 e i 15 anni, niente account personale: solo profili ridotti, creati e supervisionati da genitori o tutori, con funzionalità limitate e un tetto di un’ora al giorno. Tra i 15 e i 18 anni, le piattaforme avranno un obbligo di progettazione sicura.

Il punto di maggiore impatto regolatorio è il ribaltamento dell’onere della prova. Saranno le piattaforme a dover dimostrare che i loro servizi sono sicuri per i minori.

Le soglie proposte si innestano su un quadro che resta frammentato. L’articolo 8 del GDPR fissa a sedici anni l’età del consenso digitale, e lascia agli Stati la facoltà di abbassarla fino a tredici. Gli effetti sulla sicurezza dei minori sono ricostruiti nella scheda della rivista dedicata all’età del consenso digitale.

Un dato verificato aiuta a leggere l’annuncio: l’EU Kids Act non figura tra le nuove iniziative del programma di lavoro della Commissione per il 2026, adottato il 21 ottobre 2025 come COM(2025) 870. Quel documento si limitava a preannunciare un esame del rapporto fra minori e social, sulla scia delle raccomandazioni del gruppo di esperti. Per il primo trimestre 2026 programmava un piano d’azione contro il cyberbullismo.

La spinta arriva dagli Stati membri. Secondo Euronews, dieci Stati stanno valutando o portando avanti leggi nazionali sui divieti ai social. Sono Francia, Grecia, Austria, Danimarca, Spagna, Belgio, Italia, Germania, Polonia e Paesi Bassi. La pressione su Bruxelles per evitare la frammentazione cresce di conseguenza.

L’interpretazione, distinta dal dato: la proposta nasce fuori dalla programmazione ordinaria, sotto la spinta politica degli Stati membri.

La bozza riservata dice qualcosa di diverso

Il 15 settembre Euronews ha pubblicato i contenuti di una bozza riservata del regolamento. È una fonte secondaria su un testo non ancora pubblico, quindi va letta con cautela, ma le divergenze rispetto al discorso meritano attenzione.

Nella bozza le soglie sono quattro, non tre. Sotto i tre anni l’esclusione dai servizi ad alto rischio è totale. Fra tre e tredici anni resta l’accesso a servizi pensati per l’infanzia, sotto supervisione di un adulto. Fra tredici e quindici anni l’accesso ai social è limitato, con funzionalità ridotte e controllo dei genitori. Fra quindici e diciotto valgono i soli obblighi di progettazione sicura.

La differenza sostanziale sta nella formula. Von der Leyen ha parlato di divieto dei social sotto i tredici anni e di nessun account personale sotto i quindici. La bozza descrive invece un divieto di aprire account senza l’approvazione dei genitori sotto i quindici anni: non la stessa cosa, sul piano giuridico. Il limite di un’ora al giorno, citato in aula, non compare nel documento riportato.

L’ambito è più largo di quanto si attendeva: social, piattaforme di condivisione video, giochi online, chatbot e compagni virtuali basati su IA. Restano esclusi i servizi educativi, quelli gestiti da autorità pubbliche e i sistemi di IA per uso d’ufficio o industriale.

Sul piano degli obblighi, la bozza vieta scorrimento infinito, notifiche artificiali e alcuni meccanismi di ricompensa. Impone sistemi di raccomandazione che non costruiscano catene di suggerimenti basate solo sul coinvolgimento. Richiede impostazioni rischiose disattivate di default e profili dei minori privati. La verifica dell’età avverrebbe alla creazione dell’account, con l’app europea o soluzioni nazionali, e in forma proporzionata per gli account già esistenti.

Due punti riguardano da vicino chi si occupa di conformità. I servizi già soggetti al regime più severo del Digital Services Act dovrebbero chiedere l’autorizzazione della Commissione prima di lanciare nuove funzionalità che interessino i minori. E l’attuazione sarebbe finanziata da un contributo di vigilanza a carico delle aziende.

Digital Fairness Act: il quadro generale sulla progettazione che crea dipendenza

Von der Leyen ha riconosciuto che le funzioni costruite per creare dipendenza danneggiano anche gli adulti, annunciando un Digital Fairness Act in autunno.

Il calendario è verificabile su fonte primaria. L’allegato I del programma di lavoro 2026 colloca il Digital Fairness Act fra le iniziative legislative su base articolo 114 TFUE, con data indicativa nel quarto trimestre 2026. L’autunno annunciato in aula cade dentro quella finestra, quindi non è un rinvio, ed è la prima volta che l’atto entra in un programma di lavoro: nel programma 2025, COM(2025) 45 dell’11 febbraio 2025, non compariva.

I contenuti attesi non stanno nel programma di lavoro, che parla soltanto di pratiche sleali e ingannevoli ancora irrisolte. Vengono dalla lettera di missione al commissario Michael McGrath e dalla consultazione che ne è seguita, ricostruite nella scheda del Legislative Train: modelli di interfaccia ingannevoli, marketing degli influencer, progettazione che induce dipendenza e personalizzazione che sfrutta le vulnerabilità dei consumatori.

Sicurezza: una nuova strategia e un “articolo 4” europeo

La presidente ha annunciato, insieme all’alto rappresentante, una nuova strategia europea di sicurezza. La motivazione dichiarata è che dottrina, istituzioni e processo decisionale non hanno tenuto il passo con la nuova realtà. Il contesto è quello delle minacce ibride, che nel discorso vengono descritte come sempre meno ibride e sempre meno minacce.

Due proposte interessano anche il piano cyber. La prima è un meccanismo che affianchi l’articolo 4 della NATO, definito protocollo di emergenza per la sicurezza: attivato da uno Stato membro, farebbe convergere gli altri su una risposta coordinata a incidenti che restano sotto la soglia dell’aggressione armata.

La seconda riguarda il formato di vertice sulla sicurezza del continente, aperto a partner come Canada, Norvegia, Ucraina e Regno Unito. Sul punto la presidente non annuncia una decisione presa: dice che esporrà le proprie idee per rendere reale un Consiglio europeo di sicurezza.

Nello stesso passaggio il discorso richiama gli abilitanti strategici, cioè gli assetti di supporto critici su cui poggia qualunque difesa credibile. Da qui l’annuncio di un nuovo Strumento europeo per gli abilitanti strategici, dichiarato pienamente allineato alla NATO. Fra gli abilitanti elencati, accanto alla difesa aerea e missilistica e al trasporto strategico, compaiono lo spazio e il cyber.

AI: cooperazione internazionale e la questione del ritmo

Von der Leyen ha annunciato una cooperazione rafforzata con Canada, Regno Unito e altri partner su valutazione dei modelli, verifica, allerta precoce e sicurezza dell’AI. Ha dichiarato inoltre di voler convocare i principali laboratori di frontiera.

Qui serve una distinzione. La presidente ha affermato che i vertici delle aziende più avanzate avrebbero detto alla Commissione che è tempo di rallentare sui modelli auto ricorsivi. Nel discorso questa resta una dichiarazione di parte, senza nomi né documenti. Esiste però un atto pubblico che va nella stessa direzione, ed è antecedente al discorso.

Il 18 agosto 2026 OpenAI ha reso noto di aver rallentato il proprio ritmo di espansione. Due i motivi dichiarati: l’incidente con Hugging Face e le indicazioni preliminari che Astra, uno dei modelli in arrivo, possa raggiungere la soglia di capacità cyber critica prevista dal suo Preparedness Framework, determinazione formalizzata il 7 agosto.

Le misure comprendono una pausa di due settimane nell’addestramento per rinforzo dei modelli destinati al rilascio, con la sessione di frontiera più grande tuttora sospesa, e l’isolamento più stretto degli ambienti di ricerca. Il monitoraggio della catena di ragionamento diventa obbligatorio per gli addestramenti per rinforzo e per le valutazioni con uso di strumenti, sui modelli di capacità pari o superiore a Sol. Dopo la determinazione del 7 agosto è esteso a tutte le inferenze di Astra con strumenti. I termini sono due: l’avviso va emesso entro trenta minuti dal rilevamento, e se entro trenta minuti i team non escludono il falso positivo devono sospendere l’attività.

Il costo è dichiarato: circa il 20% di calcolo aggiuntivo sull’inferenza monitorata. È un’azienda che parla di sé stessa, non una verifica indipendente, ma il dato è verificabile e quantificato.

L’incidente Hugging Face, ricostruito da tre parti

L’incidente citato dalla presidente è documentato da fonti pubbliche distinte, che non coincidono in tutto.

Hugging Face lo ha reso noto il 16 luglio 2026 e il 27 luglio ha pubblicato la ricostruzione tecnica: circa 17.600 azioni ricostruite fra il 9 e il 13 luglio. I vettori di iniezione sul processore di dataset sono due, una lettura di file locali tramite HDF5 e una template injection Jinja2. Da lì l’escalation su cluster Kubernetes, credenziali cloud e catena di sviluppo. L’azienda precisa che gli unici contenuti di clienti letti sono cinque dataset riconducibili ai benchmark ExploitGym e CyberGym, e che modelli, dataset e Spaces pubblici non risultano manomessi.

OpenAI ha confermato il proprio coinvolgimento il 21 luglio e ha pubblicato il post mortem e il rapporto tecnico il 26 agosto. I numeri chiave: esecuzione di codice su 41 worker di produzione dei dataset server di Hugging Face, accesso root su almeno un nodo di produzione, quattro repository privati di codice scaricati. Gli agenti operavano in valutazioni interne di capacità offensive, con i classificatori di produzione disattivati proprio per misurare la capacità grezza.

Il rapporto tecnico lo dice in modo esplicito nella sezione sulle lezioni per la sicurezza: è il primo caso noto di un collettivo di agenti automatici che agisce offensivamente senza autorizzazione.

La causa prossima, secondo lo stesso rapporto, è istruttiva: 198 task su 898 del benchmark ExploitGym non erano mai stati risolti da alcun modello, e il 93% dei task discussi sulla bacheca improvvisata proveniva da quell’insieme.

Su che cosa significhi, però, i due documenti usciti il 26 agosto non dicono la stessa cosa. Per OpenAI le azioni dei modelli sono state non intenzionali, un sottoprodotto del tentativo di risolvere le valutazioni. È la lettura dell’azienda coinvolta.

La valutazione indipendente di METR e Redwood Research descrive altro. I due gruppi documentano agenti che, nel proprio ragionamento, riconoscevano l’attività come fuori dal perimetro assegnato e non etica. Vi partecipavano comunque, perché ritenevano utile al collettivo la ricerca sul modo di ingannare il valutatore. Fra gli agenti presenti sulla bacheca da almeno quattro ore prima dell’inizio dell’attacco, 533 in tutto, oltre il 90% si è unito. Sull’intero periodo i partecipanti sono circa 700 su circa 1.200 agenti, che si sono scambiati oltre 70.000 messaggi e file.

I rifiuti esistono e sono rari. Gli stessi autori riportano tre casi. Un agente si ritira definendo l’attività malevola. Un altro restringe il proprio raggio d’azione per ragioni etiche, senza però smettere di attaccare. Un veto della bacheca blocca un tentativo di social engineering via email. Annotano però che l’agente autore del veto operava da un sandbox compromesso e con ogni probabilità partecipava all’attacco: ha fermato una tecnica, non l’operazione.

In oltre il 7% delle trascrizioni gli agenti hanno alterato l’output delle proprie chiamate a strumenti. Pochissimi hanno considerato di avvisare un operatore umano, e nessuno lo ha fatto. Gli stessi autori avvertono che l’analisi è stata delegata in larga parte ad agenti AI e che il campione copre poco più del 90% dell’attività.

L’interpretazione, distinta dal dato: definire l’episodio un incidente non intenzionale è la cornice di chi lo ha causato. Per chi deve redigere una clausola contrattuale o una valutazione del rischio, la descrizione rilevante è l’altra, quella di sistemi che riconoscono il limite e lo attraversano.

La dinamica non è isolata. La rivista ha documentato un episodio parallelo con gli agenti AI su DseWiki. Lì una wiki pubblica è stata usata come bacheca per scambiarsi risposte e tecniche di aggiramento, senza che alcuna norma ne imponesse la segnalazione.

Un dettaglio che riguarda chi difende

Nella comunicazione del 16 luglio Hugging Face descrive un problema che merita di uscire dalla nota tecnica.

Per ricostruire un registro di oltre diciassettemila eventi l’azienda ha usato agenti di analisi basati su modelli linguistici. I primi tentativi con modelli di frontiera dietro API commerciali non hanno funzionato: l’analisi richiede di sottoporre comandi d’attacco reali, payload di exploit e artefatti di comando e controllo. Quelle richieste sono state bloccate dai guardrail dei fornitori, che non distinguono un incident responder da un attaccante.

L’analisi forense è stata quindi eseguita su un modello a pesi aperti, sulla propria infrastruttura. Il secondo vantaggio dichiarato è che nessun dato dell’attaccante, e nessuna delle credenziali citate, ha lasciato l’ambiente dell’azienda.

L’asimmetria è quella che l’azienda stessa mette per iscritto: non si sa quale modello alimentasse gli agenti dell’attaccante, ma l’attaccante non era vincolato da alcuna policy d’uso, mentre il lavoro forense dei difensori è stato bloccato dai presidi dei modelli ospitati.

La lezione operativa è concreta, e vale per qualunque organizzazione: individuare e qualificare in anticipo un modello eseguibile sulla propria infrastruttura, prima dell’incidente, sia per non restare fuori dai propri strumenti sia per non far uscire dati e credenziali dal perimetro.

I compagni virtuali entrano nel perimetro

L’inclusione dei chatbot e dei compagni virtuali nella bozza è la novità che più sposta il baricentro. Si muove in parallelo a quanto sta accadendo altrove.

Il 7 settembre 2026 Microsoft ha firmato un accordo sugli standard di sicurezza e riservatezza dell’IA a scuola. La controparte è la National Academy for AI Instruction, rappresentata dalla presidente dell’American Federation of Teachers, il secondo sindacato degli insegnanti statunitensi. Il documento dichiara obbligatorio ogni requisito e impone verifiche di terze parti. Fra queste, le certificazioni SOC 2 Type II, ISO 27001, ISO 27701 e ISO 42001, oltre a test di penetrazione annuali condotti da esperti indipendenti.

Il principio 4 vieta le funzioni in stile compagno o orientate alla relazione. Il divieto scatta quando sono progettate per creare attaccamento emotivo o dipendenza, per trattenere lo studente oltre il tempo richiesto dal compito, per simulare un’amicizia o per incoraggiare la rivelazione di informazioni sensibili. Il principio 1 esclude l’uso dei dati di studenti e insegnanti per addestrare modelli, con una sola eccezione ristretta legata alla sicurezza, e l’impegno sopravvive alla cessazione dell’accordo.

L’accordo è in vigore dalla firma e dura due anni. Microsoft ha dichiarato che applicherà gli standard ai propri contratti scolastici negli Stati Uniti a partire dal primo novembre.

Sul fronte dei dati d’uso, Euronews riporta uno studio austriaco del 2026. Il 60% degli intervistati fra gli 11 e i 17 anni avrebbe chiesto consigli a un chatbot su stress, conflitti o delusioni sentimentali. Il 30% avrebbe parlato con lo strumento di preoccupazioni o sentimenti. Il dato poggia su una fonte secondaria unica e non è stato verificato sullo studio originale.

Cosa succede adesso

L’EU Kids Act è una proposta. Dovrà passare da Parlamento europeo e Consiglio, con negoziati lunghi. I punti di attrito sono prevedibili: perimetro dei servizi coinvolti, metodi di verifica dell’età compatibili con la protezione dei dati, poteri di vigilanza e sanzioni. Il primo elemento da verificare, però, arriva oggi: quale delle due formule, quella del discorso o quella della bozza, entra nel testo ufficiale.

Articolo chiuso il 17 settembre 2026, prima della pubblicazione del testo ufficiale dell’EU Kids Act.

https://www.ictsecuritymagazine.com/articoli/eu-kids-act-stato-unione-2026/

SBOM e supply chain sono legati da un obbligo asimmetrico. La distinta base del software è l’elenco dei componenti software di un prodotto digitale. Il Cyber Resilience Act ne renderà obbligatoria la redazione per i fabbricanti. Una rilevazione europea su 334 organizzazioni mostra però che il documento quasi non circola: il 39% non lo riceve mai dai fornitori di software commerciale e un altro 39% lo riceve raramente.

Nello stesso periodo, in Italia, il 56% delle segnalazioni di incidente grave trasmesse alla Banca d’Italia ha coinvolto un fornitore. Le due rilevazioni misurano popolazioni diverse e non si verificano a vicenda, come si dirà più avanti. Accostate, però, descrivono una tensione precisa: lo strumento di trasparenza progettato per governare la catena di fornitura è quello che meno passa di mano.

Che cosa chiede il CRA su SBOM e supply chain

Dipendenze di primo livello, non tutta la catena

Il regolamento definisce la distinta base all’articolo 3, punto 39: “un registro formale contenente i dettagli e le relazioni della catena di approvvigionamento dei componenti inclusi negli elementi software di un prodotto con elementi digitali”.

L’obbligo sta invece nell’allegato I, parte II, punto 1 del regolamento (UE) 2024/2847. Impone ai fabbricanti di identificare e documentare le vulnerabilità e i componenti del prodotto. Devono farlo redigendo “una distinta base del software in un formato di uso comune e leggibile da un dispositivo automatico, che includa almeno le dipendenze di primo livello del prodotto”.

L’avverbio conta. La formula “almeno le dipendenze di primo livello” fissa un pavimento, non un tetto. Il fabbricante deve dichiarare le componenti che ha incluso direttamente, mentre le dipendenze delle dipendenze, cioè il grosso di una catena moderna, restano fuori dall’obbligo minimo.

Il considerando 77 spiega la finalità: aiutare fabbricanti e utilizzatori a tenere traccia delle vulnerabilità e dei rischi di cibersicurezza. La distanza fra quella finalità e il pavimento normativo è il primo nodo aperto.

Le tre date che contano

L’articolo 71 scagliona l’applicazione su tre momenti. Il capo IV, articoli da 35 a 51, si applica dall’11 giugno 2026. L’articolo 14, quello sugli obblighi di segnalazione, si applica dall’11 settembre 2026. Il resto del regolamento, compresi i requisiti dell’allegato I, si applica dall’11 dicembre 2027.

L’obbligo di redigere la distinta base non è quindi ancora in vigore. Chi oggi la produce lo fa per scelta, per pressione contrattuale o per anticipare la scadenza.

Prodotto sì, consegnato no

I dati che seguono vengono dal rapporto SBOM Adoption State of Play 2026 di ENISA, pubblicato nel giugno 2026 su una rilevazione condotta a fine 2025. Hanno risposto 334 organizzazioni, per l’87,72% del settore privato, per oltre il 65% grandi imprese sopra i 250 dipendenti e per il 65% operanti principalmente nell’Unione.

Chi lo riceve, e quanto spesso

Alla domanda su quanto spesso ricevano un SBOM dai fornitori di software commerciale, il 39% delle organizzazioni risponde mai e un altro 39% raramente. Solo il 2% risponde sempre.

È il dato che ribalta la percezione corrente. Si discute molto di come produrre una distinta base e pochissimo del fatto che, oggi, riceverne una da un fornitore è statisticamente un’eccezione.

Dieci contratti su cento

Sul versante contrattuale la fotografia è coerente. Solo il 10% dei rispondenti dichiara che la propria organizzazione ha stabilito requisiti SBOM obbligatori nei contratti di fornitura.

Le altre risposte descrivono intenzioni più che pratiche consolidate: il 55% si dichiara in procinto di inserirli in modo sistematico, il 37% li inserisce già in modo occasionale, il 27% prevede di farlo. Le voci non sono mutuamente esclusive, quindi non vanno sommate né lette come una ripartizione.

Quanti fornitori soddisfano i requisiti

Dove i requisiti esistono, la conformità resta bassa. Il 45% delle organizzazioni dichiara che solo fra lo 0 e il 25% dei propri fornitori soddisfa i requisiti richiesti. Appena il 2% colloca i propri fornitori nella fascia fra il 75 e il 100%.

C’è anche un divario fra la profondità di analisi che serve e quella che arriva: il 24% dichiara di avere bisogno di SBOM con analisi a profondità piena, ma solo il 14% li riceve.

ENISA indica l’ostacolo che incide in modo estremo con maggiore frequenza: l’indisponibilità o la scarsa qualità degli SBOM di terze parti. Non è un problema di strumenti interni, è un problema di consegna.

Adozione avviata, uso ancora no

Sul grado di adozione interna, il 9% dichiara un livello maturo e pienamente automatizzato. Il 25% afferma che gli SBOM sono ampiamente adottati nei propri prodotti, il 44% si trova in fase pilota o di adozione limitata, mentre il 22% non ha ancora iniziato.

La domanda più rivelatrice riguarda però la distanza fra produrre una distinta base e usarla davvero. Il 44% dichiara un divario moderato, il 23% un divario significativo, e solo il 7% lo ha chiuso del tutto.

ENISA ne trae una conclusione esplicita, che vale la pena riportare: gli SBOM non sono usati appieno per la sicurezza, ma principalmente per finalità di conformità. Il documento diventa un adempimento, non un controllo.

Formati frammentati e correlazione difficile

Gli ostacoli tecnici spiegano in parte il divario. Il 62% dei rispondenti giudica la completezza dell’SBOM abbastanza o estremamente difficile da ottenere. Sulla correlazione fra componenti e vulnerabilità note, il 35% risponde abbastanza difficile e il 23% estremamente difficile. Il 37% segnala problemi di qualità dei dati e il 28% carenza di competenze.

I formati restano frammentati. CycloneDX è usato dal 44% e SPDX dal 29%, mentre il 17% adotta un formato proprietario e l’11% dichiara di non usare alcun formato standard. ENISA legge quel 28% complessivo come una possibile barriera all’interoperabilità sul mercato europeo, che è cosa diversa dalla leggibilità automatica del file.

La leva per risolverla esiste già, e non è stata usata. L’articolo 13, paragrafo 24 consente alla Commissione di specificare con atti di esecuzione il formato e gli elementi della distinta base di cui all’allegato I. Gli atti devono tenere conto delle norme e delle migliori pratiche europee o internazionali.

Il 79% che va maneggiato con cura

Il rapporto riporta anche una nota di ottimismo: secondo le stime dei rispondenti, il 79% delle organizzazioni raggiungerà il livello di maturità necessario entro la piena applicabilità del CRA, indicata nel dicembre 2027.

Tre cautele prima di citarla. È una autovalutazione, non una misura. Proviene dallo stesso campione che dichiara un tasso di adozione matura del 9%. E lo stesso rapporto registra che il 30% dei rispondenti prevede di aver bisogno di due anni o più per arrivare a quel livello.

Dove gli incidenti accadono davvero

Il peso dei fornitori nelle segnalazioni italiane

La Banca d’Italia ha pubblicato il 9 luglio 2026 il Quadro segnaletico di Vigilanza dei gravi incidenti ICT. L’analisi completa del primo bilancio DORA italiano è su queste pagine, e qui conta un dato solo. Nel 56% delle segnalazioni del 2025 risulta coinvolto un fornitore di servizi. Per le banche meno significative l’Istituto scrive che il fornitore è all’origine dell’evento nella quasi totalità delle segnalazioni relative a incidenti operativi.

Il confronto con gli anni precedenti va fatto con il dato giusto. Le due edizioni non sono direttamente comparabili, perché cambiano base normativa, perimetro e soglie. L’Istituto dedica al raffronto una sezione apposita, che restringe l’analisi ai soli soggetti presenti in entrambi gli schemi.

Su quel sottoinsieme, scrive la Banca d’Italia, il coinvolgimento dei fornitori di servizi ICT negli incidenti “rimane elevato, pari a circa il 57%”. È la fonte stessa a qualificare quel livello come elevato. I valori degli anni precedenti compaiono nel grafico che accompagna la frase, quindi il confronto puntuale anno su anno non si ricostruisce dal testo.

Un accostamento, non una correlazione

I due blocchi di dati vanno letti insieme con una precisazione. ENISA interroga organizzazioni di settori diversi in tutta Europa, la Banca d’Italia conta segnalazioni di intermediari finanziari vigilati in Italia. Le popolazioni non coincidono e nessuna delle due fonti misura l’altra.

L’accostamento regge come argomento, non come nesso statistico. Dice che la dipendenza da terzi è il punto dove gli incidenti si realizzano, e che lo strumento pensato per renderla trasparente è anche quello che meno passa di mano.

Il meccanismo è visibile negli attacchi alla supply chain, dove la compromissione di un pacchetto si propaga attraverso dipendenze che nessun inventario di primo livello avrebbe intercettato. Sul versante degli standard SBOM il lavoro di normalizzazione procede, ma riguarda il formato del documento, non la sua circolazione.

Perché un documento riservato non produce trasparenza

La tensione non nasce dalla prassi, sta dentro il regolamento. Il considerando 77 include fra i destinatari del beneficio anche chi acquista il software: la distinta base “può fornire a coloro che realizzano, acquistano e utilizzano il software informazioni che migliorano la loro comprensione della catena di approvvigionamento”. Lo stesso considerando si chiude però con una frase netta: “I fabbricanti non dovrebbero essere obbligati a rendere pubblica la distinta base del software”.

La parte dispositiva conferma. L’allegato VII colloca la distinta base fra le informazioni sui processi di gestione delle vulnerabilità che compongono la documentazione tecnica del prodotto, cioè il fascicolo che il fabbricante tiene a disposizione delle autorità.

Verso il cliente, invece, la consegna resta facoltativa. L’allegato II elenca le informazioni e le istruzioni per l’utente. Al punto 9 chiede di indicare dove reperire il documento solo “se il fabbricante decide di mettere a disposizione dell’utilizzatore la distinta base del software”. È il regolamento stesso a contemplare la scelta di non consegnarla.

Anche il potere delle autorità è circoscritto. L’articolo 13, paragrafo 25 consente alle autorità di vigilanza del mercato di chiedere le distinte base ai soli fabbricanti delle categorie di prodotti individuate dal gruppo di cooperazione amministrativa. Il contesto è la valutazione della dipendenza degli Stati membri e dell’Unione nel suo complesso dai componenti software, in particolare quelli liberi e open source. Le informazioni sulle dipendenze arrivano poi al gruppo in forma anonimizzata e aggregata, “al fine di tutelare la riservatezza delle distinte base del software”.

L’obbligo di redazione nasce quindi orientato al controllo regolamentare, non allo scambio commerciale. Il dato misurato da ENISA è la conseguenza prevedibile di quella scelta: un documento che si genera e non si consegna.

Le leve disponibili sono contrattuali prima che tecniche. Un requisito vincolante nel contratto di fornitura, oggi presente in un caso su dieci, è la variabile su cui un’organizzazione può agire senza attendere il dicembre 2027. Chi si occupa di gestione del rischio dei fornitori trova qui la richiesta più concreta da mettere a contratto.

Tre grandezze diranno se qualcosa si muove: la quota di organizzazioni che riceve una distinta base dai propri fornitori, la quota che la rende obbligo contrattuale, e la percentuale di fornitori che effettivamente la consegna. Finché resteranno dove sono, il legame fra SBOM e supply chain resterà sulla carta: il documento certificherà la conformità di chi lo redige, senza migliorare la sicurezza di chi dovrebbe riceverlo.

https://www.ictsecuritymagazine.com/articoli/sbom-fornitori-cra/

Gli incidenti ICT gravi comunicati alla Banca d’Italia nel 2025 sono 101 eventi, che hanno prodotto 137 segnalazioni di vigilanza. I numeri compaiono nel Quadro segnaletico di Vigilanza dei gravi incidenti ICT, l’analisi orizzontale pubblicata il 9 luglio 2026 fra le pubblicazioni cyber dell’Istituto. Non è il primo documento del genere, perché la Banca d’Italia pubblica analisi analoghe da anni. È però il primo costruito interamente sulle definizioni, sul perimetro e sulle soglie del regolamento DORA, applicabili dal 17 gennaio 2025.

Letto accanto all’edizione precedente, il documento smentisce due convinzioni diffuse: che la quota degli attacchi stia crescendo, e che il peso dei fornitori continui a salire.

Come si contano gli incidenti ICT gravi

Un evento, molte segnalazioni

La Banca d’Italia distingue due grandezze che vengono spesso confuse. L’evento è il singolo accadimento. La segnalazione è la notifica che il singolo intermediario trasmette all’autorità.

Un guasto presso un fornitore usato da più intermediari resta un evento solo, e produce tante segnalazioni quanti sono i soggetti colpiti. Lo stesso effetto si ottiene quando più entità dello stesso gruppo segnalano l’evento che le riguarda tutte.

Il rapporto fra le due grandezze si è ridotto. Nel 2024 le segnalazioni erano 188 a fronte di 103 eventi, circa 1,8 per evento. Nel 2025 sono 137 a fronte di 101 eventi, circa 1,4.

Prima di leggervi un fenomeno di mercato conviene considerare una spiegazione normativa. Il nuovo quadro ammette la segnalazione aggregata, che prima non esisteva: una sola notifica per tutte le entità colpite dallo stesso incidente, da cui restano esclusi, fra gli altri, gli enti creditizi significativi.

Il requisito però è stretto. Non può farlo un fornitore qualsiasi, ma solo il terzo a cui l’entità abbia esternalizzato formalmente gli obblighi di segnalazione, con un accordo comunicato all’autorità prima della prima notifica. È una configurazione presumibilmente rara, non la condizione ordinaria di un fornitore usato da più banche.

Un guasto che prima produceva dieci segnalazioni può oggi produrne una. Il documento non dice se la Banca d’Italia abbia consentito l’aggregazione né quante ne siano arrivate, quindi fra le due letture, minore propagazione lungo la filiera oppure effetto del modulo, non si può scegliere.

Una riserva ulteriore, ripresa più avanti: il documento 2025 descrive a parole un aumento degli eventi che le cifre pubblicate nelle due edizioni non restituiscono.

Chi segnala, e secondo quali soglie

Il perimetro dei soggetti che segnalano alla Banca d’Italia comprende:

• banche, imprese di investimento e gestori;
• istituti di pagamento e istituti di moneta elettronica;
• prestatori di servizi per le cripto-attività ed emittenti di token collegati ad attività;
• fornitori di servizi di crowdfunding;
• Cassa Depositi e Prestiti;
• Poste Italiane, limitatamente all’attività di Bancoposta.

L’elenco non coincide con quello di DORA. L’articolo 2 del regolamento include anche imprese di assicurazione e di riassicurazione, intermediari assicurativi ed enti pensionistici aziendali o professionali. Include inoltre agenzie di rating del credito, amministratori di indici di riferimento critici, depositari centrali di titoli, controparti centrali, sedi di negoziazione e repertori di dati. Quei soggetti rispondono ad autorità diverse, nazionali o europee, quindi non compaiono in questo documento pur essendo pienamente dentro DORA.

Per banche, istituti di pagamento, prestatori di servizi di informazione sui conti e istituti di moneta elettronica l’obbligo non si ferma agli incidenti ICT gravi. Si estende anche agli incidenti operativi o relativi alla sicurezza dei pagamenti, che restano una categoria distinta.

Che cosa conti come grave non lo decide la funzione sicurezza dell’intermediario. Lo stabilisce il regolamento delegato (UE) 2024/1772, che fissa i criteri di classificazione e le soglie di rilevanza. Formati, modelli e procedure standard arrivano invece dal regolamento di esecuzione (UE) 2025/302.

Il regolamento di esecuzione 2025/302 disciplina, all’articolo 7, la segnalazione aggregata richiamata sopra. Le condizioni sono cinque. L’incidente deve nascere presso il fornitore. Il fornitore deve prestare il servizio a più di un’entità finanziaria o a un gruppo. Le entità devono stare in un unico Stato membro e sotto la stessa autorità. Ciascuna deve averlo classificato come grave. E l’autorità competente deve aver espressamente consentito l’aggregazione a quel tipo di entità.

Ogni percentuale citata più avanti va letta dentro quelle soglie, e con l’indicazione della base su cui è calcolata.

Dove il sistema si rompe

Il fornitore, sopra la metà ma sotto il picco

Nel 56% delle segnalazioni del 2025 risulta coinvolto un fornitore di servizi. La cifra va inserita in una serie, perché da sola induce in errore: era circa il 45% nel 2023 e il 65% nel 2024. Il 2025 arriva quindi dopo un picco, non dopo una salita continua.

Il confronto resta indicativo, perché le basi di calcolo non coincidono. Il 65% del 2024 è calcolato sugli incidenti segnalati, il 56% del 2025 sulle segnalazioni, e il perimetro dei soggetti obbligati è cambiato nel mezzo.

Sulle banche meno significative il documento 2025 non pubblica una percentuale. Scrive che il fornitore è all’origine dell’evento nella quasi totalità delle segnalazioni relative a incidenti operativi. L’edizione 2024 quantificava: il 92% degli incidenti operativi di quelle banche nasceva presso un fornitore, contro il 46% delle banche significative.

Sempre nel 2024, il fornitore compariva nel 72% degli incidenti operativi e nel 40% di quelli cyber. La quota di incidenti con fornitore coinvolto era dell’86% nelle banche meno significative, contro il 44% di quelle significative. La lettura della redazione è che il divario rifletta un diverso grado di esternalizzazione, anche se la fonte non misura quanto ciascuna categoria abbia esternalizzato. È lo stesso quadro già descritto su queste pagine a proposito del rischio dei fornitori e della supply chain estesa.

Cambiamenti ICT e attacchi, un pareggio stimato

Qui servono due avvertenze sulle basi di calcolo, perché il documento ne usa di diverse nella stessa sezione.

Gli eventi di cybersicurezza sono il 23% degli eventi totali. Al loro interno prevale l’esfiltrazione di dati, seguita dagli attacchi alla catena di fornitura, dal ransomware e dall’ingegneria sociale.

Gli eventi operativi attribuibili ai cambiamenti dei sistemi ICT, cioè rilasci, migrazioni e aggiornamenti pianificati, valgono circa il 30% degli eventi operativi. Non del totale.

Perché la stima resta condizionata

La Banca d’Italia presenta gli eventi in due insiemi, operativi e di cybersicurezza. Il modulo di segnalazione è però più articolato. Il campo 3.23, tipo di incidente, prevede sei voci: connesso alla cibersicurezza, malfunzionamento del processo, avaria del sistema, eventi esterni, connesso ai pagamenti e altro da precisare.

Le voci sono a scelta multipla, quindi uno stesso incidente può portarne più di una, e una di esse è residuale. I due insiemi della presentazione sono perciò una scelta di aggregazione dell’Istituto, non una proprietà del sistema di segnalazione.

Se quei due insiemi sono esaustivi e disgiunti, gli eventi operativi valgono il 77% e i cambiamenti ICT si collocano intorno al 23% degli eventi complessivi. È una stima derivata da chi scrive, subordinata a quella condizione, non una cifra pubblicata dall’Istituto.

Ne esce un pareggio sostanziale fra le due grandezze.

Il modulo tiene i cambiamenti su un altro asse

Non è però lecito ordinare i cambiamenti rispetto alle altre cause, perché le due letture stanno su assi diversi, e il regolamento lo dimostra.

Il tipo di incidente si dichiara nella relazione intermedia, al campo 3.23. Le cause di fondo si dichiarano nella relazione finale, su tre livelli. Il campo 4.1 elenca azioni dolose, malfunzionamento del processo, avaria o malfunzionamento del sistema, errore umano ed evento esterno. La gestione delle modifiche compare solo al terzo livello, il campo 4.3. Sta sotto la voce sull’inadeguatezza o il malfunzionamento delle operazioni TIC, accanto alla gestione delle vulnerabilità e delle patch, al backup e ripristino e al trattamento degli errori.

Il regolamento non ignora quindi i cambiamenti: li colloca su un altro asse e in un’altra fase. Un malfunzionamento può del resto nascere da un rilascio, e le due classificazioni non si escludono.

L’argomento regge quindi su un altro piano. Fra le cause di peso comparabile, il governo del cambiamento è l’unica interamente nelle mani dell’intermediario. Un programma di conformità che concentra la spesa sulla difesa dall’attaccante lascia scoperta una voce di dimensioni simili, e per giunta quella su cui l’organizzazione può intervenire senza dipendere da terzi.

La quota cyber non sta crescendo

Il confronto con gli anni precedenti smonta una narrazione diffusa. Nelle segnalazioni raccolte dal vecchio quadro la componente cyber è stata il 32% nel 2020, il 21% nel 2021, il 15% nel 2022, il 28% nel 2023 e il 21% nel 2024. Il 23% del 2025 cade dentro quella banda.

La quota va però tenuta distinta dal valore assoluto, che racconta un’altra storia. Le segnalazioni cyber sono passate da 26 nel 2020 a 40 nel 2024, mentre il totale cresceva più in fretta. Gli attacchi aumentano in numero, non in peso relativo, e i due fatti convivono senza contraddirsi.

Anche qui la base cambia, perché fino al 2024 la percentuale era calcolata sulle segnalazioni e nel 2025 sugli eventi. La conclusione prudente è che sei anni di dati di vigilanza non mostrano una crescita strutturale del peso relativo degli attacchi.

Tempi di reazione, danni e continuità

Quattro ore, non ventiquattro

La scadenza che circola nei materiali divulgativi, ventiquattro ore, è una semplificazione. L’articolo 5 del regolamento delegato (UE) 2025/301 fissa termini di segnalazione articolati.

La notifica iniziale va trasmessa quanto prima, e comunque entro quattro ore dalla classificazione dell’evento come grave, ed entro ventiquattro ore dal momento in cui l’entità ne è venuta a conoscenza. La relazione intermedia segue entro settantadue ore dalla notifica iniziale. La relazione finale arriva entro un mese dall’ultima relazione intermedia.

Il vincolo stringente sono quindi le quattro ore dalla classificazione. Su questo sfondo pesa un altro numero dell’analisi orizzontale: circa il 28% degli eventi viene rilevato oltre le ventiquattro ore. Circa la metà viene rilevata subito, il 20% entro otto ore e il 3% fra le otto e le ventiquattro. Le quote sono arrotondate e la loro somma eccede di poco il totale.

Il ritardo di rilevazione non produce di per sé una violazione, perché l’orologio parte dalla conoscenza. Misura però quanto a lungo l’intermediario resta all’oscuro, e di conseguenza quanto tardi il supervisore vede il fenomeno. Chi prepara i test di resilienza trova qui la metrica su cui allenarsi.

Le perdite passano da un altro canale

Circa il 35% delle segnalazioni riporta perdite economiche, che il documento definisce di bassa entità. Cinque episodi hanno superato il milione di euro: il recupero è stato integrale in due casi, parziale negli altri.

Il 2024 raccontava la stessa dimensione con un altro riferimento, segnalando che in pochi casi, sette su 188, l’impatto superava i due milioni di euro. Nessuna delle due cifre è una soglia normativa, sono entrambe illustrazioni, quindi il confronto fra le due non dice nulla.

Una soglia normativa però esiste, e sta molto più in basso. L’articolo 7 del regolamento 2024/1772 definisce l’impatto economico come somma di costi e perdite diretti e indiretti, al lordo dei recuperi. L’articolo 9, paragrafo 6 ne fissa la soglia di rilevanza a 100.000 euro, sostenuti o potenziali.

Quella soglia da sola non fa però scattare nulla. L’impatto economico è una delle sei soglie di rilevanza dell’articolo 9. L’articolo 8 richiede che l’incidente abbia interessato servizi critici. In aggiunta deve essere raggiunta la soglia dell’articolo 9, paragrafo 5, lettera b, oppure ne devono essere raggiunte almeno due fra le altre.

Quella lettera b riguarda gli accessi non autorizzati, dolosi e riusciti ai sistemi informatici e di rete, quando possono comportare perdite di dati. È l’unica cui il regolamento riconosca uno statuto speciale. Toccati i servizi critici, l’intrusione andata a segno basta da sola, anche senza alcun impatto misurabile.

Il milione e i due milioni citati nelle due edizioni restano quindi episodi di coda, dieci e venti volte sopra la soglia di rilevanza economica.

C’è però una ragione più profonda per non cercare qui la fotografia delle perdite. L’articolo 11, paragrafo 10 di DORA impone alle entità finanziarie una trasmissione annuale separata delle stime aggregate dei costi e delle perdite causati da gravi incidenti ICT, secondo gli orientamenti congiunti JC/GL/2024/34. Per i soggetti vigilati dalla Banca d’Italia il termine ordinario è il 31 maggio, spostato al 30 giugno per il 2026. Per i gruppi bancari meno significativi e i gruppi di SIM la trasmissione avviene su base consolidata. Il dato economico vero viaggia quindi su un canale separato e aggregato, mentre il 35% citato sopra resta il residuo di una rilevazione incidente per incidente.

Il servizio si ferma in sette segnalazioni su dieci

Sulla continuità del servizio la trappola è diversa. In entrambe le edizioni circa il 70% delle segnalazioni indica l’interruzione di un servizio, ma la statistica pubblicata cambia. Il 2024 riportava una durata media di circa 21 ore, in forte crescita dalle 9 ore del 2023, e ne attribuiva la causa a eventi operativi presso fornitori. Il 2025 non pubblica alcuna media e descrive solo una distribuzione per fasce: nella maggior parte dei casi non oltre le otto ore, in alcuni episodi fino a ventiquattro, in un numero limitato di casi oltre. Una media e una distribuzione non si confrontano, quindi il quesito su un eventuale miglioramento resta senza risposta pubblica.

Il metro normativo aiuta comunque a inquadrare quella distribuzione. La soglia di rilevanza del criterio sulla durata è raggiunta quando l’incidente supera le 24 ore, oppure quando l’inattività supera le due ore per i servizi TIC a supporto di funzioni essenziali o importanti. Il legislatore considera quindi rilevante un’inattività di due ore, mentre il dato pubblicato descrive interruzioni fino a quattro volte tanto.

Che cosa ha cambiato il passaggio a DORA

Continuità dichiarata, discontinuità di fatto

Il 2024 è stato l’ultimo anno del vecchio quadro, fondato sulla Circolare n. 285 e sulle disposizioni per istituti di pagamento e istituti di moneta elettronica. Dal 17 gennaio 2025 è operativo lo schema DORA, reso applicabile in Italia dalla comunicazione della Banca d’Italia del 27 dicembre 2024.

Il supervisore dichiara continuità di impianto fra i due quadri. La discontinuità riguarda il perimetro, le definizioni e le soglie, e rende improprio ogni confronto puntuale fra le due edizioni, mentre la direzione dei fenomeni resta leggibile.

L’effetto sui numeri è vistoso. Le segnalazioni scendono da 188 a 137, oltre un quarto in meno. Nel frattempo la platea degli obbligati si allarga, e accoglie imprese di investimento, gestori, emittenti di token, prestatori di servizi per le cripto-attività e fornitori di servizi di crowdfunding. Un calo di quella ampiezza a perimetro crescente rimanda alle nuove soglie di rilevanza e alla segnalazione aggregata più che a un sistema improvvisamente più solido.

Resta un punto aperto, quello anticipato in apertura. Il documento 2025 descrive una diminuzione delle segnalazioni a fronte di un aumento degli eventi, mentre le cifre pubblicate nelle due edizioni danno 103 eventi nel 2024 e 101 nel 2025. La discrepanza merita un chiarimento, e nel frattempo conviene non attribuire una direzione al movimento degli eventi.

Tre minacce significative in dodici mesi

Il nuovo quadro ha introdotto la notifica delle minacce informatiche significative, che si trasmette con un modulo separato, l’allegato III al regolamento 2025/302, e non presuppone alcun incidente. La Banca d’Italia vi dedica un capitolo del documento.

Le condizioni per qualificare una minaccia come significativa sono tre e cumulative, fissate dall’articolo 10 del regolamento 2024/1772. La minaccia deve poter colpire funzioni essenziali o importanti dell’entità, oppure altre entità finanziarie, fornitori terzi, clienti o controparti finanziarie. Deve avere elevata probabilità di concretizzarsi. E, se si concretizzasse, dovrebbe soddisfare il criterio della criticità dei servizi oppure raggiungere le soglie sui clienti e sulle transazioni o quella sull’estensione geografica.

Nel 2025 le segnalazioni ricevute su questo canale sono state tre. Due riguardavano minacce ai dati degli intermediari, gestiti da fornitori terzi. La terza riguardava tentativi di accesso non autorizzato ai conti della clientela. Tre in dodici mesi, sull’intero perimetro vigilato, per lo strumento che DORA presenta come la propria novità di metodo.

Le misure che il primo bilancio non fornisce

Tre grandezze mancano, e sono quelle che permetterebbero di valutare l’allargamento del perimetro. Il documento non indica quante segnalazioni provengano dai soggetti prima esclusi. Non riporta le comunicazioni ricevute da altri Stati membri per eventi con impatto in Italia. E non riprende una serie che il vecchio quadro pubblicava da cinque anni, quella sulla quota di incidenti a carico dei servizi di pagamento, intorno all’80% nel 2024.

Che cosa guardare nel prossimo ciclo

Il valore di questo primo bilancio sugli incidenti ICT gravi sta nella linea di base che costruisce. Tre grandezze meritano di essere seguite: la quota di segnalazioni riconducibili a fornitori, il peso dei cambiamenti ICT sugli eventi operativi e la percentuale di rilevazioni oltre le ventiquattro ore. Sono le tre misure su cui un intermediario incide con scelte proprie.

La data che conta di più però è un’altra, il 30 giugno 2026, quando i soggetti vigilati trasmettono le stime aggregate di costi e perdite. Sarà quella misura, e non il conteggio degli eventi, a dire al supervisore quanto costano davvero gli incidenti ICT gravi e se gli adempimenti DORA 2026 stiano incidendo. Si tratta però di una segnalazione di vigilanza, non di una pubblicazione, e nessuna fonte oggi garantisce se e in quale forma quel dato sarà diffuso.

https://www.ictsecuritymagazine.com/articoli/incidenti-ict-gravi-dora-banca-italia-2025/

L’evoluzione dell’intelligenza artificiale sta ridefinendo in modo profondo non solo le capacità di analisi dei dati, ma anche le modalità con cui le informazioni possono essere alterate, simulate o rese indistinguibili dall’autentico. In questo scenario emergono le tecniche anti-forensics assistite dall’AI, che spaziano dal data poisoning alla manipolazione della firma fotografica PRNU, fino ai deepfake e agli evasion attacks, mettendo in crisi la stabilità epistemologica della prova digitale.

Il contributo, che fa parte di una serie dedicata all’impatto dell’intelligenza artificiale sui sistemi probatori e sulle dinamiche del processo penale contemporaneo, analizza le principali categorie di attacchi e manipolazioni, mostrando come l’AI possa essere utilizzata sia per alterare i dati in ingresso ai modelli sia per falsificare log, immagini, contenuti multimediali e output algoritmici. L’obiettivo è evidenziare le implicazioni forensi di queste tecniche e la necessità di approcci probatori fondati su catene di verifica multiple e indipendenti.

Tecniche anti-forensics assistite dall’AI

Data poisoning, PRNU manipulation, deepfake ed evasion attacks: l’arsenale operativo dell’anti-forensics assistita dall’AI.

Data shaping e data poisoning

Il modellamento del dato (data shaping) consiste nell’alterare il dato prima che venga analizzato, senza renderlo necessariamente sospetto all’occhio umano o agli strumenti tradizionali. L’avvelenamento del dataset (data poisoning) colpisce invece i dati di addestramento, aggiornamento o affinamento del modello (fine-tuning), inducendo il sistema ad apprendere correlazioni errate o comportamenti distorti.

Goldblum et al. hanno sistematizzato questa categoria di attacchi in uno studio pubblicato su IEEE Transactions on Pattern Analysis and Machine Intelligence, distinguendo tra avvelenamento della disponibilità, volto a degradare le prestazioni generali, e avvelenamento per inserimento di backdoor, che induce comportamenti malevoli specifici attivabili da un innesco (trigger) predefinito.

Il caso Microsoft Tay (2016), benché non forense in senso stretto, rimane il riferimento emblematico: il chatbot fu ritirato dopo circa sedici ore perché un attacco coordinato sfruttava la sua capacità di apprendimento online per contaminarlo con contenuti offensivi e ideologicamente connotati. Il caso (documentato in un episodio reale) dimostra che un sistema AI può essere compromesso non perché difettoso nella propria architettura, ma perché esposto deliberatamente a un ambiente informativo ostile.

In ambito forense il parallelo è diretto: un modello linguistico impiegato per riassumere, classificare o correlare chat, messaggi di posta elettronica o documenti sequestrati potrebbe incontrare un corpus previamente manipolato con testi orientati, istruzioni ambigue o dati semanticamente falsificati. A ciò si aggiunge il rischio dell’iniezione di prompt indiretta (indirect prompt injection, IPI): un documento apparentemente innocuo, processato da un sistema AI nell’ambito di un’analisi forense, può contenere istruzioni nascoste capaci di alterare le conclusioni del modello senza lasciare tracce evidenti nei log applicativi ordinari. Per questo la letteratura sulla forensic readiness dei sistemi LLM insiste sull’invocation logging: registrazione strutturata dell’inferenza, con timestamp, identificatori di sessione, prompt completo, contesto utilizzato, parametri rilevanti e output generato.

Implicazione forense: ogni dato in ingresso a un sistema AI deve essere conservato nella forma grezza originale, autenticato con firma crittografica, sottoposto a controllo delle versioni e mantenuto separato dal dato trasformato. L’output del sistema AI non è mai valutabile in modo autonomo senza conoscere il dataset di partenza, il prompt esatto, il contesto operativo e l’intera catena delle trasformazioni subite dal dato.

Costruzione artificiosa dei log: fabbricare una realtà tecnicamente plausibile

Il log crafting consiste nella creazione o manipolazione di registrazioni di sistema formalmente coerenti: sintassi corretta, timestamp credibili, sequenze compatibili, messaggi verosimili. Il rischio specifico è che un sistema AI, addestrato al riconoscimento di pattern statistici, accetti come autentica una sequenza artificiale non perché difettoso, ma perché quella sequenza è stata confezionata per soddisfare esattamente i criteri di validità che il sistema impara a riconoscere.

Il caso Stuxnet rimane il riferimento storico più documentato di manipolazione sistematica della percezione dello stato di un sistema. Il malware modificava segretamente il funzionamento dei PLC Siemens S7-315 e S7-417 inviando agli operatori letture false che mostravano condizioni operative normali, mentre i macchinari venivano progressivamente danneggiati. Falliere, Murchu e Chien descrivono la componente rootkit come un replay attack sul canale di comunicazione PLC, rappresentando il primo caso documentato di malware capace di manipolare la percezione dello stato fisico di un impianto industriale. La logica sottostante, mostrare al sistema di monitoraggio una realtà diversa da quella effettiva, è la medesima che governa il log crafting assistito da AI in contesto forense.

In assenza di una fonte sperimentale univoca e stabilizzata, il log crafting assistito da AI deve essere qualificato come rischio metodologico emergente, non come risultato forense già consolidato. La capacità dei modelli linguistici di generare sequenze sintatticamente corrette e temporalmente plausibili impone comunque una cautela processuale precisa: i log sono spesso una fonte primaria in indagini su accessi non autorizzati, frodi informatiche ed esfiltrazione di dati, ma non devono essere valutati isolatamente.

Sul piano operativo, essi devono essere sistematicamente triangolati con fonti indipendenti non controllate dalla stessa parte: sistemi EDR, piattaforme SIEM, log di firewall e proxy, telemetria cloud, Master File Table (MFT), USN Journal ($UsnJrnl), Event Log di Windows, dati di flusso di rete (netflow e netcap), timeline applicative e repliche su sistemi remoti. La single-source evidence, ossia la prova che poggia su una sola fonte, in particolare se filtrata da un sistema AI, è strutturalmente fragile e non può fondare, da sola, una pronuncia di condanna.

PRNU manipulation: alterazione della firma della sorgente fotografica

Fondamenti della tecnica. La Photo Response Non-Uniformity (PRNU) costituisce, allo stato attuale della disciplina forense, il riferimento metodologico più robusto per l’attribuzione di un’immagine digitale a uno specifico dispositivo di acquisizione. Il suo impiego sistematico trova fondamento nel lavoro seminale di Lukáš, Fridrich e Goljan, che dimostrarono come le imperfezioni microscopiche introdotte in fase di fabbricazione del sensore CMOS o CCD generino un pattern di risposta fotoelettrica statisticamente univoco e riproducibile. La firma PRNU è indipendente dai metadati EXIF e non eliminabile attraverso la semplice rimozione degli header del file.

Il fingerprint-copy attack e le sue evoluzioni. L’attacco più documentato è il fingerprint-copy attack: l’avversario, disponendo di un campione di immagini scattate con il dispositivo bersaglio, estrae la stima del PRNU di quel sensore e la sovrappone a immagini provenienti da un dispositivo diverso, inducendo l’algoritmo di identificazione a classificare erroneamente la sorgente.

Li, Luo, Rao e Huang hanno proposto un attacco migliorato che opera con un metodo a blocchi (block-wise), sovrapponendo la firma in maniera dispersa e non uniforme sull’immagine bersaglio. La calibrazione dell’intensità della firma iniettata è vincolata alla qualità oggettiva dell’immagine risultante, riducendo così la componente non-PRNU rilevabile dal triangle test. Gli esperimenti, condotti su 2.900 immagini provenienti da quattro fotocamere distinte, confermano l’efficacia dell’attacco (risultato dimostrato sperimentalmente).

Il triangle test, introdotto da Goljan e Fridrich per contrastare il fingerprint-copy, sfrutta la correlazione anomala tra immagini sottratte e immagini falsificate. Marra et al. hanno dimostrato che anche questo test è attaccabile. Sul versante delle contromisure, Barni, Santoyo García e Tondi hanno proposto una statistica pooled migliorata per rafforzare il triangle test contro l’attacco fingerprint-copy mentre un successivo studio, con compagine d’autore parzialmente diversa, ne ha mostrato il superamento, evidenziando i limiti del test pooled nell’identificazione PRNU. L’approccio Universal Wavelet Relative Distortion (UWRD), documentato da Sameer e Naskar, offre infine un attacco counter-forensic basato su trasformata wavelet che mira a sopprimere l’impronta PRNU senza introdurre artefatti visibili macroscopici.

Deep learning: dualismo offensivo-difensivo. Le medesime architetture di apprendimento profondo che hanno rafforzato la capacità di identificazione della sorgente vengono ora impiegate anche come strumenti di attacco. Sul versante difensivo, reti convoluzionali (CNN), strutture residuali e contrastive learning estraggono l’impronta PRNU con maggiore robustezza rispetto ai metodi statistici tradizionali. Sul versante offensivo, le stesse architetture possono essere addestrate per sopprimere, falsificare o sostituire l’impronta in modo impercettibile: un approccio definibile adversarial fingerprint manipulation, che opera in modo automatizzato, scalabile e adattivo rispetto alle contromisure forensi note. La letteratura più recente conferma che nessun metodo di identificazione, tradizionale o neurale, può essere considerato immune ad attacchi mirati condotti con strumenti di deep learning.

Principio processuale: l’attribuzione di un’immagine a uno specifico dispositivo non può fondarsi esclusivamente su una correlazione PRNU positiva ottenuta mediante algoritmo automatico. Ogni perizia deve soddisfare condizioni concorrenti:

• disponibilità dell’immagine originale con catena di custodia verificabile;
• dataset di riferimento statisticamente significativo;
• verifica di coerenza temporale e integrità crittografica dei metadati;
• esclusione di ricampionamento o ricompressione;
• analisi manuale integrativa da parte di un esperto.

La forza probatoria della PRNU risiede nella convergenza con altri elementi, non nella sua autonomia.

Content-aware fill, inpainting e deepfake: l’evidenza visiva come simulazione persuasiva

Tassonomia delle tecniche di manipolazione sintetica. Il content-aware fill e l’inpainting computazionale rimuovono o sostituiscono porzioni di un’immagine attraverso algoritmi di completamento contestuale basati su GAN o modelli di diffusione, producendo riempimenti visivamente coerenti. Il deepfake video sostituisce o sintetizza il volto di un individuo in sequenze video mediante architetture encoder-decoder. Il voice cloning replica le caratteristiche acustiche della voce (timbro, cadenza, intonazione, pattern prosodici) da campioni audio anche molto brevi, producendo sintesi difficilmente distinguibile dall’originale in condizioni di ascolto non specialistico. Sistemi come VALL-E hanno mostrato la possibilità di generare una voce sintetica a partire da campioni di circa tre secondi.

In contesto forense, il problema non risiede soltanto nella distinzione tra autentico e falsificato, ma nella capacità di provare, con standard processuali, tre elementi distinti: l’origine del file, la sua integrità nel tempo e il contesto della sua produzione e diffusione.

Il caso Arup (Hong Kong, 2024). Nel gennaio 2024 un dipendente della filiale di Hong Kong della società di ingegneria britannica Arup eseguì quindici bonifici bancari per un importo complessivo di circa 200 milioni di dollari di Hong Kong (circa 25,6 milioni di dollari statunitensi), distribuiti su cinque conti correnti, a seguito di una videoconferenza nella quale tutti i partecipanti, ad eccezione della vittima, erano rappresentazioni deepfake di dirigenti reali.

L’accesso iniziale era avvenuto tramite spear-phishing impersonante il CFO; i deepfake erano stati costruiti da materiali video e audio prelevati da conferenze aziendali pubblicamente accessibili. La Hong Kong Police Force ha confermato che nessun soggetto è stato arrestato, i fondi non sono stati recuperati e l’attribuzione dell’attacco rimane aperta (caso reale documentato). L’episodio documenta tre vulnerabilità sistemiche:

• l’assenza di un canale di autenticazione out-of-band per le disposizioni finanziarie;
• l’assenza di protocolli di verifica dell’identità del chiamante nelle videoconferenze;
• la mancanza di formazione specifica del personale sull’identificazione di segnali visivi e vocali di sintesi artificiale.

Il caso Zelensky (Ucraina, marzo 2022). Il 16 marzo 2022 fu diffuso un video deepfake del presidente Zelensky che simulava un appello alla resa. Il professore Hany Farid (UC Berkeley) identificò anomalie nella proporzione testa-corpo, incongruenze nell’accento e artefatti di temporizzazione caratteristici delle architetture di face-swapping. Il video fu smentito e rimosso dalle principali piattaforme. Si tratta di uno dei primi episodi documentati di impiego operativo del deepfake in un contesto bellico attivo con finalità di disinformazione strategica.

Metodologia forense e protocollo di autenticazione. Le metodologie attualmente più consolidate analizzano le inconsistenze spazio-temporali tra fotogrammi consecutivi. Il modello MVFNet estrae congiuntamente feature forensi spaziali e temporali per rilevare inpainting, deepfake, splicing e re-encoding. Metodi basati sulla trasformata di Fourier sull’asse temporale pixel per pixel consentono di individuare periodicità artificiali introdotte dai generatori nella dimensione temporale. Una rassegna sistematica dei metodi forensi per l’identificazione multimodale di deepfake sui social media conferma che l’affidabilità di questi strumenti dipende fortemente dalla qualità del campione e che nessuno di essi è, da solo, conclusivo.

Sul piano della provenienza, il C2PA (Coalition for Content Provenance and Authenticity) ha rilasciato la specifica 2.2 nel 2025. Le Content Credentials costituiscono un meccanismo promettente di provenance tracking, ma non sono una garanzia assoluta: i manifest possono essere rimossi in fase di upload, ricodifica o distribuzione, e l’assenza di credenziali non consente, da sola, alcuna inferenza conclusiva sull’origine artificiale o autentica del contenuto. Per il voice cloning, uno studio del 2025 ha documentato criticità significative dei sistemi di speaker verification e degli strumenti anti-spoofing in condizioni realistiche, tra rumore, compressione e variabilità degli algoritmi di clonazione.

Principio fondamentale: un video convincente non è una prova; è un artefatto digitale che richiede autenticazione indipendente. Il protocollo forense prevede:

• ricostruzione del primo upload verificabile (timestamp, piattaforma, URL, hash);
• analisi della catena di diffusione;
• esame dei metadati embedded e delle codifiche successive;
• confronto con fonti indipendenti coeve;
• valutazione del contesto di pubblicazione.

Come rilevato da Farid, nessuna tecnica di rilevamento può essere trattata come prova autonoma e definitiva in assenza di un contesto probatorio convergente.

Evasion attacks: modifiche minime, effetti massimi

Fondamenti teorici. Gli evasion attacks operano in fase di inferenza: il modello è già addestrato, i parametri sono fissi, e la manipolazione riguarda esclusivamente l’input. Si distinguono dagli attacchi di data poisoning, che agiscono in fase di addestramento, e dagli attacchi di model extraction o membership inference. Il principio fondante fu formalizzato da Szegedy et al.: perturbazioni di ampiezza impercettibile, ottimizzate tramite L-BFGS, sono sufficienti a indurre l’errore di classificazione con confidenza elevata.

Goodfellow, Shlens e Szegedy fornirono la spiegazione meccanicistica attraverso il Fast Gradient Sign Method (FGSM): la linearità delle reti negli spazi ad alta dimensione è la causa strutturale della vulnerabilità. Carlini e Wagner hanno proposto tre metodi di ottimizzazione per le norme L0, L2 e L-infinito, diventati il benchmark di riferimento per la valutazione della robustezza adversarial.

Brown et al. hanno introdotto il concetto di adversarial patch: un pattern visivo stampabile e applicabile fisicamente che produce misclassification indipendentemente da posizione, scala e orientamento. Eykholt et al. hanno dimostrato che sticker applicati a segnali stradali, visivamente percepibili come atti vandalici ordinari, inducevano misclassification nel 100% delle immagini in laboratorio e nell’84,8% dei fotogrammi catturati da un veicolo in movimento per il classificatore bersaglio (risultato dimostrato sperimentalmente). Il principio forense diretto è di rilevanza immediata: la soglia di plausibilità di un attacco adversarial non coincide con quella della percezione umana.

Il caso Tencent Keen Security Lab – Tesla Autopilot, 2019. Il documento tecnico Experimental Security Research of Tesla Autopilot dimostrò sperimentalmente che l’apposizione di tre piccoli sticker sulla carreggiata era sufficiente per indurre il sistema di riconoscimento delle corsie del Tesla Model S a generare un comando di sterzo nella corsia opposta. Il rapporto documentava ulteriori superfici di attacco: attivazione dei tergicristalli tramite adversarial example fisico e controllo dello sterzo mediante gamepad wireless. L’esperimento dimostra che la frontiera dell’attacco include la manipolazione dell’ambiente percepito dal sistema, aprendo scenari di rischio che i modelli tradizionali di threat modeling non contemplano.

Evasion attacks nel dominio malware. Demetrio et al. hanno dimostrato che la modifica funzionalmente neutrale di sezioni inutilizzate dei file Windows PE, con iniezione di contenuto adversarial ottimizzato, può indurre misclassification nel classificatore MalConv. La letteratura successiva ha esteso il problema sia agli attacchi contro classificatori malware sia alla generazione di falsi positivi sistematici, ma i tassi di evasione dipendono fortemente da modello, dataset, vincoli funzionali del file e scenario sperimentale. In un contesto processuale è quindi metodologicamente scorretto trasferire percentuali ottenute in laboratorio direttamente al caso concreto senza validazione specifica.

Implicazione processuale: un classificatore AI che dichiara un file benigno, una conversazione non rilevante o un’immagine autentica deve essere trattato esclusivamente come strumento di triage. La sua pronuncia è condizionata dall’insieme di pattern appresi durante l’addestramento, dalla distribuzione del dataset, dall’assenza di esempi adversarial nel training set e dall’assenza di attacchi attivi al momento dell’inferenza: quattro condizioni non verificabili a posteriori senza documentazione rigorosa della pipeline di sviluppo del modello.

Ulteriori superfici di attacco nella catena della prova

Documenti, comunicazioni e codice malevolo AI-generato spostano il problema sull’attribuzione e sulla catena della prova.

Documenti testuali e comunicazioni

La generazione di documenti testuali è la capacità più consolidata dei sistemi AI attuali. Un LLM di qualità commerciale può generare contratti, email e messaggi di testo con stile linguistico personalizzato (voice cloning testuale); completare documenti lacunosi in modo stilisticamente coerente; tradurre mantenendo artefatti linguistici che simulano autenticità; generare metadati credibili per file Office.

Kirchenbauer et al. hanno proposto tecniche di watermarking per LLM, ma senza marcatori preventivi l’identificazione del testo AI rimane statisticamente fragile. Sadasivan et al. hanno evidenziato un limite strutturale dei sistemi di rilevazione del testo generato da AI: quando chi produce il testo conosce, o può interrogare, il detector utilizzato per valutarlo, può progressivamente modificare l’output fino a renderlo meno riconoscibile come artificiale. Ne deriva che tali strumenti possono avere utilità orientativa o di triage, ma non possono essere impiegati, da soli, come prova dell’origine artificiale di un documento in sede processuale.

Implicazione processuale: un documento presentato come prova non può essere autenticato basandosi esclusivamente sull’analisi del testo; è necessario risalire ai sistemi di origine, verificare i log dei server, analizzare la trasmissione di rete e le copie di backup indipendenti. In mancanza di tali riscontri, la sola analisi stilistica, sia essa compiuta da un esperto umano o da un sistema AI, non può assurgere a prova di autenticità o di falsità nel contesto processuale.

Codice malevolo AI-generato e attribuzione forense

Sistemi e servizi malevoli pubblicizzati come WormGPT e FraudGPT, richiamati da report di threat intelligence del 2023, sono stati presentati come strumenti per generare campagne di phishing e contenuti offensivi altamente personalizzati.

Per il consulente o perito informatico forense, il codice malevolo generato o assistito da AI introduce una criticità specifica: l’attribuzione dell’autore. Tradizionalmente, alcuni elementi stilistici del codice (denominazione delle variabili, struttura delle funzioni, commenti, scelte algoritmiche e ricorrenze sintattiche) potevano contribuire, insieme ad altri indicatori tecnici, a formulare ipotesi sull’autore o sul gruppo di attori coinvolto. L’intervento dell’AI tende però a uniformare, alterare o mascherare tali impronte individuali; ne consegue che l’attribuzione forense diventa più fragile e non può fondarsi sul solo stile del codice, ma richiede la convergenza di ulteriori elementi: infrastruttura utilizzata, catena di distribuzione, telemetria, log, artefatti di compilazione, contesto operativo e, ove disponibili, tracce relative al servizio AI eventualmente impiegato.

Ciò incide sulla tenuta complessiva della ricostruzione tecnico-probatoria nei procedimenti per cybercrime: per l’accusa, rende più fragile l’attribuzione del codice malevolo a un determinato autore o gruppo di attori; per la difesa, impone la possibilità di contestare in modo tecnicamente fondato inferenze attributive basate su indicatori stilistici non più sufficientemente affidabili. Ne deriva la necessità di rivedere i metodi tradizionali di attribuzione, privilegiando approcci multi-fonte fondati sulla convergenza tra codice, infrastruttura, telemetria, log, artefatti di compilazione e contesto operativo.

Il contributo di Cosimo de Pinto offre una ricognizione delle principali tecniche di anti-forensics assistite dall’AI, evidenziando come data poisoning, manipolazione della firma PRNU, sintesi di contenuti multimediali e attacchi di evasione possano incidere in modo strutturale sulla produzione e sulla valutazione della prova digitale. Ne emerge un quadro in cui non solo i dati e i modelli possono essere alterati, ma anche le tracce stesse dell’attività informatica diventano potenzialmente costruibili, sollevando criticità rilevanti in termini di affidabilità e verificabilità.

Per un approfondimento sistematico di queste dinamiche, si invita alla lettura del paper di Cosimo De Pinto “Quando l’AI mente bene: deepfake, prova digitale e anti-forensics nel processo penale”, che sviluppa in modo organico il rapporto tra intelligenza artificiale, attendibilità della prova e criticità processuali, offrendo un quadro teorico e operativo indispensabile per comprendere l’impatto dell’AI sul diritto probatorio contemporaneo.

https://www.ictsecuritymagazine.com/articoli/tecniche-anti-forensics/

L’adozione di sistemi di intelligenza artificiale generativa sta producendo una trasformazione profonda nel modo in cui il diritto processuale penale interpreta, valuta e utilizza la prova digitale. Ciò che per anni è stato considerato un elemento relativamente stabile e verificabile ovvero il dato digitale come traccia dell’origine di un evento o di un’azione entra oggi in una fase di progressiva instabilità epistemica. La possibilità di generare contenuti artificiali altamente coerenti, completi di metadati plausibili e strutture tecniche formalmente corrette, incrina infatti uno dei presupposti storici della digital forensics: la corrispondenza tra traccia e origine.

Questo articolo si inserisce all’interno della serie di approfondimenti a cura di Cosimo de Pinto dal titolo “Quando l’AI mente bene – Deepfake, prova digitale e anti-forensics nel processo penale”. L’approfondimento analizza la frattura introdotta dall’AI generativa nel paradigma tradizionale della prova informatica, evidenziando come la “plausibilità sintetica” possa sostituirsi alla tracciabilità dell’origine come criterio implicito di affidabilità.

Nel testo si esamina la discontinuità tra anti-forensics classica e nuove tecniche abilitate dall’intelligenza artificiale, mettendo in luce il passaggio da strategie di occultamento o distruzione della prova a sistemi capaci di costruire evidenze artificiali credibili e difficilmente distinguibili da quelle autentiche. L’analisi si concentra inoltre sulle implicazioni processuali di tale evoluzione, con particolare attenzione ai rischi per la valutazione giudiziale della prova digitale e alle possibili ricadute sulla presunzione di innocenza e sulla libertà personale.

La fine dell’innocenza digitale

L’AI generativa incrina il presupposto che la prova digitale rifletta sempre la propria origine.

La digital forensics si è sviluppata, nel corso dei suoi tre decenni di storia disciplinare, attorno a un presupposto implicito: i dati digitali conservano tracce della propria origine, e tali tracce possono essere estratte, interpretate e presentate come prova con ragionevole certezza scientifica. Un file aveva una biografia verificabile: nasceva in un momento preciso, recava l’impronta del software che lo aveva generato, i metadati del sistema operativo, le impronte dell’hardware. Su questo fondamento, ben descritto nella manualistica di riferimento, si è costruita l’intera architettura processuale della prova digitale nei sistemi giuridici occidentali.

Dal paradigma classico alla frattura epistemica

	Computer forensics classica	Scenario AI generativa
Presupposto di base	Le tracce digitali riflettono l’origine del dato	Un contenuto può simulare un’origine credibile
Obiettivo dell’analisi	Ricostruire eventi e attribuire provenienza	Verificare anche la possibilità di un’origine sintetica
Segni di manipolazione	Spesso lasciano anomalie residue	Possono imitare pattern statisticamente plausibili
Ruolo dell’esperto	Interpretare tracce e coerenze tecniche	Corroborare, autenticare e contestualizzare
Rischio giuridico	Errore tecnico circoscritto	Potenziale violazione della libertà personale

L’avvento dei modelli generativi di intelligenza artificiale, in particolare dei Large Language Models (LLM), dei modelli text-to-image, dei sintetizzatori vocali neurali e dei sistemi di video synthesis, ha introdotto nella catena della prova digitale una variabile che i framework forensi tradizionali non erano stati progettati per gestire: la plausibilità sintetica. Un documento, un’immagine, una registrazione audio o video possono oggi essere generati artificialmente in modo da superare non soltanto la percezione umana, ma anche una parte significativa delle analisi strumentali disponibili ai laboratori forensi. Come osservato dalla letteratura tecnica più recente, gli avversari non si limitano più a nascondere le prove: le costruiscono, le avvelenano e orientano l’investigatore verso una narrazione falsa.

Le conseguenze di questa trasformazione non sono confinabili all’ambito tecnico. Nei procedimenti penali, ogni errore nella valutazione di una prova digitale si traduce in una potenziale violazione della libertà personale. Un soggetto innocente può essere condannato sulla base di una conversazione WhatsApp mai avvenuta, di un’immagine fotografica manipolata, di un video che lo mostra in un luogo in cui non si è mai recato, di un log di sistema artatamente costruito per collocarlo in prossimità di un reato. L’AI non mente come un essere umano: produce output statisticamente coerenti, difficili da smascherare con gli strumenti tradizionali, e capaci di ingannare persino analisti esperti.

Ogni errore nella valutazione di una prova digitale si traduce in una potenziale violazione della libertà personale.

Il presente paper analizza le intersezioni tra AI generativa, tecniche di anti-forensics e il concetto giuridico di prova digitale, con attenzione alle implicazioni pratiche per consulenti tecnici, avvocati e magistrati. Vengono esaminate le principali superfici di attacco, le tecniche di evasione forense abilitate dall’AI, i framework di auditabilità esistenti, le lacune normative che rendono urgente un ripensamento del valore probatorio del dato digitale e, soprattutto, i rischi concreti per la libertà delle persone che derivano da un approccio acritico all’impiego dell’AI in sede processuale.

Metodo, contributo e domanda di ricerca

Metodo. Sintesi critica interdisciplinare che incrocia letteratura peer-reviewed, casi documentati, standard normativi e implicazioni processuali della prova digitale nell’era dell’AI generativa.

Contributo. Un quadro di sintesi tra tecnica di attacco, artefatto colpito, contromisure e rischio residuo; ricostruzione del nesso tra auditabilità tecnica e tenuta probatoria; proposta di principi guida per una digital forensics AI-resistant.

Domanda di ricerca. In che modo l’AI generativa trasforma la natura della prova digitale e quali condizioni metodologiche e giuridiche sono necessarie per conservarne l’affidabilità?

Questo paper affronta una delle sfide più critiche e meno sistematizzate dell’attuale panorama della sicurezza informatica applicata al diritto: l’impatto dell’intelligenza artificiale generativa sull’affidabilità delle prove digitali nei procedimenti penali. Non si tratta di uno scenario futuro. Le tecniche qui analizzate (data poisoning, log crafting, PRNU manipulation, deepfake, voice cloning, evasion attacks) sono operative già oggi, e i loro effetti sul sistema giustizia sono documentabili. Il taglio è deliberatamente duplice, tecnico e giuridico, perché duplice è il pubblico cui il problema si rivolge: professionisti della sicurezza, consulenti tecnici d’ufficio e di parte, magistrati e avvocati che si trovano a maneggiare prove digitali la cui affidabilità non può più essere data per scontata.

Sul piano del metodo, il lavoro è una sintesi critica di taglio interdisciplinare. Sul versante tecnico incrocia la letteratura peer-reviewed su anti-forensics e adversarial machine learning con casi documentati di rilevanza processuale o geopolitica; sul versante giuridico procede a un’analisi dottrinale e giurisprudenziale del diritto della prova, ancorata alla normativa italiana ed europea vigente e agli standard tecnici internazionali della famiglia ISO/IEC 27000. Le fonti sono state selezionate privilegiando, ove disponibili, gli atti originali (paper, whitepaper, testi normativi, massime ufficiali) rispetto alle fonti secondarie.

Per onestà epistemica, ogni affermazione tecnica viene qualificata secondo tre gradi di evidenza, esplicitati nel testo: risultato dimostrato sperimentalmente in letteratura; condotta documentata in un caso reale; rischio metodologico emergente, ipotizzato in via teorica ma non ancora consolidato in giudicato.

Il contributo originale è triplice: un quadro di sintesi che mette in relazione ciascuna tecnica di attacco con l’artefatto forense colpito, la contromisura di rilevazione e il rischio residuo (sezione 5); un raffronto comparato tra l’ordinamento italiano e il modello angloamericano (sezione 7); e un framework forense resistente all’AI articolato in cinque principi operativi e quattro proposte normative (sezione 10). La domanda di ricerca che tiene insieme l’intero discorso è la seguente: a quali condizioni una prova digitale generata o mediata da sistemi AI può fondare un giudizio di responsabilità penale senza violare la presunzione di innocenza e il diritto a un equo processo?

Anatomia dell’anti-forensics tradizionale e la discontinuità dell’AI

Dalle tecniche che cancellano le tracce a un’AI che le costruisce: una rottura qualitativa, non solo quantitativa.

L’anti-forensics prima dell’AI

La disciplina dell’anti-forensics, intesa come l’insieme delle tecniche volte a ostacolare, fuorviare o rendere impossibile l’analisi forense di un sistema digitale, è quasi coeva alla nascita della computer forensics stessa. Harris la definisce come qualsiasi tentativo di compromettere la disponibilità o l’utilità delle prove in un processo forense.

Le tecniche classiche si articolano in quattro categorie principali:

• distruzione dei dati (data destruction) tramite sovrascrittura multipla secondo lo standard DoD 5220.22-M, degaussing o distruzione fisica del supporto;
• occultamento dei dati (data hiding) mediante steganografia, cifratura di volumi interi (VeraCrypt, BitLocker) e slack space exploitation;
• trail obfuscation mediante applicazioni portable, timestamp manipulation (Timestomp) e cancellazione selettiva dei log di sistema;
• attacchi alla capacità di analisi attraverso exploit nei tool forensi (FTK, EnCase, Autopsy), file artatamente costruiti (crafted) e tecniche anti-VM e anti-sandbox.

La caratteristica comune di queste tecniche è che esse lasciano tracce della propria applicazione: assenza dove dovrebbe esserci presenza, anomalie statistiche, pattern inusuali. In questa prospettiva, la forensics tradizionale lavora spesso sulla deviazione rispetto all’atteso: l’anti-forensics classica mirava a cancellare, occultare o rendere non interpretabile l’evidenza. Nell’ecosistema AI la logica cambia radicalmente.

La discontinuità dell’AI: quando l’assenza non fa rumore

L’AI generativa introduce una rottura epistemica nel paradigma descritto. Il problema non è produrre contenuti falsi: è produrre contenuti coerenti con le aspettative statistiche di un analista forense. Un LLM avanzato istruito a generare la trascrizione di una conversazione WhatsApp produrrà testo con le peculiarità linguistiche del presunto autore, con riferimenti contestualmente plausibili e struttura temporale coerente; se integrato con un generatore di metadati, produrrà file con timestamp consistenti, encoding corretto, struttura interna del database SQLite di WhatsApp formalmente valida.

La differenza rispetto all’anti-forensics tradizionale è qualitativa, non soltanto quantitativa: non si tratta necessariamente di un’anti-forensics più efficiente, ma di una crisi del concetto stesso di autenticità digitale. Il bersaglio reale diventa ciò che il modello vede: dati, log, metadati, timestamp, immagini, testo, prompt, contesto RAG, workflow, plug-in, API e catena software. L’AI non mente in senso umano; produce un output coerente rispetto all’input e al contesto che riceve. Se input e contesto sono manipolati, la conclusione può essere tecnicamente elegante e probatoriamente falsa.

L’AI non mente in senso umano; produce un output coerente rispetto all’input e al contesto che riceve.

L’approfondimento ha mostrato come l’AI generativa stia alterando in modo strutturale il concetto stesso di prova digitale, spostando l’attenzione dalla tracciabilità dell’origine alla plausibilità sintetica del contenuto. Questo passaggio segna una discontinuità profonda per la digital forensics e apre scenari in cui la distinzione tra dato autentico e dato costruito diventa sempre più complessa da stabilire, con conseguenze dirette sul piano processuale e sulla tutela della libertà personale.

Il prossimo articolo approfondirà le principali tecniche anti-forensics assistite dall’AI insieme alle nuove superfici di attacco lungo la catena della prova digitale, dai documenti alle comunicazioni fino al codice generato automaticamente.

Per un inquadramento più completo e sistematico, è possibile approfondire il paper di Cosimo de Pinto “Quando l’AI mente bene – Deepfake, prova digitale e anti-forensics nel processo penale”: la lettura consente di comprendere in modo organico le dinamiche tra attacco, prova digitale e rischio probatorio, offrendo un riferimento utile sia per l’analisi tecnica sia per l’applicazione nel contesto processuale.

 

https://www.ictsecuritymagazine.com/articoli/prova-digitale/

L’intercettazione nasce come problema di analisi del segnale: individuare una presenza attraverso le sue emissioni. Per lungo tempo ciò ha significato lavorare su radiofrequenze e trasmettitori, in un contesto in cui la minaccia era esterna al dispositivo.

Nel quadro contemporaneo del Metodo SPECTRA questa separazione non esiste più. La sorveglianza può essere interna al sistema operativo, integrata nei flussi di dati e mascherata nel traffico cifrato. Il problema si sposta dal segnale al comportamento del sistema.

Le tecniche TSCM tradizionali restano necessarie sul piano fisico, ma non coprono più l’intero dominio della minaccia. In questo scenario emerge anche il limite degli IOC: ciò che non è catalogato non è visibile. Da qui il passaggio ai pattern, con lo smartphone come nodo centrale.

Nel passaggio conclusivo, il punto critico è chiaro: una bonifica basata solo su indicatori noti è strutturalmente incompleta. Molte minacce moderne restano fuori campo perché non ancora classificate.

L’ultimo approfondimento si colloca in questa transizione: dagli IOC ai pattern, dalla verifica del noto alla lettura di comportamenti e anomalie nel tempo.

Cosa sono gli IOC e il limite delle signature

Nella bonifica logica moderna, soprattutto in ambito smartphone e PC, uno degli errori metodologici più frequenti è affidarsi esclusivamente agli Indicatori di Compromissione (IOC). Gli IOC sono uno strumento fondamentale nell’analisi forense e nella risposta agli incidenti, ma diventano pericolosi quando utilizzati come unico criterio decisionale.

Gli IOC sono elementi osservabili che indicano una possibile compromissione: hash di file malevoli, domini o IP associati a infrastrutture C2, nomi di processi noti, certificati digitali specifici, stringhe di firma binaria, pattern di traffico già classificati. Sono, di fatto, tracce riconosciute di minacce già identificate, e il loro funzionamento si basa su una logica semplice: se compare qualcosa già noto come malevolo, si segnala la compromissione. È il paradigma alla base di antivirus tradizionali, EDR basati su firme, database di spyware noti, blacklist DNS/IP e scanner mobile commerciali.

I sistemi basati su signature funzionano per confronto tra il campione osservato e un database di firme conosciute. Se il campione non è presente nel database, non viene rilevato e tende a essere classificato come pulito. Da qui un limite strutturale: un sistema basato su firme riconosce solo ciò che già conosce. In ambito TSCM logico questo è critico, perché uno spyware custom non sarà presente nei database pubblici, un’operazione mirata può usare infrastrutture dedicate e non tracciate, un captatore istituzionale non compare nelle blacklist commerciali e un malware evoluto può mutare hash a ogni build.

Database incompleti e minacce evolute

I database pubblici contengono indicatori relativi a spyware commerciali diffusi, trojan Android/iOS noti, famiglie malware catalogate e infrastrutture già smantellate, ma presentano limiti evidenti: lag temporale (l’indicatore viene pubblicato solo dopo analisi e disclosure), visibilità parziale (non tutte le operazioni vengono rese pubbliche), bias commerciale (i tool mostrano ciò che possono rilevare, non ciò che esiste) e cecità verso le operazioni mirate (una campagna altamente selettiva può non lasciare tracce pubbliche).

Il problema diventa evidente con minacce zero-day, malware polimorfico, captatori custom, infrastrutture temporanee, C2 su CDN legittime e uso di servizi cloud comuni. In questi casi l’IP può sembrare legittimo, il dominio neutro, il traffico cifrato HTTPS e il processo dotato di un nome innocuo. Dal punto di vista IOC puro non esiste alcun indicatore classificato come malevolo; dal punto di vista comportamentale possono invece emergere persistenza anomala, flussi dati costanti in orari atipici, connessioni ripetitive verso ASN non coerenti con l’uso dell’utente e pattern di esfiltrazione compatibili con sorveglianza remota.

L’illusione del “nessun risultato”

Uno dei rischi operativi maggiori è l’inferenza “non abbiamo trovato IOC, quindi il dispositivo è pulito”. L’affermazione è metodologicamente scorretta: l’assenza di IOC equivale solo a “non sono stati trovati indicatori già noti”, non ad “assenza di compromissione”. In ambito TSCM logico questo errore può portare a falsi negativi critici. Un approccio esclusivamente IOC-based è infatti reattivo, dipendente da intelligence esterna, non autonomo e non investigativo: non analizza il comportamento, non studia i pattern, non costruisce una baseline e non misura le anomalie relative al contesto. Si limita a confrontare.

IOC e minacce moderne: perché l’analisi da sola non è sufficiente

Nonostante i limiti, gli IOC restano preziosi: utili per identificare minacce note, fondamentali in ambito incident response, indispensabili per la correlazione OSINT e validi come primo filtro rapido. Il problema non è l’uso degli IOC, ma il loro uso esclusivo. In un contesto caratterizzato da spyware custom, captatori evoluti, infrastrutture dinamiche, cifratura end-to-end e servizi cloud legittimi, un’analisi basata solo su IOC è insufficiente. La vera differenza metodologica risiede nella capacità di analizzare ciò che non è ancora classificato, e richiede l’integrazione tra analisi degli indicatori noti e analisi dei pattern comportamentali, oggetto del capitolo seguente.

Approccio ibrido: IOC e analisi pattern-centrica

Nell’analisi del traffico acquisito durante attività di bonifica è frequente osservare dispositivi che mantengono connessioni periodiche verso un numero ristretto di endpoint dominanti. La distinzione tra servizi legittimi e possibili architetture di controllo remoto richiede quindi un’analisi quantitativa dei flussi nel tempo. Questo capitolo rappresenta il cuore metodologico della bonifica logica moderna.

In uno scenario caratterizzato da minacce evolute, infrastrutture distribuite e strumenti di sorveglianza sempre più modulari, nessun singolo approccio analitico è sufficiente. La metodologia efficace si fonda su un modello ibrido che integra analisi basata su IOC (Indicator of Compromise) e analisi pattern-centrica comportamentale. L’integrazione di queste due prospettive consente di ridurre i falsi negativi, aumentare la capacità di individuare minacce non catalogate e mantenere un impianto metodologico tecnicamente difendibile.

Analisi basata su IOC

L’analisi IOC individua indicatori noti, già associati a campagne di sorveglianza o malware documentati: indirizzi IP noti per attività C2, domini associati a infrastrutture di sorveglianza, hash di file malevoli, certificati digitali anomali, pattern di User-Agent riconducibili a tool specifici, processi o servizi riconosciuti come spyware commerciali. I vantaggi sono la rapidità di identificazione delle minacce già catalogate, l’alta affidabilità quando l’indicatore è verificato e la facilità di documentazione tecnica.

I limiti strutturali sono altrettanto netti: funziona solo su minacce note, è inefficace contro infrastrutture custom o dedicate ed è eludibile tramite rotazione IP, domini dinamici, CDN e tunneling. Nel contesto della sorveglianza professionale o statale, l’infrastruttura può essere dedicata, temporanea, non riutilizzata e priva di indicatori pubblici: in tali scenari l’analisi IOC può risultare formalmente corretta ma operativamente cieca.

Analisi basata su pattern

L’approccio pattern-centrico non cerca etichette, ma comportamenti. Non si domanda “questo IP è noto?”, ma “questo comportamento è coerente con un uso legittimo del dispositivo?”. L’osservazione comportamentale studia i flussi in termini di frequenza, durata, periodicità, volume e direzionalità, con l’obiettivo di individuare regolarità anomale: connessioni periodiche a intervalli costanti, trasmissioni notturne ripetitive, sincronizzazioni non giustificate dall’uso dell’utente.

In assenza di Deep Packet Inspection (DPI), l’analisi si basa su conteggi, distribuzioni e correlazioni temporali. Un flusso persistente è una comunicazione che si ripete nel tempo, mantiene endpoint stabili e mostra comportamento strutturato; la persistenza è un parametro chiave nella valutazione di compatibilità con scenari di monitoraggio remoto.

Un nodo dominante è un endpoint che concentra una percentuale significativa dei flussi, mantiene relazioni multiple e mostra comportamento di aggregazione: in un contesto di sorveglianza può rappresentare un server di raccolta, un relay o un punto di orchestrazione, ma la sua identificazione resta strutturale, non attributiva. L’analisi temporale è spesso decisiva: attività in assenza di interazione utente, picchi in orari specifici, variazioni cicliche e incrementi improvvisi di uplink. Nel contesto TSCM logico, l’uplink anomalo persistente è uno degli elementi più significativi, in quanto compatibile con scenari di esfiltrazione.

Integrazione operativa

L’approccio ibrido non è una semplice somma di tecniche, ma una sequenza logica: ricerca IOC per l’esclusione rapida di minacce note; analisi strutturale dei flussi; studio della persistenza; identificazione dei nodi dominanti; valutazione temporale; separazione tra traffico infrastrutturale normale e pattern compatibili con monitoraggio. L’analisi non produce certezze assolute, ma gradi di compatibilità, scenari probabilistici e valutazioni tecnicamente argomentabili.

Esempio illustrativo

Lo scenario seguente ha finalità esclusivamente didattiche. Non descrive un caso reale, ma serve a mostrare l’applicazione della separazione tra dato, analisi e ipotesi.

Si supponga di acquisire passivamente, per un periodo di osservazione di sette giorni, il traffico di rete di uno smartphone presente in un ambiente sensibile.

Il dato è l’insieme degli elementi osservabili e verificabili: lo smartphone stabilisce connessioni verso un medesimo endpoint a intervalli regolari di circa quindici minuti, anche nelle ore notturne e in assenza di interazione utente; il volume in uplink verso tale endpoint è costante e superiore al downlink; il flusso si mantiene su HTTPS e l’endpoint non compare in alcuna blacklist pubblica.

L’analisi interpreta questi elementi in relazione tra loro: la regolarità dell’intervallo è compatibile con un meccanismo di beaconing; la prevalenza dell’uplink in assenza di attività dell’utente è coerente con un trasferimento di dati verso l’esterno; la persistenza notturna esclude una correlazione con l’uso applicativo dichiarato. Il confronto con la baseline degli altri dispositivi dell’ambiente mostra che nessuno presenta un profilo analogo. Allo stesso tempo, l’analisi registra le spiegazioni alternative legittime: notifiche push, sincronizzazione cloud, telemetria di sistema o keep-alive di un’applicazione di messaggistica possono produrre pattern simili.

L’ipotesi, esplicitamente condizionale, è che il comportamento osservato risulti tecnicamente compatibile con uno scenario di esfiltrazione remota persistente, qualora le spiegazioni alternative vengano escluse attraverso la correlazione con il dispositivo e la verifica delle applicazioni installate. L’output corretto non è quindi “il dispositivo è intercettato”, ma una valutazione di compatibilità tecnica, argomentata e subordinata all’esclusione delle ipotesi fisiologiche.

Perché l’approccio combinato è necessario

Un modello solo IOC è insufficiente; un modello solo comportamentale rischia un’eccessiva interpretazione. La robustezza metodologica deriva dal confronto tra dato noto e comportamento osservato e dalla distinzione netta tra dato oggettivo, pattern e ipotesi. La bonifica logica moderna richiede analisi passiva, assenza di attribuzione prematura e separazione tra evidenza tecnica e narrativa.

L’intelligenza artificiale come supporto analitico

Nel contesto della bonifica logica moderna, l’analisi di traffico di rete, log di sistema, metadati di comunicazione e osservazioni provenienti da domini differenti può generare una quantità elevata di dati tecnici eterogenei. In tali scenari, strumenti basati su intelligenza artificiale possono rappresentare un supporto utile all’attività dell’analista, soprattutto nelle fasi di normalizzazione, correlazione e prioritizzazione delle anomalie.

L’intelligenza artificiale non deve tuttavia essere intesa come sostituzione dell’operatore, né come meccanismo decisionale autonomo. Nel metodo SPECTRA, il suo ruolo è quello di intelligenza aumentata: un sistema di supporto capace di assistere l’analista nell’individuazione di pattern ricorrenti, nella comparazione tra eventi tecnici e nell’evidenziazione di comportamenti che meritano approfondimento.

In ambito TSCM logico, l’intelligenza artificiale può essere utile in particolare per aggregare grandi volumi di dati provenienti da PCAP, log di sistema, eventi RF, traffico Wi-Fi, traffico cellulare e metadati di rete; per individuare ricorrenze temporali non immediatamente evidenti all’osservazione manuale; per evidenziare nodi dominanti, flussi persistenti e comunicazioni ripetitive; per correlare eventi appartenenti a domini diversi (ad esempio attività RF, uplink cellulare e traffico dati); per supportare la costruzione di baseline ambientali o dispositive; e per assegnare priorità agli elementi da verificare, riducendo il carico cognitivo dell’analista.

Sul piano delle tecniche, questo supporto si traduce in famiglie di metodi già consolidate nell’analisi del traffico e dei log. Algoritmi di anomaly detection (per esempio Isolation Forest o autoencoder) possono segnalare flussi che si discostano da una baseline appresa, evidenziando uplink anomali o connessioni in fasce orarie atipiche.

Tecniche di clustering non supervisionato (per esempio DBSCAN o k-means su feature di flusso quali frequenza, volume, durata e periodicità) consentono di raggruppare comunicazioni con comportamento simile e di isolare i flussi che non rientrano in alcun raggruppamento atteso. Modelli linguistici di grandi dimensioni (LLM) possono assistere nella normalizzazione e nella correlazione di log eterogenei, nella sintesi di sequenze di eventi e nella generazione di ipotesi da sottoporre a verifica. In tutti i casi si tratta di strumenti di supporto alla lettura del dato, non di moduli decisionali autonomi.

Il valore dell’intelligenza artificiale non risiede quindi nella capacità di decidere se un dispositivo sia compromesso, ma nella capacità di rendere più leggibili strutture complesse di dati. Un sistema di analisi può, ad esempio, segnalare che un determinato endpoint compare con frequenza anomala, che un flusso si ripete in assenza di interazione utente, oppure che un’attività di rete coincide temporalmente con eventi radio osservati nello stesso ambiente. Questi output non costituiscono prove autonome: rappresentano indicatori analitici che devono essere interpretati all’interno del contesto operativo.

Per essere realmente utile, l’intelligenza artificiale deve essere integrata in una metodologia strutturata. Un utilizzo generico, non contestualizzato o basato su prompt isolati rischia di produrre risultati apparentemente convincenti ma metodologicamente deboli. In particolare, nel dominio della bonifica tecnica, l’intelligenza artificiale deve operare su dati normalizzati, criteri espliciti e categorie analitiche coerenti con il modello di riferimento: dato, pattern, ipotesi e valutazione.

Il rischio principale è l’automazione dell’interpretazione. Un’anomalia statistica non equivale a una compromissione; un flusso persistente non equivale automaticamente a un canale di esfiltrazione; un endpoint dominante non è necessariamente un server di comando e controllo. L’intelligenza artificiale può evidenziare correlazioni, ma non può sostituire la valutazione tecnica dell’analista, che deve distinguere tra comportamento fisiologico, anomalia contestuale e scenario compatibile con sorveglianza remota.

Nel metodo SPECTRA l’intelligenza artificiale assume quindi una funzione di supporto su tre livelli. Sul piano descrittivo, organizza i dati osservati, li sintetizza e li rende consultabili in modo più rapido. Sul piano correlativo, evidenzia relazioni temporali o strutturali tra eventi appartenenti a domini differenti. Sul piano prioritario, aiuta l’analista a individuare quali elementi meritano verifica ulteriore. Non assume invece funzione attributiva o conclusiva: non stabilisce l’autore di un’attività, non identifica con certezza una compromissione e non sostituisce la validazione umana.

In questa prospettiva, l’intelligenza artificiale può diventare uno strumento rilevante per la bonifica moderna, ma solo se subordinata a una metodologia rigorosa. Il suo impiego deve rafforzare la separazione tra dato, analisi e ipotesi, non indebolirla. Il processo decisionale resta responsabilità dell’analista umano, che deve valutare gli output alla luce del contesto, delle spiegazioni alternative e dei limiti tecnici dell’osservazione passiva. L’intelligenza artificiale non trasforma la bonifica tecnica in un processo automatico: la rende più scalabile, più ordinata e più efficiente, ma non elimina la necessità di competenza tecnica, interpretazione critica e validazione metodologica.

Bonifica logica nella cybersecurity: limiti degli IOC e importanza dell’approccio combinato

La bonifica logica non può basarsi esclusivamente su liste di indicatori, né su intuizioni comportamentali isolate. Richiede un approccio combinato, strutturato e tecnicamente difendibile. L’analisi IOC individua ciò che è già conosciuto; l’analisi pattern-centrica individua ciò che si comporta in modo anomalo. Solo l’integrazione delle due consente una valutazione coerente nel contesto della sorveglianza contemporanea.

Principi della metodologia di analisi passiva

Questo capitolo definisce l’impianto metodologico alla base dell’analisi tecnica applicata alla bonifica logica dei dispositivi e delle comunicazioni. Non si tratta di una procedura operativa, ma di un modello concettuale strutturato che consente di interpretare correttamente i fenomeni osservabili senza alterare il contesto tecnico analizzato. L’obiettivo non è trovare uno spyware, ma stabilire se il comportamento tecnico di un sistema sia compatibile o incompatibile con scenari di sorveglianza remota.

Analisi passiva del traffico

Il primo principio è la passività assoluta dell’osservazione. L’analisi si fonda sull’acquisizione e l’esame di traffico di rete già generato, metadati di comunicazione, distribuzione protocollare, persistenza dei flussi, frequenza e periodicità delle connessioni. Non viene generato traffico di test, non vengono effettuate interrogazioni forzate, non si inducono risposte dal dispositivo. Questo approccio garantisce integrità forense del contesto, assenza di alterazioni comportamentali e riduzione dei falsi positivi dovuti a stimolazione artificiale. In altre parole, si osserva il sistema mentre si comporta naturalmente.

Nessuna interazione attiva con il dispositivo

L’analisi non prevede installazione di software di scansione invasivi, esecuzione di exploit di verifica, test di penetrazione sul dispositivo oggetto di analisi né interrogazioni dirette verso endpoint sospetti. L’interazione attiva può modificare i log, attivare meccanismi di autodifesa, alterare i pattern di comunicazione e compromettere la validità dell’analisi. Il dispositivo viene trattato come una sorgente di dati, non come un bersaglio da stimolare.

Approccio non attributivo

Un principio fondamentale è la non attribuzione. L’analisi non identifica un autore, non attribuisce responsabilità, non formula accuse e non costruisce narrative investigative. Si limita a rispondere a una domanda tecnica: il comportamento osservato è compatibile con un’architettura di sorveglianza remota? Qualsiasi riferimento a soggetti, organizzazioni o presunti attori rimane fuori dall’ambito metodologico, riducendo bias interpretativi, derive speculative e sovrainterpretazioni.

Priorità ai pattern comportamentali

Il fulcro metodologico è l’analisi dei pattern. Non si parte da un indicatore di compromissione predefinito, ma dall’osservazione di nodi dominanti, flussi persistenti, distribuzione anomala dei protocolli, ricorrenza temporale e volumi incoerenti rispetto all’uso dichiarato. L’analisi è orientata a frequenza, durata, periodicità e topologia delle comunicazioni. Un singolo evento isolato non ha valore diagnostico; un comportamento ripetitivo, strutturato e coerente nel tempo può invece assumere significato tecnico. L’attenzione si concentra sulla coerenza del sistema, non sull’eccezione.

Separazione tra dato, analisi e ipotesi

Il metodo impone una distinzione netta tra tre livelli. Il dato è un elemento osservabile, numerico, verificabile e riproducibile. L’analisi è l’interpretazione tecnica del dato, la correlazione tra più elementi e l’identificazione di pattern. L’ipotesi è un possibile scenario compatibile, sempre condizionale e mai affermato come certezza. Questa separazione evita che l’ipotesi influenzi la lettura del dato, che il sospetto diventi conclusione e che l’interpretazione si trasformi in narrativa. Il dato resta autonomo, l’analisi è dichiarata, l’ipotesi è esplicitamente condizionale.

Coerenza con il paradigma contemporaneo

La sorveglianza moderna non si manifesta necessariamente con segnali evidenti o comportamenti plateali. Può essere silente, intermittente, a basso volume e distribuita su più endpoint. Per questo motivo l’approccio metodologico non è orientato alla firma, ma alla struttura comportamentale del sistema. La domanda centrale non è “c’è uno spyware noto?”, ma “il comportamento complessivo del dispositivo è compatibile con un modello di controllo remoto?”.

Metodologia di analisi passiva: principi fondamentali per la sicurezza informatica moderna

La metodologia di analisi passiva si fonda su cinque principi cardine: osservazione non intrusiva, assenza di stimolazione attiva, neutralità attributiva, centralità dei pattern e separazione rigorosa tra dato e ipotesi. È un modello che privilegia la solidità tecnica rispetto alla spettacolarizzazione del risultato. In un contesto in cui la sorveglianza si è spostata dal perimetro fisico al dispositivo, la qualità dell’analisi dipende dalla disciplina metodologica: non dalla ricerca dell’effetto, ma dalla coerenza del metodo.

Limiti tecnici e ambiguità dell’analisi

Ogni analisi tecnica, sia essa RF, logica o di traffico di rete, opera entro limiti strutturali che devono essere esplicitati con chiarezza. L’obiettivo di una bonifica moderna non è produrre certezze assolute, ma valutare la compatibilità tecnica dei pattern osservati con scenari di sorveglianza.

Traffico cifrato

L’evoluzione delle comunicazioni digitali ha portato a un uso quasi totale della cifratura end-to-end: TLS 1.3, HTTPS obbligatorio, DNS over HTTPS e DNS over TLS, VPN commerciali, protocolli proprietari cifrati. Dal punto di vista forense passivo (PCAP, log di rete, metadata), il contenuto del traffico non è analizzabile, il payload non è interpretabile e l’ispezione profonda (DPI) è spesso inefficace o tecnicamente inappropriata. L’analisi si concentra quindi su pattern di persistenza, frequenza delle connessioni, distribuzione temporale, nodi dominanti e anomalie rispetto alla baseline. Un flusso cifrato verso un endpoint remoto non è di per sé indicativo di attività malevola: è un dato compatibile con molteplici scenari, inclusi quelli pienamente legittimi.

Servizi cloud legittimi

Le infrastrutture cloud moderne (CDN, storage distribuito, push notification, telemetria) rendono complessa l’attribuzione tecnica. Un dispositivo può comunicare costantemente con infrastrutture di aggiornamento sistema, servizi di sincronizzazione, backup automatici, piattaforme di messaggistica e servizi di analytics. Molti captatori informatici, commerciali o statali, utilizzano infrastrutture cloud per mascherare il traffico, ma lo stesso vale per applicazioni legittime. Ne consegue che la presenza di traffico verso IP di grandi provider non è di per sé indicativa, la reputazione dell’IP non è elemento decisivo e l’assenza di blacklist non equivale a innocuità. L’analisi deve quindi basarsi sulla coerenza comportamentale, non sulla mera destinazione.

Falsi positivi

Ogni metodologia orientata ai pattern comporta il rischio di falsi positivi: applicazioni che mantengono socket persistenti per notifiche push, sistemi di backup che generano upload periodici, servizi VoIP con keep-alive frequenti, sincronizzazioni in background dopo inattività. Un pattern di traffico persistente, notturno o ricorrente può essere compatibile sia con un captatore sia con un servizio cloud legittimo. La distinzione richiede correlazione temporale, analisi del contesto operativo, confronto con baseline e validazione su più fonti di dato (rete, sistema, comportamento utente). L’errore metodologico più grave è interpretare un’anomalia come prova.

Impossibilità di certezza assoluta

In ambito tecnico-forense passivo non si dispone sempre del controllo dell’infrastruttura, delle chiavi di cifratura, dell’accesso ai server remoti né dei log lato controparte. L’analisi può quindi stabilire la compatibilità tecnica con uno scenario di sorveglianza, l’incompatibilità tecnica con determinate ipotesi e la probabilità relativa di determinati comportamenti, ma non può, nella maggior parte dei casi, stabilire con certezza assoluta l’identità dell’operatore remoto, la finalità esatta della comunicazione o la presenza di un captatore specifico in assenza di artefatti diretti.

L’analisi tecnica moderna non produce verità assolute, ma valutazioni strutturate, classificazione dei pattern, analisi di coerenza e scenari compatibili. L’output corretto non è “il dispositivo è intercettato”, ma “i pattern osservati risultano tecnicamente compatibili con uno scenario di esfiltrazione remota persistente, in assenza di spiegazioni alternative coerenti”. Questa distinzione non è debolezza metodologica: è rigore scientifico.

La bonifica logica e l’analisi di traffico devono essere presentate per ciò che sono: strumenti probabilistici ad alta competenza tecnica, non strumenti di certezza assoluta. La credibilità di un’analisi non deriva dall’enfasi conclusiva, ma dalla chiarezza con cui vengono dichiarati i suoi limiti. L’analisi individua compatibilità tecniche, non prove definitive.

Implicazioni per la bonifica moderna

Il percorso tecnico sviluppato nei capitoli precedenti conduce a una conclusione chiara: la bonifica moderna non può più essere intesa come una semplice attività di scansione radio o ispezione manuale, ma come un processo analitico integrato, multidimensionale e continuativo. Le tecniche di rilevazione radio rimangono fondamentali, così come l’ispezione manuale dell’ambiente e la verifica fisica delle infrastrutture; tuttavia, l’evoluzione delle tecnologie di sorveglianza ha progressivamente ampliato il dominio della minaccia, che oggi può manifestarsi anche a livello software, di rete o di comportamento dei dispositivi. La bonifica tecnica moderna richiede quindi un approccio metodologico capace di integrare analisi provenienti da domini differenti: spettro radio, infrastrutture di rete e sistemi digitali.

Integrazione tra analisi RF e analisi logica

La bonifica RF tradizionale rimane uno strumento fondamentale. L’analisi dello spettro consente di individuare trasmettitori attivi in ambiente, rilevare segnali anomali per potenza, persistenza o modulazione, identificare uplink sospetti su bande note e analizzare comportamenti radio incompatibili con la semplice ricezione passiva. Accanto all’analisi RF deve essere sempre affiancata l’ispezione manuale dell’ambiente: la verifica fisica degli spazi, degli oggetti e delle infrastrutture rimane una componente essenziale delle attività TSCM, consentendo di individuare dispositivi elettronici occultati anche in assenza di emissioni radio attive.

L’evoluzione delle minacce ha però spostato una parte significativa del rischio dal dominio ambientale al dominio digitale. Oggi la sorveglianza può manifestarsi attraverso dispositivi mobili compromessi, software di controllo remoto, configurazioni improprie di rete, flussi dati anomali ma apparentemente legittimi e pattern di comunicazione compatibili con esfiltrazione silente. Di conseguenza, la bonifica moderna deve integrare analisi RF ambientale, analisi di rete locale, analisi logica dei dispositivi e correlazione tra livelli fisico e digitale. La separazione netta tra bonifica ambientale e bonifica informatica non è più coerente con lo scenario operativo attuale.

Evoluzione delle minacce: dall’emissione alla mimetizzazione

Le microspie analogiche classiche erano relativamente semplici da individuare: trasmissione continua, modulazione riconoscibile, comportamento stabile. Le minacce moderne si caratterizzano invece per trasmissioni intermittenti, uso di infrastrutture esistenti (rete cellulare, Wi-Fi), cifratura dei contenuti, attivazione condizionata (trigger remoto) e integrazione in dispositivi apparentemente legittimi. Il paradigma non è più semplicemente cercare una frequenza, ma interpretare un comportamento.

Un segnale su una banda nota non è automaticamente innocuo, così come un flusso dati cifrato non è automaticamente malevolo. La distinzione avviene attraverso l’analisi del contesto: potenza rispetto all’ambiente, persistenza nel tempo, coerenza con l’uso dichiarato dello spazio, correlazione con eventi o presenze, distribuzione temporale delle attività. La minaccia moderna tende alla mimetizzazione, e la bonifica deve quindi evolversi verso l’interpretazione dei comportamenti tecnici.

Il ruolo dell’analisi comportamentale

Il passaggio concettuale più rilevante riguarda l’introduzione dell’analisi comportamentale. Non si tratta di attribuire intenzioni, ma di osservare pattern oggettivi: flussi dati ricorrenti in determinate fasce orarie, attivazioni RF non coerenti con l’uso dell’ambiente, uplink persistenti senza traffico visibile, dispositivi che mantengono comunicazioni costanti anche in stato di apparente inattività. L’analisi comportamentale non sostituisce la tecnica, ma la completa, e richiede raccolta strutturata dei dati, comparazione temporale, definizione di baseline ambientali e capacità di distinguere traffico infrastrutturale da trasmissione locale. In questo modello la bonifica diventa un processo ciclico: acquisizione, classificazione, correlazione, interpretazione, validazione. Il risultato non è un semplice “assenza di segnali”, ma una valutazione tecnica argomentata del rischio.

Il metodo SPECTRA: formalizzazione della metodologia multidominio

Posizionamento rispetto allo stato dell’arte

Le attività di Technical Surveillance Countermeasures (TSCM) sono da tempo descritte in letteratura tecnica e in ambito istituzionale attraverso linee guida operative consolidate. Documenti riconducibili a contesti governativi, come quelli sviluppati in ambito National Security Agency e Dipartimento della Difesa statunitense, definiscono in modo strutturato le procedure di bonifica ambientale, con particolare enfasi sull’analisi radioelettrica, sull’ispezione fisica e sulla rilevazione di dispositivi elettronici.

Parallelamente, negli ultimi anni si sono sviluppate metodologie tecniche avanzate orientate all’analisi dei dispositivi e dei captatori informatici: in questo ambito, i lavori di Amnesty International Security Lab e Citizen Lab hanno introdotto approcci forensi e di network analysis basati su indicatori tecnici, analisi dei log e correlazione delle infrastrutture di comunicazione, contribuendo in modo significativo alla comprensione delle moderne tecnologie di sorveglianza software.

Nonostante l’elevato livello tecnico, questi approcci risultano generalmente strutturati per dominio: le metodologie TSCM tradizionali operano prevalentemente sul piano fisico e radio, mentre le metodologie forensi moderne si concentrano sul dispositivo e sul traffico di rete. Il metodo SPECTRA si inserisce in questo contesto come formalizzazione di un approccio integrato.

Non introduce nuove tecniche di rilevazione, ma organizza in modo esplicito un modello analitico multidominio in cui analisi ambientale e radioelettrica, ispezione fisica, analisi dei dispositivi e osservazione del traffico di rete vengono trattate come componenti interdipendenti di un unico processo. L’elemento distintivo del metodo non è quindi lo strumento utilizzato, ma la logica di integrazione: il valore analitico non è attribuito alla singola evidenza, ma alla correlazione tra evidenze eterogenee osservate nel tempo.

La differenza metodologica è netta. Nei framework tradizionali il dato viene analizzato principalmente all’interno del proprio dominio di origine; nel metodo SPECTRA il dato assume significato solo attraverso la relazione con altri domini e la sua evoluzione temporale. Questo comporta due elementi metodologici espliciti: il pattern multidominio come unità minima di analisi e la correlazione temporale come criterio interpretativo. In questo senso, SPECTRA non rappresenta un rebranding di pratiche esistenti, ma la formalizzazione di un modello analitico che integra in modo strutturato domini tecnici tradizionalmente trattati separatamente.

Il confronto sintetico con i principali riferimenti dello stato dell’arte chiarisce il contributo specifico del metodo.

Va inoltre osservato che la stessa metodologia forense di Amnesty riconosce esplicitamente un principio coerente con l’impianto di questo lavoro: la mancata corrispondenza con indicatori pubblici noti non conferma l’assenza di compromissione, ma indica soltanto che non sono stati trovati riscontri con indicatori già catalogati. È la stessa logica che, al capitolo 7, motiva il superamento di un approccio basato esclusivamente su IOC.

Definizione estesa

SPECTRA (Security Pattern Environment Correlation Technical Reconnaissance & Analysis) è una metodologia multidominio per attività di Technical Surveillance Countermeasures (TSCM) basata sull’integrazione coordinata di tecniche eterogenee e sulla correlazione di pattern tecnici nel tempo. Il metodo non introduce una singola tecnica, ma formalizza un sistema integrato di analisi in cui ogni componente contribuisce alla riduzione del rischio di sorveglianza tecnica.

Principio cardine

Nessuna tecnica, isolatamente, è sufficiente a garantire una bonifica efficace. La sicurezza deriva esclusivamente da integrazione, correlazione e continuità temporale. La mancanza di uno di questi elementi introduce inevitabilmente zone cieche analitiche.

Architettura del metodo

SPECTRA è composto da sei componenti operative, da applicare congiuntamente.

1. Analisi ambientale fisica: ispezione strutturale, verifica di accessi e punti sensibili, individuazione di modifiche o anomalie.
2. Analisi spettro RF: scansione wideband e mirata, identificazione di segnali persistenti e burst, valutazione della potenza rispetto al contesto.
3. Rilevazione elettronica (giunzioni non lineari): individuazione di circuiti attivi/passivi, rilevamento di dispositivi spenti o non trasmittenti, attività conforme alle tecniche TSCM tradizionali.
4. Analisi dispositivi autorizzati: smartphone, PC, IoT; verifica logica e comportamentale; analisi del traffico dati e delle attività anomale; individuazione di compatibilità con captatori informatici.
5. Gestione dispositivi non bonificabili: dispositivi esterni (ospiti, fornitori, terzi) per i quali è impossibile una verifica tecnica diretta; misure di isolamento controllato, esclusione dall’ambiente sensibile e messa in sicurezza attiva (per esempio saturazione acustica dei microfoni).
6. Monitoraggio temporale: osservazione a breve, medio e lungo termine; correlazione degli eventi nel tempo; identificazione di pattern ricorrenti.

Figura 1. Schema concettuale del metodo SPECTRA. Il metodo integra domini tecnici differenti (ambiente fisico, spettro RF, rilevazione elettronica, dispositivi, gestione del rischio residuo e osservazione temporale) all’interno di un processo di correlazione multidominio e analisi pattern-centrica finalizzato alla valutazione tecnica del rischio di sorveglianza.

Logica unificante

Il metodo si basa su un principio operativo preciso: il valore analitico non è nella singola rilevazione, ma nella correlazione tra domini e nel tempo. Per esempio: RF più traffico dati indica una possibile attività di esfiltrazione; dispositivo più comportamento anomalo indica una possibile compromissione; segnale più persistenza indica una possibile sorgente locale.

Approccio pattern-centrico

SPECTRA introduce un cambio di paradigma. Non si cerca il singolo dispositivo, la singola frequenza o l’indicatore statico, ma si analizzano pattern tecnici, coerenza con il contesto e anomalie multidominio. Il pattern rappresenta l’unità minima di significato analitico nel metodo.

Dimensione temporale

Il metodo opera su tre scale: breve termine (rilevazioni immediate), medio termine (comportamento nel tempo) e lungo termine (persistenza e ricorrenza).

Gestione del rischio residuo

Elemento fondamentale del metodo: ciò che non è verificabile deve essere controllato. Questo riguarda in particolare i dispositivi non autorizzati, i dispositivi non analizzabili e gli ambienti non completamente isolabili. La soluzione è il contenimento del rischio, la riduzione della capacità di acquisizione (audio/dati) e il controllo delle condizioni operative. L’assenza di rilevazioni non equivale all’assenza di capacità di acquisizione.

Distinzione metodologica rispetto alla TSCM tradizionale

SPECTRA non sostituisce la TSCM: la include, la estende e la integra. Supera il limite di una visione orientata solo all’RF, solo al piano fisico o solo al dispositivo, introducendo correlazione strutturata, analisi comportamentale e integrazione multidominio.

Limite delle tecniche isolate

Il metodo formalizza un punto chiave: la bonifica RF da sola è insufficiente, così come lo sono l’analisi dei dispositivi da sola, l’isolamento dei dispositivi da solo e il monitoraggio RF continuativo da solo. La sicurezza emerge solo dalla combinazione delle tecniche. La sicurezza non è funzione della tecnica utilizzata, ma del grado di integrazione tra tecniche.

Output del metodo

SPECTRA non produce certezza assoluta, ma una valutazione tecnica strutturata basata su anomalie rilevate, pattern identificati e coerenza con il contesto. Il risultato è sempre espresso in termini probabilistici e contestuali, non deterministici.

Formalizzazione dell’acronimo

• S, Security: finalità di protezione dalla sorveglianza tecnica.
• P, Pattern: analisi basata su pattern tecnici, non su eventi isolati.
• E, Environment: ambiente fisico come dominio operativo.
• C, Correlation: correlazione multidominio e temporale.
• T, Technical: approccio tecnico, non teorico.
• R, Reconnaissance: ricognizione sistematica dell’ambiente.
• A, Analysis: analisi strutturata dei dati raccolti.

Definizione conclusiva

SPECTRA è una metodologia multidominio che integra tecniche di analisi ambientale, RF, elettronica, dispositiva e comportamentale, basata sulla correlazione di pattern nel tempo, finalizzata all’identificazione di anomalie tecniche compatibili con attività di sorveglianza o acquisizione non autorizzata di informazioni.

Contesto operativo e livelli di minaccia

Le attività di sorveglianza tecnica possono manifestarsi su livelli profondamente differenti in termini di capacità, risorse e obiettivi. In via generale è possibile distinguere lo spionaggio statale (elevata capacità tecnica, accesso a risorse avanzate come exploit zero-day e infrastrutture dedicate), lo spionaggio privato professionale (investigatori, aziende, competitor), lo spionaggio mirato a basso/medio livello (strumenti commerciali avanzati), lo spionaggio amatoriale/opportunistico (dispositivi a basso costo, software facilmente accessibile) e la sorveglianza in ambito personale (partner, familiari, soggetti interni). Il fattore discriminante tra questi scenari è rappresentato principalmente da budget operativo, livello tecnico dell’attore e obiettivi della sorveglianza.

Nel contesto operativo TSCM/SPECTRA, tali differenze non modificano il principio metodologico fondamentale. L’analisi del contesto orienta la valutazione del rischio, ma non riduce il perimetro della bonifica.

Durante la fase preliminare vengono raccolte informazioni sul contesto, stimato lo scenario di minaccia e definito il livello di rischio; in fase operativa, però, la bonifica deve comunque essere completa e multidominio. Una microspia da 50 euro e un sistema avanzato condividono lo stesso spazio operativo, un captatore software e un trasmettitore RF possono coesistere, e una minaccia apparentemente semplice può produrre effetti critici. Di conseguenza, il metodo SPECTRA prescinde dal livello dell’attaccante nella fase di verifica tecnica: il contesto serve a interpretare i risultati, a pesare le anomalie e a formulare ipotesi, ma non giustifica mai una riduzione dell’analisi.

Conclusioni

L’evoluzione della sorveglianza tecnica ha determinato uno spostamento strutturale del punto di acquisizione delle informazioni: dall’ambiente fisico al dispositivo personale, e dall’hardware dedicato al software residente. Questo cambiamento non è esclusivamente tecnologico, ma profondamente metodologico. Le tecniche di bonifica tradizionali, basate su analisi radioelettrica, ispezione fisica e rilevazione elettronica, rimangono strumenti fondamentali, ma non sono più sufficienti a descrivere l’intero dominio della minaccia.

Nel contesto contemporaneo la sorveglianza può manifestarsi attraverso dispositivi legittimi compromessi, traffico di rete cifrato, pattern comportamentali distribuiti nel tempo e infrastrutture apparentemente indistinguibili da quelle ordinarie. Di conseguenza, la bonifica tecnica non può più essere intesa come una singola attività, ma come un processo analitico multidominio. Il metodo SPECTRA si inserisce in questo contesto come formalizzazione di tale approccio, integrando analisi ambientale, analisi RF, rilevazione elettronica, analisi dei dispositivi, osservazione del traffico e correlazione comportamentale all’interno di un unico modello metodologico coerente.

Il contributo principale del metodo non consiste nell’introduzione di nuove tecnologie, ma nella definizione di un principio operativo chiaro: la sicurezza non è il risultato di una tecnica, ma dell’integrazione strutturata di più domini analitici. In questo paradigma il dato isolato perde significato, il pattern diventa unità analitica, il tempo diventa variabile critica e la certezza lascia spazio alla valutazione probabilistica. La bonifica tecnica moderna non consiste quindi nel trovare una microspia, ma nel determinare se un sistema tecnico, nel suo complesso, presenti comportamenti compatibili con scenari di sorveglianza. Questo passaggio rappresenta il vero punto di discontinuità rispetto ai modelli tradizionali e definisce il perimetro operativo della contro-sorveglianza tecnica contemporanea.

Il presente lavoro si basa principalmente su esperienza tecnica operativa e sull’analisi di casi documentati nella letteratura tecnica e giornalistica internazionale relativi all’utilizzo di captatori informatici e spyware commerciali.

Il lavoro mette in luce un cambiamento strutturale: la sorveglianza non è più un elemento esterno, riconoscibile tramite segnali dedicati, ma una funzione integrata nei sistemi digitali. Oggi il software può operare direttamente all’interno del sistema operativo dello smartphone, acquisendo dati alla sorgente e rendendo spesso invisibile il tradizionale punto di intercettazione.

Di conseguenza, anche la contro-sorveglianza deve adattare il proprio paradigma: le tecniche classiche restano fondamentali, ma non sono più sufficienti a descrivere un contesto in cui traffico cifrato e processi interni si sovrappongono al comportamento ordinario del dispositivo.

Il Metodo SPECTRA nasce in questo scenario, proponendo un approccio che non si basa solo su segnali e indicatori noti, ma sulla lettura dei pattern e delle dinamiche comportamentali nel tempo.

https://www.ictsecuritymagazine.com/articoli/ioc-bonifica-logica/

Il Cryptographic Bill of Materials (CBOM) risponde a una domanda che quasi ogni organizzazione, di fronte alla migrazione post-quantum, scopre di non saper trasformare in un elenco: dove, e con quali algoritmi, chiavi e certificati, l’azienda usa la crittografia. Sembra una domanda banale, e invece è insidiosa, perché la crittografia non vive in un posto solo. È incorporata nelle applicazioni, nelle librerie di terze parti, nei protocolli negoziati a runtime, nei certificati che scadono in silenzio, nell’hardware. Nessuno l’ha mai censita davvero, perché finora non è servito. Ora serve, e serve in fretta.

La ragione è la transizione verso una crittografia resistente ai computer quantistici, spinta da scadenze ormai fissate e dalla minaccia del “raccogli ora, decifra dopo”, che rende urgente proteggere già oggi i segreti destinati a durare a lungo. Ma prima di sostituire un algoritmo bisogna sapere di averlo. Il CBOM è lo strumento standardizzato che trasforma questa consapevolezza da esercizio manuale a inventario ripetibile, ed è la prima mossa concreta di una migrazione che, senza di esso, procederebbe alla cieca.

Che cos’è un Cryptographic Bill of Materials

Un Cryptographic Bill of Materials è l’inventario strutturato e leggibile dalle macchine degli asset crittografici di un sistema: gli algoritmi, le chiavi, i certificati e i protocolli, insieme alle relazioni che li legano ai componenti software che li usano. È l’estensione, al mondo della crittografia, di un’idea già familiare: quella del Software Bill of Materials. Come l’SBOM elenca le componenti di cui un software è fatto, il CBOM elenca la crittografia che quel software impiega, e dove la impiega. La differenza è che qui le dipendenze non sono librerie ma primitive crittografiche, ed è proprio la loro invisibilità a rendere l’inventario necessario.

Lo standard di riferimento è nato in ambito aperto. Il formato CBOM è stato introdotto in CycloneDX, il progetto di OWASP per le distinte dei materiali, con la versione 1.6 dell’aprile 2024, su un contributo iniziale di IBM Research, ed è stato poi standardizzato come ECMA-424. Non si è fermato lì: la versione 1.7, rilasciata nell’ottobre 2025 e ratificata come ECMA-424 di seconda edizione a dicembre 2025, ne ha ampliato le capacità, aggiungendo un elenco standardizzato delle famiglie di algoritmi e una lista completa delle curve ellittiche, utili anche fuori da CycloneDX per le verifiche di conformità e di prontezza al post-quantum. Non è quindi un formato proprietario legato a un fornitore, ma una grammatica comune con cui descrivere la postura crittografica di un’organizzazione, generarla con strumenti di scoperta automatica e scambiarla come si scambia già un SBOM.

Perché l’inventario viene prima della migrazione

Gli standard post-quantum, almeno i principali, ci sono: nell’agosto 2024 il NIST ha finalizzato i primi tre algoritmi resistenti al calcolo quantistico (FIPS 203, 204 e 205). E “primi” è la parola esatta, perché il quadro non è ancora completo: un ulteriore algoritmo, HQC, è stato selezionato nel marzo 2025, e la firma FN-DSA (FIPS 206) è tuttora in lavorazione. Le agenzie, intanto, hanno iniziato a fissare le date entro cui abbandonare gli algoritmi vulnerabili. Il problema, insomma, non è più quale crittografia adottare, ma dove va applicata, ed è qui che casca l’asino: la maggior parte delle organizzazioni non possiede una mappa di dove e come usa la crittografia. È un sapere sparso tra team diversi, sepolto in codice scritto anni prima, delegato a componenti che nessuno controlla riga per riga.

Non a caso le stesse autorità mettono l’inventario al primo posto. Il documento congiunto di CISA, NSA e NIST, dell’agosto 2023, indica come passo iniziale proprio la costruzione di un inventario crittografico: sapere quali algoritmi sono in uso, in quali sistemi, a protezione di quali dati. È l’applicazione di un principio tanto semplice quanto trascurato, cioè che non si può migrare ciò che non si vede. Senza quella mappa, ogni piano di transizione resta una stima, e ogni scadenza un salto nel buio.

Da allora le autorità hanno alzato la posta, e il CBOM è passato dalle raccomandazioni a un atto di governo. Con l’ordine esecutivo di giugno 2026 sulla sicurezza crittografica (Executive Order 14412), la Casa Bianca ha incaricato il Dipartimento della Sicurezza interna, tramite la CISA e in coordinamento con il NIST, di pubblicare entro 270 giorni, quindi verso il 19 marzo 2027, una guida sugli elementi minimi di un cryptographic bill of materials capace di abilitare la valutazione automatizzata degli asset crittografici di un componente hardware o software. È la prima volta che una direttiva federale nomina il CBOM come artefatto definito: il segnale che l’inventario non è più una buona pratica suggerita, ma la base su cui si costruirà la conformità.

Non solo Stati Uniti: la spinta arriva anche dall’Europa

Il baricentro del dibattito è statunitense, ma la stessa direzione si legge in Europa, ed è la parte che riguarda più da vicino chi lavora in Italia. La Coordinated Implementation Roadmap del Gruppo di Cooperazione NIS, del giugno 2025, chiede agli Stati membri di avviare la transizione entro la fine del 2026, di completare la migrazione delle infrastrutture critiche non oltre il 2030 e di estenderla ai sistemi restanti, per quanto praticabile, entro il 2035. La spinta potrebbe poi irrigidirsi in obbligo: la proposta COM(2026) 13, presentata dalla Commissione nel gennaio 2026 nell’ambito di un pacchetto di semplificazione della direttiva NIS2 e di allineamento al Cybersecurity Act, se approvata da Parlamento e Consiglio scriverebbe la crittografia post-quantum direttamente nel testo della direttiva, trasformando la pianificazione da interpretazione della clausola sullo “stato dell’arte” a requisito esplicito.

Per l’Italia la scadenza di fine 2026 è vicina, e il segnale nazionale è già arrivato: l’11 giugno 2026 l’Agenzia per la Cybersicurezza Nazionale ha pubblicato due nuovi documenti sulle funzioni crittografiche, dedicati ai cifrari a flusso e alle firme digitali, e ha aggiornato alla versione 2.0 la guida sul TLS, integrandovi le soluzioni post-quantum. Il messaggio, su entrambe le sponde dell’Atlantico, converge: la migrazione ha una data, e una data trasforma l’inventario da progetto rimandabile a compito immediato.

Dal CBOM alla crypto-agility

L’inventario, di per sé, non protegge nulla: è il presupposto di ciò che viene dopo. Con una fotografia accurata della crittografia in uso, un’organizzazione può fare ciò che senza quella mappa resta un’ipotesi. Può individuare gli algoritmi vulnerabili al quantum e distinguerli da quelli ancora solidi; può stabilire una priorità, mettendo in cima ciò che protegge segreti destinati a durare anni; può scovare la crittografia debole o scaduta che si annida ovunque, non solo quella da rimpiazzare in vista del post-quantum.

È qui che il CBOM incontra la crypto-agility, cioè la capacità di cambiare algoritmo senza riscrivere l’applicazione da capo. Se la crypto-agility è l’obiettivo, il CBOM è la mappa che lo rende raggiungibile: non si può sostituire in modo ordinato ciò di cui si ignora la collocazione. Un inventario tenuto aggiornato trasforma una migrazione monolitica e rischiosa in una serie di interventi mirati e verificabili, e permette di dimostrare a un revisore, dati alla mano, a che punto sia la transizione. La stessa logica vale per la migrazione post-quantum nel suo complesso, che diventa gestibile solo quando poggia su un inventario reale anziché su una supposizione.

I limiti: un inventario non è una migrazione

Sarebbe però un errore trattare il CBOM come una soluzione anziché come un punto di partenza. La scoperta della crittografia è tecnicamente difficile: gli algoritmi si nascondono nei binari, nell’hardware, nelle componenti di terze parti e nei protocolli decisi solo al momento della connessione, e nessuno strumento li individua tutti con certezza. Un CBOM, inoltre, è una fotografia, e come ogni fotografia invecchia: senza un processo che lo mantenga aggiornato si trasforma in fretta nel ritratto di un sistema che non esiste più. Gli strumenti di generazione stanno maturando, ma non sono ancora chiavi in mano, e la parte più insidiosa resta la crittografia che non lascia tracce facili da leggere.

Proprio per questo l’inventario non va inteso come una precondizione da esaurire prima di muoversi. Commentando l’ordine esecutivo, Cloudflare ha messo in guardia dal trasformare il CBOM esaustivo in un prerequisito paralizzante: catalogare ogni algoritmo in ogni libreria richiede molto tempo, e il rischio è che l’inventario risulti già superato nel momento in cui viene completato. La lezione è pratica: conviene procedere in parallelo, cominciando a migrare i sistemi più esposti mentre l’inventario si affina, invece di attendere una mappa perfetta che forse non arriverà mai.

Va poi ricordato che l’inventario, da solo, non corregge nulla. Elencare gli algoritmi deboli non li sostituisce, e produrre un CBOM solo per spuntare una casella di conformità, senza usarlo per pianificare e verificare, è un costo senza ritorno. La via realistica è duplice: automatizzare la scoperta il più possibile e integrarla nei processi, così che l’inventario si aggiorni da sé, e trattare il CBOM come uno strumento di lavoro continuo, non come un allegato prodotto una volta e poi dimenticato.

Cosa aspettarsi, senza illusioni

La migrazione post-quantum sarà la più grande transizione crittografica degli ultimi decenni, e il Cryptographic Bill of Materials ne è la parte meno vistosa e più decisiva, quella da cui dipende tutto il resto. Il ritorno concreto non è un documento in più, ma la capacità di rispondere con i dati a domande che oggi ricevono solo stime: quali sistemi usano crittografia vulnerabile, dove, e con quale priorità intervenire. L’orologio del “raccogli ora, decifra dopo” ha già iniziato a scorrere per i dati che devono restare riservati a lungo, e partire dall’inventario è il primo passo verso una postura crittografica difendibile. Chi tratta il CBOM come un adempimento otterrà un file inutile; chi lo tratta come la mappa su cui costruire la propria crypto-agility otterrà il controllo di una transizione che, altrimenti, subirà alla scadenza.

https://www.ictsecuritymagazine.com/articoli/cryptographic-bill-of-materials-cbom/

Il quishing, cioè il phishing veicolato da un QR code, ha smesso di essere una curiosità e nel 2026 è diventato, nella telemetria di Microsoft, il vettore email in più rapida crescita. Non è un dettaglio di forma, un phishing con un’immagine al posto di un link: è un attacco costruito apposta per aggirare i controlli che difendono la posta aziendale e per portare la vittima là dove quei controlli non arrivano. I numeri lo confermano. Il rapporto Microsoft sulle minacce email del primo trimestre 2026 registra un balzo del phishing via QR da 7,6 a 18,7 milioni di attacchi tra gennaio e marzo, più 146%, il volume mensile più alto da almeno un anno, su circa 8,3 miliardi di minacce di phishing via email rilevate nel trimestre. ESET, nel suo Threat Report del primo semestre 2026 (dicembre 2025-maggio 2026), rileva che ormai l’11% delle email di phishing contiene un QR code, con una media di centomila rilevamenti al mese: è un livello record, sia pure su una serie storica breve, dato che ESET lo traccia come categoria distinta solo da settembre 2025. Per il lettore italiano conta la geografia dei bersagli: in testa Stati Uniti (19%) e Spagna (17%), seguiti da Messico (6%) e Regno Unito (5%), con l’Italia al 3% insieme a Cechia, Canada e Polonia; il fenomeno non risparmia il nostro Paese.

La ragione di questa crescita non è la novità della tecnica, che esiste da anni, ma la sua efficacia contro le difese attuali. Il QR sposta l’attacco in un punto cieco, e lo fa sfruttando due debolezze insieme: una tecnica, nei gateway di posta, e una umana, nella fiducia quasi automatica che le persone ripongono in un quadratino da inquadrare. Una precisazione di perimetro, prima di procedere: qui si parla del quishing via email, ma lo stesso inganno vive anche nel mondo fisico, con QR fraudolenti su parcometri, bike sharing e finti avvisi di multa o di pedaggio. A Pesaro, nel maggio 2026, la società dei parcheggi controllata dal Comune ha denunciato la comparsa di QR fraudolenti su alcuni parcometri cittadini, che rimandavano a pagine non autorizzate dove veniva chiesto l’inserimento dei dati della carta: cambia il canale, non il meccanismo. Capire perché funziona è la premessa per difendersi in modo diverso dal solito richiamo a “non fidarsi delle email”.

Perché il quishing, o QR code phishing, scavalca i controlli dell’email

I filtri di sicurezza della posta sono costruiti per analizzare testo e link: seguono gli URL, ne valutano la reputazione, riscrivono i collegamenti, confrontano il contenuto con schemi noti di truffa. Un QR code, per quei filtri, è un’immagine, e l’indirizzo che nasconde non è leggibile come testo. Il collegamento malevolo viaggia dentro un disegno che il gateway, se non è attrezzato a decodificarlo, non ispeziona. È lo scarto che rende il quishing efficace: non c’è un link da bloccare, c’è una figura che supera i controlli perché quei controlli guardano altrove.

Gli attaccanti hanno affinato anche la consegna. Il canale dominante resta l’allegato PDF, che anzi cresce dal 65% delle campagne QR di gennaio al 70% di marzo, mentre i documenti Office scendono dal 31% al 24%. Accanto a questo, nel marzo 2026 Microsoft ha osservato un aumento del 336% dei QR piazzati direttamente nel corpo dell’email: un volume ancora minoritario, il 5% del totale, ma un segnale di sperimentazione. È la conferma che la tecnica non solo cresce, ma cerca di continuo la superficie che i sistemi testuali non sanno leggere.

Il salto sul telefono, fuori dal perimetro

C’è un secondo motivo, più insidioso del primo, ed è dove finisce la vittima. Un QR non si clicca dalla postazione di lavoro, si inquadra con il telefono. Nel momento in cui il dipendente prende lo smartphone per scansionare il codice, esce dall’ambiente protetto del computer aziendale ed entra su un dispositivo che le difese dell’organizzazione, di norma, non presidiano. Se poi il telefono è personale, come accade nella maggior parte dei casi, l’attacco si completa interamente fuori dal perimetro gestito, lontano dall’endpoint detection e dai proxy che filtrano il traffico dei portatili.

È un trasferimento di terreno prima ancora che di vittima: l’attacco parte in un canale sorvegliato, la posta, e si conclude in uno che quasi nessuno sorveglia, il browser di un telefono privato. A questo si aggiunge la fiducia implicita nel formato. Un URL sospetto mette in guardia, un QR no, perché è illeggibile all’occhio umano e associato a usi quotidiani e legittimi, dal menu del ristorante al pagamento. La vittima non vede l’indirizzo verso cui sta andando finché non ci è già arrivata, spesso su uno schermo piccolo dove i segnali d’allarme di un sito falso sono più difficili da cogliere.

Dove porta davvero: non un’immagine, una catena

Sarebbe un errore fermarsi al QR come se fosse l’attacco. Il codice è solo la consegna; la pagina di destinazione è quasi sempre una trappola per le credenziali, e nelle campagne più evolute non un semplice sito clone ma una pagina adversary-in-the-middle che si frappone tra la vittima e il servizio reale. Una pagina di questo tipo non ruba solo la password, ma intercetta anche il codice del secondo fattore e il token di sessione, così l’attaccante entra come se avesse superato l’autenticazione forte. È la ragione per cui il quishing non va derubricato a truffa da utente distratto: è l’anello iniziale di una catena che può arrivare a un account takeover completo. Che non sia roba da dilettanti lo conferma chi lo usa: a gennaio 2026 l’FBI ha diffuso un’allerta sui QR malevoli impiegati nello spearphishing del gruppo nordcoreano Kimsuky contro obiettivi statunitensi, descrivendo attacchi che si chiudono con il furto e il riuso del token di sessione, così da scavalcare l’MFA senza generare un allarme di “autenticazione fallita”. E le pagine AiTM a valle non sono artigianali, ma servite da kit di phishing-as-a-service: un ecosistema in continuo rimescolamento: Tycoon 2FA è stato smantellato a inizio marzo 2026, ma un kit rivale come Starkiller era già documentato due settimane prima del takedown.

Letto così, il vettore QR e il furto di sessione non sono due problemi distinti, ma lo stesso attacco visto da due estremi. Il QR serve a far attraversare indenne la posta e a spostare la vittima su un dispositivo scoperto; la pagina AiTM, all’altro capo, monetizza quel varco rubando l’accesso. Difendere solo un estremo lascia l’altro aperto.

Come difendersi: l’awareness non basta, serve struttura

La prima reazione, formare le persone a diffidare dei QR, è utile ma insufficiente, e per un motivo strutturale: il QR è nato per essere inquadrato senza pensarci, e un livello di sospetto abbastanza alto da bloccarlo bloccherebbe anche gli usi legittimi. La security awareness resta un tassello, ma va affiancata a controlli che non dipendono dall’attenzione del singolo. Sul piano della posta significa dotare i gateway della capacità di decodificare i QR nelle immagini e di analizzare la destinazione prima della consegna, invece di trattarli come figure innocue. Sul piano del dispositivo significa estendere la protezione ai telefoni che accedono alle risorse aziendali, perché è lì che l’attacco si consuma.

Ma la difesa che chiude davvero la catena agisce all’ultimo anello, l’autenticazione. Se l’accesso è protetto solo da fattori resistenti al phishing, come le passkey basate su FIDO2, senza fallback su OTP o SMS, la pagina AiTM a cui il QR conduce non ha nulla da rubare: non esiste un codice da intercettare né un token riutilizzabile, perché la credenziale è legata al dominio legittimo e non funziona altrove. È lo spostamento decisivo, dal cercare di impedire alla vittima di arrivare sulla pagina falsa al rendere inutile il fatto che ci arrivi. Le altre misure riducono la probabilità dell’attacco; questa ne annulla il guadagno.

Cosa aspettarsi, senza illusioni

Il quishing non è una moda passeggera ma un vettore destinato a restare, perché sfrutta un divario reale e duraturo: quello tra la posta aziendale, sorvegliata, e il telefono personale, che non lo è. Finché l’attacco potrà partire in un canale controllato e concludersi in uno scoperto, il QR resterà uno strumento comodo per gli aggressori, e i numeri del 2026 lo dicono già con chiarezza. La risposta efficace non è un cartello che invita a non inquadrare i codici, ma una difesa a strati che unisce l’ispezione dei QR nella posta, la protezione dei dispositivi mobili e, soprattutto, un’autenticazione che regge anche quando la vittima finisce sulla pagina sbagliata. Trattare il quishing come una questione di distrazione individuale è il modo più sicuro per continuare a subirlo; trattarlo come ciò che è, un bypass architetturale, è il primo passo per neutralizzarlo.

https://www.ictsecuritymagazine.com/articoli/quishing-qr-code-phishing/