Lezione 1 Definizioni di Incident management

Lezione 1 Definizioni di Incident management Gestione degli incidenti informatici Modulo 1 - Introduzione. Incidenti informatici, Principi di Log analysis Unità didattica 1 - Procedure di gestione Dario V Forte, CISM, CFE Università degli Studi di Milano - Ssri - CDL ONLINE

Il docente Graduated in Network Security and Computer science (Strayer, TCU), with specialization in Advanced Incident Handling (Carnegie Mellon) Oltre 30 pubblicazioni nello specifico settore, incluse 4 contribution a libri per editori come Wiley, IDEA, CMP, Elsevier ed altri. Editorial Board di Elsevier Science, SADFE, DFRWS. Talks: DFRWS, DoD, Nato CyberCrime, BlackHat, CSI, Banca mondiale, IETF. Tutto il materiale del corso è di proprietà del docente. Gli studenti possono utilizzarlo ESCLUSIVAMENTE per il corso. È vietata, ai sensi della legge sul diritto d autore, qualsiasi riproduzione/cessione/trasmissione non autorizzata.

Obiettivi dell Unità didattica Stabilire il perimetro e le definizioni pertinenti la materia, con particolare riferimento all'incident Response, alle Definizioni legali, di standard, alle RFC (Request for Comment) ecc, Saranno previsti dei momenti di verifica Email docente: dario.forte@dflabs.com

Definizioni di Incident Management Per Incident Management, si intende l insieme di politiche e procedure di risposta all incidente informatico di sicurezza. A sua volta, l Incident management contiene altri task quali: Incident Response Digital Investigation Legal Assessment Damage and Risk Assessment

Definizione di Incidente Informatico di sicurezza Partendo dal presupposto che, gran parte del mondo reale, definisce incidente informatico anche l episodio generico di business continuity, l incidente informatico di sicurezza è: 1) Qualsiasi violazione alle politiche di sicurezza aziendali 2) O di una legge 3) O un evento che possa mettere in discussione la stabilità del funzionamento di uno o più computers Se ne desume che: Devono esservi politiche di sicurezza Queste debbono essere note Alle politiche devono seguire delle procedure Possono esservi delle leggi violate che prevedono responsabilità personale ed aziendale

Caratteristiche di un Incidente di Sicurezza Può essere singolo o strutturato Singolo: coinvolge un solo asset Strutturato: coinvolge più asset e su più perimetri A seconda dell organizzazione dell azienda può essere suddiviso in livelli Può richiedere un supporto di tipo legale organizzativo Deve essere trattato come un potenziale sbocco giudiziario

Il framework di incident management Pre incident Preparation Incident Detection Risposta iniziale all incidente Formulazione di una strategia di response Investigazione dell incidente Reporting Risoluzione dell Incidente.

Pre-incident preparation Si tratta delle operazioni di tipo Preventivo che vengono effettuate per pianificare la reazione. Sono composte da: Politiche di sicurezza Procedure da seguire in caso di intrusione Hands On sulla log analysis e sull esame forense

Un incidente può essere riconosciuto : Incident Detection Con l ausilio di strumenti tecnologici (IDS, Log Correlator, Firewall, Antivirus) Segnalazione da parte di terzi coinvolti nell incidente (anche Autorità Giudiziaria)

Risposta iniziale all incidente Formazione del CERT (o CSIRT) Formazione della fonte di prova Acquisizione delle immagini disco Acquisizione dei logs Elaborazione iniziale delle informazioni

Strategia di risposta all incidente Decisioni informative ( Autorità Giudiziaria, coinvolgimento del management, anche di altre aziende coinvolte) Decisioni di interazione con l opinione pubblica: Public Relations

Investigazione sull incidente Effettuazione dell esame post-mortem Effettuazione della parte di log analysis Correlazione degli eventi Il tutto rientra nella cosiddetta Artifact Analysis

Reporting Consiste nella presentazione, a vari livelli dei cosiddetti findings. Comprende una serie di report e di presentazioni che devono essere inoltrate al management aziendale e all autorità giudiziaria.

Risoluzione dell incidente Riguarda le operazioni da effettuare per risolvere l incidente informatico, comprese: Le attività di ripristino Le attività relative alle cosiddette lessons learned che servono sia per la parte di management sia per i rapporti con i fornitori

In sintesi Abbiamo visto: La disciplina dell incident management è ampia e contiene più sottoinsiemi. Contiene una parte organizzativa ed una tecnica. Ricordate che: Bisogna sempre qualificare un incidente di sicurezza Politiche Normative La preparazione ha un ruolo fondamentale Infine: L incidente viene sempre strutturato; Va sempre trattato come un possibile sbocco in sede giudiziaria. FINE

Lezione 2 Definizioni nella "Digital Forensic" Gestione degli incidenti informatici Modulo 1 - Introduzione. Incidenti informatici, Principi di Log analysis Unità didattica 1 - Procedure di gestione Dario V Forte, CISM, CFE Università degli Studi di Milano - Ssri - CDL ONLINE

Digital Forensics vs Digital Investigations Sono due attività contigue ma con alcune differenze sostanziali. Si suggerisce l approccio basato sulle seguenti definizioni (Carrier): Digital investigation: processo dove vengono sviluppate e testate delle ipotesi che possono rispondere a determinate domande su eventi digitali Digital Forensics: processo che usa la scienza e la tecnologia per l analisi di oggetti digitali che sviluppano e testano teorie che possono avere valenza legale. La digital forensic è un investigazione digitale più restrittiva che tiene conto dei requisiti legali.

Il processo investigativo 1/2 Per alcune scuole esiste una differenza sostanziale tra Digital Investigation e Forensic Analysis La prima viene di solito effettuata dal LE La seconda a livello di lab Tuttavia possono verificarsi delle sovrapposizioni.

Il Processo Investigativo 2/2 Per la corrente carrier/spafford esiste un modello di investigazione suddiviso in sei fasi: Notifica Preservation Survey Analysis Reconstruction Presentation

Abbiamo visto: In sintesi Esistono delle differenze di fondo tra Digital Investigation e Forensic Analysis (investigation). Le due discipline sono contigue fra loro. Ricordate che: I ruoli possono differenziarsi ma sovrapporsi tra loro. Infine: Esiste un framework Investigativo/analysis che fa parte del framework generale di incident management. FINE

Lezione 3 Definizioni legali Gestione degli incidenti Informatici Modulo 1 - Introduzione. Incidenti informatici, Principi di Log analysis Unità didattica 1 - Procedure di gestione Dario V Forte, CISM, CFE Università degli Studi di Milano - Ssri - CDL ONLINE

Legal Vs. Incident management La parte legale interagisce con quella tecnico/organizzativa. Le ragioni sono molteplici: Ogni incidente può potenzialmente avere sbocchi giudiziari La tutela legale è di interesse in azienda. Esistono delle responsabilità ben precise che cadono sugli operatori e sui rispettivi supervisori di processo.

La regola primaria TRATTARE OGNI INCIDENTE COME SE DOVESSE TERMINARE IN UN AULA DI TRIBUNALE

Criminal (Penale) Standard Investigativi 1/2 codice procedura penale codice penale polizia/autorità giudiziaria procedibilità d ufficio o a querela

Standard Investigativi 2/2 Civile preponderanza della prova meno schematico del penale Amministrativo inchieste interne informalità arbitrati/mediatori potenziali incompatibilità con lo statuto dei lavoratori e con la legge Privacy E-DISCOVERY

Norme di Riferimento Codice penale e procedura penale Codice Civile e di Procedura civile Leggi Speciali Legge privacy policy interne Normative internazionali

Basic Toolkit Policies/Laws Criminal Profile Log analysis Victim Computer Analisys Case Management Tools Forensics Tools

Tainted Fruit Si tratta di fonti di prova acquisite impropriamente. violazioni privacy intercettazioni abusive violazioni della legge Ogni fonte di prova acquisita in questa maniera non può essere utilizzata in giudizio.

Chain of Custody Inventario delle fonti di prova acquisite durante la fase post incidente/forensic. le fonti di prova devono essere sigillate, fisicamente e/o elettronicamente. Time/operation stamping. Sicurezza fisica della CoC. Firma digitale dei dati/controllo di integrità ( anche post aquisizione)

Subpoena Equivalente del ns. decreto del pm o ordine di esibizione dell AG può essere un input anche per altre aziende coinvolte nel caso potrebbe richiedere una vs.deposizione come persona a conoscenza dei fatti gli impedimenti tecnici vanno documentati

Abbiamo visto: In sintesi Esiste una regola primaria nell Incident Handling. Ricordate che: Esistono vari standard investigativi orientati al Legal. Esiste un Basic Toolkit del Digital Investigator. Infine: Tainted Fruit. Chain of Custody. FINE

Lezione 4 Ruoli e responabilità Gestione degli incidenti informatici Modulo 1 - Introduzione. Incidenti informatici, Principi di Log analysis Unità didattica 1 - Procedure di gestione Dario V Forte, CISM, CFE Università degli Studi di Milano - Ssri - CDL ONLINE

Ruoli e responsabilità La loro definizione viene di solito stabilita per policy ed effettuata nella fase di preparazione all incidente. L Efficacia di detta pianificazione viene continuamente testata, sia in sede di simulazione sia durante i casi reali. La definizione di ruoli e responsabilità è un processo infungibile.

