Il termine XDR sembra oggi la “buzzword” del momento….tutti parlano di XDR, tutti fanno XDR!! Ma sappiamo esattamente di cosa si tratta?
In questo articolo cercheremo di spiegare come nasce, cosa è, come selezionare la migliore soluzione XDR per la propria organizzazione e come utilizzare XDR per far maturare i SOC.
Perché esiste il mercato XDR?
Il mercato XDR (Extended Detection and Response) è emerso come una reazione diretta all’attuale panorama della sicurezza informatica.
In particolare, è possibile identificare alcune tendenze che hanno favorito lo sviluppo di tale mercato, nello specifico:
- Organizzazioni distribuite e complesse, perimetro diluito e adozione del cloud = incremento esplosivo di vettori e tecniche di attacco
Le organizzazioni moderne sono caratterizzate da processi aziendali sempre più distribuiti e complessi, archiviazione dei dati distribuita e adozione del cloud per un numero sempre maggiore di applicazioni. Per gli attaccanti questo ha significato avere a disposizione un numero più elevato di vettori di attacco, che associato con tecniche sempre più sofisticate ha determinato una vera e proprio esplosione di attacchi informatici.
- Le soluzioni di sicurezza verticali non sono in grado di difendere adeguatamente le organizzazioni su tutti i vettori di attacco
A causa della varietà e della natura dinamica degli attacchi informatici, il mercato è stato inondato da numerose soluzioni e strumenti di sicurezza come firewall, sistemi di protezione della posta elettronica, CASB, EDR, Web gateway, IPS, NDR, IAM… e l’elenco di acronimi potrebbe continuare. Ogni soluzione di sicurezza esamina un singolo (o talvolta più) canale o vettore di attacco, ma nessuna soluzione può coprirli tutti. Supportare il rilevamento, l’indagine e la risposta alle minacce (TDIR – Threat Detection, Investigation and Response) in modo adeguato è difficile poiché le minacce moderne arrivano in qualsiasi numero e combinazione di vettori e canali.
- I SIEM tradizionali sono diventati inefficienti nel tentativo di affrontare tutti i possibili use case di sicurezza odierni
Esiste già una categoria di soluzioni che aiuta a combinare e centralizzare le informazioni provenienti dalla miriade di soluzioni di sicurezza presenti all’interno di un’organizzazione per guardare la sicurezza da una prospettiva più ampia: i SIEM. Ma i SIEM tradizionali hanno mantenuto fondamentalmente lo stesso approccio e la stessa architettura mentre attraversavano un enorme cambiamento dello scenario della cyber security. E in questo processo, quello che doveva essere un loro punto di forza – la flessibilità e la personalizzazione – è diventato un ostacolo. I SIEM tradizionali, che oggi stanno cercando di affrontare i diversi casi d’uso utilizzando il loro approccio precedente, continuano a diventare sempre più difficili da rendere operativi e mettere a punto, a causa del numero di variabili e funzionalità disponibili. Impiegare mesi per implementare una soluzione SIEM e ancora di più per continuare a personalizzarla e aggiungere nuove regole non è più un’opzione praticabile.
Il punto di rottura – dai SIEM tradizionali al XDR ai “nuovi” SIEM
La reazione del mercato alle tendenze di cui sopra è stata:
- La nascita del mercato XDR
- La necessità per i SIEM tradizionali di adattarsi ed evolvere
XDR è uno strumento chavi in mano, di tipo SaaS, che un team di sicurezza o IT può attivare e funziona. XDR nasce per rendere più efficienti i processi TDIR (Threat Detection Investigation and Response) tramite una tecnologia prescrittiva e focalizzata sul raggiungimento dei risultati. Invece di dedicare tempo alla personalizzazione infinita del SIEM per gestire più casi d’uso, gli analisti possono concentrarsi immediatamente sul rilevamento delle minacce e sulla risposta a problemi concreti e reali come credenziali compromesse o malware in modo da riportare l’organizzazione ad uno stato ottimale nel modo più veloce ed efficiente possibile.
Open XDR versus Native XDR
Oggi esistono due tipologie diverse di XDR: Open e Native.
Per capire in cosa consistono e quale delle due può essere la scelta migliore per un’organizzazione, iniziamo a comprendere quali sono gli elementi costitutivi di una piattaforma XDR.
Una soluzione XDR è in genere costituita da tre set di funzionalità principali: front-end, back-end e contenuto. Il front-end è costituito dai “sensori” che generano dati di telemetria di sicurezza, come CASB, EDR, IAM, soluzioni DLP e altri. Il back-end acquisisce tutti i dati di telemetria, i log e le informazioni di contesto, e svolge le attività di correlazione dei dati, l’analisi avanzata, il rilevamento delle minacce, l’indagine, l’orchestrazione degli strumenti di sicurezza esistenti e l’automazione della risposta.
Il terzo componente critico di qualsiasi XDR di successo è il contenuto. Senza contenuti preconfezionati e prescrittivi che leghino questi elementi a casi d’uso di sicurezza specifici, è impossibile ottenere i vantaggi di semplicità, automazione e risultati promessi da XDR.
Che cosa è un Native XDR?
Un Native XDR è un ecosistema chiuso che offre sia le funzionalità di front-end che generano i dati sia quelle di back-end di analisi e processo. Una soluzione Native XDR dovrebbe essere in grado di rendere disponibili tutte le tipologie di sensori necessari per garantire la corretta gestione degli use case XDR, come ad esempio endpoint, network, cloud, identità, mail, etc., così come le funzionalità di back-end in grado di svolgere le attività di rilevamento, investigazione e risposta alle minacce basandosi sui dati acquisiti con i sensori stessi.
I fornitori di soluzioni Native XDR possono essere sia vendor EDR, che stanno espandendo la loro offerta includendo nuovi sensori e capacità di back-end come l’Advanced Analytics, oppure vendor di piattaforme di sicurzza in grado di proporre diversi strumenti di sicurezza che stanno cercando di integrare sempre più per fornire funzionalità di tipo XDR.
Che cosa è un Open XDR?
Una soluzione Open XDR è basata principalmente sulle funzionalità di back-end e integra “out of the box” i contenuti richiesti in tutte le fasi TDIR (Threat Detection, Investigation and Response) per risolvere facilmente i casi d’uso dei SOC. Le soluzioni Open XDR devono integrarsi con tutta l’infrastruttura IT e di sicurezza esistente di un’organizzazione, quindi correlare e analizzare tutti i dati rilevanti e infine automatizzare e ottimizzare i flussi di lavoro TDIR, rendendo più facile e veloce per i team SOC rispondere agli incidenti. Poiché gli stack di sicurezza sono diventati più complessi e disgiunti nelle organizzazioni, gli Open XDR agiscono come un unico piano di controllo su più prodotti e fornitori. Ciò fornisce visibilità e consente l’orchestrazione e l’automazione delle azioni (simile alle funzionalità SIEM e SOAR) in modo che i team SOC non debbano eseguire flussi di lavoro manuali su una miriade di strumenti.
Pro e contro dei due approcci, i.e. che tipo di soluzione XDR va bene per la mia organizzazione?
Per le organizzazioni che fanno affidamento su un singolo (o pochi) vendor per l’infrastruttura IT e la sicurezza, un prodotto XDR nativo potrebbe essere sufficiente. Il presupposto è che un singolo fornitore potrebbe integrarsi meglio all’interno dell’ecosistema aziendale e che sicuramente è più semplice da gestire. Le organizzazioni che dispongono di prodotti per la sicurezza forniti da un singolo fornitore possono pertanto ritenere che l’XDR di quel fornitore sia un candidato naturale.
Tuttavia, con questo approccio potrebbero esserci delle lacune poiché un singolo fornitore Native XDR difficilmente è in grado di offrire una copertura di sicurezza completa su tutti i vettori di attacco e di pari livello in tutte le aree che copre (ad es. una buona copertura sugli endpoint ma non adeguata sulle mail).
Inoltre, questo approccio può portare ad un “vendor lock-in”. Solitamente la capacità di integrazione di soluzioni Native XDR con sorgenti di dati di terze parti non è semplice né ampia e questo potrebbe richiedere di dover implementare all’interno dell’organizzazione i sensori del vendor, richiedendo ad esempio la sostituzione del EDR esistente per adottare un XDR nativo.
Gli Open XDR sono adatti per le organizzazioni con diversi fornitori, magari di tipo “best of breed”, distribuiti nel loro ambiente di sicurezza e IT. Un Open XDR significa che non è necessario sostituire i sensori front-end esistenti per adattarsi all’approccio chiuso degli XDR nativi. Gli XDR aperti sono, per natura, progettati per integrarsi in modo efficiente con un’ampia varietà di altre tecnologie. Le organizzazioni possono semplicemente aumentare e razionalizzare il loro attuale set di strumenti e migliorarne l’output e il valore sovrapponendo un Open XDR per risolvere le loro esigenze di rilevamento, indagine e risposta alle minacce. E i team di sicurezza possono aggiungere nuovi strumenti, combinandoli con quanto esistente, continuando a beneficiare dei vantaggi della soluzione Open XDR scelta.
Il punto di vista di Exabeam sul mercato XDR
In Exabeam riteniamo che l’approccio Open XDR posizioni al meglio la maggior parte dei team di sicurezza per il successo e riduca i rischi per la sicurezza informatica. Sebbene l’approccio nativo possa, in teoria, offrire diverse componenti di un programma di sicurezza e la semplicità di un singolo fornitore, riteniamo che ciò porti inevitabilmente al “vendor lock-in”. Inoltre, i team di sicurezza avranno difficoltà a ottenere le migliori funzionalità di sicurezza su e-mail, DLP, identità, cloud, tutto da un unico fornitore.
Le organizzazioni che selezionano un Native XDR possono trovare molto difficile aggiungere uno strumento di sicurezza di un altro fornitore che copra un nuovo vettore di attacco o minacce più avanzate. Poiché gli XDR nativi sono generalmente focalizzati sul proprio portafoglio, esistono poche o nessuna capacità e supporto per integrarsi in modo efficiente con i sensori di altri strumenti di infosec.
La flessibilità offerta da un Open XDR consente ai team di sicurezza di mantenere gli investimenti esistenti negli strumenti di sicurezza migliori, consentendo al contempo le modifiche desiderate al proprio stack tecnologico. Gli XDR aperti sono fatti per integrarsi con altri prodotti, in modo che possano acquisire tutte le informazioni in modo completo e combinare segnali deboli provenienti da più prodotti per rilevare minacce complesse perse da altri strumenti.
Man mano che i programmi di sicurezza si evolvono, vediamo gli Open XDR come una soluzione chiave per aumentare la capacità di gestione della sicurezza di un’organizzazione e consentirle di crescere con le migliori soluzioni di sicurezza proposte dal mercato.
Un prerequisito fondamentale per gli XDR: Use Case prescrittivi e incentrati sulle minacce
In quest’ultima parte dell’articolo vorremmo approfondire un concetto introdotto in precedenza, ovvero il contenuto come elemento fondamentale di una soluzione XDR.
L’approccio legacy alla maturità dei SOC
Storicamente i SOC sono stati incaricati di assemblare un set di strumenti di sicurezza in grado di supportare i processi che possono aiutarli a rilevare, indagare e rispondere alle minacce informatiche. Per fare ciò, la maggior parte dei SOC aderisce a un processo simile a quanto riportato sotto.
Quando i SOC cercano di maturare le proprie capacità, in genere cercano di farlo tramite l’automazione, procedendo “da sinistra a destra”. Iniziano con il portare tutti i dati possibili nel loro SIEM “per ogni evenienza” in modo che non perdano nulla che possa essere rilevante per la sicurezza. Una volta che la fase di collection delle fonti di log è completata (si spera sempre con il set giusto di sorgenti, ma di solito sono sempre troppe ed alcune di esse anche inutili), si pone l’attenzione sull’automazione della fase di detection con la speranza di rilevare il maggior numero possibile di minacce. Con i meccanismi di detection implementati, gli alert provenienti sia dai prodotti di sicurezza che dal SIEM stesso iniziano ad accumularsi. Per gestire questo eccesso di alert, si tenta di automatizzare la fase di triage di livello 1 e così via. Questo processo di automazione da sinistra a destra progredisce fino a raggiungere la risposta e la chiusura dell’incidente.
Questo modello legacy di ottimizzazione di un SOC cerca di automatizzare una alla volta ogni fase dei processi di sicurezza, ma lo fa per tutte le diverse tipologie di minaccia contemporaneamente. Sfortunatamente, non tutte le minacce sono uguali. Hanno rilevanza diversa, priorità diverse, richiedono dati diversi, metodi di rilevamento diversi, esigenze di indagine diverse e la risoluzione richiede persone, processi e strumenti diversi. Non solo un approccio da sinistra a destra richiede un’enorme quantità di lavoro e personalizzazioni spinte, ma semplicemente non è un modo efficiente per far maturare un SOC.
Maturazione “dall’alto verso il basso” mediante casi d’uso incentrati sulle minacce
Invece di cercare di automatizzare tutte le minacce in ogni singola fase del flusso di lavoro dei SOC, quindi spostandosi da sinistra a destra, un percorso più efficiente verso la maturità SOC consiste nell’automatizzare la gestione di un singolo tipo di minaccia nel suo intero ciclo di vita, dalla fase di detection fino alla risposta finale, prima di passare al prossimo. Si può iniziare con semplici scenari e casi d’uso e poi si possono aggiungere in modo iterativo casi d’uso più sofisticati e complessi, passando così ad un modello di maturità basato sulla nostra capacità di automatizzare la gestione di questi casi d’uso end-to-end anziché da sinistra a destra. Concettualmente questo percorso di maturità è più vicino ad un approccio “dall’alto verso il basso”, come illustrato nella figura di seguito.
Per facilitare l’automazione dei processi di detection, indagine e risposta alle minacce (TDIR), i vendor di soluzioni XDR devono offrire in maniera integrata linee guida e flussi di lavoro prescrittivi per la gestione di minacce specifiche e personalizzare i loro prodotti per fornire risultati concreti per specifici tipi di minacce. La figura sotto mostra alcuni dei modi in cui i fornitori possono personalizzare i propri prodotti con funzionalità, processi e contenuti per consentire ai SOC di concentrarsi su casi d’uso incentrati sulle minacce durante l’intero ciclo di vita di TDIR.
Inoltre, le organizzazioni non dovrebbero essere costrette a creare da sole contenuti funzionali di rilevamento, valutazione, indagine e risposta alle minacce, utilizzando il famoso “bag of lego” proposto da molti vendor. Invece, i vendor dovrebbero fornire contenuti preconfezionati in ogni fase del processo TDIR che è direttamente correlato a un caso d’uso specifico. Come mostrato nella figura sotto relativamente alle minacce che prevedono movimenti laterali, ogni caso d’uso ha un ambito limitato relativamente alle origini dati specifiche, alle metodologie di rilevamento, ai passaggi di indagine, alle azioni di risposta che affrontano quella minaccia specifica. Il contenuto del caso d’uso include tutto il necessario per risolvere un particolare tipo di minaccia per ottenere risultati ripetibili e di successo ogni volta e su larga scala.
Le soluzioni XDR efficaci devono includere contenuti prescrittivi incentrati su casi d’uso
Gli XDR dovrebbero essere in grado di offrire una soluzione “closed-loop” che comprenda tutto quello che è necessario per gestire l’intero flusso di lavoro delle operazioni di sicurezza all’interno di un SOC. Gli XDR dovrebbero essere soluzioni chiavi in mano con un “time to value” immediato e una configurazione minimale, indipendentemente dal livello di competenza del SOC – quindi invece di customizzare e ottimizzare in continuazione soluzioni legacy, i SOC dovrebbero essere in grado di utilizzare gli XDR per affrontare problemi immediati gestendo i casi d’uso uno alla volta nel loro intero ciclo di vita.
Senza questa capacità, gli XDR non saranno in grado di mantenere la promessa che ha determinato la loro nascita: essere una soluzione chiavi in mano per migliorare e velocizzare in maniera automatizzata i processi TDIR all’interno di un SOC e che funziona immediatamente, senza necessità di personalizzazioni esasperate.
Autore: Paolo Cecchi
