Europol e Digital Forensics: il problema non è solo trovare le evidenze, ma sapere cosa manca

Il rapporto Europol "Digital Forensics: Gap Analysis" evidenzia le difficoltà nella validazione e nell'interoperabilità degli strumenti forensi, soprattutto quando i risultati differiscono. Vengono analizzate le lacune legate a software, formati proprietari e intelligenza artificiale, sottolineando la necessità di test indipendenti, standard comuni e formazione per tutti gli attori coinvolti. L'articolo spiega perché conoscere ciò che il software non ha analizzato è cruciale per garantire prove affidabili in ambito investigativo.

Due strumenti forensi possono esaminare gli stessi dati e restituire risultati differenti. Quale dei due possiamo considerare affidabile? Il nuovo rapporto Digital Forensics: Gap Analysis, pubblicato da Europol il 16 ottobre 2026, richiama l’attenzione sulle difficoltà che le autorità europee incontrano nella validazione degli strumenti, nell’interoperabilità dei sistemi e nell’impiego dell’intelligenza artificiale.

Tra le questioni sollevate ce n’è una particolarmente concreta: come possiamo valutare l’affidabilità di un risultato se non conosciamo abbastanza bene ciò che il software ha effettivamente esaminato? Immaginiamo di aver acquisito uno smartphone nell’ambito di un’indagine.

Il primo software forense restituisce 8.240 messaggi. Un secondo strumento, utilizzato sugli stessi dati acquisiti, ne individua 7.910. Le conversazioni principali sembrano coincidere, i riferimenti temporali sono coerenti e nessuno dei due programmi segnala errori particolari.

La differenza è di 330 messaggi. Potrebbero essere duplicati che uno dei due strumenti ha escluso, record recuperati soltanto da un determinato parser oppure dati interpretati diversamente. Non possiamo ancora saperlo. Entrambi i report appaiono completi. Entrambi sono stati prodotti da software utilizzati professionalmente nelle attività investigative.

Quale risultato utilizziamo? La risposta non dipende necessariamente da quale software sia più conosciuto o diffuso. Prima occorre capire che cosa ciascuno strumento abbia letto, quali operazioni abbia eseguito e se i due risultati siano effettivamente confrontabili.

È una delle difficoltà che emergono dal rapporto Digital Forensics: Gap Analysis, realizzato dalla Commissione europea in stretta cooperazione con Europol e pubblicato il 16 ottobre 2026 [1].

Il documento raccoglie le esigenze e le criticità individuate attraverso consultazioni con esperti, autorità nazionali e altri soggetti coinvolti nella digital forensics europea. Non è uno studio sperimentale sull’accuratezza dei singoli prodotti, ma un’analisi delle capacità disponibili e di quelle che ancora mancano.

E alcune di queste carenze diventano particolarmente evidenti quando un risultato deve essere utilizzato per sostenere una conclusione investigativa.

Il software ha trovato quei dati. Ma quali ha esaminato?

Torniamo ai due report. Il primo controllo potrebbe riguardare il database dal quale provengono i messaggi. Le due applicazioni hanno esaminato gli stessi file? Hanno interpretato allo stesso modo i record cancellati, i database SQLite e gli eventuali file WAL? Hanno applicato filtri differenti? Anche utilizzando la stessa acquisizione iniziale, due strumenti possono elaborare porzioni diverse dei dati disponibili.

La differenza potrebbe dipendere dal supporto offerto a una particolare versione dell’applicazione. Oppure da criteri differenti per identificare i messaggi, distinguere i record duplicati o ricostruire informazioni frammentarie. In altri casi, il limite si trova ancora prima dell’analisi. Un’acquisizione logica potrebbe non comprendere alcuni dati conservati in aree non accessibili oppure disponibili esclusivamente attraverso servizi remoti.

In questo caso nessuno dei due programmi potrebbe recuperarli dalla copia acquisita. Il rapporto Europol evidenzia proprio le difficoltà di accesso, estrazione e analisi che interessano dispositivi mobili, ambienti cloud, sistemi IoT e veicoli connessi. La crescente complessità tecnologica procede più velocemente della capacità di aggiornare strumenti, metodologie e competenze [1].

Ma nell’attività quotidiana queste difficoltà non si presentano necessariamente come un errore. Un software può terminare correttamente l’elaborazione e produrre un report senza che questo rappresenti necessariamente tutto il contenuto del dispositivo o tutte le informazioni potenzialmente disponibili.