Un esempio di Organigramma TOP MGMT/BOARD Security Manager Ha la responsablit di riferire al Top Management eventuali sviluppi Terze Parti CSIRT ( il team di gestione tecnica dell'incidente) Legal Valuta l'impatto legale Organization/PR Interviene in caso di crisi End Users

Alcune info sui tuoli e le responsabilità Non sempre è possibile gestirli in maniera rigida. Possono essere importanti per normative a latere come: BaselII, SOX, PCI, HIPPA, nonché la nostra Legge Privacy. Possono essere oggetto di aggiornamento del DPS.

Abbiamo visto: In sintesi Stabilire ruoli e responsabilità è un processo necessario che viene eseguito nella fase di preparazione. Ricordate che: I ruoli e le responsabilità sono multi-livello. Infine: I ruoli e le responsabilità sono, di fatto, requisiti di legge. FINE

Lezione 5 Definizione lato standard Gestione degli incidenti informatici Modulo 1 - Introduzione. Incidenti informatici, Principi di Log analysis Unità didattica 1 - Procedure di gestione Dario V Forte CISM, CFE Università degli Studi di Milano - Ssri - CDL ONLINE

Standards vs Incident management L Incident management in generale viene seguito da alcuni standard, tra i quali si cita: ISO 17799/ISO 27001 NIST RFC In questa sede si farà riferimento alla ISO17799.

ISO 17799 vs Incident Management La gestione degli incidenti per la ISO17799 viene trattata dal titolo 13. Sono inclusi in detto titolo una serie di Obiettivi e controlli, oggetto della presente lezione. ISO17799, se ben amministrato, può rappresentare un punto di riferimento per raggiungere una compliance de facto.

ISO 17799 Titolo 13: Elementi principali 13.1: Reporting Objective: To ensure information security events and weaknesses associated with information systems are communicated in a manner allowing timely corrective action to be taken. Formal event reporting and escalation procedures should be in place. All employees, contractors and third party users should be made aware of the procedures for reporting the different types of event and weakness that might have an impact on the security of organizational assets. They should be required to report any information security events and weaknesses as quickly as possible to the designated point of contact. Fonte: IS O17799 standard.

Se ne desume Vanno comunicati sia gli incidenti sia le vulnerabilità. Vanno coinvolti, a vario titolo, anche gli utenti finali e le terze parti. Il sistema di reporting deve essere pianificato a priori.

ISO 17799 Titolo 13: Elementi principali 13.2: Incident management Objective: To ensure a consistent and effective approach is applied to the management of information security incidents. Responsibilities and procedures should be in place to handle information security events and weaknesses effectively once they have been reported. A process of continual improvement should be applied to the response to, monitoring, evaluating, and overall management of information security incidents. Where evidence is required, it should be collected to ensure compliance with legal requirements. Fonte: ISO17799 standard.

Se ne desume È necessario un approccio Effettivo (quindi con riscontro pratico) alla gestione dell incidente. Continous Improvement Process Importanza della digital Forensics

Abbiamo visto: In sintesi Lo standard ISO 17799, nella sua nuova release, tratta direttamente il field degli incidenti informatici nel titolo 13. Ricordate che: I due controlli principali ( o meglio i loro concetti) sono espressi nel 13.1 e nel 13.2. Infine: È necessaria un applicazione pratica dei principi, unitamente ad una attenta valutazione legale. FINE

Lezione 6 Definizioni dei logfile Gestione degli incidenti informatici Modulo 1 - Introduzione. Incidenti informatici, Principi di Log analysis Unità didattica 1 - Procedure di gestione Dario V Forte, CISM, CFE Università degli Studi di Milano - Ssri - CDL ONLINE

Correlation L attività di cui sopra è finalizzata ad analizzare in maniera correlata l output dell esame post-mortem e quello della log analysis. L output dovrebbe fornire quanti più elementi possibili per l individuazione del responsabile e la ricostruzione dell accaduto.

Log Files 1/2 Ogni sistema/device di rete dovrebbe produrre dei log (log di sistema/device/rete). I log devono essere analizzati e correlati tra loro. L attività di cui sopra si chiama di Log analysis. La log Analysis è parte della Network Forensic.

Log Files 2/2 Atteso che è necessario assicurare l integrità dei log, questi vengono acquisiti per: comprendere le modalità di penetrazione dell intruder collaborare con le forze di polizia nel backtracing degli autori del reato collezionare il numero più alto possibile di fonti di prova relative all intrusione. Per Log Grezzo (Raw) si intende il primo log materialmente disponibile dopo la fase di acquisizione. (HTCIA Paper)

Log Files vs Preparation L architettura di log dovrebbe essere pianificata a priori Apposite policy dovrebbero garantire rotation, retention, field, payload, access, chain of custody Log Storage Log Analysis Vs. Information Security Log

In caso di incidente iniziare un operazione di traceback per identificare le posizioni dei log contattare i sysadmin per la cautela immediata dei log contenere il danno collezionare log in locale (non significa: GENERARE i log in locale) acquisire i log in una maniera forensically sounding generare l immagine delle macchine colpite

Stabilire relazioni

Abbiamo visto: I log files sono necessari per la correlazione. L architettura deve essere pianificata. Ricordate che: In sintesi Per la Digital Forensic i Log GREZZI sono fondamentali, per le operazioni di security e di Incident handling, in teoria, si potrebbero applicare i princìpi della digital investigation Infine: È consigliabile suddividere il perimetro in log zones. FINE

Lezione 1 Log Management: Security Vs Forensic Gestione degli incidenti informatici Modulo 2 - Sistemi di Logging a livello sistema, Sistemi di Logging a Livello Rete, Sistemi di Intrusion Detection Unità didattica 1 - Standard di Log Management Dario V Forte, CISM, CFE Università degli Studi di Milano - Ssri - CDL ONLINE

Obiettivo del modulo Fornire agli studenti un overview circostanziata dei meccanismi di logging in ordine ai sistemi operativi. Logging sotto Linux e Windows 2000. Logging sotto Windows XP. Cenni al logging di sistema di UNIX/LINUX. Snort, principi di funzionamento e installazione. Esempi di regole di sicurezza e di packet analysis. Gestione e management dei sistemi basati su NIDS. Router syslog. Analisi dei formati di log di router CISCO e di altri vendors. Analisi dei log, esame degli strumenti TCPDump, Ethereal e similari.

Obiettivi dell esame dei Log 1/2 Assicurare l integrità dei log. Comprendere le modalità di penetrazione dell intruder. Collaborare con le forze di polizia nel backtracing degli autori del reato. Collezionare il numero più alto possibile di fonti di prova relative all intrusione.

Correlazione Obiettivi dell esame dei Log 2/2 Documentare il danno causato Ottenere informazioni sufficientemente attendibili per decidere se interessare l autorità giudiziaria.

Obiettivo primario: cautelare la fonte di prova iniziare un operazione di traceback per identificare le posizioni dei log. contattare i sysadmin per la cautela immediata dei log. contenere il danno. collezionare log in locale. generare l immagine delle macchine colpite.

Riprodurre l incidente Comprensione del come può essere avvenuto l incidente. accantonare l ovvio. utilizzare log ed altre prove simili. considerare il livello di skill richiesto per la gestione dell incidente. creare un mirror del computer compromesso.

Ricostruzione dell incidente 1/4 Sviluppare un profilo dell intruder considerare il percorso effettuato dall intruder per raggiungere il target ricreare l incidente in lab (comparazione dei log) considerare spiegazioni alternative dell accaduto.

Ricostruzione fisica: Ricostruzione dell incidente 2/4 usa un mirror della macchina compromessa è utile per uno o comunque pochi target Ad ogni modo va tutto verbalizzato internamente.

Ricostruzione logica: Ricostruzione dell incidente 3/4 Usa simili sistemi utile in caso di micro- reti locali che hanno accesso alla lan aziendale in toto (poco frequente) può rivelarsi fuorviante verbalizzazione interna

Ricostruzione dell incidente 4/4 Ricostruzione Teorica: Va fatta in extrema ratio. necessaria quando non si può accedere direttamente ai computer direttamente coinvolti come target. Verbalizzazione estremamente granulare.

BackTracing Elementi costitutivi: target (end points) teste di ponte e-mail ed headers log vari

Stabilire le relazioni

Non modificabilità Optical media Backup Devono essere completi: Usabilità dei log - Requisiti tutti gli accessi superuser login/logout tentativi di ingresso tentativi di accesso ai servizi under wrapper tentativi di accesso a servizi critici Conservazione minima consigliata = 6 mesi.

Abbiamo visto: In sintesi Esistono delle differenze tra l utilizzo dei log in security e in forensics. Ricordate che: È comunque un errore lavorare a compartimenti stagni. Infine: È possibile trovare un balancing costruttivo per entrambi i settori. FINE

Lezione 2 Logging in Windows 2000/XP Gestione degli incidenti informatici Modulo 2 - Sistemi di Logging a livello sistema, Sistemi di Logging a Livello Rete,Sistemi di Intrusion Detection Unità didattica 1 - Standard di Log Management Dario V Forte, CISM, CFE Università degli Studi di Milano - Ssri - CDL ONLINE

Overview Nelle successive slide saranno fornite diverse informazioni di carattere descrittivo in merito al sistema di logging di Windows 2000/XP/2003. Gli eventi di sicurezza generati dal sottosistema di logging hanno un dettaglio di informazioni maggiore delle versioni precedenti dei sistemi operativi di casa Microsoft. Windows utilizza nove diverse classi entro cui raggruppare gli eventi generati sul sistema. Ogni evento all interno di queste categorie è identificato univocamente con un ID a cui è associata una descrizione.

Campi di un evento I campi standard di cui è composto un evento sono: ID informazioni temporali (data e ora) username computer sorgente che ha generato il messaggio categoria il tipo di messaggio

Event Viewer Chiaramente viene anche fornito dal sistema un tool utile al fine di visualizzare gli eventi contenuti all interno dei log generati. Questo strumento è Event Viewer che, oltre alla mera possibilità di rendere visibile il contenuto delle informazioni registrate nei file prodotti, offre altre opzioni. Alcune di queste comprendono la possibilità di filtrare determinate categorie d eventi o ricercare stringhe all interno dei log. E inoltre possibile, attraverso questa interfaccia, procedere alla esportazione manuale dei log prodotti utilizzando uno dei formati supportati.

Tipologie di log Di default ogni macchina basata sul sistema operativo Windows 2000/XP/2003 registra gli eventi in tre tipi di log distinti: application log security log system log

Application Log L application log contiene gli eventi generati dalle applicazioni o programmi presenti sul sistema. Per esempio potrebbe essere registrato all interno di questo file un comportamento anomalo da parte di un applicazione che accede ad un database a causa di un problema di lettura di file. Questo tipo di log contiene comunicazioni pensate dal produttore del sistema o dell applicativo e chi lo sviluppa decide i dati da includere e quali record generare.

Security Log Il security log è sicuramente il file che contiene il numero d informazioni di maggior rilevanza al fine di un analisi forense. All interno di questo si registrano eventi come accessi al sistema portati a buon fine dagli utenti e tentativi di login falliti. Sono molte le tipologie d eventi che si possono trovare all interno di questo log come, per esempio, le varie registrazioni delle operazione di gestione degli utenti e gruppi del sistema/dominio.

System Log Il system log contiene gli eventi generati dai diversi componenti del sistema operativo. All interno di questo file trovano spazio eventi come comportamenti anomali di driver di periferica o messaggi che notificano lo stato di determinati servizi di sistema.

Success and Failure event Gli eventi generati dal sistema Microsoft Windows si suddividono in due categorie: success event failure event Un success event identifica un accesso ad una risorsa, da parte di un utente, andato a buon fine. Un failure event descrive tale accesso tentato e non riuscito. Ovviamente i failure event sono di fondamentale importanza durante l analisi degli attacchi che possono essere stati lanciati ad un sistema e per questo motivo devono essere salvati in ogni situazione. Anche i success event, tuttavia, seppur meno sospetti, rivestono grande importanza. Si pensi al caso in cui l attaccante sia già in possesso delle credenziali di accesso al sistema oppure nel caso in cui a seguito di ripetuti failure event si registri un success event.

Abbiamo visto: In sintesi Come sono strutturati i log generati dal sistema Windows. Ricordate che: Esistono diverse tipologie di log all interno del sistema suddivise a seconda del sottositema che le ha prodotte. Infine: I failed event sono sicuramente d indubbia utilità ma anche i success event possono avere natura informativa. FINE

Lezione 2 Logging in Unix/Linux Gestione degli incidenti informatici Modulo 2 - Sistemi di Logging a livello sistema, Sistemi di Logging a Livello Rete,Sistemi di Intrusion Detection Unità didattica 1 - Standard di Log Management Dario V Forte, CISM, CFE Università degli Studi di Milano - Ssri - CDL ONLINE

Overview Nei sistemi operativi Unix/Linux la maggior parte dei log prodotti dal sistema o da demoni è in formato syslog. I log del sistema vengono generalmente scritti in directory come /var/log (Linux e Unix) e /var/adm (Solaris) o dove definito nei file di configurazione dei singoli programmi; in quasi tutti i sistemi *nix il demone syslogd si prende in carico della gestione dei log tramite il file di configurazione /etc/syslog.conf. Alcuni servizi demoni possono avvalersi di tale meccanismo offerto dal sistema per registrare i propri eventi; altri preferiscono utilizzare un proprio file di log separato ed indipendente.

Syslog message Questo formato è già stato trattato approfonditamente in altre lezioni. Solitamente questa possibilità per la registrazione dei messaggi prodotti è sempre presente all interno dei sistemi unix. Alcuni sistemi utilizzano il demone syslogd standard; altre optano per l utilizzo del demone syslog-ng che è una versione più recente e flessibile che offre inoltre una vasta schiera di opzioni di registrazione e filtro degli eventi.

Altre fonti d informazione Oltre a i log di sistema appena citati solitamente troviamo all interno del modo Unix anche i seguenti file di log: utmp wtmp lastlog

Altre fonti d informazione: utmp Il file utmp permette di scoprire informazioni su chi sta usando attualmente il sistema. Ci possono essere più utenti che stanno usando il sistema di quelli riportati, poichè non tutti i programmi usano registrazioni utmp.

Altre fonti d informazione: wtmp Contiene le informazioni degli avvenuti login e logouts. Alla base della contabilità dell'utilizzo delle risorse del sistema sta generalmente nel file /var/log/wtmp che deve esistere perchè tali registrazioni avvengano effettivamente. Per motivi storici, non si tratta di un file di testo normale (file binario), e per leggerlo si usa generalmente il programma last, al quale si aggiungono eventualmente altri programmi più raffinati.

Altre fonti d informazione: lastlog Contiene gli ultimi login effettuati al sistema. Per visulaizzare il contenuto di tale registrazione si utilizza il comando omonimo lastlog che mostra informazioni su: nome-login porta data ultima connessione

sulog e sudolog A seconda del sistema in uso è possibile che sia presente unicamente il comando su o in alterativa il comando sudo; quest ultimo è consigliabile e preferibile per le numerose opzioni disponibili. Il file sulog contiene una entry per ogni tentativo, da parte degli utenti di sistema, di utilizzare il comando su. Il file sudolog memorizza, nel suo comportamento di default, unicamente i tentativi falliti dell utilizzo ma è possibile istruirlo sulla registrazione di tutti i comandi che avvengono tramite il suo utilizzo.

Abbiamo visto: In sintesi Quali sono i log generati dal sistema Unix/Linux. Ricordate che: Esistono diverse tipologie di log all interno del sistema suddivise a seconda dello scopo che esse assolvono. Infine: Esitono una molteplicità di log all interno del sistema e molti di questi sono relativi all applicativo/demone che li produce e possono non utilizzare la facility di sistema per registrare i propri eventi. FINE

Lezione 2 Network Logging Gestione degli incidenti informatici Modulo 2 - Sistemi di Logging a livello sistema, Sistemi di Logging a Livello Rete,Sistemi di Intrusion Detection Unità didattica 1 - Standard di Log Management Dario V Forte, CISM, CFE Università degli Studi di Milano - Ssri - CDL ONLINE

Network Logging È possibile spezzare il problema a vari livelli corrispondenti ciascuno alle evidence che è possibile recuperare.

Physical e Data Link Layer 1/2 Questi due strati provvedono la base su cui si fonda la trasmissione dei dati su rete. Nel caso di rete Ethernet è possibile trovare informazioni all interno della cache ARP del sistema oppure utilizzando una registrazione del traffico in formato pcap è possibile risalire al venditore della scheda di rete (OUI). In reti ATM esistono meccanismi simili utilizzati (ATMARP) per il discover del MAC, tranne per il fatto che viene mantenuto, a differenza di ethernet, un repository centrale di corrispondenze IP<->MAC. Nel caso sia utilizzata una diversa soluzione a livello fisico e collegamento dati, è necessario utilizzare approci differenti.

Physical e Data Link Layer 2/2

Network e Transport Layer 1/2 A questo livello esistono una molteplicità di fonti informative: log del sistema operativo log dei router (o altri device di rete tipo switch L2/L3) intermediari attraversati per la comunicazioni log prodotti da strumenti di access-control (firewall) o authentication (radius) log applicativi del servizio utilizzato

Network e Transport Layer 2/2 Radius Log 172.16.1.219,CORPX ianjones,03/08/2003,17:46:04,ias,ias-server, 5,7029,6,2,7,1,66,64.252.248.133,61,5,4108,172.16.1.219 4116,0,4128,CORPX VPN,4129,CORPX ianjones,25,311 1 172.16.1.4510/08/2002 14:38:34 22348,4127,3,4130,corpx.com/Users/ianjones,4136,1,4142,0 PIX Log Jun 14 10:00:07 firewall.secure.net %PIX-2-106001: Inbound TCP connection denied from 10.14.21.57/41371 to 10.14.42.6/22 flags SYN Jun 14 10:00:47 firewall.secure.net %PIX-2-106001: Outbound TCP connection denied from 10.14.42.5/41371 to 10.10.4.16/22 flags SYN FTP log Nov 14 00:17:23 fileserver1 ftpd[2536]: user32 of 202.180.75.79 [202.180.75.79] deleted /d2/project13/data1.xls Nov 14 00:17:24 fileserver1 ftpd[2536]: user32 of 202.180.75.79 [202.180.75.79] deleted /d2/project13/data2.xls

Internet 1/2 Internet prevede l infrastruttura per differenti servizi. Molte persone sono famigliari con servizi quali e-mail e il World Wide Web. I cinque principali servizi disponibili su Internet, al fine di semplificare l analisi sono: World Wide Web (log webserver) E-Mail (header e-mail ) Newsgroup (header) Synchronous Chat Networks (log ICQ, AIM, skype, IRC, etc) Peer-2-peer (log emule, gnutella, etc)

Internet 2/2 E-mail Received: from NYU.EDU by is4.nyu.edu; (5.65v3.2/1.1.8.2/26Mar96-0600PM) id AA08502; Sun, 6 Jul 1997 21:22:35-0400 Received: from comet.connix.com by cmcl2.nyu.edu (5.61/1.34) id AA14047; Sun, 6 Jul 97 21:22:33-0400 Received: from tara.eire.gov (ec30@is4.nyu.edu [128.122.253.137]) by comet.connix.com (8.8.5/8.8.5) with SMTP id VAA01050 for <eoan.cey@nyu.edu; Sun, 6 Jul 1997 21:21:05-0400 (EDT) Date: Sun, 6 Jul 1997 21:21:05-0400 (EDT) Message-Id:,199707070121.VAA01050@comet.connix.com From: fionn@eire.gov To: hilte@nasa.gov Subject: Re: info

Anonimato in rete E possibile che vengano utilizzati alcuni strumenti in maniera da rendere più difficile, o in alcuni casi quasi impossibile, risalire all identità dell autore di una particolare azione. proxy tor encryption (pgp, aes, etc) anonymous e-mail (mixmaster remailer) anonymous p2p (freenet)

Abbiamo visto: In sintesi Quali sono le tracce reperibili nei differenti livelli utilizzati nelle comunicazione di rete. Ricordate che: Esistono una molteplicità di fonti informative collegate all attività di rete, la difficoltà maggiore sta nel reperirle, in quanto possono trovarsi su una molteplicità di sistemi spesso non sotto il medesimo controllo. Infine: Alcune tecniche e tecnologie sono state sviluppate per garantire l anonimato in rete. FINE

Lezione 2 Network Flows et simila Gestione degli incidenti informatici Modulo 2 - Sistemi di Logging a livello sistema, Sistemi di Logging a Livello Rete,Sistemi di Intrusion Detection Unità didattica 1 - Standard di Log Management Dario V Forte, CISM, CFE Università degli Studi di Milano - Ssri - CDL ONLINE

Session Flow 1/3 Sessione: indicata spesso anche col termine flow, stream o conversation, è il riassunto dei dati scambiati fra due sistemi. Protocolli come TCP si prestano meglio a questo tipo di rappresentazione, in quanto hanno il concetto di stato. L idea comunque può essere adattata anche ad latri protocolli stateless (UDP/ICMP)

Session Flow 2/3 I dati fondamentali tramite cui viene rappresentata una sessione sono: IP sorgente IP destinazione porta sorgente porta destinazione timestamp (indica solitamente in che momento ha avuto inizio la conversazione) misura del numero di informazioni interscambiate (kb, pacchetti, etc) Queste informazioni di massima vengono raccolte da tutti i tool di questa tipologia. Alcuni possono aggiungere ulteriori informazioni (es. interfaccia, TOS, Flag, etc)

Session Flow 3/3

Formato delle registrazioni 1/2 Uno dei formati standard riconosciuti per questo tipo di attività, in modo analogo al formato libpcap per le registrazioni di tipo full-content, è il Cisco NetFlow. La maggior parte dei tool elencati supportano o permettono l esportazione in tale formato.

Formato delle registrazioni 2/2 Feature IOS CISCO dalla 11.* (1996) Standard de facto Memorizza i flussi in una cache e permette l export verso un collector Diversi software che permettono l analisi (sia opensource che commerciali)

Sorgenti d informazione Solitamente gli strumenti che possono produrre tale tipo d informazione sono: router (cisco, juniper, etc) sonde con software specifico (argus, fprobe, etc) switch L2/L3 (cisco, nortel, etc)

Vantaggi e svantaggi + Permette di inferire gran parte delle informazioni necessarie + Buoni risultati anche con link ad elevate velocità + Non viola la privacy degli utenti + Non soffre del fatto che le comunicazioni siano cifrate - Rappresenta un riassunto delle comunicazioni intercorse - Non è possibile estrarre i dati scambiati

Abbiamo visto: In sintesi Il formato con cui vengono memorizzate le sessioni intercorse fra più host. Ricordate che: Una sessione è un flusso unidirezionale di pacchetti ip che viaggiano da una coppia ip/porta sorgente ad una destinazione, contenente misure quali il tempo intercorso dall inizio del flusso e i dati scambiati. Infine: Il formato standard per le registrazioni di questo tipo è il NetFlow di Cisco. FINE

Lezione 1 Struttura generale di un log file Gestione degli incidenti informatici Modulo 1 - Introduzione. Incidenti informatici, Princìpi di Log analysis Unità didattica 2 - Struttura di un log, e tecniche di correlazione Nome docente: Dario V Forte, CISM, CFE Università degli Studi di Milano - Ssri - CDL ONLINE

Obiettivi dell Unità didattica Obiettivi dell'unità didattica: Fornire un'overview su come sono strutturati i log e le relative tecniche di correlazione. Fornire esempi di formato, con riferimento ai tipi di files più diffusi. Lo studente terminerà la UD con un più ampio background relativo al log management. Università di Milano SSRI Online

Definizioni di Log File La letteratura definisce un log, come un record di un evento accaduto all interno di un sistema o di una rete. Ogni log è composto da Log Entries. Ognuna di esse è relativa ad un informazione su uno specifico evento accaduto. Originariamente i log venivano utilizzati con scopi di troubleshooting. Allo stato attuale gli scopi si sono moltiplicati. Questo percorso di studi si occupa dei log di sicurezza. Università di Milano SSRI Online

Definizione di Log Management In questo momento storico si assiste ad un aumento esponenziale delle fonti dati, termine con il quale si definisce qualsiasi dispositivo/sistema in grado di generare Log. Questo ha reso necessaria una disciplina del processing delle operazioni di gestione, denominata Log Management. Con il termine Log Management si indica il processo di generazione, trasmissione, storage, analisi e destinazione finale dei log di sicurezza. Università di Milano SSRI Online

Alcuni concetti di base Log di sicurezza: descrivono degli eventi che possano risultare direttamente security related Log di sietema operativo e/o di applicazione: contengono una serie di informazioni di troubleshooting e/o audit che possono avere dei risvolti indiretti di sicurezza La generazione dei log può essere continua o schedulata (batch mode). Università di Milano SSRI Online

Chi genera i Log Files: Security Software Il security software è una delle fonti primarie di generazione di log. La derivazione dei log più comune è evidentemente di natura network e natura sistema. Ne identifichiamo alcuni: Packet filters. Operano, per esempio, a livello router, e bloccano alcune tipologie di traffico rete, basandosi su policy. Loggano di solito gli eventi più elementari ( blocked activity). Firewalls. Hanno modus operandi simile ai PF ma delle tecnologie di ispezione più avanzate. Antimalware Software. Logga tutte le istanze in cui viene reperito malicious code, ma anche i tentativi di disinfezione, le quarantene, gli aggiornamenti, etc. Università di Milano SSRI Online

Chi genera i Log Files: Security Software (2) Intrusion Detection ed Intrusion Prevention Systems. Loggano i record di particolari comportamenti anomali e di intrusioni corrispondenti a pattern, insieme alle azioni preventive di eventi ulteriori. Qualche IDS, inoltre, si occupa di gestire l integrità, in maniera ciclica (batch mode) Vulnerability Management Software. Include anche il software di patch management, e quello di vulnerability assessment. Logga la cosiddetta patch installation history e il cosiddeetto vulnerability status di ciascuna macchina. Quest ultimo include le vulnerabilità note, unitamente ai software update che non sono stati effettuati. I VMs sono componenti che girano in maniera ciclica e generano batch files molto larghi. Authentication Servers. Si occupano di gestire ogni tentativo (riuscito o meno) di autenticazione. Inclusa l origine. Network Quarantine Servers. Sono componenti delle architetture NAC (network access control). Loggano quindi lo status delle macchine messe in quarantena prima di avere l accesso alla rete, nonché dei relativi agenti Università di Milano SSRI Online

Alcuni esempi di log fles (1) fonte NIST Intrusion Detection System[**][1:1407:9] SN MP trap udp [**] [Classification: Attempted Information Leak][Priority:2] 03/06-8:14:09.082119 192.168.1.167:1052 -> 172.30.128.27:162 UDP TTL:118 TOS:0x0 ID:29101 IpLen:20 DgmLen:87 Personal Firewall 3/6/2006 8:14:07 AM,"Rule ""Block Windows File Sharing"" blocked (192.168.1.54,netbios-ssn(139)).","Rule ""Block Windows File Sharing"" blocked (192.168.1.54,netbios-ssn(139)). Inbound TCP connection. Local address,service is (KENT(172.30.128.27),netbios-ssn(139)). Remote address,service is (192.168.1.54,39922). Process name is ""System""." 3/3/2006 9:04:04 AM,Firewallconfiguration updated: 398 rules.,firewall configuration updated: 398 rules. Università di Milano SSRI Online

Alcuni esempi di log fles (2) fonte NIST Antivirus Software, Log 1 3/4/2006 9:57:10 AM,Definition File Download,KENT,userk,Definition downloader 3/4/2006 9:33:50 AM,Definition File Download,KENT,userk,Definition downloader 3/4/2006 9:33:09 AM,AntiVirus Startup,KENT,userk,System 3/3/2006 3:56:46 PM,AntiVirus Shutdown,KENT,userk,System Antivirus Software, Log 2 240203070738,14,2,8,KENT,userk,,,,,,,16777216,"Symantec AntiVirus services startup was successful.",0,,0,,,,,0,,,,,,,,,,savpr O D,{xxxxxxxx-xxxx-xxxxxxxx-xxxxxxxxxxxx},End User,,,GR O UP,0:0:0:0:0:0,9.0.0.338,,,,,,,,,,,,,,, 240203071234,16,3,7,KENT,userk,,,,,,,16777216,"Virus definitions are current.",0,,0,,,,,0,,,,,,,,,,savpr O D,{ xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx },End User,(IP)-192.168.1.121,,GROUP,0:0:0:0:0:0,9.0.0.338,,,,,,,,,,,,,,, Antispyware Software DSO Exploit: Data source object exploit(registry change, nothing done) HKEY_USERS\S- 1-5-19 Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\0\1004!=W=3 DSO Exploit: Data source object exploit(registry change, nothing done) HKEY_USERS\.DEFAULT\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\0\1004!= W=3 Università di Milano SSRI Online

Abbiamo visto: In sintesi Esistono varie tipologie di eventi generati, e da varie tipologie di dispositivi. L insieme delle attività rientra nel log management Ricordate che: I log possono essere generati di continuo o ciclicamente Infine: Ai fini della correlazione sono importanti sia i security log sia i system/network log. Università di Milano SSRI Online FINE

Lezione 2 Struttura generale di un log di rete Gestione degli incidenti informatici Modulo 1 - Introduzione. Incidenti informatici, Princìpi di Log analysis Unità didattica 2 - Struttura di un log, e tecniche di correlazione Nome docente: Dario V Forte, CISM, CFE Università degli Studi di Milano - Ssri - CDL ONLINE

Overview Logs on networks Designing log architecture Handling logs as evidence Tools for log examination and correlation Data reduction, searching and organization Le slides di cui alla presente lezione sono copyright Dario Forte e Eoghan Casey. Università di Milano SSRI Online

Evidence on Networks Deloitte-Touche-Tohmatsu (2003 Global Security Survey) Authentication logs Anti-virus VPN IDS Vuln Assess Content filtering 96% 86% 85% 79% 77% Application logs System logs PKI Smart cards 45% 43% Network device logs Biometrics 19% US Universities (EDUCAUSE ECAR) CSI/FBI 2003 Anti-virus 99% Anti-Virus 99% SSL for web transactions Centralized backup Firewall (perimeter) Enterprise directory VPN IDS IPS Encryption Content filtering Electronic signature Shibboleth 1% 7% 48% 45% 43% 33% 32% 32% 73% 71% 71% Firewalls Access Control Physical Security Intrusion Detection Encrypted Files Encrypted Login Digital ID Reusable Passwords PCMCIA Biometrics 11% 73% 69% 58% 49% 47% 40% 98% 92% 91% Università di Milano SSRI Online

Lessons Learned Plan collection carefully: only one chance Determine which systems were used Create an accurate network diagram Obtain outside technical assistance Preserve likely sources of evidence Examine systems without alteration Università di Milano SSRI Online

Overview of Log Files INTERNET ACTIVITY Web server E-mail server Host logon FTP server PPP Dial-up Router/Firewall IRC Wireless Mobile phone LOGS FILES access/error messages/syslog wtmp/nt Eventlog xferlog TACACS/RADIUS Syslog/Netflow server/bot logs device logs transactions Università di Milano SSRI Online

TACACS & RADIUS RADIUS (RFC 2138) TACACS Jul 13 04:31:34 serv1 tacacsd[18142]: validation request from ppp-02.corpx.com [Type=10] Jul 13 04:31:34 serv1 tacacsd[18142]: xslip off from ppp-02.corpx.com SLIP34 for Jul 13 04:31:34 serv1 tacacsd[18142]: user1(0) address static1.corpx.com Jul 13 04:35:30 serv1 tacacsd[18144]: validation request from ppp-01.corpx.com [Type=1] Jul 13 04:35:30 serv1 tacacsd[18144]: xlogin query from ppp-01.corpx.com TTY26 for user2 accepted Jul 13 04:35:30 serv1 tacacsd[18145]: validation request from ppp-01.corpx.com [Type=7] Jul 13 04:35:30 serv1 tacacsd[18145]: xlogout from ppp-01.corpx.com TTY26, user user2(0) Jul 13 04:35:30 serv1 tacacsd[18146]: validation request from ppp-01.corpx.com [Type=9] Università di Milano SSRI Online

Text logs & Web Interface VPN Concentrators 3963 04/10/2001 07:16:02.340 SEV=5 PPP/8 RPT=489 64.252.71.68 User [ casey ] Authenticated successfully with MSCHAP-V1 3964 04/10/2001 07:16:11.460 SEV=4 AUTH/21 RPT=486 User casey connected 3992 04/10/2001 16:44:10.320 SEV=4 AUTH/22 RPT=474 User casey disconnected Università di Milano SSRI Online

Performance Monitoring Shows patterns on a device Spikes in traffic Loss of connectivity to a segment Multi Router Traffic Grapher (MRTG) www.mrtg.org Università di Milano SSRI Online

Abbiamo visto: In sintesi Esistono varie tipologie di eventi generati, e da varie tipologie di dispositivi. L insieme delle attività rientra nel log management Ricordate che: I log possono essere generati di continuo o ciclicamente Infine: Ai fini della correlazione sono importanti sia i security log sia i system/network log. Università di Milano SSRI Online FINE

Lezione 3 Struttura generale di un log file OS /WS Gestione degli incidenti informatici Modulo 1 - Introduzione. Incidenti informatici, Princìpi di Log analysis Unità didattica 2 - Struttura di un log, e tecniche di correlazione Nome docente: Dario V Forte, CISM, CFE Università degli Studi di Milano - Ssri - CDL ONLINE

I log a livello di Sistema Operativo I cosiddetti OS Log, sono relativi ai sistemi operativi di rete, di servizio e di workstation. Tra questi citiamo: System Events. Si tratta di azioni operative (operational actions) che sono compiute da componenti di sistemi operativi, quali lo spegnimento di un sistema, o lo start di un servizio dispositivo. Tipicamente, gli eventi falliti ( failed events) e gli eventi andati a buon fine più significanti, sono oggetto di log. Tuttavia alcuni sistemi operativi consentono agli amministratori di loggare gli eventi. Ogni evento è di solito sottopposto a timestamp, e contiene operazioni di supporto quali:event, status, error codes; service name; utente o sistema associato ad un particolare evento etc. Audit records. Contengono informazioni relative a particolari eventi di sicurezza, come tentativi di autenticazione andati più o meno a buon fine, accessi ai files, cambi di politica di sicurezza etc. Università di Milano SSRI Online

I log di sistema operativo (cont) I log di sistema sono tra gli elementi di maggior utilità per l identificazione di violazioni e anomalie. Sono utili anche per attività di correlazione. La maggior parte dei log OS sono di tipo Syslog. Quelli di altra fonte (es. windows) sono in formato proprietario (esempio sotto). Event Type: Success Audit Event Source: Security Event Category:(1) Event ID: 517 Date: 3/6/2006 Time: 2:56:40 PM User: NT AUTHO RITY/SYSTEM Co mputer: KENT Description: The auditlog was cleared Primary User Name: SYSTE M Primary Domain:NT AUTH O RITY Primary Logon ID:(0x0,0x3F7) Client User Name: userk Client Domain: KENT Client Logon ID: (0x0,0x28BFD) Università di Milano SSRI Online

Application log Simple Mail Transfer Protocol (SMTP) per e- mail, Hypertext Transfer Protocol (HTTP) peril Web, File Transfer Protocol (FTP) per file sharing. Databases Molte applicazioni si occupano di registrare gli eventi. Nella slide che segue, forniamo un esempio. Università di Milano SSRI Online

Web Access Logs Common Log Format / Extended CLF Extended CLF: remote host, userid, date, time, request, status code, # bytes returned, referring URL, browser IIS 192.168.20.65, -, 2/15/01, 20:41:28, W3SVC1, WEBSERVER, 10.120.120.7, 234, 140, 1650, 200, 0, GET, /scripts/../../winnt/system32/cmd.exe, /c+dir+c:\, Mozilla/4.0+(compatible;+MSIE+5.0; +Windows+98;+DigExt;+Zenon) Netscape 192.168.1.56 - - [24/May/2001:16:18:35-0500] GET /sales/index.html HTTP/1.1 200 13303 Mozilla/4.0 (compatible; MSIE 4.01; Windows 98; Compaq) GET /sales/index.html HTTP/1.1 Università di Milano SSRI Online

Sendmail Logs SMTP Forgery Oct 15 01:20:09 mailserver sendmail[27941]: BAA27941: from= forged.from@home.net, size=114, class=0, pri=30114, nrcpts=1, msgid=<199910150518.baa27941@mailserver>, proto=smtp, relay=atla-mx1.usa.net [20.134.161.6] Oct 15 01:20:10 mailserver sendmail[28214]: BAA27941: to= target@ayyahoo.com, delay=00:01:14, xdelay=00:00:01, mailer=esmtp, relay=192.168.1.50, stat=sent (BAA08487 Message accepted for delivery) Università di Milano SSRI Online

Post Office Protocol POP and IMAP Apr 4 03:40:26 mailsrv ipop3d[26535]: Login user=tsmith host=dialup.domain.net [10.10.2.10] Apr 4 03:40:28 mailsrv ipop3d[26535]: Logout user=tsmith host=dialup.domain.net [10.10.2.10] Internet Message Access Protocol Apr 4 14:12:29 mailsrv imapd4[18788]: Login user= tsmith host=dialup.domain.net [10.10.2.10] Apr 4 14:12:29 mailsrv imapd4[18788]: Logout user= tsmith host=dialup.domain.net [10.10.2.10] Università di Milano SSRI Online

NT Event Logs C:\>dumpel -l security 5/4/2002 9:32:34 AM 16 9 681 Security NT AUTHORITY\SYSTEM PEEKER MICROSOFT_AUTHENTICATION_PACKAGE_V1_0 eco PEEKER 3221225578 5/4/2002 9:32:34 AM 16 2 529 Security NT AUTHORITY\SYSTEM PEEKER eco PEEKER 2 User32 Negotiate PEEKER 5/4/2002 9:32:39 AM 8 9 680 Security NT AUTHORITY\SYSTEM PEEKER MICROSOFT_AUTHENTICATION_PACKAGE_V1_0 eco PEEKER 5/4/2002 9:32:39 AM 8 2 528 Security PEEKER\eco PEEKER eco PEEKER (0x0,0x11E60) 2 User32 Negotiate PEEKER Università di Milano SSRI Online

Abbiamo visto: In sintesi Esistono varie tipologie di eventi generati, e da varie tipologie di dispositivi. L insieme delle attività rientra nel log management Ricordate che: I log possono essere generati di continuo o ciclicamente Infine: Ai fini della correlazione sono importanti sia i security log sia i system/network log. Università di Milano SSRI Online FINE

Lezione 4 Log Retention e Log Rotation Gestione degli incidenti informatici Modulo 1 - Introduzione. Incidenti informatici, Princìpi di Log analysis Unità didattica 2 - Struttura di un log, e tecniche di correlazione Nome docente: Dario V Forte, CISM, CFE Università degli Studi di Milano - Ssri - CDL ONLINE

Abstract Fornire agli studenti un overview sulla gestione dei log files, con particolare riferimento alla loro generazione, disponibilità, catalogazione, produzione. Università di Milano SSRI Online

Log Rotation. Definizione Con il termine Log Rotation si indica la metodica con la quale un log viene spostato dalla modalità online a quella off line. Di solito detto spostamento viene eseguito in base ad alcune variabili quali: La dimensione disco raggiunta dal file di log ad un determinato momento (si consiglia una quota disco massima del 65%) lo strumento utilizzato per le analisi La chain of cusody. Università di Milano SSRI Online

Rotation Processo di Rotation : Ad ogni istante prestabilito di tempo o quando viene raggiunta una dimensione massima avvenga la chiusura di un file di log Compressione del file prodotto Generazione di un valore di hash del file (SHA1, MD5) che ne provi l integrità anche dopo lo spostamento e copia su diversi dispositivi Invio dell archivio verso sistema di raccolta centralizzato Università di Milano SSRI Online

Rotation (2) Implementazione di un meccanismo automatizzato per la registrazione delle attività prodotte durante la gestione dei log: Data e ora di inizio e fine operazione Motivazione della rotation: scadenza quanto di tempo o dimensione massima raggiunta Sorgente di log da archiviare Destinazione del log file Università di Milano SSRI Online

Retention Risponde alla domanda specifica relativa alla ritenzione dei log files Ad eccezione di alcune categorie aziendali non esiste una normativa specifica di retention. Esistono comunque dei parametri comuni di ritenzione, riassumibili come segue: - Tipologia di azienda - Architettura di log - Architettura di storage - Eventuali normative pendenti in merito. Università di Milano SSRI Online

Retention (2) - Tipologia di azienda a) finance b) industry c) telco d) PA - Architettura di log: Accentrata, distribuita, local - Architettura di storage: NAS, SAN etc - Eventuali normative pendenti in merito: Consob, SOX, Decreto Pisanu etc. Università di Milano SSRI Online

