SIEM: Casi d'uso e livelli di maturità

Transcript

1 SIEM: Casi d'uso e livelli di maturità Andrea Boggio Business Consultant CISA, CISM, CRISC, CGEIT, LA ISO27001, ITIL, ACP, FSE andrea.boggio@hp.com Security Summit Milano, 20/03/2014

2 SIEM Controllo e visibilità centralizzate Un SIEM offre visibilità centralizzata degli eventi generati all interno dell azienda Dispositivi di rete Dispositivi di sicurezza Physical Mobile Server Desktop Cloud IAM Databases CCTV Applicazioni 2

3 SIEM Una definizione Cos è Il termine Security Information Event Management (SIEM) è coniato da Mark Nicolett e Amrit Williams di Gartner nel 2005 e descrive le capability di prodotto di raccolta, analisi e presentazione delle informazioni dai dispositivi di rete e di sicurezza, dalle applicazioni di identity and access management, dagli strumenti di vulnerability management e policy compliance, dai log dei sistemi operativi, dei database e delle applicazioni e dalle sorgenti esterne di minacce; Combinazione di capability tecnologiche distinte: Log Management; Real-time Monitoring di eventi e incidenti di sicurezza; Strumento in grado di effettuare analisi in tempo reale degli allarmi di sicurezza e delle informazioni generate da sorgenti di log (di sicurezza e non); Sorgente di log = qualsiasi tecnologia in grado di produrre informazione digitale. 3

4 SIEM Un altra definizione Big data security analytics e soluzioni SIEM Simple Intelligent Efficient Manageable Time to Value accelerato Correlazione in tempo reale e analisi Engine ottimizzati per correlazione e storage Scalabilità enterprise Semplicità nella realizzazione, nella collezione, nell integrazione, nell utilizzo e nell esercizio. Analisi delle minacce, Big Data e processazione complessa degli eventi Storage dei dati efficiente, performance e capacità di recupero dell informazione ottimizzate Configurazione centralizzata dei contenuti, aggiornamenti, licensing, gestione degli utenti e dei ruoli 4

5 Driver principali Quantità enormi di dati di log in quotidiana crescita CyberSecurity Come fare a rilevare e investigare gli incidenti di sicurezza? Compliance Come essere certi di passare gli audit? IT Operations Come gestire i malfunzionamenti e fare troubleshooting nella propria rete? 5

6 CyberSecurity Minacce tipiche Bot, Worm e Virus APT Attacchi mirati Violazione delle policy Accessi applicativi non autorizzati C è bisogno di correlazione! 6

7 Compliance Manuale A rischio di errori e labor-intensive Impossibile assicurare compliance continua e protezione dalle intrusioni Semi-Automatica Processi di audit separati A rischio di errori e non continua Tutti i log Automatica Feed diretto degli eventi Approccio meno intrusivo e più completo per attività di audit continue e ad ampio spettro 7

8 IT Operations Driver principale: troubleshooting Ricerca di stringhe specifiche Alcuni allarmi sono basati sull informazione contenuta all interno dell evento Alcuni report sono basati sui requisiti del management o sugli SLA # less /var/log/messages grep EventID: 1354 Sep 2 15:33:53 gateway1 Server Administrator: Instrumentation Service EventID: 1354 Power supply detected a failure Sensor location: PS 2 Status Chassis location: Main System Chassis Previous state was: Unknown Power Supply type: AC Power Supply state: Presence detected, Failure detected, AC lost 8

9 SIEM\SOC Take Aways Alcuni spunti * SIEM come tecnologia di sicurezza, data management e data analysis; «Plan strategically, deploy tactically»; Non deve essere uno strumento stand-alone bensì parte di un programma di monitoraggio della sicurezza; Processi, procedure, flussi di lavoro, personale dedicato e competente; Centralità dei casi d uso; L architettura di contesto è fondamentale; La maturità di un SIEM e di un SOC richiede un commitment costante da parte dell organizzazione; Approccio di tipo output-driven; Un progetto SIEM non è realmente un progetto ma un processo e un programma al tempo stesso non si completa mai; È sempre necessario personale dedicato; I processi essenziali di sicurezza sono di due tipologie: monitoraggio in tempo reale e investigazioni ex-post. * «Security Information and Event Management Architecture and Operational Processes, Gartner Gennaio

