La collaborazione tra SOC e Cert per gestire un attacco informatico

Nella prima parte di questa analisi è stato definito il ruolo (ad alto livello, al di là delle specifiche e oramai innumerevoli declinazioni) delle entità SOC e CERT. Si richiamano solo due diagrammi illustrativi utili a contestualizzarne ad alto livello l’ambito di azione e a meglio comprendere la progressione dell’analisi (Figura 1).

Figura 1 – Schematizzazione ad alto livello degli ambiti di azione per SOC e CERT e dei punti di contatto nella gestione degli incidenti (utile per una miglior comprensione dei diagrammi successivi)

Si focalizzerà ora il ragionamento sul tema specifico della collaborazione tra queste entità nella gestione dell’incidente di sicurezza informatica e ai benefici che ne derivano.

La collaborazione tra SOC e CERT nella gestione degli incidenti

Approfondendo i concetti sviluppati sinora, è utile anche ipotizzare le strategie di gestione applicabili qualora le segnalazioni che iniziano l’iter di gestione dell’incidente provengano dalla componente SOC o da quella CERT. Questo al fine di illustrare come il processo complessivo tragga benefici da una gestione congiunta.

Il punto di avvio sarà rappresentato da segnalazioni di natura differente tra loro. In particolare, con riferimento alla Figura 2, si esemplificano due tipologie di interazione:

• Caso A: il rilevamento si origina in ambito SOC, pertanto sarà associato a elementi di natura maggiormente tecnica;
• Caso B: l’alert nasce a livello CERT, quindi di natura maggiormente metodologica/informativa.

Figura 2 – Una gestione congiunta degli incidenti di sicurezza delle informazioni – 2 casistiche.

Riferendosi quindi alla figura citata (ove in blu è evidenziata una modalità di gestione “tecnocentrica” che privilegi la risoluzione immediata, prevalentemente – se non esclusivamente – a carico del SOC), si può ipotizzare una gestione congiunta che per i due casi ripercorra i seguenti passi:

• Caso A:
  • gli strumenti tecnici del SOC rilevano condizioni anomale, magari non ancora note come associabili a un potenziale incidente;
  • la condizione è analizzata dal CERT, che sulla base delle conoscenze raccolte (anche esternamente) può definirne la portata;
  • SOC e CERT interagiscono “provando” le possibili soluzioni e applicandole in tempo reale;
  • la soluzione finale, adeguata alla realtà di riferimento, è adottata.
• Caso B:
  • le attività di intelligence e di relazione del CERT mettono in luce una minaccia potenzialmente applicabile alla realtà monitorata;
  • il CERT ne segnala gli “estremi”, contestualizzandoli (in forma di indicatori “actionable”) all’interno di tale realtà;
  • Il SOC, applicando ricerca di eventi su tale base, può ora rilevare effettivamente la presenza del threat;
  • SOC e CERT interagiscono “provando” le soluzioni e applicandole in tempo reale;
  • la soluzione finale, adeguata alla realtà di riferimento, è adottata.

Tutti i percorsi terminano ovviamente con l’identificazione di una soluzione tecnica “che funzioni” nel caso immediato e contingente.

Tuttavia, è immediato notare come il coinvolgimento di entrambe le tipologie di competenze sia estremamente naturale e quasi “fisiologico”. Infatti, una stretta integrazione tra le funzioni in questa fase può agevolare i processi di gestione, rendendo molto più “frictionless” le comunicazioni e le interazioni e agevolando la convergenza verso la soluzione finale.

Inoltre, sempre con riferimento al diagramma appena presentato e come messo in evidenza nella seguente Figura 3, da una collaborazione come quella appena delineata si crea facilmente un “circolo virtuoso”.

Figura 3 – Le attività congiunte abilitano miglioramenti in entrambe le funzioni

In pratica, quel che è auspicabile avvenga in un modello di interazione quale quello delineato, e che ne ripaga ampiamente in termini di valore lo sforzo organizzativo, è che:

