Ogni dispositivo informatico, ogni applicazione, dal mondo IT fino all’universo IoT genera in modo continuo informazioni, principalmente sotto forma di log: all’interno di questo fiume di informazioni si nascondono dati molto interessanti che però non è semplice gestire, per cui dotarsi di un SIEM in azienda è un passo dovuto.
È necessario, però, stabilire gli obiettivi: rispondere ad un requisito normativo o di compliance è diverso rispetto ad un utilizzo in ambito security.
Proviamo ad analizzare tale percorso, partendo dalle esigenze business.
Indice degli argomenti
Qual è l’esigenza delle organizzazioni?
L’obiettivo primario per ogni azienda è quello di massimizzare la disponibilità dei propri sistemi IT e, in generale, fare in modo che le business application siano sempre disponibili. È indispensabile permettere al business di avere a disposizione gli strumenti necessari per potere essere competitivi sul mercato. Andiamo ad analizzare alcuni ambiti.
La forza vendita utilizza un sistema CRM per poter pianificare e monitorare la propria strategia sui clienti. L’indisponibilità dello strumento genera un potenziale svantaggio competitivo sul mercato.
La logistica per poter essere veloce nell’attività di physical delivery adotta sistemi automatici per la gestione del magazzino. Un guasto potrebbe generare il blocco dell’operatività con possibili conseguenze su movimentazione merci, preparazione ordini e consegne.
La gestione della produzione è basata su sistemi di controllo e supervisione (SCADA). Questi dispositivi sono parte integrante del processo produttivo e la loro indisponibilità può bloccare l’intera catena.
Non dimentichiamoci dei dispositivi assegnati in modo esclusivo ai collaboratori (smartphone, notebook, tablet) che sono indispensabili per poter svolgere la propria attività lavorativa. Il loro grado di criticità è strettamente legato all’utilizzatore del bene.
Da dove partire: il System Monitoring
Tralasciamo in questo articolo l’analisi della corretta architettura tecnologica che sta alla base dei sistemi IT (ad esempio applicazioni business critical richiederebbero soluzioni di HA).
Il primo passo è quello di dotarsi di sistemi di monitoraggio – System Monitoring – che verifichino la disponibilità delle applicazioni.
Gli approcci sono generalmente di due tipologie, spesso utilizzate insieme per massimizzare i risultati:
- Bottom-up: ogni business application utilizza una struttura di componenti, strettamente dipendenti e interconnessi tra di loro. Operativamente vengono definiti una lista di indicatori per ogni componente, il cui cambiamento di stato genera un evento (parte guasta, servizio non attivo, risorsa insufficiente). L’obiettivo è monitorare tutti i componenti, partendo dal basso verso l’alto:
- sistemi fisici (server, storage);
- infrastruttura di rete;
- sistemi di virtualizzazione e sistemi operativi;
- database;
- motori applicativi.
- Top-down: con questo approccio il monitoraggio avviene tramite software intelligenti che simulano l’azione dell’utente e segnalano comportamenti anomali dell’applicazione.
Entrambi gli approcci hanno il limite di basarsi su indicatori on-off (attivo/non attivo; funzionante/guasto) o di soglie predefinite (percentuale di occupazione disco, banda, utilizzo CPU, RAM).
La funzionalità primaria è quella di generare eventi partendo dagli indicatori definiti. A seguito di tale analisi e configurazione, si otterrà uno strumento utile per ridurre i tempi di gestione di un allarme e ridurre l’impatto di un incident sul business.
Il rischio maggiore è quello di sovradimensionare o sottodimensionare il numero e la tipologia di tali indicatori, generando un effort di gestione ingiustificato da parte del personale IT o, nel caso opposto, di ignorare allarmi che possono generare gravi incident.
Una fonte ricca di informazioni: i log
L’attività di System Monitoring ha il grosso limite di fermarsi al controllo degli indicatori che sono stati definiti in fase di analisi, ignorando le fonti che sono per loro natura destrutturate o parzialmente destrutturate.
Tutti gli oggetti IT, non IT e le applicazioni generano una grossa quantità di informazioni sotto forma di log, raggruppate in diverse categorie e livelli di criticità.
Per chiarire meglio il concetto, valutiamo alcuni esempi:
- un disco (fisico) che si avvicina al momento del guasto, non genera l’accensione di nessun indicatore, ma scrive nei log diagnostici informazioni sugli errori o rallentamenti nelle sue attività di scrittura e lettura. Analizzando tali log sarebbe possibile anticiparne la sostituzione riducendo la probabilità di disservizio;
- la creazione di un profilo utente amministratore è un’operazione che viene tracciata nei security log. Tale informazione è potenzialmente un indizio di attività malevola, sia che essa sia fatta da una persona, sia – e ancor di più – che sia fatta da un software (malware).
Il valore di queste informazioni aumenta se i log vengono correlati tra di loro, prendendo fonti di tipologia differente.
Dotarsi di un SIEM
Il SIEM (Security Information and Event Management) è lo strumento che si occupa di raccogliere log prodotti da diverse fonti, interpretarli, normalizzarli e correlarli tra di loro, specificatamente in ambito security.
Questo repository risolve, ad esempio, i problemi di retention, mettendo a disposizione un repository unico. Il dato salvato localmente nel singolo dispositivo ha normalmente un tempo di conservazione limitato, mentre le regole di retention all’interno del SIEM possono essere definite in modo puntuale.
Dobbiamo distinguere le motivazioni per cui un’azienda decide di dotarsi di un SIEM. È indispensabile chiarirle internamente, prima di far partire un progetto di implementazione, per evitare che tale strumento rimanga inutilizzato o, ancora peggio, diventi un peso per il reparto IT senza effettivo beneficio per l’azienda.
Il SIEM può semplificare il processo di conformità dell’azienda alle norme nazionali o internazionali, framework di sicurezza o vincoli legali. Se l’obiettivo primario è limitato a questo aspetto, l’approccio da utilizzare deve tenere conto di questa scelta ed è consigliabile:
- minimizzare il numero di sorgenti di log (fonti);
- evitare di generare eventi;
- revisionare la configurazione in modo periodico.
Se invece, l’obiettivo primario è quello di migliorare il livello di sicurezza dell’azienda, magari in un processo continuativo, l’approccio sarà totalmente differente:
- raccogliere il numero maggiore di fonti, dopo aver eseguito un’attenta analisi del formato e contenuto;
- definire le correlazioni che devono generare eventi e alert verso il reparto IT (magari attraverso un SOC);
- eseguire continuamente attività di fine-tuning della configurazione e delle correlazioni. L’obiettivo è minimizzare i falsi positivi (eventi da ignorare) e ridurre i falsi negativi (eventi che dovevano essere analizzati e sono stati ignorati o scartati);
- valutare gli impatti alle fonti/sorgenti durante il processo di change management o nei progetti di rinnovamento tecnologico.
È facile intuire che la gestione di un SIEM per esigenze di security richiede tempo, risorse e figure specializzate.
Dotarsi di un SOC (Security Operations Center) è indispensabile per gestire gli eventi che vengono generati dallo strumento. È possibile dotarsi internamente di un SOC, ma è preferibile (per competenze e complessità di gestione) attingere da un servizio esterno, scegliendo da aziende specializzate in ambito cybersecurity che possano erogare in 24×7.
Aggiungere un IDS come fonte attiva del SIEM
Continuando nel percorso di maturazione in ambito security, l’inserimento di un IDS come fonte del SIEM è un passo obbligato.
Un IDS (Intrusion Detection System) viene inserito all’interno della rete aziendale per analizzare in modo attivo il traffico di rete. L’obiettivo è quello di generare allarmi, a fronte del rilevamento di pacchetti di rete sospetti o comportamenti anomali, sintomi di possibili intrusioni o accessi non autorizzati.
Configurando un IDS come fonte del SIEM e correlando tali informazioni con altre sorgenti, è possibile, ad esempio, identificare un malware prima che questo generi un incident di sicurezza e nei casi peggiori possa bloccare il business dell’azienda.
Anche in questo caso:
- un’attività continuativa di fine tuning può migliorare la bontà delle segnalazioni generate;
- la velocità nella risposta all’allarme riduce o elimina gli impatti possibili.
Oltre a un sistema IDS, è possibile inserire (normalmente sul limite perimetrale della rete) un IPS (Intrusion Prevention Systems). Il primo ha un ruolo passivo ed è usato come strumento di monitoraggio, il secondo è attivo e può bloccare le connessioni che vengono identificate come anomale.
Un IPS è quindi più efficace di un IDS, ma ha un potenziale impatto sul traffico di rete e deve essere configurato con particolare attenzione. Una configurazione errata dell’IPS può quindi generare possibili disservizi, in particolare se le applicazioni utilizzate in azienda sono state sviluppate internamente (e quindi potrebbero non aver tenuto conto dell’ambito security) o sono particolarmente datate.
In conclusione
Per un’organizzazione pronta a investire in un questo percorso, ci sono dunque quattro punti fondamentali da considerare:
- l’inserimento di un SIEM all’interno di un’azienda semplifica i processi di Audit e Compliance, ma gioca un ruolo fondamentale nella cybersecurity;
- non bisogna sottovalutare l’impatto che tale strumento può avere sull’operatività del reparto IT;
- è necessario dimensionare correttamente gli investimenti per poter beneficiare di tale strumento per aumentare il livello di sicurezza del business;
- l’attivazione di un servizio esterno potrebbe mediare tra investimento e beneficio atteso.