Abbiamo visto: In sintesi Esistono delle differenze tra i concetti di retention e rotation, comunque operanti in sinergia Ricordate che: I log vengono gestiti sempre a seguito di una fase adeguata di preparazione Infine: Esistono dei fattori/parametri di dipendenza relativi a retention e rotation. Università di Milano SSRI Online FINE

Lezione 5 Princìpi di correlazione Gestione degli incidenti informatici Modulo 1 - Introduzione. Incidenti informatici, Princìpi di Log analysis Unità didattica 2 - Struttura di un log, e tecniche di correlazione Nome docente: Dario V Forte, CISM, CFE Università degli Studi di Milano - Ssri - CDL ONLINE

Abstract Fornire agli studenti un overview sulla gestione dei log files, con particolare riferimento alla loro correlabilità. Il presente materiale è di copyright Dario Forte e Eoghan Casey Università di Milano SSRI Online

Reconstruction using logs One source of data may not be reliable Seek corroborating data on network Data reduction Charts and summarized lists Put together pieces of puzzle Functional analysis (how) Relational analysis (where) Temporal analysis (when) Create a picture of what happened Università di Milano SSRI Online

Data Reduction Daily summary of NT Security Logs Failed attempts on many machines Incident Response: individual account activity Università di Milano SSRI Online

Functional analysis (how) Firewall blocks external connections Attack must have been launched from within Logs help determine how this happened Università di Milano SSRI Online

Relational analysis (where) Which machines connected to target Logs used to create host connection map Università di Milano SSRI Online

Temporal Analysis Understanding When When (combined with relational) Università di Milano SSRI Online

Correct for different time zones Correct for incorrect system clocks Look out for tampering Gaps Out of sequence entries Log correlation tips Università di Milano SSRI Online

Time Pattern Analysis Mon Tues Wed Thurs Fri Sat Sun 8am 9am 10am x 11am x 12pm 1pm 2pm 3pm 4pm 5pm x x x x x 6pm 7pm Università di Milano SSRI Online