Se il programma non ha accesso a un determinato database, oppure non dispone del parser necessario per interpretarlo, il risultato finale potrebbe semplicemente non comprenderne il contenuto. E l’assenza potrebbe non essere immediatamente riconoscibile dall’interfaccia. Per questo, nel nostro esempio, non basterebbe confrontare il numero dei messaggi. Occorrerebbe verificare le sorgenti effettivamente disponibili, i dati elaborati e le eventuali differenze nei criteri di interpretazione.

I 330 elementi di differenza potrebbero anche non corrispondere a 330 messaggi mancanti. Senza stabilire che cosa sia stato conteggiato, il confronto numerico rischia di essere fuorviante.

Una validazione eseguita altrove non risolve automaticamente il nostro caso

Tra gli aspetti più significativi del rapporto c’è la frammentazione delle pratiche di validazione. Europol rileva che i Paesi europei adottano criteri e metodologie differenti per verificare gli strumenti forensi. Questo comporta duplicazione delle attività di testing, costi elevati e difficoltà nel confrontare i risultati.

Il documento arriva a raccomandare che l’Unione europea consideri la costituzione di un organismo indipendente incaricato di eseguire test sugli strumenti utilizzati dalle autorità investigative [1]. Non si tratta, quindi, di una struttura già operativa, ma di una proposta per affrontare un problema riconosciuto. L’esigenza di test indipendenti non è nuova.

Il programma Computer Forensics Tool Testing (CFTT) del NIST utilizza metodologie basate sulle specifiche funzionalità degli strumenti. Le procedure prevedono requisiti, casi di prova e risultati documentati, così da consentire una valutazione delle capacità effettivamente sottoposte a verifica [2]. Anche lo SWGDE, nel documento Minimum Requirements for Testing Tools Used in Digital and Multimedia Forensics, raccomanda di verificare che strumenti e procedure funzionino come previsto e di comprenderne i limiti [3].

Resta però una questione operativa. Supponiamo che un software abbia superato una serie di test relativi all’estrazione e all’interpretazione dei dati di una determinata applicazione. Successivamente viene rilasciata una nuova versione dell’applicazione, con modifiche alla struttura del database. Il software forense continua a individuare alcuni messaggi, ma non abbiamo verificato se il parser riconosca correttamente tutte le nuove strutture.

Possiamo utilizzare i risultati ottenuti? Potenzialmente sì. Possiamo considerare la validazione precedente sufficiente per sostenere che tutti i messaggi accessibili siano stati recuperati correttamente? Non necessariamente. Un test dimostra qualcosa rispetto alle condizioni nelle quali è stato eseguito. Se cambiano i dati, le versioni software o le funzionalità utilizzate, occorre valutare quanto quelle condizioni siano ancora rappresentative.

Lo stesso vale per una verifica effettuata da un altro laboratorio. Può essere un riferimento importante, evitando di ripetere inutilmente prove già eseguite, ma bisogna conoscere quali funzionalità siano state testate e con quali limiti. Per tornare ai nostri due strumenti, potrebbe essere sufficiente predisporre una prova mirata con un database di riferimento contenente messaggi conosciuti, record cancellati e situazioni particolari.

Il risultato permetterebbe di verificare il comportamento dei parser su quei casi. Non dimostrerebbe, da solo, che i programmi funzionino correttamente su qualsiasi smartphone o su ogni versione dell’applicazione. È proprio questa distinzione che rende utile la validazione: sapere che cosa possiamo sostenere sulla base delle verifiche realmente effettuate.

Quando il formato dei dati impedisce di controllare il risultato

Il rapporto affronta anche un’altra difficoltà: molti strumenti commerciali utilizzano formati proprietari che complicano il trasferimento dei dati tra applicazioni differenti. Non riguarda soltanto la possibilità di aprire un file con un altro programma. Consideriamo un laboratorio che utilizza un software per acquisire i dati, un secondo per analizzare le comunicazioni e un terzo per ricostruire una sequenza temporale.

Se i sistemi non condividono formati interoperabili, potrebbe essere necessario esportare, trasformare e reimportare le informazioni. Ogni passaggio richiede attenzione. Un’esportazione può conservare il testo dei messaggi ma non tutti i metadati originali. Alcuni campi potrebbero essere normalizzati, altri esclusi perché non supportati dal formato di destinazione. Una data potrebbe essere convertita in un diverso fuso orario oppure perdere l’informazione sulla sua origine.

Non è detto che queste trasformazioni alterino il significato dell’evidenza. Alcune possono essere previste, corrette e perfettamente documentabili. Ma se il passaggio non viene controllato, diventa più difficile ricostruire da dove provenga un’informazione e quale trasformazione abbia subito. Europol individua nell’assenza di formati comuni un ostacolo all’interoperabilità e all’impiego di più strumenti nella stessa catena di analisi. Propone quindi di promuovere formati standardizzati e soluzioni modulari che rendano più semplice l’integrazione [1].

