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 più dire che la digital forensic è un'investigazione più rigorosa che tiene conto anche degli aspetti legali.

* ''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
* ''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

La '''notifica''' è il momento in cui viene segnalato un incidente informatico alle figure interessate, che sia 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 nei prossimi capitoli).\\

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 dovrebbe 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'.

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 sono: sistemi che appartengono allo stesso range di indirizzi IP, sistemi con almeno un servizio in comune con il sistema vittima, sistemi che si trovano nello stesso segmento di rete, sistemi che si trovano nello stesso dominio trusted, sistemi che hanno lo stesso sistema operativo e sistemi che condividono file o informazioni.

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).

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

Il tecnico che riceve la notifica non potrebbe rifiutarsi ad avviare le indagini, ma nel caso in cui non avesse le competenze per quanto richiesto potrebbe essere sollevato dall'incarico.

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 analysis'' 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.

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.

* '''Subpoena''': è l'equivalente americano del ''decreto del pm'' o ''ordine di esibizione dell'agente giudiziario''. Due osservazioni sul subpoena:
** Potrebbe prevedere una testimonianza del perito nel paese estero che l'ha richiesto;
** Non è obbligatorio, è solo una richiesta, ma un rifiuto potrebbe avere ripercussioni sulla carriera dell'investigatore.

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 dovrebbe sempre garantire l'integrità e l'affidabilità delle informazioni.\\

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

* cautelarle (fondamenale)

* 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 potrebbero essere le sue motivazioni, ma fino a un certo punto dato che di questo si occupa la criminologia

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 assumersi le responsabilità.\\

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 dell'attacco) e '''teste di ponte''' (macchine compromesse per comprometterne altre).

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 di 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; notare che gli eventi possono essere sia a livello di log che di file system e che non è necessario che siano direttamente connessi all'attacco (ad esempio la modifica o la cancellazione di alcuni 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.

* ''Digital Forensic'': un perito consultato da un'azienda o da un tribunale, dalle cui conclusioni non seguono provvedimenti legali di alcun tipo, che rimangono di competenza alle autorità giudiziarie

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 è fondamentale 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 poi studiarle più nello specifico:

La '''notifica''' è il momento in cui viene segnalato un incidente informatico alle figure interessate, che sia 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 in una serie di documenti, e ovviamente anche nella Timeline (la tabella dei tempi che vedremo meglio nei prossimi capitoli).\\
Il tecnico che ha ricevuto la notifica non potrebbe rifiutarsi di avviare le indagini, ma nel caso in cui non avesse le competenze per quanto richiesto potrebbe essere sollevato dall'incarico.

La '''preservation''' prevede la duplicazione dell'intero ambiente operativo di una scena digitale, così che possa essere facilmente riproducibile e utilizzabile in laboratorio senza alterare l'originale; va da sé che quest'ultimo dovrebbe essere custodito e preservato per tutta la durata dell'indagine. Durante questa fase vanno prese alcune precauzioni, come l'isolare il sistema dalla rete, 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.

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 il caso di presunta pedopornografia di una studentessa di Pisa, rivelatosi poi infondato confrontando più evidence.

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 analysis sul sistema originale. E' una fase molto importante nella digital investigation, poiché consente alle forze dell'ordine di confermare alcune ipotesi e prendere se necessario provvedimenti giudiziari.

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 per la computer forensic.

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 lo correlassi ad altre fonti e altri log.

Presentation e reconstrucion sono entrambe multi-livello: 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.

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 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.

# Inventario degli asset
# Localizzare la posizione fisica delle informazioni e studiare la loro struttura;
# 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 è un elemento da tenere sempre 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.

!!! Preservation & 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, e 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 è possibile, dunque diventa difficile - se non impossibile - attuare la preservation. Vediamone alcuni:

* "casi contingenti di procedura penale o eventi esogeni", ad esempio nel primo caso la ''Convenzione di Budapest'' e nel secondo fattori come sfortuna o urgenze diverse

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 questo proposito 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 base, e in alcuni casi della validazione da parte della comunità (ad esempio dal '''NIST''', ''National Institute for Standard and Technologies'').

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

* cautelarle, obiettivo fondamentale. Come farlo l'abbiamo visto nel paragrafo precedente
* cercare il più alto numero di correlazioni possibili con altre evidence
* sviluppare il profilo dell'intruder attraverso l'analisi della scena del crimine. Bisogna in altre parole capire come l'attacker ha ottenuto l'accesso e che tipo di danno ha fatto; ci si potrebbe anche chiedere quali potrebbero essere le sue motivazioni, ma fino a un certo punto dato che di questo si occupa la criminologia

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 tra loro correlati: meno il sistema è aggiornato, maggiori sono i rischi di exploit, 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 assumersi le responsabilità.\\

* '''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 poi si avrebbe a disposizione l'esatta copia dell'ambiente in cui si è verificato l'incidente; per gli stessi motivi è però difficilmente realizzabile, dato che assemblare un sistema con gli stessi hardware 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: installazione e configurazione di sistema e servizi

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 dell'attacco) e '''teste di ponte''' (macchine compromesse per comprometterne altre, quindi non sono target finali).

* '''ricostruzione fisica''', che prevede la creazione di un mirror del computer compromesso: stesso hardware, stesso software, immagine del disco bit-by-bit. E' una tecnica perseguibile solo se è unica (o comunque molto poche) la macchina da ricostruire
* '''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, ...)