Shows spikes at certain points Highlight unusual gaps Event histograms Università di Milano SSRI Online

Abbiamo visto: Esistono vari modelli di correlazione Ricordate che: È importante sia lo studio del metodo sia della timeline Infine: In sintesi Esistono dei fattori/parametri di dipendenza relativi a alla correlazione. Bisogna fare comunque attenzione al mantenimento del dato grezzo. Università di Milano SSRI Online FINE

Lezione 6 RFC Di riferimento Gestione degli incidenti informatici Modulo 1 - Introduzione. Incidenti informatici, Princìpi di Log analysis Unità didattica 2 - Struttura di un log, e tecniche di correlazione Nome docente: Dario V Forte, CISM, CFE Università degli Studi di Milano - Ssri - CDL ONLINE

Fornire agli studenti un overview sulle RFC relative alla gestione degli Incidenti informatici Abstract Con riferimento al metodo Con riferimento ai log Con riferimento alle digital evidences. Università di Milano SSRI Online

Con riferimento al metodo Per metodo si intende il flusso di eventi e la loro gestione, da una prospettiva di alto livello. Allo stato attuale la RFC di riferimento è la 2350 a: Essa contiene una serie di riferimenti specifici Organizzazione dei response team Sicurezza delle comunicazioni Uniformità di metodi e modulistica Università di Milano SSRI Online

La RFC2350 Pur non essendo recentissima, ha dei princìpi di alto livello. Pertanto è assolutamente attuale: Viene spesso usata come documento master, anche da standard di gestione predica dei princìpi fondamentali, come : la comunicaione coordinata, la sicurezza dei sistemi di base, la rapidità di intervento. È coordinable con una serie ulteriori di documenti e standard. Università di Milano SSRI Online

Con riferimento ai log Le RFC relative al log management sono fondamentalmente quelle legate al syslog, quindi 3194 3195 Esse si differenziano tra loro in base al tipo di livello a cui approcciano lo standard. La 3194 specifica il syslog in quanto tale La 3195 si occupa di autenticazione e comunicazione sicura dei messaggi Università di Milano SSRI Online

Con riferimento alle digital evidences Guidelines for Evidence Collection and Archiving, rfc 3227 Creata nel 2002, può essere considerata alla stregua della 2350 in quanto a prospettiva di valutazione e metodo di approccio al problema Ancora in parte attuale Linee guida e di principio. Università di Milano SSRI Online

Future RFCs Xxxx, trattasi di RFC relativa al set di specifiche FINE, che comprende una serie di meta linguaggi utili all interscambio di informazioni tra Incident Response team. Basato su standard denominati IODEF RID Sono basati su XMl e in questo momento frutto del lavoro dell INCH working group della IETF, Università di Milano SSRI Online

Abbiamo visto: Esistono vari modelli di RFc, alcuni sono apparentemente obsoleti Ricordate che: In sintesi Ogni settore dell incident response ha delle Rfc di riferimento, dal management alla gestione delle digital evidences Infine: Esistono degli sviluppi in tema di interscambio di informazioni, basati sull output di INCH workgroup. Università di Milano SSRI Online FINE

Lezione 1 I fields di un log per le investigazioni 1 Gestione degli incidenti informatici Modulo 2 - Sistemi di Logging a livello sistema, Sistemi di Logging a Livello Rete, Sistemi di Intrusion Detection Unità didattica 2 - Requisiti di Log Dario V Forte, CISM, CFE Università degli Studi di Milano - Ssri - CDL ONLINE

Requisiti di Log Con il termine Log Management s intende l insieme di attività tecnico/metodologiche che trattano: la generazione dei log la loro acquisizione, memorizzazione, rotation e retention i metodi di tracciamento e di definizione delle informazioni

I file di log sono necessari per: Scopo dell attività di logging allertare chi di dovere, circa attività sospette determinare l estensione dell attività dell intrusore fornire informazioni in merito ai procedimenti investigativi aiutare ai fini del ripristino dei sistemi danneggiati

Sorgenti di Log Una delle prime attività che devono essere affrontate è identificare quali sono le informazioni d interesse che si intende registrare e dove reperirle. Alcune sorgenti d informazione sono: device di rete (routers, switch, etc) intrusion detection systems firewall applicazioni

Eterogeneità dei vari formati di log Differenti sistemi producono differenti formati di log. In alcuni casi i dati prodotti non sono sufficienti ed è quindi necessario sopperire a queste mancanze con opportuni accorgimenti. Alcuni dei formati di log più utilizzati sono: Syslog (RFC3164) Event Log sistemi Windows Common Log Format e Combined Log Format per i webserver wtmp/utmp su sistemi unix-like

Carenze insite nel formato di log 1/2 In alcuni casi i dati prodotti non sono sufficienti ed è quindi necessario sopperire a queste mancanze con opportuni accorgimenti. Consideriamo tale esempio riportante una entry in formato syslog: Nov 4 17:09:04 localhost lookupd[47]: NetInfo connection failed for server 127.0.0.1/local Non viene contemplato nessun riferimento all anno di produzione di tale evento.

Carenze insite nel formato di log 2/2 E necessario integrare i campi mancanti oppure in alcuni casi modificare le impostazioni di come gli eventi sono registrati all interno dei file di log. A seconda della tipologia di device che ci si trova di fronte è possibile seguire una delle due strade. E possibile che la sorgente di log supporti un solo formato non personalizzabile, il che costringe a trovare soluzioni alternative (ad esempio basate su qualche meccanismo presente sulla macchina adibita alla raccolta dei messaggi).

Baseline delle attività Verificare il funzionamento della rete nei primi giorni d attività e nei periodi di test è uno dei fattori di raccolta informazioni più importanti. Tali dati raccolti, definiti fidati, contengono informazioni circa il comportamento del sistema durante la normale attività e durante i momenti di picco. E impossibile individuare eventi sospetti senza conoscere a priori quali siano gli eventi prodotti nel network in situazioni di normale operatività (baseline).

Requisiti forensi 1/2 E possibile utilizzare procedure e metodi tipici della disciplina forense al fine di tracciare il momento, l importanza e le conseguenze scatenate da una violazione alla sicurezza e cercare di identificare l utente, o il sistema, responsabile di tale azione. L analisi forense deve provvedere a fornire un elenco esauriente degli eventi d interesse proveniente da uno o più computer coinvolti nell incidente. Il sistema utilizzato per le analisi deve essere in grado di trattare grandi moli di dati.

Requisiti forensi 2/2 Per poter rispondere ad alcune delle domande appena poste è necessario procedere alla memorizzazione di alcune informazioni quali: riferimenti temporali macchina coinvolta dettaglio operazioni/cambiamenti effettuati A seconda poi del preciso formato utilizzato da ciascuna sorgente e dal caso particolare devono venire valutate ulteriori informazioni.

Abbiamo visto: In sintesi All interno di una struttura di rete complessa esistono più sorgenti di log che producono un insieme di informazioni spesso in formati eterogenei. Ricordate che: Un attività di baseline degli eventi in condizioni di normale operatività aiuta ad individuare situazioni sospette. Infine: E necessario che le entry contengano alcuni campi fondamentali per la successiva analisi e correlazione delle informazioni registrate. FINE

Lezione 2 I fields di un log per le investigazioni 2 Gestione degli incidenti informatici Modulo 2 - Sistemi di Logging a livello sistema, Sistemi di Logging a Livello Rete, Sistemi di Intrusion Detection Unità didattica 2 - Requisiti di Log Dario V Forte, CISM, CFE Università degli Studi di Milano - Ssri - CDL ONLINE

Riferimenti Temporali 1/2 Durante il suo funzionamento ogni dispositivo si preoccupa di generare i log e associare ad ogni entry un determinato istante temporale che caratterizza l evento. Per questo motivo è bene configurare gli apparati che faranno parte della stessa rete in modo che utilizzino un comune riferimento temporale. Due approcci possibili: Windows Time Protocol NTP

