Information security continuous monitoring: le linee guida per una sicurezza “continua”

L’aumento della complessità che le aziende si trovano ad affrontare per proteggere le proprie informazioni e quindi il proprio business obbliga di fatto ad attivare un processo per il monitoraggio continuo della sicurezza, il cosiddetto Information Security Continuous Monitoring (ISCM).

Fenomeni come l’introduzione di nuove modalità di lavoro in mobilità, o il trasferimento su cloud dei dati aziendali, fanno sì che le informazioni, un tempo ben localizzate all’interno del perimetro aziendale, siano ora difficili da localizzare e da proteggere.

Allo stesso tempo, l’evoluzione delle tipologie di attacco, che hanno sempre più come oggetto l’utente piuttosto che le infrastrutture, comporta che l’anello debole della sicurezza sia sempre più l’utente finale.

I principi dell’Information Security Continuous Monitoring

Il NIST (National Institute of Standards and Technology), all’interno del documento di linee guida “Information Security Continuous Monitoring (ISCM) for Federal Information Systems and Organizations” (SP 800-137), dà la seguente definizione di Information Security Continuous Monitoring: “Information Security Continuous Monitoring (ISCM) is defined as maintaining ongoing awareness of information security, vulnerabilities, and threats to support organizational risk management decisions”.

Tale documento contiene le linee guida per sviluppare un’ISCM all’interno di un’organizzazione. I componenti chiave di un ISCM sono:

• definizione di una strategia di monitoring;
• definizione di un programma di monitoring;
• implementazione del programma di monitoring;
• analisi e report delle evidenze;
• risposta alle evidenze;
• revisione e modifica della strategia e del programma dell’ISCM.

Secondo il NIST, l’ISCM deve essere allineato con il programma di risk management che coinvolge tutta l’organizzazione. Le misure di sicurezza individuate per la riduzione del rischio devono essere monitorate a più livelli: il livello dell’organizzazione (Tier 1), il livello dei processi di business (Tier 2), il livello dei sistemi informativi (Tier 3).

La struttura a più livelli delle misure di sicurezza per la riduzione del rischio (fonte: Clusit).

Potrebbe sembrare che un ISCM sia riservato ad organizzazioni di grandi dimensioni, ma al di là di quelli che sono i principi e i framework, qualsiasi organizzazione può ottenere benefici anche solo adottando una parte di quello che è un ISCM completo. L’obiettivo di questo articolo è illustrare e fornire consigli pratici alle aziende su come predisporre un sistema di monitoraggio, valorizzando il più possibile quanto già disponibile in azienda.

Tra i principali benefici derivanti dall’adozione dell’ISCM si possono citare:

• consolidamento delle informazioni rilevanti ai fini della Cybersecurity;
• miglioramento dei livelli di generali di sicurezza;
• maggiore efficienza nella rilevazione e risposta alle anomalie/incidenti;
• monitoraggio continuo del rispetto delle policy, procedure, configurazioni e standard aziendali;
• automazione dei controlli sulle componenti tecnologiche critiche e relativa notifica dei malfunzionamenti;
• miglioramento continuo della cyber security;
• misurabilità del servizio;
• riduzione del rischio;
• attribuzione puntuale delle responsabilità;
• veloce individuazione delle inefficienze e loro risoluzione.

I prerequisiti di un corretto Information Security Continuous Monitoring

Affinché un’organizzazione possa adottare efficacemente un processo di continuous monitoring, sono necessari alcuni requisiti che possono essere sia di tipo organizzativo che tecnologico. La mancanza di uno o più di questi requisiti non pregiudica l’attuazione del processo, ma la loro presenza ne rende più facile l’attuazione e ne aumenta l’efficacia.

Eccoli in dettaglio:

