SIEM e SOAR - Detection, Correlazione e Response Automatizzata

Cos'e'

#

SIEM (Security Information and Event Management) centralizza i log da migliaia di sorgenti diverse e applica regole di correlazione per rilevare schemi di attacco che i singoli log non mostrerebbero mai. SOAR (Security Orchestration, Automation and Response) automatizza la risposta agli alert, eliminando le operazioni manuali ripetitive tramite playbook.

TL;DR

#

La regola base: SIEM rileva, SOAR risponde. Il flusso operativo e': Log da sorgenti eterogenee → SIEM (aggregazione + correlazione) → Alert → SOAR (esecuzione playbook) → Azione automatica (blocca IP, isola endpoint, apri ticket). Senza SIEM non hai visibilita'. Senza SOAR, la risposta e' lenta e manuale.

Mappa SIEM e SOAR

#

SIEM - Security Information and Event Management

#

Il SIEM e' il cuore del monitoraggio moderno. Il suo valore non sta nel raccogliere log da una singola fonte, ma nel correlare eventi da fonti diverse che, presi singolarmente, sarebbero innocui.

Log Aggregation e Correlazione

#

La correlazione e' la funzione che distingue il SIEM da un semplice raccoglitore di log. Esempio classico: 10 login falliti in 5 minuti su macchine diverse non e' un utente distratto, e' un brute force distribuito. Ma questa correlazione richiede che i log di Windows (Event ID 4625), Linux (Failed password for root) e firewall convergano in un unico sistema con un formato comune.

graph LR
    WIN[Windows Event Log]
    LIN[Linux /var/log]
    FW[Firewall Logs]
    IDS[IDS/IPS Alerts]
    APP[Application Logs]
    DNS[DNS Query Logs]

    SIEM[SIEM
Log Aggregation
Normalization]
    CORR[Correlation Engine]
    OUT1[Alert → SOC Analyst]
    OUT2[Alert → SOAR]
    OUT3[Trends e Reports]

    WIN --> SIEM
    LIN --> SIEM
    FW --> SIEM
    IDS --> SIEM
    APP --> SIEM
    DNS --> SIEM
    SIEM --> CORR
    CORR --> OUT1
    CORR --> OUT2
    CORR --> OUT3

Normalizzazione dei Log

#

Windows scrive Event ID 4625 per un login fallito. Linux scrive Failed password for root from 10.0.0.5 port 22. Un firewall Cisco scrive in formato CEF. Il SIEM normalizza tutti questi formati in un campo comune (auth_failure con source_ip, username, timestamp) per poterli correlare.

Formati standard di normalizzazione: CEF (Common Event Format), LEEF (Log Event Extended Format), JSON normalizzato, Syslog con schema strutturato.

Componenti SIEM

#

Lookback e Forensics

#

Il SIEM non serve solo per il monitoraggio in tempo reale. Quando si verifica un breach scoperto 3 settimane dopo l'intrusione iniziale, la capacita' di tornare indietro nel tempo e ricostruire la sequenza degli eventi e' critica per il DFIR. Un retention period troppo breve (7 giorni) rende impossibile l'analisi.

Requirement di retention per compliance: PCI-DSS richiede 12 mesi (ultimi 3 immediatamente disponibili). SOX richiede 7 anni per i log finanziari. GDPR: i log vanno conservati solo per il tempo strettamente necessario.

Alert Fatigue

#

Se la soglia degli alert SIEM e' troppo bassa, gli analisti ricevono troppi falsi positivi e iniziano a ignorarli, perdendo gli eventi reali. L'alert fatigue e' uno dei rischi operativi piu' concreti in un SOC. SOAR riduce l'alert fatigue automatizzando il triage dei casi a bassa priorita'.

SOAR - Security Orchestration, Automation and Response

#

Il SOAR riceve gli alert dal SIEM (o da altre sorgenti) e risponde automaticamente tramite playbook, senza aspettare che un analista si svegli e apra il laptop.

