Piattaforma SIEM in azienda: quali informazioni salvare e come gestirle, alla luce del GDPR

Introdurre una piattaforma di Security Information and Event Management (SIEM) in azienda può rivelarsi più complicato del previsto. La ragione del fallimento risiede nel considerare l’attività alla stregua di un semplice progetto e non di un vero e proprio processo.

Quest’ultimo richiede, infatti, un’attenta valutazione non solo delle informazioni che dovranno confluire nella soluzione scelta (le “fonti dati”), ma anche dell’evoluzione dell’infrastruttura IT nel tempo e dello scenario dei rischi che questa evoluzione impone di considerare.

Piattaforma SIEM: vantaggi e conformità al GDPR

Una piattaforma SIEM richiede risorse, con impegni notevoli del personale IT dovuti all’attività di analisi delle informazioni e alla necessità di acquistare familiarità con le funzionalità della soluzione, spesso complesse (anche nel caso di un Next-Generation SIEM).

Non sono da trascurare gli aspetti economici (dal costo delle licenze software legate alla soluzione prescelta, alle risorse hardware necessarie) e organizzativi (un’adeguata pianificazione delle attività).

La possibilità di correlare informazioni tra fonti dati eterogenee centralizzandone la raccolta, tipica di una moderna soluzione SIEM opportunamente configurata, permette al personale IT d’individuare tempestivamente comportamenti sospetti (possibili indicatori di attività anomale), ma anche malfunzionamenti degli asset (un improvviso incremento nell’utilizzo delle risorse), difficilmente identificabili interrogando i singoli dispositivi.

La centralizzazione delle informazioni permette inoltre di favorire la conformità con il requisito espresso dall’articolo 32 del GDPR (Security of processing), con particolare riguardo all’adeguatezza delle “misure tecniche e organizzative”.

Tuttavia, di fronte a una complessa soluzione SIEM, la sindrome del foglio bianco che di solito affligge gli scrittori è dietro l’angolo. Quali sorgenti includere nella raccolta degli eventi? Quale perimetro di rete prendere in considerazione? Quali informazioni estrarre? Il personale tecnico può inoltre trovarsi di fronte alla complessità di piattaforme che richiedono la comprensione profonda delle possibili regole di correlazione dei dati e delle modalità di rappresentazione delle informazioni (specifiche di ogni prodotto).

Piattaforma SIEM in azienda: un piano d’azione

Sarà quindi necessario predisporre un piano d’azione che tenga conto almeno delle fasi seguenti (necessariamente correlate tra loro):

1. mappatura dei flussi di dati aziendali (strettamente connessi alle esigenze di business e alla valutazione dei propri rischi IT);
2. valutazione delle necessità di compliance dell’azienda;
3. identificazione degli asset coinvolti (server, applicazioni, database, apparati);
4. configurazione della piattaforma SIEM (dashboard, regole di correlazione, allarmi, reportistica ecc.).

La mappatura dei flussi di dati aziendali (al fine di identificare gli asset coinvolti) dovrà prendere in considerazione non soltanto le informazioni legate al business (dati finanziari, profilazione della clientela, proprietà intellettuale, dati personali dei dipendenti nell’ambito dei rapporti di lavoro), ma anche di quelle legate ai sistemi di autenticazione, sicurezza e infrastrutturali specifici dei sistemi informativi.

Sarà necessario identificare dove le informazioni transitino, dove vengano salvate, quali siano le possibilità di accedervi dall’interno e dall’esterno della rete aziendale, quali strumenti di protezione dei dati e di autenticazione vengano impiegati.

Sarà utile disporre dei risultati dell’ultimo Risk Assessment IT per determinare le minacce, le vulnerabilità e identificare gli asset coinvolti. Il Risk Assessment fornirà indicazioni specifiche relative ai sistemi critici da proteggere, le informazioni di audit da prendere in considerazione per i controlli e, indirettamente, le modalità di configurazione della piattaforma SIEM (favorendo ad esempio l’assegnazione di una priorità agli allarmi attraverso opportune regole di correlazione).

