Digital Investigation e Digital Forensic

Torna alla pagina di Gestione degli incidenti informatici

---

:: Digital Investigation e Digital Forensic ::

Definizioni

Le definizioni che seguiranno di Digital Investigation e Digital Forensic sono di Brian Carrier, autore del libro File System Forensic Analysis e sviluppatore del programma di computer forensic The Sleuth Kit e della sua interfaccia Autopsy.

La Digital Investigation è quell'attività in cui vengono sviluppate e testate ipotesi che potrebbero rispondere a domande su determinati eventi digitali, quindi non solo sugli incidenti informatici ma su un qualsiasi oggetto digitale utilizzato. Per Digital Forensic si intende invece un processo che si avvale di scienza e tecnologia per l'analisi di oggetti digitali, sviluppando e testando teorie che possono avere valenza legale. Come si può notare ci sono delle analogie tra le due attività, e in particolare si può dire che la digital forensic è un'investigazione più rigorosa che tiene conto anche degli aspetti legali.

Per capire meglio di cosa stiamo parlando può essere utile fare un esempio su chi sono gli attori tipici dei due processi:

• per la Digital Investigation: le forze dell'ordine, che sulla base delle ipotesi che stanno cercando di dimostrare nel corso delle indagini possono prendere provvedimenti nei confronti dei presunti colpevoli
• per la Digital Forensic: un perito consultato da un'azienda o da un tribunale, dalle cui conclusioni non seguono provvedimenti legali di alcun tipo, dato che questi rimangono di competenza delle autorità giudiziarie

Da notare che in alcuni casi i due ruoli possono sovrapporsi.

Processo Investigativo

