La copertura non dovrebbe dipendere da un ciclo di versioni del fornitore

C’è un momento, in un esame forense digitale, che nessuno scrive nel manuale di procedura. Un analista apre un’estrazione, trova un’applicazione che non riconosce e controlla se il suo strumento la supporta. Non la supporta. I dati sono lì, presenti per intero, in un database di cui si vede il nome del file. E la risposta alla domanda se si possano leggere è: non in questo trimestre.

Quel momento è di solito trattato come una questione di supporto. Qualcuno apre un ticket. Forse il fornitore lo aggiunge a un arretrato, forse una versione arriva in sei mesi, forse l’applicazione è abbastanza popolare a livello regionale da valere il tempo di un ingegnere e forse non lo è. Nel frattempo sul caso corre un termine di custodia.

Non è una questione di supporto. È una proprietà strutturale del modo in cui il settore ha deciso di lavorare e, una volta visto così, molta della frustrazione quotidiana di un laboratorio risulta avere una sola causa.

La decisione è presa altrove

Ogni strumento di analisi forense di uso corrente funziona allo stesso modo. Qualcuno presso il fornitore ricostruisce per ingegneria inversa il formato di memorizzazione di un’applicazione, ne scrive un parser, lo prova e lo pubblica in una versione. L’analista riceve il risultato di quel lavoro come una capacità.

È ingegneria davvero difficile, e le persone che la fanno sono brave. Il problema non è la competenza. Il problema è che mette la decisione che pesa di più in un esame, quali dati si possano leggere in assoluto, nelle mani di qualcuno che non sa che il caso esiste.

Quella persona sta esprimendo un giudizio commerciale ragionevole. Guarda quanti clienti incontreranno questa applicazione, quanto è stabile il suo formato, quanta ingegneria richiederà. Un’applicazione di messaggistica con duecento milioni di utenti vale ovviamente il lavoro. Una piattaforma sociale regionale con quattrocentomila utenti, concentrati esattamente nella regione in cui opera il Suo gruppo di criminalità organizzata, è un caso aziendale molto più difficile. Dalla posizione del fornitore, rifiutare di implementarla è corretto. Dalla Sua posizione, con l’estrazione in mano, è l’intero caso.

Le versioni sono la metà più grande del problema

Il racconto dell’applicazione non supportata è quello che viene raccontato, ma sottostima la questione. Il fallimento più comune è più sottile: un’applicazione supportata la cui disposizione di memorizzazione è cambiata.

Un’applicazione si aggiorna. Riorganizza una tabella, sposta un file, cambia il modo in cui codifica una data e ora. Il parser è stato scritto sulla versione precedente e ora non restituisce nulla o, peggio, restituisce qualcosa di plausibile e sbagliato. Lo strumento indica l’applicazione come supportata, perché lo è, e l’analista deve accorgersi che l’output è esiguo.

I cicli di versione delle applicazioni si misurano in settimane. I cicli di versione degli strumenti forensi si misurano in mesi. Quel divario non si chiude mai, e non è colpa di nessuno. È aritmetica.

Che cosa costa, nei termini che contano

Il costo di solito non compare come un esame fallito. Compare come una riduzione del perimetro, in silenzio.

Un analista con tre settimane e quaranta sigilli non passa due giorni a leggere a mano un database SQLite sconosciuto con un editor esadecimale aperto accanto, anche se potrebbe. Esamina ciò che lo strumento ha decodificato, scrive il rapporto su quello e annota il resto come non analizzato. È una decisione professionale difendibile. È anche il modo in cui prove che esistono, su un dispositivo che il servizio ha già, in un caso che è già aperto, finiscono per non essere mai guardate.

Moltiplicato per un carico di casi, si ottiene il numero di cui i direttori di laboratorio si preoccupano davvero: la quota dei dati sequestrati che non viene mai esaminata. Non è un fallimento di triage. È un fallimento di copertura che è stato riclassificato come triage.

L’alternativa è scomoda ma semplice

Se il collo di bottiglia è che i parser sono scritti da un fornitore, in anticipo, per le applicazioni che ha scelto, allora la correzione è smettere di esigere che una persona presso un fornitore li scriva in anticipo.

Oggi è tecnicamente fattibile in un modo in cui non lo era cinque anni fa. Riconoscere a che cosa serve un database sconosciuto, che cosa contengono le sue tabelle e come si collegano ai concetti con cui lavora un investigatore, conversazioni, contatti, posizioni, è un compito di ragionamento su percorsi di file, schema e contenuto insieme. È esattamente il tipo di compito in cui i modelli generativi sono insolitamente bravi e i classificatori non lo sono.

L’obiezione ovvia è quella giusta. Non può lasciare che un modello decida come si interpretano le prove e limitarsi a fidarsi del risultato. Quindi non lo faccia. Generi la mappatura, la validi sul piano strutturale, la esegua su un campione dei dati reali e mostri all’analista un’anteprima dei record effettivi prima che si applichi qualsiasi cosa. Se la mappatura ha frainteso la sorgente, è visibile subito, perché l’anteprima è piena di nonsenso. L’analista la accetta, la corregge in un editor visuale oppure la scarta.

Ciò che cambia non è lo standard di prova. L’analista verifica ancora, e nulla entra in un rapporto senza controllo. Ciò che cambia è chi deve fare il lavoro della prima comprensione, e quando può avvenire. Può avvenire il giorno in cui il caso ne ha bisogno, invece che nel trimestre in cui un fornitore l’ha pianificato.

Perché vale la pena dirlo ad alta voce

Ogni laboratorio con cui abbiamo parlato ha una versione della stessa storia, e ciascuno la racconta come se fosse un fastidio locale. Non è locale. È lo stesso vincolo in ogni servizio, in ogni paese, ed esiste per una scelta di architettura che l’intero settore ha fatto presto e non ha mai rivisto.

Nominarlo cambia ciò che si chiede. Un servizio che crede di avere un problema di supporto chiede al suo fornitore versioni più rapide, che è una richiesta che nessuno può esaudire. Un servizio che riconosce un problema strutturale fa una domanda diversa: che cosa servirebbe perché la copertura smetta di essere qualcosa che si aspetta.

È la domanda a cui VERA è stato costruito per rispondere, ed è la ragione per cui preferiremmo sostenere la tesi piuttosto che descrivere il prodotto.