SICUREZZA DIGITALE

Attività necessarie per la creazione di un Security Operation Center (SOC)

Un SOC è una macchina molto complessa che va mantenuta in perfetta forma da chi la utilizza

Con questo articolo vorrei cercare di dare una risposta organica alle molte domande poste da clienti, curiosi conoscenti e amici. Allo stesso tempo la mia intenzione è aiutare a capire meglio quali sono i miei compiti abituali in questo campo.

Innanzi tutto, cominciamo a definire cosa sia un “SOC”.

Per SOC intendiamo l’insieme di soluzioni tecnologiche integrate, personale altamente specializzato e l’insieme di “regole” che hanno il compito di identificare, analizzare e fornire indicazioni per identificare e porre rimedio a un attacco informatico in corso o prevedibile.

Questo ambiente dovrà fornire il massimo livello di cyber-difesa come organizzazione proattiva e reattiva da attuare per un’azienda o qualsiasi tipo di entità potenzialmente esposta a cyber-attacco indipendentemente dalla loro esposizione, relativa o assoluta, alla Big Internet.

Per la mia esperienza diretta un SOC:

• dovrebbe essere UNICO – come un abito su misura (o, nel caso specifico, un giubbotto antiproiettile ?)

• dovrebbe essere sviluppato attorno alle esigenze, alla criticità e all’organizzazione (effettiva e futura) dell’azienda o dell’entità da difendere

• dovrebbe essere DINAMICO per essere efficace – e mai statico, deve essere in costante evoluzione e adattamento a seguito di cambiamenti dell’azienda o dell’entità di qualsiasi tipo

Le ovvie conseguenze di quanto sopra dovrebbero essere chiare:

Nessun “automatismo”, auto-aggiornamento, auto-qualunque-cosa è sufficiente per gestire, da solo, un SOC efficiente. Nessuna singola scatola o soluzione o soluzione del fornitore è sufficiente per implementare un SOC.

In base alla mia esperienza, questo è il motivo per cui intraprendo sempre, senza eccezioni, una prima fase puramente consultativa di “Analisi del contesto”. In questa fase è obbligatorio analizzare l’intera organizzazione dal punto di vista della sicurezza a 360 gradi. Questa fase è molto simile a una revisione interna ISO27001 e viene applicata quindi una metodologia simile. Per questo motivo, deve essere condotto con la piena collaborazione degli utenti finali SOC.

Naturalmente, durante questa fase, la capacità del revisore è completamente focalizzata sull’ambito ultimo dell’attuazione del SOC e potrebbero sorgere facilmente ulteriori domande.

Quando questa fase è correttamente concepita ed eseguita in piena collaborazione con l’organizzazione del cliente, un elenco esaustivo di attività all’avvio del SOC diventa chiaro per me e per qualsiasi utente finale del SOC (o suo beneficiario, se si preferisce). Nella maggior parte dei casi, se non in tutti, è l’intera organizzazione del cliente a beneficiare di un SOC in quanto tutti i reparti sono, in misura più o meno significativa, digitalizzati. Per far valere questa consapevolezza, di solito preparo uno o più “executive reports” sui risultati dell’audit da condividere con le parti interessate per essere sicuri che siano a conoscenza e che siano d’accordo su ogni singolo punto.

È molto importante che le parti interessate a tutti i livelli siano indirizzate e allineate. Per questo motivo, il rapporto deve essere personalizzato per essere in grado di raggiungere le competenze, i ruoli e le capacità del pubblico di destinazione dei lettori: mentre è noioso per il CEO passare attraverso le carenti attuali configurazioni del firewall ivi elencate, sarà  meglio “illuminarlo” per capire il livello dei rischi economici e impatto che la sua attività potrebbe affrontare a causa di questo.

Sulla base delle basi appena menzionate, il prossimo passo sarà molto più semplice per tutti i soggetti coinvolti.

