SOC (Security operation center) e CERT: definizioni e sinergie per la sicurezza informatica

Un’angolatura particolare alla cyber security è quella che considera la possibilità di creare o promuovere le sinergie tra le attività dei Security Operation Center (SOC) e dei Computer Emergency Response/Readiness Team (CERT). Molte realtà aziendali di sufficiente complessità sono dotate di questi centri o possono accedere alle prestazioni che essi offrono mediante contratti di servizio, o associazione con altre realtà o semplicemente a livello istituzionale.

Sinergie tra SOC e CERT per la sicurezza aziendale

Nell’ambito delle rispettive funzioni di due entità che nascono con ruoli e finalità differenti, (i SOC maggiormente rivolti all’operatività nel contrasto alle minacce, e i CERT alla ricerca e caratterizzazione delle stesse), si intende illustrare come vi siano notevoli sinergie tra le attività di un CERT e quelle di un SOC a beneficio di un’efficace presidio degli aspetti di sicurezza informatica di una specifica realtà aziendale. L’opportunità che si vuole mettere in evidenza è quella di passare sempre più da una strategia “reattiva” alla costruzione di una vera e propria “readiness” sul tema del contrasto delle minacce cyber.

Si farà qui riferimento ad organizzazioni di dimensioni medio-grandi, sino a infrastrutture critiche a livello Paese, quindi a organizzazioni in grado di sostenere e giustificare (sia per dimensioni che per rilevanza del business) l’adozione di questo tipo di strutture. Tuttavia, non si deve escludere a priori l’applicabilità di quanto segue ad associazioni di piccole imprese che vogliano dotarsi di questo tipo di presidio (o vi siano costrette, alla luce del contesto di operatività). Si pensi ad esempio al settore manifatturiero che rifornisce settori critici quali l’energy o l’automotive, o al settore medicale. In tali contesti, a grandi realtà si affiancano eccellenze regionali caratterizzate da dimensioni ridotte ma da know-how distintivo e da quote di mercato spesso rilevanti.

Presidio tecnico sui sistemi per la gestione degli incidenti

Qui, ad una gestione della sicurezza informatica di natura preventiva e/o di intelligence (quindi comunque caratterizzata da un imprescindibile attività di information sharing, supportata dallo studio dei fenomeni e dalla loro modellizzazione) deve necessariamente affiancarsi un presidio tecnico sui sistemi, così che dagli eventi anche minimali rilevati su di essi, e dalla loro analisi combinata, possa avviarsi un’efficace e proattivo processo di gestione degli incidenti.

Si vuole quindi discutere di come queste caratteristiche di proattività ed efficacia possano essere fortemente incrementate coniugando i ruoli di CERT e SOC in modo contestualizzato alla realtà gestita.

Il Security Operation Center: definizione e finalità

Volendo darne una definizione^[1], “A Security Operations Centre (SOC) can be defined as a centralized security organization that assists companies with identifying, managing and remediating distributed security attacks. Depending on the capabilities required from a SOC by the enterprise or client, a SOC can also be responsible for the management of technical controls. The end-goal of a SOC is to improve the security posture of an organization by detecting and responding to threats and attacks before they have an impact on the business.”

Un SOC nasce quindi per la raccolta e l’analisi di informazioni provenienti “dal campo”, ossia per la centralizzazione di eventi ed elementi “atomici” (log, banalmente, o specifiche configurazioni la cui variazione è potenziale sintomo di “qualcosa in atto”). L’informazione viene aggregata in forma automatizzata fino ad un certo livello, utile a far scattare un numero “umanamente gestibile” di alert rispetto ad ipotetici attacchi di sicurezza informatica, o comunque ad anomalie legate al tema.

Attività e servizi aggiuntivi del SOC

Oggi un SOC moderno, in grado di supportare efficacemente una realtà complessa, eroga (o può erogare) un gran numero di attività e servizi. Alcuni di essi sono in linea con la “mission” principale a cui si suppone un SOC debba ottemperare, o comunque ad essa strettamente correlate. Si tratta di attività continuative quali:

• Log Management, che abilita ogni successiva attività di analisi e rilevamento di anomalie;
• Security Monitoring and Alerting, on top rispetto alla raccolta informativa di cui al punto precedente;
• Security Incident Management che esprime la finalità principale e si esplicita nel supporto operativo in caso di un incidente di sicurezza informatica;

