Articolo Pubblicazioni

NIST SP 800-86 (2006): integrare la digital forensics nella risposta agli incidenti

di · Pubblicato il 16 ottobre 2006

Abstract

Nell’agosto 2006 il NIST ha pubblicato la Special Publication 800-86, «Guide to Integrating Forensic Techniques into Incident Response». La guida porta la digital forensics fuori dai laboratori delle forze dell’ordine e la propone come capacità interna delle organizzazioni. L’articolo descrive il processo in quattro fasi, le fonti di dati, le indicazioni sui sistemi accesi e le raccomandazioni organizzative.

Vincenzo Calabrò | NIST SP 800-86 (2006): integrare la digital forensics nella risposta agli incidenti
 

Perché una guida del NIST

Il National Institute of Standards and Technology pubblica linee guida di sicurezza per le agenzie federali statunitensi, che diventano spesso un riferimento anche per le aziende e per gli altri paesi. Nel 2004 aveva pubblicato la SP 800-61 sulla gestione degli incidenti. La nuova SP 800-86 completa quel documento. Chi risponde a un incidente deve spesso raccogliere ed esaminare dati, e farlo con metodo permette di capire che cosa è successo, di preservare le prove per un eventuale procedimento e di non distruggere informazioni utili.
La guida usa il termine forensics in senso ampio. Comprende l’uso di tecniche forensi per indagini su incidenti, per risolvere problemi operativi, per recuperare dati persi e per verificare il rispetto delle regole. La finalità giudiziaria è una tra le possibili, e questo spiega perché la guida si rivolga alle organizzazioni.

Il processo in quattro fasi

La guida descrive un processo che si ripete per ogni fonte di dati:
  1. raccolta, cioè identificare, etichettare, registrare e acquisire i dati dalle fonti pertinenti, preservandone l’integrità;
  2. esame, cioè elaborare grandi quantità di dati con strumenti automatici e manuali per estrarre quelli di interesse;
  3. analisi, cioè trarre dai risultati dell’esame informazioni utili a rispondere alle domande che hanno originato l’indagine;
  4. rapporto, cioè presentare i risultati, descrivere le azioni compiute, spiegare come sono stati scelti strumenti e procedure e indicare le azioni ancora necessarie.
Il passaggio da dati a informazioni e da informazioni a conclusioni è il filo conduttore. Ogni fase riduce il volume e aumenta il significato.
Sulla fase del rapporto la guida insiste su tre aspetti. Il primo sono le spiegazioni alternative, perché quando le informazioni sono incomplete l’analista deve presentare tutte le ipotesi plausibili e indicare quale sia la più probabile. Il secondo è il destinatario, perché un rapporto per la direzione, uno per l’ufficio legale e uno per gli amministratori di sistema richiedono livelli di dettaglio diversi. Il terzo sono le informazioni utili all’azione, come nuove fonti di dati da raccogliere, vulnerabilità da correggere o regole di rilevamento da introdurre.

Le fonti di dati

Il documento dedica un capitolo a ciascuna famiglia di fonti:
  • file, con indicazioni su copia dei supporti, uso di dispositivi che impediscono la scrittura, calcolo dei message digest, recupero di file cancellati e analisi dei metadati;
  • sistemi operativi, distinguendo dati non volatili, come file di configurazione e log, e dati volatili, come memoria, processi in esecuzione, connessioni di rete e utenti collegati;
  • traffico di rete, con fonti come firewall, router, sistemi di rilevamento delle intrusioni, analizzatori di pacchetti e log dei server, e con le difficoltà legate all’attribuzione degli indirizzi IP;
  • applicazioni, come posta elettronica, browser, messaggistica istantanea, condivisione di file e basi di dati, con i rispettivi file di configurazione, log e dati.

Dati volatili e ordine di raccolta

Per i sistemi accesi la guida riprende il principio dell’ordine di volatilità. Prima si raccolgono i dati che cambiano più rapidamente, come connessioni di rete, sessioni, contenuto della memoria e processi, poi quelli più stabili. Avverte anche che ogni comando eseguito sul sistema ne modifica lo stato, e raccomanda di usare strumenti affidabili portati su supporti esterni e di documentare ogni operazione. La decisione se spegnere il sistema e come farlo va presa caso per caso, valutando il rischio di perdere dati volatili o di attivare meccanismi distruttivi.

Strumenti e verifiche

La guida non raccomanda prodotti specifici. Chiede però che gli strumenti siano scelti e verificati con cura, che se ne conoscano limiti ed effetti sul sistema e che siano tenuti aggiornati. Suggerisce di disporre di un kit di risposta con supporti esterni contenenti programmi affidabili compilati staticamente, dispositivi di blocco della scrittura, supporti puliti per le copie, moduli per la catena di custodia e strumenti per fotografare e documentare. Per l’esame dei dati consiglia di lavorare sempre su copie e di confrontare l’impronta della copia con quella dell’originale.
Un’attenzione particolare va agli aspetti legali. Raccolta e analisi dei dati possono toccare la riservatezza dei dipendenti e dei terzi, e le politiche aziendali dovrebbero informare gli utenti sul possibile controllo dei sistemi. Per un’organizzazione italiana questo significa coordinare le procedure forensi con il Codice privacy e con lo Statuto dei lavoratori, che limita il controllo a distanza dell’attività dei dipendenti.

Le raccomandazioni organizzative

La parte più utile per chi gestisce la sicurezza riguarda l’organizzazione. Il NIST raccomanda queste azioni:
  1. dotarsi di una capacità forense, interna o affidata a terzi, prima che serva;
  2. definire politiche che stabiliscano chi può svolgere attività forensi, in quali circostanze e con quali autorizzazioni;
  3. coinvolgere fin dall’inizio l’ufficio legale, le risorse umane e la direzione;
  4. predisporre procedure e linee guida per le attività più comuni, mantenendole aggiornate;
  5. assicurare che i sistemi producano e conservino i log necessari, con orologi sincronizzati;
  6. formare il personale e mantenere un insieme di strumenti verificati.

Il rapporto con la risposta agli incidenti

Esiste una tensione tra le esigenze di chi deve ripristinare il servizio e quelle di chi deve raccogliere prove. Ripristinare subito un server compromesso cancella le tracce, aspettare troppo prolunga il danno. La guida suggerisce di decidere in anticipo, in base al tipo di sistema e di incidente, quale delle due esigenze prevale e quali dati raccogliere comunque prima del ripristino. È un tema che in Italia, dove la legge 231 del 2001 e il Codice privacy spingono le aziende verso procedure più strutturate, dovrebbe entrare nei piani di sicurezza.
 
Vedi anche: l’articolo del 2002 RFC 3227 e l’ordine di volatilità, l’articolo del 2014 Incident response: le fasi e l’articolo del 2011 ISO/IEC 27035:2011.
 
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