Swappa :: Gestione degli incidenti informatici

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