Digital Trends

Security Operations Center: parla Davide del Vecchio di Fastweb

Nell’ambito delle interviste ai Security Operations Center Manager, abbiamo incontrato Davide Del Vecchio, esperto di informatica e responsabile del gruppo di Enterprise Security Operations di . Ha iniziato come smanettone nel campo della ricerca e sviluppo e l’ethical hacking per poi spostarsi sulla gestione degli incidenti ed il management.

Per iniziare abbiamo chiesto quale sia la definizione di che, per il tipo di lavoro che svolge quotidianamente, ritiene più adeguata e la scelta è ricaduta su quella indicata dal SANSUn Security Operations Center è una squadra centralizzata di monitoraggio della sicurezza aziendale organizzata allo scopo di migliorare l’approccio al rischio dell’organizzazione attraverso l’uso di tecnologie e processi utili alla rilevazione, l’isolamento, l’analisi e la mitigazione degli incidenti di sicurezza”.

La sfida che si trova ad affrontare un SOC Manager è resa ardua da diverse componenti avverse: la compressione e limitazione del budget che affligge ogni ambito aziendale, il difficile approvvigionamento di risorse adeguatamente skillate (sia in termini di quantità che di qualità), la vastità ed eterogeneità della tecnologia presente sul mercato (sia quella a beneficio degli utenti finali che quella con cui si trovano a lavorare ogni giorno gli specialisti del SOC) e in ultimo il progredire incessante in termini qualitativi e quantitativi delle performance degli attaccanti. Di questi fattori qual è, a tuo parere, quello che maggiormente rende difficile il compito del SOC di cui sei a capo?

DavideDelVecchio

Davide del Vecchio – Responsabile SOC Fastweb

Il compito più complesso che mi trovo a dover affrontare è sicuramente quello legato alla componente umana. È vero, le minacce evolvono e ogni giorno ci si trova ad affrontare una nuova sfida; questo alla lunga potrebbe essere stancante, ma queste difficoltà, paragonate alla gestione delle professionalità che crescono e si sviluppano in un SOC, finiscono in secondo piano. Già trovare delle persone disposte a mettersi in gioco, a crescere ad imparare con passione mettendoci impegno è complesso, trattenere i talenti è ancora più difficile. È necessario un mix magico di formazione, possibilità di crescita e (ovviamente) anche stimoli economici che non sempre è possibile soddisfare. D’altronde quando ci si trova davanti ad una minaccia tecnologica è sempre possibile individuare una soluzione che è possibile ripetere al ripresentarsi della stessa. Uno stesso problema umano invece, declinandosi su ogni individuo in maniera diversa, potrebbe avere ogni volta una soluzione completamente diversa. È uno scenario a cui noi informatici non siamo abituati a confrontarci.

Un altro ambito che può contribuire a rendere maggiormente efficiente un SOC è l’automazione. Automatizzare il più possibile alcuni processi può eliminare alcuni “colli di bottiglia” in fase di classificazione ed eventualmente di escalation. Esistono sul mercato strumenti efficaci che permettono di automatizzare alcune fasi successive alla detection di un incidente di sicurezza?

Ho visto di recente uno strumento che sto testando e che sembra molto interessante, ha vinto anche dei premi al Blackhat di quest’anno e si chiama Phantom. E’ un framework di automazione delle Security Operations, funziona da raccordo tra varie tecnologie di sicurezza e non (mail server, sandbox, IPS, SIEM, etc) ed è in grado di automatizzare azioni e conseguenze (facendo scripting in python) sulla base anche di autorizzazioni a più livelli. Non l’ho ancora testato a dovere ma sembra molto promettente. Per di più utilizza un approccio “community-driven” che probabilmente è l’unica maniera per riuscire a star dietro alla velocità con cui la sicurezza evolve. Si può scaricare una versione gratuita chiamata “community edition”.