La fase successiva mi piace definirla come SOC Design. Il risultato dell’attività precedente guiderà (e spesso giustificherà) le decisioni tecniche e operative da prendere durante lo spiegamento del SOC stesso.

In fase di progettazione facciamo scelte tecniche e tecnologiche insieme a quelle di impatto economico, logistico e umano che l’utente finale del SOC deve mettere in atto. La mia esperienza porta alla progettazione prestando adeguata attenzione ai vincoli, ai bisogni e alle priorità dell’organizzazione. È fondamentale non perdere questo punto di vista in quanto esattamente questi elementi rappresentano blocchi molto impattanti a livello di funzionalità e budget.

La progettazione del SOC è molto interattiva e si basa sia sul progetto generale che sui risultati dell’analisi del contesto (non sottolineerò quindi mai abbastanza quanto sia critico!). Ogni decisione finalizzata in fase di progettazione deve trovare il pieno consenso tra tutte le parti interessate a cui ci rivolgiamo nella loro “lingua” individuale con una comunicazione personalizzata e assicurandosi che il messaggio e le informazioni siano espresse in modo chiaro e comprensibile.

Spesso le persone hanno una diversa percezione del SOC. Per la maggior parte di coloro che sono influenzati dalla filmografia sull’argomento, la vedono come “la stanza con un sacco di schermi sul muro e un numero uguale di personale che li controlla che all’ accendersi  di una luce rossa inizierebbe a urlare e agitarsi”: questo è quella che chiamo SOC Room. Le persone con un background IT invece visualizzano il SOC come la somma dei singoli elementi delle funzionalità SOC in un set di telco rack standard: questa è la sala SOC DataCenter.

SOC Room

La realtà è che stiamo conducendo qui due progetti distinti ma interconnessi. In effetti, entrambe le sale devono essere progettate e implementate correttamente per realizzare un SOC di prima classe in grado di crescere secondo necessità. I prerequisiti di entrambe le sale saranno un mix di esperienza dell’organizzazione di implementazione e delle esigenze dei clienti identificate nell’analisi di contesto fondamentale.

Il capitale umano è un altro aspetto spesso sottovalutato in un progetto SOC.

Un SOC è come una macchina molto complessa mantenuta in perfetta forma da chi la utilizza. Gli operatori SOC sono risorse rare e quindi un investimento significativo in termini di sviluppo delle competenze. Questa competenza, infatti, viene creata seguendo la personalizzazione del nascente SOC. La conservazione di queste risorse (“retention”), a causa della rarità e della crescente necessità del mercato, è un fattore importante su cui pianificare un’efficienza a lungo termine del SOC. È essenziale che tutte le parti pianifichino e stanzino correttamente budget per le attività inerenti alla selezione ma anche al mantenimento del fattore umano.

È propedeutico formalizzare i profili delle persone necessarie e iniziare la selezione di candidati interni potenzialmente o effettivamente disponibili nell’organizzazione al fine di pianificare ed eseguire il piano di formazione e / o procedere con un ciclo di reclutamento esterno. Ricorda! un SOC con giocatori incompetenti e inadeguati è “meno utile” per non dire quasi inutile!

Finalmente la tanto attesa fase di implementazione. Supponendo che abbiamo eseguito diligentemente e correttamente entrambe le fasi precedenti, quest’ultima dovrebbe essere priva di fattori di sorpresa, anche se la legge di Murphy proibisce di affermarlo ?!

Coloro che sono stati selezionati e che sono i  responsabili dell’attuazione (di solito anche qui rimango comunque coinvolto), assicurano e supervisionano tutti gli specialisti al fine di mettere in piedi le architetture dell’ infrastruttura del SOC. I requisiti per le configurazioni di rete, le impostazioni IT, le prestazioni e la configurazione dello storage, l’integrazione della piattaforma sono pronti per essere trasferiti allo specialista designato ma devono poi essere verificati in ogni fase del trasferimento, o almeno è così che opero io.

