Uno dei modi in cui collaboriamo con la nostra comunità di partner è fornire servizi gestiti agli utenti finali. E come in quasi tutti gli scenari di implementazione, ogni ambiente ha le proprie configurazioni, i propri requisiti e, talvolta, anche le proprie sfide. Tenendo presente questo, abbiamo pensato di illustrare alcune delle sfide più comuni che abbiamo affrontato, nella speranza di potervi aiutare nel vostro percorso.
Ma prima, diamo un'occhiata all'elenco delle sfide riportato di seguito. Qualcuna di queste problematiche è presente nel vostro Security Operations Center (SOC) attuale?
- Costo di proprietà elevato: ciò comporta il costo della creazione di casi d'uso di Security Information and Event Management (SIEM) e il turnover del personale addetto alla manutenzione nei ruoli di analista di primo e secondo livello, con continue assunzioni e formazione che comportano un aumento dei costi.
- Inefficienze nella sicurezza: difficoltà nell'ottenere una copertura completa dei log e dei casi d'uso a causa dei costi di acquisizione dei log, delle sfide tecniche e operative o della limitata capacità di eseguire analisi forensi sulla progressione di un incidente.
- Affaticamento da allarmi: i registri o i sistemi tradizionali basati sulle firme generano troppi allarmi, troppi falsi positivi o entrambi, e/o difficoltà nell'individuare e comprendere il contesto degli allarmi.
Se hai risposto sì a una qualsiasi delle sfide, sei nel posto giusto.
Il SOC 1.0
Il SOC 1.0, o SIEM SOC, è stata la prima evoluzione nella creazione di una capacità di monitoraggio della sicurezza all'interno di un'organizzazione. L'idea alla base del SOC 1.0 è semplicemente quella di raccogliere tutti i log dai firewall, dai proxy, dai server di autenticazione, dalle applicazioni e dalle workstation, praticamente da qualsiasi cosa lo consenta. Una volta fatto ciò, è possibile aggregarli in una piattaforma SIEM, dove i dati possono essere facilmente interrogati e correlati, e acquisire ulteriori indicatori di compromissione (IoC) o informazioni sulle minacce che possono essere confrontati con i dati di log.
È qui che inizia il divertimento e si intraprende un percorso di creazione di query o casi d'uso per individuare azioni dannose o rischiose all'interno di tutti i dati. In genere, si inizia a pensare a come creare avvisi quando determinati eventi, combinazioni di eventi o soglie vengono superati, in modo che gli analisti siano in grado di rispondere agli avvisi e utilizzare il SIEM insieme ad altri strumenti e risorse per indagare sugli eventi. Idealmente, questo dovrebbe essere configurato in modo isolato, il che significa che gli analisti devono passare da una console all'altra, da uno strumento all'altro, per cercare di triangolare manualmente gli avvisi e capire cosa sta succedendo. In generale, questo approccio ha molti vantaggi ed è oggi considerato lo standard de facto e la capacità fondamentale in molti SOC, sia per le grandi che per le piccole organizzazioni, tuttavia presenta alcuni problemi fondamentali.
Lo scenario comune in molti ambienti SOC 1.0 include:
- Non sono disponibili registri adeguati
- I log non contengono dati sufficienti per eseguire un rilevamento adeguato delle minacce.
- È costoso creare e mantenere i casi d'uso o le regole per il rilevamento.
- Il costo di archiviazione dei log in un SIEM sta diventando un problema importante per i clienti.
- L'approccio basato sulle regole di query e sull'analisi statistica non è abbastanza potente per rilevare gli aggressori furtivi.
- Il SOC viene sovraccaricato di avvisi, la maggior parte dei quali sono rilevamenti falsi positivi.
- Gli analisti SOC hanno difficoltà a ottenere informazioni sufficienti sul contesto dell'allerta e la classificazione degli allarmi richiede molto lavoro manuale per indagare.
Di conseguenza, vi è un gran numero di offerte di lavoro per analisti informatici, sviluppatori e addetti alla risposta agli incidenti a causa dell'elevato volume di lavoro nei SOC e del fatto che il lavoro stesso nei SOC 1.0 è talvolta banale e poco gratificante, con un conseguente elevato turnover delle risorse. I costi di gestione di un SOC 1.0 stanno aumentando, mentre la superficie di attacco da proteggere è in costante crescita nella realtà post COVID-19. Allo stesso tempo, la criminalità informatica è in aumento, gli aggressori stanno diventando più sofisticati, gli attacchi sono molto specifici, furtivi e personalizzati in base all'organizzazione bersaglio.
Presentazione di SOC 2.0
A causa delle difficoltà legate all'approccio SOC 1.0, molte organizzazioni stanno trasformando le loro operazioni SOC in SOC 2.0. L'approccio SOC 2.0 è più economico da gestire, richiede meno personale, rileva gli attacchi più rapidamente, introduce l'automazione insieme a nuove tecniche analitiche ed è pronto per combattere attacchi mai visti prima.
Di seguito sono evidenziati i principali cambiamenti nella trasformazione delle operazioni SOC:
Questo significa che il SIEM sta diventando obsoleto? No, il SIEM e l'analisi basata sui log rimangono ancora fondamentali. Il passaggio al SOC 2.0 utilizza il SIEM per ciò che gli riesce meglio: rilevare rischi noti che possono essere facilmente articolati in regole di query. Un esempio potrebbe essere il viaggio impossibile, in cui si confronta la distanza geografica tra i luoghi di accesso in un determinato arco di tempo. Si tratta di uno scenario in cui è possibile creare facilmente un caso d'uso e i log del server di autenticazione sono prontamente disponibili. In SOC 2.0, il SIEM assume il ruolo di un unico pannello di controllo alimentato da rilevamenti di punteggi pre-analizzati provenienti da fonti endpoint e risposta endpoint (EDR), rilevamento e risposta della rete (NDR) e analisi del comportamento di utenti ed entità (UEBA).
Per gli obiettivi di rilevamento, dove la copertura dei log è chiaramente insufficiente e più correlata al riconoscimento dei modelli sfumati nel comportamento degli utenti e delle applicazioni, SOC 2.0 sfrutta l'apprendimento automatico insieme ai dati di rete e degli endpoint. Immaginate di provare a creare un programma software tradizionale o una regola per distinguere e ordinare le immagini. Questo non è realmente fattibile, tuttavia, con un modello di apprendimento automatico di base, il riconoscimento dei modelli diventa un'attività banale. Lo stesso vale per l'analisi dei modelli di attacco nella rete, cloud, nel SaaS o nelle applicazioni. Machine Learning possono essere addestrati a distinguere i modelli dannosi dal traffico applicativo e di rete benigno. Il bello del machine learning è che, una volta creato il modello, l'algoritmo si addestra da solo per iniziare a svolgere il lavoro di rilevamento: ciò significa che le soluzioni di machine learning richiedono poca o nessuna messa a punto e personalizzazione per iniziare a svolgere i compiti.
Con SOC 2.0, gli algoritmi di intelligenza artificiale arricchiscono il contesto delle rilevazioni, correlandole e assegnando loro un punteggio. Il ruolo dell'analista SOC viene elevato per lavorare sugli incidenti prioritari, dove può applicare rapidamente conoscenze ed esperienza, nonché competenze forensi per costruire una cronologia e un caso per la valutazione di comportamenti specifici rilevati, fornendo al contempo indicazioni al team di risposta per intervenire. Tutto ciò consente all'organizzazione di ripensare cosa acquisire, poiché tutti i rilevamenti non sono basati sui log. Inoltre, le soluzioni EDR e NDR forniranno al SIEM i rilevamenti di allerta prioritari anziché solo dati grezzi.
Il SOC 2.0 non si affida più ai sistemi IDS: i dati relativi alle minacce (IP, domini) vengono analizzati nella soluzione NDR. I firewall applicano le regole in tempo reale. L'antivirus e la protezione della posta elettronica si occupano di applicare le firme ai file e ai payload. Gli aggressori tendono a crittografare i propri dati in transito, quindi applicare le firme al traffico di rete ha sempre meno senso. Infine, poiché l'automazione viene applicata alla risposta agli incidenti e quando un rilevamento di minacce viene ritenuto vero e grave, automaticamente o manualmente, le piattaforme SOAR (Security Orchestration, Automation and Response) possono subentrare per eseguire le azioni necessarie a fermare la progressione degli attacchi secondo i playbook prestabiliti.
Guardando al futuro
Sebbene SOC 1.0 sia ancora lo standard in molte organizzazioni, sempre più aziende stanno adottando l'approccio SOC 2.0. Vectra svolge un ruolo chiave nella triade della visibilità SOC, poiché i dati provenienti dalla nuova rete composta da servizi IaaS, SaaS e on-premise non mentono. L'apprendimento automatico e l'intelligenza artificiale migliorano notevolmente il livello di automazione e accelerano la capacità dell'organizzazione di bloccare gli attacchi prima che si trasformino in violazioni.
Scopri come Vectra può aiutarti a migliorare la visibilità del tuo SOC oppure inizia prenotando una demo.