10 Difficoltà comuni Fattori di insuccesso Complessità di deployment; Complessità di amministrazione; Complessità operativa; Difficoltà ad esprimere il pieno valore della soluzione; SIEM implementations often fail to deliver full value not due to broken tools, but due to broken processes and practices by the organization that owns and operates the SIEM tool. * * «Security Information and Event Management Architecture and Operational Processes, Gartner Gennaio

11 Livelli di Maturità

12 SIEM Maturity Scale 12

13 Approccio olistico Tecnologia, Persone, Processi Process Technology People Escalation 1 Router Firewall 2 Intrusion detection Web server 5 Level 1 Level 2 4 Engineer Incident Handler 6 Network & System Owners Case closed Proxy server ESM server 3 13

14 Transazione Impatto dei Casi d Uso Trasformazione SIEM Maturity Model Risk Management SI e OC Avanzati Monitoraggio delle sicurezza & Response Compliance Voglio iniziare a pensare al rischio in maniera più ampia. Mi serve qualcosa di semplice per garantire la conformità. Siamo stati attaccati e siamo finiti sui giornali. Mi serve qualcosa che mi aiuti. Devo mettere in sicurezza la mia azienda in un contesto fatto di cloud, mobility e social. Gestione operativa Coinvolgimento degli stakeholder C-Level 14

15 Esempio di Maturity Assessment 15 General Training Certifications Experience People Skill Assessments Career Path Leadership Mission Process Operational Process Analytical Process Business Process Technology SIEM Monitoring Architecture Correlation Monitored Security Technologies Information Lifecycle Management How many SOC analysts do you have per shift? What is your ratio of level-2 analysts to level-1? Do you have defined roles and responsibilities? Do you have documented R&R for teams you interact with? Do you have a dedicated SOC engineer? Who does your SOC support? What is the basic mission of your SOC? Are escalations to internal teams or external clients? Does your SOC conduct any incident response activities? Does your SOC have a documented mission statement? Do other teams know about the SOC mission? What SIEM do you use? Do you have a test implementation of your SIEM? How do you monitor infrastructure performance? (availability, throughout, latency, average > peak > surge) Do you monitor any of the product vendor monitoring consoles to supplement your SIEM? Maturity Level Level 0 - Incomplete 0 Level 1 - Performed 1 Level 2 - Managed 2 Level 3 - Defined 3 Level 4 - Measured 4 Level 5 - Optimizing 5

16 SOC Maturity Assessment Tech Process SOMM Level 2,50 2,00 1,50 1,00 0,50 0,00 People Business Company A Average Current Phase 1 Phase 2 Phase 3 Timeline 6 mos 1 yr 2 yr SOMM Target Use Cases Logging Perimeter, compliance Insider Threat, APT Application Monitoring Staffing Ad hoc 4 x L1, 1x L2 8 x L1, 2x L2 12 x L1, 2x L2, 2x L3 Coverage 8x5 8x5 12x7 24x7 Maturity Assessment Score Business 2.44 Mission 1.86 Accountability 1.21 Sponsorship 2.18 Relationship 2.15 Deliverables 3.00 Vendor Engagement 2.67 Facilities 1.27 People 1.82 General 1.98 Training 2.61 Certifications 1.58 Experience 2.00 Skill Assessments 0.88 Career Path 1.92 Leadership 1.50 Process 0.63 General 2.01 Operational Process 1.67 Analytical Process 0.00 Business Process 0.00 Technology Process 0.00 Technology 2.60 Architecture 1.54 Data Collection 3.69 Monitoring 1.50 Correlation 1.37 General 2.13 Overall SOM Level

17 Project and Capability timeline Verifica e Design Sviluppo Implementazione Operatività Transizione Capability Go-live delle operazioni di sicurezza Capability inziale di monitoraggio Skills Assessment Maturity Assessment 17 Live data Sviluppo contenuti Training Data Onboarding Roadmap Assessment Livello di effort

18 Metriche operative

