Introduzione alle operazioni SIEM: una guida pratica per il Blue Team

Le piattaforme Security Information and Event Management (SIEM) sono al cuore della maggior parte dei Security Operations Center (SOC). Aggregano i log, correlano gli eventi e generano alert che gli analisti devono sottoporre a triage e investigare. Questa guida illustra il flusso operativo principale in modo che tu possa iniziare a pensare come un analista SIEM, indipendentemente dalla piattaforma (Splunk, Elastic, Microsoft Sentinel, QRadar, ecc.) che usa la tua organizzazione.

Cosa fa davvero un SIEM

Al suo livello più elementare, un SIEM svolge tre funzioni: raccoglie i log da endpoint, dispositivi di rete, applicazioni e servizi cloud; normalizza i dati in uno schema coerente; e correla gli eventi usando regole di rilevamento per generare alert. Gli analisti poi elaborano questi alert attraverso un ciclo di triage e investigazione. Comprendere questa pipeline ti aiuta a diagnosticare i problemi quando i dati sembrano sbagliati o gli alert sembrano mancanti.

Configurazione delle sorgenti di log

Prima che qualsiasi logica di rilevamento abbia importanza, hai bisogno di dati affidabili. Le sorgenti comuni includono:

• Telemetria degli endpoint (agenti EDR, Windows Event Logs via Sysmon)
• Dati di rete (log del firewall, query DNS, log proxy, NetFlow)
• Log di autenticazione (Active Directory, VPN, provider SSO)
• Log di audit del cloud (AWS CloudTrail, Azure Activity Logs, GCP Audit Logs)

Quando carichi una nuova sorgente, verifica l'accuratezza del timestamp, conferma che il parsing dei campi sia corretto e controlla il volume di ingestion rispetto ai baseline attesi. Un parser mal configurato interrompe silenziosamente i rilevamenti senza lanciare errori, quindi controlla regolarmente gli eventi grezzi rispetto ai campi parsati.

Scrittura e ottimizzazione delle regole di rilevamento

La maggior parte dei SIEM utilizza una forma di ricerca correlata o sintassi di regola di rilevamento. Un esempio semplice in SPL di Splunk potrebbe assomigliare a questo:

index=auth sourcetype=windows EventCode=4625
| stats count by user, src_ip
| where count > 10

Questa regola contrassegna gli account con più di 10 tentativi di accesso falliti, un indicatore classico di brute-force. Quando costruisci regole:

1. Inizia in modo restrittivo, poi amplia in base al tasso di falsi positivi.
2. Mappa ogni regola a una tecnica MITRE ATT&CK per il contesto e il tracciamento della copertura.
3. Documenta l'intento della regola, la sorgente dati attesa e i scenari di falsi positivi noti.
4. Imposta soglie realistiche — troppo sensibile e gli analisti affogano nel rumore; troppo lasca e le minacce reali passano inosservate.

Flusso di lavoro del triage degli alert

Una volta che un alert si attiva, il compito dell'analista è rispondere a: è malevolo e richiede escalation? Una checklist pratica di triage:

• Convalida l'alert — conferma che l'evento sottostante sia effettivamente avvenuto e non sia un artefatto di parsing.
• Arricchisci con contesto — controlla la criticità dell'asset, il ruolo dell'utente, la geolocalizzazione dell'IP di origine e gli alert correlati recenti sullo stesso host.
• Cerca una tendenza — pivot sull'utente, l'IP o l'hash in una finestra temporale più ampia per vedere se è isolato o parte di una campagna più ampia.
• Classifica — vero positivo, falso positivo o vero positivo benigno (attività reale, ma non malevola, come uno script legittimo di un amministratore).
• Escalation o chiusura — documenta il tuo ragionamento in entrambi i casi; gli alert chiusi hanno comunque bisogno di una giustificazione chiara per scopi di audit.

Creazione di dashboard efficaci

I dashboard dovrebbero rispondere a domande operative specifiche, non solo sembrare impressionanti. Esempi utili includono:

• Top sorgenti di autenticazione fallite nelle ultime 24 ore
• Volume di alert per gravità e assegnazione dell'analista
• Integrità della sorgente dati (lag di ingestion, interruzioni)
• Copertura di rilevamento mappata rispetto alle tattiche ATT&CK

Evita la proliferazione di dashboard — una manciata di viste ad alto segnale è meglio di venti pannelli raramente controllati.

Gestione dell'affaticamento da falsi positivi

L'affaticamento da alert è uno dei rischi operativi più grandi in un SOC. Affrontalo con:

• Revisione regolare degli alert chiusi per identificare i pattern ricorrenti di falsi positivi.
• Soppressione dell'attività nota come benigna con eccezioni documentate (non disabilitazione di regole completa).
• Tracciamento del tempo medio di triage e del tempo medio di risposta come metriche per individuare i colli di bottiglia.
• Rotazione dei cicli di revisione delle regole di rilevamento in modo che le regole vecchie e rumorose vengano affinate o ritirate.

Documentazione e passaggio di consegne

Ogni investigazione dovrebbe lasciare una traccia: cosa ha attivato l'alert, cosa è stato controllato, quale conclusione è stata raggiunta e quali azioni di follow-up sono necessarie. Questo è importante per i passaggi tra turni, gli audit di compliance e la costruzione della conoscenza istituzionale che sopravvive al turnover degli analisti. Un semplice template di runbook per tipo di alert — passaggi di investigazione, contatti per escalation e prove previste — fa risparmiare tempo significativo sotto pressione.

Pratica pratica

Il modo più veloce per acquisire fluidità con SIEM è la ripetizione: ingestion dei log di esempio, scrittura di alcune regole di rilevamento rispetto alle tecniche di attacco note e pratica dell'intero ciclo di triage da capo a fondo. Dataset gratuiti e stack SIEM open-source (come Elastic Stack) sono ambienti eccellenti a basso costo per questo.

Sei pronto ad approfondire i fondamenti del blue team? Esplora i segmenti correlati di Korra Studio sull'analisi dei log, i flussi di lavoro di risposta agli incidenti e l'ingegneria del rilevamento per continuare a costruire il tuo set di competenze SOC.