Riferimenti Temporali 2/2 Windows Time Protocol: nei sistemi operativi della famiglia NT (NT, 2000, XP, 2003) è incluso un client SNTP (servizio W32Time) che può essere utilizzato per sincronizzare il sistema senza dover installare software aggiuntivi. NTP: una delle metodologie più utilizzate per mantenere la sincronizzazione temporale su sistemi *NIX/*BSD è l utilizzo del demone ntpd, che solitamente è già incluso all interno della suite applicativa a corredo del sistema operativo. Quando è necessario raccogliere e correlare i log provenienti da zone geografiche distinte risulta necessario che ogni informazione temporale sia accompagnata dalla timezone di appartenenza.

Macchina coinvolta All interno della entry prodotta deve venire riportato l identificativo del sistema che ha prodotto al stessa. Una macchina può venire identificata, nella maggio parte dei casi con uno dei tre seguenti modi: nome DNS nome NetBIOS indirizzo IP L ultima opzione è quella da preferire rispetto alle altre citate.

Corpo del messaggio La parte più corposa ed informativa della entry è quella che comprende una spiegazione dell evento. In questo spazio trovano posto indicazioni sul programma o processo generante il messaggio e una descrizione esaustiva della notifica prodotta.

Altre considerazioni Fino a questo momento si è sottointeso il fatto che il formato con cui le varie entry vengono memorizzate sia testuale; questo non è sempre vero. Esistono device o applicazioni che producono log in formato proprietario non intelleggibile o binario se non con appositi strumenti forniti dal produttore stesso. Va verificata la possibilità di convertire tale formato ad un formato testuale, preoccupandosi di conservare comunque il formato originale.

Un esempio pratico: Cisco logging 1/2 I dispositivi di rete Cisco (router, switch, access point) che montano versioni dello IOS della serie 12.x hanno la possibilità di generare messaggi syslog. Sono però necessari alcuni accorgimenti per produrre messaggi di buona qualità. abilitazione della sincronizzazione temporale inclusione dei riferimenti temporali nel messaggio inclusione dell interfaccia da cui proviene il messaggio invio dei messaggi generati ad un log collector remoto

Un esempio pratico: Cisco logging 2/2 Router#configure terminal Router(config)#clock timezone EST -5 Router(config)#clock summer-time EDT recurring Router(config)#ntp server 192.168.0.1 Router(config)#end Router# Router(config)# logging on Router(config)# logging 192.168.0.10 Router(config)# service timestamps log datetime locatime Router(config)# logging source-interface type number

Campi su cui effettuare correlazione Una volta analizzato il formato prodotto da una sorgente di log ed incluso i campi minimi al fine di garantire la minima rispondenza ai requisiti per un analisi a posteriori è possibile procedere ad una correlazione fra diversi log sulla base: dei riferimenti temporali sull indirizzo sorgente che ha generato il messaggio

Abbiamo visto: In sintesi Quali siano i campi minimi al fine di garantire una buona costruzione di una entry di log. Ricordate che: E bene che i dispositivi utilizzino un medesimo riferimento temporale. Infine: Avendo un minimo comune denominatore sul formato di log prodotto da una molteplicità di dispositivi facilita la correlazione fra diverse fonti. FINE

Lezione 1 Struttura Generale di un Architettura Gestione degli incidenti informatici Modulo 1 - Introduzione. Incidenti informatici, Princìpi di Log analysis Unità didattica 3 - Architetture di log e requisiti Nome docente: Dario V Forte, CISM, CFE Università degli Studi di Milano - Ssri - CDL ONLINE

Obiettivo dell Unità didattica Fornire un'overview su come sono strutturate le architetture di log e i relativi requirements La lezione nr 1 e la lezione nr 2 sono con slides in lingua inglese. Copyright Dario Forte, 2004/2006. Università di Milano SSRI Online

Log analysis: the basis Every IT/Network Object can generate a log The log itself can be used either for Intrusion Detection and Network Forensic purposes However, while from an IDS standpoint it could be not that important, for a Network Forensic Examiner a log Must guarantee: Integrity Time Stamping Normalization and Data Reduction Università di Milano SSRI Online

The Integrity Issue (1) Acquisizione Trasmissione/Relay Collecting Storage Università di Milano SSRI Online

The Integrity Issue (2) Log Integrity could be violated in several ways: #Hijacking the connection between two channels (lack of encryption) #IP Spoofing (Syslog attack) Some Possible solution could be: #RFC 3195 #Using SCP #Using Cryptcat (Mostly Used) #Using Syslog NG Università di Milano SSRI Online

The Integrity Issue (3) To Hash or Not to Hash: This is the question. The theory claims that a single hash for each log entry should be done Other problems related to log integrity are the Ätomicity of the log entry The Trustworthyness of the log file (Final Record Message) Università di Milano SSRI Online

The TimeStamping Issue Time stamping is important for two reasons: atomicity and correlation. Major issues in this field are: lack of syncronization and lack of an uniform time zone. Università di Milano SSRI Online

It can be solved in two ways: Lack of syncronization Using Atomic Watches placed ouside the LAN Using NTP with one fundamental issue: NTP must be NOT Accessible from outside Using Appliances Università di Milano SSRI Online

Abbiamo visto: In sintesi Esistono dei problemi di base sulle architetture di log Ricordate che: Ogni log deve garantire, tra l altro, autenticità e metodiche di sincronizzazione Infine: Esistono dei protocolli in grado di mitigare il problema, che si consiglia di supportare comunque con hardware appropriato. Università di Milano SSRI Online FINE

Lezione 2 Architettura, Integrità di log e Firma digitale dei log Gestione degli incidenti informatici Modulo 1 - Introduzione. Incidenti informatici, Princìpi di Log analysis Unità didattica 3 - Architetture di log e requisiti Nome docente: Dario V Forte, CISM, CFE Università degli Studi di Milano - Ssri - CDL ONLINE

Obiettivo della lezione Fornire un'overview su come sono strutturate le architetture di log e i relativi requirements La lezione nr 1 e la lezione nr 2 sono con slides in lingua inglese. Copyright Dario Forte, 2004/2006. Università di Milano SSRI Online

Università di Milano SSRI Online A possible example of log Architecture

Log Architecture: some info We use libpcap compatibile format (TcpDump, Ethereal) In presence of Tcp Based Connection it could be possible to give another layer of timestamping using the specification of RFC 1072 and 2018 enabling SackOK option (Selective AcknowledgementOK) We use GMT Time zone Università di Milano SSRI Online

The Normalization and Data Reduction Problem (1) Normalized Output (using a dedicated Engine) W3C LogFile Libpcap LogFile Propetary App LogFile Università di Milano SSRI Online

The Normalization, Data Reduction and Integrity problem Normalized Output W3C LogFile Libpcap LogFile Propetary App LogFile Secure repository Secure repository Secure repository Università di Milano SSRI Online

Correlating and Presenting Events Gui Tp Correlation Engine/Event Filter Normalization Engine 1 Normalization Engine 2 Tp= Tunneling and Auth Protocol (es Ipsec) Università di Milano SSRI Online Tp

Log Acquisition Tools: requirements Tcpdump support (import and export) MD5/Sha 1 Support Data reduction and Data Recovery Capability Covert Channels Detection capability Read Only During Collection and Examination. Complete Collection. Security Università di Milano SSRI Online

An Example of Practical Implementation: The IRItaly Project IRItaly was Born in 2001 at Crema Research Center (University of Milano) More than 20 people involved A Document with Procedures for Incident response and Forensics A First Response CdRom The Italian Chapter of Honeynet Project Università di Milano SSRI Online

IRItaly Test Bed Iritaly workstation With CDRom Cryptcat Based Connection Tx = Iritaly Cd Booted Machine T2 T1 T3 Università di Milano SSRI Online

Disk Forensics Supports NTFS, Ext2, FFS and FAT. IRItaly Project: features Supports many different image file formats, including sgzip (compressed image format), Encase's Expert Witness format, as well as the traditional dd files. Advanced timelining which allows complex searching NSRL hash support to quickly identify files Windows Registry support, includes both win98 variant as well as the Window NT variant Unstructure Forensics capability allows recovery of files from corrupted or otherwise unmountable images by using file magic Università di Milano SSRI Online

Network Forensics (FLAG) Stores tcpdump traffic within an SQL database Performs complete TCP stream reconstruction IRItaly: further steps Has a "knowledge base" making deductions about network communications Can construct an automatic network diagram based on TCPDump, or real time Log analysis Allows arbitrary log file formats to be easily uploaded to database GUI driven complex database searches using an advanced table GUI element Università di Milano SSRI Online

Abbiamo visto: In sintesi I problemi di base sulle architetture di log possono essere mitigati con interventi strutturali in fase di preparazione Ricordate che: Ogni log deve garantire, tra l altro, autenticità e metodiche di sincronizzazione Infine: Il progetto IRItaly approccia il problema, almeno dal punto di vista prototipale, basandosi su opensource tools. Università di Milano SSRI Online FINE

Lezione 3 Misure di protezione e trasmissione dei log files Gestione degli incidenti informatici Modulo 1 - Introduzione. Incidenti informatici, Princìpi di Log analysis Unità didattica 3 - Architetture di log e requisiti Nome docente: Dario V Forte, CISM, CFE Università degli Studi di Milano - Ssri - CDL ONLINE

Obiettivo della lezione Fornire un'overview sui metodi di protezione e trasmissione dei files di log, all interno di un architettura. Università di Milano SSRI Online

Standard di sviluppo (2) Deve essere specificata una soluzione alternativa per i Log principali- Detta selezione deve essere gestire: centralizzazione firma (Elettronica e/o Digitale) fsum (hash) rotazione (at) Università di Milano SSRI Online

Requisiti richiesti A prescindere dalla decisione finale, nel caso siano richiesti dagli organi competenti, i log devono rispondere a determinati requisiti per la validità legale: I log file devono essere raccolti e conservati nel loro formato originario Nessuna modifica inerente: Informazioni contenute nel log Time stamp del log file creato Nessuna tecnica di normalizzazione sui log file originali Inoltre, l architettura di log deve essere in grado di generare alert Università di Milano SSRI Online

Struttura della Log Farm Si consiglia di solito la realizzazione di un architettura di logging basata su sistema operativo *nix e sull uso del demone syslog (syslog-ng): Cluster di DUE macchine (ridondanza a livello di sistema) Non indispensabile, ma consigliata, tecnologia RAID (ridondanza a livello di disco) Successivo storage. Università di Milano SSRI Online

Università di Milano SSRI Online Struttura della Log Farm (2)

Requisiti e consigli software di struttura Si consiglia l uso dei seguenti componenti software : Sistema operativo: Linux Un servizio affidabile di raccolta Un servizio affidabile di sincronizzazione Un servizio affidabile di rotazione Controllo di integrità Un servizio affidabile di gestione della confidenzialità Università di Milano SSRI Online

Requisiti di implementazione Dove possibile : Utilizzare trasmissione su protocollo TCP Inserire nel messaggio l ip o l host che lo ha generato Mantenere sincronizzati apparati e sistemi di logging (NTP o NetTime Service) Trasmissioni crittate dei dati tramite: L utilizzo di Secure Shell (SSH) L utilizzo di Secure Socket Layer (SSL) Università di Milano SSRI Online

Rotation Processo di Rotation : Ad ogni istante prestabilito di tempo o quando viene raggiunta una dimensione massima avvenga la chiusura di un file di log Compressione del file prodotto Generazione di un valore di hash del file (SHA1, MD5) che ne provi l integrità anche dopo lo spostamento e copia su diversi dispositivi Invio dell archivio verso sistema di raccolta centralizzato Università di Milano SSRI Online

Rotation (2) Implementazione di un meccanismo automatizzato per la registrazione delle attività prodotte durante la gestione dei log: Data e ora di inizio e fine operazione Motivazione della rotation: scadenza quanto di tempo o dimensione massima raggiunta Sorgente di log da archiviare Destinazione del log file Università di Milano SSRI Online

Conservazione Le procedure di storing dei log devono rispettare la seguente metodologia: A intervalli di tempo ben definiti deve essere realizzato un archivio dei i dati da conservare Di tale archivio deve essere calcolato il codice hash, tale codice deve essere salvato su file e inserito nel supporto insieme all archivio L archivio generato deve essere firmato con gli applicativi del caso (es. PGP) Il supporto generato va quindi riposto in luogo fisicamente sicuro Università di Milano SSRI Online

Abbiamo visto: In sintesi Le soluzioni di gestione dei log devono prevedere dei meccanismi di protezione Ricordate che: Ogni log deve garantire, tra l altro, autenticità e metodiche di sincronizzazione Infine: Lo storage e la ridondanza hanno un ruolo molto importante. Università di Milano SSRI Online FINE

Lezione 4 Granularità ed Atomicità degli eventi Gestione degli incidenti informatici Modulo 1 - Introduzione. Incidenti informatici, Princìpi di Log analysis Unità didattica 3 - Architetture di log e requisiti Nome docente: Dario V Forte, CISM, CFE Università degli Studi di Milano - Ssri - CDL ONLINE

Obiettivo della lezione Fornire un'overview sul significato del singolo evento in relazione al log grezzo. Università di Milano SSRI Online

Con il termine Granularità si intende il livello di dettaglio di registrazione di log event. Granularità La granularità viene di solito predefinita dal vendor (in caso di soluzione proprietaria), o dall utente durante la fase di preparazione. Il concetto di granularità non va confuso con quello di atomicità dell evento. Università di Milano SSRI Online

Granularità Vs. Atomicità Granularità Atomicità Riguarda i field e la fase di preparazione, parte della letteratura la associa al concetto di log scheme Riguarda la capacità di registrazione degli eventi. Università di Milano SSRI Online

Il concetto è legato alla capacità di: Atomicità degli eventi Registrare tutti gli eventi Essere certi che gli eventi stessi siano autentici e non modificati (No tampering) Il concetto di atomicità è estremamente importante per la letteratura (Schneier/Kelsey 2001) ma meno applicabile nel mondo reale. Ove non possibile raggiungere l ottimale atomicità dell evento si opta per l affidabilità dei log in quanto tali. Università di Milano SSRI Online

Alcuni concetti correlati all atomicità. Ogni singolo evento generato deve essere acquisito e registrato. Ogni evento registrato deve avere un timestamping supportato da crittografia e integrità. Su quest ultimo esistono degli esperimenti e dei prototipi, anche di applicazione industriale. Università di Milano SSRI Online

Abbiamo visto: In sintesi Esiste una differenza tra Granularità ed Atomicità dell evento Ricordate che: Esse si decidono in due momenti differenti della generazione architettura di log Infine: esistono alcuni metodi di gestione dell atomicità, che rimane comunque un obbiettivo non facilmente raggiungibile, almeno senza compromessi. Università di Milano SSRI Online FINE

Lezione 1 Come operano gli IDS 1 Gestione degli incidenti informatici Modulo 2 - Sistemi di Logging a livello sistema, Sistemi di Logging a Livello Rete, Sistemi di Intrusion Detection Unità didattica 3 - IDS Dario V Forte, CISM, CFE Università degli Studi di Milano - Ssri - CDL ONLINE

Intrusion Detection System: Overview I sistemi di Intrusion Detection System sono passati dall essere strumenti di uso esclusivo dei laboratori di ricerca e università ad essere considerati uno degli strumenti di maggior impiego nella cybersecurity moderna. Ciò che si prefigge di svolgere un IDS è, come traspare dal termine, l individuazione di un eventuale intrusione. Tale obbiettivo è tutt altro che banale e alcuni ricercatori spesso fanno riferimento a tali sistemi etichettandoli come attack detection system, enfatizzando sul fatto che, allo stato attuale, la maggior parte delle tecnologie permette unicamente di rilevare un eventuale exploit verso un sistema.

Principi di funzionamento di un IDS 1/2 Il principio su cui basano il loro funzionamento gli IDS, indipendentemente dalla loro tipologia, sono sostanzialmente due: confronto di un evento con una base di conoscenza in modo da produrre in uscita una valutazione della bontà o meno dell evento analisi delle anomalie dell evento rispetto alla normale attività Esistono anche soluzioni ibride intermedie.

Principi di funzionamento di un IDS 2/2 Appare immediato come i primi eseguano un confronto fra il dato con un repository di dati preclassificati come benigni o maligni. Questa base di dati può venire man mano aggiornata e non sono necessarie pre-conoscenze per implementare una tale situazione. Il secondo approccio invece utilizza un periodo di training sulla base del quale impara a classificare, con l interazione di un operatore, gli evento come normale o sospetto. Tale approccio è più efficiente ma richiede un tempo di training che talvolta non può venire effettuato.

Falsi positivi e falsi negativi Un IDS perfetto è quello che riesce ad individuare tutte e sole le intrusioni. A seconda della tipologia di errore commesso da parte dell IDS nella valutazione di un evento sono possibili due situazioni: l IDS rileva qualcosa di anormale ma non è avvenuta alcuna intrusione (falsi positivi) l IDS non rileva un intrusione avvenuta (falsi negativi) Ovviamente la situazione più grave è la seconda, ma anche un eccessiva presenza di falsi positivi potrebbe produrre un elevato numero di eventi, rendendo arduo il lavoro agli incaricati dell audit.

Tipologie di IDS Esistono diverse tipologie di IDS che si differenziano in base al livello a cui approcciano al problema. Alcuni lavorano a livello di rete, altri a livello di filesystem ed altri ancora lavorano a livello applicativo. Si delineano le seguenti tipologie: Network Intrusion Detection System (NIDS) Host Intrusion Detectio System (HIDS) Application-based IDS (AIDS)

Network Intrusion Detection System Sono solitamente considerati come dispositivi di rete passivi che monitorano l intera sottorete da attacchi verso le macchine connesse. Come già precedentemente accennato possono utilizzare un database di signature di attacchi od una serie di algoritmi per rilevare delle anomalie nel traffico di rete. E fondamentale il corretto posizionamento di tali strumento in maniera da renderne effettivo il suo impiego.

Host Intrusion Detection System Controllano il traffico da e verso particolari sistemi, monitorano gli eventi di sistema e alcuni file sensibili dello stesso. Alcuni sistemi utilizzano un analisi euristica delle signature, controllano le attività dell utente avvisando gli amministratori o i responsabili della sicurezza d eventuali usi impropri delle risorse. I maggiori vantaggi di tale strumento riguardano il fatto che possono rilevare anomalie che possono sfuggire ai NIDS.

Application-based IDS Rilevano il comportamento sospetto di un utente che tenta di abusare delle sue autorizzazioni ed analizzano gli eventi generati da una singola applicazione software. Ovviamente tale applicazione deve essere in grado di generare un qualche tipo di log applicativo. Questi strumenti permettono, nella maggior parte dei casi, di avere una granularità tale da poter risalire al singolo comando impartito dall utente.

NIDS Confronto fra le diverse soluzioni 1/2 + permettono di dare una visione d insieme dei diversi eventi generati nel segmento di rete ove sono stati collocati + possibilità di ottenere in maniera semplice un incremento del livello di sicurezza - su reti switchate necessitano hardware specializzato per controllare le comunicazioni (network TAP, SPAN Port, etc.) - difficoltà con link ad elevate velocità - inefficaci in presenza di traffico cifrato (a meno di non utilizzare particolari soluzioni)

HIDS Confronto fra le diverse soluzioni 2/2 + possono rilevare anomalie che sfuggono ad un NIDS + non soffrono delle problematiche legate all analisi del traffico di rete in quanto risiedono sull host - visione ristretta al singolo host e difficoltà di gestione se la base d installazione è vasta. - essendo il sensore installato sul sistema, esiste la possibilità di disabilitare il sensore stesso se il sistema viene compromesso AIDS + livello di granularità sulle operazioni molto basso - i log di livello applicativo sono meno protetti rispetto a quelli di sistema

Abbiamo visto: In sintesi Quale scopo si prefigge un IDS e quali tecniche impiega per raggiungere tale scopo. Ricordate che: Esistono una molteplicità di tali strumenti ognuno dei quali affronta il problema a livelli differenti. Infine: E necessario valutare approfonditamente, in base allo scopo che ci si prefigge, le capacità e le limitazioni di ciascuna soluzione prima di realizzarle sul campo. FINE

Lezione 2 Come operano gli IDS 2 Gestione degli incidenti informatici Modulo 2 - Sistemi di Logging a livello sistema, Sistemi di Logging a Livello Rete, Sistemi di Intrusion Detection Unità didattica 3 - IDS Dario V Forte, CISM, CFE Università degli Studi di Milano - Ssri - CDL ONLINE

Network Intrusion Detection System Il compito di un NIDS è quello di analizzare il traffico che transita nel segmento di rete a cui è connesso e classificarlo sulla base di determinati parametri. signature-based anomaly-based I primi esaminano il traffico e lo confrontano con un repository di firme di attacchi riconosciuti. La loro decisione si basa su di un set di firme. Al contrario i secondi basano la propria scelta sull analisi delle anomalie. Ovvero se uno o più flussi non rispettano determinati standard, il sistema segnala l'errore con il consueto allarme. Esistono anche altri approcci, nonché soluzioni ibride.

Strumenti esistenti Esistono una molteplicità di strumenti che realizzano tale funzione, sia in ambiente commerciale sia nel mondo open-source. Tenable Network ISS RealSecure Symantec Sygate snort prelude bro

Snort 1/3 É uno strumento gratuito, leggero, modulare capace di effettuare analisi di traffico real-time su reti IP. Le caratteristiche principali: protocol analysis/decoding analisi del contenuto/matching real time alerting formato di registrazione libpcap compatibile struttura a plug-in per definizione delle regole

É costituito da quattro componenti principali: Snort 2/3 il processo in ascolto sul canale adibito alla cattura del traffico il preprocessore il detection engine il motore di alerting capace di generare messaggi in una molteplicità di formati

Snort 3/3 Preprocessore, Detection Engine, Output sono plugin che possono essere riscritti o modificati per adattare meglio snort alle esigenze dell utilizzatore.

Snort: il processo di sniffing Utilizza la modalità promiscua dell interfaccia di rete per catturare tutto il traffico in transito.

Snort: preprocessore Controlla se i pacchetti passati dallo sniffer soddisfano determinate regole in base a una serie di plug-in scelti dall utente. Nel caso in cui il controllo sia positivo vengono inoltrati al Detection Engine.

Snort: detection engine Ricerca le corrispondenze (matching) tra i dati passati dal preprocessore e un insieme di regole (knowledge-base); nel caso in cui siano verificate i pacchetti vengono inoltrati all alert processor. Le regole sono basate su "firme" e ordinate in categorie. Per mantenere efficiente lo strumento tali regole devono essere aggiornate.

Snort: motore di alerting Snort supporta una molteplicità di formati per la registrazione degli eventi. A seconda del caso e delle necessità va valutato quale, o quali, plug-in abilitare. Ognuno dei formati di registrazione va valutato alla luce di quanto discusso nella precedente unità didattica. syslog (locale o remoto) registrazione del traffico in formato libpcap output su database (MySQL, Oracle, Postgre,etc)

Abbiamo visto: In sintesi Alcuni esempi di NIDS in circolazione descrivendo in modo particolare Snort. Ricordate che: Anche gli strumenti di NIDS utilizzano approcci o signature-based o anomaly-based per effettuare le proprie valutazioni; snort in particolare la prima tipologia di approccio. Infine: E bene anche valutare il formato, o i formati, che lo strumento supporta per la produzione dei messaggi di alert. FINE

Lezione 3 Come operano gli IDS 3 Gestione degli incidenti informatici Modulo 2 - Sistemi di Logging a livello sistema, Sistemi di Logging a Livello Rete, Sistemi di Intrusion Detection Unità didattica 3 - IDS Dario V Forte, CISM, CFE Università degli Studi di Milano - Ssri - CDL ONLINE

Host Intrusion Detection System Anche in questo caso, come nel caso degli strumenti di NIDS, si hanno una molteplicità di soluzioni fra le quali è possibile decidere. Tripwire Osiris Samhain NIDES ISS Real Secure Symantec Host IDS Enterasys Dragon Squire

Un esempio di HIDS: Tripwire E un programma basato su policy che controlla l integrità di file e directory, rilevando eventuali modifiche degli stessi tramite il confronto con le informazioni precedentemente salvate. Tali informazioni sono memorizzate all interno di un database crittato. Ogni discrepanza fra i file attualmente presenti sul sistema e l immagine, solitamente sottoforma di hash, degli stessi presente nel db è segnalata e loggata in un report.

Come funziona Tripwire 1/3 Per usufruire delle funzionalità di questo HIDS è necessario procedere con i seguenti passi: Inizializzazione del database si crea il database degli oggetti presenti nel sistema; una sorta di fotografia dello stesso. In questa modalità Tripwire legge le policy definite in un file di configurazione e sulla base delle stesse genera il relativo db crittato. Controllo dell integrità Dopo la costruzione del db viene scandito il sistema alla ricerca di violazioni, come specificato nel file di policy. Usando le regole di tale file, Tripwire confronta lo stato attuale del file system con quello salvato nel database.

Come funziona Tripwire 2/3 Aggiornamento del database delle firme Permette di aggiornare il contenuto del database sulla base delle informazioni presenti nel report di controllo di integrità. Aggiornamento delle policy Viene utilizzato quando si necessità di modificare o aggiornare le policy e di conseguenza aggiornare il database. Modalità di prova Serve per testare l effettivo funzionamento della policy implementata e diagnosticare il corretto funzionamento del motore di alert.

Come funziona Tripwire 3/3

L evoluzione degli HIDS 1/2 Un evoluzione degli strumenti di HIDS consiste nel mantenere un repository centralizzato contenente il database delle firme e le policy di configurazione; si richiede unicamente di installare sui sistemi da monitorare un agente. Questo agente procederà nella verificare, a scadenze temporali predefinite, l integrità dei file o cartelle da monitorare in base alle policy definite. In questo modo è possibile agevolare e gestire in maniera centralizzata i log prodotti dai diversi agenti, richiedendo che gli stessi inviino eventuali violazioni al repository centrale (sottoforma di messaggi syslog o come record di database).

L evoluzione degli HIDS 2/2 Alcuni vantaggi che porta questo nuovo modello sono: gestione centralizzata delle configurazioni degli agenti l eventuale arresto di un agente su un sistema perché lo stesso viene compromesso è facilmente rilevabile possibilità di centralizzare anche le informazioni prodotte dai risultati del controllo dell integrità del file-system o di particolari contenuti nelle entry dei log di sistema

Samhain 1/2 Uno strumento open-source che utilizza l approccio appena descritto è Samhain. Questo strumento multipiattaforma è in grado di gestire l intergità di file e di fornire funzionalità di HIDS in maniera centralizzata. Unix Linux Windows (Cygwin) E concepito per monitorare una molteplicità di host, potenzialmente con differenti sistemi operativi, da una locazione centrale; in alternativa può anche funzionare come applicativo stand-alone.

Alcune caratteristiche di questo strumento sono: Samhain 2/2 architettura client-server che permette una gestione centralizzata delle attività central logging central storage delle configurazioni Aggiornamento centralizzato delle policy console di gestione web (Beltane) possibilità di supportare una molteplicità di logging faility, ognuna delle quali può venire configurata individulamente Tamper-resistant logfile Syslog Databse (MySQL, Postgre, Oracle, etc)

Informazioni addizionali Una comparazione delle funzionalità dei più diffusi strumenti di HIDS a livello open-source è disponibile all indirizzo http://www.la-samhna.de/library/scanners.html Si consiglia di prendere visione in modo particolare delle varie opzioni di logging di ogni strumento.

Abbiamo visto: In sintesi Alcuni esempi di HIDS descrivendo in modo particolare Tripwire e Shamhaian. Ricordate che: Solitamente l approccio più utilizzato è la verifica di particolari file sensibili con un immagine fidata degli stessi eseguita in un istante temporale precedente. Infine: Come tutte le tecnologie anche gli strumenti di HIDS si evolvono e cercano di migliorare cercando di aggiungere maggiori funzionalità e sopperendo ad eventuali carenze FINE

Lezione 4 Come operano gli IDS 4 Gestione degli incidenti informatici Modulo 2 - Sistemi di Logging a livello sistema, Sistemi di Logging a Livello Rete, Sistemi di Intrusion Detection Unità didattica 3 - IDS Dario V Forte, CISM, CFE Università degli Studi di Milano - Ssri - CDL ONLINE

Application-based IDS: Overview 1/2 Dopo aver analizzato gli approcci a livello di trasporto dati e di singolo sistema alcune caratteristiche tipiche dei sistemi IDS appaiono chiare. Questa tecnologia è concettualmente abbastanza recente comparata a soluzioni NIDS e HIDS; tali strumenti basano la loro validità sulla definizione di concetti quali relazione, entità osservabile, relazione statistica e soglia.

Application-based IDS: Overview 2/2 Relazione: espressione di come due o più entità siano associate. Entità osservabile: qualsivoglia oggetto, come un utente, un dato, una risorsa, che produce ho possiede un determinato valore che può venire utilizzato per definire una relazione. Relazione statistica: può venire utilizzata per confrontare il valore corrente di un entità con un profilo, ovvero una collezione d informazioni statistiche caratterizzanti comportamenti normali od anomali. Soglia: determina come il risultato prodotto da una relazione debba venire interpretato; valori sotto un determinato valore di soglia risultano normali mentre quelli al di sopra risultano anomali.

App-IDS: come funzionano 1/2 In quanto gli AIDS fondano la loro valenza sul concetto di relazioni per la rilevazione delle intrusioni, debbono venire definiti alcuni meccanismi tramite i quali un App-IDS acquisisca le informazioni necessarie alla valutazione di tali relazioni. In maniera analoga, un AIDS può costruire una base di eventi contenente un elenco di tutte le situazioni d interesse e, se possibile, la relativa entità che ne ha causato l occorrenza.

App-IDS: come funzionano 2/2 Queste basi d eventi possono venire generati seguendo due distinte strade. La prima consiste nello scandire e registrare, su base temporale oraria o giornaliera, tutti quei valori che sono stati modificati all interno di una registrazione d evento. La seconda alternativa prevede il ricorso all utilizzo dei così detti code triggers; i code triggers sono piccoli frammenti di codice inseriti all interno delle applicazioni stesse che all avvenire di un dato evento all interno del programma, indicato dal code trigger eseguito, causa la registrazione dei un evento all interno dell apposito log o la valutazione di una relazione. Al momento non è ancora chiaro quale dei due metodi sia preferibile in quanto entrambi presentano aspetti legati alla sicurezza e alle performance.

Application-based IDS vs HIDS 1/2 La somiglianza principale fra i sistemi HIDS e AIDS è che entrambi possono utilizzare metodi statistici e basati su regole, con un valore predefinito di soglia, per identificare eventuali intrusi. Nonostante un AIDS può utilizzare sia un approccio basato su il riscontro di anomalie che uno sul rilevamento dell utilizzo improprio del sistema, risulta chiaro come la prima opzione sia quella utilizzata più largamente ma con il supporto sia da parte delle relazioni statistiche che definite da regole.

Application-based IDS vs HIDS 2/2 AIDS possono unicamente rilevare un intrusore una volta che questi sia penetrato nel sistema e abbia ottenuto accesso all applicazione. E possibile, comunque, che talvolta siano gli utenti stessi legittimi del sistema ad abusare dello stesso.

McAfee Entercept Family 1/2 Questo prodotto è un esempio di App-IDS. Esistono versioni specifiche rivolte a differenti applicazioni come: web server database server applicazioni per ambienti desktop

McAfee Entercept Family 2/2 Nella versione per Web Server (WSE) prevede un protezione di server web come: Apache iplanet SunOne IIS Entercept rileva eventuali attacchi e violazioni alle risorse gestite dal web server prima che venga processata una transazione non autorizzata analizzando le richieste inviate allo stesso e all application programming interface (API).

Abbiamo visto: Cos è un App-IDS e come funzioni. Ricordate che: In sintesi Gli App-IDS basano la loro validità sulla definizione di concetti quali relazione, entità osservabile, relazione statistica e soglia. Infine: Comparata alle altre tecnologie viste è quella più recente e meno matura nonostante si stia svolgendo un ampio lavoro di ricerca in questa direzione. FINE

Lezione 1 Provenienza e Follow Up delle Segnalazioni Gestione degli incidenti informatici Modulo 3 - Advanced Log Analysis, First Incident Response,Digital Forensic Unità didattica 3 - First Incident Response Dario V Forte, CISM, CFE Università degli Studi di Milano - Ssri - CDL ONLINE

La provenienza delle segnalazioni Allo stato attuale la RFC 2350/3227 e la ISO 17799 richiedono la schematizzazione delle comunicazioni di incidente: Punti di raccolta Attori del processo di segnalazione Tracciamento della segnalazione

Punti di raccolta Con questo termine si indica: Il punto di contatto interno all azienda per la gestione della notifica Il punto di contatto - lato investigativo - per la ricezione delle notifiche Il punto di collection e di coordinamento tra i vari punti di raccolta.

Gli attori sono: Attori del processo di segnalazione CSIRT Legal Police CERT CC Tuttavia sono gli utenti finali ad avere un ruolo fondamentale nella fase di apertura incidente.

Tracciamento della segnalazione La segnalazione deve essere tracciabile lato ricezione. Significa che: Deve essere possibile - lato segnalatore- sapere che percorso (almeno in via preliminare) ha fatto il suo ticket. Deve essere possibile -lato ricezione - tracciare la provenienza, anche al fine di un follow up qualificato al cliente finale.

Il Follow Up Il follow up opera in due direzioni: Verso l interno Direzione sicurezza Direzioni HR, Legal etc Escalation Verso l esterno Forze di Polizia Magistratura Altre aziende Utenti finali per riscontro della segnalazione iniziale.

Modellizzazione delle segnalazioni Di solito esistono dei modelli da riempire, basati su templates derivati dagli standard citati all inizio Le informazioni dovrebbero poi essere gestite ed intercambiate tra enti omologhi, velocizzando i processi I risultati delle segnalazioni dovrebbero esser aggregati.

Privacy e sicurezza Vs. Incidenti Le segnalazioni dovrebbero essere offuscate per ovvi motivi di sicurezza. Privacy e rispetto delle normative correlate Segreto industriale (e norme correlate)

Abbiamo visto: In sintesi È importante garantire il flusso delle segnalazioni (notifiche). Ricordate che: Detto flusso è ottimale se garantito in maniera biunivoca. Infine: Lo scambio di informazioni deve essere effettuato rispettando i parametri di legge e di sicurezza. FINE

Lezione 2 Impatto e valutazione economica delle segnalazioni Gestione degli incidenti informatici Modulo 3 - Advanced Log Analysis, First Incident Response,Digital Forensic Unità didattica 3 - First Incident Response Dario V Forte, CISM, CFE Università degli Studi di Milano - Ssri - CDL ONLINE

Elementi costitutivi della gestione dell incidente: Econonics Sia la RFC 2350 sia la normativa penalistica sul computer crime, richiedono quello che in gergo viene denominato Damage Assessment. Si tratta di una serie di task effettuati per verificare e qualificare l impatto degli incidenti sugli economics aziendali. Il risultato dell assessment può avere sbocco giudiziario e/o assicurativo.

Con questo termine si indica: Il damage assessment Il conteggio dei costi sicurezza: Costo della creazione del dato relativi all incidente di Costo della Riproduzione del dato Costi associati alla effettuazione dell esame post mortem Costi associati alla gestione legale Costo associato alla tutela del marchio e dell immagine.

Metodi di calcolo dei costi Si effettuano calcoli mediante fogli elettronici predisposti e relativi a: Valore degli asset (fisici e informatici) Valore delle informazioni (intrinseco ed estrinseco) Costi uomo per il ripristino/intervento

Gli attori sono: Attori del processo di assessment CSIRT Legal HR PR IT

I costi della privacy Un incidente di sicurezza può avere un impatto sulla legge 196/2003. È possibile avere un impatto Diretto e/o Indiretto. Impatto diretto: Sanzioni previste dalla legge, costi di reggenza legale Impatto indiretto: costi di adeguamento

Tempistica del damage assessment Si tratta di un living cost, cioè di un processo continuo di revisione, fino alla chiusura dell incidente. Di solito il Damage Assessment, è effettuato con tecniche e team di composizione mista. Alcuni incidenti vedono un costo anche nella gestione del team che si occupa dell assessment medesimo.

I costi dell incidente sono detraibili? Determinazioni fiscali Estorsioni Ripristino Esami e legal Importante: la soggettività della valutazione.

La tutela giudiziaria del costo Le aziende si costituiscono di solito parte civile. Le assicurazioni, ove presenti, cercano di accodarsi e di rifarsi sull azienda attaccata. La tutela giudiziaria è anche passiva, in quanto gli esterni possono in teoria rifarsi sull azienda colpita in caso di violazioni di legge.

In sintesi Abbiamo visto: Il damage assessment è un operazione fondamentale nell incident management. Ricordate che: Si tratta di un living task. Infine: Innumerevoli i risvolti giudiziari. FINE

Lezione 3 Applicazioni dei Framework nella vita reale Gestione degli incidenti informatici Modulo 3 - Advanced Log Analysis, First Incident Response,Digital Forensic Unità didattica 3 - First Incident Response Dario V Forte, CISM, CFE Università degli Studi di Milano - Ssri - CDL ONLINE

Gli elementi costitutivi del processo: i framework I framework, per lo scopo del presente corso di studi, sono relativi a: Gestione dei processi di business Gestione dell incidente Gestione della Digital Investigation Tutti questi vanno mappati fra loro.

La gestione dei processi di business Con questo termine si indica la modalità di regolazione delle attività interne all azienda. A seconda del settore industriale in cui si trova ad operare, esiste uno standard di gestione. Uno standard è efficace nel momento in cui è realmente applicabile nel mondo reale.

L incident management a supporto della business security Uno dei requisiti di base del business è quello della continuità (Business Continuity). L incident management si prefigge, tra l altro, il supporto alla continuità, sia lato processi sia lato tecnico. Uno dei mezzi fondamentali è il Framework.

L applicazione del framework nella vita reale dell azienda La preparazione ha un valore fondamentale. Durante la fase di preparazione all incidente è possibile iniziare la mappatura tra la reazione e i processi di business. Di solito si opera facendo attenzione a: Priorità di ripristino Tutela tecnica Tutela giudiziaria

Strategia di risposta all incidente Nella gestione dell incidente, una parte importante è dedicata alla strategia di risposta. Mitigation e remediation sono due punti di una certa importanza. Nella strategia di risposta si opera anche con il Damage Assessment

Esempi di applicazione della strategia Attacchi convenzionali Fughe di notizie e frodi Atti criminali di vario genere Richieste di ausilio provenienti dall esterno

La digital investigation a supporto Uno dei casi più ricorrenti riguarda l uso della digital investigation nelle cosiddette indagini difensive Riguarda la metodica di tutela del patrimonio aziendale, per esempio: Impiegati infedeli Tutela del marchio Post mortem per hacking

I tempi medi di un investigazione digitale rapportata all incidente Ai fini della mitigation, il tempo medio va dalle 2 alle 48 ore. Ai fini della completa identificazione dell accaduto e l identificazione delle lessons learned, e in presenza delle info necessarie, il tempo di indagine non supera i 15/20 giorni. Il tempo è direttamente proporzionale all urgenza, ma è fondamentale avere tutti i dati disponibili per diminuire il tempo di reazione.

Abbiamo visto: In sintesi Esiste un rapporto diretto tra Incident Management e Business Continuity. Ricordate che: Non è possibile una reazione efficace senza una preparazione precisa. Infine: La preparazione è necessaria per accorciare i tempi di reazione, altresì alla luce del rapporto tra mitigation e soluzione definitiva. FINE

Lezione 1 Definizione del Framework Investigativo Gestione degli incidenti informatici Modulo 1 - Introduzione. Incidenti informatici, Principi di Log analysis Unità didattica 4 - Investigazioni e Metodiche Dario V Forte, CISM, CFE Università degli Studi di Milano - Ssri - CDL ONLINE

Obiettivo dell Unità didattica Fornire un overview su come sono strutturate le tecniche di investigazione. Al termine dell'unità sarà possibile ottenere una panoramica su strumenti e metodologie. Con questa lezione introduciamo al framework investigativo.

Regola Fondamentale TRATTARE OGNI INCIDENTE COME SE DOVESSE TERMINARE IN UN AULA DI TRIBUNALE

Standard Investigativi 1/2 Criminale codice procedura penale codice penale polizia/autorità giudiziaria procedibilità d ufficio o a querela

Civile preponderanza della prova meno schematico del penale Standard Investigativi 2/2 Amministrativo inchieste interne informalità arbitrati/mediatori possibili incompatibilità con lo statuto dei lavoratori.

Basic ToolKit Policies Criminal Profile Log analysis Victim Computer Analisys Email Header analysis Forensics Tools

Norme di riferimento Codice penale procedura penale Legge 196/2003 Legge 231/2001 Policy interne

Regole di acquisizione Devono poter avere valenza probatoria producibili nel normale corso del business devono essere autentiche e immodificabili chain of custody

Tainted Fruit Si tratta di fonti di prova acquisite impropriamente violazioni privacy intercettazioni abusive violazioni della legge ogni fonte di prova acquisita in questa maniera non può essere utilizzata in giudizio.

Chain of Custody Inventario delle fonti di prova acquisite durante la fase post incidente/forensic le fonti di prova devono essere sigillate, fisicamente e/o elettronicamente Time/operation stamping Sicurezza fisica della CoC Firma digitale dei dati (anche post-acquisizione)

Abbiamo visto: In sintesi Le investigazioni digitali si basano su un framework. Ricordate che: I framework sono frutto di peer review e condivisione, conosciuto anche comeconsensus. Infine: Ogni attività deve essere gestita come se un giorno dovesse avere uno sbocco giudiziario. FINE

Lezione 2 Il Framework At Glance Gestione degli incidenti informatici Modulo 1 - Introduzione. Incidenti informatici, Principi di Log analysis Unità didattica 4 - Investigazioni e Metodiche Dario V Forte, CISM, CFE Università degli Studi di Milano - Ssri - CDL ONLINE

Obiettivo della lezione Fornire un overview sul dettaglio del framework investigativo, secondo i parametri definiti da Spafford-Carrier (DFWRS 2002).

Il processo investigativo Notification Preservation Survey Search Reproduction Presentation

Preservation 1/2 La relazione tra questa fase del processo investigativo e quella di acquisizione è diretta. Questo significa che, ove possibile, esiste l obbligatorietà di gestire in maniera preservation oriented l attività di acquisizione

Preservation 2/2 Esistono dei casi in cui l acquisizione potrebbe non essere possibile: Live System Analysis File Systems di dimensioni troppo grandi File Systems di tipologie non riconosciute dallo strumento di clonazione Casi contingenti di procedura penale o di eventi esogeni

Acquisizione - Processo L originale non deve essere alterato. Bisognerà quindi operare in read-mode, con appositi strumenti di blocco in scrittura. Detti strumenti possono essere di tipo Hardware e/o software. Il processo di validazione è fondamentale in questo caso.

Strumenti di clonazione (imaging) di tipo Software Based Possono essere di tipo open-source e commerciale Quelli di tipo open-source sono fondamentalmente dd e I suoi derivati. Dd va analizzato nel dettaglio prima di effettuare qualsiasi operazione invasiva la versione di dd da utilizzare è sicuramente quella che include anche la generazione di hash. Sul progetto IRItaly è possibile trovare la doc necessaria.

Hash Insieme con il CRC è sicuramente una componente fondamentale della fase di acquisizione. Gli algoritmi più utilizzati sono MD5 e SHA 1. Ultimamente questi algoritmi sono stati messi in discussione da alcune ricerche scientifiche. Tuttavia la comunità non li ha ancora abbandonati.

Hardware based devices Possono essere di tipo Gun e di tipo Simple HW Blocker. Dovrebbero, di norma, essere validati. Il NIST ne sta sottoponendo alcuni a controllo e verifica di laboratorio.

Sistemi di tipo GUN Vengono definiti in gergo a pistola in quanto simulano lo stesso comportamento Sono solitamente dei dispositivi All in One che hanno alcuni pro e alcuni contro: Pro. Rapidità e celerità di esecuzione, massima automazione possibile, riconoscimento della comunità, aggiornabilità Contro: richiedono una certa esperienza d uso e la famliarizzazione con alcuni concetti di base

Abbiamo visto: In sintesi Le investigazioni digitali si basano su un framework. Ricordate che: Per questo corso di studi si fa riferimento al metodo Spafford/Carrier. Infine: Esistono vari strumenti tecnologici a supporto della fase di preservation ed analisi. FINE

Lezione 3 Definizione del Framework Investigativo Gestione degli incidenti informatici Modulo 1 - Introduzione. Incidenti informatici, Principi di Log analysis Unità didattica 4 - Investigazioni e Metodiche Dario V Forte, CISM, CFE Università degli Studi di Milano - Ssri - CDL ONLINE

Obiettivo della lezione Come gli strumenti e le tecniche si mappano sulle varie esigenze investigative. I vari obiettivi prioritari di un investigazione digitale.

Sviluppare il profilo dell intruder Analisi della scena del crimine come è stato ottenuto l accesso? Che tipo di danno è stato generato (furto, danneggiamento, clean up ) possibili motivazioni (uso interno)

Obiettivi dell esame 1/2 assicurare l integrità dei log comprendere le modalità di penetrazione dell intruder collaborare con le forze di polizia nel backtracing degli autori del reato collezionare il numero più alto possibile di fonti di prova relative all intrusione

Obiettivi dell esame 2/2 correlazione documentare il danno causato ottenere informazioni sufficientemente attendibili per decidere se interessare l autorità giudiziaria

Obiettivo primario: cautelare la fonte di prova iniziare un operazione di traceback per identificare le posizioni dei log contattare i sysadmin per la cautela immediata dei log contenere il danno collezionare log in locale generare l immagine delle macchine colpite.

Riprodurre l incidente Comprensione del come può essere avvenuto l incidente. Accantonare l ovvio utilizzare log ed altre prove simili considerare il livello di skill richiesto per la gestione dell incidente creare un mirror del computer compromesso.

Creare un mirror del computer compromesso Immagine del disco/dischi (dischetto di boot) immagine bit by bit cautela di sorgente e destinazione possibilmente generare un md5 possibilmente generare la copia di lavoro su uno/più cd rom

Ricostruzione dell incidente 1/4 Sviluppare un profilo dell intruder considerare il percorso effettuato dall intruder per raggiungere il target ricreare l incidente in lab (comparazione dei log) considerare spiegazioni alternative dell accaduto.

Ricostruzione fisica Ricostruzione dell incidente 2/4 usa un mirror della macchina compromessa è utile per uno o comunque pochi target Ad ogni modo va tutto verbalizzato internamente

Ricostruzione logica Ricostruzione dell incidente 3/4 Usa simili sistemi utile in caso di microreti locali che hanno accesso alla lan aziendale in toto (poco frequente) può rivelarsi fuorviante verbalizzazione interna

Ricostruzione dell incidente 4/4 Ricostruzione Teorica va fatta in extrema ratio necessaria quando non si può accedere direttamente ai computer direttamente coinvolti come target. verbalizzazione estremamente granulare.

BackTracing Elementi costitutivi: target (end points) teste di ponte email ed headers log vari

Stabilire le relazioni

Abbiamo visto: Ogni investigazione ha degli obiettivi prefissati. Ricordate che: La cautela e la ricostruzione hanno importanza prioritaria. Infine: In sintesi Non esiste investigazione efficace se non è stato precedentemente stabilito un perimetro. FINE

Lezione 4 Perché utilizzare tool appropriati Gestione degli incidenti informatici Modulo 1 - Introduzione. Incidenti informatici, Principi di Log analysis Unità didattica 4 - Investigazioni e Metodiche Dario V Forte, CISM, CFE Università degli Studi di Milano - Ssri - CDL ONLINE

Obiettivo della lezione Descrizione della pratica della digital investigation. Illustrazione pratica delle features degli strumenti tipo.

Digital forensic 1/3 Digital Forensic consiste nell analisi e recupero dati da supporti di memorizzazione e si compone di innumerevoli attività. Analisi on site dei supporti tramite metodologie non invasive atte ad evidenziare ed eventualmente acquisire le informazioni ritenute interessanti ai fini delle indagini. L utilizzo di hardware e software dedicato garantisce che l analisi possa essere effettuata in modalità di sola lettura senza che l operazione stessa possa alterare in alcun modo il contenuto del supporto.

Digital forensic 2/3 La fase iniziale consiste nella copia fisica e/o l'acquisizione del supporto. Per strumenti e metodologie utilizzati, viene garantita la ripetibilita' dell'atto in qualsiasi fase del procedimento. Le operazioni sono condotte seguendo gli standard operativi e di letteratura riconosciuti a livello mondiale come le "best practices". Visualizzazione logica a basso livello dei dati contenuti nei supporti ed attivazione di una metodologia di ricerca concordata con l'utente. Quest'ultima risulta estremamente efficace sia in casi di computer crimes "puri" sia per indagini di tipo riservato (criminalità organizzata, terrorismo, pedofilia, traffici illeciti)

Digital forensic 3/3 Analisi presso il laboratorio dei dati acquisiti e sviluppo di ricerche parametriche semplici o combinate durante la quale viene garantita la massima interazione con gli organi investigativi, al fine di garantire la migliore efficacia delle operazioni. Le ricerche avvengono a "basso livello" (file system e oltre, secondo la letteratura vigente) con l'utilizzo di prodotti standard e/o strumenti proprietari secondo modalità concordate con l'utente. Questa analisi consente di individuare file anche se sono stati cancellati o se il disco è stato formattato.

Analisi a basso livello

Ricerca di un file

Esplorazione di un disco rigido

Ricerca di file cancellati

Visualizzazione file nella cache del browser

Abbiamo visto: In sintesi La digital forensics, oltre alla parte di framework, ha un impiego tecnico di basso livello. Ricordate che: Ogni finalità ha uno strumento ad hoc. Infine: La tecnologia può aiutare l investigatore, ma non in maniera esclusiva. FINE

Lezione 5 Test dei tool e validazione dei toolkit Gestione degli incidenti informatici Modulo 1 - Introduzione. Incidenti informatici, Principi di Log analysis Unità didattica 4 - Investigazioni e Metodiche Dario V Forte, CISM, CFE Università degli Studi di Milano - Ssri - CDL ONLINE

Descrizione del Lab Management Obiettivo della lezione Descrizione del lab testing e delle metodiche utilizzate nei test indipendenti.

Lab management Trattasi delle attività di gestione del laboratorio, o, in casi residuali, della Digital Investigation Zone. Sono effettuati secondo delle metodiche interne che, di norma, si rifanno a standard consolidati. Allo stato attuale esistono degli standard, basati su metodiche governative statunitensi.

Lab Management Inventario degli strumenti di analisi Inventario dei supporti Inventario delle tecnologie Tool Validation

Tool Validation 1/2 Validation Interna: Effettuata in laboratorio frutto di un processo di verifica (es. Sanitization) Validation esterna: Effettuata da terzi trusted può riguardare sia la configurazione sia i tools in senso stretto.

Tool Validation 2/2 Esistono alcuni esempi di validazione esterna effettuati dal NIST (National Institute for Standard and Technologies). Sono roadmap di validazione vera e propria. Vengono utilizzati anche per contraddittori in tribunale, ma solo per casi residuali. Se un tool è stato testato, con esito positivo, dal NIST, può avere un plus rispetto ad altri. Ma la validazione NON è vincolante.

Abbiamo visto: In sintesi Esistono dei processi di lab management e di tool validation. Ricordate che: La validazione può essere interna o esterna. Infine: Il NIST ha un processo di validazione di interesse per la comunità. FINE

Lezione 1 Remote Forensics, The Basics Gestione degli incidenti informatici Modulo 2 - Sistemi di Logging a livello sistema, Sistemi di Logging a Livello Rete,Sistemi di Intrusion Detection Unità didattica 4 - Remote Forensics Dario V Forte, CISM, CFE Università degli Studi di Milano - Ssri - CDL ONLINE

La remote forensics Si tratta di un evoluzione della forensics tradizionale. Si applica in alcuni casi in cui non è possibile o richiesto effettuare una digital investigation convenzionale, per esempio: collection di volatile data macchine di produzione

Obiettivi della remote forensics Assicurare l integrità delle fonti di prova comprendere le modalità di penetrazione dell intruder Ridurre l esigenza di intervenire localmente collezionare il numero più alto possibile di fonti di prova relative all intrusione

Caratteristiche principali della RF

Pesi e misure della RF a seconda della tecnologia utilizzata, si opera su uno o più sistemi operativi di solito gli agenti installati per monitorare hanno un peso minimo il deployment risulta alquanto razionale in presenza di personale specializzato e di un piano architetturale adeguato è possibile sviluppare un monitoraggio di 30mila macchine in poco meno di sessanta giorni

Market Overview Allo stato attuale, le soluzioni di remote forensics più utilizzate sono: Guidance software Encase Enterprise TechPathways Prodiscover Mandiant tools

Abbiamo visto: In sintesi In caso di impossibilità di agire localmente e su macchine di produzione si opera con la remote forensics. Ricordate che: L architettura è composta da examiner workstations e agents. Infine: Il range di offerta è abbastanza ristretto ma il tempo/volume di deployment sono efficaci. FINE

Lezione 2 EnCase EE 1 Gestione degli incidenti informatici Modulo 2 - Sistemi di Logging a livello sistema, Sistemi di Logging a Livello Rete, Sistemi di Intrusion Detection Unità didattica 4 - Remote Forensics Dario V Forte, CISM, CFE Università degli Studi di Milano - Ssri - CDL ONLINE

EnCase Enterprise Edition: Overview La Guidance Software con il suo EnCase Enterprise Edition (EnCase EE) è stata una delle prime aziende a fornire un prodotto di remote forensic. Tale strumento permette ad un investigatore di condurre una live-analysis, una review delle informazioni unitamente ad un processo di discovery sul sistema sottoposto ad esame sia via rete locale che geografica. Inoltre sono state incluse funzionalità per assicurare la protezione da parte di occhi indiscreti delle informazioni scambiate unitamente ad una parte di controllo degli accessi in modo da prevenire l utilizzo di tale tecnologia da parte di personale non autorizzate.

I componenti di EnCase EE 1/3 EnCase EE è formata da tre componenti principali: EnCase Examiner EnCase SAFE EnCase Servlet Encase Examiner: questo sw è installato sul computer autorizzato nel procedere alle operazioni di investigazione forense verso un dato host sottoposto ad analisi. Questo software è costruito sulla base di EnCase Forensic Edition ed include funzionalità e l interoperabilità per l accesso remoto al server SAFE ed ai corrispondenti network servlet.

I componenti di EnCase EE 2/3 EnCase SAFE: il Secure Authentication For Encase facilita l amministrazione degli utenti, traccia le varie transazioni, gestisce e controlla i privilegi d accesso ai diversi dispositivi di rete. Per la comunicazione fra l Examiner e le servlet viene utilizzato un canale di comunicazione crittato a garanzia della confidenzialità dei dati scambiati. EnCase Servlet:è un piccolo servizio con un impatto minimo che deve venire installato sui sistemi; permette ad EnCase Examine di vedere, importare ed acquisire dati. Solo i computer dotati di tale servizio possono essere sottoposti ad esame o venire acquisiti.

I componenti di EnCase EE 3/3

Autenticazione 1/4 EnCase utilizza la crittografia a chiave asimmetrica per l autenticazione delle parti e lo scambio dei dati. Durante il processo di autenticazione al SAFE, il software Examiner genera un numero casuale (Erand). L Examiner firma, con la propria chiave privata, sia il numero casuale che il proprio corrispondente nome utente. Queste informazioni infine sono crittate con la chiave pubblica del SAFE ed inviate tramite la rete al SAFE stesso.

Autenticazione 2/4 Il SAFE una volta ricevuto il pacchetto lo decifra con la propria chiave privata. Viene estratto il nome utente dal database del SAFE e la corrispondente chiave pubblica viene utilizzata per verificare la firma; nel caso questa operazione vada a buon fine viene memorizzato il numero casuale compreso nel pacchetto all interno del SAFE. In risposta all examiner, il SAFE genera un proprio numero casuale (Srand) e una chiave di sessione (Sekey); quest ultima verrà utilizzata per la cifratura simmetrica delle sessioni successive. Questi valori, unitamente al valore Erand originale sono firmati con la chiave privata del SAFE e cifrati con la chiave pubblica dell utente e rispediti all Examiner.

Autenticazione 3/4 L Examiner riceve il pacchetto e decifra il contenuto con la chiave privata dell utente; verifica poi la firma dello stesso con la chiave pubblica del SAFE. Viene successivamente esaminato il valore Erand e viene confermato che sia il medesimo nuemro generato in precedenza. Viene creato il pacchetto finale da inviare al SAFE che conclude il processo di autenticazione. Il Srand ricevuto viene crittato con la chiave di sessione,sekey e rispedito al SAFE.

Autenticazione 4/4 Il SAFE riceve il pacchetto lo decifra con la chiavesekey. Viene verificato che il valore Srand sia il medesimo generato in precedenza. Alla fine del processo l Examiner ed il SAFE possono incominciare a comunicare utilizzando un canale di comunicazione crittato basato sull algoritmo AES a 128Bit.

Query alle servlet Una volta che un utente è autenticato, può utilizzare l Examiner per esaminare i dati di un sistema remoto a supporto di un investigazione o durante il processo di IR. Segue a questo punto un processo simile a quello appena visto durante il processo d autenticazione, per instaurare un canale sicuro fra il SAFE e la servlet al quale segue l invio dei comandi da parte dell Examiner verso la servlet e la successiva ricezione dei risultati. Il concetto fondamentale è che il SAFE media l accesso alle servlet da parte dell Examiner ai soli aventi diritto.

Abbiamo visto: Come si compone Encase Enterprise Edition. Ricordate che: In sintesi I componenti principali di cui si compone la suite Encase EE sono Encase Examine, SAFE e le servlet. Infine: L utilizzo di strumenti di remote forensic comporta problemi tipici di sistemi client-server come l autenticazione e la verifica dell identità delle parti coinvolte FINE

Lezione 3 EnCase EE 2 Gestione degli incidenti informatici Modulo 2 - Sistemi di Logging a livello sistema, Sistemi di Logging a Livello Rete, Sistemi di Intrusion Detection Unità didattica 4 - Remote Forensics Dario V Forte, CISM, CFE Università degli Studi di Milano - Ssri - CDL ONLINE

Campi d utilizzo Con uno strumento come EnCase EE è possibile usufruire dei benefici tipici di soluzioni di remote forensic come: risposta tempestive ad un dato incidente aggiunta della possibilità di catturare volatile data possibilità di gestire sistemi eterogenei, come windows, Linux e Solaris da un solo punto interrogare lo stato di sistemi alla traccia di eventuali anomalie anche durante un normale processo di auditing del sistema

System Snapshot Tramite l esecuzione di snapshot è possibile acquisire informazioni volatili che possono risultare utili al fine investigativo, che risulterebbero non disponibili nel caso si procedesse ad una normale acquisizione post-mortem. Queste informazioni comprendono: file aperti processi in esecuzione porte di rete ed altre informazioni cruciali per un dato istante Inoltre queste informazioni possono fornire un ottimo spunto per la correlazione con altre informazioni prodotte da sistemi come IDS e firewall.

Automated Incident Response 1/2 E possibile integrare i sistemi IDS con Encase EE in modo da scatenare sulla base di un alert prodotto dal sistema di intrusion detection un processo automatico di snapshot di un dato sistema. In questo modo è possibile acquisire informazioni volatili sia del sistema bersaglio dell attacco che di quello da cui è partito lo stesso (sempre a condizione che sia installata la servlet su entrambi le macchine). Questo è particolarmente utile quando l attacco è perpetrato da un utente interno.

Automated Incident Response 2/2

System Auditing Uno strumento del genere è utile anche nello svolgimento del normale processo di Auditing e revisione dei sistemi. Può essere utilizzato, per esempio, per identificare: programmi non autorizzati sistemi compromessi identificazioni di malicious process identificazioni di processi nascosti e rootkit

Forensic Investigation Due delle caratteristiche più apprezzate di EnCase sono l elevato numero di sistemi operativi e di file system supportati. EnCase Enterprise può interpretare il contenuto di diverse tipologie di file system via rete, accedendovi tramite le servlet. Alcuni file system supportati comprendono: FAT12/FAT16/FAT32 NTFS EXT2/EXT3, ReiserFS UFS JFS FFS HFS/HFS+ CDFS, ISO9660, UDF

Forensic Analysis: Preview EnCase EE permette all investigatore di effettuare una preview del sistema compromesso. Questo processo si compone della instaurazione di una comunicazione sicura fra il sistema da analizzare e la console di analisi offrendo la possibilità di visualizzare tutta una serie di informazioni sottostando ai dettami della disciplina forense. unallocated, deleted, allocated, file slack, volume slack e attributi dei file accesso a dispositivi firewire, cdrom, RAID array volumi PGP montati, USB pen-drive Queste operazioni ne allertano l utilizzatore del sistema ne alterano il contenuto dello stesso.

Forensic Analysis: Data Acquisition 1/2 Sono presenti le possibilità di acquisizione fornite già all interno della versione stand-alone Forensic. E possibile acquisire un sistema,o una molteplicità di sistemi, e nel frattempo continuare nell indagine della macchina. Durante il processo di copia i blocchi di dati trasferiti vengono continuamente verificati tramite un codice CRC. Al completamento dell acquisizione un secondo processo di controllo verifica la correttezza della totalità dei dati trasferiti. Uno dei problemi principali delle acquisizioni via rete è lagata al fatto dell enorme mole di dati da trasferire e la ristretta velocità presente sui link di tipo geografico.

Forensic Analysis: Data Acquisition 2/2 Acquisition read-ahead: permette di memorizzare in una cache alcuni blocchi dati in anticipo rispetto alla relativa richiesta, in maniera da offrire all investigatore un servizio migliore. Acquisition granularity: offre la possibilità all investigatore di discriminare sulla quantità di dati da trasferire per ogni singola evidence che deve essere acquisita. Acquisition restart: possibilità di fermare e riavviare il processo senza perdere i progressi compiuti.

Abbiamo visto: In sintesi Maggiori dettagli della struttura della suite Encase Enterprise. Ricordate che: Il processo di remote forensic presuppone alla base alcuni requisiti come l autenticazione e l autorizzazione d accesso al computer da esaminare solo agli aventi diritto. Infine: Sono fornite possibilità di generare preview, snapshot ed eseguire processi di live-analysis sul sistema. FINE

Lezione 4 Prodiscover Gestione degli incidenti informatici Modulo 2 - Sistemi di Logging a livello sistema, Sistemi di Logging a Livello Rete, Sistemi di Intrusion Detection Unità didattica 4 - Remote Forensics Dario V Forte, CISM, CFE Università degli Studi di Milano - Ssri - CDL ONLINE

Caratteristiche generali Prodotto dall azienda Technology Pathways per investigazioni di Remote Forensics. live Analysis via network TCP/IP live Acquisition (RAM e dischi) via network TCP/IP indagini in ambienti medio/piccoli (un sistema alla volta) progettato secondo le specifiche del NIST utilizzato dai professionisti di Computer Forensics per trovare e presentare prove in processi civili e penali Sono disponibili più versioni di tale prodotto; le funzionalità elencate sopra sono disponibili nella versione Incident Response.

Architettura Console (o client): incorpora le funzionalità principali del tool Agenti (o server): in esecuzione sui sistemi sotto indagine

Caratteristiche della console 1/2 non necessita di dongle per funzionare interfaccia grafica configurabile 3 algoritmi di hashing MD5 SHA1 SHA256 impostazione fuso orario del sistema remoto connessione console/agente remoto configurabile su qualsiasi porta TCP, inclusi timeout e auto-retry selezione metadati EXIF da estrarre dai file grafici JPEG e TIFF log delle attività della console e dell agente remoto

Caratteristiche della console 2/2

Agente remoto - caratteristiche lettura disco a livello dei settori in modalità read-only utilizzo di un proprio file system fidato e in sola lettura file system supportati: Windows FAT e NTFS (inclusi dischi dinamici e software RAID) Linux Ext2, Ext3 Solaris UFS (SPARC e X86)

Sono possibili quattro livelli di analisi: Agente remoto - analisi livello filesystem (Content View) basso livello (Cluster View) registri di sistema (Registry View) log degli eventi (Event Log View)

Comunicazione console agenti canale di comunicazione criptato con AES o TwoFish a 256 bit Global Unique Identifiers per integrità e sicurezza della comunicazione agente protetto con password blocco login per 5 min dopo 5 tentativi falliti

Funzionalità integrazione e utilizzo di script Perl per l automatizzazione di procedure filtraggio file fidati (binari s.o./applicazioni note) tramite verifica dell hash (KnownBad/ KnownGood) controllo file di Windows tramite comparazione file signature/estensione recupero file cancellati contenuti nello slack space copia file dal sistema remoto ricerche per parole chiave analisi dei registri di Windows analisi del log degli eventi riferimento incrociato file/cluster visualizzazione Alternate Data Streams estrazione info da history Internet Explorer (index.dat) tool per rilevare interi dischi criptati (es. PGP Disk)

Funzionalità di IR Find Unseen Processes: determina quali file sono locked e li confronta con la lista dei processi che il s.o. considera running. Find Unseen File: lettura a basso livello (bit level) delle filesystem tables e confronto con la lista dei file rilevati dal s.o. Find Suspect File: confronto della firma hash di directory o interi dischi su database di hash noti (calcolo creato leggendo sempre a basso livello in modalità readonly). Create Baseline/Compare Baseline: verifica integrità file tramite baseline fidata precedentemente creata. Open/Connected IP port: Lista porte TCP e UDP aperte e connesse, con relativo stato della connessione. Get Process List: Lista dei processi running e relative librerie utilizzate.

Acquisizioni acquisizioni RAM e hard disk (locale o via rete TCP/IP) due formati immagini: Unix dd, formato proprietario creato file di log per eventuali errori di I/O formato proprietario copia bit a bit + checksum + log compressione/decompres immagine protezione con password convertibile nel formato Unix dd restore dell immagini

In sintesi Abbiamo visto: Una presentazione generale del prodotto Prodiscover IR. Ricordate che: Come lo strumento descritto nella lezione precedente, l architettura di funzionamento è simile e prevede una serie di agenti controllati da una console centrale. Infine: Gli strumenti di remote forensic differiscono per lo più per le tipologie di file-system supportati e sistemi operativi su cui è possibile installare gli agenti, ma tendono a mantenere un minimo comune denominatore di caratteristiche condivise (modello architettura, canale trasmissivo sicuro, etc). FINE

Lezione 5 Netwitness e Tizor Mantra Gestione degli incidenti informatici Modulo 2 - Sistemi di Logging a livello sistema, Sistemi di Logging a Livello Rete, Sistemi di Intrusion Detection Unità didattica 4 - Remote Forensics Dario V Forte, CISM, CFE Università degli Studi di Milano - Ssri - CDL ONLINE

Netwitness overview E un analizzatore di traffico in grado catturare e ricostruire l attività di rete Fornisce log validi dal punto di vista dell analisi forense Snelissisce e velocizza le attività di monitoraggio Genera reportistica utile come allegato tecnico alle indagini NetWitness può essere utilizzato su reti: 10/100 mbit Ethernet 8/16 mbit Token Ring FDDI network

Netwitness: modalità di funzionamento Real Time Capture: Cattura il traffico utilizzando la modalità promiscua della scheda di rete File Based Network Capture: Può leggere diversi tipologie di formati di log fra cui: TCPDump *.tcp,*.tcp.gz,*.pcap,*.pcap.gz NetMon *.cap,*.cap.gz EtherPeek *.pkt,*.pkt.gz IPTrace *.ipt,*.ipt.gz RAW *.raw,*.raw.gz CAYMAN *.ppp SPILL *.nwx,*.nwm EMAIL *.eml

Netwitness: struttura

Netwitness: applicazioni Prevenzione degli attacchi e delle frodi, a prescindere dalla loro origine Detection del traffico anomalo in caso di incidenti particolari. Netwitness non è un IDS, è uno strumento molto più potente e flessibile Può essere utilizzato per servizi avanzati

Netwitness: modalità di analisi 1/2 E possibile analizzare i dati, sia precedentemente registrati che in real-time, utilizzano differenti livelli di dettaglio, in concomitanza con la strutturazione dei protocolli. Più il livello è basso maggiore è la granularità delle informazioni; più il livello è alto maggiore è la strutturazione ed il valore complessivo delle informazioni livello rete livello sessione livello applicazione

Netwitness: modalità di analisi 2/2 E anche possibile organizzare le informazioni per altri parametri non inerenti lo strato network come: intervalli temporali utenti coinvolti dimensione dei dati scambiati Una delle caratteristiche che rende questo strumento particolare è la possibilità di analisi dei dati di rete con un approccio forensic-oriented; infatti sono comprese funzionalità di hash delle informazioni, ricostruzione di sessioni, esportazione di informazioni, generazione di log all interno di un database.

Tizor Mantra: Overview Il prodotto permette di consolidare in un unico strumento funzionalità di: data auditing data security Questo tipo di tecnologia viene impiegata per garantire le due funzionalità citata su dati ad elevato valore, come record medici, numeri di carte di credito, file di bilancio, progetti industriali, contenuti all interno di: database file server

Tizor Mantra: come lavora 1/2 Discovery dei data repository (come file server e database server) basato sull analisi passiva del traffico. Definizione ed attivazione di policy basate su: dati raccolti durante la fase di discovery policy predefinite distribuite con il prodotto policy interne all azienda Registrazione di informazioni aggregate su più dimensioni come hostname, indirizzo ip, data, ora, username, comando impartito,etc. Utilizzo di un motore di behavioral analysis per la rilevazione di eventuali sottrazioni di informazioni o identity theft. Console web per la gestione e consultazione delle informazioni.

Tizor Mantra: come lavora 2/2

Rispetto dei requisiti forensi Ogni informazione registrata dal prodotto è memorizzata unitamente ad informazioni collaterali utili al fine di svolgere un attività forense a posteriori. modifica ai permessi utente modifiche alle informazioni accesso ed utilizzo ad informazioni riservate condizioni d errore sorgente della richiesta identificativo temporale della richiesta L inclusione di tali informazioni permette ai dati registrati dallo strumento di avere valenza dal punto di vista della disciplina forense; va tuttavia valutato sempre il livello ed il dettaglio delle informazioni da includere in ciascun evento registrato.

Abbiamo visto: In sintesi Due strumenti che affrontano differenti problemi ma facendo attenzione agli aspetti tipici della computer forensic. Ricordate che: Indipendentemente dalla soluzione che si intende utilizzare vanno valutate le capacità di sottostare delle stesse a particolari requisiti forensi. Infine: A prescindere dal prodotto, procedere a regolari ispezioni sulla funzionalità del sistema di raccolta, collezione e monitoraggio degli eventi. FINE

Lezione 1 IRItaly CD 1 Gestione degli incidenti informatici Modulo 5 - Tool Overview Unità didattica 4 - CDRom di First Response Dario V Forte, CISM, CFE Università degli Studi di Milano - Ssri - CDL ONLINE

Cos è IRItaly Live CD IRItaly è un cdrom Live contenente una distribuzione in grado di rendere disponibile all'utilizzatore un immediato ambiente di lavoro basato su Linux, al fine di rispondere ad un incidente. Live System Analysis per la verifica dell incidente. Acquisizione della fonte di prova Creazione e analisi di immagini forensi. Acquisizione di dati pertinenti. Integrità dei dati acquisiti Recupero dati Valutazione delle vulnerabilità

Pagine di riferimento Il sito web del progetto è raggiungibile all indirizzo http://www.iritaly-livecd.org ed è disponibile un forum sul quale scambiare opinioni con i membri della community e contattare i manutentori del progetto stesso.

F.I.R.E (http://biatchux.dmzs.com/) -> v1 Knoppix STD (Debian 2.4.x) -> v2 Gentoo Linux (2.6.x) -> v3 Next gen? History Uno degli aspetti critici di un Live CD di First Incident Response è la sua manutenzione e aggiornamento. L utilizzo di Gentoo permette di avvalersi di un potente sistema di installazione e aggiornamento dei pacchetti. Questa soluzione permette di ottenere un sistema forgiato in base alle necessità degli sviluppatori ed il pieno controllo sul funzionamento del sistema (init, servizi, kernel, etc).

Versioni disponibili Il CD di IRItaly è disponibile in tre differenti versioni, ognuna con un ben preciso obbiettivo. IRItaly Live CD Base: contiene un minimo set di strumenti utili ad acquisire evidence sia a livello di media che di network. E il pilastro portante sulla base del quale sono sviluppate le altre due versioni. IRItaly Live CD Media: contiene strumenti specifici per l analisi dei media. IRItaly Live CD Network: offre strumenti per l analisi del traffico di rete così come tool per la valutazione del livello d esposizione dei sistemi. Integrazione in un unica versione

Win32 GUI La parte Win32 fornisce una serie di tool che consentono, in fase di risposta, di verificare, acquisire e validare le informazioni presenti sul PC incriminato. Essendo uno strumento di incident response esistono vincoli a cui non è possibile transigere. Consistente e verificabile Utilizzo di metodologia forense Minimizzare l impatto sul sistema. Utilizzo di binari fidati. Trascrizione delle operazioni eseguite. Integrità dei dati acquisiti.

Binari statici Binari "fidati (presenti entro la cartella statbin del CD) scaricati e ricompilati manualmente e staticamente. Win32 (95/98/ME, NT, 2000, XP, 2003) Solaris (sparc) Linux (x86) Raccolta preliminare di informazioni atte alla verifica dell incidente ed alla successiva collezione di evidence. La necessità di usare tali binari si contrappone all utilizzo di comandi di sistema probabilmente modificati (trojanizzati) al momento dell' intrusione.

IRItaly Live CD Base (1) Verifica dell incidente netstat, lsof. netstat.exe,pslist.exe, fport.exe. Descrizione del sistema uname, uptime, date, time. psinfo.exe, date.exe, time.exe, cygwin s binary. Evidence Collection Host based: ram, immagini disco, log file, file. Network based: log file, network dump, netflow. disk_stat, setmax, fdisk, dd (dcfldd), memdump, netcat, cryptcat, md5sum, md5deep.

IRItaly Live CD Base (2) Il sistema dispone di tutti quegli applicativi che permettono all utente di effettuare una normale attività su sistema Linux, quindi anche capacità di rete e altri strumenti di utilità. Sistema Linux base: Servizi: sshd, syslog-ng, dmraid FileSystem: FAT12/16/32, NTFS (ro), ntfs-3g (rw), EXT2/3, ReiserFS, UFS (BSD), CDFS, CIFS, smb. Rete: bridge-utils, dhcpcd, iptables Ambiente grafico leggero ed essenziale (Enlightenment). Utility: telnet, ftp, wget, netcat, cryptcat, screen, elinks, vim, nano, zip.

In sintesi Abbiamo visto: Una panoramica del progetto IRItaly Live CD e delle diverse versioni prodotte dallo stesso. Ricordate che: Esistono tre versioni ognuna delle quali contiene strumenti specifici; in base alle necessità è consigliabile l utilizzo di una versione rispetto ad un altra. Infine: E inclusa una GUI Win32 unitamente a binari statici per verificare l incidente sul sistema. FINE

Lezione 2 IRItaly CD 2 Gestione degli incidenti informatici Modulo 5 - Tool Overview Unità didattica 4 - CDRom di First Response Dario V Forte, CISM, CFE Università degli Studi di Milano - Ssri - CDL ONLINE

IRItaly Live CD Media (1) Questa versione del CD contiene tutti gli strumenti indispensabili per un analisi dei media contenenti le tracce di una potenziale compromissione. Tramite il cd è quindi possibile disporre di un completo ambiente di lavoro di Forensic Investigation. General Media Analysis Password recovery Microsoft analysis Rootkit detection Antivirus

IRItaly Live CD Media (2) Analisi dei media Sleuthkit e il suo front-end Autopsy. file system layer, data layer, metadata layer, file name layer e journal layer. Creare timeline mac-robber e mactime. Estrazione spazio unallocated e slack dls Data carving lazarus, foremost e scalpel.

IRItaly Live CD Media (3) Password recovery e steganalysis cmospwd, stegdetect e outguess. Antivirus & rootkit check f-prot, clamav, rkhunter e chkrootkit. Utility disk_stat, disk_sreset, setmax.

IRItaly Live CD Network (1) Questa versione del CD è stata ampliata fornendo complete capacità di Cattura del traffico. Analisi del traffico. Sono disponibili anche una serie di strumenti per l enumerazione e la valutazione delle vulnerabilità. Information gathering Enumerazione. Vulnerability check. Exploit.

IRItaly Live CD Network (2) Cattura del traffico Full content: tcpdump, dumpcap, Ethereal/Wireshark, snort. Session data: fprobe, flow-tools, argus, sflowtools. Statistical data: ipcad, ifstat, bmon, TTT, trafshow. Alert data: snort, prelude-nids. Analisi del traffico Content search: ngrep. Data carving & recovery: chaosreader, tcpxtract, tcpflow, driftnet. Analysis: Ethereal/Wireshark, netdude, ra, snort, p0f, (honeysnap).

IRItaly Live CD Network (3) Information gathering ed enumerazione Intelligence: dnsquery, p0f, hping. Enumeration and scanning: nmap, xprobe2, amap, nbtscan, arping. Vulnerability check Exploit General purpose: Nessus. Web Server: nikto. General purpose: Metasploit.

Win32 GUI (1) La GUI Win32 è strutturata in più sezioni che corrispondono a diverse modalità d utilizzo. Questa interfaccia è presente in tutte le versioni. Trusted enviroment Shell (95/98/ME, NT, 2000,XP). Binari (librerie esterne non incluse). Informazioni sul sistema lista dei processi attivi. dll caricate nel sistema. lo stato delle porte attive sul sistema. servizi e driver installati. Programmi autorun. lista degli ultimi accessi (success o failed).

Win32 GUI (2) La sezione di acquisizione permette di collezionare informazioni che andremo ad analizzare durante la fase di analisi. Acquisizione Ram, volume logico o fisico Copia locale o remota. Split dell immagine. Hash dei dati (md5, sha1, sha256). Log delle operazioni. Modalità Client vs Server.

Win32 GUI (3) Client Server

Win32 GUI (4) Hashing File hashing con CRC32, MD5, SHA1. Internet History di navigazione e cookie (pasco, galletta, iecv e mzcv). Internet Explorer, Mozilla/Firefox, Netscape. Sniffer Windump per la cattura del traffico di rete. Possibilità di installare librerie pcap (valutare impatto). Sniffer di password.

Win32 GUI (5) Hash Sniffer