Un approccio Open source alla gestione delle vulnerabilità

Un approccio Open source alla gestione delle vulnerabilità

Generalità. Ora più che mai è tempo di sdoganare infrastrutture tecnologiche e SW per la cyber security attraverso ambienti volte a proteggere la piccola e media utenza internet. Tali ambienti dovranno andare oltre le più tradizionali contromisure rappresentate da SW antimalware. Da questo punto di vista sensori IDS/IPS/Ibridi, (IDS=Intrusion Detection; IPS=Intrusion Prevention) agenti intelligenti on-board e ambienti di monitoraggio SIEM ( Security Information and Event Management ) di tipo open source, quindi più flessibili ed adattivi, nonché più economici, possono essere integrati nelle reti domestiche e in quelle di piccole e medie imprese con le tradizionali misure di homeland security (allarmistica sensoriale e telecamere), quindi alla portata di tutti.

Un nuovo approccio integrato in linea con le regole dell’IoT e delle Smart City. La crisi Covid-19 ha evidenziato infatti un aumento degli attacchi individuali e a piccole e medie imprese meno protette e dunque più vulnerabili delle grandi corporation. Essendo la piccola utenze sottoposta alla normativa sulla privacy GDPR oltre alle eventuali certificazioni di qualità ISO27001, nasce una immediata necessità di risolvere queste vulnerabilità con utilizzo di approcci standardizzati efficienti ed efficaci. Sarebbe auspicabile trovare la maniera di inserire i report dei vari vulnerability assessment all’interno del sistema di log management, per automatizzare il più possibile il processo di identificazione di attacchi. In effetti l’implementazione di NIST-800-53 e NIST-800-41 MITRE offrono questa possibilità.

Le parti fondamentali di questa architettura che potrebbe anche afferire a un SOC ( Security Operational Center) prevedono:

• Un Event Manager
• Un Correlation Manager con eventuali sistemi interni di E-learning per allertamento preventivo
• Un ambiente di Datafusion , Data Analysis
• Un CMDB – (Configuration Management Data Base)
• Un Ticketing System
• Un Workflow Manager and OPSs – ovvero un Incident Manager dotato di un Sistema di allertamento rapido con un Operational Procedure Steps (OPSs)
• Un cruscotto con grafica avanzata e reportistica.

