Rilevamento e analisi: identificare gli incidenti reali

La fase di rilevamento e analisi inizia quando viene identificato per la prima volta un potenziale incidente di sicurezza e termina quando l'ambito e l'impatto sono sufficientemente chiari da poter avviare il contenimento. La sfida principale di questa fase è distinguere i veri positivi dai falsi positivi: un avviso generato da attività dannose da un avviso attivato da un comportamento normale, ma insolito. Un rilevamento efficace richiede strumenti configurati correttamente, analisti formati e baseline documentate delle attività normali.

Gli incidenti vengono rilevati attraverso diversi canali: avvisi SIEM generati da regole di correlazione, rilevamenti EDR ottenuti dall'analisi comportamentale sugli endpoint, segnalazioni degli utenti (la fonte di rilevamento iniziale più comune per il phishing), notifiche di terze parti (forze dell'ordine, fornitori di threat intelligence, servizi di notifica delle violazioni), scansioni automatizzate (scanner di vulnerabilità o CSPM che rilevano anomalie) e threat hunting (indagine proattiva). Ogni fonte presenta livelli di affidabilità diversi e fornisce tipi diversi di prove.

Un rilevamento efficace richiede la raccolta di log da fonti diverse. I tipi di log critici includono: log di autenticazione (Windows Security Event Log, /var/log/auth.log) per gli accessi riusciti e non riusciti, log di rete (firewall, VPC Flow Logs, proxy) per le connessioni insolite, log DNS per le query verso domini notoriamente dannosi, log degli endpoint (EDR, Sysmon) per la creazione dei processi e l'attività sui file e log di audit cloud (CloudTrail, Azure Monitor) per le chiamate API. Un SIEM aggrega e correla queste fonti eterogenee.

Gli analisti SOC esaminano ogni giorno centinaia o migliaia di avvisi, la maggior parte dei quali sono falsi positivi: attività legittime che hanno attivato una regola di rilevamento. Un falso positivo spreca il tempo degli analisti e crea una stanchezza da avvisi che porta a ignorare le minacce reali. Un vero positivo rappresenta un'attività effettivamente dannosa. Un falso negativo è l'esito più pericoloso: un'attività dannosa che non ha generato alcun avviso. Ottimizzare le regole di rilevamento per ridurre i falsi positivi senza aumentare i falsi negativi è una competenza fondamentale del SOC.

Le regole di correlazione SIEM combinano più eventi di log individuali per identificare schemi indicativi di attacchi. Esempio: un singolo tentativo di accesso non riuscito è normale; 100 tentativi non riusciti dallo stesso indirizzo IP in 60 secondi indicano un attacco brute force. Un altro esempio: se un utente esegue l'autenticazione dagli Stati Uniti alle 9:00 e poi dalla Cina alle 11:00, si tratta di un viaggio impossibile, probabilmente dovuto a un account compromesso. Regole di correlazione efficaci bilanciano la sensibilità (intercettare gli attacchi reali) con la specificità (non sommergere gli analisti di rumore).

Durante l'analisi, chi interviene raccoglie gli Indicatori di compromissione (IoC) che caratterizzano l'attacco: indirizzi IP sospetti, nomi di dominio dannosi, hash dei file contenenti malware, chiavi di registro modificate dall'attaccante, nomi insoliti dei processi o relazioni tra processi padre e figlio e connessioni di rete anomale. Gli IoC vengono utilizzati per: determinare l'ambito (questo IoC è presente su altri sistemi?), arricchire la threat intelligence, bloccare ulteriori accessi dell'attaccante e sviluppare regole SIEM per rilevare attività simili in futuro.

L'analisi dell'ambito risponde alle domande: Quali sistemi sono interessati? A quali dati è stato effettuato l'accesso o quali dati sono stati esfiltrati? Come e quando è entrato l'attaccante? Chi interviene utilizza l'analisi dei log per ricostruire la sequenza temporale dell'attacco, identificare il vettore di accesso iniziale, elencare tutti i sistemi toccati dall'attaccante (movimento laterale) e determinare se i dati sono stati esfiltrati (picchi nei trasferimenti in uscita, directory di staging dei dati). La valutazione dell'ambito guida le decisioni di contenimento: non è possibile contenere ciò che non è stato mappato.

Le piattaforme EDR (Endpoint Detection and Response) sono lo strumento tecnico principale per l'analisi degli incidenti a livello di endpoint. La telemetria EDR fornisce: alberi di esecuzione dei processi (quale processo ne ha avviato un altro), attività del file system, connessioni di rete per processo, modifiche al registro e rilevamento dell'iniezione nella memoria. Durante un incidente, l'EDR consente agli analisti di cercare simultaneamente un IoC su tutti gli endpoint (threat hunting a livello aziendale), isolare un endpoint compromesso dalla rete ed estrarre artefatti forensi senza toccare fisicamente il sistema.

Le evidenze di rete sono spesso la fonte più affidabile durante l'analisi di un incidente. NetFlow e VPC Flow Logs rivelano le connessioni tra i sistemi senza mostrare il contenuto del payload, risultando utili per mappare il movimento laterale. La cattura completa dei pacchetti (PCAP) mostra il contenuto completo della conversazione, comprese credenziali, dati esfiltrati e comandi C2 (se il traffico non è crittografato). I log delle query DNS rivelano il beaconing del malware verso i domini C2. Chi interviene cerca: grandi trasferimenti di dati in uscita, connessioni verso porte insolite, schemi di beaconing (connessioni regolari ogni N secondi) e comportamenti di scansione interna.

Ricostruire la sequenza temporale dell'attacco è essenziale per comprendere il tempo di permanenza (per quanto tempo l'attaccante è stato presente prima del rilevamento), identificare il vettore di accesso iniziale (per chiudere la vulnerabilità) e conservare le prove in ordine cronologico per i procedimenti giudiziari. Le sequenze temporali vengono create correlando i timestamp provenienti da più fonti di log. La sincronizzazione dell'ora (tramite NTP) è fondamentale: i log con orologi di sistema errati creano lacune e contraddizioni nelle sequenze temporali, compromettendo le conclusioni forensi.

Non tutti gli avvisi richiedono l'attivazione completa del CSIRT. Gli analisti utilizzano criteri documentati per determinare i trigger di escalation: la scoperta di una violazione dei dati confermata attiva le notifiche obbligatorie alle autorità di regolamentazione e l'escalation ai dirigenti. La scoperta di malware che si è diffuso oltre un singolo sistema attiva il coinvolgimento completo del CSIRT. Una singola e-mail di phishing, se non è stato fatto clic, rimane al livello di un analista di livello 1. Soglie di escalation ben definite evitano sia reazioni eccessive, che sprecano risorse per eventi minori, sia reazioni insufficienti, che consentono a violazioni gravi di aggravarsi mentre vengono trattate come semplici avvisi.

Verifichi la Sua comprensione dei concetti di CompTIA Security+ (SY0-701) trattati in questa lezione.

In questa lezione ha imparato che: il rilevamento si basa su diverse fonti di log aggregate da un SIEM, con regole di correlazione che identificano modelli di attacco composti da più eventi, gli IoC raccolti durante l'analisi vengono utilizzati per definire l'ambito dell'incidente su tutti i sistemi e sviluppare regole di blocco e i falsi negativi sono l'esito più pericoloso perché consentono agli aggressori di operare senza essere rilevati. Nel prossimo modulo esamineremo contenimento, eradicazione e ripristino.