Chi ha bisogno di un Security Operations Center (SOC)?
Non importa la dimensione o lo scopo di un’azienda, è prezioso avere un team dedicato a livello organizzativo il cui compito è quello di monitorare costantemente le operazioni di sicurezza e gli incidenti e rispondere a qualsiasi problema che può sorgere. Le varie responsabilità all’interno di un team di cybersecurity possono essere estremamente complesse, e un SOC può servire non solo come console tattica per consentire ai membri del team di svolgere i loro compiti quotidiani, ma anche come centro strategico per mantenere il team consapevole delle tendenze di sicurezza più grandi e a lungo termine.
Un tipico centro operativo di sicurezza tiene traccia di qualsiasi numero di avvisi di sicurezza che un’organizzazione potrebbe incontrare, comprese le notifiche di potenziali minacce tramite tecnologie e strumenti, così come dipendenti, partner e fonti esterne. Da quel punto, il SOC indaga e convalida la minaccia segnalata per assicurarsi che non sia un falso positivo (cioè una minaccia segnalata che in realtà è innocua). Se l’incidente di sicurezza è ritenuto valido e richiede una risposta, il SOC lo consegna alle persone o ai team appropriati per la risposta e il recupero.
Ci vuole una sofisticata combinazione di competenze, processi e organizzazione per gestire efficacemente un centro operativo di sicurezza come parte di un programma generale di rilevamento e risposta agli incidenti. Questo è il motivo per cui ogni organizzazione potrebbe non essere in grado di supportare o di fornire risorse a un SOC in-house. Invece, molti scelgono di far gestire il loro SOC da un’agenzia esterna o addirittura di affidarlo completamente in outsourcing.
Preparazione
Ci sono una serie di componenti di supporto che devono essere in atto prima che un SOC sia un’opzione valida per un’organizzazione. Il primo è avere un buon programma di gestione della superficie di attacco. Questo include la tecnologia di prevenzione delle minacce per tutte le vie d’ingresso e d’uscita delle minacce, la scansione regolare delle vulnerabilità (e le relative patch), il pen test, l’autenticazione e l’autorizzazione degli utenti, la gestione delle risorse, il test delle applicazioni esterne (con le relative patch) e la gestione degli accessi remoti.
Successivo è avere un piano di risposta agli incidenti. In genere, uno degli obiettivi principali dell’introduzione di un SOC in un programma IDR è aumentare l’efficacia del rilevamento delle minacce nell’ambiente dell’organizzazione. Se i processi di risposta agli incidenti che seguono la scoperta di una violazione non sono in atto e testati regolarmente, si stanno affrontando solo alcune componenti di un programma IDR efficace.
Infine, è importante avere un piano di disaster recovery. Una violazione è semplicemente un esempio specifico di un disastro da cui le organizzazioni devono riprendersi. Una volta che la violazione rilevata è stata completamente individuata e le risorse, le applicazioni e gli utenti interessati sono stati contenuti, ci deve essere un piano in atto per ripristinare i normali processi operativi aziendali. Questo è il disaster recovery.
Iniziare
Data la complessità intrinseca di un centro operativo di sicurezza, ci sono molte cose da considerare quando se ne crea uno. Indipendentemente dal fatto che venga creato in-house o in outsourcing, la preparazione dei seguenti tre elementi è essenziale per il successo del SOC:
- Persone: Comprendere i ruoli e le responsabilità degli analisti del SOC è un importante precursore della selezione della tecnologia che gestirà il vostro SOC. I team che creerete e i compiti che assegnerete loro dipenderanno dalla struttura esistente della vostra organizzazione. Ad esempio, se state costruendo un SOC per aumentare le capacità esistenti di rilevamento e risposta alle minacce, dovrete considerare quali compiti specifici sono di competenza dei membri del team SOC e quali ricadono sui team IDR non-SOC. Dovrete anche dividere le responsabilità tra gli analisti del SOC, in modo che ci sia una chiara comprensione di chi gestisce gli avvisi ad alta fedeltà, chi convalida gli avvisi a bassa fedeltà, chi effettua l’escalation degli avvisi, chi va a caccia di minacce sconosciute, ecc. Molti centri operativi di sicurezza operano con una struttura a livelli per il personale per aiutare a stabilire chiare responsabilità e gerarchia.
- Tecnologia: Decidere quale tecnologia utilizza il SOC è dove il tempo speso per stabilire i ruoli e le responsabilità di cui sopra darà i suoi frutti. Quale tecnologia useranno? Probabilmente, avranno bisogno di combinare strumenti per l’aggregazione dei log, l’analisi del comportamento degli utenti, l’interrogazione degli endpoint, la ricerca in tempo reale e altro ancora. Sarà importante guardare come gli analisti SOC stanno utilizzando la vostra tecnologia e determinare se la tecnologia esistente sta aiutando o ostacolando i processi SOC, e se una nuova tecnologia dovrà sostituirla. Inoltre, sarà importante disporre di strumenti di comunicazione che consentano agli analisti di collaborare.
- Processi: Stabilire i processi che le persone e la tecnologia di cui sopra seguiranno è l’ultimo componente da considerare quando si inizia con un SOC. Cosa succede se un incidente di sicurezza deve essere convalidato, segnalato, escalation o passato a un altro team? Come raccoglierete e analizzerete le metriche? Questi processi devono essere abbastanza precisi da garantire che le piste investigative siano gestite in ordine di criticità, ma abbastanza flessibili da non dettare i processi di analisi. I processi possono fare o rompere l’efficacia di un SOC e vale la pena di fare uno sforzo per ottenere il giusto.