In questa fase verranno identificate anche le persone (amministratori di sistema, utenti con accessi privilegiati, utenti chiave ecc.) che potranno essere oggetto di particolari valutazioni in merito ai sistemi utilizzati per accedere alla rete (necessità di audit delle workstation, dei sistemi di autenticazione, dei meccanismi di controllo dei dati quali le soluzioni di data loss prevention).

La seconda fase dovrà tener conto delle esigenze di conformità dell’azienda alle norme nazionali, a quelle internazionali e ai framework di sicurezza richiesti dalle esigenze di business. Il regolamento (UE) 2016/679 o GDPR contiene numerosi riferimenti utili dei quali tener conto nel disegno di una piattaforma SIEM:

1. la tutela del legittimo interesse nel trattare dati personali (degli utenti interni, dei clienti che accedono alle piattaforme web), al fine di rispettare le esigenze di sicurezza delle reti e dell’informazione, osservando il principio di proporzionalità (49);
2. la necessità di stabilire una politica di conservazione dei dati di log (i dati dovranno essere conservati per il tempo necessario a garantire la sicurezza delle reti e delle informazioni), favorendo la gestione degli incidenti informatici e le analisi forensi;
3. la necessità di differenziare l’accesso alle informazioni di log nel rispetto dei principi di least privilege e need to know (con particolare riguardo ai sistemi che ricadono sotto l’articolo 35, “valutazione d’impatto sulla protezione dei dati”); in questo senso, potrebbe essere necessario mascherare l’accesso da parte degli amministratori di sistema alle informazioni di navigazione degli utenti provenienti dai log di un proxy server;
4. protezione dei dati di log at rest (integrità) e in transito (cifratura, firma, possibilità verifica della validità della firma; impiego del protocollo TLS 1.2 per la protezione dei dati di log in trasmissione dalle fonti al SIEM); si suggerisce di prendere in considerazione le indicazioni del National Institute of Standards and Technology (NIST) statunitense (SP 800-131A, SP 800-133) per valutare l’efficacia dei protocolli di cifratura supportati dai vendor e le modalità di salvaguardia delle chiavi crittografiche;
5. determinare una data-destruction policy (retention period) rispettando il principio del diritto all’oblio (art. 17); la piattaforma SIEM consentirà di registrare gli accessi ai file aziendali (attraverso l’audit sui file server o le NAS), ma anche dimostrare che le modalità di cancellazione sicura dei dati personali siano rispettate;
6. favorire attraverso la centralizzazione delle informazioni di sicurezza (art. 32) l’individuazione delle violazioni dei sistemi (articoli 33 e 34), anche avvalendosi di funzionalità automatiche basate su modelli di User and entity behavior analytics (UEBA), largamente impiegati dai vendor di soluzioni SIEM (si legga in proposito il report Gartner “Market Guide for User and Entity Behavior Analytics” del 21 maggio 2019).

Come già anticipato, dovranno essere prese in considerazione le esigenze di conformità ai framework di sicurezza e alle linee guida da rispettare per continuare ad operare nel proprio mercato di riferimento (ad esempio ISO 27001, PCI DSS, AgID, ma anche COBIT per la compliance SOX).

Alcuni framework contengono indicazioni molto precise in merito alle modalità di configurazione delle impostazioni di audit e conservazione dei log di sistema. Si pensi ad esempio al Payment Card Industry Data Security Standard (PCI DSS) e al requisito 10, che impone l’impiego di soluzioni di file-integrity monitoring per la protezione dei dati di log (req. 10.5.5), la necessità di revisione giornaliere delle informazioni di sicurezza dei componenti critici (req. 10.6.1) e tempi di retention diversi dagli abituali 180 giorni imposti per la conservazione dei log degli amministratori di sistema (il requisito 10.7 richiede almeno un anno, con un minimo di 90 giorni disponibili per le analisi on line).

Le piattaforme SIEM dovranno essere in grado di garantire la conformità alle varie disposizioni offrendo funzionalità di personalizzazione estremamente dettagliate.

Il team di progetto preposto a configurare la soluzione SIEM dovrà invece tener conto delle varie esigenze, identificando correttamente il perimetro di certificazione.

Piattaforma SIEM in azienda: la fase di configurazione

Al termine delle due fasi precedenti, si avrà un’idea più chiara di quali saranno gli asset da coinvolgere nel processo di raccolta dei log (data source) e delle relative modalità di configurazione dei parametri di audit, raccolta dei dati, monitoraggio, reportistica, log retention e storage.

