Articolo Pubblicazioni

RFC 3227 e l’ordine di volatilità: le regole per raccogliere le prove digitali

di · Pubblicato il 20 maggio 2002

Abstract

Nel febbraio 2002 l’IETF ha pubblicato la RFC 3227, «Guidelines for Evidence Collection and Archiving», scritta da Dominique Brezinski e Tom Killalea. Il documento raccoglie in poche pagine le regole per acquisire prove da un sistema compromesso. L’articolo spiega l’ordine di volatilità, cioè la sequenza in cui raccogliere i dati partendo da quelli che spariscono prima, i principi generali, gli errori da evitare, la documentazione della catena di custodia e il kit di strumenti affidabili che conviene preparare in anticipo.

Vincenzo Calabrò | RFC 3227 e l’ordine di volatilità: le regole per raccogliere le prove digitali
 

Un documento breve e molto pratico

La RFC 3227, pubblicata dall’Internet Engineering Task Force nel febbraio 2002 con lo status di Best Current Practice, è uno dei pochi riferimenti scritti per chi deve raccogliere prove da un computer. Non è una norma di legge e non entra nei dettagli di un singolo sistema operativo. Il suo valore sta nel metodo, che chiunque si occupi di sicurezza o di indagini può applicare quando un server viene violato e serve capire che cosa è successo senza distruggere le tracce.
Il destinatario tipico è l’amministratore di sistema che scopre un’intrusione. In quel momento la tentazione è spegnere la macchina o ripulirla subito, e così si perdono proprio le informazioni che permetterebbero di ricostruire l’attacco e di identificarne l’autore.

L’ordine di volatilità

Il cuore del documento è l’idea che i dati non hanno tutti la stessa durata. Alcuni esistono solo per pochi nanosecondi, altri restano sul disco per anni. La raccolta deve quindi partire da ciò che scompare per primo. La RFC propone questo ordine:
  1. registri e cache del processore;
  2. tabella di routing, cache ARP, tabella dei processi, statistiche del kernel e memoria;
  3. file system temporanei;
  4. disco;
  5. dati di log e di monitoraggio conservati su sistemi remoti;
  6. configurazione fisica e topologia della rete;
  7. supporti di archiviazione, come i nastri di backup.
In pratica, su una macchina accesa, i primi dati utili da salvare sono le connessioni di rete aperte, i processi in esecuzione con i file che utilizzano, gli utenti collegati e il contenuto della memoria. Spegnere il sistema prima di averli raccolti significa perderli per sempre.

I principi della raccolta

Accanto all’ordine di volatilità, la RFC elenca alcuni principi generali:
  • rispettare le politiche di sicurezza dell’organizzazione e coinvolgere chi ha l’autorità per decidere;
  • catturare un’immagine del sistema il più possibile fedele;
  • annotare ogni operazione, con data e ora, e indicare la differenza fra l’orologio del sistema e l’ora reale;
  • essere pronti a testimoniare su ciò che si è fatto, perché le note serviranno anche mesi dopo;
  • ridurre al minimo le modifiche ai dati, evitando di aggiornare i tempi di accesso ai file;
  • preferire la raccolta all’analisi, che potrà avvenire dopo sulle copie;
  • procedere in modo che ogni passo possa essere ripetuto da altri.

Gli errori da evitare

Il documento è altrettanto chiaro su ciò che non va fatto. Non bisogna spegnere il sistema finché la raccolta non è completata, perché molte prove si trovano in memoria e alcuni programmi malevoli cancellano tracce allo spegnimento. Non bisogna fidarsi dei programmi presenti sulla macchina, che un attaccante potrebbe aver sostituito con versioni modificate per nascondere processi e file. Non vanno eseguiti programmi che modificano i tempi di accesso ai file, e non conviene scollegare subito la rete o reinstallare il sistema, perché l’attaccante potrebbe accorgersene e cancellare le tracce rimaste.

Legalità e riservatezza

La RFC ricorda che le prove devono essere raccolte nel rispetto della legge e della riservatezza delle persone. Chi raccoglie dati non dovrebbe esaminare informazioni a cui normalmente non avrebbe accesso, come la corrispondenza privata, se non nei limiti consentiti. Il documento cita anche le caratteristiche che una prova deve avere per essere utile in giudizio, cioè ammissibilità, autenticità, completezza, attendibilità e credibilità.

La catena di custodia

Per ogni prova raccolta occorre poter dire dove, quando e da chi è stata trovata, chi l’ha maneggiata e dove è stata conservata. La RFC chiede di documentare il passaggio da una persona all’altra e di conservare le prove in modo che l’accesso sia limitato e registrato. Le copie vanno protette con valori di controllo, oggi in genere MD5 o SHA-1, calcolati al momento dell’acquisizione e verificati a ogni utilizzo.

Il kit di strumenti

L’ultima parte riguarda gli strumenti. Poiché i programmi del sistema compromesso non sono affidabili, la RFC suggerisce di preparare in anticipo un supporto in sola lettura, come un CD, con versioni pulite e compilate staticamente dei comandi necessari:
  • un programma per esaminare i processi, come ps;
  • programmi per lo stato del sistema e della rete, come netstat, arp e ifconfig;
  • un programma per copiare bit a bit i dischi, come dd;
  • programmi per generare i valori di controllo e per esaminare i file;
  • uno strumento per acquisire la memoria del sistema.
Preparare il kit prima dell’incidente è la condizione per poter seguire le altre regole. Quando un server è sotto attacco, cercare in fretta un programma affidabile costa tempo e aumenta il rischio di modificare i dati.

Un esempio

Si pensi a un server web aziendale su cui compare una pagina modificata. Seguendo la RFC, l’amministratore annota l’ora in cui se ne accorge e la differenza fra l’orologio del server e un orologio di riferimento. Dal CD con gli strumenti puliti salva l’elenco dei processi, le connessioni aperte, gli utenti collegati e, se dispone di uno strumento adatto, il contenuto della memoria, trasferendo tutto su un altro computer attraverso la rete o su un supporto esterno. Solo dopo isola la macchina e procede alla copia bit a bit del disco, di cui calcola il valore di controllo. I log conservati su un server remoto vengono copiati a loro volta, perché permettono di ricostruire gli accessi anche se l’attaccante ha ripulito quelli locali.

Perché conta per le indagini in Italia

Il nostro codice di procedura penale non contiene ancora regole specifiche sulla raccolta di dati informatici, e la Convenzione di Budapest firmata a novembre 2001 dovrà essere recepita. Nel frattempo la RFC 3227 offre a consulenti tecnici e polizia giudiziaria un riferimento condiviso. Un verbale che segue l’ordine di volatilità, documenta gli strumenti usati e registra i valori di controllo è molto più difficile da contestare di un’acquisizione improvvisata.
 
 
Vincenzo Calabrò | Ingegnere informatico specializzato in sicurezza informatica e investigazioni digitali. Funzionario informatico del Ministero dell'Interno; su incarico autorizzato si occupa di sicurezza informatica e di perizie informatiche forensi. Autore di articoli e saggi. Lecturer, Speaker, Trainer.
Profili: Google Scholar · ORCID · ResearchGate · Academia.edu · CyberSecurity360 · AgendaDigitale · ICT Security Magazine · LinkedIn