Normalmente i SIEM hanno metodi predefiniti per il collezionamento, il filtraggio, l’aggregazione e la normalizzazione di log di particolari sistemi o applicazioni (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 valori 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 gli schemi più appropriati, rendendo il sistema molto più flessibile ed adattivo rispetto agli asset da proteggere. La generazione degli eventi avviene all’interno dei sistemi e delle applicazioni di cui si vogliono raccogliere i log da far pervenire al SIEM. Possono essere considerate due diverse famiglie di eventi generati:

1. I generatori di dati basati su eventi (sensori) che generano eventi corrispondenti a specifiche operazioni svolte da sistemi operativi, applicazioni, dispositivi di sicurezza e così via sulla rete.
2. I generatori di dati basati sullo stato (polling), generano eventi basati sulla reazione a stimoli esterni ad esempio dati relativi a check di integrità o demons che hanno il compito di verificare lo stato di un certo servizio.

Dash Board di un generico SIEM Open Source

Strategia di gestione dei Log. Il server SIEM può anche riceve i log dagli asset senza bisogno di installare un software particolare (agentless). Alcuni SIEM hanno la possibilità di iniziare la connessione con il sistema sorgente, utilizzando opportuni meccanismi di autenticazione per 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 metodi pull. In altri casi i sistemi sorgente inviano loro stessi i log al SIEM, dove è presente un opportuno receiver in tal caso, una corretta strategia di Log Management prevederà i seguenti 4 punti:

1. Centralizzare nel sistema di log management tutti gli eventi rilevanti. Una volta definiti gli eventi rilevanti per la propria organizzazione, occorre far sì che tali eventi siano registrati all’interno di un sistema centralizzato, dopo averli sottoposti a filtraggio, aggregazione e normalizzazione. Solo gli eventi provenienti dai sistemi giudicati rilevanti debbono essere raccolti.
2. 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.
3. Revisione tempestiva dei log. È necessario definire quali sono gli eventi di interesse ovvero gli eventi che possono costituire una minaccia, tenendo conto che, dei centinaia di migliaia 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 interesse, stabilendo l’intervallo di tempo affinché l’evento venga evidenziato con una procedura da seguire per ogni evento di interesse. Occorre infine schedulare la produzione di report degli eventi chiave dei dispositivi di sicurezza.
4. Creare un percorso di audit degli eventi di interesse. Occorre mantenere un percorso di audit sicuro per provare come gli eventi di interesse siano stati gestiti e risolti. Documentare poi come ogni evento di interesse sia stato gestito attraverso le SOPs rispettando gli SLA.

Reporting avanzato. Attraverso strumenti quali Kibana ed Elastic Search è possibile correlare ed interpetare i dati rilevati dai sensori in modo semplice ed efficace. Kibana è un’applicazione frontend gratuita e aperta che si trova sopra lo stack Elastic Stack, fornendo funzionalità di ricerca e visualizzazione dei dati per dati indicizzati. Comunemente noto come strumento di creazione di grafici (già denominato ELK=Elasticsearch – Logstash – Kibana), Kibana funge da interfaccia utente per il monitoraggio, la gestione e la protezione di un cluster Elastic Stack, nonché da hub centralizzato per soluzioni integrate sviluppate per lo Stack. Pensato nel 2013 all’interno della community Elasticsearch, Kibana è cresciuto fino a diventare l’interfaccia dello Stack stesso, offrendo un portale per utenti ed applicazioni di grande potenza rappresentativa e velocità.

Esempio di grafici Kibana per l’Integrity Monitoring di un generico SIEM

Analisi del rischi. Tutti gli standard di riferimento implementati in un SIEM afferiscono ad una analoga strategia di Risk Management anche se con differenti approcci dipendenti dalle differenti metodologie e standard di riferimento(ISO31000,ISO27001,COBIT, ITIL, COSO ecc.). Indicativamente una gestione ed analisi dei rischi può essere assimilata alle seguenti 4 fasi fondamentali: 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.

Moduli di un generico SIEM open source

Regulatory Compliance. Un SIEM orientato al mercato e alla piccola utenza dovrà soddisfare delle complience ad ampio spettro verso NIST 800-53, PCI DSS, TSC, HIPAA, GDPR, che andremo ad esplicitare di seguito.

PCI DSS. L’Ente responsabile degli standard di protezione PCI (PCC Security Standards Council) è costantemente al lavoro per monitorare le minacce e potenziare gli strumenti del settore dei pagamenti elettronici. Grazie al miglioramento continuo, agli standard di protezione PCI e grazie alla formazione di professionisti della sicurezza, l’Ente mantiene un alto livello globale di sicurezza verso i clienti del mondo bancario evitando compromissione dei dati della carta di pagamento.

TSC. In ottica SOC-SIEM (SOC=Security Operational Center), nei così detti Trust Services Criteria (TSC) dell’AICPA. I SOC Response Team devono disporre di tutti i controlli applicabili ed essere in grado di fornire tempestivamente prove dell’efficacia di tali controlli. I criteri per i servizi fiduciari (TSC) necessari ad ottenere la certificazione SOC 2 e quindi soddisfare i più recenti standard del framework, sono relativi a controlli che le organizzazioni devono implementare nell’infrastruttura IT. Le cinque categorie di criteri di controllo sono riportate in figura. Va da sé che uno strumento come il SIEM, in grado di supportare tali controlli, faciliterà l’approccio ad un SOC certificato anche e soprattutto in ottica CLOUD.

HIPAA. L’Health Insurance Portability and Accountability Act (HIPAA) è una legge federale degli Stati Uniti che definisce i requisiti per il trattamento dei dati sanitari protetti dei privati. La compliance HIPAA è regolamentata dall’HHS (Department of Health and Human Services) e l’OCR (Office for Civil Rights) che ha il compito di farla rispettare. L’HIPAA compliance deve essere parte integrante della cultura aziendale di ogni entità che opera nel settore sanitario al fine di garantire la privacy, la sicurezza e l’integrità dei dati sanitari protetti.

GDPR. General Data Protection Regulation (Regolamento Generale sulla Protezione dei Dati), ovvero il Regolamento Europeo NIS 2016/679 che chiarisce come i dati personali debbano essere trattati, raccolti, utilizzati, protetti e condivisi. Un SIEM che consenta di poter gestire adeguatamente dei report periodici che soddisfano la normativa GDPR/ISO 27001/Framework NIST è da preferire rispetto ad altre soluzioni.

NIST 800-53. Costituisce uno standard di conformità alla sicurezza creato dal Dipartimento del Commercio degli Stati Uniti e dal National Institute of Standards in Technology in risposta alle capacità tecnologiche in rapido sviluppo di soggetti avversari. Il NIST 800-53 è obbligatorio per tutti i sistemi informativi federali degli Stati Uniti ad eccezione di quelli relativi alla sicurezza nazionale. Le sue linee guida possono essere adottate da qualsiasi organizzazione che gestisca un sistema informativo con dati sensibili o regolamentati. Fornisce un catalogo di controlli sulla privacy e sulla sicurezza per la protezione da una varietà di minacce, dai disastri naturali agli attacchi ostili.

MITRE FRAMEWORK

Considerata una tipica Cybersecurity Kill Chain il framework MITRE, originariamente pensato con due ambienti fondamentali: PRE-ATT&CK e ATT&CK come mostrato in figura, ha recentemente subito alcune modifiche.

PRE-ATT&CK offriva inizialmente ai difensori la possibilità di rispondere a domande come: Ci sono segni di cosa un attaccante potrebbe prendere di mira?

Quali tecniche comunemente usate usa l’attaccante contro di te? In che modo dovresti dare la priorità alle acquisizioni e all’analisi dei dati di intelligence sulle minacce cyber per ottenere ulteriori informazioni per «percepire» l’attaccante prima che si verifichi l’exploit? Il 27 ottobre 2020, MITRE ha pubblicato ATT&CK v8. Questa versione rimuove il dominio PRE-ATT&CK dalla chain ATT&CK, sostituendo il suo ambito con due nuove tattiche in Enterprise ATT&CK Reconnaissance e Resource Development (vedi figura MITRE Tecniche e Tattiche).

È stata inoltre aggiunta una nuova piattaforma in cui si testano queste tecniche. ATT&CK MITRE ha suddiviso infatti ATT&CK in diverse matrici: enterprise, mobile e PRE-ATT&CK che viene evidenziato internamente appunto come matrice. Ogni matrice include strategie e tattiche diverse pertinenti all’argomento della matrice. La matrice ATT&CK for Enterprises ad esempio descrive cosa fa normalmente un utente malintenzionato quando si infiltra in una rete aziendale. Le informazioni raccolte durante un attacco sono presentate sotto forma matriciali alle quali si accede ad informazioni estese sulle Tattiche, Tecniche e Procedure dell’attaccante. La struttura di ATT&CK consiste in 14 tattiche che delineano il “perché” dell’approccio di un attaccante e quindi rappresentano l’obiettivo del suo attacco. Le tecniche ATT&CK sono del tipo “come” un avversario raggiunge un determinato obiettivo. Le procedure sono i passaggi specifici che un avversario compie per eseguire e implementare una tecnica. Queste tecniche rappresentano i vari modi in cui un cyber-attack può raggiungere obiettivi target. Questo approccio, implementato in un SIEM open source fornisce una soluzione completa e molto economica per prevenire e mitigare minacce alla sicurezza informatica.

Dash board delle minacce rispetto alle TTP MITRE registrate da un generico SIEM open source

Combinando queste due soluzioni, le difese di un’organizzazione possono essere migliorate contrastando le azioni nemiche in tutte le fasi del ciclo di vita dell’attacco. Per ciascuna tecnica elencata nel MITRE ATT&CK, vengono fornite le seguenti informazioni:

• Un identificatore e la tattica a cui è associato.
• Le fonti di dati che identificano l’uso della tecnica.
• Le mitigazioni e i metodi di rilevamento.

Le informazioni presenti nella matrice ATT&CK fanno parte di una raccolta di dati continuamente aggiornata. MITRE ha unificato le energie per includere informazioni sui crimini informatici che utilizzano determinate tecniche di attacco. Lo sviluppo delle contromisure sarà di tipo adattivo rispetto agli attacchi real time. Le informazioni fornite dal framework ATT&CK possono essere utilizzate dai team SOC per stabilire le priorità e per individuare le vulnerabilità nelle misure strategiche. Le tecniche, le tattiche e le procedure ATT&CK possono quindi essere utilizzate per dare priorità alla mitigazione delle minacce e scoprire le lacune nella sicurezza di una organizzazione.

Mappatura di intelligence delle minacce. L’elenco organizzato ed accessibile dei TTP registrati degli attaccanti è una guida preziosissima per studiare le minacce da parte dei team SOC all’interno di un SIEM. Nell’ipotesi che l’attività potenziale di un aggressore sia predittiva sulla base di TTP precedentemente sperimentate, è utile per tutti i team di difesa ed analisi delle minacce registrare queste informazioni in modo strutturato (compresi i dettagli di supporto). Oltre alle informazioni su come identificare, rilevare e mitigare la tecnica, viene anche fornita una descrizione esaustiva di ciascuna tecnica rilevata.

È inoltre possibile illustrare le lacune di esposizione rimuovendo a livello di codice le informazioni dal database per tecniche di interesse forense. ATT&CK aiuta de facto ad avere una visione più approfondita della capacità difensiva dell’organizzazione. Le procedure e le tattiche di ATT&CK osservate o rilevate possono essere utilizzate dal Security Operations Center (SOC) e dall’unità di Incident Response. Ciò consente di spiegare dove si trovano le capacità di difesa e gli errori rilevati e fornisce inoltre una convalida dei controlli per la prevenzione e l’identificazione della minaccia. Quando si fa riferimento alle tecniche ATT&CK, i controlli difensivi possono avere un significato ben noto.

La mappatura delle difese ATT&CK offre una roadmap delle vulnerabilità difensive in riferimento a tipologie di attacco precedentemente registrate. Diversi strumenti e risorse standardizzano le tattiche e le tecniche per una sicurezza coesa ed inclusiva. I difensori potranno quindi mantenere una maggiore consapevolezza condivisa durante il processo di Information Sharing associato.

 

Sonde IDS/IPS. Concludiamo questo articolo facendo notare che sonde molto economiche di tipo open source basate su Raspberry PI OS carrozzate con tecnologia IDS/IPS (ad esempio Suricata) sono molto efficienti per la risoluzione di vulnerabilità in reti domestiche e reti afferenti a piccole e medie imprese. Possono quindi assumere differenti configurazioni di rete e trasmettere attraverso API con il SIEM open source per il rispetto delle normative sulla protezione dei dati e sulle certificazioni di qualità e gestione di rischi.

 

Autore: Francesco Corona