Le politiche aziendali e i framework di riferimento permetteranno inoltre di determinare i modelli di deployment delle soluzioni SIEM più opportuni: on premise, cloud, SIEM-as-a-service (avvalendosi di un fornitore esterno), self o hybrid managed.

Al termine dell’analisi, giunti alla fase di configurazione della piattaforma, potrebbe emergere la necessità d’includere le sorgenti riportate di seguito (a titolo d’esempio):

• sistemi deputati ai controlli di sicurezza e rete:

1. firewall (log degli accessi, ma anche tutte le informazioni legate al traffico);
2. concentratori VPN (log amministrativi, sessioni, durata delle sessioni ecc.);
3. intrusion detection (and prevention) systems (IDS, IDPS);
4. strumenti di data loss prevention (DLP);
5. web proxy, reverse proxy;
6. web application firewall (WAF);
7. endpoint security (antivirus e soluzioni Endpoint Detection and Response);
8. router, switch, dispositivi wireless (management console o i log dei singoli apparati, se non amministrati in modo centralizzato);
9. DNS server, DHCP server;
10. soluzioni cloud access security broker (CASB);
11. cloud infrastructure (tramite appositi connettori forniti dai cloud solution provider);

• sistemi infrastrutturali:

1. Domain Controller Microsoft, LDAP server;
2. strumenti di Identity and Access Management (IAM);
3. file server, network-attached storage (NAS);
4. soluzioni di virtualizzazione (hypervisor);
5. database;
6. mail server;
7. application server;
8. web server, web application server;
9. cloud application (SaaS);
10. strumenti di trasferimento dati;
11. soluzioni di Mobile Device Management (MDM);

• altro:

1. Workstation (laptop, desktop), centralizzando le informazioni tramite il servizio di Windows Event Collector;
2. Workstation amministrative, top user (C-level user), utenti con accesso a dati personali;
3. soluzioni di asset inventory.

Politiche di hardening e di audit dei sistemi

È bene ricordare quanto le soluzioni SIEM siano prima di tutto contenitori d’informazioni provenienti dalle sorgenti selezionate. Quanto più queste informazioni sono complete, tanto più sarà possibile aumentare l’efficienza dell’ambiente di monitoraggio.

Sono fondamentali in tal senso le politiche di hardening, che dovranno fornire al personale tecnico accurate indicazioni in merito alla configurazione dell’audit dei sistemi.

Esistono numerose guide dei vendor e di altre organizzazioni (Center for Internet Security Benchmark, Defense Information Systems Agency STIG) che aiutano a impostare opportunamente i parametri di audit di sicurezza delle piattaforme. Anche in questo caso, sarà opportuno tener conto delle valutazioni fatte nelle prime due fasi.

Sarà inoltre necessario coinvolgere i vari team interni (DBA, sistemisti, applicativi) per scegliere correttamente i parametri di audit senza compromettere il funzionamento dei sistemi di produzione.

Una volta che i sistemi saranno in grado di produrre eventi di sicurezza significativi, sarà possibile configurare la piattaforma al fine di aggregare le informazioni e identificare scenari di rischio attraverso le funzionalità di correlazione degli eventi.

Il SANS Institute ha pubblicato nel 2013 una breve guida per individuare i controlli di sicurezza più comuni, che dovrebbero essere presi in considerazione nel personalizzare il SIEM. Il documento, “Top 6 SANS Essential Categories of Log Reports 2013”, indica almeno sei categorie di report utili agli amministratori di sistema nel riconoscimento delle attività sospette. Le categorie sono riportate di seguito (e non sono certo esaustive):

• autenticazione e autorizzazione;

1. logon riusciti/falliti (utenti attivi, disabilitati, di servizio, non presenti);
2. tentativi di logon provenienti dal medesimo indirizzo (tecniche di password spraying);
3. autenticazione VPN, accessi remoti in generale;
4. impiego degli account privilegiati;
5. successione di login falliti seguita da un login riuscito legato ad un medesimo account in un determinato intervallo di tempo;

• modifiche ai sistemi e ai dati;