19 Cosa potrebbero dire i dati 1. Gli eventi orari per ogni analista sono troppi oppure troppo pochi 2. 99% di tutto il volume di traffico viene generato da due dispositivi 3. Il team sta gestendo oggi un volume di dati 5 volte maggiore rispetto a 1 anno fa 4. Gli incidenti dovuti al malware stanno aumentando in fretta 5. Un analista apre ogni case con priorità alta 6. Il tempo di riconoscimento di un evento è inferiore a 60 minuti 19

20 Perchè misurare? Metriche e misure sono parte essenziale di un SOC Fornire visibilità Dimostrare il Ritorno d Investimento (ROI) Facilitare il miglioramento continuo Costruire casi di business Supporto per due diligence Promuovere il raggiungimento dei risultati 20

21 Cose da guardare Efficacia Efficienza Quanti dati stanno arrivando? Quanto e cosa sta venendo fuori? Eventi grezzi ( raw ) Eventi correlati Quanti punti vengono controllati Incidenti / Casi Quanti casi d uso Raggiungimento degli SLA Aggiungere il contesto Per ore/giorni/mesi Per analista Per incidente/caso/ severity Per business unit Quanto è veloce la gestione? Riconoscimento degli eventi Escalation Risoluzione 21

22 Processo di analisi dei log di un SOC Questo IP sta facendo altre cose? Altri log Questa porta è aperta? port scan Cos è installato su questo sistema? asset inventory L attacco è effettivamente tale? payload Per cose viene usato? port lookup Come funziona l attacco? Dettagli della signature Va avanti da molto tempo? Contesto storico Che altro succede? Eventi concorrenti : :1433 SQL Injection Attack 23Mar :003 user=jones 22 traceroute Che sistemi vengono chiamati? Da dove viene? nslookup vulnerability scan Questo sistema è vulnerabile? ITAM Chi gestisce questo sistema? Ci sono cambiamenti in corso? Analisi del traffico IDAM Qual è lo stato di questo utente? Qual è il timing? address book Cosa fa questa persona?

23 Gestire, misurare, migliorare Chiamate e Ticket CERT, Severity, Categorie Intelligence quotidiana Situational awareness Report settimanali delle minacce Panorama delle minacce Report esecutivi mensili Visibilità agli executive 23

24 Esempi di report mensili «C-Level» 24

25 Key Performance Indicator

26 Esempio di KPI 1 Numero di eventi/ Numero di eventi per sorgente Perchè: Base per molti altri KPI Il trend mostra la qualità della gestione degli eventi Sorgenti dati: Tutte Come: Log Mgmt: Report quotidiani per contare gli eventi SIEM: Trend con report on top 26

27 Esempio di KPI 2 Numero di login falliti di utenti privilegiati Perchè: Potenziali pericoli per la sicurezza Sorgenti dati: Sistemi Operativi Applicazioni Server di autenticazione Come: Log Mgmt: Report usando i nomi degli utenti nelle query SIEM: Report tramite active list popolate, ad esempio, dall integrazione con AD 27

28 Esempio di KPI 3 Numero di incidenti di sicurezza Perchè: Base per altri KPI Mostra il trend degli incidenti di sicurezza Sorgenti dati: SIEM Service Desk, Ticketing System Come: Log Mgmt: applicabile se integrato con il sistema di ticket SIEM: applicabile se viene usato per il case management o se è integrato con il sistema di ticket 28

29 Esempio di KPI 4 Numero di indirizzi IP non autorizzati, porte e tipologie di traffico negate Perchè: Mostra le violazioni di sicurezza Indicatore di successo delle attività di awareness Sorgenti dati: Firewall e router con ACL IDS/IPS Come: Log: Report MGMT: Report tramite active list e zone 29

30 Case Study Evoluzione di un SIEM

31 Contesto di riferimento L attuale infrastruttura abilita sia i servizi di conformità alle leggi/normative italiane (Log Management) sia quelli relativi monitoraggio degli eventi di sicurezza (Correlation): Il perimetro Compliance (Log Management) è definito dalla normativa di riferimento, che determina anche modalità e tempi di conservazione minimi dei dati raccolti; Il perimetro Sicurezza (Correlation) è rappresentato dalle sonde di Intrusion Detection Systems, attestate sui segmenti di rete critici, e da altre sorgenti di log di sicurezza (Firewall, Domain Controller, AntiVirus). 31