• Politica di log management. Non deve essere orientata soltanto alla compliance normativa, ma anche al continuous monitoring. Nell’ottica di utilizzare ciò che è già disponibile in azienda, i log sono una fonte preziosa di informazione: il problema sarà semmai estrarre efficacemente le informazioni utili separandole dal rumore di fondo.
• Sinergia tra diverse funzioni interne. Fondamentale per identificare puntualmente cosa tracciare, in che modo, con quale frequenza e, soprattutto, per quale finalità.
• Maturità cyber security. Devono essere già presenti misure di sicurezza: non ha senso monitorare ciò che è intrinsecamente insicuro.
• Risk assessment. Necessaria affinché vi sia consapevolezza di quali siano i dati e le informazioni importanti da proteggere e a quali rischi siano connessi, in modo da indirizzare i monitoraggi verso quelli che sono i rischi maggiori.
• Gestione degli asset. Collegandosi al punto precedente, un sistema di gestione degli asset permette di avere consapevolezza di quali siano gli asset coinvolti nella gestione dei dati e delle informazioni più a rischio e le loro interdipendenze, associando un livello di criticità ad ogni asset. In fase di monitoraggio si terrà conto della criticità dei vari asset. Tra gli asset possiamo comprendere anche le persone, che in base al loro ruolo avranno diversi livelli di criticità.
• Gestione delle vulnerabilità. È fondamentale eseguire regolari vulnerability assessment o, meglio, adottare un processo di gestione delle vulnerabilità associate ai singoli asset. Finché tali vulnerabilità non sono corrette, il monitoraggio terrà conto, oltre che del livello di criticità dell’asset, anche delle vulnerabilità a cui è soggetto.
• Approccio orientato alla difesa. Non fare troppo affidamento sulla sicurezza preventiva, ma dare per scontato che le misure preventive possono fallire.
• Team dedicato alla gestione operativa della sicurezza. La raccolta di grandi volumi di dati può essere complicata da gestire in modo che la rilevazione e la risposta siano efficaci. Per questo motivo, oltre che da un punto di vista tecnologico, è necessario intervenire anche da un punto di vista organizzativo e procedurale, andando a definire, se non già presenti nella propria realtà, nuovi ruoli a cui attribuire nuove mansioni e relative responsabilità, costruendo un team dedicato alla gestione operativa della sicurezza o, meglio ancora, un vero e proprio SOC strutturato. Il SOC può essere costruito ricorrendo a servizi di società esterne.
• Committment aziendale. Anche se presentato per ultimo, si tratta probabilmente del requisito più importante. Affinché il continuous monitoring abbia successo è necessario un forte supporto da parte dei vertici dell’azienda, che ne faccia capire l’importanza a tutti i livelli aziendali e che permetta di rendere disponibili le risorse necessarie al suo efficace funzionamento.

Cosa monitorare durante un Information Security Continuous Monitoring

Come abbiamo visto parlando dei prerequisiti, è bene integrare nel sistema di continuous monitoring, se disponibili, le informazioni derivanti dal risk assessment, dall’asset management e dal vulnerability management. Detto questo, gli strumenti di monitoraggio della sicurezza posti all’interno dell’azienda possono essere divisi in due categorie:

1. sonde dedicate al monitoraggio;
2. log di sistemi e applicazioni.

Se vogliamo sfruttare in particolare quanto già presente in azienda possiamo partire da questa seconda categoria, per poi eventualmente procedere in un secondo momento a posizionare sonde dedicate al monitoraggio in punti strategici della rete. 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 per individuare attacchi, frodi ed usi inappropriati. Per ogni tipo di situazione, certi eventi sono più pertinenti di altri nel contenere 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.

In generale, i sistemi da cui prelevare i log utili al continuous monitoring sono i seguenti:

• sistemi di sicurezza (firewall, IPS, sistemi antimalware di qualsiasi tipo, VPN, web proxy, sistemi di autenticazione); trattandosi di sistemi dedicati alla sicurezza, i dati provenienti da essi sono di primaria importanza per il monitoraggio della sicurezza;
• sistemi operativi e DBMS. Anche i sistemi operativi presenti su server, workstation e apparati di rete producono log significativi dal punto di vista della sicurezza. 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 punto precedente e al punto successivo. 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 segnalato un’attività sospetta, sui log del sistema operativo possono essere trovati maggiori dettagli sull’attività segnalata;
• applicazioni e web service. Utilizzate dalle organizzazioni per memorizzare, accedere e manipolare i dati usati dai processi di business, possono generare propri log o utilizzare le funzionalità di log del web server o dell’application server. Tali log sono importanti nel caso di incidenti che coinvolgono le applicazioni, o di accesso non autorizzato che sfrutti una o più vulnerabilità applicativa.

