SIEM, SOAR e strumenti del SOC

Nel SOC (Security Operations Center) l’analista di turno vive dentro due piattaforme complementari: il SIEM e il SOAR. Fanno cose diverse e l’esame CBROPS insiste sulla distinzione operativa: il SIEM raccoglie, normalizza e correla i dati; il SOAR orchestra ed esegue la risposta. Confonderli è l’errore più comune del turno.

Il SIEM: dalla raccolta all’alert

Un SIEM (Security Information and Event Management) è il punto di aggregazione dove convergono i log di sicurezza dell’intera infrastruttura — firewall, IPS/IDS, router e switch via syslog, endpoint, server, proxy web, NetFlow, controller di dominio, apparati Cisco IOS-XE. Il suo valore per l’analista si costruisce in tre stadi che vanno tenuti distinti.

• Log collection: acquisizione grezza degli eventi tramite syslog, agent o API. È ingestion pura — raccoglie e conserva, senza interpretare. Se una sorgente non inoltra i log, il SIEM è cieco su di essa.
• Normalizzazione (parsing): gli eventi arrivano in formati eterogenei (un log ASA, un evento IOS-XE, un record proxy, un flusso NetFlow). Il SIEM li mappa in uno schema comune con campi standard — src IP, dst IP, porta, utente, azione, timestamp — condizione senza la quale eventi di sorgenti diverse non sono confrontabili.
• Log correlation e alerting: il motore a regole mette in relazione eventi di fonti differenti lungo il tempo, riconosce pattern d’attacco e genera alert prioritizzati per il triage.

Collection vs correlation: la distinzione del turno

La collection risponde a “cosa è transitato”, la correlation risponde a “questi eventi insieme raccontano un attacco”. Il beaconing verso un canale command-and-control non emerge da un singolo pacchetto: solo mettendo in relazione la regolarità temporale dei flussi NetFlow con l’improvviso volume di risoluzioni DNS verso domini generati algoritmicamente (DGA) il pattern diventa un alert. Una sorgente sola, isolata, resta rumore di fondo.

Il SOAR: orchestrazione, automazione, playbook

Il SOAR (Security Orchestration, Automation and Response) entra in gioco dopo che l’alert esiste. Non scova l’incidente: lo gestisce in modo rapido e ripetibile, comprimendo l’MTTR (Mean Time To Respond) e togliendo all’analista il lavoro manuale a basso valore.

• Orchestrazione: coordina via API strumenti diversi — SIEM, firewall/Firepower, EDR, threat intelligence, ticketing, gateway email — così che agiscano in un unico flusso.
• Automazione: esegue azioni ripetitive senza intervento umano (arricchire un IoC, detonare un URL, aprire un ticket, mettere in quarantena).
• Playbook (o runbook): workflow predefinito, spesso condizionale, che descrive la sequenza di risposta.

Un playbook realistico da turno SOC, innescato da un phishing segnalato dall’utente: estrae l’URL e lo detona in sandbox; se il verdetto è malevolo, ricava gli IoC (dominio, hash allegato, mittente) e li usa per una ricerca retrospettiva sulle mailbox alla caccia di messaggi gemelli; procede quindi alla quarantena massiva dei messaggi correlati e alla notifica agli utenti coinvolti. I passi ad alto impatto restano dietro un checkpoint di approvazione umana; un playbook può essere fully automated oppure human-in-the-loop.

Gli strumenti del turno (SOC toolchain)

Oltre a SIEM e SOAR, la cassetta degli attrezzi dell’analista comprende:

• IDS/IPS (Snort, Firepower): rilevano/bloccano traffico malevolo e alimentano il SIEM.
• Analisi di traffico e pacchetti (Wireshark, tcpdump) e NetFlow per la visibilità di flusso.
• Threat Intelligence platform e feed (IoC, reputation) per l’arricchimento.
• Ticketing/case management per tracciare l’incidente end-to-end.
• EDR per visibilità e contenimento sull’endpoint.
• Sandbox per il malware analysis dinamico.

Il flusso del turno: il SIEM correla e genera l’alert → l’analista fa triage → il SOAR esegue il playbook orchestrando gli altri strumenti e abbattendo l’MTTR.

Trappole tipiche d’esame

• Collection non è correlation: uno scenario che parla di inoltrare e archiviare i log grezzi descrive la collection; uno che parla di mettere in relazione eventi nel tempo (beaconing periodico + DNS DGA) descrive la correlation. Sono due stadi distinti dello stesso SIEM.
• La normalizzazione è il prerequisito: se lo scenario cita “formati di log diversi resi confrontabili con uno schema comune”, la funzione è la normalizzazione/parsing del SIEM — non un’attività del SOAR né la correlazione vera e propria.
• Chi comprime l’MTTR? → il SOAR, tramite orchestrazione e automazione dei playbook. Il SIEM da solo non mette in quarantena mail né isola host: rileva e allerta soltanto.
• Detonazione in sandbox e ricerca IoC sono passi automatizzati orchestrati dal SOAR; l’individuazione dell’alert iniziale resta compito del SIEM (o della segnalazione utente).
• Sorgente mancante = punto cieco: se un attacco non genera alcun alert, sospetta prima una fonte di log non inoltrata al SIEM (collection incompleta) che un errore di correlazione — nessuno stadio successivo recupera dati mai ingeriti.