32 Obiettivi e risultati attesi Gli obiettivi principali sono: consolidamento e potenziamento dell infrastruttura; innalzamento del livello di maturità del SIEM. I driver di trasformazione dell attuale infrastruttura sono molteplici: Armonizzazione con i progetti di consolidamento e virtualizzazione; refresh tecnologico piattaforma SIEM; integrazione del nuovo perimetro; miglioramento di efficienza ed efficacia della componente di Correlation. Il perimetro Compliance verrà alimentato tramite l integrazione con la nuova corporate, unitamente alle normali attività day by day. Il perimetro Sicurezza verrà notevolmente aumentato tramite la definizione di Use Case specifici e la correlazione di eventi generati dai sistemi di monitoraggio della sicurezza presenti. 32

33 Sorgenti di Log Ambito Sistema - Ruolo Tipo di log - Informazioni nel log Tipologia raccolta Modalità raccolta Numerosità sorgenti EPS medi stimati MS_Windows Domain Controller EventView Security: log on-off PULL WMI IBM RACF RACF RACF for z/os file: log on-off PUSH SFTP Digital Vault Gestione utenze locali privilegiate Syslog: operazioni delle utenze amministrative, logon-logoff, orario PUSH SYSLOG Oracle DB DB Oracke File pclogdw_ora PUSH SCP Microsoft File Server File Server Audit Log su operazioni effettuate su file e directory PULL WMI Sistemi Unix Unix Syslog: operazioni delle utenze amministrative, logon-logoff, sudo, cron, orario PUSH SYSLOG VDI DHCP VDI DHCP: New lease, released, renewed PUSH Connettore installato su server RADIUS Firewall Firewall Centrali Eventi IPS: Vulnerabilità, sistemi interessati, orario PUSH SYSLOG

34 Casi d uso attuali 1 di 2 MS Windows Accessi di tutte le utenze del dominio; IBM RACF Accessi degli amministratori di sistema dei Mainframe; Digital Vault Accessi locali degli amministratori di sistema sui server Microsoft e Unix; Indirizzamento NAC & Accesso NAC Informazioni utili alla ricostruzione di un identità a fronte di un evento rischioso; Sistemi Unix Accessi degli amministratori di sistema Unix; VDI Informazioni DHCP dell ambiente VDI; 34

35 Casi d uso attuali 2 di 2 Firewall Log di sicurezza generati dai firewall (UTM, AV, IPS, clean-up rules, etc); Oracle DB Accessi degli amministratori del database; Microsoft File Server Audit delle operazioni di Read, Write, List, Modify e Delete di file e cartelle sui File Server individuati. 35

36 Esempi di caso d uso base e avanzati 36

37 Mappare i requisiti di business sui casi d uso Stakeholder Requisiti di business Casi d Uso Sorgenti dati CISO Misura della security posture Report e dashboard mensili di alto livello verso o da host o domini malevoli noti Security Operations Compliance Identificare exploit 0-day e perdita di dati sensibili Mantenere la compliance alla PCI (sezione 10) Monitoraggio e rilevazione delle APT Collezionare, conservare I log di sicurezza e fare analisi per eventuali violazioni Firewall IDS/IPS Antivirus Authentication Vulnerability Scanner Frodi Controllare gli account di vendor/partner per attività fraudolente Controllare attività e transazioni sospette 37