È innegabile che all’interno di un SOC la piattaforma SIEM rappresenti un elemento cardine. Proprio per l’importanza che tale strumento tecnologico riveste, ritieni pericoloso dal punto di vista strategico legarsi a una determinata soluzione che magari in un certo momento rappresenta l’optimum, mentre nello scenario dinamico della sicurezza di oggi potrebbe non essere altrettanto adeguato in futuro? È possibile che si generi una sorta di lock-in da cui è difficile svincolarsi? Se sì, esistono precauzioni e metodologie che possono mettere in grado un SOC di “prescindere” dalla soluzione tecnologica sottostante anche se si parla di uno strumento pivotale come il SIEM?

Il pericolo del lock-in è concreto, per questo ritengo estremamente importanti due elementi: uno strumento flessibile e delle competenze che permettano di personalizzarlo. Avere la flessibilità e le competenze consente di non ancorarsi a logiche che la tecnologia impone, con il rischio di costruire processi e procedure che ruotano attorno a specifiche funzionalità del prodotto. Il problema di noi tecnologi è che spesso finiamo per farci dominare dalla tecnologia, dimenticandoci che la tecnologia deve essere sempre uno strumento al nostro servizio, mai il fine.

Un’altra importante sfida che si trova ad affrontare un SOC Manager è quella di dimostrare il valore delle proprie attività al “business”. In passato era molto complicato far comprendere al management l’importanza di dotarsi di adeguate strutture che tutelino la sicurezza dell’organizzazione, ora in taluni casi si assiste al fenomeno contrario: un management “illuminato” spinge fortemente sulla sicurezza (magari perché incalzato da norme e regolamenti) e la struttura tecnica sottostante fatica a seguire l’impulso che viene dall’alto, soprattutto per l’oggettiva difficoltà dell’impresa. Per dimostrare il proprio valore, il SOC, il suo manager e la sua squadra devono fornire risultati misurabili. È necessario quindi stabilire dei KPI (Key Performance Indicator) e promuovere un circolo virtuoso di miglioramento continuo (Continual Service Improvement). All’interno del tuo SOC sono previste misurazioni di KPI? È previsto un percorso ciclico di miglioramento continuo?

Per riuscire a governare è necessario capire e per riuscire a capire è necessario misurare. Prendere dei punti di riferimento, degli indicatori per poi fissare degli obiettivi di miglioramento. È naturale quindi che all’interno di ogni SOC vi siano dei KPI ed è necessario che questi KPI siano concordati con il management, questo per essere certi che i risultati siano anche comprensibili a chi poi valuterà il nostro lavoro. Non in tutti i SOC ci sono gli stessi KPI, è chiaro che i KPI possono variare nel tempo a seconda dell’evoluzione delle minacce ma è chiaro anche che non dipendono solo da fattori esterni ma anche interni all’azienda, perché ogni azienda ha asset completamente diversi da proteggere, quindi è normale che debbano esserci KPI diversi. Alcuni dei KPI che utilizziamo sono il tempo medio che occorre per chiudere un incidente, in quanti minuti (o secondi) reagiamo e gestiamo un alert, etc. Ma i numeri espressi dai KPI sono sempre da analizzare in maniera critica ed approfondita. Non necessariamente il diminuire di un KPI, come ad esempio può essere quello del numero degli incidenti, è un dato positivo. È anche possibile infatti che qualche tecnologia non stia più funzionando correttamente oppure che qualcuno stia sbagliando nell’applicazione di qualche procedura. È per questo che abbiamo una dashboard aggiornata in tempo reale e che mensilmente rivediamo e discutiamo i risultati dei KPI, una consuetudine che ci porta a ritoccare e migliorare continuamente processi, procedure e tecnologie.

