Red Hot Cyber
Sicurezza Informatica, Notizie su Cybercrime, Analisi Vulnerabilità e Intelligenza Artificiale
L'uso dell'intelligenza artificiale nella digital forensics sta dilagando, evidenziando come l'automazione possa accelerare l'esame di grandi volumi di immagini ma introdurre rischi di falsi positivi e falsi negativi. Vengono discussi i limiti delle metriche tradizionali come l'accuracy, l'importanza di recall e precision, la calibrazione dei modelli e le minacce adversarial. Si sottolinea la necessità di un approccio human‑in‑the‑loop, di valutazioni contestuali e di una chiara definizione dell'uso previsto per garantire affidabilità operativa.
L’intelligenza artificiale può ridurre drasticamente il tempo necessario per esaminare grandi quantità di immagini e video. Ma una buona accuracy non significa automaticamente che un sistema sia affidabile per una specifica attività forense. Il problema più delicato può non essere ciò che il modello classifica in modo errato davanti ai nostri occhi, ma ciò che lascia fuori senza attirare mai la nostra attenzione.
Per questo, prima di affidare a un classificatore una parte della ricerca, dovremmo capire quali errori può commettere, su quali dati conosciamo realmente le sue prestazioni e quali conseguenze può avere quell’errore sul nostro esame.
Immaginiamo di dover esaminare 100.000 immagini alla ricerca di una determinata categoria di contenuti. Aprirle tutte una per una richiederebbe molto tempo. Un sistema basato su intelligenza artificiale può invece analizzarle rapidamente e proporci una selezione di quelle che ritiene compatibili con ciò che stiamo cercando. Trecento immagini vengono segnalate.
L’analista comincia da quelle. Le apre, confronta i risultati con ciò che sta cercando, scarta quelli sbagliati e approfondisce gli altri. Fin qui l’automazione svolge esattamente il compito che ci aspettiamo: riduce lo spazio di ricerca e aiuta a stabilire da dove iniziare. Il problema compare quando quelle 300 immagini diventano, quasi senza che ce ne accorgiamo, tutte quelle che riteniamo meritevoli di attenzione.
Il sistema non ci ha necessariamente detto questo. Ha restituito gli elementi che, secondo il modello e la configurazione utilizzati, appartengono a una categoria o superano una determinata soglia.E anche una classificazione corretta non stabilisce da sola la rilevanza investigativa del file. Riconoscere un oggetto in una fotografia è una cosa. Capire quale rapporto abbia quella fotografia con i fatti che stiamo esaminando ne richiede altre.
Restano poi 99.700 immagini fuori dalla selezione. Che cosa sappiamo di quelle?
Supponiamo che il sistema segnali come rilevante un’immagine che in realtà non appartiene alla categoria cercata. È un falso positivo. L’analista apre il file e può accorgersi dell’errore. Non è una garanzia: anche la verifica umana può sbagliare e un risultato suggerito dal software può influenzare chi lo osserva. Però quel contenuto è arrivato davanti all’esaminatore.
Il falso negativo segue un percorso diverso. Il contenuto che stavamo cercando esiste, ma il modello non lo segnala. Se il lavoro si concentra soltanto sui risultati proposti dal sistema, quel file potrebbe non essere mai aperto. Questa differenza diventa importante quando decidiamo quale funzione affidare all’AI. Nella guida sulle tecnologie AI per l’analisi video, SWGDE richiama sia il rischio di identificazioni errate sia quello di non rilevare evidenze rilevanti. Richiama inoltre la verifica umana e/o la corroborazione con altre evidenze prima di assumere determinate decisioni sulla base di comparazioni effettuate mediante machine learning e, sul piano della validazione, considera l’impiego di dataset di riferimento conosciuti e la valutazione di falsi positivi e falsi negativi. [1]
Questo non significa che i falsi positivi siano un problema minore. Significa che i due errori possono produrre conseguenze diverse. Uno può portare davanti all’analista materiale che non avrebbe dovuto esserci. L’altro può impedire che qualcosa arrivi davanti all’analista. Ed è soprattutto quest’ultimo rischio a diventare delicato quando la selezione automatica finisce per coincidere con il confine dell’esame.
Quando valutiamo un classificatore, uno dei numeri più intuitivi è l’accuracy. Quante classificazioni ha effettuato correttamente? È una metrica utile, ma da sola può raccontare molto poco. Torniamo alle nostre 100.000 immagini e supponiamo, solo per costruire l’esempio, di conoscerne esattamente il contenuto. Soltanto 500 appartengono alla categoria che ci interessa.
Immaginiamo ora un classificatore particolarmente inutile: risponde sempre “negativo”. Sbaglia tutte le 500 immagini che stavamo cercando, ma classifica correttamente le altre 99.500. Accuracy: 99,5%. Il numero potrebbe sembrare eccellente. La ricerca, invece, non avrebbe trovato nulla. Per capire meglio ciò che è successo servono altre misure. La recall, o sensibilità, ci dice quanti degli elementi effettivamente appartenenti alla categoria sono stati individuati. Nel nostro esempio sarebbe zero.
La precision risponde a una domanda diversa: tra gli elementi segnalati dal sistema, quanti appartengono davvero alla categoria cercata? Le due misure descrivono quindi problemi operativi differenti. Una ci aiuta a capire quanto materiale rilevante rischiamo di perdere; l’altra quanta parte della selezione proposta rischia di trasformarsi in lavoro di verifica inutile.
Poi c’è la soglia.
Abbassarla può permettere di intercettare più contenuti, ma spesso aumenta anche i falsi positivi. Alzarla può rendere più breve la lista da controllare, lasciando però fuori altri elementi. Non esiste quindi una percentuale che, da sola, ci dica se il sistema sia adatto al nostro lavoro. Prima dobbiamo sapere che cosa gli stiamo chiedendo.
Un sistema può essere molto utile per stabilire quali immagini guardare per prime senza essere sufficientemente affidabile per decidere quali immagini non guardare affatto. La differenza è importante. Se l’AI viene utilizzata soltanto per prioritizzare, l’analista mantiene teoricamente la possibilità di proseguire l’esame sul resto del materiale.
Ma anche qui il confine non è sempre così netto. Se il tempo disponibile termina prima che la revisione sia completata, ciò che il sistema ha collocato in fondo potrebbe comunque non essere esaminato. L’uso reale del classificatore conta quindi più dell’etichetta con cui descriviamo la funzione.
Il NIST IR 8589 collega la validazione ai requisiti dell’uso previsto e alla caratterizzazione delle prestazioni entro un ambito definito. Applicato a questo problema, significa chiedersi se le prestazioni conosciute siano adeguate proprio al compito che stiamo affidando al sistema. [2]
Usare un modello per stabilire una priorità, usarlo per escludere materiale e utilizzare il suo risultato per sostenere una conclusione non sono la stessa cosa. Prima di chiederci quanto sia bravo il modello, dovremmo stabilire quale decisione gli stiamo permettendo di influenzare.
Supponiamo adesso che il modello sia stato valutato correttamente. Abbiamo dati di test separati da quelli utilizzati durante l’addestramento, categorie definite e risultati documentati. È certamente un buon punto di partenza. Durante un esame forense, però, possiamo incontrare fotografie compresse più volte, screenshot, immagini ritagliate, miniature, file sfocati, contenuti ricodificati da applicazioni o recuperati solo parzialmente. La categoria può essere la stessa.
Il modo in cui arriva al classificatore può essere molto diverso. Il Playbook del NIST AI Risk Management Framework richiama proprio la rappresentatività dei dati rispetto al contesto di utilizzo, insieme alla necessità di valutare le prestazioni del sistema nelle condizioni rilevanti. [3] Un benchmark, quindi, ci dice come si è comportato il modello nelle condizioni del benchmark.
Non dimostra automaticamente che manterrà lo stesso comportamento sui dati del dispositivo che abbiamo davanti. Con un prodotto commerciale potremmo non conoscere nel dettaglio il dataset utilizzato per l’addestramento. Possiamo però cercare informazioni sulle condizioni nelle quali il sistema è stato valutato e, quando la conclusione lo richiede, effettuare verifiche mirate utilizzando materiale di riferimento dal contenuto conosciuto.
Dove queste informazioni mancano, anche il peso che attribuiamo al risultato dovrebbe tenerne conto.
Un’interfaccia mostra una categoria e, accanto, un numero: 92%.
È facile leggerlo come: “c’è il 92% di probabilità che questa immagine rappresenti ciò che sto cercando”. Ma non è detto che significhi questo. Potrebbe trattarsi di un punteggio di similarità, dell’output interno di un classificatore oppure di una stima probabilistica. La forma grafica non basta a stabilirlo.
Anche quando il valore viene presentato come probabilità, rimane il problema della calibrazione: quanto i livelli di confidenza prodotti dal modello corrispondono effettivamente alle frequenze di correttezza osservate su dati adeguati? Il lavoro di Guo e colleghi sulla calibrazione delle moderne reti neurali mostra perché questa corrispondenza non possa essere data per scontata. [4]
E neppure una buona calibrazione rende il numero universalmente valido. Se il sistema incontra contenuti molto diversi da quelli sui quali è stato valutato, un valore elevato non dimostra automaticamente che la previsione sia affidabile nello stesso modo. Alcuni sistemi possono rifiutare una classificazione o segnalare un input anomalo. Altri assegnano comunque una delle categorie disponibili.
Bisogna sapere come si comporta lo strumento che stiamo utilizzando. La confidence del modello non dovrebbe diventare automaticamente la fiducia dell’analista.
Nella digital forensics dobbiamo considerare anche un altro problema. Qualcuno potrebbe aver cercato deliberatamente di rendere un contenuto più difficile da riconoscere. L’adversarial machine learning studia, tra gli altri fenomeni, modifiche agli input progettate per indurre errori nel modello.
La tassonomia NIST distingue, per esempio, gli attacchi di evasion, che cercano di influenzare il comportamento del sistema durante il suo utilizzo, dagli attacchi di poisoning, che intervengono invece sulle risorse impiegate nella fase di apprendimento. [5]
Ma qui serve cautela. Un’immagine degradata non è automaticamente un’immagine modificata con finalità anti-forensi. Compressione, ridimensionamento, variazioni cromatiche o ricodifica possono derivare dal normale utilizzo di un dispositivo o dal passaggio attraverso un’applicazione. Trasformazioni simili potrebbero anche essere applicate intenzionalmente. La modifica osservata e l’intento con cui è stata prodotta sono due questioni differenti. Per valutare l’affidabilità del classificatore, però, rimane utile una domanda più semplice: che cosa succede quando il sistema incontra variazioni realisticamente presenti nei dati forensi?
Le prestazioni rimangono accettabili? Aumentano soprattutto i falsi positivi o i falsi negativi? Alcune categorie diventano più difficili da riconoscere? Un buon risultato ottenuto su immagini pulite non permette, da solo, di rispondere.
A questo punto potremmo pensare di risolvere il problema lasciando sempre la decisione finale all’analista. È certamente una salvaguardia importante. Bisogna però capire dove quella persona entra realmente nel processo. Se il sistema analizza 100.000 immagini e ne propone 300, l’analista può verificare quelle 300.
Ma la verifica riguarda ciò che il sistema gli ha mostrato. Non ci dice direttamente quanti contenuti rilevanti siano rimasti tra gli altri file. Questo non significa che l’unica alternativa sia controllare manualmente tutte le 100.000 immagini. A seconda del caso possiamo utilizzare controlli su campioni del materiale non segnalato, ricerche con criteri differenti oppure approfondire le discrepanze rispetto ad altre evidenze disponibili.
Anche questi controlli, però, devono essere interpretati per quello che sono. Un campione troppo piccolo o scelto male potrebbe non intercettare errori rari. Due strumenti differenti potrebbero condividere limiti simili. La concordanza tra due risultati non dimostra automaticamente che nulla sia rimasto fuori.
Dire semplicemente che “il risultato è stato verificato da un essere umano” dice quindi poco. Dovremmo poter spiegare quale parte del processo è stata verificata e cosa quella verifica ci permette realmente di concludere.
C’è poi un problema ancora più semplice, che rischia facilmente di passare inosservato. Un contenuto può non comparire nella selezione senza essere mai stato classificato. Un formato non supportato, un errore di decodifica, un’elaborazione interrotta o un problema nella pipeline possono lasciare alcuni file senza valutazione. Nel caso di un video, il sistema potrebbe inoltre analizzare soltanto determinati fotogrammi.
Questo rende importante distinguere almeno tre situazioni:
Sono tre risultati diversi.
Prima di interpretare una selezione dovremmo quindi sapere quanti file rientravano realmente nell’attività, quanti sono stati elaborati, quali sono rimasti fuori e quali impostazioni hanno determinato ciò che il software ci presenta. Se questi passaggi non sono ricostruibili, anche le metriche del modello raccontano soltanto una parte del processo.
L’affidabilità operativa non dipende solo dal classificatore. Dipende da tutto ciò che avviene tra il dato originale e ciò che compare davanti all’analista.
Il NIST AI Risk Management Framework considera il rischio dell’AI rispetto al contesto nel quale il sistema viene utilizzato e lungo il suo ciclo di vita. Il più recente ARIA Evaluation Planning Manual, pubblicato nel settembre 2026, propone una valutazione che combina model testing, red teaming e user testing. [3][6]
ARIA non è una procedura specifica per validare classificatori utilizzati nella digital forensics. Il collegamento che ci interessa è metodologico. Valutare il modello non significa necessariamente aver valutato tutto il sistema. Nel laboratorio contano anche altri elementi: come l’interfaccia presenta i risultati, se gli errori vengono segnalati, quanto sia semplice raggiungere i file che non compaiono nella selezione e se sia possibile ricostruire successivamente configurazione e impostazioni utilizzate.
Un classificatore può avere ottime prestazioni ed essere inserito in un flusso di lavoro che induce comunque conclusioni eccessive. Pensiamo a un software che mostri semplicemente “nessun risultato”. Significa che tutti i file sono stati processati e classificati come negativi? Oppure alcuni non sono stati elaborati? Oppure nessuno ha superato la soglia? Dal punto di vista dell’analista non sono dettagli. Cambiano il significato della risposta.
Torniamo alle nostre 100.000 immagini. Il sistema ci ha aiutato a individuare rapidamente una selezione da controllare. Se vogliamo spiegare quale peso attribuire a quel risultato, dobbiamo però essere in grado di ricostruire qualcosa di più. Quale funzione abbiamo utilizzato? Con quale versione del software e, quando disponibile, del modello? Quale configurazione? Quale soglia? Quanti file sono stati effettivamente processati? Quali limiti conoscevamo? Quali controlli abbiamo eseguito?
Soprattutto, dobbiamo capire se l’AI sia servita soltanto a stabilire l’ordine con cui esaminare il materiale oppure se abbia contribuito a decidere quale materiale non sarebbe più stato esaminato. È una differenza che cambia anche il modo di scrivere la conclusione. “Nessun contenuto segnalato dalla funzione utilizzata” descrive un risultato dell’elaborazione.
Dire che “il materiale cercato è assente” significa qualcosa di più. Per arrivare alla seconda affermazione servono elementi ulteriori, proporzionati all’estensione dell’esame, ai controlli effettuati e ai limiti conosciuti del metodo.
Probabilmente utilizzeremo sempre più automazione nella digital forensics. La quantità di dati da esaminare rende questa evoluzione difficile da evitare e, in molti casi, utile. Il punto non è quindi decidere se fidarci o meno dell’intelligenza artificiale in astratto. Una buona accuracy può essere compatibile con errori importanti per il nostro caso.
Un confidence score può essere utile senza rappresentare ciò che pensiamo rappresenti. Un benchmark può descrivere bene un sistema e descrivere male i dati che abbiamo davanti. E la presenza di un essere umano nel processo non significa automaticamente che tutto ciò che il modello ha escluso sia stato controllato. La domanda diventa più concreta:
quale decisione stiamo permettendo a questo sistema di influenzare, quali errori può commettere nelle condizioni che stiamo osservando e cosa rischiamo di non vedere quando sbaglia? Da qui possiamo decidere quali verifiche siano necessarie e quanto peso attribuire all’output. L’AI può aiutarci a vedere più rapidamente.
In un esame forense, però, dobbiamo conoscere abbastanza bene il processo da poter spiegare anche che cosa potrebbe essere rimasto fuori.
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]