38 Perimetro Caso d Uso Sorgenti di log principali Criteri di allarme Azione Attività Botnet Firewall, IDS, Proxy, Mail, Threat Intelligence Connessione verso o da host o domini malevoli noti Visualizzazione nell active channel dell analista Virus outbreak Antivirus 3 virus rilevati con lo stesso nome in 10 minuti Attivazione del supporto antivirus / visualizzazione su dashboard Attacco / Codice malevolo IDS/IPS, Vulnerability L asset attaccato ha una vulnerabilità con relevance=10 Attivazione del gruppo di supporto / Visualizzazione nell active channel dell analista / visualizzazione su dashboard SQL injection Web Server, DAM, IDS/IPS 5 tentativi di injection in una specifica finestra temporale Visualizzazione nell active channel dell analista Phishing Threat Intelligence, Firewall, IDS, Proxy, Mail Connessione verso o da host o domini malevoli noti Visualizzazione nell active channel dell analista Accesso remoto non autorizzato VPN, Applicazioni Autenticazione avvenuta con successo da parte di un membro esterno al dominio Visualizzazione nell active channel dell analista / attivazione del gruppo di supporto Nuova vulnerabilità su un host in DMZ Vulnerability Nuova vulnerabilità identificata su un host pubblicamente accessibile Invio di report quotidiano tramite al gruppo di gestione delle vulnerabilità Attività sospetta Firewall, IDS, Mail, Proxy, VPN Escalation watch lists (recon, exploit, brute force, etc.) Invio quotidiano di i con il report delle attività sospette Anomalia statistica IDS, Firewall, Proxy, Mail, VPN, Web Server Variazione medi di magnitudine X durante una specifica finestra temporale Visualizzazione degli allarmi nella dashboard di situational awareness 38 Nuovo pattern di IDS, Firewall, Proxy, Mail, VPN, Web Rilevazione di un pattern sconosciuto attività Server Visualizzazione nell active channel dell analista

39 Minacce interne Caso d Uso Sorgenti di log principali Criteri di allarme Azione Violazione Policy OS, Business Applications, Network Devices, DAM Utilizzo di applicazioni P2P Eccessivo consumo di banda Accessi fuori policy verso siti web Visualizzazione nell active channel dell analista / al manager dell impiegato / visualizzazione nella summary dashboard Violazione dei Ruoli OS, Business Applications, Network Devices, DAM Accesso diretto ai database da parte di utenti non DBA Accesso ai sistemi HR da parte di impiegati non HR Visualizzazione nell active channel dell analista /escalation al livello successivo / visualizzazione nella summary dashboard Utenti ad alto rischio (neo-assunti, consulenti, etc) OS, Business Applications, Network Devices, DAM Escalation watch lists (violazione policy, violazione ruoli, codice malevolo) con report quotidiano dell attività sospetta Utenti privlegiati & account condivisi OS, Business Applications, Network Devices Campi sensibili aggiornati (salario, costo, etc) dal DBA Account DBA acceduto da «root» o da «administrator» Account amministrativo acceduto da un utente non di dominio Visualizzazione nell active channel dell analista / escalation per la risposta all incidente Report delle attività utente AD or IAM, OS, Business Applications, Network Devices Report completo sulle attività degli utenti ad alto rischio con report quotidiano dell attività sospetta Nuovo pattern di attività IDS, Firewall, Proxy, Mail, VPN, Web Server Rilevazione di un pattern sconosciuto Visualizzazione nell active channel dell analista 39

40 Dati di contesto e determinazione della priorità esempio di applicazione pratica in un SIEM (HP ArcSight)

41 Sorgenti di dati di contesto 41

42 Correlazione arrichita dal contesto Contesto Asset Vulnerabilità Storia dell attacco Criticità Contesto utente Ruoli Attributi Account Contesto location Fisico Logico 42 Badge Query ai DB File salvati su USB Login VPN File acceduti inviate Screen Print Navigazione Web Applicazioni

43 Contesto di vulnerabilità Una vulnerabilità è uno stato software, hardware o firmware che espone un asset ad un potenziale rischio di sfruttamento della stessa. All interno di ArcSight, la risorsa Vulnerability consiste in una serie di directory che corrispondono a diverse autorità o enti che pubblicano descrizioni di vulnerabilità quali XS-Force, CVE e Bugtraq. La descrizione di una vulnerabilità consiste solitamente in un insieme di software e/o hardware che, se presente nel sistema analizzato, potrebbe essere sfruttato da parte di una forza esterna. Se un sistema soddisfa tutti i requisiti elencati nella descrizione della vulnerabilità viene considerato esposto a tale vulnerabilità. Nella maggior parte degli ambienti le vulnerabilità sono individuate e gestite attraverso uno scanner i cui risultati possono essere utilizzati per alimentare il network model di ArcSight. 43