Si vedrà nel seguito come queste tre tipologie di attività rappresentino l’essenza stessa di un SOC “tipico”. Ad esse si affiancano, in un SOC che sia comunque propenso ad aiutare l’organizzazione gestita attraverso un presidio esteso degli aspetti di cybersecurity, altre attività quali:

• Security Operation Management anche in modalità continuativa;
• Vulnerability Assessment sul perimetro interno e/o esterno.

Alla luce delle competenze necessarie per portare avanti servizi come quelli sopra descritti nel contesto sempre più dinamico, mutevole e complesso della cybersecurity, un SOC “evoluto” è in grado di erogare anche servizi aggiuntivi su richiesta, tra cui ad esempio:

• il security assessment di servizi applicativi;
• la gestione di elementi collegati al sistema di sicurezza complessivo aziendale;
• la fornitura di “security analytics” partendo dagli eventi del SIEM;
• forse in parziale sovrapposizione con quanto, come vedremo, caratterizza i CERT, la cosiddetta “threat intelligence”.

A monte, un SOC può iniziare la propria attività di collaborazione con la realtà gestita mediante un posizionamento del livello di maturità nella gestione della sicurezza informatica da parte della stessa, esercizio comunque utile per comprendere il livello in cui ci si trova ad operare, ma anche per porre una “baseline” rispetto a cui confrontare l’efficacia del proprio operato e per individuare in modo mirato aree che necessitano di maggior presidio.

All’altro estremo della catena, un SOC intraprende sempre più spesso attività di comunicazione verso i principali interlocutori nella realtà monitorata, attraverso la condivisione di indicatori, che da un lato diano il “polso” della situazione, e dall’altro rendano conto del valore generato mediante l’attività.

L’insieme degli ulteriori servizi attribuibili ad un SOC può essere molto ampio, in funzione del peso e del ruolo di centralità che si vuole dare al SOC all’interno dell’organizzazione. In taluni casi, applicando un’interpretazione probabilmente eccessivamente allargata, il SOC può arrivare a coprire il ruolo di definizione della strategia di sicurezza informatica.

A prescindere da ciò, il punto è che per i SOC il ruolo si è andato espandendo nel corso degli anni, per tenere il passo con esigenze di supporto ad una sicurezza informatica sempre più complessa e pervasiva, non solo in termini di minacce e impatti ma anche in per quanto riguarda le esigenze di comunicazione e di interazione con attori interni ed esterni.

Le tre aree di attività prevalenti del SOC

Il ruolo chiave rimane però quello inizialmente descritto, a copertura di tre esigenze principali, qui sotto elencate, e si esplicita (in termini di attività ricoperte) nel diagramma riportato in Figura 1:

• threat prevention;
• attacks detection and containment;
• security systems (or features) tuning.

Figura 1 – Il ruolo principale di un SOC: 3 aree di attività prevalenti

In figura, si evidenzia come l’operatività di un SOC si estenda lungo tutta la “filiera” che va dalla raccolta dei dati atomici e “grezzi” sui sistemi monitorati fino alla memorizzazione/archiviazione degli stessi, e alla successiva analisi e correlazione. Tale analisi abilita un monitoraggio proattivo a vari livelli, nonché la rilevazione (detection) di eventi di sicurezza informatica complessi, che possono o meno concretizzarsi in incidenti e per i quali è necessario innescare un’opportuna reazione.

Il Security Information and Event Management system

Come nota si segnala che la fase centrale di archiviazione e aggregazione tradizionalmente avviene nel cosiddetto SIEM (Security Information and Event Management system), che secondo la letteratura costituisce il cuore dell’azione di un SOC, ma ciò rappresenta solo una possibile scelta tecnologica è non è vincolante a livello concettuale.

Identifichiamo piuttosto ad alto livello tre blocchi fondamentali, partendo da sinistra, indicativamente collocati come nella figura citata sopra (separati dalle linee tratteggiate):

• gli aspetti “tecnici” di integrazione dei sistemi nel contesto monitorato e di identificazione dei già citati “elementi atomici” rilevanti per la sicurezza;
• la raccolta, archiviazione e analisi degli eventi di cui sopra (i cui volumi possono essere elevatissimi), fino a raggiungere un livello di selezione e sintesi tali da abilitare un concreto ed efficace monitoraggio, finalizzato all’emissione di alert;
• la detection dei “trigger” per lo scatenarsi di detti alert, e la conseguente gestione della reazione (per quanto di competenza).

