Gli errori possono essere innocui, circoscritti o decisivi; occorre stabilire quali aree o database siano stati interessati.
In informatica forense il valore di un risultato non dipende soltanto dallo strumento utilizzato, ma dalla possibilità di descrivere la sorgente, il metodo, i limiti e il percorso logico che conduce dal dato alla conclusione. Questo articolo propone una procedura utilizzabile come base di lavoro e come criterio di lettura critica.
Che cosa significa dal punto di vista forense
Gli errori possono essere innocui, circoscritti o decisivi; occorre stabilire quali aree o database siano stati interessati.
La prima operazione consiste nel definire con precisione il quesito. Una ricerca priva di perimetro tende a produrre grandi quantità di dati difficili da interpretare; un quesito ben formulato individua invece periodo, soggetti, dispositivi, account, eventi e grado di certezza richiesto.
Occorre inoltre distinguere il dato osservato dall’artefatto decodificato dal software, l’artefatto dall’inferenza e l’inferenza dalla conclusione. Questa separazione rende la relazione più trasparente e permette alla controparte di verificare il ragionamento tecnico.
Quali fonti devono essere esaminate
Le fonti principali da prendere in considerazione comprendono:
- log degli errori
- settori o file non letti
- database incompleti
- hash e dimensioni
- tentativi alternativi
La disponibilità effettiva di tali fonti dipende dalla versione del sistema operativo, dalla configurazione, dalla profondità dell’acquisizione, dalla retention e dagli strumenti impiegati. L’assenza di un elemento non deve essere interpretata automaticamente come assenza dell’evento.
Metodo operativo di analisi
Una procedura ordinata può essere articolata nei seguenti passaggi:
- classificare l’errore
- localizzare l’impatto
- ripetere se possibile
- usare tecnica alternativa
- dichiarare il limite
Durante ogni passaggio è opportuno conservare i riferimenti agli artefatti sorgente, annotare gli strumenti e le versioni, normalizzare i timestamp e registrare le operazioni che possono avere modificato lo stato del sistema.
Che cosa può dimostrare
- la presenza di specifici artefatti
- la coerenza temporale tra più eventi
- la provenienza tecnica del dato quando la sorgente è disponibile
La forza della conclusione aumenta quando più sorgenti indipendenti convergono sullo stesso evento e quando la ricostruzione è coerente con fonti esterne, verbali, log server, immagini, dati del veicolo o ulteriori dispositivi.
Che cosa non deve essere dedotto automaticamente
- non attribuisce automaticamente l’attività a una persona
- non sostituisce la valutazione del contesto
- dipende da versione, configurazione e completezza dell’acquisizione
Esempio di impostazione della ricostruzione
Una conclusione robusta nasce quando più fonti indipendenti descrivono la stessa sequenza senza contraddizioni rilevanti.
Interpretazione tecnica: spiegare il significato dell’artefatto e le condizioni necessarie.
Correlazione: riportare le fonti indipendenti che confermano o contraddicono l’ipotesi.
Conclusione: usare una formulazione proporzionata, distinguendo compatibilità, elevata probabilità e attribuzione certa.
Come documentare il risultato
La relazione dovrebbe specificare almeno:
Reperto, copia, account o servizio da cui deriva il dato.
Strumenti, versioni, query, filtri e operazioni eseguite.
Formato originario, timezone, conversioni e possibili scarti.
Controlli sul sorgente e riscontri indipendenti.
Dati mancanti, retention, cifratura, errori e ipotesi alternative.
Separazione tra fatto, inferenza e conclusione.
Conclusioni
Gli errori possono essere innocui, circoscritti o decisivi; occorre stabilire quali aree o database siano stati interessati.
La metodologia più affidabile non cerca una risposta immediata in un singolo artefatto. Costruisce invece una catena verificabile: sorgente, evento, tempo, identità, contesto e riscontro. È questa struttura a rendere il risultato comprensibile, ripetibile e utilizzabile nel confronto tecnico.