1. modifica ai gruppi, soprattutto se privilegiati (ad esempio i gruppi Domain Admins, Enterprise Admins, Schema Admins di Microsoft Active Directory; sudo user in Linux);
2. aggiunta di utenti amministratori;
3. modifica/reset password;
4. modifica ai file di sistema, binari, file di configurazione;
5. modifica dei permessi sui file;
6. aggiunta/rimozione di servizi;
7. installazione/disinstallazione di applicazioni;

• attività della rete;

1. connessioni in outbound dalle DMZ;
2. file transfer particolarmente consistenti;
3. file upload a server web esterni;
4. VPN network activity (uso delle risorse interne, durata sessioni, byte trasferiti ecc.);
5. statistiche sui volumi di log raccolti nel tempo (al fine di evidenziare anomalie e picchi d’utilizzo);

• accesso alle risorse;

1. accesso alle risorse in orario non consentito (ad esempio non lavorativo);
2. accesso ai file server, NAS;
3. accesso ai database (identificando gli utenti maggiormente attivi);
4. modifiche ai database (ad esempio comandi di INSERT, DELETE);
5. invio allegati di posta voluminosi (identificazione utenti);

• attività legate al malware e agli strumenti di prevenzione;

1. statistiche sul rilevamento del malware;
2. disabilitazione/abilitazione funzionalità antivirus sulle postazioni;
3. connessioni ad indirizzi IP potenzialmente rischiosi;

• errori critici;

1. errori critici di sistemi e applicazioni;
2. fallimento dei backup;
3. esaurimento delle risorse (CPU, spazio disco).

Regole di correlazione e reportistica

È bene sottolineare l’importanza di personalizzare le regole di correlazione e la reportistica predefinita presenti nelle soluzioni SIEM. I vendor sono costretti ad approntare regole generiche che gli amministratori di sistema devono necessariamente modificare, al fine di adattarle alla specifica realtà nella quale operano.

Una mancata personalizzazione delle regole di correlazione può generare un numero elevato di falsi positivi e gli allarmi generici tendono ad essere ignorati (anche per questioni di sopravvivenza del personale IT).

Un aiuto per identificare possibili indicatori di attività sospette da evidenziare all’interno delle piattaforme SIEM può inoltre venire dalle tecniche d’attacco catalogate dal MITRE ATT&CK.

Il MITRE è un’organizzazione non a scopo di lucro statunitense che, con ATT&CK, si propone di mantenere una knowledge base di tattiche e tecniche che descrivono il modus operandi di attacchi reali.

Permettendo di definire agevolmente un threat model, ATT&CK è immediatamente applicabile agli ambienti aziendali ed è improntato alla pratica. In ogni tecnica d’attacco riportata (identificata con un ID univoco preceduto dal prefisso “T”), appare una descrizione delle sorgenti (Data Sources) che possono fornire indicatori di compromissione/attività.

La tecnica T1094 (“Custom Command and Control Protocol”), ad esempio, che si riferisce alla pratica adottata da alcuni attaccanti di stabilire canali di comunicazione personalizzati con i sistemi di command and control (C2), suggerisce le fonti d’informazioni seguenti: Packet capture, Netflow/Enclave netflow, Process use of network, Process monitoring, Host network interface, Network intrusion detection system, Network protocol analysis. La disponibilità di queste informazioni all’interno della piattaforma di monitoraggio permette di disporre di elementi utili a identificare scenari di rischio.

Sempre il MITRE fornisce una seconda knowledge base di analytics che suggerisce modelli integrabili all’interno delle soluzioni SIEM. Il repository è denominato MITRE Cyber Analytics Repository (CAR) e include indicazioni per favorire l’adozione di formati di firma generici open source quali Sigma.

Conclusioni

Il processo di identificazione delle informazioni da includere in una piattaforma SIEM è complesso e segue differenti fasi che coinvolgono diversi team all’interno dell’IT aziendale.

Un’adeguata pianificazione delle attività e soprattutto l’aggiornamento costante delle fonti dati all’interno della piattaforma sono fondamentali per garantire che il processo di salvataggio dei log non venga rapidamente compromesso.

Il SIEM deve continuare ad offrire nel tempo informazioni preziose per la salvaguardia del patrimonio informativo.