SOAR Security Orchestration, Automation and Response.

Cosa aggiunge il SOAR rispetto al SIEM

Security Orchestration, Automation and Response è il livello di azione che si colloca dietro la rilevazione. Un SIEM è bravo a raccogliere i log, a correlarli e a generare avvisi, ma si ferma all'avviso. Il SOAR prende il testimone da lì e svolge il lavoro che altrimenti un analista farebbe a mano: arricchisce l'avviso con ricerche di reputazione e contesto sugli asset, decide quanto è urgente, apre o aggiorna un ticket e, dove la policy lo consente, intraprende azioni di contenimento come isolare un host, disabilitare un account o bloccare un indicatore a livello di firewall. L'unità di lavoro in un SOAR è il playbook, una sequenza di passaggi codificata che trasforma una procedura ripetibile di gestione degli incidenti in qualcosa che la piattaforma può eseguire da sola.

L'orchestrazione e l'automazione sono due idee distinte che l'acronimo raggruppa. L'orchestrazione è il cablaggio: collegare il SIEM, l'EDR, il sistema di ticketing, il provider di identità, i feed di threat intelligence e il firewall affinché possano scambiarsi dati e comandi tramite un'unica console. L'automazione è ciò che viene eseguito attraverso quel cablaggio senza un essere umano nel ciclo.

La maggior parte dei team maturi mantiene un punto di approvazione umana sui passaggi distruttivi, così la piattaforma arricchisce e classifica automaticamente, ma attende che un analista confermi prima di mettere in quarantena un server di produzione. Quel mix, il lavoro ripetitivo automatizzato con il giudizio umano sulle azioni di maggiore impatto, è ciò che i professionisti effettivamente implementano.

SIEM, SOAR e il SOC

Questi tre termini viaggiano insieme ed è facile confonderli. Non sono prodotti concorrenti. Descrivono ruoli diversi all'interno della stessa operazione di rilevazione e risposta.

Leggilo come una pipeline. Il SIEM trova il segnale, il SOAR svolge il lavoro di risposta ripetibile attorno a quel segnale, e il SOC sono le persone che possiedono l'intero ciclo e gestiscono tutto ciò che i playbook non possono. Il valore più evidente del SOAR è sul volume: segnalazioni di phishing, avvisi di malware comune, accessi sospetti. Tutto ciò che arriva in massa e segue uno schema di gestione prevedibile è candidato a un playbook, ed è da qui che proviene la riduzione del tempo medio di risposta e il motivo per cui gli analisti smettono di passare il turno su arricchimenti in copia-incolla.

Perché i progetti SOAR riescono o falliscono

La shortDefinition è schietta sulla trappola, e corrisponde a ciò che si vede sul campo: un SOAR vale solo quanto valgono i playbook che scrivi e mantieni, e la maggior parte dei progetti SOAR falliti è rimasta senza autori di playbook. La piattaforma viene fornita con connettori e un motore di workflow, ma viene fornita senza alcuna conoscenza del tuo ambiente. Ogni playbook deve essere progettato, costruito, testato contro avvisi reali e poi mantenuto man mano che i tuoi strumenti, la tua rete e i tuoi attaccanti cambiano. Un playbook che chiama un'API deprecata lo scorso trimestre è peggio di nessun playbook, perché fallisce silenziosamente nel mezzo di un incidente.

Dal punto di vista della governance, il SOAR è il modo in cui diversi obiettivi di controllo smettono di essere aspirazionali. Nell'ambito di un sistema di gestione della sicurezza delle informazioni ISO/IEC 27001, supporta il lato tecnico della gestione degli incidenti, della registrazione e del monitoraggio, e produce un registro coerente e con marca temporale di come è stato gestito ogni incidente, che è esattamente la prova che un auditor desidera.

Sostiene inoltre la capacità di risposta che il NIST Cybersecurity Framework presuppone e che normative come NIS2 e DORA si aspettano che le organizzazioni mantengano, in particolare riguardo alla gestione e segnalazione tempestiva degli incidenti significativi. Considera il SOAR come un moltiplicatore di forza per un processo che funziona, non come un sostituto dell'averne uno.