Un formato proprietario, naturalmente, non rende automaticamente inaffidabile un prodotto. Esistono strumenti commerciali che permettono verifiche approfondite, esportazioni documentate e controlli sui dati originari. Altri possono presentare limitazioni più importanti. La questione cambia quando il risultato deve essere controllato indipendentemente.

Se una determinata informazione è visibile soltanto attraverso un’interfaccia e non possiamo risalire ai dati dai quali deriva, il margine di verifica si riduce. Nel nostro esempio, la differenza tra 8.240 e 7.910 messaggi potrebbe essere chiarita tornando ai database originali e confrontando i singoli record. Se invece disponessimo soltanto di due esportazioni prive degli identificativi e dei riferimenti alle sorgenti, il confronto diventerebbe molto più complicato.

L’interoperabilità, quindi, non riguarda soltanto l’efficienza dei laboratori europei. Può incidere anche sulla possibilità concreta di sottoporre un risultato a controllo.

Con l’intelligenza artificiale compare un’altra selezione

Alle pagine 19 e 20, il rapporto dedica una sezione specifica all’intelligenza artificiale nella digital forensics. Europol richiama la necessità di utilizzare sistemi controllati, con operazioni tracciabili, documentazione dei processi e verifiche umane quando necessarie. Nel documento compare anche un esempio particolarmente significativo: una risposta AI con accuratezza del 99% può comunque risultare inutilizzabile quando non sia possibile dimostrare il processo che l’ha prodotta [1].

È un’affermazione che merita di essere letta nel suo contesto. Immaginiamo che un sistema AI venga utilizzato per individuare immagini potenzialmente rilevanti all’interno di un’acquisizione forense. Il programma analizza migliaia di file e ne segnala alcune centinaia per la revisione dell’operatore. L’analista controlla tutte le immagini segnalate e conferma quelle pertinenti. Il lavoro risulta molto più rapido rispetto a un esame manuale completo.

Resta però una domanda: che cosa sappiamo delle immagini che non sono state segnalate? Alcune potrebbero essere state classificate come negative. Altre potrebbero aver ricevuto un punteggio inferiore alla soglia impostata. Altre ancora potrebbero non essere state elaborate per errori di lettura, formati non supportati o problemi durante il processing. Queste situazioni non sono equivalenti.

Un’elevata accuratezza misurata su un dataset di test non ci dice automaticamente quanti contenuti rilevanti possano sfuggire al sistema nel caso concreto. Per valutarlo occorrono informazioni sul tipo di classificazione, sulla sensibilità, sui falsi negativi e sulla rappresentatività dei dati utilizzati per la verifica. Anche la soglia di classificazione può cambiare il numero dei risultati mostrati.

Se il sistema viene impiegato soltanto per stabilire quali immagini esaminare per prime, un certo margine di errore può essere gestito diversamente rispetto a un utilizzo nel quale tutti i contenuti non segnalati vengono esclusi da ulteriori verifiche. Nel secondo caso, un falso negativo può avere un effetto diretto sulla completezza dell’esame.

Il rapporto richiama inoltre il rischio che tecniche anti-forensi e modificazioni dei dati di input possano interferire con i sistemi AI, generando output errati. Non qualsiasi modifica osservata costituisce necessariamente un attacco anti-forense. Una ricompressione o una trasformazione dell’immagine può avere origini ordinarie. Ma se quel cambiamento altera la classificazione, il comportamento merita di essere verificato, indipendentemente dalla possibilità di attribuire un’intenzione.

La revisione umana rimane importante, ma bisogna comprenderne il perimetro. Se l’operatore controlla soltanto i contenuti che l’AI ha selezionato, non ha verificato automaticamente tutti quelli che il sistema ha escluso o non è riuscito a elaborare. In un processo controllato, la versione del modello, la configurazione, le soglie, gli errori di elaborazione e la copertura del dataset diventano informazioni necessarie per interpretare correttamente il risultato. Questo non richiede necessariamente di conoscere ogni dettaglio interno del modello.

Richiede però controlli e verifiche adeguati all’utilizzo previsto, soprattutto quando l’output contribuisce a una conclusione forense e non soltanto a orientare le successive attività investigative.

Il limite dello strumento deve arrivare fino a chi utilizza l’evidenza

Nel rapporto emerge anche un problema che riguarda il percorso dell’evidenza dopo l’acquisizione. Europol raccomanda percorsi formativi differenziati non soltanto per gli specialisti, ma anche per first responder, investigatori, pubblici ministeri e magistrati. La scelta è coerente con le difficoltà descritte nel documento. Pensiamo a una telecamera domestica collegata a un servizio cloud.