• da un lato, come follow-up degli incidenti di tipo A, si è avuto un arricchimento delle capacità/conoscenze del CERT, che ha acquisito nuova conoscenza non solo in termini di un possibile problema ma anche rispetto alla soluzione efficace ad esso associata (certamente da studiare, analizzare, contestualizzare, tuttavia un utilissimo elemento di condivisione);
• dall’altro, in seguito al tuning dei sistemi di detection che si associa agli incidenti di tipo B (e ne abilita la discovery), ora l’azienda è equipaggiata per rilevare in autonomia condizioni analoghe o similari.

Le sinergie allargate

Quanto esposto sinora può già giustificare l’adozione di un modello di presidio della sicurezza informatica che coniughi competenze tipiche di un SOC e di un CERT. La maggior efficacia ipotizzabile rispetto all’attività core, nonché i miglioramenti in termini di proattività di detection, rappresentano infatti un valore aggiunto immediato.

Tuttavia, è possibile ampliare l’analisi e mettere in luce come le sinergie tra le due funzioni non si concludano qui, ma anzi si estendano oltre il ruolo comune legato alla gestione degli incidenti. Nel seguito si ripercorrono due esempi di queste “sinergie allargate”.

Definizione e al miglioramento evolutivo della cybersecurity strategy

Un’efficace integrazione tra le attività del CERT e del SOC può riflettersi con benefici rilevanti sulla formulazione e sull’aggiornamento della strategia di sicurezza informatica dell’organizzazione, sia in termini di identificazione degli ambiti di presidio, sia per quanto riguarda l’adattamento dell’allocazione delle risorse a posteriori, in ottica di miglioramento continuo.

Ciò è rappresentato ad alto livello in Figura 4, dove si vede come il SOC e il CERT, con alcune delle loro attività “tipiche”, possano (o debbano) ricevere ma soprattutto fornire utili indicazioni alla funzione incaricata.

Figura 4 – Come le attività di SOC e CERT possono migliorare la definizione della strategia di sicurezza informatica

In particolare si possono identificare le seguenti relazioni:

• Il CERT può aggiornare le funzioni preposte alla formulazione e alla manutenzione dell’information security strategy (CISO, board of directors, ecc.) rispetto ai rischi emergenti, permettendo a questo/i soggetto/i di scegliere in modo informato e consapevole (previe le opportune semplificazioni) quali minacce (o classi/ambiti di minaccia) mantenere monitorati in relazione alla connotazione del business:
  • si noti che anche la capacità del CERT, grazie a competenze non solo tecniche ma anche di comunicazione e condivisione, di “semplificare” gli elementi per la valutazione delle minacce pur mantenendo correttezza e significatività dei messaggi è una caratteristica fondamentale che porta elevato valore aggiunto;
  • in risposta, i soggetti deputati alla formulazione della strategia indicano appunto al CERT le specifiche tipologie di minaccia su cui ritengono opportuno essere informati. Ovviamente, ciò non esclude il ruolo proattivo del CERT nell’emettere alert ritenuti rilevanti per il target, tuttavia aiuta a definire e precisare l’attività del CERT stesso