Quindi, perché si concretizzi la finalità ultima di un SOC, che è quella di emettere per la realtà tecnologica monitorata alert “tempestivi” alle funzioni interne che gestiscono le varie componenti tecnologiche e di cybersecurity rispetto all’insorgere di eventuali incidenti, e supportare la remediation attraverso gli strumenti di sicurezza in gestione, il SIEM non deve porsi solo come strumento, ma anche essere complementato dalla capacità di selezionare eventi aggregati significativi, perché il SOC sia efficace.

Proattività e prevenzione

Da notare come dietro alla parola “tempestivi” si nasconda (e si debba nascondere), in un SOC che realmente generi valore, la connotazione di “proattivi” o “preventivi”. Nella misura, infatti, in cui le tipologie di “eventi aggregati” rilevati dal SIEM sono sufficientemente anticipatori di reali compromissioni, l’emissione dell’alert avviene in modo sufficientemente anticipato da poter contrastare l’evento sin dalla sua insorgenza, evitando quindi la necessità di scalare al di fuori dalle funzioni preposte al presidio della cybersecurity.

Qualora invece l’incidente assuma tale connotazione, il personale del SOC collabora naturalmente alle attività di contrasto e rientro.

I driver per l’adozione del SOC

Quali sono le realtà che per prime si dotano di un SOC, al di là degli aspetti abilitanti delle dimensioni e di eventuali driver normativi esterni? Possiamo individuare alcuni fattori:

• la presenza di dati o processi critici o “sensibili” (in termini di business e/o di compliance normativa);
• l’insorgenza di trend di crescita dell’azienda tali, per cui una funzione di information security interna non strutturata e/o fortemente sbilanciata sull’operato di un outsourcer non riesce più a “tenere il passo” (creazione di colli di bottiglia tra outsourcer e referenti interni, outsourcing sottodimensionato, ecc.);
• la necessità di dotarsi di capacità “spinte” di monitoraggio e risposta sul piano tecnico ad eventi di sicurezza informatica.

CERT, ruolo e finalità principali

Nella seconda metà degli anni ’80 “Morris2” ha rappresentato forse il primo serio attacco informatico con impatto globale sulle infrastrutture ICT. Questo worm si è propagato in modo estremamente veloce riuscendo ad infettare un gran numero di sistemi IT nel mondo. L’incidente è stato un campanello d’allarme: nel giro di alcuni giorni la Defence Advanced Research Projects Agency (DARPA) ha stabilito il primo CERT Coordination Center (CERT/CC) presso la Carnegie Mellon University a Pittsburgh (Pennsylvania). L’acronimo CERT sta per “Computer Emergency Response Team” ed è in realtà una denominazione comune per questo tipo di ente, sebbene la denominazione considerata maggiormente precisa è CSIRT, che sta per “Computer Security Incident Response Team”. Esistono anche altre sigle utilizzate per caratterizzare la medesima funzione, se ne riportano alcune:

• IRT (Incident Response Team)
• CIRT (Computer Incident Response Team)
• SERT (Security Emergency Response Team)

Non è naturalmente interesse di questa analisi approfondire tali aspetti formali, ma si ritiene utile richiamarli per porre l’accento sulla molteplicità di significati, e di conseguenza di aspettative e potenziali ruoli, che a questo tipo di team vengono attribuiti in relazione all’ambito di azione e/o alla tipologia di costituency.

Le aree di azione e intervento del CERT

Infatti nel corso degli anni i CERT hanno esteso le loro aree di azione e di intervento, trasformandosi da una pura forza di reazione a (in taluni casi) veri e propri security provider, in grado di erogare:

• servizi preventivi (come gli alert su attacchi di sicurezza informatica)
• i “bollettini” (advisory) di sicurezza informatica
• il training sul tema e anche la gestione dei servizi di sicurezza per le realtà che vi si affidano (quindi in evidente sovrapposizione con le funzioni definite per i SOC).

Per questa ragione, riprendendo e concludendo la nota storica sull’evoluzione dei nomi, alla fine degli anni ’90 è stata introdotta la denominazione CSIRT. Al momento è considerata un sinonimo di CERT (sebbene come già accennato la prima sia più precisa), e nel seguito di questa analisi si farà appunto riferimento a questo tipo di enti come ai CERT.