I Tre Pilastri O-A-R

#

Orchestration: il SOAR integra e coordina strumenti diversi (SIEM, firewall, EDR, ticketing, email, ITSM) chiamando le loro API. Non blocca l'IP lui stesso: chiede al firewall di bloccarlo.

Automation: elimina le operazioni manuali ripetitive. Un alert di phishing che prima richiedeva 20 minuti di analisi manuale viene gestito in secondi: estrai URL → verifica su VirusTotal → blocca su proxy → notifica utente → apri ticket.

Response: le azioni concrete definite nel playbook. Esempi: disabilita account, blocca IP su firewall, isola endpoint in quarantena, reset password, notifica SOC via Slack, apri ticket su ServiceNow.

Playbook vs Runbook

#

La distinzione e' critica all'esame Security+:

Flusso Operativo SIEM + SOAR

#

Il flusso tipico in un SOC moderno combina i due strumenti in pipeline:

graph TD
    SIEM1[SIEM riceve log
da 200 sorgenti]
    CORR[Correlation Engine
analizza pattern]
    ALERT[Alert generato
brute force rilevato]
    SOAR[SOAR riceve alert
seleziona playbook]
    PB[Playbook eseguito
automaticamente]
    A1[Blocca IP su firewall]
    A2[Disabilita account]
    A3[Notifica analista via Slack]
    A4[Apri ticket su Jira]
    ANALYST[Analista riceve
contesto pre-arricchito]

    SIEM1 --> CORR
    CORR --> ALERT
    ALERT --> SOAR
    SOAR --> PB
    PB --> A1
    PB --> A2
    PB --> A3
    PB --> A4
    A3 --> ANALYST
    A4 --> ANALYST

Alert Enrichment

#

Il SOAR non risponde solo: arricchisce automaticamente gli alert con contesto prima che l'analista li veda. Per ogni alert, il SOAR puo' interrogare automaticamente: la criticita' dell'asset coinvolto, la storia degli accessi dell'utente, il punteggio di reputazione dell'IP esterno su threat intel feeds, i CVE attivi sul sistema compromesso. L'analista riceve un caso pre-istruito invece di un alert grezzo.

Vendor Principali

#

Dev parallel: in un'app Node/PHP con molti microservizi, il SIEM e' l'equivalente di un sistema di logging centralizzato come ELK Stack, Datadog o CloudWatch, ma orientato alla security invece che al debug applicativo. La differenza e' nel tipo di evento che cerchi: invece di 5xx errors e latenza, cerchi pattern di attacco. Un rate limiter che logga ogni risposta 429 + una regola SIEM che correla 1000 tentativi in 60s da IPs diversi = detection automatica di credential stuffing. Il SOAR e' l'equivalente di un webhook automatico che su deploy fallito apre un ticket e notifica Slack, ma applicato alla sicurezza: senza intervento umano, in secondi.

Scenario Reale

#

Un analista SOC inizia il turno e trova 3 alert separati nella dashboard SIEM: un login riuscito da un IP geograficamente insolito per quell'utente, seguito da accesso massivo a file share in 4 minuti, seguito da un trasferimento verso un IP esterno sconosciuto. Presi singolarmente, ogni evento ha una spiegazione innocua. La correlazione SIEM mostra che i tre eventi appartengono alla stessa sessione, stesso utente, stesso minuto di inizio. Il SOAR ha gia' eseguito il playbook automaticamente: account sospeso, endpoint isolato, ticket aperto con tutti i log pre-aggregati. L'analista deve solo confermare o revocare le azioni automatiche.

Collegato a

#

• log — logging come fonte primaria del SIEM
• logging — sorgenti di log, syslog, normalizzazione
• wazuh-architecture — implementazione SIEM open source nel vault
• ids-ips — sorgente di alert per il SIEM
• incident-response-lifecycle — SOAR supporta la fase Response
• edr — strumento comandato dal SOAR nei playbook