Ascolto e definizione del problema
Si distingue ciò che il cliente ritiene sia accaduto da ciò che può essere verificato tecnicamente. Vengono individuati materiale, periodo, dispositivi, account e domanda da esaminare.
Metodo operativo · Roma
Metodo di lavoro per perizie informatiche e prove digitali a Roma
Il metodo dello Studio Quaranta parte da un principio essenziale: una prova digitale deve essere conservata prima di essere interpretata.
Smartphone, chat, email, file audio, video, fotografie, account e log possono cambiare anche durante operazioni apparentemente normali. Per questo l’attività inizia dalla comprensione del problema, dalla verifica delle fonti e dalla scelta di una procedura proporzionata.
Perché serve un metodo nell’informatica forense?
Una prova digitale può essere fragile. Può essere copiata senza lasciare tracce evidenti, modificata automaticamente, dipendere da un account remoto, cambiare attraverso la sincronizzazione, essere cancellata dalla retention o ricodificata da una piattaforma.
Azioni come aprire, rinominare, inoltrare, convertire o esportare un file possono modificare timestamp, metadati, struttura, compressione, dati temporanei, log e hash.
Un metodo riduce il rischio di alterare il reperto, perdere informazioni, confondere l’originale con una copia derivata, attribuire un’attività a una persona senza elementi sufficienti o produrre una relazione non riproducibile.
ascolto
→ valutazione preliminare
→ conservazione
→ acquisizione
→ verifica
→ analisi e correlazione
→ relazione tecnica
Il metodo Quaranta in sette fasi
Valutazione preliminare
Si verifica fattibilità, urgenza, rischio di perdita, fonti mancanti e limiti già evidenti. La valutazione può anche concludere che il materiale non consente l’accertamento richiesto.
Conservazione
Si evitano modifiche, conversioni, cancellazioni, ripristini e sincronizzazioni non controllate. Vengono identificati i reperti e registrata la catena di custodia.
Acquisizione
La procedura viene scelta in base alla fonte: immagine forense, copia bit-a-bit, file system, acquisizione logica, backup, export cloud o acquisizione web.
Verifica
Si controllano hash, completezza, errori, struttura, segmenti, volumi, versioni e fonti. Un’acquisizione conclusa senza errori visibili può essere comunque incompleta.
Analisi e correlazione
Il quesito guida l’analisi. File, account, dispositivi, timestamp, sessioni, indirizzi IP, log e contesto vengono correlati senza trasformare automaticamente l’associazione tecnica in attribuzione personale.
Relazione tecnica
Vengono documentati incarico, materiale, metodo, strumenti, risultati, interpretazioni, ipotesi alternative, limiti e conclusioni. Ogni allegato tecnico è identificato e, quando opportuno, associato a un hash.
Definizione dell’incarico e autorizzazione all’esame
Prima dell’analisi vengono definiti committente, finalità, autorizzazione, quesito, periodo, reperti, account, fonti incluse e fonti escluse.
Un incarico generico come “analizzare il telefono” non chiarisce quali dati siano pertinenti. Un incarico tecnico può invece delimitare applicazione, interlocutori, intervallo, allegati, cancellazioni da valutare e output finale.
Lo Studio non svolge attività finalizzate ad accedere abusivamente ad account, utilizzare password sottratte, aggirare protezioni di terzi, acquisire cloud personali senza titolo o superare il perimetro dell’incarico.
Conservazione della prova digitale
La conservazione precede l’analisi perché sincronizzazione, aggiornamenti, cancellazione remota, rotazione dei log, utilizzo del supporto e conversione dei file possono cambiare il materiale.
Cosa non fare
- Non formattare o ripristinare.
- Non reinstallare il sistema.
- Non rinominare o convertire gli originali.
- Non esportare ripetutamente le chat.
- Non usare software di recupero sull’originale.
- Non caricare dati riservati su detector pubblici.
Cosa conservare
- File nella forma ricevuta.
- Dispositivo e supporti associati.
- Backup, chat, email e notifiche.
- URL e screenshot del contesto.
- Log e relazioni precedenti.
- Cronologia delle operazioni già eseguite.
Identificazione e catena di custodia
Ogni reperto riceve un codice univoco e viene descritto mediante fonte, stato, seriale, data, soggetto consegnante, modalità di ricezione, dimensione, hash e posizione di conservazione.
La catena di custodia documenta consegna, ricezione, acquisizione, copia, analisi, conservazione e restituzione.
Hash
L’hash identifica la copia esaminata e consente di verificare se due file siano identici a livello binario. Non dimostra chi abbia creato il file, quando sia stato creato, se fosse già stato modificato o se il contenuto rappresenti la verità.
Acquisizione forense e verifica
La modalità di raccolta dipende dalla fonte e dal quesito. Non tutte le acquisizioni offrono lo stesso livello di completezza.
| Fonte | Possibili modalità | Controlli essenziali |
|---|---|---|
| Hard disk, SSD e supporti | Immagine fisica, copia bit-a-bit, file system | Write blocker, log, segmenti, hash |
| Smartphone | Backup, logica, file system, fisica, cloud | Modello, OS, cifratura, errori, completezza |
| Account e cloud | API, export, audit, backup | Ruolo, query, intervallo, paginazione, retention |
| Web e social | Download, screenshot, codice sorgente, video | URL, data, account, contesto, hash |
La copia forense dei supporti, l’acquisizione Android, l’acquisizione iOS, la cloud forensics e l’acquisizione web richiedono procedure differenti.
Originale, copia forense e output derivato
Il dispositivo o file preso in carico è distinto dalla copia acquisita, dalla copia utilizzata per l’analisi e dagli output creati durante il lavoro, come CSV, WAV, screenshot, frame, timeline o report.
Verifica dell’acquisizione
Vengono controllati completezza, leggibilità, hash, errori, dimensioni, struttura, volumi, file mancanti e log. Esempi di criticità sono segmenti E01 mancanti, paginazione API incompleta, database privi di WAL o export limitati dalla retention.
Analisi guidata dal quesito e correlazione delle fonti
L’analisi non consiste nella ricerca indiscriminata di ogni informazione disponibile. Parte da una domanda tecnica verificabile.
Esempio: copia su USB
Possibili fonti: registro Windows, eventi USB, MFT, USN Journal, supporto di destinazione, DLP, sessione utente e timeline.
Esempio: autenticità di una chat
Possibili fonti: database, dispositivo, identificativi, timestamp, allegati, backup, screenshot e secondo dispositivo.
Dati grezzi e report automatici
Quando possibile, il risultato del software viene verificato sul record originario. Il report automatico è utile, ma non sostituisce dato, query, contesto, ragionamento e relazione.
Strumenti, versioni ed errori
Per ogni strumento vengono registrati nome, versione, build, plugin, configurazione, data e sistema operativo. Errori, warning, file non supportati, database corrotti o export interrotti vengono documentati e collegati all’impatto sulle conclusioni.
Account, dispositivo e persona
Un log può documentare un account, un dispositivo, un indirizzo IP, un token o una sessione. Non dimostra automaticamente chi fosse fisicamente presente. Credenziali condivise, accesso remoto, account compromesso, automazioni o malware possono costituire spiegazioni alternative.
Timeline e ipotesi alternative
La timeline forense correla fonti differenti dopo aver verificato timezone, precisione, clock drift, event time e ingest time. La successione temporale non dimostra automaticamente causalità.
Distinzione tra fatti, interpretazioni e deduzioni
| Livello | Esempio |
|---|---|
| Fatto osservato | Nel database è presente il record ID 8452. |
| Interpretazione tecnica | Il record è compatibile con un messaggio inviato. |
| Deduzione ulteriore | La persona indicata ha inviato il messaggio. |
La terza affermazione richiede elementi ulteriori. La relazione deve rendere visibile ogni passaggio inferenziale.
Formule tecniche prudenti
- Nei limiti del materiale disponibile.
- Compatibile o coerente con.
- Non consente da solo di dimostrare.
- Richiede correlazione con ulteriori elementi.
- L’attribuzione personale richiede elementi ulteriori.
- Le fonti non consentono di determinare.
Relazione tecnica, allegati e revisione
La relazione può comprendere incarico, quesito, autorizzazione, materiale, cronologia, metodo, strumenti, risultati, discussione, limiti, risposte, conclusioni e allegati.
Gli allegati possono includere registro reperti, verbali, hash, log, output, CSV, screenshot, database, timeline, query, script e fotografie. Ogni elemento dovrebbe essere identificato e, quando opportuno, associato a un SHA-256.
Prima della consegna viene verificata la corrispondenza con il quesito, la corretta identificazione dei reperti, le versioni degli strumenti, i comandi, le query, i limiti, le conclusioni, gli allegati e la minimizzazione dei dati.
Per approfondire: relazione tecnica, CTP e contestazione delle prove digitali.
Privacy, minimizzazione e collaborazione professionale
Un incarico può esporre chat private, dati sanitari, fotografie, contenuti intimi, credenziali e informazioni aziendali. Il metodo prevede accesso limitato, cifratura, minimizzazione, copie oscurate, separazione degli allegati, conservazione proporzionata e canali idonei.
L’originale non viene oscurato: gli oscuramenti vengono prodotti su copie derivate e documentate.
Quando il caso richiede competenze differenti, il lavoro può coinvolgere avvocati, fonici forensi, esperti video, linguisti, traduttori, medici, grafologi o specialisti di sicurezza, distinguendo attività, output e responsabilità.
Operazioni in contraddittorio
Durante CTU o perizie, reperto, procedura, strumento, operazione e output devono essere comprensibili alle parti. Il CTP può formulare richieste, osservazioni, riserve e proposte di verifica specifiche.
Cosa riceve il cliente e quali limiti restano
In base all’incarico possono essere consegnati indicazioni preliminari, verbali, copie forensi, manifesti hash, estratti, timeline, allegati, relazione tecnica, note critiche o osservazioni alla CTU.
Il metodo non può garantire recupero integrale, identificazione certa della persona, completezza assoluta dei log, rilevazione di ogni manipolazione, autenticità assoluta o esito processuale. Può garantire soltanto una procedura tecnica coerente, documentata e proporzionata all’incarico.
Risorse collegate
Domande frequenti sul metodo
No. Dipende dal quesito. In alcuni casi sono sufficienti il file originario, il database, un export cloud, un messaggio email o i log; in altri il dispositivo è essenziale.
Sì, come immagine. Non sostituisce però necessariamente la fonte originaria e può non consentire di verificare database, account, allegati, cronologia o modifiche.
Sì. È normalmente preferibile lavorare su una copia verificata mediante hash, conservando l’originale separatamente.
Perché software e parser possono cambiare. La versione rende l’analisi identificabile, verificabile e riproducibile.
Perché ogni fonte ha limiti. Dichiararli evita di presentare una conclusione più forte del materiale disponibile.
No. Può servire soltanto a orientare, preservare il materiale, individuare le fonti e decidere se procedere.
No. Ammissibilità e valore probatorio competono al difensore e all’autorità giudiziaria.
Hai bisogno di una procedura tecnica chiara per una prova digitale a Roma?
Lo Studio Quaranta può valutare il materiale disponibile, le fonti da preservare, l’acquisizione più adatta, i rischi di alterazione, le analisi possibili e i limiti.
Evita di modificare dati prima di una valutazione tecnica.
Contatto riservato
Descrivi il tuo caso allo Studio Quaranta
Indica il tipo di materiale, il dispositivo o account coinvolto, il periodo, il problema e le operazioni già effettuate. Non inviare prove sensibili prima di aver concordato un canale idoneo.
Telefono: +39 393 020 9776
Email: info@periziainformatica.legal
Sede: Via Gregorio Ricci Curbastro, 43, 00149 Roma RM