L’automazione del processo di continuous monitoring

Tracciare i log provenienti dai vari sistemi aziendali elencati precedentemente ha lo scopo di individuare eventuali comportamenti anomali, ovvero possibili indicatori del realizzarsi di una minaccia. Vista la numerosità degli eventi, il processo di analisi sarebbe troppo impegnativo per un’organizzazione se effettuata con strumenti manuali. Per poter effettuare efficacemente attività di audit diventa quindi quasi indispensabile per l’organizzazione dotarsi di uno strumento di centralizzazione dei log.

Esistono strumenti di diverso tipo che vanno dai più semplici sistemi di log management ai SIEM (System Information and Event Management) i quali, oltre a conservare i log per il tempo stabilito dall’organizzazione garantendone l’integrità, sono dotati di strumenti di correlazione. Gli strumenti di correlazione permettono di definire regole che, al verificarsi di determinati pattern che coinvolgano eventi provenienti anche da diverse sorgenti, permettano di generare qualche tipo di azione, come per esempio generare un alert.

Occorre precisare che i file di log vengono memorizzati nell’infrastruttura SIEM in due aree distinte con diverse esigenze di conservazione dei dati: una adibita alla archiviazione a lungo termine dei dati compressi (generalmente da 6 mesi ad un anno, oppure superiore in presenza di particolari richieste di conservazione) per esigenze di compliance normativa o anche in vista di possibili interventi di computer forensics e, l’altra, con i dati “live” per le attività operative di continuous monitoring con una retention time di circa 3 mesi.

Infine, esiste la possibilità di mettere in correlazione gli eventi fissando determinate soglie al di sopra delle quali possa risultare molto plausibile la possibilità che ci si trovi di fronte ad un attacco informatico riuscito oppure la possibilità che ci si trovi dinanzi ad una serie di eventi palesemente classificati come falsi positivi; generalmente le piattaforme SIEM sono in grado di implementare un set predefinito di regole di correlazione standard, ma consentono anche di creare delle regole “personalizzate”.

Prerequisito fondamentale per poter correlare gli eventi provenienti da diverse sorgente è quello di mantenere sincronizzati gli orologi dei diversi sistemi utilizzando il protocollo NTP, definendo il livello di accuratezza richiesto e generando allarmi ogni qual volta l’orario di un sistema si discosti dal livello di accuratezza o quando l’orario di un sistema viene modificato manualmente.

La tipologia di eventi da raccogliere, da analizzare e correlare è specifica dell’organizzazione ed è quindi impossibile dare delle regole generali e per motivi di spazio è anche impossibile fare esempi significativi. Occorre però dire che l’obiettivo con cui vengono scelte le varie tipologie di eventi da raccogliere e le regole di correlazione non deve essere unicamente il riconoscimento di eventuali attacchi, ma anche eventuali attività di post-attacco, come cancellazione delle tracce, attività finalizzate al mantenimento dell’accesso, movimenti laterali e esfiltrazione dei dati, soprattutto i dati che il risk assessment ha individuato come critici.

Fasi del processo di raccolta e analisi degli eventi di sicurezza (fonte: Clusit).

Misurare l’efficienza del continuous monitoring: le KPI

Per misurare l’efficienza del processo di monitoraggio, di analisi degli eventi di sicurezza e di azioni intraprese è importante raccogliere puntualmente dati statistici e, soprattutto, introdurre alcuni indicatori KPI. Ciò permetterà la definizione della cosiddetta baseline, contenente le informazioni desunte dalle attività di verifica in modo che possano essere di supporto nelle successive verifiche.

Un esempio di alcuni indicatori KPI significativi è presentato di seguito:

• numeri di eventi raccolti su base settimanale;
• numeri di eventi critici raccolti su base settimanale da sottoporre al processo di analisi;
• numero di asset monitorati, con riferimento particolare agli asset critici;
• numero di login falliti (superiori ad una soglia minima con evidenza delle occorrenze in orario extra lavorativo);
• numero di scansioni riconducibili ad uno stesso attaccante;
• top 10 attacker e top 10 target;
• top 10 categorie d’attacco;
• numero di casi esaminati su base settimanale o per analista;
• tempo necessario alla risoluzione di un caso.