• Il SOC può (o deve) essere “alimentato” sin dal lato più tecnico delle sue attività con le indicazioni rispetto agli eventi tecnologici (in senso lato, è poi compito del SOC declinarle e contestualizzarle ai sistemi in campo) da monitorare. Il SOC dovrà essere adeguatamente munito di risorse in tal senso, al fine di instrumentare adeguatamente il perimetro ICT presidiato ed essere in grado di raccogliere le indicazioni opportune:
  • di contro, il SOC può fornire dati concreti rispetto alla rilevanza (anche numerica) dei vari fenomeni di cui attua il monitoraggio tecnologico, anche in ottica di ottimizzazione della spesa. Ad esempio, il SOC può segnalare, come follow-up delle proprie attività di analisi e rielaborazione, quali “collettori” hanno raccolto ampie quantità di dati, magari eccedenti il dimensionamento dei collettori stessi che devono pertanto essere potenziati, e quali fonti dati si sono invece rivelate poco ricche di informazioni;
  • si noti come la scarsa ricchezza informativa di cui sopra possa essere legata alla quantità ma anche della qualità. Pertanto, dal SOC possono pervenire utili indicazioni sia per adeguare l’eventuale licensing dei prodotti di raccolta/monitoraggio di specifici fenomeni (es. “riducendo il numero di sonde IDS si ottiene in linea di massima lo stesso risultato”), sia utili a compiere scelte/esclusioni sulle sorgenti utilizzate (es. “i dati che rileviamo con questa sonda li abbiamo già, in forma più ricca e precisa, monitorando i log di sistema”);
  • il valore aggiunto di questi riscontri forniti dal SOC è che le considerazioni di cui sopra possono essere non solo numeriche, ma anche legate all’efficacia/utilità del dato ai fini della threat detection (es. “raccogliere questo dato è poco utile, in quanto in realtà non pare associarsi come previsto alle minacce”).

Le tipologie di relazione espresse sopra sono puramente esemplificative, ma aiutano a comprendere come una information security strategy supportata da indicazioni precise e contestualizzate provenienti sia dall’intelligence esterna che “dal campo”, ossia dai dati sui sistemi, abbia una potenziale efficacia attesa superiore, rispetto ad una formulazione avulsa da riscontri reali.

La “cristallizzazione” della conoscenza a beneficio della realtà monitorata

Un altro esempio di sinergie tra le attività del SOC e del CERT è legato alla possibilità di raffinare le analisi post-incidente svolte dal CERT attraverso i dati derivanti dall’effettiva detection operata dal SOC, migliorando così la contestualizzazione e la formalizzazione della conoscenza acquisita. Ciò è intuitivo, ed è illustrato in Figura 5.

Figura 5 – Come le attività di SOC e CERT possono migliorare l’analisi post-incidente da una prospettiva lesson-leart contestualizzata all’ambito di operatività

Come si osserva, dall’interazione emerge la possibilità concreta di attuare l’analisi degli incidenti in ottica lessons-learnt, promossa e incoraggiata dagli standard di settore.

In particolare dalle competenze del CERT può (e deve) auspicabilmente pervenire lo studio dei principali incidenti avvenuti, nella realtà aziendale specifica o in altri contesti simili monitorati, unitamente a:

• indicatori tecnologici per un loro riconoscimento che sia quanto più anticipato possibile;
• raccomandazioni “actionable” e contestualizzate alla realtà monitorata per la gestione/ risoluzione della minaccia qualora dovesse presentarsi.

Gli “indicatori” menzionati devono essere creati e comunicati al SOC in forma utile perché il SOC possa trasformarli “con effort ragionevole” in configurazioni tecniche sui sistemi, sia per la detection che per la protezione a priori.

Il SOC di contro può/deve fornire al CERT:

• riscontri sull’effettiva frequenza di accadimento di quanto modellato (e valutazione sull’appropriatezza del modello formulato dal CERT ai fini della detection/ reaction);
• Indicazioni su “macro anomalie” frequenti, ancora non modellate in relazione a possibili minacce.

Il primo dei due elementi permette al CERT un raffinamento progressivo della comprensione di specifiche minacce, specie se tale condivisione proviene da molteplici realtà gestite o comunque da un ecosistema tecnologico di sufficiente complessità. Il secondo abilita lato CERT lo studio di eventuali nuove minacce qualora le anomalie vengano valutate come tali.

Avendo esplorato le possibili sinergie derivanti da una stretta collaborazione tra le strutture SOC e CERT, nel successivo approfondimento si valuteranno gli aspetti legati all’integrazione delle competenze.