Alma Mater Studiorum Â· UniversitÃ di Bologna FACOLTÃ' DI SCIENZE MATEMATICHE, FISICHE E NATURALI Corso di Laurea Triennale in Informatica MONITORAGGIO DELLA SICUREZZA INFORMATICA MEDIANTE IL MODELLO SIEM IN UNA ORGANIZZAZIONE COMPLESSA: LA REGIONE EMILIA-ROMAGNA Tesi di Laurea in Sicurezza Relatore:
Chiar.mo Prof.
OZALP BABAOGLU Presentata da: FABIO BUCCIARELLI Sessione III Anno Accademico 2010/11 ii Introduzione La sicurezza costituisce un elemento sempre piÃ¹ importante nellâ''ambito di azien- de e pubblica amministrazione, soprattutto in seguito alla sempre maggior in- terconnessione tra i sistemi e allâ''aumento dei servizi Internet. Per questo motivo negli ultimi anni si Ã¨ assistito ad un proliferare di sistemi di sicurezza, passando da un modello basato su pochi dispositivi posti sul perimetro della rete, ad un modello di sicurezza distribuita, in cui tutti gli end point della rete collaborano alla sicurezza. Il continuo aumento del numero e dellâ''assortimento dei dispositivi di sicu- rezza presenti in azienda, e in generale lâ''aumento della complessitÃ del sistema informativo aziendale fa sÃ¬ che che i team dedicati alla sicurezza siano alle pre- se con un flusso di eventi continuamente crescente e spesso ingestibile. Gli amministratori di sicurezza, di sistema e di rete, sotto la cui responsabilitÃ rica- de tradizionalmente lâ''analisi dei log, considerano tale attivitÃ come unâ''attivitÃ a bassa prioritÃ , noiosa e poco produttiva rispetto al dispendio di tempo ed energia richiesti. Questo Ã¨ in parte motivato dal fatto che su milioni di log pro- dotti giornalmente, solo poche decine hanno un interesse reale e senza strumenti automatici Ã¨ impossibile distinguerli dal rumore di fondo. La necessitÃ di rilevare prontamente eventuali attacchi e violazione delle po- licy, il rispetto di normative e di â''best practiceâ' sulla sicurezza delle informazioni rendono indispensabile la presenza di unâ''infrastruttura di log management ro- busta e affidabile, che automatizzi anche alcune operazioni di analisi impossibili da svolgere a mano. Lâ''attivitÃ di questa tesi si concentra sulla gestione dei log di sicurezza azien- dali secondo il modello System Information and Event Management (SIEM), considerato come strumento di monitoraggio della sicurezza privilegiato su cui basare lâ''attivitÃ di un Security Operation Center (SOC). Viene analizzato come caso di studio il sistema di monitoraggio della sicurez- za implementato presso la Regione Emilia-Romagna, realizzato sotto la diretta responsabilitÃ del candidato nellâ''ambito della propria attivitÃ lavorativa presso tale Ente. La prima parte tratta da un punto di vista generale la gestione dei log di sicu- rezza secondo il modello SIEM. Il capitolo 1 introduce gli scopi, le problematiche e i modelli di gestione dei log di sicurezza. Il capitolo 2 descrive lâ''architettura e le componenti di un SIEM. Il capitolo 3 descrive lâ''architettura e le specificitÃ di Arcsight ESM, il SIEM utilizzato dalla Regione Emilia-Romagna. iii La seconda parte descrive il processo di realizzazione del sistema di moni- toraggio presso la Regione Emilia-Romagna. Il capitolo 4 descrive la gestione della sicurezza informatica presso tale ente. Il capitolo 5 descrive i passi seguiti nella realizzazione del sistema, la definizione del modello, lâ''interconnessione con il database degli asset, la definizione di regole per la rilevazione di eventi di interesse. iv A Serena, Chiara, Daniele, Stefano, Filippo v vi Indice I Gestione dei log mediante un System and Event Ma- nagement 1 1 La gestione dei log di sicurezza 3 1.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 Tipologie di log di sicurezza . . . . . . . . . . . . . . . . . . . . . 3 1.2.1 Software di sicurezza . . . . . . . . . . . . . . . . . . . . . 4 1.2.2 Sistemi operativi . . . . . . . . . . . . . . . . . . . . . . . 5 1.2.3 Applicazioni . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.3 Gli scopi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.3.1 Monitoraggio della sicurezza . . . . . . . . . . . . . . . . . 7 1.3.1.1 Lâ''analisi dei rischi . . . . . . . . . . . . . . . . . 7 1.3.1.2 VulnerabilitÃ e minacce . . . . . . . . . . . . . . 8 1.3.1.3 Riconoscimento degli attacchi . . . . . . . . . . 10 1.3.2 Compliance alle normative . . . . . . . . . . . . . . . . . 14 1.4 Le strategie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.5 Le sfide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 1.5.1 Gestione e registrazione dei log . . . . . . . . . . . . . . . 18
1.5.2 Protezione dei log . . . . . . . . . . . . . . . . . . . . . . 18
1.5.3 Analisi dei log . . . . . . . . . . . . . . . . . . . . . . . . 19 1.6 I modelli . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 1.6.1 Il modello Syslog . . . . . . . . . . . . . . . . . . . . . . . 19
1.6.2 Il modello SIEM . . . . . . . . . . . . . . . . . . . . . . . 20 2 Architettura di un SIEM 25 2.1 Generazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.2 Collezionamento . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.3 Registrazione e immagazzinamento . . . . . . . . . . . . . . . . . 29
2.4 Analisi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 2.4.1 Il Rule e il Correlation Engine . . . . . . . . . . . . . . . 30
2.4.2 La Knowledge Base . . . . . . . . . . . . . . . . . . . . . 32 2.5 Monitoraggio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 vii INDICE 3 ArcSight ESM 37 3.1 Architettura di Arcsight ESM . . . . . . . . . . . . . . . . . . . . 37 3.2 Collezionamento . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 3.2.1 I componenti . . . . . . . . . . . . . . . . . . . . . . . . . 40 3.2.2 I processi . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 3.3 Registrazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 3.3.1 I componenti . . . . . . . . . . . . . . . . . . . . . . . . . 43 3.3.2 Lo schema degli eventi . . . . . . . . . . . . . . . . . . . . 43 3.4 Analisi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 3.4.1 La correlazione . . . . . . . . . . . . . . . . . . . . . . . . 45 3.4.1.1 Rule . . . . . . . . . . . . . . . . . . . . . . . . . 46 3.4.1.2 Azioni . . . . . . . . . . . . . . . . . . . . . . . . 47 3.4.1.3 Liste . . . . . . . . . . . . . . . . . . . . . . . . 48 3.4.2 Knowledge base . . . . . . . . . . . . . . . . . . . . . . . . 48 3.4.2.1 ArcSight Asset Model . . . . . . . . . . . . . . . 48 3.4.2.2 ArcSight Network Model . . . . . . . . . . . . . 49 3.5 Monitoraggio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 3.5.1 Active Channel . . . . . . . . . . . . . . . . . . . . . . . . 50 3.5.2 Dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . 51 3.5.3 Query Viewer . . . . . . . . . . . . . . . . . . . . . . . . . 52 3.6 Reportistica e analisi degli incidenti . . . . . . . . . . . . . . . . 52 3.6.1 Query . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 3.6.2 Trend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 3.6.3 Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 II Un caso di studio: la Regione Emilia-Romagna 53 4 Gestione della sicurezza informatica 55 4.1 Le policy di sicurezza . . . . . . . . . . . . . . . . . . . . . . . . . 55 4.2 Il sistema di verifiche . . . . . . . . . . . . . . . . . . . . . . . . . 56 4.3 Le soluzioni tecnologiche . . . . . . . . . . . . . . . . . . . . . . . 57 4.3.1 Sistemi firewall . . . . . . . . . . . . . . . . . . . . . . . . 57 4.3.2 Sistemi anti malware . . . . . . . . . . . . . . . . . . . . . 57 4.3.3 Sistemi di Intrusion Prevention e Intrusion Detection . . . 58 4.3.4 Virtual Private Network . . . . . . . . . . . . . . . . . . . 58 4.3.5 Web Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . 58 4.3.6 I sistemi di autenticazione . . . . . . . . . . . . . . . . . . 58 4.3.6.1 Il dominio Active Directory . . . . . . . . . . . . 58 4.3.6.2 Il sistema di Identity and Access Management . 59 4.3.6.3 Il servizio RADIUS . . . . . . . . . . . . . . . . 60 4.3.7 Il Configuration Management Database . . . . . . . . . . 60 4.4 La gestione degli incidenti di sicurezza . . . . . . . . . . . . . . . 61 viii INDICE 5 Realizzazione del sistema di monitoraggio 65 5.1 Il sistema di log management . . . . . . . . . . . . . . . . . . . . 65 5.2 Architettura del sistema di log correlation . . . . . . . . . . . . . 69 5.3 Modellazione della rete e degli asset . . . . . . . . . . . . . . . . 70 5.3.1 Importazione delle zone . . . . . . . . . . . . . . . . . . . 70 5.3.2 Importazione degli asset e definizione delle categorie di asset 71 5.3.3 VulnerabilitÃ degli asset . . . . . . . . . . . . . . . . . . . 72 5.4 Individuazione degli eventi di interesse . . . . . . . . . . . . . . . 73 5.5 Autenticazione degli utenti . . . . . . . . . . . . . . . . . . . . . 73 5.5.1 Regole di correlazione . . . . . . . . . . . . . . . . . . . . 74 5.5.1.1 Tentativi ripetuti di login provenienti da una singola sorgente . . . . . . . . . . . . . . . . . . 74 5.5.1.2 Tentativi ripetuti di login rivolti ad un singolo account . . . . . . . . . . . . . . . . . . . . . . 75 5.5.1.3 Attacchi di forza bruta . . . . . . . . . . . . . . 76 5.5.1.4 Errori di autenticazione sulla VPN . . . . . . . . 77 5.5.1.5 Modifica delle configurazioni di utenti e host . . 77 5.5.1.6 Accesso ai sistemi mediante account amministra- tivi non personali . . . . . . . . . . . . . . . . . 78 5.5.2 Strumenti di monitoraggio . . . . . . . . . . . . . . . . . . 79 5.5.2.1 Monitoraggio di ripetuti login falliti e attacchi di forza bruta . . . . . . . . . . . . . . . . . . . 79 5.5.2.2 Monitoraggio degli eventi di autenticazioni sulla VPN . . . . . . . . . . . . . . . . . . . . . . . . 80 5.5.2.3 Autenticazioni fallite sulla VPN da parte di uten- ti privilegiati . . . . . . . . . . . . . . . . . . . . 81 5.5.3 Reportistica . . . . . . . . . . . . . . . . . . . . . . . . . . 81 5.5.3.1 Utilizzo della VPN . . . . . . . . . . . . . . . . . 81 5.5.3.2 Modifica delle configurazioni degli utenti . . . . 81 5.5.3.3 Monitoraggio delle sessioni amministrative . . . 81 5.6 Attacchi sulla rete . . . . . . . . . . . . . . . . . . . . . . . . . . 81 5.6.1 Regole di correlazione . . . . . . . . . . . . . . . . . . . . 81 5.6.1.1 Alto numero di connessioni negate . . . . . . . . 82 5.6.1.2 Connessioni in outbound su porte differenti . . 82 5.6.2 Strumenti di monitoraggio . . . . . . . . . . . . . . . . . . 83 5.6.2.1 Overview degli eventi provenienti dal firewall . . 83 5.6.2.2 Overview degli eventi provenienti dallâ''IPS . . . . 84 5.6.3 Reportistica . . . . . . . . . . . . . . . . . . . . . . . . . . 85 5.6.3.1 Uso di protocolli in chiaro in outbound . . . . . 85 5.6.3.2 IP interni bloccati . . . . . . . . . . . . . . . . . 85 5.6.3.3 IP esterni bloccati . . . . . . . . . . . . . . . . . 86 5.6.3.4 Principali alert da IDS / IPS . . . . . . . . . . . 86 5.7 Attacchi e malware a livello host . . . . . . . . . . . . . . . . . . 86 5.7.1 Regole di correlazione . . . . . . . . . . . . . . . . . . . . 86 5.7.1.1 Malware rilevato ma non rimosso . . . . . . . . . 86 5.7.1.2 Worm Rilevato . . . . . . . . . . . . . . . . . . . 87 ix INDICE 5.7.2 Strumenti di monitoraggio . . . . . . . . . . . . . . . . . . 89 5.7.2.1 Overview dei sistemi antivirus . . . . . . . . . . 89 5.7.3 Reportistica . . . . . . . . . . . . . . . . . . . . . . . . . . 89 5.7.3.1 Sorgenti di malware . . . . . . . . . . . . . . . . 89 5.7.3.2 Malware rilevato . . . . . . . . . . . . . . . . . . 89 5.8 Attacchi alle applicazioni web . . . . . . . . . . . . . . . . . . . . 89 5.8.1 Regole di correlazione . . . . . . . . . . . . . . . . . . . . 90 5.8.1.1 Directory traversal . . . . . . . . . . . . . . . . 90 6 Conclusioni 91 Bibliografia 93 x Elenco delle figure 1.2.1 Esempi di log di sistemi di sicurezza . . . . . . . . . . . . . . . . 21 1.2.2 Esempio di log di sistema operativo linux . . . . . . . . . . . . . 22 1.2.3 Esempio di log di un web server apache . . . . . . . . . . . . . . 23 2.0.1 Macro architettura di un SIEM . . . . . . . . . . . . . . . . . . . 26 2.2.1 Evento di login fallito su Windows . . . . . . . . . . . . . . . . . 28 2.2.2 Evento di login fallito su Linux . . . . . . . . . . . . . . . . . . . 28 2.4.1 Regola per login amministrativo . . . . . . . . . . . . . . . . . . 31 2.5.1 Architettura di dettaglio di un SIEM . . . . . . . . . . . . . . . . 35 3.1.1 Architettura dellâ''ESM . . . . . . . . . . . . . . . . . . . . . . . . 38 3.1.2 Ciclo di vita degli eventi nellâ''ESM . . . . . . . . . . . . . . . . . 39 3.2.1 Collezionamento . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 3.4.1 Il processo di correlazione . . . . . . . . . . . . . . . . . . . . . . 46 3.5.1 Esempio di Active Channel . . . . . . . . . . . . . . . . . . . . . 50 3.5.2 Esempio di Dashboard . . . . . . . . . . . . . . . . . . . . . . . . 51 4.4.1 Gestione degli incidenti di sicurezza . . . . . . . . . . . . . . . . 63 5.2.1 Architettura del sistema . . . . . . . . . . . . . . . . . . . . . . . 70 5.5.1 Filtro: Attack Login Source . . . . . . . . . . . . . . . . . . . . . 74 5.5.2 Rule: Attack Login Source . . . . . . . . . . . . . . . . . . . . . . 74 5.5.3 Filtro: Attack Login Target . . . . . . . . . . . . . . . . . . . . . 75 5.5.4 Rule: Attack Login Target . . . . . . . . . . . . . . . . . . . . . . 75 5.5.5 Filtri: Attack Login Source Correlated e Attack Login Target Correlated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 5.5.6 Rule: Brute Force Logins . . . . . . . . . . . . . . . . . . . . . . 76 5.5.7 VPN Authentication Failed . . . . . . . . . . . . . . . . . . . . . 77 5.5.8 Filtro: Configuration Modification . . . . . . . . . . . . . . . . . 78 5.5.9 Rule: Successfull Configuration Change . . . . . . . . . . . . . . 78 5.5.10Query: Privileged Users Login . . . . . . . . . . . . . . . . . . . . 79 5.5.11Dashboard di monitoraggio dei login falliti . . . . . . . . . . . . . 80 5.5.12Filter: VPN Successfull Login . . . . . . . . . . . . . . . . . . . . 80 5.5.13Filter: VPN Failed Login . . . . . . . . . . . . . . . . . . . . . . 80 xi ELENCO DELLE FIGURE 5.6.1 Rule: High Number of Denied Connections . . . . . . . . . . . . 82 5.6.2 Rule: Firewall Network Port Scan . . . . . . . . . . . . . . . . . 83 5.6.3 Filtri: Denied Inbound Connections e Denied Outbound Connec- tions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 5.6.4 Dashboard: Firewall Overview . . . . . . . . . . . . . . . . . . . 84 5.6.5 Filtro: IDS - IPS Events . . . . . . . . . . . . . . . . . . . . . . . 85 5.6.6 Dashboard: IPS Overview . . . . . . . . . . . . . . . . . . . . . . 85 5.7.1 Rule: Antivirus Unsuccessfull Clean . . . . . . . . . . . . . . . . 86 5.7.2 Filter: Target Port Activity By Attacker . . . . . . . . . . . . . . 87 5.7.3 Rules: Possible Outbound Network Sweep e Possible Inbound Network Sweep . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 5.7.4 Rule: Worm Outbreack . . . . . . . . . . . . . . . . . . . . . . . 88 5.7.5 Filtro: Virus Activity . . . . . . . . . . . . . . . . . . . . . . . . 89 5.8.1 Filtro: Web Application . . . . . . . . . . . . . . . . . . . . . . . 90 5.8.2 Rule: Web Attack . . . . . . . . . . . . . . . . . . . . . . . . . . 90 xii Elenco delle tabelle 2.1 Eventi normalizzati . . . . . . . . . . . . . . . . . . . . . . . . . . 29 2.2 Eventi standard in un SIEM . . . . . . . . . . . . . . . . . . . . . 32 3.1 Categorizzazione degli eventi nello schema ESM . . . . . . . . . . 42 3.2 Gruppo di eventi . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 5.1 Formato del file CSV delle zone . . . . . . . . . . . . . . . . . . . 71 5.2 Formato del file CSV degli asset . . . . . . . . . . . . . . . . . . 73 xiii ELENCO DELLE TABELLE xiv Parte I Gestione dei log mediante un System and Event Management 1 Capitolo 1 La gestione dei log di
sicurezza 1.1 Introduzione Con il termine log si intende un record di eventi che si verificano allâ''interno dei sistemi e delle reti di unâ''organizzazione. I log sono composti da entries; ogni entry contiene informazioni relative ad uno specifico evento che si Ã¨ verificato allâ''interno di un sistema o di una rete. In origine i log erano usati soprattutto per la risoluzione dei problemi, ma attualmente i log espletano varie funzioni al- lâ''interno delle organizzazioni, come lâ''ottimizzazione delle prestazioni dei sistemi e delle reti, la registrazione delle azioni degli utenti, lâ''investigazione sulle attivi- tÃ malevole. Molti di questi log contengono informazioni relative alla sicurezza dei sistemi; esempi di questo tipo di log sono gli audit log, che tengono traccia dei tentativi di autenticazione degli utenti e i log dei dispositivi di sicurezza, che registrano possibili attacchi. In seguito allâ''aumento del numero di dispositivi connessi alla rete e allâ''au- mento delle minacce a tali sistemi, il numero di log Ã¨ andato via via aumentando, fino a richiedere un vero e proprio processo di log management. Con log ma-
nagement si intende il processo di generazione, trasmissione, memorizzazione, analisi e messa a disposizione dei log di sicurezza. Con infrastruttura di log management si intende lâ''insieme di hardware, soft- ware, reti e media utilizzati per il log management. 1.2 Tipologie di log di sicurezza Le varie tipologie di sistemi presenti allâ''interno di unâ''organizzazione producono log che contengono diverse tipologie di informazioni. Alcune tipologie di log sono piÃ¹ indicate di altre ai fini di indivuare attacchi, frodi e usi inappropriati. Per ogni tipo di situazione, certi log sono piÃ¹ pertinenti di altri nel contenere 3 CAPITOLO 1. LA GESTIONE DEI LOG DI SICUREZZA informazioni dettagliate sulle attivitÃ in questione. Altri tipi di log contengono informazioni meno dettagliate, ma sono comunque utili per correlare i log con quelli del tipo principale. Per esempio, un sistema di intrusion detection puÃ² rilevare comandi malevoli inviati ad un server da un host esterno: questa sarÃ la fonte primaria di informazioni. PuÃ² essere quindi utile cercare allâ''interno dei log di un firewall altre connessioni tentate dallo stesso IP sorgente: questa sarÃ la fonte secondaria di informazione sullâ''attacco. 1.2.1 Software di sicurezza Allâ''interno delle organizzazioni sono presenti diversi dispositivi di sicurezza che hanno lo scopo di evidenziare e di proteggere da attivitÃ malevole. Occorre partire da queste tipologie di log nella realizzazione di unâ''infrastruttura di log management. Descriviamo brevemente scopi e caratteristiche delle principali tipologie di dispositivi di sicurezza, al fine di comprendere che tipo di informazioni Ã¨ possibile estrarne. â'¢ Firewall. I firewall sono dispositivi che, basandosi su policy definite piÃ¹ o meno complesse, bloccano o permettono il passaggio di traffico di rete. Generalmente viene generato un record di log per ogni pacchetto o per ogni sessione del traffico di rete che attraversa il firewall, con la policy che viene applicata. â'¢ Sistemi AntiMalware. I software antimalware piÃ¹ comuni sono i soft- ware antivirus. Tipicamente registrano tutte le istanze di malware, file e sistemi disinfestati e file messi in quarantena. In piÃ¹, i software antivirus possono anche registrare quando vengono effettuate scansioni alla ricerca di malware e quando viene fatto lâ''update del database delle signature. â'¢ Sistemi di Intrusion Prevention e Intrusion Detection. I sistemi di Intrusion Detection e Intrusion Prevention hanno lo scopo di segnala- re (Intrusion Detection) e/o di bloccare (Intrusion Prevention) eventuali attacchi alle reti o ai sistemi, generalmente basando il riconoscimento su signature e/o anomalie nel comportamento. I log registrano informazioni sui sospetti tentativi di attacco e sulle azioni intraprese per bloccarli. â'¢ Virtual Private Network software. Le VPN garantiscono lâ''accesso remoto in modalitÃ sicura alle risorse aziendali. I log di tali sistemi con- tengono generalmente tentativi di autenticazioni, sia falliti che andati a buon fine, durata e provenienza delle connessioni, le risorse a cui lâ''utente ha avuto accesso. â'¢ Web Proxy. I web proxy sono sistemi che fungono da intermediari nel- lâ''accesso alle risorse web, mantenendo una cache locale delle pagine web e restringerndo lâ''accesso ad alcune risorse web basandosi su policy definite, proteggendo cosÃ¬ la rete dellâ''organizzazione. I log registrano gli url a cui gli utenti hanno avuto accesso attraverso il web proxy. 4 CAPITOLO 1. LA GESTIONE DEI LOG DI SICUREZZA â'¢ Sistemi di autenticazione. Tipicamente directory server, radius ser- ver e server di single sign on, registrano le autenticazioni andate a buon fine e i tentativi di autenticazione falliti, con lo username dellâ''utente, il timestamp, il sistema di provenienza. â'¢ Software per la gestione delle vulnerabilitÃ . In questa categoria sono compresi i software per la gestione delle patch di sicurezza e i software per il vulnerability assessment. I log contengono la storia delle patch installate e lo stato delle vulnerabilitÃ di ogni host. Esempi di log di sistemi di sicurezza sono mostrati nella figura 1.2.1. 1.2.2 Sistemi operativi Anche i sistemi operativi presenti su server, workstation e apparati di rete pro- ducono log significativi dal punto di vista della sicurezza, appartenenti alle ca- tegorie di seguito elencate. I log dei sistemi operativi contengono inoltre log dei software di sicurezza e delle applicazioni installate sul sistema: tali log rientrano nelle tipologie trattate al paragrafo precedente e al paragrafo successivo. â'¢ Eventi di sistema. Gli eventi di sistema sono azioni svolte dai singo- li componenti dei sistemi operativi. Tipicamente vengono registrati gli eventi falliti e gli eventi piÃ¹ significativi che hanno avuto successo. Alcuni sistemi operativi permettono allâ''amministratore di definire i tipi di eventi di cui tenere traccia. I log contengono un timestamp, il nome del sistema e altre informazioni che possono variare enormemente da sistema a sistema, come descrizione dellâ''evento, stato, codici di errore. â'¢ Audit Record. Contengono eventi relativi alla sicurezza, come tentativi di autenticazione andati a buon fine o falliti, utilizzo di privilegi ammi- nistrativi da parte dellâ''utente, accesso a file critici, modifica di policy di sicurezza, creazione, modifica, cancellazione di account e variazione nella composizione di gruppi. Gli amministratori dei sistemi operativi in genere possono specificare quali tipi di eventi possono essere soggetti ad audit e se tenere traccia di alcune azioni andate a buon fine o fallite. I log del sistema operativo sono importanti soprattutto nel caso di attacchi verso un host specifico. Se per esempio da parte di un software di sicurezza viene se- gnalato unâ''attivitÃ sospetta, sui log del sistema operativo possono essere trovati maggiori dettagli sullâ''attivitÃ segnalata. La maggior parte dei sistemi opera- tivi produce log in formato syslog, mentre, altri, come per esempio Microsoft Windows, utilizzano un formato proprietario. Un esempio di log di sistemi operativi sono mostrati nella figura 1.2.2. 1.2.3 Applicazioni Le applicazioni, usate allâ''interno delle organizzazioni per memorizzare, accedere e manipolare i dati usati dai processi di business, possono generare i loro log o 5 CAPITOLO 1. LA GESTIONE DEI LOG DI SICUREZZA utilizzare le funzionalitÃ di log del sistema operativo. Le informazioni contenute allâ''interno dei log cambiano enormemente a seconda del tipo di applicazione. Di seguito vengono elencati tipologie di informazioni che possono essere contenute allâ''interno dei file di log di applicazioni e che possono riguardare il monitoraggio della sicurezza. â'¢ Richieste del client e risposte del server. Possono essere molto utili per ricostruire sequenze di eventi e il loro esito, in caso di investigazione su- gli incidenti, nelle operazioni di audit e in fase di verifiche sulle conformitÃ alle policy. â'¢ Informazioni su account. Contengono informazioni come tentativi di autenticazione che hanno avuto successo o che sono falliti, modifiche sugli account, uso di privilegi. Possono essere utilizzati per individuare attacchi di forza bruta o escalation di privilegi e per verificare chi ha utilizzato lâ''applicazione e in quali momenti. â'¢ Informazioni sullâ''uso. Contengono informazioni come il numero di transazioni in un certo periodo di tempo e la grandezza delle transazio- ni. Possono essere utilizzati per alcuni tipi di monitoraggio, quando si verificano variazioni significative rispetto al normale utilizzo. â'¢ Azioni significative. Contengono informazioni come lâ''avvio o lo stop dellâ''applicazione, errori dellâ''applicazione o le principali modifiche nella configurazione. Possono essere utilizzate per verificare le compromissioni della sicurezza e malfunzionamenti. Un esempio di log di un web server Ã¨ mostrato nella figura 1.2.3. Tali log sono importanti soprattutto in caso di incidenti che coinvolgono le applicazioni; spesso perÃ² sono in formato proprietario, cosa che rende difficile il loro utilizzo. 1.3 Gli scopi Gli scopi che ci si prefigge nellâ''implementazione di unâ''infrastruttura di log management allâ''interno di unâ''azienda sono sostanzialmente due: â'¢ il monitoraggio della sicurezza dei propri asset, che vanno protetti da tutti gli attacchi a cui possono essere soggetti; â'¢ la conformitÃ alle normative che regolano la sicurezza e la privacy. Se sicurezza informatica vuole dire garantire la confidenzialitÃ , lâ''integritÃ e la disponibilitÃ del dato, come ci insegna qualsiasi manuale di sicurezza informati- ca, i due punti precedenti vanno declinati sul modello di business della singola azienda. Occorre quindi partire da unâ''analisi dei rischi, nella quale si cerca di capire qual Ã¨ il valore dei singoli asset, quali sono le principali minacce a cui sono soggetti, la probabilitÃ che si concretizzino, ottenendo cosÃ¬ una valutazione del 6 CAPITOLO 1. LA GESTIONE DEI LOG DI SICUREZZA rischio. Il modello di business dellâ''organizzazione Ã¨ anche il punto da cui partire per definire quali sono le leggi, le normative, gli standard o semplicemente le best pratice relative alla privacy e alla sicurezza informatica che lâ''organizzazione Ã¨ tenuta a rispettare. 1.3.1 Monitoraggio della sicurezza 1.3.1.1 Lâ''analisi dei rischi Differenti tipi di organizzazione hanno differenti tipi di dati da proteggere, a seconda di come Ã¨ configurato il loro business. Un sistema di monitoraggio della sicurezza, e ancor piÃ¹ in generale il processo di messa in sicurezza del sistema informativo di unâ''organizzazione, per poter essere efficace deve partire da unâ''analisi dei rischi. Lâ''analisi dei rischi puÃ² essere scomposto nelle seguenti fasi: â'¢ identificazione o classificazione degli asset da proteggere; â'¢ identificazione delle minacce a cui sono soggetti gli asset; â'¢ identificazione delle vulnerabilitÃ ; â'¢ stima delle probabilitÃ di sfruttamento; â'¢ valutazione del rischio. Identificazione o classificazione degli asset da proteggere In questa fase occorre fare un inventario di tutti gli asset. Con asset si intende una risorsa informativa che puÃ² essere un dato, un software, un hardware. In particolare tale inventario dovrebbe definire, per gli asset censiti, dati come tipo di risorsa (dato, hardware, software, ...), criticitÃ , proprietÃ delle informazioni, posizione fisica o logica, numero di inventario (in caso di asset fisico), informazioni relativi a contratti di manutenzione per lâ''asset, relazione con asset di altri tipi (es. un server con le applicazioni in esecuzione su di esso). Al fine poi della protezione delle risorse il dato piÃ¹ importante Ã¨ quello della criticitÃ ; il valore della criticitÃ deve essere ricavato, soprattutto per quel che riguarda le risorse informative, a partire dalle caratteristiche del proprio business confrontate con gli obiettivi primari della sicurezza, confidenzialitÃ , integritÃ e disponibilitÃ . La classificazione degli asset dovrebbe avvenire proprio a partire dalla criticitÃ . Identificazione delle minacce a cui sono soggetti gli asset Le minac- ce possono essere di diversi tipi, che devono essere considerati in relazione alle caratteristiche dellâ''organizzazione. Queste vanno valutate sia in termini di lo- cazione geografica, sia (e soprattutto) in riferimento alle attivitÃ e al modello di business. Per esempio, una banca sarÃ maggiormente esposta a minacce di tipo volontario di quanto non lo sia una catena di ristoranti. 7 CAPITOLO 1. LA GESTIONE DEI LOG DI SICUREZZA Ognuno dei modi in cui una risorsa puÃ² essere danneggiata, alterata, rubata, distrutta o resa inaccessibile, costituisce una minaccia. Tra questi modi bisogna considerare sia quelli volontari che involontari, senza dimenticare le catastrofi, quali incendi, terremoti e inondazioni. Identificazione delle vulnerabilitÃ (vulnerability assessment) Con vul- nerabilitÃ si intende una o piÃ¹ situazioni particolari o debolezze che possono essere sfruttate affinchÃ© le minacce si concretizzino. Considerando le varie mi- nacce (che possono essere anche di tipo misto), Ã¨ possibile determinare quali vulnerabilitÃ possono essere sfruttate. Le vulnerabilitÃ sono, in generale, dovu- te a errori o trascuratezza di gestione: una configurazione superficiale, un bug del software, una versione non aggiornata dellâ''antivirus e cosÃ¬ via. Stima della probabilitÃ di sfruttamento Il passaggio successivo consiste nella determinazione della probabilitÃ con cui una vulnerabilitÃ possa essere sfruttata. Questa probabilitÃ Ã¨ ottenuta tenendo conto delle misure di sicurezza giÃ adottare allâ''interno dellâ''organizzazione e della probabilitÃ che qualcuno o qualcosa le aggiri. Valutazione del rischio Terminate le quattro fasi illustrate precedentemen- te, attraverso un lavoro di sintesi si arriverÃ alla valutazione del rischio, che puÃ² essere sia di tipo qualitativo che quantitativo, includendo, per esempio, valori numerici del rischio espressi in percentuale del fatturato. 1.3.1.2 VulnerabilitÃ e minacce Per poter operare un efficace monitoraggio della sicurezza, occorre tenere conto delle vulnerabilitÃ dei propri sistemi; sarebbe auspicabile trovare la maniera di inserire i report dei vari vulnerability assessment effettuati allâ''interno del sistema di log management, per automatizzare il processo di identificazione di possibili attacchi. Di seguito vengono analizzati alcune delle principali vulnerabilitÃ che pos- sono essere presenti allâ''interno dellâ''organizzazione. Protocolli vulnerabili I protocolli che regolano la comunicazione tra com- puter sono stati pensati parecchi anni fa e con una minima attenzione alle pro- blematiche della sicurezza. Alcuni di questi protocolli contengono vulnerabilitÃ note e alcuni di questi sono stati sostituiti con versioni piÃ¹ sicure. Per eliminare tali vulnerabilitÃ occorrerebbe definire delle policy che non permettano lâ''uso di protocolli vulnerabili. Sistemi che individuino tali protocolli sul loro segmento di rete, come router o IDS che siano configurati per inviare i loro log al sistema di log management, permettono di segnalare lâ''uso di protocolli vulnerabili non consentiti dalle policy. 8 CAPITOLO 1. LA GESTIONE DEI LOG DI SICUREZZA Errori di configurazione Gli errori di configurazione possono introdurre vul- nerabilitÃ su sistemi altrimenti sicuri. Tali errori possono essere frutto di sviste da parte di amministratori, mentre a volte possono essere appositamente com- messi da parte di utenti che intendono svolgere attivitÃ malevole senza essere scoperti. Esempi comuni di errori di configurazione possono essere lâ''attivazione o la disattivazione di servizi, la modifica di configurazione di servizi che ven- gono resi meno sicuri. Il sistema di log management puÃ² essere utilizzato per monitorare i servizi attivi sui sistemi e per ricevere i log di sistemi di controllo dellâ''integritÃ . Errori degli utenti Molte vulnerabilitÃ vengono introdotte nei sistemi da parte degli utenti che, sia perchÃ© non sono adeguatamente formati sulle possibili minacce, o perchÃ© giudicano eccessive le policy di sicurezza, possono tenere dei comportamenti o commettere errori che mettano a repentaglio la sicurezza della rete e del sistema informativo dellâ''organizzazione. Esempi di comportamenti di questo tipo sono lâ''installazione di software non autorizzato, la navigazione su siti di dubbia reputazione, il desiderio di accedere a documenti riservati, la navigazione su siti contenuti in email che sono in realtÃ attacchi di phishing. Al di lÃ del fatto che la contromisura piÃ¹ efficace a questo tipo di vulnerabilitÃ Ã¨ la formazione continua degli utenti, questi comportamenti, se il sistema di log management Ã¨ opportunamente configurato, possono essere monitorati. Minacce interne ed esterne Passando dal campo delle vulnerabilitÃ a quel- lo delle intenzioni malevole, le reti aziendali sono normalmente meno protette verso gli attacchi provenienti dallâ''interno rispetto a quelli provenienti dallâ''ester- no. Il motivo principale Ã¨ che molte reti sono costruite puntando i sistemi di sicurezza verso lâ''esterno, lÃ dove si pensa vengano la maggior parte delle mi- nacce. Le statistiche dicono invece che la maggior parte degli attacchi proviene dallâ''interno; per questo motivo nelle misure di sicurezza occorre sempre tenere presente tali minacce. Come contromisure alle minacce interne, occorre sempre tenere conto del principio del minimo privilegio, cercando di fare in modo di concedere a ciascun utente i minimi privilegi che gli permettano di svolgere la sua attivitÃ . Le tecniche per limitare le possibilitÃ che utenti alterino la sicurezza dei sistemi e/o per rilevare possibili azioni malevole sono: â'¢ separazione dei privilegi;
â'¢ rotazione delle attivitÃ ;
â'¢ definizione di access control list (ACL) secondo il principio del minimo privilegio; â'¢ implementare lâ''auditing su dati critici, applicazioni, configurazioni e log dei sistemi. Le minacce esterne sono generalmente piÃ¹ facili da rilevare, in quanto esistono apparati di sicurezza in grado di segnalare attacchi provenienti dallâ''esterno. 9 CAPITOLO 1. LA GESTIONE DEI LOG DI SICUREZZA Tale rilevazione Ã¨ piÃ¹ facile nel caso di attacchi operati con tool automatici, che lasciano molte piÃ¹ tracce e generano piÃ¹ â''rumoreâ', rispetto ad attacchi manuali mirati. 1.3.1.3 Riconoscimento degli attacchi La maggior parte degli attacchi, di qualsiasi tipo, lasciano tracce allâ''interno dei log di uno o piÃ¹ sistemi. Una volta che questi log sono arrivati al sistema di log management, il team di sicurezza puÃ² comprendere che qualcosa di sospetto sta accadendo. Di seguito viene presentato un sommario di alcuni eventi contenuti in un attacco e che possono essere identificabili e alcuni modi in cui puÃ² essere confi- gurato il sistema di log management per identificarli rapidamente. Scansione e riconoscimento Normalmente la fase preliminare di ogni at- tacco prevede la scansione della rete per identificarne la topologia, i sistemi che ne fanno parte e la presenza di eventuali servizi vulnerabili. Tale attivitÃ si compone normalmente di due fasi, una fase di fingerprinting, durante la quale lâ''attaccante cerca di identificare la struttura del sistema IT, le sottoreti IP e i sistemi di tali sottoreti, e la fase di footprinting, nella quale lâ''attaccante cerca di identificare la natura dei nodi individuati durante la fase precedente, sistema operativo, servizi attivi e relative versioni, livello di patching; ciÃ² allo scopo di individuare allâ''interno della rete i sistemi piÃ¹ appetibili, o per la rilevanza dei dati contenuti, o per la presenza di vulnerabilitÃ che permettano facilmente di prenderne possesso. Durante tale fase, soprattutto se svolta con tool automatici, avremo, nellâ''arco di un periodo di tempo limitato, una certa quantitÃ di pacchetti provenienti da un unico indirizzo IP verso molti indirizzi della rete o verso molte porte tcp e udp di un singolo target. Lâ''attaccante puÃ² svolgere la scansione e il riconoscimento in maniera manuale, diradando la frequenza dei pacchetti e utilizzando piÃ¹ indirizzi IP sorgenti, rendendo lâ''identificazione di questo tipo di attivitÃ piÃ¹ complicata. Malware Una volta che lâ''attaccante ha unâ''idea della topologia della rete ed ha identificato uno o piÃ¹ sistemi target che espongono vulnerabilitÃ o che sono appetibili, la fase successiva puÃ² essere quella di installare malware sui sistemi target nella speranza di comprometterli. Questa fase puÃ² avvenire anche diret- tamente, saltando la fase di scansione e riconoscimento, per esempio attraverso attacchi automatici fatti da un worm che cerca di propagarsi. Esempi di malware sono i virus e i worm. I virus si iniettano allâ''interno del codice eseguibile e una volta che il codice eseguibile viene lanciato, il codice del virus viene eseguito con i privilegi dellâ''utente che lo ha lanciato. Normalmente il virus replica sÃ© stesso, oltre ad eseguire le attivitÃ malevole definite allâ''interno del suo codice. I worm sono un tipo malware che si auto-propaga e che sfrutta vulnerabi- litÃ note allâ''interno di applicazioni o servizi. Una prevenzione per i worm Ã¨ lâ''installazione tempestiva delle patch di sicurezza sui sistemi. 10 CAPITOLO 1. LA GESTIONE DEI LOG DI SICUREZZA I malware vengono rilevati dai sistemi antivirus, che devono essere configurati per inviare i log al sistema di log management. Allâ''interno del sistema di log management, occorre essere in grado di rilevare la presenza dello stesso malware su diversi sistemi o lâ''individuazione di un malware che lâ''antivirus non Ã¨ in grado di eliminare. IP spoofing Molti attacchi provenienti dallâ''esterno vengono fatti in modo da presentarsi come provenienti da IP appartenenti alla rete interna (ip spoofing dallâ''esterno), in generale IP privati. Alla stessa maniera, un malintenzionato che si trova su una rete interna privata, puÃ² generare pacchetti con IP sorgente pubblico, diretti verso lâ''esterno (ip spoofing dallâ''interno). In entrambi i casi il firewall dovrÃ bloccare tale tipo di pacchetti e inviare i log di tali blocchi al sistema di log management. Denial-of-service distribuito (DDoS) In questo attacco, molti IP sorgenti diversi inviano pacchetti ad un singolo indirizzo IP ad una tale frequenza che il sistema sotto attacco, cercando di soddisfare queste false richieste, finisce per non rispondere piÃ¹ alle richieste di servizio lecite. Questo tipo di attacco Ã¨ difficile da individuare; il sistema migliore sono le segnalazioni di sistemi IDS basati sullâ''analisi delle anomalie di comportamento, eventualmente correlate con segnalazioni di utenti. Buffer overflow e attacchi di SQL injection Sono attacchi che sfruttano vulnerabilitÃ causate da errori di programmazione nelle applicazioni, in par- ticolare la mancata validazione dellâ''input dellâ''utente. Gli attaccanti possono sfruttare tali vulnerabilitÃ per ottenere lâ''accesso a sistemi o a database. A par- te la necessitÃ di eliminare preventivamente vulnerabilitÃ di tale tipo, attraverso processi di vulnerability assessement o di auditing del codice, tentativi di at- tacco di tale tipo possono essere individuati attraverso lâ''analisi dei log degli application server, che segnalano eventuale input dellâ''utente rigettato. Anche i sistemi IDS contengono le signature di molti di questi attacchi. Attacchi di forza bruta alle password Un malintenzionato potrebbe ten- tare di ottenere lâ''accesso ad un sistema o ad unâ''applicazione provando diverse combinazioni di password, generalmente con lâ''aiuto di apposite applicazioni. Una contromisura a questo tipo di minaccia puÃ² essere quella di bloccare tem- poraneamente un account dopo un certo numero di errori di autenticazione, anche se tale contromisura puÃ² rendere vulnerabili ad attacchi di denial of ser- vice. Attacchi di questo tipo possono essere rilevati attraverso il monitoraggio dei log dei sistemi di autenticazione. Attacchi ai sistemi IPS/IDS I sistemi IPS/IDS sono un componente fonda- mentale del monitoraggio della sicurezza. Ã' bene monitorare i pacchetti diretti a tali sistemi, in quanto normalmente non esistono pacchetti destinati ai sistemi IPS/IDS, se non provenienti dai sistemi di management. 11 CAPITOLO 1. LA GESTIONE DEI LOG DI SICUREZZA Nel caso un attacco sia andato a buon fine, lâ''attaccante provvederÃ a na- scondere le sue tracce, in modo da poter continuare indisturbato a svolgere le sue attivitÃ . Di seguito viene presentato un sommario delle modalitÃ con cui un attaccante puÃ² procedere a tale scopo. Disattivazione degli aggiornamenti di sistema operativo Al fine di mantenere la vulnerabilitÃ appena sfruttata, lâ''attaccante potrebbe disabilita- re lâ''installazione delle patch di sistema, che rimuovono le vulnerabilitÃ note. Occorre tenere costantemente monitorata lâ''installazione delle patch di sicurez- za. Unâ''altra tecnica piÃ¹ sofisticata consiste nella modifica delle impostazioni per la risoluzione dei nomi per far puntare il sistema compromesso ad un server DNS sotto il controllo dellâ''attaccante. In questa maniera gli aggiornamenti di sicurezza verranno scaricati da un sito sotto il controllo dellâ''attaccante. Occorre monitorare le connessioni dirette alla porta 53 di indirizzi IP diversi dai server DNS legittimi. Unâ''altra tecnica con le stesse finalitÃ consiste nel modificare il file hosts locale al sistema compromesso: occorre tenere modificate tutte le modifiche al file hosts dei sistemi. Disattivazione degli aggiornamenti del software antivirus e antispy-
ware Al fine di evitare che il malware installato venga rilevato, lâ''attaccante potrebbe impedire al sistema di connettersi ai server da cui vengono scaricate le signature e gli aggiornamenti per i software antivirus e antispyware. Anche in questo caso occorre monitorare gli aggiornamenti dei sistemi, le connessioni aperte verso la porta 53 di indirizzi IP diversi dai server DNS legittimi. Disattivazione del forwarding dei log al sistema di log management
Lâ''attaccante, al fine di disperdere le proprie tracce, potrebbe disabilitare il for- warding dei log verso il sistema di log management. Occorre monitorare, sul sistema di log management, se i sistemi interrompono la trasmissione dei log. Modifica alle configurazioni dei sistemi Allo scopo di aprire nuove bac- kdoor e assicurarsi la possibilitÃ di accedere nuovamente al sistema, lâ''attaccan- te potrebbe effettuare modifiche alla configurazione del sistema compromesso. Queste modifiche possono essere rilevate da tool di verifica dellâ''integritÃ . I log di tali sistemi possono essere inviati al sistema di log management. Installazione di nuovi servizi e disattivazione di altri servizi Allo scopo di aprire nuove backdoor e assicurarsi la possibilitÃ di accedere nuovamente al sistema, lâ''attaccante potrebbe avviare servizi esistenti o installare nuovi servizi. Potrebbe inoltre arrestare o disabilitare servizi legati alla sicurezza del sistema. Anche in questo caso occorre rilevare le modifiche alle configurazioni dei sistemi, inviando i riscontri al sistema di log management. 12 CAPITOLO 1. LA GESTIONE DEI LOG DI SICUREZZA Inoltre lâ''attaccante, dopo essersi nascosto, avrÃ necessitÃ di installare dei tool e malware che gli permettano di operare un controllo maggiore sulla rete dellâ''organizzazione. A tale scopo provvederÃ a fare un download di rootkit o collezione di malware da installare allâ''interno della rete compromessa. Di seguito viene presentato un elenco di tecniche usate dagli attaccanti a tale scopo. Reset della home page di default del browser Quando un browser carica un sito web, script ed eseguibili possono essere messi in esecuzione sul sistema client. Se lâ''attaccante puÃ² modificare la home page di default del browser, even- tuale software malevolo contenuto in tale home page verrÃ eseguito non appena lâ''utente apre il browser. Se poi la home page Ã¨ costruita in modo da assomigliare a quella legittima, tale malware puÃ² essere eseguito piÃ¹ volte. Una protezione a questo tipo di attacco puÃ² essere quella di impostare a livello centrale la home page di default del browser. Uso di IP che fanno parte di blacklist Gli attaccanti hanno spesso ne- cessitÃ di mantenere risorse raggiungibili da Internet, per ottenere i loro scopi. Alcuni server che ospitano attivitÃ malevole sono conosciuti e finiscono nelle co- siddette â''black listâ'. Ci sono parecchi siti su Internet che mantengono blacklist aggiornate e rendono tali liste disponibili per il download. Alcuni IDS hanno la possibilitÃ di consultare e scaricare blacklist in modo da monitorare pacchetti distinati ad IP appartenenti ad esse. Traffico anomalo Spesso le risorse esterne dellâ''attaccante non sono ancora state identificate e non sono ancora entrate a far parte di blacklist, oppure do- po essere entrate a far parte di blacklist lâ''attaccante ha spostato il server su un altro indirizzo IP. Occorre quindi monitorare la rete alla ricerca di traffico anomalo, pur diretto ad IP leciti. Esempi di questo tipo di monitoraggio pos- sono essere upload e download di file di grandi dimensioni, traffico verso porte note per essere utilizzate da malware, traffico eccessivo verso IP di paesi da cui notoriamente arriva il maggior numero di attacchi. Infine, una volta che lâ''attaccante ha una conoscenza approfondita della rete compromessa, ha individato alcuni sistemi da attaccare, ha preso possesso di tali sistemi, ha coperto le proprie tracce, si Ã¨ assicurato la possibilitÃ di continuare ad accedere, ha contattato il proprio repository esterno per il download della versione aggiornata della propria collezione di malware, avrÃ necessitÃ di inviare dati allâ''esterno. Di seguito verrÃ presentato un elenco di tecniche utilizzate in questa fase. IRC Questo protocollo Ã¨ spesso usato come mezzo di comunicazione fra lâ''at- taccante e la sua collezione di sistemi compromessi, chiamata zombies. Una chat room puÃ² essere utilizzata dallâ''attaccante per isolarsi dai suo zombies, ri- manendo cosÃ¬ anonimo. Gli zombies possono essere istruiti per ricevere comandi 13 CAPITOLO 1. LA GESTIONE DEI LOG DI SICUREZZA attraverso una chat room. Normalmente il protocollo IRC non Ã¨ utilizzato al- lâ''interno delle organizzazioni, per cui occorre monitorare la propria rete alla ricerca di tentativi dâ''uso di tale protocollo. Porte conosciute come destinazione di traffico malevolo Molti tipi di malware utilizzano porte specifiche per comunicare. Occorre monitorare il traffico diretto verso tali porte. Protocolli inattesi/atipici Il traffico e i protocolli usati allâ''interno della rete di unâ''organizzazione rientrano spesso in una lista standard e predicibile. Occorre monitorare lâ''uso di protocolli e destinazioni che non rientrano in tale lista. 1.3.2 Compliance alle normative Negli ultimi anni, in seguito allâ''aumento del numero dei dati trattati, si Ã¨ as- sistito ad un aumento della consapevolezza da parte delle organizzazioni del- lâ''importanza delle informazioni trattate, e quindi della loro protezione, per il raggiungimento degli obiettivi di business. Vi Ã¨ quindi, da parte delle organiz- zazioni, una crescente esigenza di â''complianceâ', ovvero di predisporre processi e modalitÃ di gestione delle informazioni, che abbiano adeguati requisiti di ri- servatezza, tracciabilitÃ e protezioni, richieste dalle leggi vigenti, ma anche da standard internazionali, da â''best practiceâ' e policy interne allâ''organizzazione. Limitandoci allâ''aspetto delle normative, uno dei motivi che negli ultimi anni hanno portato molte organizzazioni alla creazione di infrastrutture di log ma- nagement Ã¨ lâ''introduzione di leggi che hanno lo scopo di regolare la protezione delle informazioni da parte delle organizzazioni, al fine di prevenire eventuali danni ad individui e ad altre organizzazioni. Un tratto comune di queste nor- mative Ã¨ lâ''introduzione dellâ''obbligo di controllo sulla sicurezza dei sistemi IT e dellâ''obbligo di documentare le misure e le procedure di sicurezza adottate. Alcune normative, per lo piÃ¹ riguardanti gli operatori finanziari, prevedono esplicitamente forme di log management. Lâ''unica normativa italiana che prevede esplicitamente la raccolta e la gestione di log Ã¨ il â''Provvedimento del Garante per la Protezione dei Dati Personali relativo agli Amministratori di Sistemaâ', ma occorre considerare che organizzazioni che operano sul mercato bancario e finanziario internazionale sono tenute a rispettare standard e best practice internazionali. Di seguito vediamo piÃ¹ in dettaglio alcune di queste normative. Il Testo Unico sulla Privacy (Dlgs196/2003) Il Codice in materia di dati personali, varato il 30 giugno 2003 ed entrato in vigore il 1Â° gennaio 2004, riuni- sce tutti i provvedimenti normativi connessi con la protezione dei dati personali varati precedentemente. Il testo unico introduce (allegato B) un Disciplinare Tecnico in materia di misure minime di sicurezza. La novitÃ piÃ¹ importante introdotta dal testo unico consiste nellâ''obbligo di creare una catena di comando 14 CAPITOLO 1. LA GESTIONE DEI LOG DI SICUREZZA formalizzata, dedicata a garanzia della privacy, in cui vengono definiti, per cia- scun trattamento di dati, ruoli specifici (Titolare del trattamento, Responsabile, Incaricato) a cui corrispondono compiti e responsabilitÃ definite. Vengono inol- tre introdotte le cosiddette misure minima di sicurezza relative al trattamento di dati personali con strumenti elettronici: â'¢ autenticazione informatica; â'¢ adozione di procedure di gestione delle credenziali di autenticazione; â'¢ utilizzazione di un sistema di autorizzazione; â'¢ aggiornamento periodico dellâ''ambito del trattamento consentito ai singo- li incaricati e addetti alla gestione o alla manutenzione degli strumenti elettronici; â'¢ protezione degli strumenti elettronici e dei dati rispetto a trattamen- ti illeciti dei dati, ad accessi non consentiti e a determinati programmi informatici; â'¢ adozione di procedure per la custodia di copie di sicurezza, il ripristino della disponibilitÃ dei dati e dei sistemi; â'¢ tenuta di un aggiornato documento programmatico sulla sicurezza; â'¢ adozione di tecniche di cifratura o di codici identificativi per determinati trattamentidi dati idonei a rivelare lo stato di salute o la vita sessuale effettuati da organismi sanitari (dati sensibili). Di rilevante per lâ''ambito qui trattato vi Ã¨ lâ''esigenza di identificare in maniera certa gli incaricati di ciascun trattamento quando questi accedono ai dati e ai sistemi che li contengono. CiÃ² porta a prevedere un processo per lâ''assegnazione dei privilegi minimi per gli operatori che hanno lâ''esigenza di lavorare sui soli dati, per le sole operazioni previste dal proprio ruolo e necessarie per lo svolgimento delle proprie mansioni. Il requisito di poter attribuire in modo inequivocabile le azioni compiute su un dato critico al suo effettivo autore obbliga a prevedere un sistema di tracciamento, non ripudiabile, che intervenga ad ogni livello di operazione compiuta su un dato critico. Il controllo sullâ''operato degli Amministratori di Sistema Il Provvedi- mento del Garante per la Protezione dei dati personali relativo agli Ammini- stratori di Sistema, varato il 27 novembre 2008, le cui prescrizioni sono entrate in vigore il 15 dicembre 2009, nasce dalla constatazione che gli amministratori di sistema svolgono funzioni delicate che comportano la concreta capacitÃ di accedere a tutti i dati che transitano sulle rete di aziende e pubbliche ammi- nistrazioni. Le ispezioni effettuate nel corso degli anni da parte dellâ''AutoritÃ Garante hanno messo in luce in diversi casi una scarsa consapevolezza da parte delle organizzazioni di qualsiasi dimensione del ruolo svolto dagli amministratori di sistema e una sottovalutazione dei rischi che possono derivare da unâ''attivitÃ 15 CAPITOLO 1. LA GESTIONE DEI LOG DI SICUREZZA di questo tipo svolta senza il necessario controllo. Per questo motivo il Garante ha deciso di prescrivere lâ''adozione di specifiche misure tecniche e organizzative che agevolino la verifica sulla sua attivitÃ da parte di chi ha la titolaritÃ delle banche dati e dei sistemi informatici. Il provvedimento del Garante prescrive che lâ''operato degli amministratori di sistema deve essere oggetto, con cadenza almeno annuale, di unâ''attivitÃ di verifica da parte dei titolari del trattamento, in modo da controllare la sua rispondenza alle misure organizzative, tecniche e di sicurezza riguardanti i trat- tamenti di dati personali. Inoltre devono essere adottati strumenti idonei alla registrazione degli accessi logici ai sistemi di elaborazione e agli archivi elettro- nici da parte degli amministratori di sistema. Ciascuna organizzazione dovrÃ conservare in un documento gli estremi identificativi degli amministratori di si- stema e lâ''elenco delle funzioni loro attribuite. Dovranno essere infine valutate con attenzione esperienza, capacitÃ e affidabilitÃ della persona chiamata a rico- prire il ruolo di amministratore di sistema, che deve essere in grado di garantire il pieno rispetto della normativa in materia di protezione dei dati personali, compreso il profilo della sicurezza. Il Payment Card Industry Data Security Standard (PCI DSS) Lo standard Payement Card Industry (PCI) Data Security Standard (DSS) rego- lamenta le modalitÃ di realizzazione e di protezione dei sistemi di pagamento e delle carte che vengono utilizzate nellâ''ambito dei circuiti di pagamento. Questo standard si applica a tutte le infrastrutture di rete, server, sistemi di messaggi- stica e applicazioni utilizzate allâ''interno di ambienti dove sono conservati dati relative alle carte di credito o debito. Lo standard contiene specifiche per 12 aree di controllo separate: 1. provvedere allâ''installazione e manutenzione di firewall; 2. non utilizzare dati di default forniti dal venditore come password di siste- ma; 3. proteggere i dati di un proprietario di card che siano stati memorizzate in un sistema di storage aziendale; 4. criptare i dati del possessore di card quando vengono trasmessi su qualsiasi tipo di rete; 5. utilizzare e aggiornare con regolaritÃ il software delle applicazioni antivi- rus; 6. sviluppare e mantenere adeguatamente il sistema di sicurezza e le appli- cazioni; 7. limitare lâ''accesso in aderenza al concetto di need-to-know, ovvero conce- derlo esclusivamente a coloro che hanno ottimi motivi; 16 CAPITOLO 1. LA GESTIONE DEI LOG DI SICUREZZA 8. assegnare un ID univoco a ogni persona che abbia accesso ai computer interessati alla gestione o alla trasmissione dei dati di un proprietario di card; 9. limitare lâ''accesso ai dati di un proprietario di card anche dal punto di vista fisico; 10. effettuare il tracciamento e il monitoraggio di tutti gli accessi alle risorse e ai dati dei proprietari delle card ; 11. effettuare regolarmente il test sia del sistema di sicurezza che dei singoli processi; 12. mantenere e aggiornare costantemente una policy che indirizzi il tema della sicurezza delle informazioni. 1.4 Le strategie Una strategia di log management adeguata alle esigenze dellâ''organizzazione prevede i passi di seguito elencati. â'¢ Centralizzare nel sistema di log managementi tutti gli eventi rilevanti . Una volta definiti gli eventi rilevanti per la propria organizza- zione, occorre far sÃ¬ che tali eventi siano registrati allâ''interno di un sistema centralizzato, dopo averli sottoposti a filtraggio, aggregazione e normaliz- zazione. Solo gli eventi provenienti dai sistemi giudicati rilevanti debbono essere raccolti. â'¢ Definire lâ''ambito di applicazione. Occorre documentare quali sono i sistemi rilevanti ai fini del monitoraggio della sicurezza o del rispetto alle normative. Occorre definire quali sono le reti e gli asset interni che fanno parte di una rete protetta. Occorre, infine, produrre un documento che definisca dove sono registrati gli eventi e il periodo di conservazione per ogni tipologia di log. â'¢ Revisione tempestiva dei log. Definire quali sono gli Eventi di interes- se , ovvero gli eventi che possono costituire una minaccia, tenendo conto che, dei milioni di log prodotti giornalmente, meno dellâ''1% rappresenta una minaccia. Occorre definire dei Service Level Agreement (SLA) e delle
Standard Operating Procedures (SOPs) per ogni tipo di evento di inte- resse, stabilendo lâ''intervallo di tempo affinchÃ© lâ''evento venga evidenziato e una procedura da seguire per ogni evento di interesse. Occorre infine schedulare la produzione di report degli eventi chiave dei dispositivi di sicurezza. â'¢ Creare un percorso di audit degli eventi di interesse. Occorre man- tenere un percorso di audit sicuro per provare come gli eventi di interesse siano stati gestiti e risolti. Documentare come ogni evento di interesse sia stato gestito attraverso le SOPs e rispettando gli SLA. 17 CAPITOLO 1. LA GESTIONE DEI LOG DI SICUREZZA 1.5 Le sfide La gestione dei log allâ''interno delle organizzazioni presenta diverse sfide, che si possono riassumere con la considerazione che le risorse per la gestione dei log sono sempre meno e meno preparate, mentre il numero e la varietÃ dei log Ã¨ in aumento. Vediamo piÃ¹ in dettaglio quali sono le problematiche. 1.5.1 Gestione e registrazione dei log I log sono prodotti e risiedono su molti host allâ''interno dellâ''organizzazione, ren- dendo necessaria lâ''implementazione di un sistema di log management. Una stessa sorgente di log puÃ² inoltre generare molteplici log, per esempio unâ''appli- cazione puÃ² registrare gli eventi di autenticazione in un log e lâ''attivitÃ di rete in unâ''altra. Ogni sorgente di log registra solo alcune informazioni allâ''interno dei propri log, come lâ''indirizzo IP dellâ''host e lo username. Per efficienza, spesso la sorgente di log registra solo la parte di informazione ritenuta piÃ¹ importante. Questo puÃ² rendere difficile registrare gli eventi provenienti da diverse sorgenti (ad esempio la sorgente 1 registra lâ''indirizzo IP, ma non lo username e viceversa). Ogni tipo di log puÃ² inoltre rappresentare i valori in maniera diversa. Ogni sorgente di log registra eventi associando un timestamp basato sul suo orologio interno. Se lâ''orologio interno non Ã¨ preciso, lâ''evento verrÃ registrato con un timestamp non preciso, che in fase di analisi dei log potrebbe portare che una certa sequenza di eventi si sia svolta con un ordine diverso da quanto avvenuto realmente. Molte sorgenti di log usano diversi formati, come campi separati da virgola, campi separati da tabulazioni, database, syslog, snmp, file xml, file binari. Al- cuni formati di log sono pensati per essere letti da umani, altri no. Alcuni log, come le trap snmp, non sono pensati per la memorizzazione in un file, ma per la trasmissione via rete ad altri sistemi. Formati e contenuti inconsistenti rappresentano un problema in fase di re- visione dei log, in quanto occorre comprendere il significato di tutti i campi dati in tutti i log. Per facilitare lâ''analisi dei log, occorre implementare sistemi automatici per convertire log che hanno contenuti e formati differenti verso un formato standard con una rappresentazione coerente dei campi dati. 1.5.2 Protezione dei log I log provenienti dai diversi sistemi dellâ''organizzazione possono contenere dati delicati dal punto di vista della sicurezza o della privacy, come password di utenti, dati relativi alla navigazione o alle mail. Occorre quindi che i log siano protetti adeguatamente sia durante la trasmissione che durante la registrazione, sia dal punto di vista della confidenzialitÃ che dellâ''integritÃ . I log infatti non devono essere alterabili, per esempio da parte di malintenzionati che vogliano coprire le loro tracce. 18 CAPITOLO 1. LA GESTIONE DEI LOG DI SICUREZZA Occorre inoltre garantire la disponibilitÃ dei dati. Per esempio molti sistemi sono configurati in modo che i file di log abbiano una dimensione massima e che, raggiunta tale dimensione, i file di log siano sovrascritti. Per garantire il rispetto delle policy di retention, le organizzazioni devono conservare i log per un periodo di tempo maggiore rispetto a quello di persistenza sui sistemi di origine. 1.5.3 Analisi dei log Allâ''interno della maggior parte delle organizzazioni, gli amministratori di siste- ma e di rete sono stati tradizionalmente responsabili dellâ''analisi dei log, stu- diando i log per identificare eventi di interesse. Lâ''analisi dei log Ã¨ spesso stata trattata come attivitÃ a bassa prioritÃ da amministratori e dal management, perchÃ© altre attivitÃ degli amministratori necessitavano di risposte piÃ¹ rapide. Gli amministratori che effettuano lâ''analisi dei log spesso non ricevono forma- zione adeguata per effettuare lâ''analisi efficacemente ed efficientemente, partico- larmente per quel che riguarda la prioritarizzazione. Inoltre molti amministra- tori non hanno a disposizione tool che siano efficaci nellâ''automatizzazione dei processi di analisi. Molti di questi tool sono particolarmente efficaci nel trovare pattern che gli umani non possono vedere facilmente, come la correlazione di eventi da diverse sorgenti che si riferiscono allo stesso evento. Un altro problema consiste nel fatto che molti amministratori considerano lâ''attivitÃ di analisi dei log noiosa e poco proficua rispetto al tempo richiesto. Lâ''analisi dei log Ã¨ spesso trattata come reattiva, spesso fatta dopo che un problema Ã¨ stato giÃ identi- ficato mediante altri mezzi, piuttosto che proattiva, per identificare problemi imminenti. Tradizionalmente, la maggior parte dei log non viene analizzata in realtime. 1.6 I modelli 1.6.1 Il modello Syslog In una infrastruttura di log management basata sul modello syslog, ogni sorgente produce log dello stesso formato e utilizza lo stesso meccanismo per trasferire i log a un server syslog remoto. Syslog fornisce un semplice framework per la generazione, lo storage e il trasferimento dei log, che ogni sistema operativo, software di sicurezza o applicazione puÃ² utilizzare, se Ã¨ progettato per poterlo fare. Molte sorgenti di log usano syslog come formato nativo oppure offrono la possibilitÃ di convertire i log dal loro formato nativo a syslog. Lo standard syslog consente di operare una classificazione del messaggio, al fine di di stabilirne la tipologia e la prioritÃ , basandosi su due attributi: la facility e la severity. La facility rappresenta la tipologia del messaggio, per esempio messaggio del kernel, messaggio di autorizzazione, di sicurezza, applicativo. La severity puÃ² assumere un valore compreso fra 0 (emergency) e 7 (debug). 19 CAPITOLO 1. LA GESTIONE DEI LOG DI SICUREZZA Il formato syslog Ã¨ pensato per essere molto semplice e prevede che ogni messaggio sia formato da 3 parti: la prima parte contiene la facility e la severity, descritte sopra, in formato numerico, la seconda parte contiene il timestamp e il nome host (o lâ''indirizzo IP) del sistema che ha generato lâ''evento e la terza parte Ã¨ il contenuto del messaggio. Non ci sono campi standard definiti per syslog e lâ''unica possibilitÃ di classificazione Ã¨ quella basata su severity e faciltiy: solo mediante questi attributi Ã¨ possibile decidere come trattare e come fare il forward dei log. Lo storage dei log syslog puÃ² essere effettuato utilizzando file di testo locali al sistema che li ha generati oppure puÃ² essere effettuando un forward verso uno o piÃ¹ sistemi centralizzati. Lo standard syslog Ã¨ stato progettato in tempi in cui la sicurezza dei log non era oggetto di molta considerazione, per cui presenta alcuni aspetti critici. In primo luogo il protocollo di trasporto utilizzato da syslog per la trasmissione sulla rete Ã¨ lâ''UDP, protocollo senza connessione che non garantisce la consegna dei pacchetti. In secondo luogo, il server syslog che raccoglie messaggi via rete non effettua nessuna forma di autenticazione, per cui qualsiasi sistema puÃ² in- viare messaggi al server syslog, senza nessun ulteriore controllo. In terzo luogo, i log trasmessi via rete da syslog viaggiano in chiaro ed Ã¨ quindi possibile in- tercettarli. Alcune implementazioni di syslog presentano soluzioni a uno o piÃ¹ di questi problemi, per esempio utilizzando TCP invece che UDP, utilizzando TLS per crittografare i dati sulla rete e cosÃ¬ via, basate su una proposta di stan- dard lâ''RFC 3195, che ha lo scopo di migliorare la sicurezza di syslog, oppure anche soluzioni non previste dallâ''RFC 3195, come la memorizzazione dei log su database. Queste implementazioni, tuttavia, non sono supportate da tutti i sistemi. 1.6.2 Il modello SIEM Il modello System Information and Event Management (SIEM), pur non essendo standardizzato prevede maggiori funzionalitÃ rispetto al modello syslog e preve- de unâ''infrastruttura piÃ¹ complicata, contenente uno o piÃ¹ server che permettono lâ''analisi dei log, un database, strumenti per la correlazione degli eventi, uno o piÃ¹ database server per lo storage dei log, strumenti sofisticati per la ricerca e la reportistica. Essendo il modello SIEM lâ''oggetto di questa tesi, alla descrizione dettagliata della sua architettura Ã¨ dedicato tutto il capitolo 2. 20 CAPITOLO 1. LA GESTIONE DEI LOG DI SICUREZZA FIREWALL: 1:15:02 ctl craig.phoneboy.com >daemon sys_message:
installed defaultfilter; product: VPN-1 & FireWall-1; 1:15:02 ctl craig.phoneboy.com >daemon sys_message:
The eth-s3p1c0 interface is not protected by
the anti-spoofing feature.
Your network may be at risk; product: VPN-1 & FireWall-1; 1:15:02 ctl craig.phoneboy.com >daemon sys_message:
The eth-s2p1c0 interface is not protected by
the anti-spoofing feature.
Your network may be at risk; product: VPN-1 & FireWall-1; 1:15:02 ctl craig.phoneboy.com >daemon sys_message:
The eth-s1p1c0 interface is not protected by
the anti-spoofing feature.
Your network may be at risk; product: VPN-1 & FireWall-1; 1:43:20 ctl craig.phoneboy.com >daemon sys_message:
installed phoneboy-traditional; product: VPN-1 & FireWall-1; 1:43:20 craig.phoneboy.com >daemon cp_message:
Parameter â''Connections hash table sizeâ'' changed from
65536 to 32768; 12:34:08 drop craig >eth-s2p1c0 product:
VPN-1 & FireWall-1; src: Alpha-Cluster-Inside.foo.com; s_port: IKE; dst: craig; service: 876; proto: udp; rule: 5; 12:48:17 accept craig >eth-s1p1c0 product:
VPN-1 & FireWall-1; src: cartman.phoneboy.com; s_port: 2343; dst: craig; service: https; proto: tcp; rule: 1; INTRUSION DETECTION SYSTEM: 11/06/04-00:32:05.706661 {ICMP}
192.168.206.129 -> 192.168.100.5 [**] [1:469:3] ICMP
PING NMAP [**] [Classification: Attempted Information Leak] [Priority: 2] [Xref => http://www.whitehats.com/info/IDS162] 11/06/04-00:32:10.896823 {ICMP}
192.168.206.129 -> 192.168.100.5 [**] [1:469:3] ICMP
PING NMAP [**] [Classification: Attempted Information Leak] [Priority: 2] [Xref => http://www.whitehats.com/info/IDS162] Figura 1.2.1: Esempi di log di sistemi di sicurezza 21 CAPITOLO 1. LA GESTIONE DEI LOG DI SICUREZZA Oct 15 18:19:08 localhost audispd: node=prx01 type=ANOM_PROMISCUOUS msg=audit(1318695548.187:3561):
dev=eth0 prom=0 old_prom=256 auid=10000 ses=500 Oct 15 18:19:08 localhost audispd: node=prx01 type=SYSCALL msg=audit(1318695548.187:3561): arch=c000003e syscall=3 success=yes exit=0 a0=3 a1=1 a2=13e0c020 a3=0 items=0
ppid=25014 pid=25449 auid=10000 uid=77 gid=77 euid=77
suid=77 fsuid=77 egid=77 sgid=77 fsgid=77 tty=pts0 ses=500
comm="tcpdump" exe="/usr/sbin/tcpdump"
subj=user_u:system_r:unconfined_t:s0 key=(null) Oct 15 18:19:08 localhost audispd: node=prx01 type=EOE msg=audit(1318695548.187:3561):
Oct 15 18:21:29 localhost kernel:
device eth0 entered promiscuous mode Oct 15 18:21:29 localhost audispd: node=prx01 type=ANOM_PROMISCUOUS msg=audit(1318695689.232:3562):
dev=eth0 prom=256 old_prom=0 auid=10000 ses=500 Oct 15 18:21:29 localhost audispd: node=prx01 type=SYSCALL msg=audit(1318695689.232:3562):
arch=c000003e syscall=54 success=yes exit=0
a0=3 a1=107 a2=1 a3=7fffc25fdb90
items=0 ppid=25014 pid=25980 auid=10000 uid=0
gid=0 euid=0 suid=0 fsuid=0 egid=0 s
gid=0 fsgid=0 tty=pts0 ses=500 comm="tcpdump"
exe="/usr/sbin/tcpdump" subj=user_u:system_r:unconfined_t:s0 key=(null) Figura 1.2.2: Esempio di log di sistema operativo linux 22 CAPITOLO 1. LA GESTIONE DEI LOG DI SICUREZZA 192.168.1.1 192.168.1.24 - - [07/Oct/2011:14:53:16 +0200]
"GET /wpad.dat
HTTP/1.1" 404 1027 "-" "-" 192.168.1.100 - - - [07/Oct/2011:15:01:52 +0200]
"GET /squidlog/usage_201109.html HTTP/1.1" 200 105266 "-"
"Mozilla/5.0 (Windows NT 6.1; rv:7.0.1)
Gecko/20100101 Firefox/7.0.1" 192.168.1.100 - - - [07/Oct/2011:15:01:52 +0200]
"GET /squidlog/ctry_usage_201109.png HTTP/1.1"
200 2478 "http://prx01/squidlog/usage_201109.html"
"Mozilla/5.0 (Windows NT 6.1; rv:7.0.1)
Gecko/20100101 Firefox/7.0.1" 192.168.1.100 - - - [07/Oct/2011:15:01:52 +0200]
"GET /squidlog/hourly_usage_201109.png HTTP/1.1"
200 2103 "http://prx01/squidlog/usage_201109.html"
"Mozilla/5.0 (Windows NT 6.1; rv:7.0.1)
Gecko/20100101 Firefox/7.0.1" 1192.168.1.100 - - - [07/Oct/2011:15:01:52 +0200]
"GET /favicon.ico HTTP/1.1" 404 1008 "-"
"Mozilla/5.0 (Windows NT 6.1; rv:7.0.1)
Gecko/20100101 Firefox/7.0.1" 192.168.1.100 - - - [07/Oct/2011:15:02:52 +0200]
"GET /calamaris/ HTTP/1.1" 200 481 "-"
"Mozilla/5.0 (Windows NT 6.1; rv:7.0.1)
Gecko/20100101 Firefox/7.0.1" 192.168.1.100 - - - [07/Oct/2011:15:02:56 +0200]
"GET /calamaris/weekly.html HTTP/1.1" 200 214903
"http://prx01/calamaris/"
"Mozilla/5.0 (Windows NT 6.1; rv:7.0.1)
Gecko/20100101 Firefox/7.0.1" 192.168.1.1 192.168.1.30 - - [07/Oct/2011:15:05:58 +0200] "GET /wpad.dat HTTP/1.1" 404 1027 "-" "-" Figura 1.2.3: Esempio di log di un web server apache 23 CAPITOLO 1. LA GESTIONE DEI LOG DI SICUREZZA 24 Capitolo 2 Architettura di un SIEM Sebbene non esista uno standard che definisca lâ''architettura di un SIEM, Ã¨ tuttavia possibile descrivere i moduli di cui solitamente si compone e le loro interazioni (vedi figura 2.0.1). Possiamo distinguere cinque moduli: generazione di eventi, collezionamento di eventi, registrazione e immagazzinamento, analisi, monitoraggio e reporting. Nel seguito del capitolo approfondiremo le funzioni di ognuno di questi mo- duli, unitamente ad una discussione sulle problematiche da affrontare e le pos- sibili soluzioni. Verranno anche discusse le modalitÃ di integrazione fra i diversi moduli. 2.1 Generazione La generazione degli eventi avviene allâ''interno dei sistemi e delle applicazioni di cui si vogliono raccogliere i log da far pervenire al SIEM. Ad una prima analisi questo modulo sembrerebbe non fare parte del SIEM, tuttavia, conside- rando il SIEM come un processo piuttosto che come un sistema da acquistare ed installare, anche questo modulo rientra a tutti gli effetti nel SIEM. Possono essere considerate due diverse famiglie di eventi generati. I generato- ri di dati basati su eventi (sensori), generano eventi corrispondenti a specifiche operazioni svolte da sistemi operativi, applicazioni, dispositivi di sicurezza e cosÃ¬ via sulla rete. I generatori di dati basati sullo stato (poller), generano even- ti basati sulla reazione a stimoli esterni, come un ping, dati relativi a check di integritÃ o demoni che hanno il compito di verificare lo stato di un certo servizio. â'¢ Sensori. Sebbene nellâ''ambito della sicurezza informatica il tipo piÃ¹ noto di sensori siano gli IDS, sia network based che host based, si possono far rientrare in questa categoria la maggior parte delle tipologie di log di sicurezza elencati alla sezione 1.2, come i log di firewall, VPN, sistemi di autenticazione, i log di sistemi operativi e applicazioni, ecc. 25 CAPITOLO 2. ARCHITETTURA DI UN SIEM Figura 2.0.1: Macro architettura di un SIEM â'¢ Poller. Lo scopo dei poller Ã¨ quello di generare un evento ogni qualvolta un sistema terzo raggiunga un determinato stato. In un ambito di sicu- rezza, i poller sono responsabili della verifica dello stato di servizi (per rilevare la presenza di DOS) e la verifica dellâ''integritÃ . 2.2 Collezionamento Lo scopo di questo modulo Ã¨ quello di raccogliere informazioni dai diversi sensori e poller e tradurle in un formato standard, in modo da avere una base omogenea di messaggi. Al di lÃ dei diversi meccanismi di collezionamento utilizzati dai SIEM, esi- stono fondamentalmente due metodi di collezionamento. Si parla di metodo basato su agenti (agent-based) quando il collezionamento avviene attraverso un agente software del SIEM installato sul sistema sorgente, di metodo senza agen- 26 CAPITOLO 2. ARCHITETTURA DI UN SIEM ti (agentless), quando il collezionamento avviene senza nessun tipo di agente installato su di esso. â'¢ Agentless. Il server SIEM riceve i log dai sistemi sorgenti senza bisogno di installare su di essi nessun software particolare. Alcuni SIEM hanno la possibilitÃ di iniziare la connessione con il sistema sorgente, utilizzando opportuni meccanismi di autenticazione, e andare a reperire ad intervalli regolari i log presenti, per esempio disponibili in un database o in un file di testo; si parla in tal caso di metodo pull. In altri casi i sistemi sorgente inviano loro stessi i log al SIEM, dove Ã¨ presente un opportuno receiver: in tal caso si parla di metodo push. Esempio di questo tipo di metodo Ã¨ il syslog. â'¢ Agent based. Un agente software Ã¨ installato sui sistemi che generano i log, allo scopo di effettuare filtraggio, aggregazione e normalizzazione per un certo tipo di log, trasmettendo poi i dati dei log normalizzati, normal- mente in real-time o quasi in real-time, per lâ''analisi e lâ''immagazzinamento. Se un sistema ha diverse tipologie di log di interesse, Ã¨ necessario installare piÃ¹ agenti. In ognuna delle precedenti tipologie di collezionamento sono presenti vantaggi e svantaggi. Il vantaggio principale dellâ''approccio agentless Ã¨ che non occorre installare, configurare e mantenere agenti in ogni sorgente di log. Lo svan- taggio principale sta invece nel fatto che non Ã¨ possibile effettuare filtraggio, aggregazione e normalizzazione a livello di sistema sorgente. Un altro possibi- le svantaggio Ã¨ nella necessitÃ di dotare il SIEM di credenziali valide per ogni sistema sorgente. Normalmente i SIEM hanno metodi predefiniti per il collezionamento, il filtraggio, lâ''aggregazione e la normalizzazione di log di particolari sistemi o ap- plicazioni (per esempio, server web, database relazionali, mail server, ecc.). In tali casi il SIEM sa come interpretare i vari campi presenti nel log originario (per esempio il campo numero 12 rappresenta lâ''IP sorgente) o determinati valo- ri presenti nel log originario (per esempio lâ''evento con codice 680 in un sistema Windows rappresenta unâ''autenticazione fallita). Per sistemi o applicazioni che non dispongono di metodi predefiniti i SIEM forniscono normalmente strumenti che permettono di costruirsi i propri meto- di, rendendo il SIEM molto piÃ¹ flessibile. Naturalmente per costruire il pro- prio metodo di collezionamento Ã¨ indispensabile conoscere il formato dei log da collezionare e dei campi disponibili allâ''interno del SIEM. Scopo del modulo di collezionamento Ã¨ anche quello di operare una norma- lizzazione dei log. Con normalizzazione si intende il processo che permette di trasformare i log raccolti dai diversi sistemi sorgenti nei loro formati nativi in un unico formato che sia utilizzabile allâ''interno del SIEM. Come esempio, supponiamo di avere due eventi provenienti da sistemi diversi, un server Windows Server 2003 (fig. 2.2.1) e un server Linux (fig. 2.2.2) e che entambi gli eventi rappresentino un tentativo fallito di login. 27 CAPITOLO 2. ARCHITETTURA DI UN SIEM Figura 2.2.1: Evento di login fallito su Windows Oct 4 21:38:34 192.168.1.1 sshd[28061]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser=
rhost=localhost.localdomain user=root Oct 4 21:38:36 192.168.1.1 sshd[28059]: error: PAM: Authentication failure for root from localhost.localdomain Figura 2.2.2: Evento di login fallito su Linux 28 CAPITOLO 2. ARCHITETTURA DI UN SIEM Come si puÃ² vedere due diversi sistemi producono per un evento simile due log differenti. Un esempio di come potrebbero apparire i due eventi dopo il processo di normalizzazione Ã¨ riportato nella tabella 2.1 Time Device Ven- dor Device Type Event Type Address Host Name User Name Behavior 2011/10/04 21:34:10 CEST Microsoft Operating System Authentication 192.168.1.2 WinHost Administrator Failure 2011/10/04 21:38:36 CEST Unix Operating System Authentication 192.168.1.1 LinuxHost root Failure Tabella 2.1: Eventi normalizzati Altre operazioni che possono avvenire nellâ''ambito di questo modulo sono il filtraggio e lâ''aggregazione. Con filtraggio si intende la selezione, allâ''interno del sistema sorgente, dei log che hanno un certo interesse per la successiva registrazione e analisi e lâ''esclusione dei log privi di interesse. Con aggregazione si intende il consolidamento di piÃ¹ eventi simili in unâ''unica entry che abbia un campo contatore del numero di eventi. 2.3 Registrazione e immagazzinamento Per lavorare con lâ''elevato numero di log che arrivano al SIEM, occorre definire un sistema di memorizzazione che permetta di conservare i log per il periodo definito allo scopo di soddisfare i requisiti normativi e di effettuare analisi storiche. Nella scelta del meccanismo di memorizzazione occorre tenere presente la facilitÃ con cui Ã¨ possibile definire query per estrarre gli eventi di interesse e la rapiditÃ di risposta alle query definite. Esistono tipicamente tre metodi di memorizzazione dei log: in un database, in file di testo, in file binari. Il caso di memorizzazione in un database standard Ã¨ attualmente il piÃ¹ utilizzato, in quanto Ã¨ il sistema che permette solitamente il miglior compromesso fra la necessitÃ di utilizzare i log da parte di altre appli- cazioni, la necessitÃ di eseguire facilmente le analisi, e la necessitÃ di accedere a tali dati in maniera efficiente. I file di testo, pur permettendo lâ''accesso ai log da parte di altre applicazioni e di eseguire facilmente analisi, non permettono di ac- cedere in maniera efficiente ai dati, soprattutto in presenza di archivi contenenti grandi quantitÃ di log. Al contrario, i formati binari permettono di accedere in maniera efficiente ai dati, ma non permettono lâ''accesso ad altre applicazioni che non siano il SIEM stesso. Per garantire lâ''integritÃ dei dati memorizzati, alcuni SIEM calcolano un digest sul database dei log, o sui file che contengono i log, o su ogni record contenuto nel database. Un digest Ã¨ una firma che identifica univocamente 29 CAPITOLO 2. ARCHITETTURA DI UN SIEM i dati, con la caratteristica che cambiando un singolo bit del dato, il digest cambia. I principali algoritmi utilizzati per il calcolo del digest sono lâ''MD5 e lo SHA-1. In questa maniera, se per qualche motivo i log fossero alterati il digest cambierebbe e si avrebbe la prova dellâ''alterazione. Un altro meccanismo per garantire lâ''integritÃ puÃ² essere la conservazione dei log su dispositivi di sola lettura. Pur nella specificitÃ dei vari SIEM, per ognuno dei quali la tabella dei mes- saggi conterrÃ campi diversi, Ã¨ possibile individuare un insieme minimo di campi che generalmente, affinchÃ© il SIEM possa svolgere la sua funzione, fanno parte della tabella dei messaggi. â'¢ Time. Contiene il timestamp in cui Ã¨ avvenuto lâ''evento. PuÃ² essere affiancato da altri timestamp, per esempio il timestamp in cui Ã¨ avvenuto il parsing dellâ''evento. â'¢ Type. Contiene il tipo di sistema che ha generato lâ''evento, per esempio sistema operativo, database, firewall, ecc. â'¢ Category. Contiene la tipologia dellâ''evento, per esempio se si tratta di unâ''autenticazione, di unâ''autorizzazione, dellâ''avvio di unâ''applicazione, ecc. â'¢ Severity. Contiene il livello di pericolositÃ dellâ''evento.
â'¢ Device. Contiene il sistema che ha generato lâ''evento. PuÃ² essere diviso su piÃ¹ campi, contenenti per esempio lâ''indirizzo IP, lâ''hostname e il fully qualified hostname. â'¢ Source. Contiene il sistema da cui Ã¨ partito lâ''evento. Per esempio, in un login via rete, contiene un riferimento al sistema da cui lâ''utente ha fatto il login. Come per il device, anche in questo caso lâ''informazione puÃ² essere divisa su piÃ¹ campi. â'¢ Destination. Contiene il destinatario dellâ''evento. Per esempio, in un login via rete, contiene un riferimento al sistema su cui lâ''utente ha fatto il login. Come per il device e il source, anche in questo caso lâ''informazione puÃ² essere divisa su piÃ¹ campi. â'¢ User. Contiene, se esiste, lâ''account che ha generato lâ''evento. PuÃ² essere diviso in user sorgente e user destinazione per tenere conto del caso di eventi che contengano una sorgente e una destinazione. â'¢ Message. Contiene un testo che descrive lâ''evento. Oltre ai log, il SIEM si occuperÃ di registrare le statistiche e gli eventi di alert. 2.4 Analisi 2.4.1 Il Rule e il Correlation Engine Lo scopo dellâ''analisi Ã¨ quello di cercare eventuali anomalie allâ''interno dei log, per esempio per rilevare attacchi o tentativi di attacco. In un SIEM nel quale 30 CAPITOLO 2. ARCHITETTURA DI UN SIEM tutti i log con una qualche rilevanza dal punto di vista della sicurezza siano centralizzati e nel quale siano presenti strumenti che permettano di operare fa- cilmente delle ricerche per individuare eventi di interesse, tale analisi puÃ² essere operata da parte di analisti della sicurezza; questo tipo di approccio, tuttavia, Ã¨ utile soprattutto in fase investigativa. Per poter operare in maniera proattiva nei SIEM esiste normalmente un componente, il rule engine, che permette di generare allarmi da mostrare sulla console agli operatori del SOC, oppure da inviare via mail, in base al verificarsi di determinate condizioni. Generalmente le regole vengono scritte utilizzando una qualche forma di logica booleana. Supponiamo di voler generare un allarme ogni qualvolta un utente faccia login via rete su un server utilizzando credenziali amministrative locali e suppo- niamo che allâ''interno dellâ''organizzazione siano presenti server Windows e server Linux (vedi fig. 2.4.1). Normalmente dovremmo definire diversi trigger allâ''in- terno dei diversi sistemi, mentre in un SIEM, utilizzando la logica interna, Ã¨ possibile definire unâ''unica regola basata su diverse variabili che definisca un trigger. Figura 2.4.1: Regola per login amministrativo Uno strumento piÃ¹ sofisticato per generare allarmi Ã¨ rappresentato dal cor- relation engine , un sottoinsieme del rule engine che permette di correlare diversi eventi provenienti da diverse sorgenti creando un unico evento correlato. Tale correlazione viene operata allo scopo di semplificare lâ''identificazione di potenziali incidenti e le procedure di risposta. Supponiamo di voler rilevare un attacco di forza bruta andato a buon fine verso un server, costituito da una serie di tentativi di login falliti su tale server provenienti dallo stesso IP sorgente, seguito da un tentativo di login andato a buon fine, in un certo intevallo di tempo. Supponiamo di avere una situazione come quella presente in tabella 2.2. In una situazione reale la situazione Ã¨ molto piÃ¹ complicata, perchÃ¨ potrem- mo avere migliaia di eventi al secondo: chiaramente, in tale situazione, sarebbe 31 CAPITOLO 2. ARCHITETTURA DI UN SIEM Time Eventi ID Source Destination Message 2011/10/04 21:34:10 CEST 10087 192.168.1.2 10.10.10.25 Login failed 2011/10/04 21:34:10 CEST 10088 192.168.1.10 10.10.10.30 Login successfull 2011/10/04 21:34:10 CEST 10089 192.168.1.2 10.10.10.25 Login failed 2011/10/04 21:34:10 CEST 10090 192.168.1.11 10.10.10.31 Login failed 2011/10/04 21:34:10 CEST 10091 192.168.1.12 10.10.10.35 Login successfull 2011/10/04 21:34:10 CEST 10092 192.168.1.12 10.10.10.36 Login successfull 2011/10/04 21:34:10 CEST 10093 192.168.1.2 10.10.10.25 Login failed 2011/10/04 21:34:10 CEST 10094 192.168.1.13 10.10.10.100 Login failed 2011/10/04 21:34:10 CEST 10095 192.168.1.13 10.10.10.110 Login failed 2011/10/04 21:34:10 CEST 10096 192.168.1.2 10.10.10.25 Login successfull Tabella 2.2: Eventi standard in un SIEM molto difficile rilevare manualmente un attacco di forza bruta. Il correlation engine permette, utilizzando operatori di logica booleana, di definire una regola che permetta di correlare i diversi eventi in un singlolo evento, che possa genera- re un allarme. Un esempio di una possibile definizione che permetta di rilevare un attacco di forza bruta Ã¨ il seguente: I f [ ( f a i l e d l o g i n s >= 3) and then ( S u c c e s s f u l Login ) ] from the same source within 20 seconds = P o s s i b l e Brute Force Compromise 2.4.2 La Knowledge Base Di ausilio alla fase di analisi Ã¨ anche la componente di Knowledge Base, dove viene tenuta traccia del livello globale di sicurezza dellâ''infrastruttura IT. Que- sto permette di valutare se un tentativo di intrusione su un certo sistema puÃ² effettivamente portare ad unâ''intrusione e il livello di criticitÃ di tale tentativo di intrusione. Fanno parte della componente di knowledge base il database degli asset, il database delle vulnerabilitÃ e le policy di sicurezza dellâ''organizzazione. Il database degli asset puÃ² essere utilizzato per definire alcuni aspetti delle configurazioni dei sistemi, il tipo di servizio garantito allâ''interno del sistema informativo, gli altri sistemi al quale sono correlati, i referenti; in definitiva lo scopo Ã¨ quello di determinare il livello di criticitÃ dei sistemi e lâ''impatto che puÃ² avere unâ''eventuale intrusione. Il database delle vulnerabilitÃ contiene informazioni relative alle violazioni della sicurezza e ai comportamenti insicuri che possono avere impatto sul livello globale di sicurezza o che possono essere utilizzate da un attaccante allo scopo di effettuare unâ''intrusione. Il database delle vulnerabilitÃ puÃ² contenere i seguenti tipi di vulnerabilitÃ : 32 CAPITOLO 2. ARCHITETTURA DI UN SIEM â'¢ vulnerabilitÃ strutturali, ovvero vulnerabilitÃ presenti in software specifici, per esempio buffer overflow; questa parte del database puÃ² essere popolata attraverso report di software di vulnerability scanner; â'¢ vulnerabilitÃ funzionali, ovvero vulnerabilitÃ che dipendono da configura- zioni, comportamenti degli utenti, ecc. Un esempio di questo tipo Ã¨ la presenza di un server nfs che espone delle share non adeguatamente pro- tette di cui un eventuale malintenzionato puÃ² fare il mount, accedendo cosÃ¬ al filesystem. Contrariamente alle vulnerabilitÃ del tipo precedente, queste vulnerabilitÃ dipendono fortemente dallâ''ambiente in cui risiedono. La parte piÃ¹ difficoltosa Ã¨ trovare il modo per definire / formattare questo tipo di vulnerabilitÃ in maniera tale da popolare il database; â'¢ vulnerabilitÃ basate sulla topologia di rete, incluso lâ''impatto delle intru- sioni sulla rete e le loro conseguenze. Questa parte del database include le vulnerabilitÃ di rete (sniffing, spoofing, ecc.) cosÃ¬ come lâ''impatto del filtraggio sui path di intrusione. Questo tipo di vulnerabilitÃ non posso- no essere contenute in un database, a meno che questo non supporti un minimo di modellazione topologica. Gli aspetti principali delle policy di sicurezza che devono essere considerati sono le autorizzazioni e le procedure di testing /auditing. Questi due aspetti forni- ranno informazioni riguardanti i comportamenti che i sensori dovranno rilevare. Gli eventi generati (login amministrativi, portscan, ecc.) potranno essere mar- cati come conformi alle policy di sicurezza oppure come parte di un possibile tentativo di intrusione. Lâ''obiettivo finale della knowledge base Ã¨ quella di valutare lo stato di sicu- rezza dei sistemi monitorati. Le informazioni contenute nella knowledge base possono essere processate da un apposito engine, che fornirÃ una lista delle vulnerabilitÃ a cui ogni sistema Ã¨ soggetto, il potenziale impatto di ogni vulne- rabilitÃ e i path di intrusione che possono sfruttare tali vulnerabilitÃ . Tale valu- tazione andrÃ rigenerata ogni qualvolta venga trovata una nuova vulnerabilitÃ e ogni qualvolta ci siano modifiche ai sistemi monitorati. 2.5 Monitoraggio Il monitoraggio Ã¨ il modo con cui gli operatori del SOC e gli analisti della sicurezza interagiscono con il log registrati nel SIEM. Generalmente i SIEM hanno una console, che puÃ² essere web-based o client- server, che permette di interagire con i dati registrati sul SIEM. In generale sono presenti tre interfacce: â'¢ interfaccia per il monitoraggio real-time: fornisce una visione real-time degli eventi che arrivano al SIEM, permettendo un filtraggio base allo scopo di isolare i messaggi di interesse. Viene usata per scopi di debugging, per analisi approfondite di eventi specifici e per la reazione ad eventi; 33 CAPITOLO 2. ARCHITETTURA DI UN SIEM â'¢ interfaccia per la gestione degli incidenti: Ã¨ lâ''engine utilizzato per la crea- zione e la gestione di ticket di incidente e le procedure di reazione e risoluzione; â'¢ interfaccia per le analisi statistiche: fornisce dati sulle statistiche di atti- vitÃ di sicurezza sul corto, medio e lungo periodo. Oltre alla console, i SIEM hanno generalmente strumenti meno operativi, a disposizione dei responsabili della sicurezza e del management aziendale. In generale sono presenti le seguenti interfacce: â'¢ interfaccia per la valutazione dei rischi: fornisce informazioni sullâ''attuale livello di sicurezza delle configurazioni dei sistemi monitorati e dei soft- ware installati. Fornisce informazioni sul livello di sicurezza globale, sulle vulnerabilitÃ e le criticitÃ , gli scenari di intrusioni e i dettagli sulle patch e le configurazioni; â'¢ attivitÃ di sicurezza: fornisce reportistiche a medio e lungo termine sulle intrusioni verificatisi, tipi, frequenze, sorgenti e conseguenze sui sistemi monitorati. Ã' usato per determinare trend, attacchi ricorrenti e sistemi maggiormente colpiti; â'¢ stato dei sistemi: fornisce un quadro sugli incidenti aperti, sistemi sotto attacco e path di intrusione attivati dagli attaccanti. Fornisce informa- zioni sulle procedure di reazione ed escalation messe in atto allo scopo di circoscrivere lâ''attacco. Nella figura 2.5.1, alla luce di quanto detto in questo capitolo, Ã¨ schema- tizzata unâ''architettura piÃ¹ di dettaglio di un SIEM. Sono presenti i moduli descritti allâ''interno del capitolo e per ognuno di essi i componenti descritti. Ã' stato inoltre schematizzato il flusso delle informazioni e le interazioni fra i vari moduli. 34 CAPITOLO 2. ARCHITETTURA DI UN SIEM Figura 2.5.1: Architettura di dettaglio di un SIEM 35 CAPITOLO 2. ARCHITETTURA DI UN SIEM 36 Capitolo 3 ArcSight ESM Al fine di realizzare quanto esposto nel capitolo precedente, i principali ven- dor hanno sviluppato soluzioni di System Information and Event Management complete, che integrano tutte le componenti dellâ''architettura. Sul mercato sono presenti moltissimi prodotti con caratteristiche simili, come ad esempio: Q1 Labs QRadar, Cisco Security Mars, RSA Envision. In questo capitolo verranno illustrate lâ''architettura e le caratteristiche di Arcsight Enterprise Security Manager (ESM), il prodotto utilizzato presso la Regione Emilia-Romagna per la realizzazione del sistema di monitoraggio. 3.1 Architettura di Arcsight ESM Lâ''Arcsight ESM consiste di diversi componenti installabili separatamente che cooperano per processare i dati degli eventi della rete di unâ''organizzazione. Que- sti componenti si connettono alla rete attraverso sensori che nella terminologia ArcSight sono denominati ESM SmartConnector. Gli SmartConnector trasfor- mano una moltitudine di log di diversi sistemi in uno schema normalizzato che diventa il punto di partenza per le componenti di correlazione e analisi. La figura 3.1.1 illustra i componenti dellâ''ESM e i componenti opzionali che gestiscono il flusso e lâ''analisi degli eventi e permettono il monitoraggio della rete e la risposta agli incidenti. Tali componenti verranno illustrati nel corso del capitolo, man mano che intervengono allâ''interno della descrizione organizzata secondo il ciclo di vita degli eventi. 37 CAPITOLO 3. ARCSIGHT ESM Figura 3.1.1: Architettura dellâ''ESM Lâ''ESM processa gli eventi in varie fasi, allo scopo di identificare gli eventi di interesse e operare le rispettive contromisure. La figura 3.1.2 fornisce una panoramica delle fasi principali che costituiscono il ciclo di vita di un evento attraverso lâ''ESM. 38 CAPITOLO 3. ARCSIGHT ESM Figura 3.1.2: Ciclo di vita degli eventi nellâ''ESM Appare evedente che le fasi riportate nella figura coincidono con i moduli mostrati in figura 2.1 e descritti nel capitolo 2. Nel seguito del capitolo verranno illustrate le modalitÃ e le specificitÃ con cui lâ''ESM implementa tali moduli. 39 CAPITOLO 3. ARCSIGHT ESM 3.2 Collezionamento 3.2.1 I componenti La fase di collezionamento viene operata dagli SmartConnector, che possono essere installati sui sistemi sorgenti (modalitÃ agent), oppure su server dedicati o sulla Connector Appliance (modalitÃ agentless). SmartConnector Gli SmartConnector sono lâ''interfaccia con i sistemi sor- genti di eventi rilevanti sulla rete dellâ''organizzazione. Il loro scopo Ã¨ quello di collezionare eventi sulla rete. Gli eventi collezionati dagli SmartConnector sono normalizzati nel formato comune dellâ''ESM, descritto in seguito; gli eventi pos- sono inoltre essere filtrati e aggregati, cosÃ¬ da ridurre il volume inviato allâ''ESM Manager e migliorare lâ''efficienza e lâ''accuratezza. Gli SmartConnector inoltre categorizzare gli eventi usando un formato fa- cilmente leggibile e interpretabile e in modo indipendente dal sistema sorgente, sul quale poter facilmente costruire filtri, regole, report e monitoraggio nelle fasi successive. Gli SmartConnector si occupano infine di trasmettere gli eventi allâ''ESM Manager. Connector Appliance La Connector Appliance Ã¨ una soluzione hardware che permette di ospitare tutti gli SmartConnector necessari in unâ''unico device, che contiene anche unâ''interfaccia utente di management per gli SmartConnec- tor contenuti nellâ''appliance stessa, in server remoti dedicati, oppure installati sui sistemi sorgenti dei log, permettendo operazioni massive su tutti i tipi di connettori. FlexConnector ArcSight fornisce SmartConnector configurati per i sistemi sorgenti piÃ¹ diffusi, come sistemi di intrusion prevention and detection, tool di vulnerability assessment, firewall, antivirus e antispam, sistemi operativi, web server, application server, database server, apparati di rete e cosÃ¬ via. Per poter integrare allâ''interno del SIEM anche i log di sistemi non diretta- mente supportati dagli SmartConnector, Arcsight fornisce anche il FlexConnec- tor, un software development kit (SDK) che permette la creazione di SmartCon- nector basati su qualsiasi sorgente di log. Vengono forniti metodi per il parsing di file di testo basati su regular expression, di file di testo di tipo CSV, di tabelle di database basate su timestamp o su id. 3.2.2 I processi Nella figura 3.2.1 sono schematizzati i processi relativi alla fase di colleziona- mento svolta dagli SmartConnector. I connettori normalizzano i dati nello sche- ma dellâ''ESM, categorizzano gli eventi e operano filtraggio e aggregazione degli eventi per ridurre il loro volume. 40 CAPITOLO 3. ARCSIGHT ESM Figura 3.2.1: Collezionamento Collezionamento e normalizzazione Il modo in cui log dei sistemi sorgenti raggiungono i connettori dipende dal tipo di sorgente; in tali casi ciÃ² puÃ² avve- nire direttamente, in altri attraverso dei concentratori (es. syslog), in alcuni casi Ã¨ il connettore che si connette al sistema sorgente, in altri Ã¨ il sistema sorgente che invia i log attraverso stream di rete. La normalizzazione, come detto al paragrafo 2.2, permette, a partire da ambiente e dati non eterogenei, di estrarre informazioni omogenee e inserirle nello schema utilizzato dallâ''ESM. Durante il processo di normalizzazione, in base al livello di pericolo rappresentato dallâ''evento, assegna un valore allâ''attributo
Agent Severity contenuto nello schema dellâ''ESM, che puÃ² assumere i valory Very Low , Low, Medium, High e Very High, oppure Unknown se il connettore non Ã¨ in grado di assegnare alcun valore. Tale attributo viene utilizzato in fase di analisi per valutare la prioritÃ di un evento. Categorizzazione In un sistema che raccoglie eventi provenienti dalle ca- tegorie piÃ¹ disparate di device, Ã¨ opportuno che sia presente un modello per descrivere le caratteristiche di ogni evento che viene processato, in modo che sia molto semplice comprendere il significato reale di un evento come riportato da device differenti. Questa modello aiuta, nella fase di analisi e correlazione, a scrivere regole e filtri indipendenti dal sistema che li ha generati. Lâ''ESM for- nisce un modello per descrivere gli eventi e lo SmartConnector assegna valori opportuni, secondo quanto stabilito in fase di configurazione del connettore. Le categorie di eventi sono una serie di sei criteri che traducono il significato di un evento nel formato dellâ''ESM. Tali sei criteri sono centrali nella fase di analisi. Lâ''elenco delle categorie di eventi Ã¨ contenuto nella tabella 3.1 41 CAPITOLO 3. ARCSIGHT ESM Tabella 3.1: Categorizzazione degli eventi nello schema ESM Categoria Descrizione Esempi Object Si riferisce al tipo di oggetto che ha generato lâ''evento Application Operating
System Resource Router User Behavior Si riferisce a cosa viene fatto con lâ''oggetto che ha generato lâ''evento Access Authentication Authorization Execute Modify Outcome Descrive se lâ''operazione descritta in Behavior ha avuto successo. PuÃ² contenere Attempt, Failure o Success. Attempt indica che lâ''esito dellâ''azione non Ã¨ chiaro. Attempt Failure Success Technique Descrive la natura del behavior che lâ''evento rappresenta. Se lâ''evento Ã¨ considerato un attacco, identifica il metodo di attacco. Exploit Brute force Code execution Scan Denial of service Device Group Molti dispositivi di sicurezza hanno diversi scopi.
Per esempio, un IPS genera eventi di tipo firewall
cosÃ¬ come eventi di tipo Intrusion Detection. Il Device Group indica se un evento Ã¨ di un tipo o di un altro, informazione che puÃ² essere utilizzata per effettuare query. Assessment tool Security info
manager Firewall IDS Identity
Management Operating
System Network
equipment VPN Significance Indica il rischio di sicurezza relativa di un evento
basato su vari elementi, incluse le informazioni dal
device stesso, le informazioni inserite in fase di
modellazione degli asset e i dati da altre categorie di
eventi. I valori inseriti in questa categoria possono essere utilizzati dallo staff del Security Operation Center e dagli analisti di sicurezza per assegnare una prioritÃ agli eventi. Normal Informational Reconnaissance Suspicious Hostile Compromise Filtraggio e aggregazione Le fasi di filtraggio e aggregazione, descritte nel paragrafo 2.2, nellâ''ESM sono svolte ancora dallo SmartConnector. Lâ''aggregazione permette di condensare in un unico evento aggregato piÃ¹ eventi che hanno lo stesso valore in uno specifico insieme di campi, per un numero di volte specificato oppure per un intervallo di tempo specificato. Lâ''evento 42 CAPITOLO 3. ARCSIGHT ESM aggregato contiene i valori che gli eventi base hanno in comune, piÃ¹ il timestamp dellâ''evento iniziale e quello dellâ''evento finale. Il campo count contiene il numero di eventi aggregati. 3.3 Registrazione Lâ''ArcSight ESM utilizza, per la registrazione degli eventi, un database Oracle. In tale database sono memorizzati, oltre agli eventi, anche le configurazioni di sistema e le regole definite dagli utenti. 3.3.1 I componenti ESM Database Quando lo stream degli eventi arriva allâ''ESM dagli Smart- connectors, vengono scritti allâ''interno del Database con uno schema normalizza- to. Questo abilita lâ''ESM ad effettuare analisi a posteriori sugli eventi provenienti dai sistemi sottoposti a monitoraggio. Unâ''installazione tipica mantiene i dati on line per un periodo di tempo variabile fra alcune settimane e alcuni mesi. SmartStorage Partition Management Le SmartStorage Partition sono pozioni di database che possono essere compresse e archiviate (quindi poste off line) per essere utilizzate successivamente in caso di necessitÃ . ArcSight Logger Lâ''Arcsight Logger Ã¨ unâ''appliance ottimizzata per la memo- rizzazione di grandi quantitÃ di eventi. Il Logger mantiene gli eventi in maniera compressa e inalterabile, allo scopo di poterli estrarre in caso di necessitÃ in caso di analisi forensi. 3.3.2 Lo schema degli eventi Lo schema degli eventi Ã¨ il culmine del processo di normalizzazione, e la base della struttura dati che guida la correlazione dellâ''ESM. I 400 campi dati nello schema sono divisi in 17 gruppi, come mostrato nella tabella 3.2. Tabella 3.2: Gruppo di eventi Gruppo
eventi Descrizione Event(root) Contiene informazioni generali sugli eventi che lâ''ESM usa per identificare e tracciare Category Contiene una descrizione della categoria dellâ''evento applicata dallo SmartConnector che lâ''ha ricevuto. Le categorie sono descritte nella tabella 3.1 43 CAPITOLO 3. ARCSIGHT ESM Gruppo
eventi Descrizione Threat Descrive la valutazione da parte dellâ''ESM di quale sia lâ''importanza dellâ''evento. Agent Descrive lo SmartConnector che ha riportato lâ''evento nel manager. In unâ''architettura multi-manager, Agent Ã¨ lo SmartConnector che ha invito lâ''evento al manager. In questo caso Agent puÃ² essere lâ''ultimo in una lunga fila di SmartConnector che hanno fatto il forward dellâ''evento in una geriarchia multi-manager. Gli altri campi convolti in una catena di device sono Device, Final Device, Agent e Original Agent. Device Descrive le caratteristiche del sensore che che riporta lâ''evento allo
SmartConnector. Per esempio, se un host ospita un syslog, un HIDS e un
web server, i campi in questo gruppo descrivono quale sensore in
quellâ''host ha generato lâ''evento.
Questi campi includono anche i valori ascritti allâ''evento dal sensore
originale, come la severity, che indica la valutazione del livello di
minaccia dellâ''evento da parte del sensore. In un ambiente che usa concentratori questi campi descrivono la prima device della catena che ha processato lâ''evento. Lâ''ultima device della catena Ã¨ chiamata Final Device. Source Descrive lâ''asset che Ã¨ lâ''origine del traffico di rete rappresentato
dallâ''evento. In un evento che rappresenta unâ''interazione tra due asset,
Source Ã¨ in coppia con Destination, e insieme, questi campi descrivono il
mittente e il ricevente del traffico di rete. Nel caso di un evento che coinvolge solo un asset i campi Source saranno vuoti. Destination Descrive lâ''asse che Ã¨ il ricevente del traffico di rete rappresentato
dallâ''evento. In un evento che rappresenta unâ''interazione tra due asset,
Destination Ã¨ in coppia con Source, e insieme questi campi descrivono il
mittente e il ricevente del traffico di rete. Nel caso di un evento che coinvolge un solo asset i campi Destination descrivono tale asset. Attacker Descrive lâ''asset che ha iniziato lâ''azione rappresentata dallâ''evento.
Nel caso di un evento che rappresenta unâ''interazione tra due asset,
Attacker Ã¨ in coppia con Target, che Ã¨ il punto focale del traffico di rete.
Nella maggior parte dei casi, Attacker Ã¨ associato con Source, ma in caso
di un attacco che causa la divulgazione di informazioni che non
dovrebbero andare allâ''esterno, un sensore, come un IDS, potrebbe
intercettare una risposta che indica come il Destination abbia attaccato
il Source. Nel caso di un evento che coinvolge solo un asset, i campi Attacker saranno vuoti. Target Descrive lâ''asset che rappresenta il punto focale dellâ''azione rappresentata
dallâ''evento.
Nel caso di un evento che rappresenta unâ''interazione tra due asset,
Target Ã¨ in coppia con Attacker, che Ã¨ lâ''entitÃ che ha iniziato lâ''attacco. Nel caso di un evento che coinvolge solo un asset, i campi Attacker descrivono il nodo in cui lâ''azione ha avuto luogo. 44 CAPITOLO 3. ARCSIGHT ESM Gruppo
eventi Descrizione File Si riferisce allo stato corrente di un file in un sistema operativo o di una
risorsa ESM che Ã¨ stata modificata. Questi campi possono essere monitorati nel caso si sia alla ricerca di modifiche su risorse ESM di tipo file e puÃ² essere popolato da software di monitoraggio, come Tripwire. Old File Si riferisce allo stato precedente di un file in un sistema operativo o di
una risorsa ESM che Ã¨ stata modificata. Questi campi possono essere monitorati nel caso si sia alla ricerca di modifiche su risorse ESM di tipo file e puÃ² essere popolato da software di monitoraggio, come Tripwire. Request Descrive gli attributi di una richiesta per alcune azioni, come una HTTP GET oppure una query su un database. Original Agent In un ambiente multi-Manager, descrive lo SmartConnector che inizialmente ha ricevuto lâ''evento. Ã' il primo SmartConnector in una catena di SmartConnector che inoltra lâ''evento in una gerarchia di piÃ¹ Manager. Final Device Descrive lâ''ultimo device che ha processato lâ''evento prima di essere trasmesso ad uno SmartConnector. Final device entra in gioco solo in un ambiente nel quale un concentratore o un motore di analisi crea una catena di device. Event Annotation Contiene ogni assegnazione fatta nellâ''ambito della gestione di un workflow. Device Custom I campi appartenenti a questo gruppo sono riservati per attributi
specifici del device che ha generato lâ''evento, non catturati dal resto dello
schema. Questi campi sono definiti dallâ''autore dello SmartConnector. Ogni campo contiene una coppia etichetta/valore. Se i campi Device Custom vengono utilizzati in filtri, regole o data monitor, occorre includere sempre sia lâ''etichetta che il valore. Flex Nel caso lo schema ESM non catturi tutti i dati da monitorare di un
certo device e non ci sia uno SmartConnector personalizzato, Ã¨ possibile
configurare i campi Flex nello schema dello SmartConnector per
riportare questi dati.
Per esempio, potrebbe essere necessario estendere un FlexConnector per
catturare maggiori informazioni, o popolare questi campi in eventi
correlati quando viene innescata una regola. Questi campi sono
configurabili allâ''interno del setup di uno SmartConnector. Se i campi del gruppo Flex sono definiti, ogni campo contiene una coppia etichetta/valore. Se i campi Flex vengono utilizzati in filtri, regole o data monitor, occorre includere sempre sia lâ''etichetta che il valore. 3.4 Analisi 3.4.1 La correlazione La correlazione implementata dallâ''ESM permette di evidenziare la relazione tra eventi, inferire il significato di queste relazioni, assegnare una prioritÃ e fornire 45 CAPITOLO 3. ARCSIGHT ESM infine un framework per implementare una reazione. Il contesto della correlazio- ne Ã¨ fornito dal modello di rete (vedi sez. 3.4.2.2), la fase di messa in evidenza, lâ''inferenza e lâ''azione sono forniti dalle regole. La prioritÃ Ã¨ determinata dalla categorizzazione e dalla modellazione della rete. Figura 3.4.1: Il processo di correlazione 3.4.1.1 Rule Una regola dellâ''ESM Ã¨ una procedura programmata che valuta la presenza di condizioni specifiche e pattern allâ''interno degli eventi. Se viene trovata una corrispondenza, puÃ² essere intrapresa unâ''azione di risposta. Le regole sono la colonna portante del motore di correlazione ESM e sono la componente che rileva significati specifici allâ''interno del costante flusso di eventi. Vengono costruite usando aggregazioni e espressioni booleane per valutare oggetti come campi di eventi, modelli di rete e active lists. Le regole esprimono condizioni attraverso le quali il flusso di eventi viene valutato. Queste condizioni possono essere espresse a partire dal modello di rete e degli asset, della prioritÃ dellâ''evento, delle â''Active listâ' (3.4.1.3) e delle â''Session listâ' (3.4.1.3). Le regole possono essere costruite in maniera modulare per fare uso di blocchi di altre condizioni espresse attraverso filtri o altre regole. I filtri sono il mattone base utilizzato per costruire le regole; essi permettono, utilizzando strumenti della logica booleana, di definire criteri sugli attributi degli eventi: gli eventi che li soddisfano continueranno ad essere valutati allâ''interno delle regole, altrimenti verranno scartati. Simple rule Le â''simple ruleâ' vengono innescate quando gli eventi soddisfano una serie di condizioni, per esempio, eventi che hanno come target un certo asset e sono classificati come ostili. Se una â''simple ruleâ' Ã¨ configurata per aggregare eventi multipli che soddisfino una condizione su un attributo, la regola Ã¨ innescata quando piÃ¹ di un evento soddisfa la condizione. Per esempio, se la regola Ã¨ configurata per aggregare tre eventi, la regola Ã¨ attivata quando i tre eventi capitano allâ''interno dellâ''intervallo di tempo specificato. Join rule Il â''joinâ' permette di connettere eventi da differenti nodi allo scopo di verificare gli attributi che possono avere in comune. La â''Join ruleâ' riconosce 46 CAPITOLO 3. ARCSIGHT ESM pattern che coinvolgono piÃ¹ di un tipo di evento e viene innescata dagli eventi che soddisfano due o piÃ¹ set di condizioni. Per esempio, una join rule puÃ² essere innescata quando ad un evento sul sistema di intrusion detection corrisponde un evento permit sul firewall ed entrambi hanno come target lo stesso asset sulla stessa porta da parte dello stesso ip di provenienza. Se la join rule Ã¨ configurata per aggregare eventi multipli, la regola Ã¨ innescata quando il numero di eventi impostato soddisfa la condizione. Rule aggregation Ã' possibile avere lâ''innesco di unâ''azione ogni volta che le condizioni attraverso le quali Ã¨ definita la regola vengono soddisfatte. Ã' perÃ² anche possibile definire aggregazioni per innescare lâ''azione dopo un certo numero di volte che le condizioni vengono soddisfatte in un certo intervallo di tempo in cui certi campi sono unici o identici. Lâ''aggregazione puÃ² essere definita in base a: â'¢ numero di condizioni soddisfatte in un certo intervallo di tempo;
â'¢ aggregazione quando campi specifici sono unici;
â'¢ aggregazione quando campi specifici sono identici. 3.4.1.2 Azioni Alle regole Ã¨ sempre associata unâ''azione che viene eseguita quando le condizio- ni che definiscono la regola sono soddisfatte. Oltre a definire lâ''azione occorre definire quando lâ''azione viene scatenata. I criteri possibili sono i seguenti: â'¢ al primo evento;
â'¢ dopo un certo numero di eventi in un intervallo di tempo;
â'¢ ad ogni evento;
â'¢ al primo raggiungimento di una soglia;
â'¢ dopo un certo numero di volte che la soglia viene raggiunta;
â'¢ ogni volta che la soglia viene raggiunta;
â'¢ dopo un certo numero di minuti. Una volta deciso quando lâ''azione deve essere scatenata, occorre decidere quale Ã¨ lâ''azione. Alcune azioni possibili sono le seguenti: â'¢ invio di una notifica;
â'¢ esecuzione di un comando;
â'¢ creazione di un case allâ''interno dello strumento di ticketing Arcsight o aggiunta ad un case giÃ creato; â'¢ aggiunta o rimozione da unâ''active list;
â'¢ aggiunta o rimozione da una session list. 47 CAPITOLO 3. ARCSIGHT ESM 3.4.1.3 Liste Una lista Ã¨ una modalitÃ di monitoraggio degli asset. Una lista Ã¨ una locazione temporanea in memoria usata per contenere informazioni che possono essere usate in altre attivitÃ di correlazione o monitoraggio. Lâ''informazione Ã¨ aggiunta ad una lista basate su regole . Ã' possibile avere una lista di indirizzi IP sospetti, attivitÃ VPN, o altri tipi di valori specifici. Queste liste possono essere utilizzate per essere lette da altre regole, monitor, report. Possono essere utilizzate due tipi differenti di liste. Active list . Ã' possibile aggiungere informazioni a questo tipo di lista au- tomaticamente attraverso la definizione di regole oppure manualmente. Ogni lista ha un tempo di vita specifico (TTL) per i suoi asset. Il TTL Ã¨ lâ''ammon- tare di tempo che lâ''asset rimarrÃ nella lista. Gli asset nella Active List sono costantemente rivalutati e il TTL viene azzerato ogni qualvolta che viene sca- tenata lâ''azione di aggiunta dellâ''asset nellâ''active list. Se il TTL Ã¨ impostato a 0, lâ''informazione non viene mai rimossa dallâ''active list. Session list . Una session list Ã¨ definita per essere usata per un periodo di tempo specifico, non soltanto come segnaposto per informazioni su un campo, in cui lâ''informazione puÃ² scadere ed essere rimossa dalla lista. Le session list sono anche utilizzate per monitorare lâ''attivitÃ di sessione. 3.4.2 Knowledge base La componente di knowledge base in ArcSight ESM Ã¨ denominata ArcSight ESM network model. Questa componente aiuta nella costruzione di criteri di corre- lazione dettagliati cosÃ¬ come nellâ''assegnare una prioritÃ agli eventi processati dallâ''ESM. 3.4.2.1 ArcSight Asset Model Lâ''Asset Model Ã¨ il punto in cui vengono definiti i vari asset da monitorare allâ''interno dellâ''organizzazione. Al fine di ottenere il massimo dei benefici dalla modellazione degli asset, occorre fornire le seguenti informazioni, soprattutto per gli asset piÃ¹ critici. â'¢ VulnerabilitÃ . Come giÃ detto, una vulnerabilitÃ Ã¨ uno stato particolare o una debolezza di un sistema hardware o software che puÃ² essere sfrut- tata da un exploit. Spesso le vulnerabilitÃ allâ''interno delle organizzazioni possono essere rilevate attraverso dei tool di vulnerability scan. In questo caso Ã¨ possibile popolare il network model con i dati del vulnerabily scan utilizzando un apposito SmartConnector che comunica allâ''ESM Manager una serie di eventi. Quando il Manager riceve eventi da un vulnerability scanner, cerca innanzi tutto di individuare lâ''asset contenuto nel vulnera- bility scan allâ''interno degli asset giÃ modellati nel sistema. Se lâ''asset non viene trovato ne crea uno. Se lâ''organizzazione possiede un database degli asset nel quale siano presenti molti attributi, come per esempio lâ''owner- 48 CAPITOLO 3. ARCSIGHT ESM ship, Ã¨ possibile utilizzare lâ''attributo External ID per fare riferimento a tale database. â'¢ Location. Ã' una informazione opzionale che puÃ² fornire parecchi dettagli sullâ''origine e la destinazione di un evento. â'¢ Categoria di asset. Descrive le proprietÃ di un asset utili in fase di valutazione delle minacce o di reazione ad eventi. Sebbene questa opzione debba essere impostata e mantenuta manualmente, fornisce informazioni come la tipologia dellâ''asset, lâ''ownership, la criticitÃ , che possono essere utilizzate in fase di costruzione di filtri, regole e report per correlare gli eventi associati a questo asset. 3.4.2.2 ArcSight Network Model Il Network Model Ã¨ il punto in cui viene definita la modalitÃ in cui i gruppi di asset da monitorare sono rappresentati allâ''interno dellâ''organizzazione. Al fine di ottenere il massimo dei benefici dalla modellazione della rete, occorre fornire le seguenti informazioni. â'¢ Asset. Un asset Ã¨ definito come un endpoint di rete con un indirizzo IP, MAC address, host name o ID esterno. Ogni singola interfaccia di rete visibile Ã¨ considerata un asset distinto allâ''interno del Network Model. Mentre lâ''ESM crea automaticamente gli asset per modellare i nodi di rete che ospitano i componenti ArcSight (Database, Console, Manager, Con- nettori), Ã¨ importante creare in anticipo ogni asset importante. Questa informazione, in congiunzione con quelle contenute nellâ''Asset Model (vul- nerabilitÃ , location e categoria), sono importanti in fase di costruzione dei contenuti allâ''interno dellâ''ESM. Ã' possibile configurare gli Asset Group, gruppi logici di asset e gli Asset Range, gruppi di asset con lo stesso range di IP. â'¢ Zones. Possono rappresentare ogni parte della rete e sono identificate da un blocco di indirizzi IP contiguo. Le zone rappresentano solitamente un gruppo funzionale allâ''interno della rete e ogni asset o asset range deve essere associato ad una zona. â'¢ Networks. Sono una collezione logica di zone. Nel caso fossero presenti due o piÃ¹ subnet con NAT che usano lo stesso address space privato, si definirÃ una network. Le network devono essere associate a una zona; gli asset allâ''interno di tale zona saranno associati automaticamente alla network. La creazione del Network Model puÃ² avvenire con metodi diversi, alcuni dei quali basati sulla console ESM e altri basati sugli SmartConnector. I metodi basati sulla console ESM sono due. Esiste un primo metodo che permette di configurare individualmente gli asset ed un secondo metodo che permette invece di importare gli asset in modalitÃ batch basato su un file csv. 49 CAPITOLO 3. ARCSIGHT ESM Figura 3.5.1: Esempio di Active Channel I metodi basati su Smartconnector sono ancora due. Un primo metodo per- mette di definire un flex connector configurato per importare automaticamente le informazioni contenute allâ''interno di un file csv. Un secondo metodo permet- te di importare le informazioni sugli asset da un tool di vulnerability scanner (come FoundStone, ISS Internet Scanner o Nessus). Tutti i metodi elencati precedentemente permettono di integrare le infor- mazioni contenute nel network model di ESM con quelle importate dalle fonti esterne. 3.5 Monitoraggio I processi di normalizzazione e di correlazione permettono ai Security Opera- tione Center di avere consapevolezza in tempo reale degli eventi che occorrono allâ''interno della rete. I tool di monitoraggio e di investigazione permettono di tracciare una situazione durante la sua evoluzione, vedere lâ''origine di un evento, vedere i sistemi coinvolti e comprendere gli effetti sugli altri nodi di rete. I tool di monitoraggio che lâ''ESM mette a disposizione sono: â'¢ Active Channel â'¢ Dashboard â'¢ Query viewer 3.5.1 Active Channel Gli Active Channel sono uno strumento molto importante in fase di investiga- zione sugli incidenti e in fase di monitoraggio real-time. Allâ''interno di un Active Channel Ã¨ possibile visualizzare i dati che soddisfano un certo filtro in un certo intervallo di tempo definito o in tempo reale. Esempio di Active Channel Ã¨ riportato alla figura 3.5.1 In fase di creazione di un nuovo Active Channel sono richieste informazioni specifiche. â'¢ Nome del channel. Nome unico per lâ''Active Channel. 50 CAPITOLO 3. ARCSIGHT ESM â'¢ Timestamp di inizio e fine del monitoraggio. Intervallo di tempo da monitorare â'¢ Timestamp da utilizzare. Ã' possibile utilizzare il timestamp del dispositivo che ha generato i log oppure quello dellâ''ESM. â'¢ Valutare in caso di attacco o continuamente. Questa opzione permette di definire se lâ''Active Channel deve mostrare un intervallo di tempo specifico oppure mostrare gli eventi in real time. â'¢ Filtro da utilizzare. Il filtro utilizzato puÃ² essere un filtro creato preceden- temente oppure uno creato specificatamente per lâ''Active Channel. â'¢ Campi da utilizzare. Questa opzione permette di definire i campi da mostrare nellâ''Active Channel. 3.5.2 Dashboard Scopo delle Dashboard Ã¨ la visualizzazione di indicatori dello stato di sicurezza dellâ''organizzazione, cosÃ¬ come riportato allâ''ESM dalle sorgenti dei dati. Le dashboard sono formate da data monitor individuali in una varietÃ di formati grafici o tabellari che riassumo il flusso degli eventi e comunicano lâ''effetto del traffico di eventi su specifici sistemi della rete. Le dashboard forniscono diversi tipi di vusualizzazione e analisi del flusso di eventi: sono pertanto il mezzo ideale per visualizzare gli eventi della rete in una varietÃ di viste statistiche. Esempio di dashboard Ã¨ riportato alla fig. 3.5.2 Figura 3.5.2: Esempio di Dashboard 51 CAPITOLO 3. ARCSIGHT ESM 3.5.3 Query Viewer I Query Viewer combinano la capacitÃ di eseguire query SQL da parte dei trend e dei report con la capacitÃ di visualizzazione e drill-down degli active channel per creare grafici e tabelle interattive. I query viewer sono altamente persona- lizzabili e permettono di avere una vista a largo raggio e nello stesso tempo di accedere a dettagli in drill-down. I dati raccolti da un query viewer possono essere aggiunti ad una dashboard o pubblicati come report. I query viewer uti- lizzano query basate su eventi e altre risorse, come trend, active list, session list, asset, ecc. Sono lo strumento ideale per investigare situazioni potenzialmente sospette. 3.6 Reportistica e analisi degli incidenti Una volta che gli eventi sono stati processati dal Manager e memorizzati nel database, Ã¨ possibile eseguire una serie di operazioni batch che permettono di analizzare incidenti, trovare nuovi pattern e eseguire report sullâ''attivitÃ dei sistemi 3.6.1 Query Una Query Ã¨ una risorsa che permette di definire i parametri dei dati che si vuole ottenere da una sorgente dati. Il risultato di una query diventa la base per un o piÃ¹ report o trend. Le sorgenti dati che possono essere utilizzate per definire una query sono gli eventi contenuti nel database ESM, i dati contenuti in unâ''active list, session list o raccolti da un trend. Possono essere utilizzati dati interni allâ''ESM come per esempio gli asset. In una query Ã¨ possibile selezionare i campi dati da riportare e funzioni specifiche su di essi. 3.6.2 Trend Un Trend Ã¨ una risorsa che definisce come e con che frequenza valutare tendenze. Un trend Ã¨ costituito da una o piÃ¹ query eseguite con una certa frequenza. Un trend puÃ² essere utilizzato come fonte dati primaria per un report oppure puÃ² essere utilizzato come fonte dati per unâ''altra query che raffina i risultati della query iniziale. 3.6.3 Report Un report Ã¨ una risorsa che lega una o piÃ¹ fonti dati a un template e imposta gli attributi in output, come il formato del file, dimensioni della carta, limiti di righe e vincoli di time zone. Una volta che il report Ã¨ definito, Ã¨ possibile eseguirlo manualmente, ese- guirlo automaticamente ad intervalli regolari, o eseguire un report â''deltaâ' per confrontare i risultati di un report con un altro. 52 Parte II Un caso di studio: la Regione Emilia-Romagna 53 Capitolo 4 Gestione della sicurezza
informatica La Regione Emilia-Romagna mostra giÃ da tempo una spiccata sensibilitÃ al tema della sicurezza informatica, sensibilitÃ che si Ã¨ concretizzata sia sul piano organizzativo che su quello di assegnazione delle risorse, tanto da diventare punto di riferimento anche per altre pubbliche amministrazioni. Negli ultimi anni si Ã¨ operato principalmente in tre direzioni: 1. definizione di policy di sicurezza dellâ''ente, che hanno portato allâ''adozione di appositi Disciplinari Tecnici, ognuno dei quali tratta diversi aspetti ed Ã¨ rivolto a diverse tipologie di utenti; 2. strutturazione di un sistema di verifiche e controlli per la gestione della sicurezza nel suo complesso; 3. messa in opera di soluzioni tecnologiche al fine di assicurare e migliorare la sicurezza informatica, ottemperando anche agli obblighi previsti dalla normativa vigente. In questo capitolo descriveremo quanto realizzato dallâ''Ente in queste tre dire- zioni e quale sia lâ''impatto sul sistema di monitoraggio realizzato. 4.1 Le policy di sicurezza I principali standard internazionali che trattano la sicurezza informatica racco- mandano alle organizzazioni la definizione di linee guida e policy di sicurezza per il proprio sistema informativo. Le policy di sicurezza, che hanno il fine ultimo di proteggere le persone e le informazioni dellâ''organizzazione, definiscono le regole di comportamento per utenti, amministratori di sistema e management, autorizzando il personale addetto alla sicurezza informatica a monitorare i sistemi e fare indagini in caso di sospetti incidenti di sicurezza. 55 CAPITOLO 4. GESTIONE DELLA SICUREZZA INFORMATICA La Regione Emilia-Romagna nel corso degli ultimi anni ha provveduto alla definizione di policy di sicurezza per il sistema informativo dellâ''ente attraverso lâ''adozione di appositi Disciplinari Tecnici, ognuno dei quali tratta diversi aspetti ed Ã¨ rivolto a diverse tipologie di utenti. I Disciplinari Tecnici riguardanti la sicurezza informatica adottati finora sono i seguenti. â'¢ Disciplinare Tecnico per gli utenti del sistema informatico;
â'¢ Disciplinare Tecnico per amministratori di sistema;
â'¢ Disciplinare Tecnico in materia di sicurezza di applicazioni informatiche;
â'¢ Disciplinare Tecnico verifiche e controlli;
â'¢ Disciplinare Tecnico incidenti di sicurezza;
â'¢ Disciplinare Tecnico relativo al controllo degli accessi;
â'¢ Disciplinare Tecnico in materia di videosorveglianza. Uno degli scopi del sistema di monitoraggio oggetto di questa tesi Ã¨ la verifica delle policy di sicurezza regolamentate attraverso i Disciplinari Tecnici sopra elencati, soprattutto le policy riguardanti gli utenti del sistema informatico e gli amministratori di sistema. 4.2 Il sistema di verifiche Per garantire la sicurezza del proprio sistema informatico unâ''organizzazione, oltre a definire le regole di comportamento di utenti, amministratori di sistema e management, deve formalizzare un sistema di verifiche e controlli, autorizzando il personale addetto alla sicurezza ad effettuare il monitoraggio della sicurezza e a verificare il rispetto delle policy di sicurezza dellâ''organizzazione, delle normative e degli standard internazionali, individuare eventuali attacchi ed essere in grado di proporre eventuali modifiche o nuove implementazioni ai sistemi di sicurezza sulla base delle verifiche effettuate. La Regione Emilia-Romagna disciplina tale sistema allâ''interno del Discipli- nare Tecnico verifiche e controlli, adottato il 21 luglio 2009. Tale disciplinare prevede quattro tipi di verifiche: â'¢ puntuali preventive: attivitÃ di verifica effettuate precedentemente allâ''im- plementazione o alla modifica sostanziale di un sistema o di un processo per verificarne la rispondenza alle politiche di sicurezza; â'¢ puntuali a posteriori: attivitÃ di verifica effettuate a seguito del verificarsi di incidenti di sicurezza; â'¢ periodiche: attivitÃ di verifica, manuali o automatizzate, per contrastare minacce incombenti o potenziali, effettuate con cadenza periodica pro- grammata; 56 CAPITOLO 4. GESTIONE DELLA SICUREZZA INFORMATICA â'¢ a campione: attivitÃ di verifica effettuate su campioni scelti secondo criteri prestabiliti e ad intervalli di tempo non fissi. Il sistema di monitoraggio della sicurezza dovÃ fornire strumenti che permettano di effettuare tali verifiche, in particolare per le verifiche puntuali a posteriori e per le verifiche periodiche. 4.3 Le soluzioni tecnologiche Lâ''analisi dei rischi effettuata annualmente in occasione dellâ''aggiornamento del Documento Programmatico per la Sicurezza della Giunta Regionale, consente di monitorare e verificare le vulnerabilitÃ del sistema di sicurezza anche alla luce degli aggiornamenti normativi, tecnologici, procedurali e organizzativi, e di pia- nificare le necessarie contromisure. Le contromisure possono essere organizzative o tecnologiche. In questo paragrafo descriveremo brevemente alcune soluzioni tecnologiche di sicurezza adottate dalla Regione Emilia-Romagna; poichÃ© dal punto di vista del sistema di monitoraggio della sicurezza tali soluzioni tecnologiche rappresentano la fonte principale delle informazioni, la descrizione riguarderÃ soprattutto que- sto aspetto, descrivendo il tipo di informazione che si puÃ² ricavare dal sistema e i contenuti dei log. 4.3.1 Sistemi firewall Lâ''Ente Ã¨ dotato di un cluster di firewall statefull in tecnologia Checkpoint, si- tuato sulla frontiera esterna della rete regionali a protezione delle reti dei server, delle reti degli uffici e della DMZ. Oltre ai nodi che compongono il cluster Ã¨ pre- sente un server che funge da management (SmartCenter), fornendo unâ''interfac- cia per lâ''installazione delle policy, conservando il database delle configurazioni, ricevendo e conservando i log, in formato proprietario, provenienti dai nodi. 4.3.2 Sistemi anti malware Lâ''Ente Ã¨ dotato di diverse tipologie di sistemi anti malware, tutti di tecnologia Trend Micro. Su tutte le workstation e i server fisici Ã¨ installato Trend Micro Office Scan o Server Protect. Sui sistemi di virtualizzazione Ã¨ presente Trend Micro Deep Security, un sistema anti malware specifico per ambienti virtuali Vmware, il quale, utilizzando apposite API dedicate alla sicurezza fornite da Vmware, agisce come antimalware, come firewall e IPS per il traffico da e verso i server virtuali senza bisogno di installare alcunchÃ© sulle macchine virtuali. Per finire lâ''elenco del sistemi anti malware, citiamo Trend Micro Interscan Messaging Security Suite (IMSS), sistema anti malware dedicato alla posta elettronica e Trend Micro Interscan Web Security Virtual Appliance, sistema dedicato alla sicurezza della navigazione web. 57 CAPITOLO 4. GESTIONE DELLA SICUREZZA INFORMATICA 4.3.3 Sistemi di Intrusion Prevention e Intrusion Detec-
tion Il sistema di Intrusion Prevention e Intrusion Detection a disposizione dellâ''En- te, in tecnologia Tipping Point, Ã¨ costituito da alcune sonde posizionate sulla frontiera esterna della rete regionale e sulle frontiere fra le reti dei server e le reti degli uffici. Tali sonde ispezionano tutti i pacchetti del traffico di rete che le attraversa e, sulla base di apposite signature rilasciate dal produttore e co- stantemente aggionate e delle policy impostate dallâ''amministratore, bloccano o segnalano eventuali pacchetti che possono costituire minacce alla sicurezza. Ol- tre alle sonde il sistema di Intrusion Prevention e Intrusion Detection contiene un server che funge da managment e che fornisce unâ''interfaccia per lâ''instal- lazione delle policy, conservando il database delle configurazioni, ricevendo e conservando i log, in formato proprietario, provenienti dalle sonde. 4.3.4 Virtual Private Network Il sistema in dotazione per lâ''accesso remoto Ã¨ un sistema Checkpoint di VPN SSL, ovvero una VPN che utilizza il protocollo SSL (Secure Socket Layer) e che veicola il traffico di rete attraverso un tunnel utilizzato per garantire la protezio- ne delle comunicazioni. Le policy di accesso sono molto granulari, permettendo, per ogni utente, di definire applicazioni e/o combinazioni di host e protocolli utilizzabili. 4.3.5 Web Proxy Le postazioni di lavoro della rete regionale sono configurate in modo tale da per- mettere lâ''accesso al web solo attraverso un sistema di web proxying. Il sistema di web proxying ha lo scopo di rendere piÃ¹ efficiente la navigazione, mantenendo una cache locale delle pagine web e di rendere piÃ¹ sicura la navigazione, restrin- gendo lâ''accesso ad alcune risorse web in base a policy definite. Il sistema di web proxying regionale, utilizzabile solo previa autenticazione, Ã¨ costituito da un servizio di web cache open source (Squid), un sistema di content filtering pro- prietario (Trend Micro) basato sulla categorizzazione dei siti e un sistema open source di content filtering dinamico basato sullâ''analisi realtime dei siti visitati. 4.3.6 I sistemi di autenticazione 4.3.6.1 Il dominio Active Directory Il meccanismo primario per lâ''autenticazione degli utenti per lâ''accesso alle risorse utilizzato nellâ''Ente si basa su Microsoft Active Directory. Tale tipo di auten- ticazione (c.d. autenticazione di dominio), prevede lâ''identificazione dellâ''utente che accede ad una risorsa tramite userid e password. Sono presenti due domi- ni regionali, uno dedicato agli utenti interni alla rete regionale e un altro che comprende utenti esterni allâ''Ente che accedono ad applicazioni e servizi interni 58 CAPITOLO 4. GESTIONE DELLA SICUREZZA INFORMATICA allâ''Ente. Lâ''autenticazione di dominio Ã¨ impiegata per accedere alle postazioni di lavoro, al sistema di posta elettronica, alle cartelle di rete su file server. Gli eventi del sistema di autenticazione Active Directory sono registrati al- lâ''interno dellâ''Event Viewer dei Domain Controller dei rispettivi domini, dove viene registrato il timestamp dellâ''evento, il nome utente, la modalitÃ di auten- ticazione utilizzata, lâ''host di provenienza, lâ''host di destinazione, la modalitÃ di autenticazione (Kerberos, NTLMv2, ecc). I domain controller tengono inoltre traccia di tutte le modifiche apportate ad oggetti di Active Directory, come utenti, gruppi e computer. 4.3.6.2 Il sistema di Identity and Access Management La Regione Emilia-Romagna dispone di un sistema di Identity & Access Mana- gement (IAM). Il sistema di IAM Ã¨ finalizzato alla gestione razionale, scalabile ed omogenea delle utenze del Sistema Informativo della Regione ottemperan- do al tempo stesso alle normative ed ai requisiti di legge in tema di sicurezza informatica e di protezione dei dati personali. Il sistema di IAM Ã¨ composto dalle seguenti componenti:
â'¢ un servizio di Directory per la gestione centralizzata delle utenze interne ed esterne, sul quale poggiano le funzioni di â''profilaturaâ' e â''autenticazioneâ' di sistemi e applicazioni integrati nello IAM. Il Directory Ã¨ popolato tramite il sistema di Identity Management (vedi punto seguente), che si occupa anche di sincronizzare le password delle utenze allâ''interno del Directory con quelle dei domini Active Directory; â'¢ una soluzione di Identity Management, che, interfacciandosi a diversi re- pository utente, consente la gestione dellâ''intero ciclo di vita delle identitÃ su specifici sistemi e applicazioni, la sincronizzazione delle password degli utenti e la delega ai referenti alla gestione delle loro utenze; consente inol- tre lâ''automatizzazione del processo di provisioning degli account, integrato con i processi organizzativi mediante lâ''utilizzo di workflow; â'¢ una soluzione di Access Management che permette lâ''accesso in Single Sign On alle applicazioni web integrate, liberando le applicazioni stesse dalla gestione dellâ''autenticazione. Tramite il sistema di Identity e Access Management sono state gestite anche le utenze amministrative dei server Linux e dei server Windows che non fanno parte del dominio Active Directory, permettendo gli accessi degli amministratori con credenziali personali e permettendo lâ''accesso mediante account amministrativi generici (Administrator o root) solo da console e non via rete. Il sistema di Access Management Ã¨ inoltre integrato con il sistema di au- tenticazione federata della Regione Emilia-Romagna (fedERa), agendo sia come â''Identity Providerâ', permettendo ai proprio utenti di accedere con le proprie credenziali a servizi esposti da altri Enti del territorio regionale, che come â''Ser- vice Providerâ', permettendo ad utenti di altri Enti lâ''uso di applicazioni integrate con lâ''Access Manager. 59 CAPITOLO 4. GESTIONE DELLA SICUREZZA INFORMATICA 4.3.6.3 Il servizio RADIUS Allâ''interno del Sistema Informatico della Regione Emilia-Romagna Ã¨ inoltre pre- sente un sistema RADIUS che ha lo scopo di implementare un ulteriore metodo per lâ''autenticazione, autorizzazione e accounting per gli utenti che hanno neces- sitÃ di accedere a risorse eterogenee. Nello specifico il sistema RADIUS imple- mentato si basa su Cisco ACS ed Ã¨ configurato in modo da utilizzare gli utenti presenti allâ''interno del dominio Active Directory interno. Il servizio RADIUS Ã¨ utilizzato per lâ''accesso agli apparati di rete e per lâ''accesso ad alcune applian- ce. Tale configurazione permette di accedere con account personali evitando gli account generici con password condivise tra piÃ¹ utenti. 4.3.7 Il Configuration Management Database La Regione Emilia-Romagna dispone di un Configuration Management Databa- se (CMDB) contenente le informazioni piÃ¹ significative relative alle componenti del sistema informatico. Tale database costituisce di fatto il sistema informati- vo del sistema informatico dellâ''ente e contiene i dettagli dei configuration item (CI) della infrastruttura IT, intesi come gli asset costituenti lâ''intero ambito informatico, sia materiali (hardware) che immateriali (software). Il CMDB aiuta lâ''organizzazione nella comprensione delle relazioni tra le com- ponenti censite e la loro configurazione e rappresenta un componente fondamen- tale nei processi di change management. I dati contenuti in questo database sono strategici per il buon governo del- lâ''infrastruttura e, al fine di garantire un elevato livello qualitativo del sistema, Ã¨ fondamentale assicurare un costante aggiornamento delle informazioni in esso contenute. Tale obiettivo Ã¨ perseguibile attraverso regolari attivitÃ di allinea- mento dei dati. Il CMDB dellâ''Ente Ã¨ basato sul prodotto CMDBuild; si tratta di una applicazione web realizzata con Software Open Source, completamente configurabile per modellare ed amministrare il database degli asset informatici e supportarne i workflow di gestione. CMDBuild Ã¨ un sistema flessibile ed espan- dibile in modo graduale ed autonomo dallâ''utilizzatore, orientato allâ''utilizzo delle best practices di qualitÃ ITIL (IT Information Library) e rilasciato con licenza open source GPL. Attraverso il CMDB sono censiti la quasi totalitÃ degli asset materiali ed im- materiali gestiti dal Servizio Informativo Informatico Regionale, in particolare: â'¢ asset materiali: apparati di rete, server, rack; â'¢ asset immateriali: database e grant di accesso, applicazioni web e software installati sui server, amministratori di sistema. Ai fini della realizzazione del sistema di monitoraggio della sicurezza, Ã¨ impor- tante che le informazioni censite dal CMDB siano messe a disposizione del SIEM, sul quale potranno essere definite regole che tengano conto di tali informazioni. In tale maniera sarÃ per esempio possibile definire monitoraggi specifici per gli asset critici, altri per i web server, monitorare gli accessi degli amministratori 60 CAPITOLO 4. GESTIONE DELLA SICUREZZA INFORMATICA di sistema, accessi ai database da parte di utenti che non dovrebbero essere au- torizzati. Le modalitÃ di sincronizzazione delle informazioni riguardanti reti e asset fra il CMDB e il SIEM sono oggetto delle fasi di modellazione della rete e degli asset; nel paragrafo 5.3 verrÃ descritto come tali fasi sono state affrontate. 4.4 La gestione degli incidenti di sicurezza La gestione degli incidenti di sicurezza informatica Ã¨ un tema che tutte le or- ganizzazioni devono essere pronte ad affrontare in quanto, nonostante tutte le attivitÃ di prevenzione e di analisi dei rischi, non tutti gli incidenti possono essere prevenuti ed Ã¨ meglio affrontarli avendo una procedura definita. La pro- cedura deve avere lo scopo di permettere una rilevazione rapida dellâ''incidente, di minimizzare i danni e le perdite, mitigare le debolezze e ripristinare i sistemi. La procedura utilizzata dalla Regione Emilia-Romagna Ã¨ codificata dal Di- sciplinare Tecnico per incidenti di sicurezza, adottato in forma sperimentale il 9 marzo 2009. Tale disciplinare prevede la presenza di unâ''unitÃ di gestione degli incidenti di sicurezza informatica (UGISI), con le seguenti caratteristiche: â'¢ rappresenta il punto di riferimento a cui rivolgersi per segnalare un inci- dente di sicurezza; â'¢ gestisce tutte le attivitÃ inerenti un incidente di sicurezza, ivi comprese quelle relative alla sua documentazione e notifica; â'¢ garantisce la disponibilitÃ e rintracciabilitÃ di liste di contatti (es.: per- sonale dipendente, collaboratori, fornitori, manutentori), necessarie per la gestione di un incidente di sicurezza; â'¢ garantisce che la gestione incidenti risponda alle esigenze dellâ''Ente, prov- vedendo che sia sempre mantenuta aggiornata: â'' a valle di cambiamenti tecnologici, infrastrutturali e organizzativi; â'' a valle di incidenti di sicurezza che mettano in evidenza aspetti di miglioramento nella procedura stessa. La procedura di gestione si articola nelle fasi di seguito elencate e schematizzate nella figura 4.4.1. Durante la fase di analisi Ã¨ prevista la categorizzazione dellâ''incidente, in base agli eventi preventivi e indicativi riscontrati. Il SIEM puÃ² essere utile nel rilevare rapidamente gli eventi indicativi di tutte le tipologie di incidente; esempi di eventi indicativi che possono essere rilevati dal SIEM sono: â'¢ attivitÃ di port scan, host scan, vulnerability scan, ping, traceroutes, DNS zone transfers, OS fingerprinting, banner grabbing; â'¢ tentativi di accesso a file contenenti informazioni critiche (es.: password- files) presenti nel sistema; 61 CAPITOLO 4. GESTIONE DELLA SICUREZZA INFORMATICA â'¢ traffico di rete fortemente sbilanciato (molto traffico in ingresso, poco in uscita alla rete); â'¢ antivirus software alert; â'¢ tentativi di accesso al servizio che presenta una vulnerabilitÃ ; â'¢ log dei dispositivi di rete (Firewall, router) relativi alla presenza di comu- nicazioni client-server legati alla presenza di Trojan Horse; â'¢ traffico anomalo da/verso determinati sistemi. Unâ''altra fase in cui il SIEM Ã¨ fondamentale Ã¨ la fase di analisi delle evidenze, fatta sia a scopo legale che cautelativo, che di indagine interna volta a rimuovere le cause dellâ''incidente. La ricerca allâ''interno dei log puÃ² rendere evidenti le modalitÃ in cui lâ''incidente ha avuto luogo. 62 CAPITOLO 4. GESTIONE DELLA SICUREZZA INFORMATICA Figura 4.4.1: Gestione degli incidenti di sicurezza 63 CAPITOLO 4. GESTIONE DELLA SICUREZZA INFORMATICA 64 Capitolo 5 Realizzazione del sistema di
monitoraggio Il sistema di monitoraggio della sicurezza informatica in Regione Emilia-Romagna, basato, come giÃ detto, su un modello SIEM, Ã¨ lâ''evoluzione di un sistema di log management adottato dalla Regione Emilia-Romagna allo scopo di adeguarsi al provvedimento del Garante per la Protezione dei Dati Personali sugli Ammi- nistratori di sistema del 27 novembre 2008, le cui disposizioni sono entrate in vigore il 15 dicembre 2009. Il processo di implementazione del sistema di log management Ã¨ stato svolto avendo sempre presente come obiettivo secondario lâ''integrazione di eventi significativi dal punto di vista della sicurezza informatica dellâ''Ente. In questo capitolo verrÃ descritto il processo di realizzazione del sistema di monitoraggio della sicurezza informatica allâ''interno della Regione Emilia- Romagna, descrivendo il sistema di log management di partenza, la scelta del- lâ''architettura del SIEM, la modellazione della rete e degli asset, la definizione, a partire da alcuni eventi di interesse, di regole, strumenti di monitoraggio e reportistica. 5.1 Il sistema di log management Lâ''obbligo, previsto dal provvedimento del Garante sopra citato, di adottare stru- menti atti alla registrazione degli accessi logici degli amministratori di sistema, registrando in maniera inalterabile login avvenuti con successo, login falliti e logout, insieme al timestamp di tali eventi, non era soddisfabile utilizzando gli strumenti in essere. Allâ''interno dellâ''Ente i log degli accessi erano infatti presenti unicamente allâ''interno dei sistemi che li avevano generati e i tempi di conserva- zione erano incerti. Era presente unicamente un server Syslog che raccoglieva in un punto centrale i log dei sistemi server linux; sebbene tale sistema potesse co- stituire un punto di partenza per la creazione di un sistema di log management centralizzato, Ã¨ stato valutato che ciÃ² non fosse conveniente, sia perchÃ© non tutti 65 CAPITOLO 5. REALIZZAZIONE DEL SISTEMA DI MONITORAGGIO i sistemi su cui erano stati designati amministratori di sistema erano compati- bili con syslog, sia perchÃ© i log immagazzinati non avevano caratteristiche di integritÃ e inalterabilitÃ . Vista la necessitÃ di acquisire uno strumento di log management si Ã¨ pensato di approfittarne per scegliere uno strumento che potesse, attraverso la raccolta dei log, aiutare nellâ''individuazione di eventi significativi dal punto di vista della sicurezza, orientandosi perciÃ² nella realizzazione di un SIEM. Requisiti essen- ziali nella scelta del prodotto erano anche la piÃ¹ ampia presenza possibile di connettori giÃ configurati per supportare i sistemi su cui erano stati individuati amministratori di sistema, la presenza di metodi per creare connettori â''customâ' verso i sistemi non supportati nativamente e la possibilitÃ di memorizzare il database degli eventi su un sistema di Storage Area Network (SAN). La valutazione delle soluzioni disponibili ha portato a scegliere la soluzione ArcSight, nello specifico lâ''appliance L7200-SAN (logger appliance), che supporta fino a 75000 eventi per secondo (EPS), insieme allâ''appliance C3200 (connector
appliance ), che contiene i connettori verso le sorgenti di log e funge anche da console di management per gli altri connettori installati su altri device. Al- tri connettori sono installati su un server virtuale Windows o, in alcuni casi, sui sistemi sorgenti dei log. I connettori contenuti nella soluzione ArcSight (SmartConnector) hanno lo scopo di filtrare gli eventi che non sono di interesse, di aggregare eventi simili e soprattutto normalizzare e categorizzare gli eventi adattandoli allo schema ArcSight di categorizzazione degli eventi. La scelta delle sorgenti di log da integrare allâ''interno del sistema di log management Ã¨ stata effettuata con lâ''obiettivo primario di ottemperare al prov- vedimento del garante, senza tuttavia trascurare tutti quegli eventi non relativi agli accessi degli amministratori ma che fossero significativi dal punto di vista della sicurezza informatica. Di seguito viene descritta la tipologia di log presenti sul sistema di log ma- nagement al momento dellâ''avvio del progetto di realizzazione del sistema di monitoraggio della sicurezza informatica e le modalitÃ di integrazione. Sistemi server Windows Alcuni connettori standard contenuti sulla con- nector appliance sono configurati per prelevare via RPC i log di tipo security contenuti allâ''interno dei registri degli eventi dei sistemi server Windows fisici e virtuali dellâ''Ente (circa 250); lâ''invio avviene quindi con metodo pull. Sistemi server Linux La connector appliance contiene un server syslog, configurabile per utilizzare il protocollo udp o tcp. Il syslog dei server Linux dellâ''Ente (circa 100), sono configurati per inviare i log al connector appliance; lâ''invio avviene quindi in modalitÃ push. Sistemi di sicurezza Tutte le categorie di sistemi di sicurezza descritti al capitolo 4.3 sono integrati con il sistema di log management. Per i firewall lâ''integrazione avviene mediante un connettore standard instal- lato su un server Windows. Il connettore preleva in real time i log dal server di 66 CAPITOLO 5. REALIZZAZIONE DEL SISTEMA DI MONITORAGGIO management utilizzando lo standard OPSEC LEA (Log Export API). La versio- ne adottata utilizza il protocollo SSL per assicurare che il traffico che attraversa la rete tra lo SmartCenter e la componente di collezionamento del SIEM sia criptato. I firewall generano un evento per ogni sessione del traffico di rete che li attraversa, indicando il timestamp dellâ''evento, lâ''ip di origine e di destinazione, il protocollo layer 4 utilizzato, la porta tcp o udp di origine e di destinazione, il nodo firewall e lâ''interfaccia di rete attraversata dal pacchetto, la policy appli- cata. Per il sistema di VPN SSL, le modalitÃ di interazione con il sistema di log management sono le stesse dei sistemi firewall. Il sistema VPN SSL genera eventi a seguito dellâ''autenticazione degli utenti, indicando il timestamp dellâ''e- vento, lâ''ip di origine e di destinazione, il protocollo layer 4 utilizzato, la porta tcp o udp di origine e di destinazione, la policy applicata. Per quel che riguarda i sistemi anti malware elencati nel paragrafo 4.3.2, tutti, ad eccezione di Deep Security, permettono di inviare i log degli eventi si- gnificativi ad un concentratore, il Trend Micro Control Manager, che si appoggia ad un database. Un connettore standard contenuto sulla connector appliance, attraverso query sql, preleva i log da tale database, in modalitÃ pull. PoichÃ© per il sistema Deep Security non Ã¨ possibile utilizzare il Trend Micro Contro Mana- ger, per tale sistema viene fatto un forward degli eventi alla connector appliance mediante il protocollo Syslog. Gli eventi generati dai sistemi anti malware con- tengono il timestamp dellâ''evento, il sistema dove Ã¨ stato rilevato il malware, il malware rilevato, il file, lâ''url o il messaggio di posta elettronica che lo conteneva, lâ''operazione effettuata dal sistema anti malware e lâ''esito dellâ''operazione. Altri eventi registrati sono lâ''aggiornamento dei database delle signature del malware ed eventuali scansioni complete. Le sonde di Intrusion Detection and Prevention generano un evento per ogni pacchetto che fa match con una delle signature presenti, per la quale sia stata definita una policy che lo preveda. Viene indicato il timestamp dellâ''evento, lâ''ip di origine e di destinazione, il protocollo layer 4 utilizzato, la porta tcp o udp di origine e di destinazione, il nodo firewall e lâ''interfaccia di rete attraversata dal pacchetto, la policy applicata, una descrizione della minaccia. Il SIEM riceve in real time i log dal server di management utilizzando il protocollo Syslog. Per quel che riguarda il sistema di web proxying, allâ''interno del file di access log di Squid viene registrato il timestamp, il nome utente, lâ''ip del client che si connette, lâ''uri richiesto, lâ''esito dellâ''operazione, lâ''azione richiesta sulla cache, il metodo HTTP. Il SIEM interagisce attraverso un connettore installato sui server dove Ã¨ presente Squid, il quale processa in real time i file di log, li aggrega, li normalizza e li invia al SIEM. Sistemi di autenticazione Gli eventi del sistema di autenticazione Active Directory sono registrati allâ''interno dellâ''Event Viewer dei Domain Controller dei rispettivi domini. Il SIEM preleva i log attraverso uno dei connettori installati sulla connector appliance dedicati ai server Windows. Per quel che riguarda il sistema di Identity and Access Management, ognuno dei componenti del sistema di IAM ha un suo sistema di logging. 67 CAPITOLO 5. REALIZZAZIONE DEL SISTEMA DI MONITORAGGIO Il Directory Server registra allâ''interno di file di testo il timestamp e la query ldap effettuata (tra cui lâ''operazione di bind, ovvero lâ''autenticazione). La co- municazione con il SIEM avviene attraverso un connettore installato sui server stessi dove Ã¨ in esecuzione il Directory Server. Lâ''Identity Manager registra allâ''interno di un database Oracle gli eventi di autenticazione allâ''interno del sistema stesso e gli eventi di modifica degli oggetti gestiti dal sistema. Gli attributi presenti sono il timestamp, il tipo di operazione effettuata, il nome utente, il sistema di provenienza. La comunicazione con il SIEM avviene mediante un connettore custom installato centralmente. Lâ''Access Manager, infine, registra allâ''interno di file di testo gli eventi di au- tenticazione degli utenti sul portale delle applicazioni e ogni accesso ad ogni singolo url esposto dalle applicazioni integrate con lâ''Access Manager. Gli attri- buti presenti sono il timestamp, il nome utente, il sistema di provenienza, lâ''url a cui si Ã¨ tentato di accedere. La comunicazione con il SIEM avviene attraverso un connettore installato sui server stessi dove Ã¨ in esecuzione lâ''Access Manager. Infine il servizio RADIUS (Cisco ACS) memorizza allâ''interno di un database proprietario gli eventi di autenticazione, autorizzazione ed accounting, memoriz- zando timestamp, sistema di provenienza, nome utente e gruppo di appartenen- za dellâ''utente. La comunicazione con il SIEM avviene attraverso il protocollo Syslog. Sistemi Database Oracle, MSSql e Postgres I sistemi RDBMS sono integrati con lo strumento di log management mediante connettori standard presenti sulla connector appliance. Nel caso di Oracle i log vengono letti dal database stesso, nel caso di MSSQL i log vengono presi da file di testo prodotto sul sistema dove Ã¨ installato lâ''RDBMS dalla componente di audit dellâ''RDBMS stesso, nel caso di Postgres si utilizza il protocollo syslog. Software SAP Allâ''interno dellâ''Ente sono presenti diversi landscape SAP, sia di produzione che di test. Tali sistemi sono integrati mediante connettori standard presenti sulla connector appliance. Tali connettori processano appositi file di audit contenuti sui server dove Ã¨ installato SAP. Applicazioni web La maggior parte delle applicazioni web presenti nel- lâ''Ente ha unâ''architettura multi-tier, con il frontend realizzato attraverso un sistema di bilanciamento, che ha la possibilitÃ di operare layer 7: il sistema LBL di TCO Group. Tale bilanciatore registra i log degli accessi su una tabella di un database Oracle. Lâ''integrazione di tali eventi avviene mediante un con- nettore custom residente sulla connector appliance, configurato per prelevare gli eventi allâ''interno del database. Gli eventi registrati contengono il timestamp, il sistema sorgente e di destinazione, lâ''url invocato, lâ''operazione http, i parametri dellâ''uri, i cookies, lâ''esito dellâ''operazione. Le applicazioni web con autenticazione centralizzata hanno il frontend rea- lizzato da server Apache che, attraverso il modulo di policy agent del sistema 68 CAPITOLO 5. REALIZZAZIONE DEL SISTEMA DI MONITORAGGIO Sun Access Manager, si occupa dellâ''autenticazione e della verifica delle autoriz- zazioni dellâ''utente. Lâ''integrazione di tali eventi avviene mediante un connettore standard installatato sui server di frontend, che processa i file di log di Apache e invia i log aggregati e normalizzati al sistema di log management. Gli even- ti registrati, oltre agli attributi elencati per i bilanciatori LBL, contengono lo username dellâ''utente che ha effettuato lâ''accesso. Sistema centralizzato di backup Lâ''Ente dispone di un sistema centra- lizzato di backup in tecnologia IBM, il Tivoli Storage Manager, che provvede, attraverso agenti installati sui server, al backup e allâ''eventuale rispristino di dati residenti sui filesystem dei server e contenuti in RDBMS. Gli eventi di accesso al sistema, lancio dei backup e dei rispristini effettuati mediante il sistema sono contenuti allâ''interno di un database proprietario. Lâ''integrazione di tali even- ti avviene mediante un connettore custom presente su un server Windows; sul medesimo server Windows Ã¨ presente un client Tivoli che ad intervalli regola- ri esegue unâ''esportazione degli eventi in un file: tale file viene processato dal connettore custom, che invia gli eventi processati al sistema di log management. 5.2 Architettura del sistema di log correlation Il sistema di log management descritto al paragrafo 5.1 contiene in un database tutti gli eventi di interesse per il monitoraggio della sicurezza informatica del- lâ''Ente adeguatamente normalizzati, con in piÃ¹ strumenti di ricerca e reportistica. Tale sistema Ã¨ completamente adeguato per la ricerca a posteriori di evidenze di incidenti di sicurezza, per la verifica del rispetto delle policy di sicurezza e per la conformitÃ alle normative (quale il giÃ citato provvedimento del Garante per la protezione dei dati personali sugli amministratori di sistema, motivo per il quale il sistema Ã¨ stato realizzato). La possibilitÃ di individuare eventi indi- cativi di incidenti di sicurezza Ã¨ limitata a ricerche manuali, fatte dagli analisti di sicurezza, e allâ''analisi dei report schedulati, quindi non in modalitÃ realtime: quello che mancava era quindi uno strumento di log correlation. Si Ã¨ quindi proceduto allâ''acquisizione di uno strumento di log correlation, che, per essere compatibile con i connettori giÃ installati, doveva essere di tec- nologia ArcSight. La scelta Ã¨ caduta sullâ''appliance Arcsight Express M7200, un sistema Linux contenente un DBMS Oracle e il sofware Arcsight Enterprise Manager (ESM), descritto al capitolo 3 e dimensionato per il numero di sistemi e di eventi presenti nellâ''Ente. Tale sistema Ã¨ stato configurato per ricevere gli eventi dal logger, il quale effettua il forward degli eventi ricevuti. Una volta individuate correlazioni fra gli eventi, lâ''ESM crea nuovi eventi, i cosiddetti eventi correlati. Lâ''ESM Ã¨ stato configurato affinchÃ© gli eventi correlati, oltre ad essere conservati sul database dellâ''ESM, vengano inviati al logger, il quale li conserverÃ nel proprio database rendendoli non modificabili. Lâ''architettura del SIEM Ã¨ illustrata in figura 5.2.1. 69 CAPITOLO 5. REALIZZAZIONE DEL SISTEMA DI MONITORAGGIO Figura 5.2.1: Architettura del sistema 5.3 Modellazione della rete e degli asset Al fine della definizione degli eventi di interesse, Ã¨ opportuno che allâ''interno del SIEM siano definite le zone di reti dellâ''organizzazione, in modo che attaccante e vittima degli eventi di interesse siano collocate allâ''interno della rete dellâ''or- ganizzazione e che sia possibile definire gli eventi di interesse in base alle reti coinvolte. Allo stesso modo Ã¨ opportuno che allâ''interno del SIEM siano definiti gli asset dellâ''organizzazione, in modo da poter definire eventi di interesse che tengano conto del livello di criticitÃ degli asset, del ruolo da essi ricoperto al- lâ''interno dellâ''organizzazione, delle porte tcp/udp su cui sono in ascolto servizi, delle vulnerabilitÃ presenti, del sistema operativo installato, eccetera. Presso il sistema informativo della Regione Emilia-Romagna sia le informa- zioni relative alle reti che quelle relative agli asset sono contenute allâ''interno del CMDB. 5.3.1 Importazione delle zone Le zone definite sul CMDB sono relative ai domini di broadcast definiti allâ''in- terno della lan dellâ''organizzazione. Le reti degli uffici fanno parte di zone che rispecchiano la collocazione fisica (es. il piano di un edificio) e hanno indiriz- zamento ip dinamico (tramite dhcp), mentre le reti dei server fanno parte di zone raggruppate secondo la funzione logica del server e hanno indirizzamento ip statico. Lâ''importazione delle zone Ã¨ avvenuta partendo da un file csv prodotto dal CMDB e importato sul SIEM attraverso un apposito tool dellâ''ESM. Il formato del file CSV dal quale Ã¨ stata fatta lâ''importazione Ã¨ mostrato in tabella 5.1. Ã' da 70 CAPITOLO 5. REALIZZAZIONE DEL SISTEMA DI MONITORAGGIO notare come nella definizione della zona occorra dichiarare se lâ''indirizzamento Ã¨ statico o dinamico. Tabella 5.1: Formato del file CSV delle zone Nome Descrizione Obbligatorio Ripetibile Name Nome descrittivo della zona, come lo scopo o la locazione geografica. SÃ¬ No Start Address Il primo IP dellâ''intervallo che definisce la zona. SÃ¬ No End Address Lâ''ultimo IP dellâ''intervallo che definisce la zona. SÃ¬ No Dynamic Determina se i dispositivi definiti nella zona usano indirizzamento dinamico. PuÃ² contenere true o false. SÃ¬ No Category URI URI della categoria di asset da
assegnare alla zona. PuÃ² essere
ripetuta perchÃ© una zona puÃ² essere
assegnata a piÃ¹ categorie di asset. Esempio: /All Asset Categories/All Site Asset Categories/Business Impact Analisys/Business Role/Service/Web/ No SÃ¬ 5.3.2 Importazione degli asset e definizione delle categorie
di asset Allâ''interno del CMDB sono definiti gli asset materiali e immateriali dellâ''Ente. La modellazione degli asset prevede che un asset venga identificato in maniera univoca attraverso il suo indirizzo ip (asset fisici aventi piÃ¹ indirizzi ip risultano essere piÃ¹ asset allâ''interno del modello). In fase di inserimento di un asset oc- corre poi definire quali sono le categorie alle quali lâ''asset appartiene. Allâ''interno del CMDB sono definite le categorie di asset elencate di seguito. â'¢ Area di amministrazione; tale informazione allâ''interno del CMDB Ã¨ utiliz- zata per avere traccia di chi siano gli amministratori dellâ''asset; allâ''interno del SIEM, oltre che essere utile per rilevare gli accessi degli amministratori, lo Ã¨ anche come ruolo ricoperto dallâ''asset. â'¢ Sistema operativo; tale informazione allâ''interno del CMDB Ã¨ utilizzata per la gestione del catalogo del software e per la gestione degli aggiornamenti; allâ''interno del SIEM Ã¨ utilizzata per la creazione di monitoraggi specifici per asset con un certo sistema operativo o per una sua versione specifica. â'¢ CriticitÃ del sistema; tale informazione allâ''interno del CMDB Ã¨ utilizzata per derivarne le modalitÃ di esecuzione di operazioni di manutenzione o 71 CAPITOLO 5. REALIZZAZIONE DEL SISTEMA DI MONITORAGGIO di fermi programmati; allâ''interno del SIEM Ã¨ utilizzata per poter defini- re regole dedicate ad asset critici; il tipo di criticitÃ dellâ''asset Ã¨ inoltre utilizzato dallâ''ESM per calcolare la formula di prioritÃ di un evento. â'¢ Locazione; tale informazione allâ''interno del CMDB Ã¨ utilizzata per la ge- stione dellâ''hardware e dei cablaggi; allâ''interno del SIEM Ã¨ utilizzata per eventuali monitoraggi basati sulla locazione fisica. La prima importazione degli asset allâ''interno del SIEM Ã¨ avvenuta esportando le informazioni contenute allâ''interno del CMDB in un file csv; tale file Ã¨ stato opportunamente modificato per far coincidere le categorie degli asset del CMDB con gli URI associati alle categorie definite allâ''interno del SIEM. Il file csv Ã¨ stato poi importato utilizzando lo stesso tool dellâ''ESM utilizzato per lâ''importazione delle zone. Il formato del file csv utilizzato Ã¨ mostrato in tabella 5.2. Se la prima importazione Ã¨ avvenuta attraverso una procedura manuale, oc- correva impostare poi una procedura automatizzata per permettere a regime la sincronizzazione fra le informazioni sugli asset contenute nel CMDB e quelle contenute nel SIEM, in quanto avvengono piuttosto frequentemente variazioni sugli asset e sulle loro configurazioni. A tal fine Ã¨ stato utilizzato un apposito connettore Arcsight, lâ''Asset Import file FlexConnector. Tale connettore permet- te di configurare una directory nella quale vengono posizionati i file csv: ogni qualvolta un nuovo file csv viene posizionato nella directory il connettore lo pro- cessa, inviando i risultati allâ''ESM. Gli asset giÃ esistenti allâ''interno dellâ''ESM vengono modificati con i nuovi dettagli che via via vengono trovati allâ''interno del file csv. Per lâ''automazione dellâ''operazione di creazione dei file csv da dare in input al connettore, Ã¨ stato creato uno script Python che, processando i risultati di una query sql eseguita sul database del CMDB, va a compilare il file csv che verrÃ poi elaborato dal connettore. 5.3.3 VulnerabilitÃ degli asset Allâ''interno del SIEM Ã¨ importante avere conoscenza delle vulnerabilitÃ a cui sono affetti i singoli asset e delle porte tcp e udp su cui siano in ascolto servi- zi. Tali informazioni sono cruciali per poter individuare attacchi che cerchino di utilizzare vulnerabilitÃ effettivamente presenti allâ''interno degli asset e sono inoltre utilizzate dallâ''ESM per calcolare la prioritÃ degli eventi individuati. Presso la Regione Emilia-Romagna vengono effettuati regolari vulnerabili- ty assessment su tutti gli asset presenti, utilizzando il software di vulnerability scanning Tenable Nessus. Un apposito connettore Arcsight, il Tenable Nessus
.nessus File permette di configurare una directory nella quale vengono posi- zionati i report delle scansioni: ogni qualvolta in tale directory appare un file
<nome_report>.nessus_done , il report <nome_report>.nessus viene processa- to. Attraverso uno shell script appositamente creato, la scansione degli asset con le informazioni su vulnerabilitÃ e porte aperte viene automaticamente importata allâ''interno del SIEM. 72 CAPITOLO 5. REALIZZAZIONE DEL SISTEMA DI MONITORAGGIO Tabella 5.2: Formato del file CSV degli asset Nome Descrizione Obbligatorio Ripetibile Name Nome descrittivo dellâ''asset. Se il nome non Ã¨ specificato, verrÃ generato un nome unico. No No Host Name Nome DNS del dispositivo rappresentato dallâ''asset. No No IP Address Indirizzo IP del dispositivo di rete rappresentato dallâ''asset. SÃ¬ No MAC Address MAC address del dispositivo di rete rappresentato dallâ''asset. No No Static Address Definisce se lâ''indirizzo di rete dellâ''asset Ã¨ in una zona statica o dinamica. PuÃ² contenere true o false. No No Category URI URI della categoria di asset. PuÃ²
essere ripetuta perchÃ© lo stesso asset
puÃ² essere categorizzato in piÃ¹
modi. Esempi:
/All Asset Categories/RER/Area
Riferimento/Amministratori Server
Linux - S345 /All Asset Categories/System Asset Categories/Criticality/High No SÃ¬ 5.4 Individuazione degli eventi di interesse Sono state individuate categorie di eventi che possono costituire minacce per il sistema informatico dellâ''Ente. Per ogni categoria individuata, sono state definiti filtri e regole di correlazione, usati poi per popolare console di monitoraggio e generare report per il monitoraggio della sicurezza a piÃ¹ alto livello. Gli eventi di interesse individuati sono i seguenti: â'¢ autenticazione degli utenti; â'¢ attacchi sulla rete; â'¢ attacchi e malware a livello host; â'¢ attacchi alle applicazioni web. 5.5 Autenticazione degli utenti La categoria di eventi di interesse legate allâ''autenticazione degli utenti ha lâ''obiet- tivo di individuare attacchi di forza bruta, tentativi di indovinare le password, malware e applicazioni mal configurate. 73 CAPITOLO 5. REALIZZAZIONE DEL SISTEMA DI MONITORAGGIO 5.5.1 Regole di correlazione Allâ''interno dellâ''ESM Ã¨ possibile individuare gli eventi di autenticazione, indi- pendentemente dalla sorgente che li ha prodotti, verificando il valore del cam- po categoryBehavior, che in tali casi contiene il valore â''/Authentication/Veri-
fy â'; il campo categoryOutcome conterrÃ lâ''esito del tentativo di autenticazione: â''/Successâ', â''/Failureâ' o â''/Attemptâ'. 5.5.1.1 Tentativi ripetuti di login provenienti da una singola sorgente Si vuole creare un evento correlato ogni qualvolta si hanno cinque login falliti provenienti da un singolo host nellâ''arco di un minuto. Eâ'' stato inizialmente predisposto un filtro per lâ''individuazione di tale evento, che costituirÃ il mattone sul quale costruire successivamente regole, strumenti di monitoraggio e report. Tale filtro, denominato â''Attack Login Sourceâ', Ã¨ cosÃ¬ costituito: ( NotInActiveList("ArcSight Agent Users") AND NotInActiveList("Proxy server") AND Attacker Address Is NOT NULL AND Category Behavior = /Authentication/Verify AND Category Outcome = /Failure AND Category Technique != /Brute Force/Login AND Device Product != Squid Web Proxy Server ) Figura 5.5.1: Filtro: Attack Login Source Le active list che escludono alcune categorie di asset e utenti, hanno lo scopo di escludere dal monitoraggio alcune categorie di eventi che esulano dagli scopi. Nel nostro caso sono stati esclusi gli eventi di login fallito sui server proxy (avremmo avuto tutti gli eventi di tipo http 407 â''Proxy authentication requiredâ') e gli eventi di login fallito da parte degli account utilizzati dai connettori del SIEM. Il filtro â''Attack Login Sourceâ' viene usato poi per la creazione di eventi corre- lati utilizzando a questo fine una simple rule. Tale rule avrÃ come condizione la corrispondenza con il filtro precedente, come aggregation cinque condizioni sod- disfatte nellâ''arco di un minuto, aggregando solo gli eventi che hanno lâ''attributo AttackerAddress identico. Auth_Fail : MatchesFilter("Attack-Login Source") Aggregate if at least 5 matching conditions are found within 1 Minutes AND these event fields are the same (Auth_Fail.Attacker Zone Resource, Auth_Fail.Attacker Address) Figura 5.5.2: Rule: Attack Login Source La rule cosÃ¬ creata genererÃ un evento correlato al raggiungimento della soglia impostata. Sullâ''evento correlato vengono impostati i seguenti valori per i campi: 74 CAPITOLO 5. REALIZZAZIONE DEL SISTEMA DI MONITORAGGIO message: Repeat Attack-Login source categoryBehavior: /Authentication/Verify categoryOutcome: /Failure categoryTechnique: /Brute Force/Login 5.5.1.2 Tentativi ripetuti di login rivolti ad un singolo account Si vuole creare un evento correlato ogni qualvolta si hanno cinque login falliti rivolti ad un singolo account nellâ''arco di un minuto. Eâ'' stato inizialmente predisposto un filtro per lâ''individuazione di tale evento, che costituirÃ il mattone sul quale costruire successivamente regole, strumenti di monitoraggio e report. Tale filtro, denominato â''Attack Login Targetâ', Ã¨ cosÃ¬ costituito: ( NotInActiveList("ArcSight Agent Users") AND NotInActiveList("Proxy server") AND Target User Name Is NOT NULL AND Category Behavior = /Authentication/Verify AND Category Outcome = /Failure AND Category Technique != /Brute Force/Login AND Device Product != Squid Web Proxy Server ) Figura 5.5.3: Filtro: Attack Login Target Le active list che escludono alcune categorie di asset e utenti, hanno lo scopo di escludere dal monitoraggio alcune categorie di eventi che esulano dagli scopi. Nel nostro caso abbiamo escluso gli eventi di login fallito sui server proxy (avremmo avuto tutti gli eventi di tipo http 407 â''Proxy authentication requiredâ') e gli eventi di login fallito da parte degli account utilizzati dai connettori del SIEM. Il filtro â''Attack Login Targetâ' viene usato poi per la creazione di eventi corre- lati utilizzando a questo fine una simple rule. Tale rule avrÃ come condizione la corrispondenza con il filtro precedente, come aggregation cinque condizioni sod- disfatte nellâ''arco di un minuto, aggregando solo gli eventi che hanno lâ''attributo AttackerAddress identico. Auth_Fail : MatchesFilter("Attack-Login Target") Aggregate if at least 5 matching conditions are found within 1 Minutes AND these event fields are the same (Auth_Fail.Attacker Zone Resource, Auth_Fail.Attacker Address) Figura 5.5.4: Rule: Attack Login Target La rule cosÃ¬ creata genererÃ un evento correlato al raggiungimento della soglia impostata. Sullâ''evento correlato vengono impostati i seguenti valori per i campi: message: Repeat Attack-Login target categoryBehavior: /Authentication/Verify categoryOutcome: /Failure categoryTechnique: /Brute Force/Login 75 CAPITOLO 5. REALIZZAZIONE DEL SISTEMA DI MONITORAGGIO 5.5.1.3 Attacchi di forza bruta Se vengono rilevati diversi successivi tentativi falliti di autenticazione, prove- nienti da un singolo host oppure aventi come oggetto un certo account, e suc- cessivamente dallo stesso host o verso lo stesso account un evento di login che ha successo, potremmo trovarci in presenza di un attacco riuscito di forza bruta. Per individuare attacchi di questo tipo Ã¨ possibile utilizzare gli eventi corre- lati generati dalle rule ai due punti precedenti. Sono stati inizialmente predisposti due filtri, â''Attack-Login Source Correla- ted â' e â''Attack-Login Target Correlatedâ', che sono filtri che individuano gli eventi correlati creati dalle due simple rule precedenti. ( NotInActiveList("ArcSight Agent USers") AND NotInActiveList("Proxy server")
AND Type = Correlation AND Attacker Address Is NOT NULL AND Category Behavior
= /Authentication/Verify AND Category Outcome = /Failure AND Category
Technique = /Brute Force/Login AND Device Product != Squid Web Proxy Server ) ( NotInActiveList("ArcSight Agent USers") AND Category Behavior = /Authentication/Verify AND Category Outcome = /Failure AND Category Technique = /Brute Force/Login AND Device Product != Squid Web Proxy Server AND Target User Name Is NOT NULL AND Type = Correlation ) Figura 5.5.5: Filtri: Attack Login Source Correlated e Attack Login Target Correlated Tali filtri sono stati poi utilizzati per la definizione della join rule â''Brute Force Logins â', che permette la creazione di eventi correlati al verificarsi di sospetti attacchi riusciti di forza bruta. Matching Event: ( Brute_Force.End Time <= Login_Success.End Time AND ( ( Brute_Force.Attacker Address = Login_Success.Attacker Address AND
Brute_Force.Attacker Zone Resource = Login_Success.Attacker Zone Resource ) OR
Brute_Force.Target User Name = Login_Success.Target User Name ) ) Brute_Force : ( ( MatchesFilter("Attack-Login Source Correlated") OR MatchesFilter("Attack-Login Target Correlated") ) AND NotInActiveList("Trusted
List") AND NotInActiveList("ArcSight Agent USers") ) Login_Success : ( NotInActiveList("Trusted List") AND Category Behavior = /Authentication/Verify AND Category Outcome = /Success AND Category Technique != /Brute Force/Login ) Aggregate if at least 5 matching conditions are found within 2 Minutes AND these event fields are the same (Brute_Force.Customer Resource, Brute_Force.Target User ID, Login_Success.Target User ID, Login_Success.Target User Name, Brute_Force.Target User Name, Login_Success.Customer Resource) Figura 5.5.6: Rule: Brute Force Logins 76 CAPITOLO 5. REALIZZAZIONE DEL SISTEMA DI MONITORAGGIO La rule cosÃ¬ creata genererÃ un evento correlato al raggiungimento della soglia impostata. Sullâ''evento correlato vengono impostati i seguenti valori per i campi: message: Repeat Attack-Login target categoryBehavior: /Authentication/Verify categoryOutcome: /Success categoryTechnique: /Brute Force/Login 5.5.1.4 Errori di autenticazione sulla VPN Si vuole creare un evento correlato ad ogni tentativo di autenticazione fallita sulla VPN. Lâ''accesso in VPN, infatti, non avviene attraverso meccanismi di strong authentication, ma tramite username e password ed Ã¨ utilizzata anche da utenti che dispongono di privilegi elevati sulla rete regionale. I log degli eventi di autenticazione sono caratterizzati dal campo categoryBe- havior , che in tali casi contiene il valore â''/Accessâ'; il campo categoryDeviceGroup conterrÃ il valore â''/Firewallâ' e il campo DeviceEventClassId conterrÃ infine il valore â''rejectâ'. Ã' stata creata la rule â''VPN Authentication Failedâ', definita di seguito. ( Category Behavior = /Access AND Category Device Group = /Firewall AND Device Event Class ID = reject AND Attacker Address Is NOT NULL Figura 5.5.7: VPN Authentication Failed La rule cosÃ¬ creata genererÃ un evento correlato alla prima occorrenza di evento che corrisponde alla definizione; sullâ''evento correlato vengono impostati i seguenti valori: categoryBehavior: /Authentication/Verify categoryDeviceGroup: /VPN categorySignificance: /Informational/Error categoryTechnique: /Brute Force/Login La rule, ad ogni evento correlato generato, andrÃ a popolare unâ''active list con lâ''ip di provenienza del login fallito e il nome dellâ''account con cui Ã¨ stata tentata lâ''autenticazione. 5.5.1.5 Modifica delle configurazioni di utenti e host Si vuole creare un evento correlato ogni qualvolta vengano effettuate modifi- che su utenti, quali creazione, assegnazione a gruppi, concessione di privilegi, reset password. Si vuole inoltre tenere traccia dellâ''utente che ha fatto le modifi- che. Questa categoria di eventi Ã¨ molto importante in un contesto esteso come il sistema informatico della Regione Emilia-Romagna, dove molte di queste opera- zioni non sono fatte direttamente dagli amministratori, ma delegate a referenti. La gestione degli utenti allâ''interno del sistema informatico della Regione Emilia- Romagna avviene attraverso un programma che interagisce con il dominio Active Directory e attraverso il sistema di Identity & Access Management. 77 CAPITOLO 5. REALIZZAZIONE DEL SISTEMA DI MONITORAGGIO I log di entrambe queste categorie sono caratterizzati dal campo category- Behavior , che conterrÃ il valore â''/Modify/Configurationâ'. Eâ'' stato inizialmente predisposto il filtro â''Configuration Modificationâ', cosÃ¬ costituito: ( MatchesFilter("Non-ArcSight Events") AND Category Behavior = /Modify/Configuration ) Figura 5.5.8: Filtro: Configuration Modification Tale definizione utilizza il filtro â''Non-Arcsight Eventsâ', che ha lo scopo di escludere gli eventi generati dallâ''ESM o dal logger. A partire dal filtro appena definito viene definita la rule â''Successfull Confi- guration Change â': ( Target Address Is NOT NULL AND Target Zone Is NOT NULL AND Category Outcome
= /Success AND MatchesFilter("Configuration Modifications") AND Category
Object != /Host/Operating System ) Aggregate if at least 1 matching conditions are found within 2 Minutes AND these event fields are the same (event1.Target User Name, event1.Message, event1.MyAction, event1.Attacker User Name) Figura 5.5.9: Rule: Successfull Configuration Change La rule cosÃ¬ creata genererÃ un evento correlato al raggiungimento della soglia impostata. Sullâ''evento correlato vengono impostati i seguenti valori per i campi: categoryBehavior: /Modify/Configuration deviceCustomString1: $MyAction deviceCustomString1Label: Action priority: 2 La variabile $MyAction contiene il tipo di operazione svolta sullâ''utente e contiene valori quali â''Reset passwordâ', â''Add Groupâ', eccetera. La rule, oltre a generare un evento correlato andrÃ a popolare unâ''active list con il nome utente che ha fatto la modifica, lâ''utente oggetto della modifica, lâ''azione effettuata, i dettagli dellâ''azione, il timestamp. 5.5.1.6 Accesso ai sistemi mediante account amministrativi non per-
sonali Le policy della Regione Emilia-Romagna prevedono che il login venga effettuato solamente utilizzando account personali, anche per quel che riguarda le utenze amministrative, e che gli account impersonali utilizzati dalle applicazioni non vengano utilizzati per lâ''accesso interattivo ai sistemi. Lâ''accesso con account amministrativi non personali deve essere limitato a casi particolari e comunque solo attraverso le console dei sistemi, non via rete. Per tale motivo si rende necessario monitorare il ricorso a tali eccezioni. 78 CAPITOLO 5. REALIZZAZIONE DEL SISTEMA DI MONITORAGGIO Eâ'' stata predisposta la query â''Privileged Users Loginâ', cosÃ¬ costituita: ( InActiveList("Administrative Accounts List") AND Category Behavior = /Authentication/Verify [ignore case] AND Category Outcome = /Success [ignore case] ) Figura 5.5.10: Query: Privileged Users Login La lista â''Administrative Accounts Listsâ' contiene lâ''elenco degli account am- ministrativi non personali, quali Administrator, root, admin, eccetera. 5.5.2 Strumenti di monitoraggio Gli strumenti predisposti per il monitoraggio dellâ''autenticazione degli utenti, consistono in alcuni active channel basati sulle regole create e in alcune dash- board in cui viene visualizzato, attraverso liste e grafici aggiornati in realtime, un compendio significativo degli eventi di interesse. 5.5.2.1 Monitoraggio di ripetuti login falliti e attacchi di forza bruta Si vuole predisporre una dashboard che permetta di visualizzare in forma grafica e in real time gli eventi relativi a login falliti e ad attacchi di forza bruta. A questo scopo, a partire dai filtri â''Attack-Login Source Correlatedâ', â''Attack- Login Target Correlated â' e â''Attack Brute Forceâ', sono state creati data monitor di tipo â''Last N eventsâ', che permettono di visualizzare una lista degli ultimi N eventi che soddisfano un filtro e data monitor di tipo â''Top Value Countsâ', che permettono di visualizzare un grafico con gli N oggetti per il quali il filtro Ã¨ stato soddisfatto. Tali data monitor sono stati combinati per ottenere una dashboard, che ha un aspetto del tipo mostrato in figura 5.5.11. 79 CAPITOLO 5. REALIZZAZIONE DEL SISTEMA DI MONITORAGGIO Figura 5.5.11: Dashboard di monitoraggio dei login falliti 5.5.2.2 Monitoraggio degli eventi di autenticazioni sulla VPN Si vuole creare una dashboard che permetta di visualizzare in forma grafica e in real time gli eventi di autenticazione sulla VPN. A questo scopo, sono stati creati i filtri â''VPN Successfull Loginâ' e â''VPN Failed Login â', mostrati in figura. ( Name = authcrypt AND Device Custom String3 = smartcenter AND ( Message Contains " connected" OR Message StartsWith connected ) ) Figura 5.5.12: Filter: VPN Successfull Login ( Category Behavior = /Access AND Category Device Group = /Firewall AND Device Event Class ID = reject AND Attacker Address Is NOT NULL Figura 5.5.13: Filter: VPN Failed Login A partire dai filtri creati, sono stati predisposti data monitor di tipo â''Last N events â', che permettono di visualizzare una lista degli ultimi N eventi che soddisfano un filtro e data monitor di tipo â''Top Value Countsâ', che permettono di visualizzare un grafico con gli N oggetti per il quali il filtro Ã¨ stato soddisfatto. Tali data monitor sono stati combinati per ottenere una dashboard. 80 CAPITOLO 5. REALIZZAZIONE DEL SISTEMA DI MONITORAGGIO 5.5.2.3 Autenticazioni fallite sulla VPN da parte di utenti privile-
giati Allo scopo di monitorare gli eventi di autenticazione fallita da parte di utenti privilegiati, ovvero di utenti che attraverso la VPN hanno accesso a diversi sistemi, anche critici, Ã¨ stato predisposto un active channel. Tale active channel Ã¨ basato sulla rule â''VPN Authentication Failedâ', combinando il nome dellâ''utente con una active list appositamente predisposta e popolata a mano, contenente gli utenti privilegiati. 5.5.3 Reportistica 5.5.3.1 Utilizzo della VPN Ã' stato predisposto un report, eseguito giornalmente, che mostra le connessioni degli utenti alla rete regionale attraverso VPN, in modo da poter evidenziare eventuali comportamenti anomali. Per ogni connessione, il report mostra il nome utente, lâ''ip di provenienza, i timestamp di inizio connessione e di fine connessione. 5.5.3.2 Modifica delle configurazioni degli utenti Ã' stato predisposto un report, eseguito settimanalmente, che mostra una lista di tutti gli utenti creati, modificati e cancellati, contenente il timestamp dellâ''o- perazione, lâ''amministratore che ha effettuato la modifica e il sistema su cui la modifica Ã¨ stata effettuata. 5.5.3.3 Monitoraggio delle sessioni amministrative Ã' stato predisposto un report, eseguito settimanalmente, che mostra, per ogni amministratore e per ogni sistema amministrato, il numero di connessioni effet- tuate ogni giorno del periodo di riferimento del report. Tale report ha anche lo scopo di essere utilizzato nellâ''ambito delle verifi- che dellâ''operato degli amministratori di sistema, richieste dal provvedimento del garante per la protezione dei dati personali relativo agli amministratori di sistema. 5.6 Attacchi sulla rete La categoria di eventi di interesse legate ad attacchi sulla rete ha lâ''obiettivo di individuare scansioni di rete e presenza di malware. 5.6.1 Regole di correlazione Allâ''interno dellâ''ESM Ã¨ possibile individuare eventi di attacchi sulla rete moni- torando gli eventi provenienti soprattutto da firewall e IPS. 81 CAPITOLO 5. REALIZZAZIONE DEL SISTEMA DI MONITORAGGIO Gli eventi provenienti da firewall sono caratterizzati dal valore /Firewall contenuto allâ''interno del campo categoryDeviceGroup e dal valore /Access con- tenuto allâ''interno del campo categoryBehavior. Il campo categoryOutcome con- terrÃ /Success o /Failure a seconda che il firewall abbia accettato o bloccato la connessione. Gli eventi provenienti da IPS sono caratterizzati dal valore /IDS/Network contenuto allâ''interno del campo categoryDeviceGroup e dai valori Permit o Block contenuti allâ''interno del campo deviceAction, a seconda che il pacchetto sia stato solo segnalato o anche bloccato. I campi categoryBehavior e categoryOutcome possono contenere diversi valori a seconda dal tipo di minaccia o attacco rilevato. 5.6.1.1 Alto numero di connessioni negate Si vuole generare un evento correlato ogni qualvolta si hanno piÃ¹ di 900 tentativi di connessione negate in 1 minuto da parte di host esterni verso un singolo host interno su porte udp differenti maggiori della 1024. Per generare tali eventi Ã¨ stata definita la rule â''High Number of Denied Connections â': ( Type = Base AND Category Behavior = /Access AND Category Device Group =
/Firewall AND Category Object = /Host/Application/Service AND Category Outcome
= /Failure AND NotInActiveList("Event-based Rule Exclusions") ) Aggregate if at least 900 matching conditions are found within 1 Minutes AND these event fields are the same (event1.Category Object, event1.Device Product, event1.Category Device Group, event1.Attacker Zone Resource, event1.Device Address, event1.Attacker Address, event1.Category Behavior, event1.Category Outcome, event1.Device Vendor, event1.Device Host Name, event1.Device Zone Resource, event1.Attacker Host Name) Figura 5.6.1: Rule: High Number of Denied Connections La rule cosÃ¬ creata genererÃ un evento correlato al raggiungimento della soglia impostata. 5.6.1.2 Connessioni in outbound su porte differenti Si vuole generare un evento correlato ogni qualvolta si hanno piÃ¹ di 100 tentativi di connessione in un minuto da parte di host interni verso un singolo host esterno su porte udp differenti maggiori della 1024. Per generare tali eventi Ã¨ stata definita la rule â''Firewall Network Port Scanâ': 82 CAPITOLO 5. REALIZZAZIONE DEL SISTEMA DI MONITORAGGIO ( ( Category Behavior = /Access OR Category Behavior = /Access/Start ) AND
Category Device Group = /Firewall AND Category Outcome = /Success AND
NotInActiveList("_Test Trusted") AND ( NotInActiveList("_RER Suspicious List") OR
NotInActiveList("_Test Scanned List") ) AND Attacker Zone URI StartsWith
/All Zones/Site Zones/ AND NotTarget Zone URI StartsWith /All Zones/Site Zones/
AND NotAttacker Port <= 1024 ) Aggregate if at least 100 matching conditions are found within 2 Minutes AND these event fields are unique (Allow_TCP_UDP.Target Port) AND these event fields are the same (Allow_TCP_UDP.Target Address, Allow_TCP_UDP.Attacker Zone Resource, Allow_TCP_UDP.Username, Allow_TCP_UDP.Target Zone Resource, Allow_TCP_UDP.Attacker Address) Figura 5.6.2: Rule: Firewall Network Port Scan La rule cosÃ¬ creata genererÃ un evento correlato al raggiungimento della soglia impostata. Sullâ''evento correlato vengono impostati i seguenti valori per i campi: categoryBehavior: /Access categoryDeviceGroup: /Security Information Manager categoryObject: /Network categoryOutcome: /Attempt categoryTechnique: /Scan/Port categoryDeviceCustomString1: $Username categoryDeviceCustomString1Label: Username La variabile $Username, assegnata al campo categoryDeviceCustomString1, Ã¨ valorizzata andando a prelevare il valore del nome utente associato allâ''indirizzo IP da cui Ã¨ partito lâ''attacco da una lista che tiene associato in tempo reale, basandosi sui dati della navigazione degli utenti, un certo ip con nome utente. 5.6.2 Strumenti di monitoraggio Gli strumenti predisposti per il monitoraggio di attacchi sulla rete, consistono in alcuni active channel basati sulle regole create e in alcune dashboard in cui viene visualizzato, attraverso liste e grafici aggiornati in realtime, un compendio significativo degli eventi di interesse provenienti da firewall e IPS. 5.6.2.1 Overview degli eventi provenienti dal firewall Si vuole predisporre una dashboard che permetta di visualizzare in forma grafica e in real time unâ''overview degli eventi provenienti dal firewall. Sono stati innanzi tutto definiti i due filtri â''Denied Inbound Connectionsâ', per ottenere le connessioni dalla rete esterna alla rete regionale bloccate dal firewall e â''Denied Outbound Connectionsâ', per ottenere le connessioni dalla rete regionale alla rete esterna. I due filtri sono mostrati in figura: 83 CAPITOLO 5. REALIZZAZIONE DEL SISTEMA DI MONITORAGGIO ( Category Behavior = /Access AND Category Device Group = /Firewall AND Category
Object = /Host/Application/Service AND Category Outcome = /Failure AND ( Device
Direction = Inbound OR MatchesFilter("Inbound Events") ) ) ( Category Behavior = /Access AND Category Device Group = /Firewall AND Category Object = /Host/Application/Service AND Category Outcome = /Failure AND ( Device Direction = Outbound OR MatchesFilter("Outbound Events") ) ) Figura 5.6.3: Filtri: Denied Inbound Connections e Denied Outbound Connections I filtri â''Inbound Eventsâ' e â''Outbounds Eventsâ', utilizzati per la creazione dei filtri precedenti, permettono di ottenere eventi il cui ip di provenienza sia interno o esterno alla rete dellâ''organizzazione. Partendo dai due filtri sono state creati data monitor di tipo â''Last N eventsâ', che permettono di visualizzare una lista degli ultimi N eventi che soddisfano un filtro, e data monitor di tipo â''Top Value Countsâ', che permettono di visualizzare un grafico con gli N oggetti per il quali il filtro Ã¨ stato soddisfatto. Tali data monitor sono stati combinati per ottenere una dashboard, che ha un aspetto del tipo mostrato in figura. Figura 5.6.4: Dashboard: Firewall Overview 5.6.2.2 Overview degli eventi provenienti dallâ''IPS Si vuole predisporre una dashboard che permetta di visualizzare in forma grafica e in realtime unâ''overview degli eventi provenienti dallâ''IPS. Ã' stato innanzi tutto definito il filtro â''IDS - IPS Eventsâ', per ottenere gli eventi provenienti dal sistema IPS. Il filtro Ã¨ mostrato in figura: 84 CAPITOLO 5. REALIZZAZIONE DEL SISTEMA DI MONITORAGGIO ( Category Device Group StartsWith /IDS AND Category Device Group != /IDS/Host/Antivirus ) Figura 5.6.5: Filtro: IDS - IPS Events Partendo da tale filtro sono state creati data monitor di tipo â''Top Value Counts â', che permettono di visualizzare un grafico o una tabella con gli N oggetti per il quali il filtro Ã¨ stato soddisfatto. Tali data monitor sono stati combinati per ottenere una dashboard, che ha un aspetto del tipo mostrato in figura. Figura 5.6.6: Dashboard: IPS Overview 5.6.3 Reportistica 5.6.3.1 Uso di protocolli in chiaro in outbound Ã' stato predisposto un report, eseguito giornalmente, che mostra lâ''utilizzo in outbound di protocolli in chiaro, quali ad esempio lâ''ftp. Il report contiene indirizzo e nome host sorgente, indirizzo e nome host destinatario, la porta di destinazione e il numero di eventi. 5.6.3.2 IP interni bloccati Ã' stato predisposto un report, eseguito settimanalmente, che mostra i principali IP interni bloccati. Il report contiene indirizzo sorgente, indirizzo di destinazione e il numero di pacchetti bloccati. 85 CAPITOLO 5. REALIZZAZIONE DEL SISTEMA DI MONITORAGGIO 5.6.3.3 IP esterni bloccati Ã' stato predisposto un report, eseguito settimanalmente, che mostra i principali IP esterni bloccati. Il report contiene indirizzo sorgente, indirizzo di destinazione e numero di pacchetti bloccati. 5.6.3.4 Principali alert da IDS / IPS Ã' stato predisposto un report, eseguito giornalmente, che mostra i principali alert provenienti da IPS. Il report contiene la signature rilevata, la sua descri- zione e il numero di occorrenze. 5.7 Attacchi e malware a livello host La categoria di eventi di interesse legate ad attacchi e malware a livello host ha lâ''obiettivo di individuare host che possono essere infetti o compromessi. 5.7.1 Regole di correlazione Allâ''interno dellâ''ESM Ã¨ possibile individuare host compromessi monitorando gli eventi provenienti dal sistema antimalware o dal sistema IPS. Gli eventi provenienti da firewall sono caratterizzati dal valore /IDS/Ho- st/Antivirus contenuto allâ''interno del campo categoryDeviceGroup. Gli eventi provenienti da IPS sono caratterizzati dal valore /IDS/Network contenuto allâ''interno del ramo categoryDeviceGroup e dai valori Permit o Block contenuti allâ''interno del campo deviceAction, a seconda che il pacchetto sia stato solo segnalato o anche bloccato. I campi categoryBehavior e categoryOutcome possono contenere diversi valori a seconda dal tipo di minaccia o attacco rilevato. 5.7.1.1 Malware rilevato ma non rimosso Si vuole generare un evento correlato ogni qualvolta un malware su un host viene rilevato dal sistema anti malware, ma questâ''ultimo non riesce a rimuoverlo. Per generare tali eventi Ã¨ stata definita la rule â''Antivirus Unsuccessfull Clean â': ( Category Device Group = /IDS/Host/Antivirus AND Device Custom String5 Contains
unsuccessful AND Device Custom String6 Contains unsuccessful ) Aggregate if at least 1 matching conditions are found within 2 Minutes AND these event fields are the same (event1.Device Custom String5, event1.Device Custom String6, event1.File Name, event1.File Path, event1.Name, event1.Target Address, event1.Target Zone Resource, event1.Target Host Name) Figura 5.7.1: Rule: Antivirus Unsuccessfull Clean 86 CAPITOLO 5. REALIZZAZIONE DEL SISTEMA DI MONITORAGGIO La rule cosÃ¬ creata genererÃ un evento correlato al primo evento che soddisfa la regola. Oltre a impostare lâ''evento correlato si andrÃ a popolare unâ''active list con i seguenti campi: Target Address Target Zone Name File Name File Path Timestamp 5.7.1.2 Worm Rilevato Si vuole definire una regola di correlazione che abbia lo scopo di rilevare malware per il quale non sia stata ancora rilasciata la relativa signature allâ''interno dei sistemi IPS. Ã' stato innanzi tutto definito il filtro: ( Target Port != 8443 AND Attacker Address Is NOT NULL AND Target Port Is NOT NULL AND Not( Attacker Asset ID InGroup("/All Asset Categories/Site Asset Categories/Application/Type/Domain Name Server/") Or Attacker Asset ID InGroup("/All Asset Categories/Site Asset Categories/Application/Type/Email/") Or Attacker Asset ID InGroup("/All Asset Categories/Site Asset Categories/Application/Type/Proxy/") ) ) Figura 5.7.2: Filter: Target Port Activity By Attacker Il filtro Ã¨ stato poi utilizzato allâ''interno di un data monitor di tipo moving average, denominato anchâ''esso â''Target Port Activity By Attackerâ'. Un data monitor di tipo â''moving averageâ' calcola lâ''ammontare medio di eventi in un in- tervallo di tempo specificato. Il data monitor â''Target Port Activity by Attackerâ' utilizza il filtro in fig. 5.7.2, raggruppando i campi â''Target Portâ' e â''Attacker
Address â' per calcolare lâ''utilizzo medio di una porta target per un attaccante e generare un evento correlato avente lo stesso nome del data monitor se lâ''utilizzo medio cambia del 100% nellâ''intervallo di tempo configurato per uno di questi gruppi. Sono state poi definite due rule, â''Possible Outbound Network Sweepâ' e â''Pos- sible Inbound Network Sweep â' che generano eventi correlati nel caso di sospetti network sweep. 87 CAPITOLO 5. REALIZZAZIONE DEL SISTEMA DI MONITORAGGIO ( Type != Correlation AND Attacker Address Is NOT NULL AND Device Product !=
ArcSight AND Device Vendor != ArcSight AND Target Address Is NOT NULL AND
Target Port Is NOT NULL AND Not( Attacker Asset ID InGroup("/All Asset
Categories/Site Asset Categories/Application/Type/Domain Name Server/") Or
Attacker Asset ID InGroup("/All Asset Categories/Site Asset
Categories/Application/Type/Email/") Or Attacker Asset ID InGroup("/All Asset
Categories/Site Asset Categories/Application/Type/Proxy/") ) AND Category
Behavior != /Access/Stop AND MatchesFilter("Internal to Internal Events") ) ( Type != Correlation AND Attacker Address Is NOT NULL AND Device Product != ArcSight AND Device Vendor != ArcSight AND Target Address Is NOT NULL AND Target Port Is NOT NULL AND Not( Attacker Asset ID InGroup("/All Asset Categories/Site Asset Categories/Application/Type/Domain Name Server/") Or Attacker Asset ID InGroup("/All Asset Categories/Site Asset Categories/Application/Type/Email/") Or Attacker Asset ID InGroup("/All Asset Categories/Site Asset Categories/Application/Type/Proxy/") ) AND Category Behavior != /Access/Stop AND MatchesFilter("Outbound Events") ) Figura 5.7.3: Rules: Possible Outbound Network Sweep e Possible Inbound Network Sweep Gli eventi correlati generati dal data monitor e dalle rule vengono infine utilizzati per la definizione della join rule â''Worm Outbreakâ': Matching Event: ( event1.Attacker Zone = event2.Attacker Zone AND event1.Attacker
Address = event2.Attacker Address AND event1.Target Port = event2.Target Port ) event1 : ( NotInActiveList("Worm Infected Systems") AND ( Name =
Possible Internal Network Sweep OR Name = Possible Outbound Network Sweep ) AND
Type = Correlation AND Device Product = ArcSight AND Device Vendor = ArcSight ) event2 : ( Name = Target Port Activity by Attacker [ignore case] AND Type =
Correlation AND Device Event Category StartsWith
/datamonitor/movingaverage/threshold/rising [ignore case] AND Device Custom
Number1 > 100 AND Device Custom Number2 > 1 AND NotInActiveList("Worm
Infected Systems") ) Aggregate if at least 1 matching conditions are found within 10 Minutes AND these event fields are the same (event1.Attacker Asset Resource, event1.Target Port, event1.Attacker Zone Resource, event1.Attacker Address, event1.Customer Resource, event1.Attacker Zone) Figura 5.7.4: Rule: Worm Outbreack La join rule cosÃ¬ creata ha lo scopo di individuare casi in cui da un attaccante aumenti il traffico verso un certo target (ip e porta) e contemporaneamente venga effettuato un network sweep verso il medesimo target. La rule genererÃ un evento correlato al primo evento che soddisfa la regola. Oltre a impostare lâ''evento correlato si andrÃ a popolare unâ''active list con i seguenti campi: Attacker Zone 88 CAPITOLO 5. REALIZZAZIONE DEL SISTEMA DI MONITORAGGIO Attacker Address
Target Port
Lâ''evento correlato generato dalla rule avrÃ i seguenti campi impostati:
categoryBehavior: /Communicate categoryDeviceGroup: /Security Information Manager categoryObject: /Host/Infection/Worm categoryOutcome: /Success categorySignificance: /Compromise priority: 10 5.7.2 Strumenti di monitoraggio 5.7.2.1 Overview dei sistemi antivirus Si vuole predisporre una dashboard che permetta di visualizzare in forma grafica e in realtime unâ''overview degli eventi provenienti dal sistema antimalware. Ã' stato innanzi tutto definito il filtro â''Virus Activityâ', per ottenere gli eventi provenienti dal sistema IPS. Il filtro Ã¨ mostrato in figura: ( ( Category Object StartsWith /Vector/Virus OR Category Object StartsWith /Host/Infection/Virus ) OR ( ( Category Behavior StartsWith /Modify/Content OR Category Behavior = /Found/Vulnerable OR Category Behavior StartsWith /Modify/Attribute OR Category Behavior = /Delete ) AND Category Device Group = /IDS/Host/Antivirus AND Device Custom String1 Is NOT NULL ) ) Figura 5.7.5: Filtro: Virus Activity Partendo da tale filtro sono stati creati data monitor di tipo â''Event Graphâ', che permettono di visualizzare un grafico dellâ''attivitÃ dei virus e data monitor di tipo â''Moving Averageâ', che permettono di visualizzare gli incrementi, rispetto al valore medio, del numero di host sui quali Ã¨ stato rilevato un malware. 5.7.3 Reportistica 5.7.3.1 Sorgenti di malware Ã' stato predisposto un report che mostra una lista di host soggetta ad un certo malware, raggruppato per il malware rilevato. 5.7.3.2 Malware rilevato Ã' stato predisposto un report che mostra la lista dei malware rilevati e, per ognuno di essi, il numero di occorrenze riscontrate. 5.8 Attacchi alle applicazioni web La categoria di eventi di interesse legate ad attacchi alle applicazioni web ha lâ''obiettivo di individuare attacchi rivolti alle applicazioni web. Va in ogni caso 89 CAPITOLO 5. REALIZZAZIONE DEL SISTEMA DI MONITORAGGIO considerato che per rilevare questo genere di attacchi sono piÃ¹ efficaci altri strumenti quali application firewall o IDS. 5.8.1 Regole di correlazione Allâ''interno dellâ''ESM Ã¨ possibile individuare gli attacchi alle applicazioni web monitorando gli eventi provenienti dai web server che costituiscono il frontend delle applicazioni web. Gli eventi provenienti da firewall sono caratterizzati dal valore del campo Request URL non nullo. 5.8.1.1 Directory traversal Si vuole generare un evento correlato ogni qualvolta venga individuato un at- tacco di tipo â''directory traversalâ', ovvero il caso in cui un attaccante cerchi di â''uscireâ' dal contesto dellâ''applicazione per arrivare sul filesystem del server che funge da server web. Allâ''interno dellâ''ESM Ã¨ possibile rilevare attacchi di questo tipo monitorando gli eventi provenienti dai web server che fanno da frontend per le applicazioni web (bilanciatori, reverse proxy, ecc.). Per generare questi eventi Ã¨ stato innanzi tutto definito il filtro â''Web Appli- cation â': ( Request Method Is NOT NULL AND Device Vendor NOT Contains Squid ) Figura 5.8.1: Filtro: Web Application La definizione del filtro esclude gli eventi provenienti dai web proxy, in quanto anche essi hanno il campo Request Method non nullo. A partire dal filtro appena definito viene definita la rule â''Web Attackâ': ( MatchesFilter("_RER Web Application") AND Request Url Contains ../../.. ) Aggregate if at least 1 matching conditions are found within 1 Minutes AND these event fields are the same (event1.Target Address, event1.Attacker Zone Resource, event1.Attacker Address, event1.Target Zone Resource) Figura 5.8.2: Rule: Web Attack La rule cosÃ¬ creata genererÃ un evento correlato al primo evento che la sod- disfa e inoltre andrÃ a popolare unâ''active list con lâ''ip dellâ''attaccante, il target e lâ''url richiesto. 90 Capitolo 6 Conclusioni Il lavoro svolto ha riguardato la realizzazione di un sistema di monitoraggio della sicurezza informatica mediante il modello SIEM allâ''interno della Regio- ne Emilia-Romagna. I risultati ottenuti hanno permesso di constatare come un SIEM, adeguatamente configurato per tenere conto delle caratteristiche del siste- ma informatico dellâ''organizzazione, dei dati disponibili e dei rischi individuati, possa rappresentare un valido strumento a disposizione di un Security Operation Center di unâ''organizzazione complessa, utile per il monitoraggio real-time della sicurezza dellâ''infrastruttura informatica e per la generazione di reportistica dei sistemi e delle applicazioni. Tale risultato avviene mediante lâ''acquisizione, la conservazione e lâ''elabora- zione delle informazioni contenute allâ''interno dei log. Ogni dispositivo o applica- zione, infatti, genera log con informazioni utili a identificare e gestire situazioni rilevanti per la sicurezza e il funzionamento dei sistemi. Lâ''importanza dei log ha portato allo sviluppo di pratiche per la gestione e lâ''utilizzo degli stessi log che in molti casi sono anche state tradotte in norme alle quali le aziende dotate di siste- mi IT si devono attenere (es. SOX, PCI, normativa italiana sul controllo degli amministratori di sistema). I log di dispositivi e applicazioni, pur contenendo potenzialmente un notevole patrimonio informativo, vengono normalmente ana- lizzati solo successivamente al verificarsi di incidenti o malfunzionamenti, allo scopo di capire le cause di quanto successo. Lâ''esigenza da cui parte un corretto processo di log management Ã¨ quella di estrarre da questa grande mole di dati presente allâ''interno dellâ''organizzazione le informazioni necessarie a garantire la sicurezza dei sistemi informatici in maniera proattiva. AffinchÃ© questo processo sia portato a termine correttamente occorre imple- mentare unâ''infrastruttura complessa con strumenti che si occupino della corretta acquisizione, conservazione, analisi e correlazione dei log, della reportistica e del- la ricerca. La complessitÃ del processo fa sÃ¬ che non sia sufficiente lâ''installazione e la configurazione di uno dei prodotto SIEM commerciali o open source presenti sul mercato. La corretta configurazione del sistema Ã¨ basata sullâ''individuazione di eventi di interesse, ovvero di eventi che possono costituire una minaccia o requisiti di 91 CAPITOLO 6. CONCLUSIONI business; affinchÃ© tali eventi di interesse siano individuati correttamente Ã¨ ne- cessario che lâ''organizzazione abbia operato una seria analisi dei rischi e definito politiche di sicurezza. Nel caso della Regione Emilia-Romagna, come descritto allâ''interno della tesi, entrambi i requisiti erano soddisfatti. Altro prerequisito essenziale per la fase di messa in opera del SIEM Ã¨ la presenza di un modello per la corretta categorizzazione degli asset. Nel caso della Regione Emilia-Romagna tali informazioni sono presenti allâ''interno del CMDB. Per la realizzazione del sistema di monitoraggio della sicurezza informatica allâ''interno della Regione Emilia-Romagna sono state necessarie diverse fasi. Individuazione dellâ''architettura . Lâ''architettura scelta Ã¨ quella di un sistema agentless con connettori concentrati su alcuni sistemi. I connettori inviano gli eventi filtrati, aggregati e normalizzati al sistema di log management, il quale firma gli eventi ricevuti e li immagazzina in un database; a sua volta il log manager invia gli eventi al sistema di log correlation, che li analizza e attiva gli strumenti di monitoraggio e reportistica configurati. Individuazione delle sorgenti di eventi. Per ogni sorgente di eventi Ã¨ stato individuata la forma migliore di integrazione, configurando di conseguenza i connettori con il sistema di log management ed il SIEM. Modellazione della rete e degli asset . Le informazioni su zone di rete, su- gli asset e la loro categorizzazione, contenute allâ''interno del CMDB, sono state riportate sul SIEM, impostando anche meccanismi di sincronizzazione automa- tica. Sul SIEM sono state inoltre riportate le informazioni sulle vulnerabilitÃ che colpiscono i vari asset, impostando meccanismi di importazione automatica dei risultati dei report dei vulnerability assessment svolti periodicamente. Individuazione di eventi di interesse e definizione di strumenti specifici. So- no stati definiti eventi di interesse appartenenti alle categorie: autenticazione degli utenti, attacchi sulla rete, attacchi e malware a livello host, attacchi al- le applicazioni web. Per ogni evento di interesse sono state costruite regole di correlazione, strumenti di monitoraggio e reportistica, sia operativi, a disposi- zione degli operatori del SOC e analisti della sicurezza, sia di piÃ¹ alto livello, a disposizione del management. Possibili sviluppi futuri del lavoro svolto, oltre allâ''individuazione di ulteriori eventi di interesse e la conseguente definizione di strumenti di monitoraggio specifici, sono la realizzazione di workflow per la gestione degli alert aperti dal sistema di monitoraggio della sicurezza, lâ''integrazione con il workflow di gestione degli incidenti di sicurezza, lâ''integrazione del SIEM con il sistema di trouble ticketing della Regione Emilia-Romagna. 92 Bibliografia 1. Guide to Computer Security Log Management - NIST Special Publica- tion 800-92 - September 2006 (cap. 1,2) http://csrc.nist.gov/publications/nistpubs/800-92/SP800-92.pdf 2. Sicurezza aziendale e continuitÃ del business - Giuseppe Saccardi, Gae- tano Di Blasio, Riccardo Florio - Reportec - 2010 (cap. 1) 3. Sicurezza in informatica - Charles P. Pfleeger, Shari Lawrence Pfleeger - Pearson Prentice Hall - 2008 - ISBN 978-88-7192-363-5 (cap. 1) 4. Successful SIEM and Log Management Strategies for Audit and Com- pliance - David Swift - SANS Institute InfoSec Reading Room - November 2010 - (cap. 1,2,5) http://www.sans.org/reading_room/whitepapers/auditing/successful-siem- log-management-strategies-audit-compliance_33528 5. A Practical Application of SIM/SEM/SIEM Automating Thread Iden- tification - David Swift - SANS Institute InfoSec Reading Room - Decem- ber 2006 - (cap. 1,5) http://www.sans.org/reading_room/whitepapers/logging/practical-application- sim-sem-siem-automating-threat-identification_1781 6. Keys to Implementing a Successfull Security Information Manage- ment Solution (or Centralized Security Monitoring) - Michael Martin - SANS Institute InfoSec Reading Room - December 2003 - (cap. 1) http://www.sans.org/reading_room/whitepapers/bestprac/keys-implementing- successful-security-information-management-solution-or-centralized-security_1303 7. Security Information and Event Management (SIEM) Implementa- tion - David R. Miller, Shon Harris, Allen A. Harper, Stephen Vandyke, Chris Blask - Mc Graw Hill - 2011 - ISBN 978-0-07-170109-9 (cap. 1,2,3) 93 APPENDICE . BIBLIOGRAFIA 8. Security Operation Center concepts & Implementation - Renaud Bi- dou - (cap. 2) http://www.iv2-technologies.com/SOCConceptAndImplementation.pdf 9. Disciplinare Tecnico per gli utenti del sistema informatico della Re- gione Emilia-Romagna - Dicembre 2011 (cap. 4) 10. Disciplinare Tecnico per amministratori di sistema della Regione Emilia- Romagna - Gennaio 2012 (cap.4) 11. Disciplinare Tecnico per la gestione degli incidenti di sicurezza infor- matica della Regione Emilia-Romagna - Marzo 2009 (cap. 4) 12. ESM 101: Concepts for Arcsight ESM - ArcSight - May 2010 (cap. 3,5) 13. ArcSight ESM User Guide - Arcsight - September 2011 (cap. 3,5) 14. ArcSight ESM Standard Content Guide - ArcSight - May 2009 (cap. 5) 94

Document Outline

I Gestione dei log mediante un System and Event Management La gestione dei log di sicurezza Introduzione Tipologie di log di sicurezza Software di sicurezza Sistemi operativi Applicazioni Gli scopi Monitoraggio della sicurezza L'analisi dei rischi VulnerabilitÃ e minacce Riconoscimento degli attacchi Compliance alle normative Le strategie Le sfide Gestione e registrazione dei log Protezione dei log Analisi dei log I modelli Il modello Syslog Il modello SIEM Architettura di un SIEM Generazione Collezionamento Registrazione e immagazzinamento Analisi Il Rule e il Correlation Engine La Knowledge Base Monitoraggio ArcSight ESM Architettura di Arcsight ESM Collezionamento I componenti I processi Registrazione I componenti Lo schema degli eventi Analisi La correlazione Rule Azioni Liste Knowledge base ArcSight Asset Model ArcSight Network Model Monitoraggio Active Channel Dashboard Query Viewer Reportistica e analisi degli incidenti Query Trend Report II Un caso di studio: la Regione Emilia-Romagna Gestione della sicurezza informatica Le policy di sicurezza Il sistema di verifiche Le soluzioni tecnologiche Sistemi firewall Sistemi anti malware Sistemi di Intrusion Prevention e Intrusion Detection Virtual Private Network Web Proxy I sistemi di autenticazione Il dominio Active Directory Il sistema di Identity and Access Management Il servizio RADIUS Il Configuration Management Database La gestione degli incidenti di sicurezza Realizzazione del sistema di monitoraggio Il sistema di log management Architettura del sistema di log correlation Modellazione della rete e degli asset Importazione delle zone Importazione degli asset e definizione delle categorie di asset VulnerabilitÃ degli asset Individuazione degli eventi di interesse Autenticazione degli utenti Regole di correlazione Tentativi ripetuti di login provenienti da una singola sorgente Tentativi ripetuti di login rivolti ad un singolo account Attacchi di forza bruta Errori di autenticazione sulla VPN Modifica delle configurazioni di utenti e host Accesso ai sistemi mediante account amministrativi non personali Strumenti di monitoraggio Monitoraggio di ripetuti login falliti e attacchi di forza bruta Monitoraggio degli eventi di autenticazioni sulla VPN Autenticazioni fallite sulla VPN da parte di utenti privilegiati Reportistica Utilizzo della VPN Modifica delle configurazioni degli utenti Monitoraggio delle sessioni amministrative Attacchi sulla rete Regole di correlazione Alto numero di connessioni negate Connessioni in outbound su porte differenti Strumenti di monitoraggio Overview degli eventi provenienti dal firewall Overview degli eventi provenienti dall'IPS Reportistica Uso di protocolli in chiaro in outbound IP interni bloccati IP esterni bloccati Principali alert da IDS / IPS Attacchi e malware a livello host Regole di correlazione Malware rilevato ma non rimosso Worm Rilevato Strumenti di monitoraggio Overview dei sistemi antivirus Reportistica Sorgenti di malware Malware rilevato Attacchi alle applicazioni web Regole di correlazione Directory traversal Conclusioni Bibliografia

Monitoraggio della sicurezza informatica mediante il modello SIEM in una organizzazione complessa

Document Outline

In evidenza

Articoli correlati

Dalla stessa azienda