Torna alla pagina di Gestione degli incidenti informatici
:: RFC 3227 ::
Linee guida per la raccolta e l'archiviazione di prove
1 Introduzione
Un incidente di sicurezza è un evento di sistema in cui le politiche di sicurezza sono state trasgredite o violate. Nella RFC 3227 vengono suggerite alcune linee guida cui un amministratore di sistema può scegliere di attenersi ai fini di raccogliere e archiviare le prove digitali di incidenti di questo tipo.
Negli ultimi anni le operazioni di ripristino di un sistema compromesso sono diventate sempre più facili, altrettanto non si può dire delle attività di collezionamento di fonti di prova. Questa fase molto sottovalutata è in realtà fondamentale per comprendere le strategie e le tecniche operative di un attaccante, dunque per rendere il sistema più robusto in futuro.
Ultima nota prima di inoltrarci nella RFC: le linee guida ivi descritte non hanno validità giuridica in tutte le giurisdizioni, dunque è raccomandabile richiedere validazione legale dalle forze dell'ordine locali.
Principi guida durante la raccolta di prove
- aderisci alle tue Politiche di Sicurezza e coinvolgi forze dell'ordine e personale dello CSIRT
- cattura l'immagine del sistema nel modo più fedele e accurato possibile
- mantieni annotazioni dettagliate che includano anche data e ora e che siano eventualmente generate in modo automatico
- per ogni timestamp raccolto indica anche l'UTC, così da segnalare il fuso orario del luogo in cui si trova la macchina
- tieni conto che potrai essere chiamato a dare conto delle tue scelte e delle tue azioni anche ad anni di distanza, quindi è vitale che le tue note siano chiare e dettagliate
- minimizza l'alterazione dei dati che stai collezionando, non solo da un punto di vista di contenuto ma anche per quanto riguarda altri attributi come ad esempio i tempi di accesso
- rimuovi le possibili vie esterne di modifica (esterne rispetto la macchina, ovviamente)
- se ti trovassi a dover scegliere tra fare prima la collezione o l'analisi, dai sempre priorità alla collezione
- le procedure che scegli di attuare devono essere implementabili e fattibili, in particolare in una situazione di crisi. Devono dunque essere definite in modo metodico, testate e possibilmente automatizzate
- dato che il tempo è un fattore critico, se hai un gran numero di dispositivi su cui effettuare la collezione di prove potresti organizzare col tuo team una raccolta in parallelo delle evidence, così da massimizzare la velocità. Viceversa, su un singolo dispositivo tali operazioni andrebbero fatte passo passo, in modo sequenziale
- la raccolta deve tener conto dell'ordine di volatilità dei dati (vedi paragrafo successivo)
- dovresti effettuare copie bit-by-bit dei dispositivi del sistema, così da preservare l'integrità dei dati (che in fase di analisi vedrebbero alterati alcuni loro attributi)
2.1 Ordine di volatilità
Quando si raccolgono le prove digitali bisognerebbe procedere da quelle più volatili a quelle meno volatili. A titolo d'esempio, ecco un tipico ordine di volatilità di un sistema comune:
- registri, cache
- tabelle di routing, cache arp, tabella dei processi, statistiche del kernel, RAM
- file temporanei di sistema
- dischi
- log
- configurazioni fisiche e topologie di rete
- dispositivi di archiviazione
2.2 Cose da evitare
Dato che è fin troppo facile distruggere le prove collezionate, vediamo gli errori tipici da evitare.
- non spegnere il sistema prima di aver terminato la raccolta, non solo perché perderesti le prove che stai attualmente recuperando, ma anche perché l'attaccante potrebbe aver modificato l'operazione di chiusura e ripristino del sistema in modo da cancellarne altre
- non fidarti dei programmi installati sul sistema, ma usa i tuoi e falli girare su dispositivi protetti esterni
- non eseguire programmi che potrebbero alterare le informazioni sui tempi di accesso di tutti i file del sistema (ad esempio "tar" o "xcopy")
- quando rimuovi le vie esterne di modifica tieni conto del fatto che la semplice disconnessione della macchina o il filtraggio spartano delle comunicazioni potrebbe far scattare dei meccanismi – introdotti dall'attaccante – per cancellare le prove
2.3 Considerazioni sulla privacy
- rispetta le regole e le linee guida sulla privacy della tua azienda e del tuo sistema giuridico, in particolare assicurati che nessuno che non sia autorizzato possa accedere alle informazioni fornite dalle prove raccolte (log o file personali che siano)
- a meno che tu non abbia ottimi motivi non invadere mai la privacy altrui, soprattutto se stai collezionando informazioni da aree in cui normalmente non avresti accesso (ad esempio file personali)
- assicurati sempre di stare rispettando le procedure stabilite dalla compagnia
2.4 Considerazioni legali
Le prove digitali devono essere:
- ammissibili, cioè devono essere conformi a determinate norme legali perché possano essere usate in tribunale
- autentiche, ovvero bisogna poter dimostrare il collegamento tra il materiale probatorio e l'incidente
- complete, che non tengano cioè conto di un'unica prospettiva ma dell'intero accaduto
- affidabili, dato che non deve esserci nulla che possa dare adito a dubbi sulla loro autenticità o veridicità
- credibili, ovvero che siano allo stesso tempo comprensibili e attendibili per un tribunale
3. La procedura di raccolta
La procedura di raccolta dovrebbe essere descritta nel modo più dettagliato e meno ambiguo possibile, in modo da minimizzare il numero di decisioni da prendere in fase operativa.
3.1 Trasparenza
Il metodo di raccolta delle prove dovrebbe essere trasparente e riproducibile, oltre che testato da esperti indipendenti.
3.2 Passi di raccolta
- elencare i sistemi coinvolti nell'incidente e dire da quali di questi bisognerà raccogliere le prove
- stabilire quali tra queste sono rilevanti ed ammissibili, tenendo sempre conto che è meglio raccoglierne troppe che troppo poche
- tener sempre conto dell'ordine di volatilità
- rimuovere le possibili vie esterne di modifica
- usare gli strumenti di collezione che specificheremo nel capitolo 5
- chiedersi man mano che si procede con la raccolta se c'è qualcos'altro che si può considerare prova
- documentare ogni passaggio
- non dimenticarsi delle persone coinvolte: prendere nota di chi è presente alle varie operazioni, che osservazioni fa, che reazioni ha
Ove possibile è meglio fare uso di checksum e altre firme crittografiche per ogni prova, così da rendere più sicura e robusta la conservazione futura.
4. La procedura di archiviazione
Le prove devono essere assolutamente messe in sicurezza e l'intero inventario (chiamato chain of custody) deve essere documentato.
4.1 Chain of custody
Bisogna descrivere in modo chiaro e preciso come hai trovato la prova, come l'hai utilizzata e qualsiasi altra cosa tu ci abbia fatto. Più precisamente, ecco cosa bisogna specificare:
- dove, quando e da chi è stata trovata e raccolta la prova
- dove, quando e da chi è stata maneggiata o esaminata
- chi ha in custodia la prova, per quanto tempo e come l'ha memorizzata
- come, quando e con quali modalità cambia la custodia
4.2 Dove e come archiviare
Utilizzate se possibile dispositivi convenzionali e non qualche oscuro sistema di archiviazione. L'accesso alle prove deve essere estramamente limitato e monitorato, e in ogni caso sempre documentato.
5. Strumenti di cui hai bisogno
I programmi per la raccolta e l'analisi delle prove digitali dovrebbero girare su supporti di sola lettura (come i CD) ed essere specifici per ogni sistema operativo.
Tra gli strumenti di cui hai bisogno ci sono sicuramente:
- programmi per l'analisi dei processi (ad esempio "ps")
- programmi per l'analisi dello stato del sistema (ad esempio "showrev", "ifconfig", "netstat", "arp")
- programmi per la copia bit-by-bit (ad esempio "dd")
- programmi per generare checksum e firme (ad esempio "sha1sum", "pgp")
- programmi per generare immagini del sistema per poi esaminarle
- script per automatizzare la raccolta di prove
Tutti questi programmi non devono richiedere librerie che non siano già contenute nel supporto, e in ogni caso bisogna sempre testarne l'autenticità e l'affidabilità.
Torna alla pagina di Gestione degli incidenti informatici
