SANS, due framework per usare l’AI in digital forensics e incident response

• SANS ha creato due framework AI: uno per la digital forensics, uno per l'incident response
• Mappati su SWGDE e NIST Cybersecurity Framework 2.0
• L'output dell'AI, anche con alta confidenza, va sempre validato in modo indipendente
• L'AI non deve compiere azioni irreversibili; l'esaminatore umano ha l'ultima parola

SANS ha introdotto nel 2026 due framework dedicati all’uso dell’intelligenza artificiale nelle indagini digitali: il Digital Forensics & AI Investigations Framework, allineato agli standard dello Scientific Working Group on Digital Evidence (SWGDE), e l’Incident Response & AI Investigations Framework, mappato sul NIST Cybersecurity Framework 2.0. A illustrarne la logica è Heather Barnhart, VP of Curriculum di SANS, in un contributo pubblicato il 15 ottobre 2026.

Il problema: sicurezza apparente degli output

Secondo Barnhart, l’AI è già usata nel lavoro di DFIR, con o senza una policy che la regoli. Gli strumenti diventano più “sicuri di sé” più in fretta di quanto i professionisti sviluppino metodi per verificarli. Un risultato non verificato può finire in un report forense, in una deposizione o in tribunale.

Un output con punteggio di confidenza alto non è una validazione. Se lo strumento non mostra il proprio ragionamento, il risultato è inaffidabile a prescindere dal punteggio. Anche quando cita il file analizzato, l’affermazione va confermata in modo indipendente. L’errore tipico è trattare l’AI come unica fonte di verità, per esempio quando un detector segnala un file come generato dall’AI e questo diventa “il risultato” senza fonte né spiegazione.

Documentare ciò che ha prodotto un risultato

Il machine learning è presente da anni nei software forensi, ad esempio nel rilevamento della pelle, nella somiglianza facciale e nella categorizzazione delle immagini. Quando l’AI è integrata in un prodotto forense, basta indicare lo strumento. Per un modello generico serve registrare la versione esatta. Le capacità dell’AI cambiano più in fretta dei tempi di un caso: senza uno storico delle versioni, la controparte può sfruttare il divario tra la tecnologia disponibile alla raccolta e quella nota al momento della testimonianza.

Due discipline, due policy

Forensics e incident response hanno tolleranze al rischio diverse. Nell’incident response conta capire in fretta cosa è successo, e l’AI aiuta a individuare attività poco visibili. Nella forensics ogni file sorgente va validato, per questo molti si aspettano che l’AI aggiunga lavoro invece di ridurlo. Da qui la scelta di due documenti separati.

Durante un incidente attivo, richiedere l’approvazione di ogni singola azione sovraccarica l’analista. Se il team ha costruito e validato l’AI che propone contenimento o triage, un modello con l’umano che monitora e interviene è praticabile.

Il vincolo comune: nessuna azione irreversibile

Entrambi i framework ripetono una regola: l’AI non deve compiere azioni che non si possono annullare. La verifica degli hash può essere automatizzata. Decidere come acquisire dati cloud, come approcciare una scena o come catturare il movimento laterale no, perché un’acquisizione sbagliata preclude l’analisi. Lo stesso vale per l’autorità legale: segnalare un account cloud collegato a un soggetto è utile, raccogliere i dati in autonomia supera un limite che l’esaminatore non può rimediare. Alcuni strumenti forensi possono farlo da soli, se configurati in tal modo.

Per l’autrice la variabile decisiva è il professionista: chi padroneggia la disciplina e vi affianca l’AI crea valore, mentre un operatore inesperto è un rischio che la dirigenza deve valutare con onestà.

Fonte: The Hacker News · Foto: The Hacker News