Esistono diverse pubblicazioni da parte del NIST riguardanti la sicurezza, alcune specificamente relative all’ambito dell’incident handling (come la NIST SP.800-61 r2), in questa pubblicazione viene definito ed identificato il ciclo di vita di gestione di un incidente come composto da Preparation, Detection & Analysis, Containment, Eradication & Recovery e Post-incident Activity. Le più note al pubblico (e ai fruitori finali del servizio) sono probabilmente le due centrali in elenco anche se risultano importantissime anche la fase di “preparation” e quella di “post-incident”. In questo tipo di pubblicazioni è possibile trovare materiale prezioso per la progettazione e la gestione di un SOC. Nella creazione del tuo SOC hai attinto a questo tipo di documenti? In quale delle fasi sopra elencate è stato più utile aderire a certe indicazioni e quali suggerimenti sono risultati più applicabili alla realtà che ti trovavi ad affrontare?

Prendere spunto dalle best practice è essenziale ma è assolutamente necessario adattarle alle proprie esigenze. Da circa 4 anni, raccogliamo tutti gli incidenti che gestiamo tramite il SOC e che impattano l’Autonomous System di Fastweb (una base di circa 6 milioni di indirizzi IP pubblici), li aggreghiamo ed anonimizziamo e ne estrapoliamo statistiche sugli incidenti più frequenti. Per tutti gli incidenti più frequenti costruiamo una metodologia di gestione dell’incidente basata proprio sulle linee guida del NIST. Noto spesso un approccio estremamente teorico alla sicurezza informatica, con risultati che alle volte si dimostrano a dir poco disastrosi. Quello che io reputo il giusto approccio è invece un mix più orientato verso la pratica ma che abbia basi solide nelle best practice consolidate. D’altronde non dobbiamo mai dimenticare che il nostro obiettivo è evitare il maggior numero possibile di incidenti ed allo stesso tempo, quando inevitabilmente accadranno, riuscire a gestirli nel minor tempo possibile.

Sei a capo del SOC di Fastweb ormai da parecchio tempo e nel corso degli anni il panorama dell’information security si è modificato in maniera importante, sia dalla parte dei “buoni” che dei “cattivi”. Qual è la tua visione sull’evoluzione delle minacce e degli attacchi durante questi ultimi anni?

L’idea di hacker che molte persone hanno, cioè quella del ragazzino adolescente in felpa con cappuccio che da casa sua entra nei server della NASA, è un’idea legata al passato. Forse 15-20 anni fa poteva corrispondere al vero, ma ormai non è assolutamente più così. Da una parte i ragazzini curiosi sono stati soppiantati da veri e propri cyber criminali, che semplicemente utilizzano Internet come mezzo per effettuare truffe, estorsioni, furti, ecc. Da un’altra l’informatica e la connessione ad Internet sono entrati a far parte del nostro quotidiano e gli “smart object” (o Internet of Things) sono una realtà molto più presente di quanto possiamo immaginare. Molti oggetti infatti son già connessi ad Internet da anni in maniera “trasparente” rispetto alla nostra percezione. Anche se spesso non ce ne rendiamo conto, praticamente tutto ormai è connesso ad Internet o raggiungibile tramite una rete IP: macchinari, telecamere, metropolitane, treni, automobili ed ovviamente tutti i nostri telefoni. Il problema è che la stragrande maggioranza di questi dispositivi “smart” non è affatto smart in termini di security. Questi due fattori messi insieme hanno portato ad un mix estremamente pericoloso, specialmente se combinati con il fattore di rischio estremamente basso di essere “beccati”.

Luigi Cristiani

Luigi Cristiani

Luigi Cristiani è il responsabile dell’infrastruttura di rete e trasmissione dati di Cedecra Informatica Bancaria, centro servizi informatici che opera al servizio delle Banche di Credito Cooperativo in Emilia-Romagna. Laureato in Scienze dell’Informazione all’Università di Bologna ha, nel corso degli anni, maturato interesse e passione per i temi della sicurezza informatica, con il convincimento che le problematiche di sicurezza vadano condivise e discusse non solo fra gli addetti ai lavori, bensì portate all’attenzione del pubblico più vasto possibile.

Twitter LinkedIn 

Clicca per commentare

Commenti e reazioni su:

Loading Facebook Comments ...

Lascia una replica

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *

No Trackbacks.

Inizio
Share This