!!!Validazione dei toolkit
Tra le attività di gestione del laboratorio di investigazione una delle più importanti riguarda la ''validazione degli strumenti'', la '''tool validation'''. Può essere ''interna'' quando è svolta in laboratorio ed è frutto di un processo di verifica; ad esempio dopo aver scaricato una iso ne verifico gli md5 per vedere se è corrotta, faccio una serie di test standard e verbalizzo tutto. Se è invece effettuata da terze parti [@trusted@] viene chiamata ''esterna''; ad esempio [@PTK@] è validato sia in laboratorio con test di configurazione, sia dalla comunità con test sullo strumento stesso. In entrambi i casi, vengono spesso utilizzati strumenti di testing creati appositamente, chiamati '''DFTT''' (''Digital Forensics Testing Tool'').

Ultima considerazione va fatta sulle validazioni esterne fatte da organismi come il ''NIST'', che hanno la caratteristica di avere la [@Recognition in Court@], ovvero sono attestati e accertati in tribunale in quanto la loro validità ha riconoscimento giudiziario.

!!Strumenti operativi
Gli '''strumenti operativi''' (o ''standard operativi'') sono quelli utilizzati dal response team per la gestione degli incidenti informatici. Gli strumenti più diffusi di ''Incident Management'' permettono di seguire l'intero corso dell'incidente e generare report compatibili con i più rigorosi standard internazionali; inoltre consentono di effettuare un'attenta analisi economica dei danni, considerando gli asset coinvolti, le ore uomo impiegate (o sprecate) e altri costi collaterali (spese legali, recupero marketing, ...).

Vediamo quali features dovrebbe avere un software di questo tipo:

* '''Report''' dettagliato con tutte le informazioni relative all'incidente e rispettoso dello standard '''IODEF'''. Lo IODEF è un metalinguaggio basato su XML il cui standard si trova su [@ietf.org@] e che garantisce univoca interpretazione e portabilità del report. E' estendibile con moduli aggiuntivi certificati, purché rispettino i prerequisiti e non creino dipendenze
* '''Timeline''' (''tabella dei tempi''), una sorta di log in cui viene preso nota di tutto ciò che accade nel sistema e di tutte le operazioni effettuate dagli investigatori. Deve consentire un certo margine di personalizzazione, ad esempio dando la possibilità di aggiungere informazioni sul nome dell'utente che ha generato un evento
* '''Analisi Grafica''' delle statistiche relative all'incidente e agli impatti monetari conseguenti
* '''Allegati''', ad esempio lettere pervenute dalla polizia giudiziaria, log, file di configurazione, ...
* '''Ricerca''', fondamentale per verificare se l'incidente informatico in analisi ha analogie con altri
* '''Dashboard''', che visualizza un riepilogo delle principali informazioni legate al caso presenti nel database
* '''Sistema di Messaggistica Separata''' per evitare compromissioni
* '''Modulo Supervisor''' che gestisce gli utenti, assegna i task, garantisce la comunicazione tra operatori e controlla la dashboard
* Possibilità di '''inviare e ricevere report esterni'''