Red Hot Cyber
Sicurezza Informatica, Notizie su Cybercrime, Analisi Vulnerabilità e Intelligenza Artificiale
Nella digital forensics, ciò che un software non trova non è necessariamente assente. I falsi negativi possono escludere elementi rilevanti dall'analisi, mentre risultati ripetibili non sono automaticamente corretti. Testing, verifica indipendente e conoscenza dei limiti del tool sono fondamentali per evitare che una black-box sostituisca il giudizio dell'analista.
Nella digital forensics utilizziamo continuamente software che automatizzano acquisizione, parsing, ricerca, classificazione e ricostruzione degli artefatti. Spesso non conosciamo nel dettaglio ciò che accade tra il dato originale e il risultato che compare sullo schermo. Questo, da solo, non rende uno strumento inaffidabile.
Il problema nasce quando una decisione investigativa dipende da quell’output e non sappiamo stabilire quanto possiamo verificarlo, quali siano i suoi limiti o, soprattutto, cosa possa non averci mostrato. La domanda allora cambia: quanto della nostra conclusione dipende dal tool e quanto possiamo verificare indipendentemente? Il software ha trovato qualcosa. E adesso?
Immaginiamo una situazione concreta. Abbiamo acquisito un dispositivo contenente centinaia di migliaia di file. Il software forense termina l’elaborazione e organizza i risultati in categorie, timeline, artefatti ricostruiti e contenuti classificati automaticamente. Tra migliaia di immagini ne segnala alcune come potenzialmente rilevanti. L’analista le apre. Il contenuto sembra effettivamente compatibile con ciò che sta cercando.
A prima vista il sistema ha fatto esattamente ciò che ci aspettavamo: ha ridotto enormemente lo spazio di ricerca e ha portato la nostra attenzione su qualcosa che meritava di essere esaminato. Proviamo però a cambiare domanda. Non chiediamoci cosa abbia trovato.
La differenza è sostanziale. Un falso positivo può emergere durante il controllo. Il software segnala qualcosa, l’analista lo esamina e può accorgersi che il risultato non è pertinente. Il controllo umano, però, può a sua volta sbagliare. Un falso negativo rischia invece di non arrivare mai a quel controllo.
Il file esiste, magari è rilevante, ma non compare nella selezione proposta dal sistema. Se iniziamo a trattare quella selezione come se coincidesse con l’intero insieme dei contenuti rilevanti, ciò che il software non ha riconosciuto rischia semplicemente di uscire dal nostro campo di osservazione.
A quel punto il problema non riguarda più soltanto le prestazioni del software. Riguarda la decisione che abbiamo preso sulla base del suo risultato.
Quando parliamo di strumenti black-box è facile cadere in una semplificazione. Non conosco il codice sorgente o l’algoritmo interno, quindi non posso fidarmi del risultato. Nella pratica, però, utilizziamo continuamente componenti dei quali non conosciamo ogni dettaglio implementativo: sistemi operativi, firmware, librerie, filesystem, applicazioni proprietarie e strumenti commerciali.
La disponibilità del codice sorgente può certamente aumentare le possibilità di analisi e verifica, ma non risolve da sola il problema dell’affidabilità. Allo stesso modo, un prodotto chiuso non diventa affidabile semplicemente perché è diffuso o utilizzato da molti laboratori.
La domanda utile è un’altra: cosa sappiamo del comportamento dello strumento nella funzione che ci interessa? Lo Scientific Working Group on Digital Evidence affronta il problema proprio da questa prospettiva. Le raccomandazioni SWGDE sul testing comprendono strumenti commerciali, open source e sviluppati internamente e collegano la verifica alla funzione svolta e all’impiego operativo, non semplicemente alla provenienza del software. [1]
È un passaggio importante. Non dobbiamo necessariamente conoscere ogni istruzione eseguita dal programma. Dobbiamo però avere elementi sufficienti per capire se, nelle condizioni rilevanti per il nostro esame, fa ciò che riteniamo faccia e quali siano i limiti conosciuti di quella funzione.
Supponiamo di preparare un dataset del quale conosciamo esattamente il contenuto. Inseriamo elementi rilevanti e non rilevanti, eseguiamo l’analisi e confrontiamo i risultati con ciò che sappiamo essere presente. Il software individua correttamente tutto ciò che ci aspettavamo. È certamente un risultato utile. Ma cosa abbiamo realmente dimostrato?
Abbiamo osservato il comportamento dello strumento su quei dati, con quella versione e in quelle condizioni. Non abbiamo dimostrato che funzionerà allo stesso modo con qualsiasi formato, filesystem, database, sistema operativo o condizione che incontreremo in futuro. SWGDE contempla, tra le possibili modalità di testing, proprio l’utilizzo di dataset con risultati conosciuti e la verifica manuale dei risultati. Allo stesso tempo evidenzia come la variabilità di software e hardware renda impossibile garantire che uno strumento si comporti come previsto in ogni possibile situazione. [1]
Anche il programma Computer Forensics Tool Testing del NIST segue un’impostazione basata sulle funzioni: vengono definite specifiche, requisiti, casi di test e ambienti di prova per valutare determinate categorie di strumenti forensi. [5]
Questo suggerisce una certa prudenza quando utilizziamo parole come validato. Non significa: questo software produce sempre risultati corretti. I test ci mostrano come si è comportato. Verificare significa accertare se rispetta i requisiti stabiliti. Per parlare di validazione, quei requisiti devono essere adatti all’uso previsto: dobbiamo avere elementi per dire che il metodo va bene per il lavoro che gli chiediamo. [7]
Ed è una differenza tutt’altro che formale.
Eseguiamo nuovamente l’analisi. Stesso input, stessa versione, stessa configurazione. Otteniamo esattamente lo stesso risultato. È importante, se da quella funzione ci aspettiamo lo stesso risultato a ogni esecuzione. Ma la ripetibilità, da sola, non dimostra che il risultato sia corretto. Un errore sistematico può essere perfettamente ripetibile.
Un parser che interpreta in modo errato una particolare struttura dati potrebbe farlo nello stesso identico modo ogni volta. Una funzione che ignora una determinata condizione potrebbe ignorarla con assoluta coerenza. SWGDE distingue gli errori casuali da quelli sistematici e considera proprio la possibilità che un’implementazione imperfetta produca risultati errati al verificarsi di determinate condizioni. [2]
Per questo ripetere l’operazione può essere utile, ma non sempre basta. A volte la domanda più interessante è:
posso arrivare allo stesso risultato attraverso una strada diversa?
Supponiamo che il software ricostruisca un messaggio da un database. Possiamo limitarci a riportare ciò che compare nell’interfaccia. Oppure possiamo tornare al dato sottostante, sulla copia di esame: osservare le tabelle interessate, verificare timestamp e identificativi, confrontare gli elementi correlati o utilizzare, quando serve, un secondo metodo di parsing.
Anche qui serve attenzione. Se i due programmi condividono lo stesso errore, ottenere due volte la stessa risposta non ci aiuta a scoprirlo. È un limite del confronto tra strumenti richiamato anche da SWGDE. [1]
Non significa duplicare indiscriminatamente ogni operazione. Sarebbe spesso inutile e, in molti casi, impraticabile. Il punto è capire quanto è importante la conclusione che stiamo traendo e quanto quella conclusione dipende da un singolo processo automatizzato. Se un risultato serve a decidere da dove cominciare, potremmo accettare un livello di verifica.
Se diventa centrale per una conclusione tecnica, il livello necessario può cambiare. E questo vale anche per il triage, quando decide quali dati non esamineremo più. Le best practice SWGDE per gli esami di computer forensics richiamano proprio questo problema: gli strumenti automatizzati utilizzati per il parsing possono non interpretare o processare tutti i dati rilevanti. L’esaminatore deve quindi conoscerne i limiti e considerare, quando necessario, l’analisi di ciò che potrebbe essere stato escluso. [3]
La verifica indipendente non serve soltanto a confermare ciò che abbiamo trovato. Può servire a scoprire ciò che il primo metodo non ci ha mostrato.
Un esempio concreto compare nella decisione McBride v. Commonwealth of Kentucky, pronunciata il 24 settembre 2026. Dopo un’estrazione con Cellebrite, l’investigatore si accorse che mancavano immagini e video attesi. L’analista provò anche Magnet AXIOM, ottenendo un report sostanzialmente analogo. Proseguì quindi con un esame manuale del telefono, documentando mediante Cellebrite schermate dei contenuti visualizzati. La sentenza riferisce inoltre che, secondo il detective, i contenuti in questione erano in Google Photos e non memorizzati localmente. [8]
Il passaggio utile, per noi, è questo: due report simili non bastavano a spiegare ciò che mancava. Il caso non permette di stabilire quale passaggio tecnico avesse lasciato fuori quei contenuti. Mostra però perché una discrepanza meriti attenzione, anche quando un secondo programma sembra confermare il primo.
La sorgente, i dati acquisiti, gli artefatti ricostruiti e il report non sono la stessa cosa. Prima di concludere che un contenuto non esiste, dobbiamo capire fino a dove è arrivato il nostro esame.
Torniamo alle nostre immagini. Il sistema ne analizza 100.000 e ne presenta 300 come potenzialmente rilevanti. Possiamo controllare quei 300. Ma cosa sappiamo degli altri 99.700?
È qui che l’automazione produce un paradosso interessante. Più è efficace nel ridurre il volume di informazioni che dobbiamo esaminare, più rischiamo di dipendere dalla sua capacità di decidere cosa meriti la nostra attenzione. Questo non è un argomento contro l’automazione.
Senza ricerca, filtraggio, indicizzazione e classificazione automatica, molti dataset contemporanei sarebbero difficilmente gestibili in tempi ragionevoli. Il problema nasce quando facciamo, magari senza accorgercene, un passaggio ulteriore:
“il tool non lo ha trovato” → “non esiste”.
Le due affermazioni non sono equivalenti. La prima descrive il risultato di una procedura. La seconda descrive la realtà che stiamo cercando di ricostruire. Tra le due c’è lo spazio nel quale devono entrare testing, conoscenza dei limiti, verifica e giudizio dell’analista.
Con l’intelligenza artificiale il problema non nasce da zero. Diventa semplicemente più evidente. Un classificatore può assegnare una categoria o un punteggio a un’immagine senza che l’analista possa ricostruire facilmente perché abbia prodotto proprio quel risultato.
Potremmo non conoscere il dataset utilizzato per addestrarlo. Potremmo non conoscere tutti i passaggi di preprocessing. Potremmo ricevere un confidence score senza sapere quanto quel valore sia significativo sui dati che stiamo realmente esaminando.
Oppure modello e pipeline potrebbero essere completamente proprietari. Ma anche qui chiedere genericamente se “l’AI è affidabile” serve a poco. La domanda dovrebbe essere più precisa:
affidabile per quale funzione, su quali dati e rispetto a quale decisione?
Un sistema può essere molto utile per stabilire quali elementi esaminare per primi senza che il suo output debba diventare, da solo, una conclusione forense. Un’accuracy elevata ci dice quante classificazioni sono corrette sui dati del test. Da sola non ci dice quali errori restano, né quanto peseranno nel nostro esame.
Il NIST AI Risk Management Framework colloca infatti validità e affidabilità accanto ad altre caratteristiche, tra cui accountability, trasparenza, spiegabilità, privacy, sicurezza e resilienza. [6]
Un buon risultato su un benchmark può dirci qualcosa sulle prestazioni di un sistema in quelle condizioni. Non ci dice automaticamente quanto sia difendibile una conclusione costruita sul suo output.
C’è infine un passaggio molto più quotidiano. Molti strumenti producono automaticamente report estremamente dettagliati. Hash, percorsi, timestamp, categorie, miniature, risultati delle ricerche. Decine, talvolta centinaia di pagine. È facile confondere questa quantità di informazioni con la documentazione dell’esame.
Ma non sono la stessa cosa. SWGDE osserva che i report generati dagli strumenti documentano normalmente le azioni e i risultati specifici del software, non necessariamente l’intero esame forense. [4] Il report automatico può quindi essere una parte della documentazione.
La responsabilità della relazione rimane dell’esaminatore. È l’analista che deve poter spiegare cosa è stato fatto, quale versione e configurazione siano state utilizzate quando rilevanti, quali risultati siano stati ottenuti, quali verifiche siano state effettuate e quali anomalie o limitazioni siano emerse.
Soprattutto, dovrebbe essere possibile ricostruire quanto quel risultato abbia pesato sulla decisione finale.
Torniamo un’ultima volta alle immagini del nostro esempio. Il software ne ha segnalate alcune. L’analista le ha esaminate, ha controllato i file nella copia acquisita e ha conservato gli elementi necessari a ricostruire il processo. Quando un risultato è diventato particolarmente importante, non si è fermato alla visualizzazione proposta dal software ma ha cercato una verifica ulteriore.
E soprattutto non ha trasformato automaticamente l’assenza di una segnalazione nell’assenza del fenomeno cercato. Non abbiamo aperto la black-box. Abbiamo fatto qualcosa di più realistico: abbiamo ridotto la quantità di fiducia che siamo costretti a riporre esclusivamente in essa.
Nella digital forensics non possiamo pretendere di conoscere ogni dettaglio interno di ogni componente che utilizziamo. Possiamo però sapere quale decisione stiamo prendendo sulla base del suo risultato. Possiamo chiederci cosa sia stato realmente verificato. Possiamo cercare di capire cosa potrebbe essere rimasto fuori.
E possiamo documentare i limiti entro i quali quel risultato è stato utilizzato. Per questo, davanti all’output di uno strumento, forse la domanda più utile non è:
“Posso fidarmi?”
Ma: “Quale decisione sto prendendo sulla base di questo risultato, cosa posso verificare indipendentemente e cosa rischio di non vedere se il tool sbaglia?”
Perché il punto non è eliminare la black-box. È evitare che diventi, senza che ce ne accorgiamo, il luogo nel quale abbiamo delegato anche il nostro giudizio.
Riferimenti essenziali
Sono aperte le iscrizioni al corso in Live Class “AGENTIC AI CYBER OPERATIONS (AACO)”. La cybersecurity sta entrando nell'era degli AI Agent: sistemi capaci di ragionare, utilizzare strumenti, orchestrare attività e portare avanti operazioni complesse. Ma come funzionano davvero dal punto di vista tecnico? Con AACO, Red Hot Cyber porta i professionisti della cybersecurity a toccare con mano gli strumenti agentici, attraverso una Live Class in italiano con 15 ore di formazione, laboratori pratici e scenari reali. Agentic AI, Tool Calling, MCP, orchestrazione di agenti, OSINT, Threat Intelligence, vulnerability assessment e automazione delle operazioni di cybersecurity. Non un corso per imparare a usare un chatbot, ma un percorso per capire, costruire e governare sistemi agentici applicati alla sicurezza informatica.
Partenza: Sabato 7 novembre
Programma completo e iscrizioni: https://www.redhotcyber.com/linksSk2L/academy-agentic-ai
Per info: 379 163 8765 [email protected]