In linea di principio, appare chiaro come l’avere un team di sicurezza IT (ma non solo, come si vedrà) che possa aiutare le organizzazioni che lo supportano a mitigare e prevenire incidenti rilevanti e a proteggere gli asset informatici di maggior valore sia un beneficio, specie con riferimento al target già definito per questa analisi.

I vantaggi dei CERT

Più in particolare, questo tipo di entità permette:

• un coordinamento centralizzato delle problematiche di sicurezza IT all’interno di un’organizzazione, agendo da Point of Contact;
• la capacità di fornire a tali problematiche, qualora si trasformassero in incidenti, una risposta centralizzata e specializzata;
• le conoscenze per gestire gli aspetti legali legati alla raccolta e conservazione della digital evidence, anche in caso di procedimenti legali;
• il monitoraggio continuo degli sviluppi nel settore della sicurezza informatica;
• lo stimolo continuo e la costruzione di awareness, all’interno del gruppo di soggetti che formano al costituency dell’ente, ma non solo.

Nel caso in cui poi il ruolo si estenda oltre i confini che la definizione presuppone, si arriva alla disponibilità “in loco” della necessaria expertise per supportare e assistere gli utenti nelle procedure di recovery dagli incidenti. Quanta parte di queste attività sia in realtà erogata sa uno specifico CERT dipende in larga misura appunto dal gruppo di costituenti e dal tipo di ambiente o settore (industriale ma non solo) in cui il CERT opera.

I maggiori settori che si dotano di CERT specifici

• settore accademico;
• settore governativo;
• le infrastrutture critiche;
• grandi aziende/gruppi;
• settore militare;
• istituzioni a livello globale (es. Stati);
• gruppi di piccolo-medie imprese.

Esistono naturalmente i CERT erogati da vendor di soluzioni ICT, a supporto della sicurezza delle stesse, in primis, e CERT che offrono un servizio commerciale generalista, sebbene con servizi specifici per settore.

La seguente Figura 2^[2] illustra una classificazione dei principali servizi “tradizionalmente erogabili” dai CERT, sebbene nessun CERT in realtà li offra tutti o comunque si concentri su tutti allo stesso modo.

Figura 2 – La tassonomia dei servizi erogati dai CERT

Già il posizionamento di un CERT rispetto alla scelta di quali servizi offrire costituisce una scelta strategica importante nella sua costituzione, ed in realtà è almeno in parte correlato all’ambito, come già accennato. Tuttavia, alla luce della complessità dello schema e del crescente focus verso la prevenzione e la gestione “a tutto campo”, oggi l’acronimo CERT ha avuto un’ulteriore evoluzione verso il significato di “Computer Emergency Readiness Team”.

Il ruolo chiave di un CERT

È opportuno focalizzare l’attenzione sul fatto che, a prescindere da tutti gli adattamenti intercorsi negli anni, il ruolo chiave di un CERT rimane quello che si esplicita nel diagramma riportato in Figura 3.

Figura 3 – Il ruolo di un CERT: 3 aree principali di attività

Come si evince dalle tipologie di attività definite accanto all’asse verticale, è un ruolo maggiormente rivolto alla creazione e implementazione di “readiness” rispetto alla gestione degli incidenti, durante tutto il ciclo di vita degli stessi.

Quindi in sintesi si parte dallo studio e dall’arricchimento di conoscenza preliminare riguardo alle fenomenologie in campo, sia rispetto all’analisi tecnologica delle singole tipologie di minacce, sia per quanto riguarda l’analisi e la modellazione dei fenomeni più generali e delle motivazioni (“perché e come oggi opera il cybercrime?”), mediante fonti esterne e collaborazione con enti analoghi, fino ad arrivare alla core competence: la capacità di dare supporto specialistico nel corso di un incidente.

E da un CERT ci si può attendere (in relazione ovviamente alla sua natura, organizzazione e specializzazione) un supporto a 360°: non solo tecnico (identificazione dell’evento, proposizione delle modalità con cui trattarlo), ma anche comunicativo, relazionale, forse legale, ecc.

Il valore aggiunto del CERT