Sia la Digital Investigation che la Forensic Analysis hanno un imperativo comune: preservare l'integrità dei dati originali. Detto ciò, l'analisi forense viene comunemente condotta a livello di laboratorio (isolato dall'esterno), così che i processi e le procedure previste possano essere applicate in modo sistematico; nella Digital Investigation invece questa rigorosità non è altrettanto essenziale in quanto lo scopo è verificare delle ipotesi e non ricostruire esattamente i fatti.

Secondo la corrente di pensiero "Carrier/Spafford" il modello del processo investigativo è diviso in sei fasi, che di seguito elencheremo brevemente per studiarle meglio poi nello specifico:

• Notifica
• Preservation
• Survey
• Analysis
• Reconstruction
• Presentation

Notifica

La notifica è il momento in cui viene segnalato un incidente informatico alle figure interessate, che ciò avvenga per via telefonica, sistemi di allarme o altro. Da questo momento parte il processo investigativo, che può aver bisogno di un'autorizzazione a procedere e in alcuni casi anche di una conferma del reale accadimento dell'incidente. Il tutto deve essere ovviamente certificato con una serie di documenti, e ovviamente anche nella Timeline (la tabella dei tempi che vedremo meglio nella pagina di Strumenti di investigazione e forensic).
Il tecnico che riceve la notifica non può rifiutarsi di avviare le indagini, ma qualora si ritenesse che questi non abbia le competenze adatte per portarla avanti, può essere sollevato dall'incarico.

Preservation

La preservation prevede la duplicazione dell'intero ambiente operativo di una scena digitale, così che possa essere facilmente riproducibile e utilizzabile in laboratorio senza che sia alterato l'originale; va da sé che quest'ultimo deve essere custodito e preservato per tutta la durata dell'indagine. Durante questa fase vanno prese alcune precauzioni, come isolare il sistema dalla rete esterna, rispettare l' ordine di volatilità delle informazioni, avere particolare attenzione per tutti i file di log, prendere nota di eventuali processi o servizi sospetti in esecuzione.

Per quanto riguarda le memorie fisiche la preservation viene garantita effettuando una o più copie bit-by-bit, mentre per il traffico di rete vengono utilizzate sonde di livello ISO/OSI 3 (quello di trasporto), chiamate sniffer.

Anticipiamo qui l'importanza della correlazione (corroboration) delle fonti di prova per dare maggiore validità alla conclusioni dell'analisi. A tal proposito era stato citato in classe il caso di presunta pedopornografia di una studentessa di Pisa, rivelatosi poi infondato confrontando più evidence.

Survey

Il survey è un insieme di attività generali finalizzate alla ricerca delle fonti di prova (digital evidence). Dovrebbe essere svolta in laboratorio e possibilmente sulle copie prodotte nella fase precedente, ma può capitare che per motivi di urgenza si debba ricorrere a una Live System Analysis (LSA) sul sistema originale. E' un passaggio molto importante della digital investigation poiché consente alle forze dell'ordine di confermare alcune ipotesi e prendere se necessario provvedimenti giudiziari.

Nel survey si capisce se chi effettua l'indagine è una persona adatta al compito dal momento che in questa fase emergono le abilità e competenze (skills) di chi ha commesso la violazione.

Analysis

Durante l' Analysis le informazioni vengono esaminate minuziosamente, così che si possano tracciare delle conclusioni corroborate dalle prove raccolte. Questa fase deve essere condotta in laboratorio perché impone maggior rigore nella procedura rispetto al survey; deve infatti garantire la ripetibilità dei risultati, l'applicazione del metodo scientifico per la verifica delle ipotesi e l'utilizzo di un metodo iterativo di validazione.

Pur essendo prevalentemente ad appannaggio della forensic, questa fase può essere molto utile anche per il comparto investigativo con cui si sta cooperando (o si coopererà). Bisogna dunque documentare nella timeline tutto quello che è stato fatto e che si sta facendo, ad esempio telefonate in entrata e uscita, nuove fonti acquisite, pause fatte, etc...

Chi si occupa dell'analysis è chiamato anche Forensics Examiner, ed è una persona che deve avere certificazioni in campo informatico rilasciate da organismi conosciuti come il SANS institute o il Cisco, oppure dagli sviluppatori di software di computer forensic.

Reconstruction

La reconstruction ha sia una componente di analisi che di investigazione ed ha lo scopo di mettere insieme tutti gli indizi raccolti così da costruire una visione di insieme dell'accaduto. Ovviamente non tutte le prove vanno considerate allo stesso modo, ma ognuna delle digital evidence deve essere classificata in base ad un trust level (livello di fiducia) ovvero al peso della prova stessa. Ad esempio un log di cui non conosco la fonte potrebbe avere peso 1, ma il suo trust level potrebbe aumentare se riesco a correlarlo ad altre fonti e altri log.

Anche in questa fase viene utilizzato il metodo scientifico per avvalorare o meno le teorie basate sulle fonti di prova raccolte in un modo molto simile a quanto avveniva nell'analysis.

Presentation

Concludiamo con la presentation, ovvero la fase in cui avviene la presentazione delle digital evidence ai vari attori del processo investigativo, investigatori esterni compresi.

Presentation e reconstrucion sono entrambe multi-livello: si mantiene un livello più alto di carattere generale per le decisioni rapide (che si interfaccia ad esempio col management) ed uno più basso con le descrizioni tecniche dell'accaduto.

E' buona abitudine inserire in ogni rapporto anche un glossario con i termini usati, in quanto non si conosce a priori il grado di preparazione di chi lo legge ed è meglio non dare nulla per scontato. Più la relazione è semplice e chiara e minore è il numero di fraintendimenti possibili.

Aspetti legali dell'investigazione

Nella gestione degli incidenti informatici non si può prescindere dal contesto legale poiché non esiste processo (task) che non abbia una rilevanza o un riscontro di tale tipo. Va infatti considerato che (dalle slide di Dario Forte, 2008):

• "Ogni incidente ha un potenziale sbocco giudiziario"
• "La tutela legale è di interesse in azienda"
• "Esistono delle responsabilità ben precise che cadono sugli operatori e sui rispettivi supervisori di processo", e ci possono volere anche 3 anni prima di avere una ripercussione visibile

La regola numero uno è trattare ogni incidente come se dovesse terminare in un'aula di tribunale, cosa da far sempre presente anche se dall'alto dicono che non si devono prendere certe precauzioni (come il fare un'immagine del disco, ad esempio). Il decreto legge n.231 dell'8 giugno 2001 introduce infatti l'obbligo di dover rispondere come persona giuridica per i reati commessi all'interno della propria struttura, il che significa che si ha sempre la responsabilità delle proprie azioni.

Facciamo un esempio pratico: le forze dell'ordine mi chiedono di acquisire delle prove che mi hanno portato, cosa devo fare?

1. Notificare l'acquisizione (firma, controfirma, fotografie, ...)
2. Verificare le fonti della prova, anche attraverso il controllo di sigilli fisici o virtuali (hash)
3. Chiedere se le prove consegnate sono già delle copie o sono gli originali
4. Se infine mi rendo conto che le prove sono inquinate o comunque in uno stato tale per cui potrebbero portarmi in tribunale a risponderne, posso rifiutarmi di acquisirle a patto di documentarne la motivazione

Ci sono degli standard investigativi da tenere in considerazione per poter analizzare l'evento e trarne conclusioni valide. Un investigatore che si occupa di crimini informatici deve saper consultare il codice penale e quello di procedura penale, sapere come operano le forze dell'ordine e l'autorità giudiziaria, e conoscere inoltre la differenza tra procedibilità d'ufficio (quando l'azione penale parte senza denuncia) o a querela. In ambito civile la rigidità scientifica della prova è minore di quella penale, anche se storicamente sta diventando altrettanto schematica e rigorosa. Infine, per quanto riguarda le indagini amministrative, queste vengono generalmente condotte come se fossero penali poiché spesso sfociano in esse; nell'amministrativo l'investigatore deve considerare tra le altre cose eventuali incompatibilità con lo statuto dei lavoratori o con la legge sulla privacy.

Cosa serve allora a un investigatore per condurre indagini di tipo investigativo o forense? Innanzitutto un minimo di conoscenze di criminologia, poi sicuramente le leggi (tenendo conto del fatto che se stiamo operando all'estero siamo vincolati e legalmente punibili con le norme di quel paese), nozioni di base sull'analisi dei log e dei computer delle vittime, e infine strumenti di case management e forensics.

Concludiamo con una serie di definizioni correlate all'aspetto legale della gestione degli incidenti informatici:

• Tainted Fruit: sono le fonti di prova acquisite in modo improprio (tainted significa infatti contaminato), ovvero con violazioni della privacy o della legge; ad esempio potrebbero essere le intercettazioni abusive. Queste prove non possono essere utilizzate in tribunale, ma è pratica comune raccoglierle e tener comunque conto dei risultati ai fini dell'indagine; va ricordato infatti che attualmente ci sono due trend di incident response: Difesa Offensiva e Investigazione non Denunciata;
• Chain of custody: è l'inventario delle fonti di prova acquisite durante l'investigazione o la forensic. Ogni evidence deve essere sigillata, fisicamente o elettronicamente;
• Subpoena: è l'equivalente americano del decreto del pm o ordine di esibizione dell'agente giudiziario. Potrebbe prevedere una testimonianza del perito nel paese estero che l'ha richiesto, e va detto che pur non essendo obbligatorio - si tratta comunque di una richiesta - un rifiuto potrebbe avere ripercussioni sulla carriera dell'investigatore.

Forensic Readiness

La forensic readiness è il processo imprescindibile di preparazione alle indagini digitali, grazie al quale è possibile stabilire se si è pronti all'incident response e alla digital investigation.

La prima fase riguarda l'osservazione degli assesment:

1. fare l'inventario degli asset
2. localizzare la posizione fisica delle informazioni e studiare la loro struttura;
3. identificare i punti in cui le informazioni possono essere attaccate

Fatto ciò rimangono altre attività preliminari da portare a termine. Per prima cosa bisogna verificare la presenza di piani di Disaster Recovery per far fronte ad eventi gravissimi (come terremoti, alluvioni, fulmini, ...) o furti, poiché l'integrità fisica delle fonti di prova va sempre messa in primissimo piano. Il passo successivo è quello della pianificazione della fase di preservation, anche attraverso la creazione e il mantenimento di un inventario che consenta allo stesso tempo di sapere quali dispositivi/strumenti abbiamo a disposizione e di non perderne nessuno.

In un contesto aziendale l'operatore è la figura che rischia più di tutti per le sue mancanze ("i manager cadono sempre in piedi"), dunque gli conviene essere veloce, lineare e corretto. Per la velocità - come detto più volte - più si è preparati e minore è il tempo di risposta all'incidente, mentre per quanto riguarda la correttezza il principio è non fare niente senza prima aver consultato la legge e gli assesment aziendali. Una buona pratica per l'operatore è considerare e mantenere la propria rete come se fosse una "Source of Evidence", all'interno della quale garantire sempre l'integrità e l'affidabilità delle informazioni.
In ogni caso, se la situazione degenera vige il Don't Panic, ovvero non bisogna disperarsi ma si deve chiedere istruzioni e consigli all' helper (se esiste) o chi per esso (se non esiste, PANIC!).

Una preparazione inadeguata può portare a problematiche di vario tipo, tra cui: negligenze o sbagli, acquisizioni di evidence in modo illecito (tainted fruit), fuga di informazioni e conclusioni affrettate e/o errate.

Approfondimenti

Acquisizione

Abbiamo detto che la fase di preservation ha come obiettivo quello di preservare le fonti di prova acquisite, così da poter garantire l'integrità dei dati da analizzare; questo tipo di acquisizione (detta logica) è eseguita nel rispetto dei capisaldi dell'indagine forense, tenendo ad esempio conto degli ordini di volatilità dell'informazione. Si rivela dunque fondamentale un processo di validazione che attesti la genuinità dei dati, validazione che può avvenire internamente al laboratorio o esternamente ad opera di una comunità o altra parte certificata.

Ci sono tuttavia dei casi in cui l'acquisizione non è praticabile, dunque diventa difficile - se non impossibile - garantire la preservation. Vediamone alcuni:

• file system troppo grandi per poter essere duplicati
• file system non riconosciuti dagli strumenti di analisi adoperati (ad esempio Lotus Notes dà spesso problemi di questo tipo)
• "casi contingenti di procedura penale" (ad esempio la Convenzione di Budapest) o "eventi esogeni" (come sfortuna o urgenze diverse)
• Live System Analysis, cui spesso si ricorre per la verifica iniziale e la risposta immediata all'incidente

Come cercare di tutelare le fonti di prova in questi casi? Ad esempio utilizzando dispositivi come gli hardware write blocker, che impediscono l'accesso in scrittura sui media su cui intervengono facendo sì che i dati originali non siano mai alterati. L'accesso in read-mode sui dati viene anche chiamato preview. Ci sono versioni diverse di questi dispositivi, a seconda dell'interfaccia supportata (SCSI, SATA, ..) e della modalità di interfacciamento col computer (USB, IDE, Firewire, ...); il loro costo varia dai 300 ai 1500 euro.

Quando si ha più tempo a disposizione per l'intervento la preservation delle fonti di prova viene garantita con la duplicazione dell'ambiente lavorativo della macchina compromessa. A tal fine esistono molti strumenti di clonazione (o imaging) software-based anche open-source come il diffuso dd, che in alcune versioni consente di: estrarre il layout del media da acquisire, effettuare il wipe (cancellazione definitiva) del disco su cui caricare la copia per evitare di inquinare le prove, e generare hash (MD5 o SHA1). Quest'ultima opzione è insieme al CRC (Controllo Ciclico di Ridondanza) fondamentale per il controllo dell'integrità.
Esistono inoltre numerosi dispositivi hardware di clonazione anche detti "a pistola" (gun) perché in un certo senso ne simulano il comportamento (premi il grilletto ed entrano in azione. Mah). Tra i loro vantaggi ci sono una maggiore automazione, aggiornabilità e rapidità di esecuzione; per contro invece richiedono esperienza, conoscenza delle nozioni di base, e in alcuni casi della validazione da parte della comunità (ad esempio dal NIST, National Institute for Standard and Technologies).

Obiettivi dell'investigazione

Abbiamo già visto in questo capitolo molti degli obiettivi di un'investigazione digitale, proviamo ad elencarli tutti (o almeno, buona parte) come attività di ripasso:

• raccogliere il maggior numero di fonti di prova possibile relative all'incidente
• verificarne l'integrità
• cautelarle, conservandole in luoghi sicuri e protetti
• cercare il più alto numero di correlazioni possibile con altre evidence
• sviluppare il profilo dell'intruder attraverso l'analisi della scena del crimine. Bisogna in altre parole capire come questi ha ottenuto l'accesso e che tipo di danno ha fatto; ci si potrebbe anche chiedere quali siano le sue motivazioni, ma fino a un certo punto dato che di questo si occupa la criminologia
• ricostruire una timeline degli eventi collegati all'incidente
• documentare con precisione il danno causato, perché questo farà risparmiare tempo in caso di consulta o presentazione in tribunale
• collaborare con le forze dell'ordine o interpellare l'autorità giudiziaria ove necessario

Ricostruzione dell'incidente

La ricostruzione dell'incidente è un'attività molto importante per diversi motivi. In primo luogo permette di chiarire la dinamica degli eventi e di valutare il livello di esposizione del sistema a vulnerabilità e rischi legali. Notare come questi due aspetti siano fortemente correlati: meno il sistema è aggiornato, maggiori sono i rischi di exploit e più siamo esposti legalmente. Certo questo discorso non vale in generale, non ad esempio per quei sistemi che se patchati perderebbero alcune librerie di cui hanno bisogno; queste eccezioni vanno però motivate attraverso un'attenta analisi del rapporto rischio/benefici, così che sarà poi il management ad assumersene le responsabilità.
In secondo luogo la ricostruzione è utile per scoprire le vie d'ingresso sfruttate dall'intruder per l'accesso al sistema e per mettere in luce eventuali errori di configurazione, così che si possa allo stesso tempo evitare che l'incidente si ripeta in futuro (lesson learned) e comunicare il pericolo a chi ha macchine simili.

Ci sono tre tipi diversi di ricostruzione dell'incidente:

• ricostruzione fisica, che prevede la creazione di un mirror del computer compromesso: stesso hardware, stesso software, immagine del disco bit-by-bit. E' l'opzione più rapida e fedele dato che fornisce l'esatta copia dell'ambiente in cui si è verificato l'incidente; per gli stessi motivi è però difficilmente realizzabile, dato che assemblare un sistema identico a quello in analisi non è così semplice
• ricostruzione logica, che fa uso ad esempio di macchine virtuali. Permette una ricostruzione più agevole di un maggior numero di macchine, ma i risultati possono essere fuorvianti dato che una macchina virtuale non ha lo stesso comportamento di una reale (diverse prestazioni, diverse modalità di chiamate di funzione, ...). La ricreazione del sistema "from scratch" è un caso particolare di ricostruzione logica, che richiede la ricreazione di una serie di servizi di base per far funzionare il sistema da analizzare
• ricostruzione teorica, l'ultima spiaggia se non si può accedere direttamente ai computer coinvolti nell'incidente

Ultima nota: durante la ricostruzione è possibile riconoscere i ruoli che hanno avuto le macchine coinvolte nell'incidente, distinguendo tra target (o end point, gli obiettivi finali dell'attacco) e teste di ponte (macchine compromesse per comprometterne altre).

Correlazione e chaining

La correlazione e il chaining sono due attività fondamentali dell'investigazione perché consentono di comprovare che le tesi dimostrative da noi formulate sono basate su ipotesi fondate. In particolare durante la correlazione vengono relazionate le prove digitali raccolte in fase di acquisizione, mentre nel chaining vengono concatenati gli eventi occorsi durante l'incidente, così da confermare l'attendibilità delle evidence e aumentarne il peso in fase dimostrativa.

Più correliamo e concateniamo e più siamo in grado di capire la dinamica di ciò che è successo. Bisogna perciò cercare il maggior numero di punti di correlazione possibili, anche se si trovano al di fuori del nostro perimetro investigativo; vanno quindi considerate anche le trust relationship, ovvero quei sistemi o piattaforme simili o omogenei a quelle di nostra competenza, e tutte le connessioni temporanee o permanenti riconducibili alla macchina compromessa (così da tener conto anche di eventuali teste di ponte). Per quanto riguarda le trust relationship alcuni esempi da verificare sono:

• sistemi che appartengono allo stesso range di indirizzi IP, perché oggetto di studio approfondito da parte degli attacker per scoprirne le vulnerabilità
• sistemi con almeno un servizio in comune con il sistema vittima (come l'FTP, il DNS o l'SMTP)
• sistemi che si trovano nello stesso segmento di rete, perché se ad esempio l'attacco è stato sferrato a un router potrebbero essere stati a loro volta compromessi
• sistemi che si trovano nello stesso dominio trusted, perché l'attaccante può mascherarsi da uno di questi per ottenere l'accesso autorizzato alla macchina
• sistemi che hanno lo stesso sistema operativo
• sistemi che condividono file o informazioni, perché se tale condivisione è mal configurata potrebbe consentire un accesso da remoto non desiderato

Come detto in precedenza la correlazione si opera sui vari tipi di evidence raccolti, riconducibili a tre categorie fondamentali:

• host level, ad esempio effettuando una live analysis, una file system analysis o una binary analysis
• service level (livello di servizio), che esamina il comportamento del servizio ad esempio con l'ausilio della log analysis
• network level, che all'analisi dei log affianca la network forensic

Correlare i vari tipi di evidence tra loro è fondamentale per ricostruire esattamente gli eventi durante l'intrusione e prima e dopo la compromissione. Riportiamo un esempio esaustivo di tale attività dalle slide del professor Dario Forte: "E' ad esempio possibile risalire alla compromissione del sistema analizzando i logi di un servizio vulnerabile; correlando l'ora dell'avvenuto exploit presente nei log con i timestamp di creazione dei file prodotti nella parte di analisi del file-system è possibile tracciare eventuali file creati nel sistema a seguito dell'intrusione. Inoltre mediante la revisione delle registrazioni delle conversazioni di rete e dei log degli apparati è possibile concludere che i binari installati sul sistema procedevano alla ricerca di nuovi bersagli da attaccare; tale affermazione può venire confermata da una successiva analisi dei binari stessi. Nel caso si fosse proceduto ad una fase di live-analysis sul sistema è possibile che vi sia la presenza di tali processi attivi sul sistema, confermati da eventuali porte di rete aperte."

Riconsideriamo ora l'event chaining, ovvero quell'attività di basso livello che consiste nel chiarire la catena degli eventi occorsi ricostruendo lo scenario. Gli eventi da considerare possono essere sia a livello di log che di file system e non è necessario che siano direttamente connessi all'attacco; ad esempio va tenuto conto anche delle cancellazioni di possibili file di prova. Più precisamente ciò che si fa è formulare una prima ipotesi a fronte delle evidence acquisite, dopodiché si riproduce a livello di laboratorio l'attacco così come ipotizzato in modo che l'ipotesi possa essere o meno confermata; in caso negativo si fa un rollback e si procede a formulare una seconda ipotesi.

---

Torna alla pagina di Gestione degli incidenti informatici