Ci sono vantaggi dalle possibili integrazioni tra Soc e Cert, sia per quanto riguarda le competenze e sia per le modalità di approvvigionamento.

Le competenze in campo

Ricordiamo che nelle prime due parti di questa analisi è stato definito il ruolo delle entità SOC e CERT (ad alto livello, al di là delle specifiche e oramai innumerevoli declinazioni). È stato discusso come queste entità possano/debbano cooperare nella gestione dell’incidente di sicurezza informatica, approfondendo le sinergie e i benefici che ne derivano. 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 successive)

Si è già avuto modo di accennare come vi siano competenze specifiche in ciascuna delle macro-attività che compongono le due funzioni (pur con tutti i necessari distinguo e le inevitabili e peraltro opportune commistioni). Il diagramma di Figura 2 esprime una collocazione “tipo” dei task, e permette di comprendere meglio quali siano le professionalità in gioco.

Figura 2 – Distribuzione ad alto livello di task/expertise tra SOC e CERT

Rispetto a tutto quanto detto, appare opportuno ipotizzare una distribuzione di macro-competenze che, pur ad alto livello, da un lato riconosca e dall’altro abiliti le sinergie discusse.

In particolare:

• nel SOC è opportuno che predominino le competenze tecnico sistemistiche, non solo sulla specificità degli apparati legati all’information security, ma anche sugli aspetti di sicurezza attinenti alle tecnologie in uso nell’azienda, e sulle implicazioni tra necessità di modificarle e disponibilità dei sistemi. Si noti bene: volendo ipotizzare una quantificazione ad alto livello della suddivisione di ambito tra le competenze sistemistiche in gioco, l’esperienza di chi i SOC li esercisce testimonia che non è irrealistico parlare di un 80% di competenze su sistemi specificamente atti ad erogare funzionalità di information security rispetto a un 20% con competenze di sicurezza in altri ambiti sistemistici. Ciò, alla luce della necessità di un continuo fine-tuning e troubleshooting dei sistemi monitorati, nonché per abilitare lo scambio informativo verso il CERT relativo agli eventi rilevati, illustrato.
• nel CERT predominano competenze generali sulla sicurezza informatica sia in termini di fenomeni/motivazioni, che di analisi tecniche, che di processo/comunicazione.

Il fatto poi che una delle due funzioni sia interna (o strettamente internalizzata), migliora l’efficacia nella risposta all’incidente, grazie alla maggiore contestualizzazione e conoscenza specifica del contesto operativo.

Complementare un’unità o funzione interna con capability esterne

L’analisi, per quanto ad alto livello, delle competenze in gioco e della loro collocazione tra SOC e CERT permette di intuire come sia in effetti probabile che solo un ristretto numero di aziende di rilevanti dimensioni e operanti in contesti critici agiscano dotandosi internamente di entrambe le funzioni. Ciò, alla luce della complessità ipotizzabile per la gestione delle competenze in gioco, nonché operativamente per la numerosità dei professionisti coinvolti.

Tuttavia, i benefici che una realtà aziendale può ottenere mediante una protezione congiunta attuata da un SOC ed un CERT che cooperino sono stati ben messi in luce, ed è altamente probabile che organizzazioni comunque articolate e complesse siano già dotate di una di queste funzioni.

L’organizzazione può evolvere il proprio posizionamento di partenza secondo direttrici distinte, in relazione al punto di partenza.

Integrare un CERT esistente con un SOC esterno

Nel caso in cui l’azienda abbia un CERT interno, o collabori strettamente con un CERT di settore, è possibile per essa approvvigionarsi esternamente delle funzioni proprie di un SOC (intese come strumenti ma anche competenze, sino ad un certo punto) di raccolta e analisi degli eventi, nonché del presidio di primo livello (idealmente h24) delle segnalazioni. In tal caso, per massimizzare il livello di contestualizzazione nella gestione di eventuali incidenti, si può ipotizzare che:

• a fronte dell’identificazione da parte del personale esterno di primo livello di un potenziale evento di interesse, l’escalation avvenga sul team di gestione interno in forza al CERT;
• in relazione al tipo di servizio esterno acquisito, ma anche al tipo di eventi “elementari” che si desidera monitorare, possa insorgere la necessità di specifiche configurazioni tecniche sui sistemi, da attuarsi tipicamente con la collaborazione di personale interno. Le dotazioni tecnologiche “core”, invece (SIEM/log collector) possono essere acquisite “as a service”;

Integrare un SOC esistente con un CERT esterno