Le sfide più comuni legate a questa fase si riferiscono alle capacità dello specialista e alla loro chiara comprensione dell’ambito del progetto complessivo. Questo è il motivo per cui, in questa fase, non è richiesto solo un project manager professionale ma anche la piena disponibilità attiva e di controllo dell’architetto della soluzione originale, per garantire la correttezza dell’implementazione di tutte le fasi.

Altro mito da sfatare: l’ultimo dispositivo nel rack o l’ultima integrazione dell’ultima piattaforma nella SOC Datacenter Room o la configurazione finale della SOC Room non rappresentano la fine del progetto: a questo punto l’implementazione, infatti, è solo in la sua fase finale, ma non ancora alla fine.

Quando tutti i sistemi SOC sono installati, integrati e l’infrastruttura SOC è attiva e funzionante, è tempo di iniziare l’onboarding di tutti i dispositivi ed i sistemi dei clienti. Non sottovalutate lo sforzo richiesto in questa fase perché non è un problema IT minore, anzi!.

Al momento dell’implementazione, tutti i sistemi devono essere configurati ed in grado di inviare (tramite firewall e routing) eventi al cuore del SOC. Nella maggior parte dei casi ciò influisce sulle operazioni dell’organizzazione IT effettiva o dell’entità coinvolta ed è la prima volta che i due gruppi (IT e SOC) entrano in contatto diretto offrendo attività insieme. Ho sperimentato diversi ambienti in cui la segregazione, le regole, la paura e la storia poco chiara dell’evoluzione della rete creano un vuoto nella comunicazione tra server o alcuni dispositivi e il resto della rete, incluso e soprattutto con il SOC appena creato.

In queste situazioni, le attività richiedono molto tempo e diventa quasi impossibile soddisfare tutte le pregresse le attuali requisiti dei diversi giocatori. Questo mi ha portato a sviluppare e brevettare una soluzione per semplificare questo passaggio. Ne parlerò in modo più dettagliato in un’istanza separata: rimanete sintonizzati!

Il mio suggerimento è di includere un “buffer” significativo (cioè un abbondante intervallo di tempo) nella sequenza temporale di consegna per questa parte e iniziare a condividere al più presto le risultanze risultanti dell’analisi del contesto.

Quando anche l’onboarding è completo raggiungendo un buon 50% -80%, la “macchina SOC” inizierà a produrre dozzine di migliaia di eventi potenzialmente dannosi ogni giorno che richiedono ovviamente una grande ottimizzazione per poter essere gestiti e questo lo considero parte dell’implementazione.

Flussi di Eventi gestiti dal SOC

L’ottimizzazione di maggior successo si verifica quando la maggior parte della forza lavoro identificata per lavorare nel SOC è già impegnata e disponibile a partecipare a questa fase finale di integrazione: l’integrazione con gli umani!

Un ciclo di vita di un SOC, infatti, include un periodo variabile per mettere a punto i sistemi (tutti!) In base alle conoscenze acquisite su come la propria infrastruttura raggiunge un numero ragionevole di eventi potenzialmente dannosi scoperti ogni giorno. Questa fase potrebbe durare facilmente 1 anno e in alcuni ambienti grandi e complessi potrebbe raggiungere un periodo di 2 anni. Durante questo periodo il SOC si occupa idealmente dei possibili eventi campionandoli da una base enorme, cercando sempre di trovare modi per apprendere lezioni per un’ulteriore ottimizzazione per ridurre il numero di eventi in futuro. Questo è un utilizzo molto subottimale del SOC, ma è solo un inevitabile “fase iniziale” per ottenere in seguito prestazioni ottimali.

Questa fase finale offre una buona opportunità per iniziare a produrre la prima serie di politiche e procedure per affrontare il SOC e per gestire le sue indispensabili relazioni con il resto dell’organizzazione.

Back to top button
Close
Close