Perché serve il security monitoring
In un SOC (Security Operations Center) il problema non è la mancanza di dati, ma il loro eccesso: firewall, router, switch, endpoint, server, IDS/IPS, proxy e servizi cloud generano milioni di eventi ogni giorno. Analizzare queste fonti isolatamente è impossibile e, soprattutto, un attacco reale si manifesta quasi sempre come correlazione fra eventi provenienti da sistemi diversi, non come un singolo log sospetto. Il security monitoring consiste nel raccogliere, normalizzare e osservare in modo continuativo questi flussi per individuare comportamenti anomali prima che diventino incidenti.
Il SIEM: aggregazione e correlazione
Un SIEM (Security Information and Event Management) centralizza i log da fonti eterogenee e li rende confrontabili. Le sue funzioni chiave sono:
- Aggregazione: raccoglie log via syslog, agent, API o NetFlow, da apparati Cisco (con
logging host), da un firewall Firepower, da Cisco ISE, dai domain controller, dagli endpoint. - Normalizzazione: converte formati diversi in uno schema comune, così che un IP sorgente sia lo stesso campo indipendentemente dalla sorgente.
- Correlazione: applica regole che collegano eventi distinti. Esempio classico: 20 login falliti su ISE seguiti da un login riuscito e poi da una connessione verso un IP esterno mai visto. Nessuno dei tre eventi, da solo, è un allarme; insieme suggeriscono un credential stuffing andato a segno.
- Alerting e dashboard: genera alert prioritizzati e offre viste per il triage.
Il SIEM è anche fondamentale per la retention dei log (requisiti di compliance e indagini forensi) e per la ricerca retrospettiva quando emerge un nuovo IoC (Indicator of Compromise).
| Concetto | Significato pratico |
|---|---|
| True positive | Alert reale su attività malevola: va gestito |
| False positive | Alert su attività legittima: rumore, erode la fiducia |
| False negative | Attacco reale non rilevato: il rischio più pericoloso |
| True negative | Attività normale correttamente ignorata |
Il SOAR: automazione della risposta
Il SOAR (Security Orchestration, Automation and Response) aggiunge al monitoraggio la risposta automatizzata. Dove il SIEM rileva e allerta, il SOAR esegue tramite playbook: sequenze predefinite di azioni orchestrate tra strumenti diversi.
Un playbook può, ad esempio: ricevere l’alert dal SIEM, arricchirlo interrogando una threat intelligence esterna, aprire automaticamente un ticket, mettere in quarantena l’endpoint via EDR, bloccare l’IP sul firewall e imporre un cambio password. Il valore del SOAR è ridurre il MTTR (Mean Time To Respond) e liberare gli analisti dai compiti ripetitivi, lasciando all’uomo le decisioni critiche. Le azioni ad alto impatto (isolare un server di produzione) restano tipicamente soggette ad approvazione umana.
Quando escalare un evento
Non ogni alert diventa un incidente. Il triage dell’analista di primo livello (L1) valuta gravità, affidabilità della sorgente e contesto. Si escala verso L2/L3 quando l’evento indica un compromesso confermato o probabile: movimenti laterali, esfiltrazione di dati, privilegi elevati ottenuti, malware attivo, o sistemi critici coinvolti. Gli alert a bassa confidenza o chiaramente benigni vengono chiusi o inviati al tuning delle regole.
La trappola centrale: garbage in, garbage out
Un SIEM vale quanto i dati che riceve. Se una fonte non invia log, il SIEM è cieco su di essa (potenziale false negative). Se le regole sono mal tarate, producono valanghe di false positive: gli analisti si abituano al rumore, ignorano gli alert per alert fatigue e finiscono per non vedere l’incidente reale nascosto tra centinaia di allarmi inutili. Il tuning continuo delle regole non è un dettaglio: è ciò che separa un SOC efficace da uno saturo. Ridurre i falsi positivi migliora la capacità di cogliere i veri positivi.
Trappole tipiche d’esame
- Scenario: gli analisti chiudono ripetutamente lo stesso alert perché innocuo. → Risposta giusta: fare tuning della regola di correlazione per ridurre i false positive, non disabilitare il monitoraggio.
- Scenario: un attacco reale non ha generato alcun alert. → È un false negative, spesso causato da una fonte di log mancante o non inoltrata al SIEM, non da un errore dell’analista.
- Scenario: la domanda chiede chi aggrega e correla i log vs chi esegue playbook di risposta. → Aggregazione/correlazione = SIEM; orchestrazione/automazione della risposta = SOAR.
- Scenario: eventi individualmente innocui ma sospetti in sequenza. → Il valore del SIEM è la correlazione fra fonti, non l’analisi del singolo evento.
- Scenario: rilevato un compromesso confermato su un sistema critico. → Va escalato immediatamente a un livello superiore, non chiuso in autonomia dall’L1.