Nel caso in cui l’azienda abbia un SOC interno, è possibile per essa approvvigionarsi esternamente di servizi di “threat intelligence” ed “early warning”, nonché avvalersi di collaborazioni esterne (laboratori o soggetti anche in ambito accademico) per l’analisi di minacce contestualizzate e la creazione di “indicatori di possibile incidente” a beneficio del SOC. In tal caso, sempre per massimizzare il livello di contestualizzazione nella gestione di eventuali incidenti, si può ipotizzare che:

• le segnalazioni provenienti dal CERT esterno vengano comunque riportate al team di secondo (o terzo) livello presente nel SOC, che sarà direttamente coinvolto nella gestione della problematica interna. È altamente probabile che tale nucleo di persone sia effettivamente interno all’azienda o comunque dotato di elevata conoscenza di contesto;
• in relazione al livello di formalizzazione atteso negli scambi informativi necessari (ad es. per misurare il servizio offerto dal CERT e/o per tracciare tutte le azioni di prevenzione e di reazione), può insorgere la necessità di dotare il gruppo interno di tool per knowledge management e/o integrare il sistema di ticketing per la gestione delle segnalazioni esterne (o approvvigionarsi di tali strumenti “as a service”);

Benefici attesi dall’integrazione tra SOC e CERT

Generalizzando le considerazioni sviluppate in precedenza, e a prescindere dal posizionamento di partenza, avendo una delle due funzioni interne emerge comunque il fatto che è possibile approvvigionarsi esternamente delle competenze per “creare” (o erogare) la funzione mancante, ottenendo così i benefici ipotizzabili dall’interazione tra le due, con l’accortezza di mantenere il presidio del “blocco funzionale” individuato per la gestione degli incidenti. Si sottolinea naturalmente l’opportunità di creare e mantenere internamente ruoli e conoscenze chiave, soprattutto qualora queste ultime diventino fortemente contestualizzate alla realtà di riferimento.

A complemento dell’ampia trattazione sviluppata nel corso dei tre interventi, si possono delineare i seguenti benefici attesi dall’integrazione tra SOC e CERT (interni o esterni, comunque contestualizzati alla realtà aziendale o almeno al settore di operatività):

• maggiore efficacia e tempestività nell’individuare gli eventi dall’interno, eventualmente in ottica “anticipatoria” qualora il CERT attui un efficace processo di modellazione delle minacce le cui descrizioni possano essere fornite in input al SOC, in forma “actionable”, ossia rimappabile con effort limitato sulle configurazioni dei sistemi in campo;
• migliore riuso delle conoscenze acquisite dalle attività di post-incident analysis, in relazione a quanto sopra. L’analisi effettuata dal CERT non sfocia più solamente in “generici alert” al personale tecnico, ma si concretizza nel tuning dei sistemi di detection effettivamente in campo;
• possibilità di anticipare l’innesco di alcune analisi da parte del CERT, a fronte di segnalazioni di “anomalie” provenienti dal SOC che ancora non siano riconosciute come “incidente”. Il CERT è pertanto nelle condizioni di operare su dati “di prima mano” e potenzialmente di anticipare minacce sul nascere;
• miglioramento, allargando la vision rispetto all’ambito puramente tecnico e di processo, dell’efficacia dello spending sui processi e sulle tecnologie di detection e monitoraggio in campo, alla luce della possibilità di studiare l’effettiva casistica e distribuzione degli eventi, ma soprattutto la loro correlazione con le minacce alla sicurezza informatica. Iper-semplificando, l’attività di analisi di un CERT sulle segnalazioni rilevate e riportate da un SOC può arrivare a mettere in luce fenomeni quali:
  • eccessiva proliferazione di segnalazioni da parte di sorgenti sulle quali di fatto non si rileva un numero significativo di attacchi (si può considerare tale casistica “rumore”, ma occorre considerare che solitamente la raccolta e il processing dei log ha un costo variabile con i volumi degli stessi, sia in termini di licenze che di potere computazionale e spazio di storage richiesto);
  • raccolta insufficiente di segnali e log da sorgenti su cui invece si concentrano o si riflettono attacchi ripetuti e significativi. Eventuali “saving” derivanti dal punto precedente possono essere virtuosamente reindirizzati a rafforzare queste casistiche;
  • In generale, porzioni di detection mancanti o non coperte adeguatamente, che possono costituire una casistica del punto precedente e si presta ad analoga soluzione.

Al di là di ulteriori considerazioni specifiche, questi benefici, assieme ad altri discussi nel corso della trattazione complessiva, ad esempio sull’efficientamento nella gestione degli incidenti, sul miglioramento delle competenze, e sul supporto all’attuazione della strategia di sicurezza informatica, possono ampiamente ripagare lo sforzo di integrazione in senso tecnico e organizzativo che, va riconosciuto, può essere anche significativo.