Durante un intervento viene sequestrato il dispositivo. L’analisi della memoria locale non restituisce registrazioni relative all’intervallo temporale di interesse. L’assenza di quei video nella memoria acquisita può essere un risultato corretto. Ma non dimostra che le registrazioni non siano mai esistite. Potrebbero essere state conservate soltanto sul servizio remoto, eliminate secondo una politica di conservazione oppure rese temporaneamente inaccessibili dalle condizioni del sistema.

Il rapporto segnala che gli ambienti IoT possono distribuire le informazioni tra dispositivi, applicazioni e infrastrutture cloud, spesso con tempi di conservazione limitati [1]. La criticità comincia già durante il primo intervento, quando bisogna riconoscere quali sorgenti di evidenza siano presenti, quali informazioni possano essere volatili e quali operazioni siano consentite e tecnicamente opportune. Una volta arrivati alla relazione, però, il problema assume un’altra forma.

Se scriviamo semplicemente che l’analisi non ha individuato registrazioni, senza specificare che è stata esaminata esclusivamente la memoria locale, chi legge potrebbe attribuire a quel risultato un’estensione che non possiede. Lo stesso può accadere con i messaggi dello smartphone o con le immagini classificate dall’intelligenza artificiale. Il software restituisce un insieme di dati. La relazione dovrebbe consentire di comprendere a quale sorgente e a quale attività di esame si riferisca quell’insieme.

Quando un’evidenza passa dal laboratorio all’investigatore e successivamente all’autorità giudiziaria, non dovrebbe perdere le informazioni necessarie per valutarne la portata. Torniamo allora ai 330 messaggi di differenza. Prima di scegliere quale report utilizzare, l’analista dovrebbe poter documentare l’acquisizione di partenza, le versioni degli strumenti, le operazioni compiute, le verifiche effettuate e gli eventuali limiti incontrati.

Se la differenza viene chiarita, la conclusione può tenerne conto. Se non viene chiarita, bisogna valutare se quel limite incida sulla domanda investigativa alla quale stiamo cercando di rispondere. Una discrepanza relativa a messaggi estranei all’intervallo temporale di interesse potrebbe avere un peso diverso rispetto alla mancata ricostruzione di una conversazione decisiva. Non sempre sarà necessario ricostruire ogni singolo record. Ma la decisione di interrompere o approfondire le verifiche dovrebbe essere proporzionata alla rilevanza di ciò che resta incerto.

Il rapporto Europol propone una risposta europea fatta di strumenti condivisi, validazione indipendente, formati interoperabili, cooperazione e formazione. Sono interventi che potrebbero migliorare concretamente le capacità investigative. Nel singolo procedimento, tuttavia, resta una responsabilità che nessuna piattaforma condivisa può eliminare completamente: stabilire che cosa i risultati ottenuti permettano effettivamente di concludere.

Un report può essere tecnicamente corretto e avere comunque una copertura limitata. Un programma può aver funzionato secondo le proprie specifiche senza aver esaminato tutte le informazioni potenzialmente rilevanti. La conclusione dell’analista deve tenere conto anche di questo.

Perché davanti a un risultato forense, a volte, la domanda più importante non riguarda ciò che il software ha trovato. Riguarda ciò che non siamo ancora in grado di escludere.

Riferimenti essenziali

[1] Europol, Digital Forensics: Gap Analysis, Publications Office of the European Union, Luxembourg, 2026. ISBN 978-92-9414-156-9. DOI: 10.2813/7161293.
Rapporto integrale Europol (PDF)

[2] National Institute of Standards and Technology (NIST), Computer Forensics Tool Testing (CFTT) – Methodology Overview.
Documentazione ufficiale NIST

[3] Scientific Working Group on Digital Evidence (SWGDE), Minimum Requirements for Testing Tools Used in Digital and Multimedia Forensics, SWGDE 18-Q-001-2.1, Version 2.1, 7 marzo 2024.
Documento ufficiale SWGDE

[4] ISO/IEC 27042:2015, Information technology – Security techniques – Guidelines for the analysis and interpretation of digital evidence.
Standard ISO

Lello Molinario

Lello Molinario si occupa di digital forensics, cybersecurity, investigazioni digitali ed ethical hacking. Integra esperienza operativa e ricerca accademica, con particolare attenzione alla digital evidence, alla first response e alla robustezza dei sistemi di AI applicati alla forensics.

Aree di competenza: Digital Forensics, Digital Evidence, Incident Response, Cybersecurity, Ethical Hacking, AI Security, DFIR, OSINT, Forensic Acquisition