|
Wiki
UniCrema
Materie per semestre
Materie per anno
Materie per laurea
Help
|
|
Uni.RFC3227 History
Hide minor edits - Show changes to output
Changed lines 12-13 from:
Ultima nota prima di inoltrarci nella RFC: le linee guida ivi descritte non hanno validità giuridica sotto tutte le giurisdizioni, dunque è raccomandabile richiedere validazione legale alle forze dell'ordine locali. to:
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. Changed line 24 from:
* 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 metodico to:
* 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 Changed line 43 from:
* non eseguire programmi che potrebbero alterare le informazioni sui tempi di accesso di tutti i file del sistema (ad esempio “tar” o “xcopy”) to:
* non eseguire programmi che potrebbero alterare le informazioni sui tempi di accesso di tutti i file del sistema (ad esempio "tar" o "xcopy") Changed lines 47-50 from:
* 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 (che siano log o file personali poco cambia)
* 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 mai accesso (ad esempio file personali)
* assicurati sempre che stai rispettando le procedure stabilite dalla compagnia to:
* 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 Changed lines 56-58 from:
affidabili, dato che non deve esserci nulla che possa dare adito a dubbi sulla loro autenticità o veridicità
* credibili, ovvero sia comprensibili che attendibili per un tribunale to:
* 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 Changed lines 60-61 from:
La procedura di raccolta da seguire dovrebbe essere descritta nel modo più dettagliato e meno ambiguo possibile, in modo da minimizzare il numero di decisioni da prendere in fase operativa. to:
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. Changed line 67 from:
* stabilire quali di queste sono rilevanti ed ammissibili, tenendo sempre conto che è meglio raccoglierne troppe che troppo poche to:
* stabilire quali tra queste sono rilevanti ed ammissibili, tenendo sempre conto che è meglio raccoglierne troppe che troppo poche Changed lines 70-76 from:
* usa gli strumenti di collezione che specificheremo nel capitolo 5
* chiediti man mano che procedi con la raccolta se c'è n'è altre che puoi considerare prove
* documenta ogni passaggio
* non ti dimenticare delle persone coinvolte: prendi 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ù semplice e robusta la conservazione futura. to:
* 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. Changed lines 78-79 from:
Le prove devono essere assolutamente messe in sicurezza, e l'intero inventario (chiamato ''chain of custody'') deve essere documentato. to:
Le prove devono essere assolutamente messe in sicurezza e l'intero inventario (chiamato ''chain of custody'') deve essere documentato. Changed lines 93-96 from:
* 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”) to:
* 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") Changed line 100 from:
Tutti questi programmi non devono richiedere librerie che non siano già contenute nel supporto, e in ogni caso ne devi testare l'autenticità e l'affidabilità. to:
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à.
Added lines 1-103:
(:title Gestione degli incidenti informatici - RFC 3227:)
[[Torna alla pagina di Gestione degli incidenti informatici->Gestione degli incidenti informatici]]
----
%titolo%''':: RFC 3227 ::'''
%center%%sottotitolo%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 sotto tutte le giurisdizioni, dunque è raccomandabile richiedere validazione legale alle 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 metodico
* 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 (che siano log o file personali poco cambia)
* 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 mai accesso (ad esempio file personali)
* assicurati sempre che stai 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 sia comprensibili che attendibili per un tribunale
!!3. La procedura di raccolta
La procedura di raccolta da seguire 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 di 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
* usa gli strumenti di collezione che specificheremo nel capitolo 5
* chiediti man mano che procedi con la raccolta se c'è n'è altre che puoi considerare prove
* documenta ogni passaggio
* non ti dimenticare delle persone coinvolte: prendi 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ù semplice 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 ne devi testare l'autenticità e l'affidabilità.
----
[[Torna alla pagina di Gestione degli incidenti informatici->Gestione degli incidenti informatici]]
|
|