44 Scansioni di vulnerabilità e Network Model 1 di 2 Spesso gli scanner di vulnerabilità sono configurati per eseguire le proprie operazioni ad intervalli regolari e in maniera continuativa, ad esempio ogni 24 ore. Lo scanner produce un report che viene salvato all interno di una directory o di un database all interno della rete. Lo SmartConnector ArcSight di tipo Scanner viene configurato per controllare questa directory o database in cerca di file aggiornati: non appena viene rilevato un report di scansione aggiornato, si occupa di collezionare i dati e normalizzarli nello schema ESM. Per comunicare i dati contenuti nel report alla componente ESM Manager, il connettore ne effettua il parsing trasformandoli in singoli eventi ESM contenenti informazioni per ogni asset di rete, categoria di asset e vulnerabilità. Quando ESM riceve un aggiornamento dallo scanner di vulnerabilità, cerca di ricondurre l asset presente nel report ad un indirizzo IP già esistente e modellizato all interno del correlatore; se inesistente, lo crea ex novo. 44

45 Scansioni di vulnerabilità e Network Model 2 di 2 45

46 Vulnerabilità e priorità degli eventi -1 di 2 Il correlatore determina la priorità degli eventi utilizzando quattro fattori: 1. Model confidence: si riferisce al fatto che l asset sia modellizzato o meno all interno del correlatore. Un asset modellizzato potrà usare l output della scansione di vulnerabilità includendo nuove informazioni (vulnerabilità rilevate, porte aperte, etc) e disponendo di un model confidence più attendibile; 2. Relevance: si riferisce al fatto che un evento sia o meno rilevante per un asset in funzione delle porte e/o delle vulnerabilità associate a tale evento; 3. Severity: i punteggi di Severity sono assegnati sulla base della presenza dell attaccante e del target in una delle Active List del correlatore; 4. Asset Criticality: viene configurata manualmente durante il processo di modellizzazione categorizzando gli asset all interno del correlatore. 46

47 Vulnerabilità e priorità degli eventi 2 di 2 La Model Confidence è maggiore se un asset è oggetto di scansione di vulnerabilità e di porte aperte. La Relevance è maggiore se la porta attaccata è effettivamente aperta sull asset e se l attaccante sta cercando di sfruttare una specifica vulnerabilità su tale asset: il correlatore calcola la priorità di un evento valutando se la porta attaccata è aperta e se l indirizzo IP attaccato è interessato da specifiche vulnerabilità. Il campo dell evento Vulnerability viene popolato quando l obiettivo dell attacco è un asset che espone una signature di vulnerabilità che corrisponde al campo deviceeventclassid dell evento. 47

48 Priority Formula La Priority Formula è un insieme di cinque criteri utilizzati per valutare ogni singolo evento al fine di determinarne relativa importanza e priorità. Si tratta di una funzione automatica sempre attiva che viene applicata a tutti gli eventi ricevuti dal correlatore. Il calcolo della priorità serve a segnalare al personale di sicurezza se l evento specifico merita particolare attenzione o no. La Priority Formula consiste in quattro fattori combinati che generano una valutazione complessiva della priorità: ogni criterio offre alla formula un valore numerico compreso tra 0 (basso) e 10 (alto): un elevato fattore di priorità indica un evento ad elevato fattore di rischio. Non tutti gli eventi ad alta priorità sono necessariamente minacce di sicurezza (potrebbero infatti essere allarmi di tipo operativo). Oltre ai quattro fattori di priorità, la Priority Formula utilizza anche l agentseverity (ovvero la traduzione della Severity in valori normalizzati per il correlatore). 48

49 Fattore di priorità Model Confidence La Model Confidence è relativa al fatto che l asset sia modellizzato o meno all interno del correlatore e a che livello. Il punteggio massimo è : l asset è modellizzato e il suo asset ID è presente; +4: l asset è stato oggetto di scansione per le porte aperte; +4: l asset è stato oggetto di scansione di vulnerabilità. 49

50 Fattore di priorità Relevance La Relevance è relativa al fatto che un evento sia o meno rilevante per un asset sulla base del fatto che l evento contenga porte aperte e/o vulnerabilità note e, in caso affermativo, se queste vulnerabilità e/o porte siano esposte dall asset. Se un asset non espone porte o vulnerabilità contenute nell evento, l evento non è rilevante per l asset. Il punteggio massimo è

