Le sorgenti degli alert nel SOC
Un analista di sicurezza non lavora mai su una singola fonte: correla eventi provenienti da tecnologie diverse, ognuna con un punto di osservazione differente sulla rete. Conoscere quale sorgente produce quale tipo di evidenza è fondamentale per il triage e per l’esame CBROPS.
| Source technology | Cosa fornisce | Prospettiva |
|---|---|---|
| IDS/IPS (es. Snort, Firepower) | Alert su firme, anomalie di protocollo, pattern di exploit | Deep packet inspection sul payload |
| Firewall (stateful / NGFW) | Log di connessioni permesse/negate, policy hit, application control | Livello 3-4 (e L7 su NGFW) |
| Application logs (web server, DB, auth) | Errori applicativi, tentativi di login, query anomale | Contesto applicativo end-to-end |
| NetFlow | Metadati di flusso: IP src/dst, porte, byte, durata, flag | Visibilità comportamentale senza payload |
| Proxy (web/forward proxy) | URL richiesti, categorie, user-agent, download, C2 su HTTP/HTTPS | Traffico web utente-verso-Internet |
Il valore di NetFlow merita una nota: non ispeziona il contenuto (quindi funziona anche con traffico cifrato) ma rivela pattern comportamentali — beaconing verso un C2, esfiltrazioni con flussi outbound anomali, scansioni con molti flussi brevi verso host diversi. Il proxy, al contrario, vede l’URL e il contenuto HTTP in chiaro (o dopo TLS decryption), utile per bloccare domini malevoli e categorie non consentite.
IDS contro IPS: rilevare o bloccare
La differenza operativa è tanto semplice quanto ricorrente nei quiz:
- Un IDS opera out-of-band, tipicamente riceve una copia del traffico via SPAN port o network tap. Rileva e genera alert, ma non può fermare il pacchetto: quando emette l’allarme, il traffico malevolo è già passato. Zero impatto sulla latenza, zero rischio di bloccare traffico legittimo, ma nessuna capacità di prevenzione.
- Un IPS opera inline: il traffico lo attraversa fisicamente. Può quindi droppare, resettare o bloccare la sessione in tempo reale (mode prevention). Il rovescio della medaglia: introduce latenza, è un potenziale single point of failure e — punto critico — un false positive su un IPS inline blocca traffico legittimo, con impatto diretto sul business.
Molti dispositivi Firepower/IOS-XE possono girare in modalità IDS (monitor-only) o IPS (inline) a seconda del deployment.
Le quattro categorie di verdetto
Ogni alert va classificato secondo due assi: c’è stato un allarme? e c’era davvero una minaccia?
| Minaccia reale presente | Nessuna minaccia | |
|---|---|---|
| Alert generato | True Positive (TP) — allarme corretto su attacco reale | False Positive (FP) — falso allarme |
| Nessun alert | False Negative (FN) — minaccia non rilevata | True Negative (TN) — silenzio corretto |
Impatto sul triage:
- True Positive: il sistema ha fatto il suo lavoro; l’analista apre un incident.
- True Negative: nessun rumore, nessun lavoro — lo stato desiderato per il traffico pulito.
- False Positive: consuma tempo dell’analista, genera alert fatigue e può portare a disattivare regole “rumorose”. Fastidioso e costoso, ma la sicurezza non è compromessa.
- False Negative: il caso più pericoloso. Un attacco reale è passato senza generare alcun alert; il SOC crede di essere al sicuro mentre l’avversario è già dentro. Nessuno apre un ticket perché nessuno sa che è successo qualcosa.
La strategia di tuning delle firme è un equilibrio: rendere le regole troppo strette riduce i FP ma aumenta i FN; regole troppo larghe fanno l’opposto. Il tuning corretto riduce i FP senza creare FN.
Trappole tipiche d’esame
- Scenario: “Un IDS non ha bloccato l’attacco, è un malfunzionamento?” → Risposta giusta: no, un IDS per definizione rileva ma non blocca (out-of-band); serve un IPS inline per la prevenzione.
- Scenario: “Quale situazione rappresenta il rischio maggiore per l’organizzazione?” → Risposta giusta: il false negative — minaccia reale non rilevata. Non confonderlo mai con il false positive, che è solo rumore.
- Scenario: “Il SOC è sommerso da alert su traffico legittimo e sta ignorando le notifiche” → Risposta giusta: sono false positive che causano alert fatigue; la cura è il tuning delle firme, non disabilitarle in blocco (rischio di introdurre FN).
- Scenario: “Serve visibilità su traffico cifrato senza ispezionare il payload” → Risposta giusta: NetFlow, che analizza i metadati di flusso (beaconing, volumi, durate) indipendentemente dalla cifratura.
- Scenario: “Un IPS inline ha bloccato un aggiornamento software legittimo” → Risposta giusta: è un false positive, e proprio perché il dispositivo è inline ha causato un blocco con impatto operativo — motivo per cui l’IPS richiede tuning più prudente dell’IDS.