Ultimo ma non ultimo, il valore aggiunto del CERT è la possibilità, in seguito ad un “incidente tipo”, di studiarlo, modellarlo e renderne disponibili internamente e/o esternamente le caratteristiche distintive ed identificative. Ciò, se formalizzato in modalità condivisibili e standardizzate, costituisce utilissimo riferimento futuro, in ottica di una più efficace reazione al medesimo evento.

Il tutto scarica a terra il massimo del potenziale valore nel momento in cui il threat management viene efficacemente attuato in real-time, ossia quando, grazie alle informazioni pregresse e alla capacità disponibili nella struttura, il CERT può efficacemente supportare le realtà che vi si affidano nella gestione degli incidenti legati alla sicurezza informatica.

Anche in questo caso, prima di procedere nello sviluppo della riflessione e per condividere una baseline sulle esigenze a cui un CERT risponde, è utile chiedersi a quale tipo di organizzazione giovi l’avvalersi del contributo di questo tipo di struttura. Alcune casistiche:

• quando non si sia costantemente coinvolti nel contrasto di minacce fortemente contestualizzate per cui occorre attività esterna di advisoring;
• quando si operi in settori critici;
• quando la gestione incidenti lato information security richieda forte strutturazione, e interazione con altri enti (ad esempio per ottemperare alla normativa in essere).

I punti di contatto tra il SOC e il CERT

Quanto puntualizzato sinora rispetto ai ruoli principali delle due entità SOC e CERT è finalizzato a mettere in luce un evidente punto di contatto: entrambe le realtà vengono coinvolte in quella che è la fase più critica del presidio della sicurezza informatica in ambito aziendale (ma non solo): la gestione dell’incidente.

La seguente Figura 4 è ottenuta incrociando i diagrammi relativi al mainstream di attività di SOC e CERT e si vede bene come la gestione dell’incidente rappresenti una fase comune.

Figura 4 – La gestione degli incidenti come punto di incontro tra le attività mainstream di SOC e CERT

Qui, la conoscenza pregressa che arriva dal CERT e la padronanza tecnica (contestualizzata alla realtà operativa) che caratterizza il SOC possono realmente fare la differenza, se opportunamente combinate. Come si evince dalla figura, in questa fase operano assieme professionalità differenti provenienti dalle due “anime”, e l’evento può essere trattato molto più efficacemente in quanto si uniscono le competenze di:

• persone che hanno esatta percezione dello stato dei sistemi, in tempo reale;
• persone che sanno interpretare con chiarezza il significato dei segnali, in prospettiva più ampia, e condividerne il senso e le implicazioni;

In particolare, primario elemento di valore che emerge da una gestione congiunta è che in questo modo la remediation identificata sarà “actionable”, in quanto legata tecnicamente ai sistemi su cui si è rilevata la problematica, ma sarà allo stesso tempo di portata generale, in quanto derivante da una conoscenza condivisa a livello di settore. Si esce pertanto dalla logica della pura risoluzione dell’emergenza, affrontando invece le problematiche in modo strutturato.

Riassumendo, la collaborazione di SOC e CERT (come strutture formalizzate, interne o esterne a una realtà aziendale, o anche semplicemente come ambiti di competenza) se correttamente realizzata a livello tecnico/organizzativo permette di ipotizzare il beneficio potenziale di una gestione degli eventi/incidenti di sicurezza informatica che:

• permetta l’adozione di misure concrete e immediatamente applicabili, in quanto elaborate per essere attuate sui medesimi sistemi gestiti dalla componente SOC;
• pervenga a soluzioni che risolvano il problema alla radice, o che quantomeno siano quanto di meglio si possa fare con le conoscenze del momento per adottare una soluzione definitiva, in quanto abilitate dalla conoscenza generalista detenuta dalla componente CERT.

Vedremo, nella seconda parte di questa serie di articoli, come quanto discusso sinora possa essere il punto di partenza per un’efficace/sinergica integrazione delle competenze e delle attività descritte nel caso specifico della gestione degli incidenti, e come la composizione di queste possa portare a sinergie interessanti, al di là di quelle più ovvie.

1. Ad esempio ispirandosi a http://icsa.cs.up.ac.za/issa/2013/Proceedings/Full/58/58_Paper.pdf ↑
2. www.enisa.europa.eu/publications/csirt-setting-up-guide/Fat_download/fullReport ↑

L’articolo SOC (Security operation center) e CERT: definizioni e sinergie per la sicurezza informatica proviene da Agenda Digitale.