Relazioni con altri processi di security

Abbiamo visto precedentemente come prerequisiti importanti per il processo di continuous monitoring siano l’integrazione con il processo di risk management, di asset management e di vulnerability management.

Il processo di continuous monitoring sarà tuttavia tanto più efficace quanto più sarà capace di integrarsi e scambiare informazioni con tutti i processi di security presenti all’interno dell’organizzazione. Seguono alcuni esempi di possibili integrazioni.

• Incident response. Da un lato il sistema di continuous monitoring permette la raccolta di evidenze da utilizzare all’interno del processo di incident report, dall’altro lato le informazioni derivanti dal processo di incident response possono essere utilizzate per modificare il sistema di monitoraggio e rendere più efficace la risposta agli incidenti. Inoltre un programma di incident response richiede un efficace monitoraggio affinché possa soddisfare i bisogni dell’organizzazione e continuare a migliorare.
• Digital forensics. Normalmente il sistema di continuos monitoring prevede che gli eventi vengano firmati e resi soggetti ad una marca temporale, rendendoli così inalterabili; analogamente, il fatto che gli eventi siano prelevati immediatamente dopo il loro accadimento e portati su un altro sistema li rende non modificabile da parte di un eventuale attaccante che voglia cancellare le sue tracce. Da notare inoltre che gli strumenti di ricerca avanzata presenti normalmente nei sistemi di continuous monitoring velocizzano le fasi di esame ed analisi. Per tali motivi è abbastanza naturale utilizzare le evidenze provenienti dal sistema di continuous monitoring in ambito digital forensics.
• Threat intelligence. Tradizionalmente i sistemi di continuous monitoring permettono la reazione solo a quelle che sono minacce identificate, in quanto non sono sono a conoscenza delle mosse di un attaccante in base a dati storici. L’integrazione di informazioni di Threat Intelligence permetterebbe di superare in parte questi limiti, fornendo informazioni verificate e pulite sugli indicatori di attacco, permettendo di rispondere adeguatamente alle minacce. Infine è ormai universalmente riconosciuta l’importanza della condivisione di informazioni di Threat Intelligence e, allo scopo anche di essere processate automaticamente, sono nati linguaggi e protocolli che favoriscono la condivisione, come per esempio STIX e TAXII: sarebbe importante che gli i produttori di SIEM fornissero nativamente il supporto per questi formati, e molti stanno iniziando a farlo.
• Machine learning. Abbiamo detto sopra che i sistemi di continuous monitoring permettono la reazione solo a quelle che sono minacce identificate. Una possibile soluzione a questo limite è quella di utilizzare algoritmi di machine learning nell’ambito del processo di continuous monitoring. In generale l’utilizzo di algoritmi di machine learning è conveniente quando si debba affrontare la risoluzione di problemi per i quali è complesso scrivere un algoritmo che ne contenga la soluzione. L’utilizzo del machine learning in ambito cybersecurity è diventato conveniente, come per altri ambiti, per il fatto che sono disponibili soluzione che permettono di generare, immagazzinare e analizzare grandi quantità di dati e in parte anche perché permette in parte di compensare la mancanza cronica di personale esperto sulla cybersecurity. Quest’ultimo aspetto, oltre ad essere un beneficio, potrebbe trasformarsi in un problema. Chi adotta tecnologie di questo tipo potrebbe essere indotto a pensare che non sia necessario dotarsi di personale formato, quando in realtà non è così: quanto rilevato da algoritmi di machine learning va sempre verificato da un analista in grado di valutare cosa stia succedendo.

Conclusioni

Non è semplice descrivere un processo così complesso e dipendente dalle peculiarità della singola organizzazione nello spazio di un articolo. Quanto qui riportato ha cercato di fornire alle aziende interessate a migliorare il loro approccio alla sicurezza una panoramica non esaustiva del processo, al fine di illustrarne i benefici.

Parte del materiale utilizzato nell’articolo deriva dalla pubblicazione della Oracle Community for Security “SOC e Continuous Monitoring faccia a faccia con la Cybersecurity” di cui sono uno degli autori. La pubblicazione è liberamente scaricabile da questo indirizzo.