51 Fattore di priorità Severity - 1 di 2 La Severity è una sorta di funzione storica: il sistema è stato attaccato o compromesso in precedenza, l attaccante ha già eseguito azioni malevole o scansioni in passato? Punteggi diversi sono assegnati sulla base della presenza o meno dell attaccante all interno delle Active List del correlatore (/All Active Lists/ArcSight System/Threat Tracking), i cui contenuti sono aggiornati automaticamente dalle regole di correlazione. Il punteggio massimo è : l asset appare come attaccante nell Active List /ArcSight System/Threat Tracking/Infiltrators List; +5: l asset appare come attaccante nell Active List /ArcSight System/Threat Tracking/Hostile List; 51

52 Fattore di priorità Severity 2 di 2 +3: l asset appare come attaccante nell Active List /ArcSight System/Threat Tracking/Compromised List; +3: l asset appare come attaccante nell Active List /ArcSight System/Threat Tracking/Suspicious List; +1: l asset appare come attaccante nell Active List /ArcSight System/Threat Tracking/Reconnaissance List. 52

53 Fattore di priorità Asset Criticality L Asset Criticality misura l importanza dell asset nel contesto specifico in funzione del modello di rete configurato all interno del correlatore usando le categorie standard /System Asset Categories/Criticality/Very High, High, Medium, Low, e Very Low. Il punteggio massimo è : l asset è trovato dal filtro /System Asset Categories/Criticality/Very High; +8: l asset è trovato dal filtro /System Asset Categories/Criticality/High; +6: l asset è trovato dal filtro /System Asset Categories/Criticality/Medium; +4: l asset è trovato dal filtro /System Asset Categories/Criticality/Low; +2: l asset è trovato dal filtro /System Asset Categories/Criticality/Very Low; +0: l asset non è categorizzato dai filtri precedenti. 53

54 Valutazione della priorità 1 di 2 La priorità di un evento è calcolata valutando complessivamente l agentseverity con i fattori Model Confidence, Relevance, Severity e Asset Criticality. I quattro fattori della Priority Formula insieme all agentseverity sono tutti campi all interno dello schema del correlatore. La valutazione della priorità è associata a colori e mostrata all interno dell Active Channel. 54

55 Valutazione della priorità 2 di 2 Priorità Colore Descrizione 0-2 Verde 3-4 Blu 4-6 Giallo 7-8 Arancione 9-10 Rosso Very Low: questo evento è una funzione di routine (ad es. l accesso di un utente autorizzato). Low: questo evento descrive un operazione comune, come un cambio di configurazione o una scansione di sistema programmata. Medium: questo evento è un potenziale problema, ad esempio una scansione propedeutica ad un attacco, violazioni di policy o vulnerabilità identificate. Questi eventi spesso sono tentativi ostili di accesso il cui esito non è confermato. High: questo evento è un problema che indica, ad esempio, formazioni di attacco, violazioni di sicurezza, utilizzo improprio, traffico verso darknet, valori di registro sbagliati, un SYN flood, etc. Very High: questo evento è un problema grave, ad esempio violazioni di sicurezza certe o pacchetti DHCP che non contengono all interno del proprio payload determinati dati. 55

56 Thank you!

57 Nome: Andrea Boggio Ruolo: Business Consultant Location: Roma Industry Focus: Cross industry Andrea Boggio ricopre il ruolo di Business Consultant in HP Enterprise Security Services. Partecipa all'information Security Arena da oltre 10 anni e si focalizza principalmente sugli aspetti tecnologici e di processo delle aree di Governance, Risk & Compliance, SIEM\SOC, Mobile Protection, Threat and Vulnerability Management e Network Security. Ha maturato esperienze significative presso clienti del settore Telco, Public Sector e Finance. Detiene le seguenti certificazioni di sicurezza: ISO/IEC 27001:2005 Lead Auditor; Certified Information Systems Auditor (CISA); Certified Information Security Manager (CISM); Certified in the Governance of Enterprise IT (CGEIT); Certified in Risk and Information Systems Control (CRISC); Information Technology Infrastructure Library (ITIL); oltre ad altre certificazioni professionali di specifiche tecnologie di sicurezza (ArcSight, FireEye, etc). È membro del capitolo Italiano di ISACA. Partecipa all'expert Group di ENISA per la tematica Cloud Security and Resilience. 57