Categoria: SIEM

L’articolo di oggi pubblicato su Linkedin è sicuramente introduttivo e cita soltanto alcuni dei punti che ho avuto modo di valutare e riscontrare in questi mesi.

Credo fortemente che l’integrazione sul SIEM possa fare la differenza tra una detection e per questo nei prossimi mesi ho deciso di deployare un piccolo SIEM, probabilmente basato su Elastic, ma sono pronto a valutare anche Splunk e Qradar nelle versioni trial/community, per cercare di affrontare nel nostro piccolo le tematiche citate nel post.

Tuttavia credo che l’onboarding di dati all’intero del SIEM debba essere effettuato da una persona diversa da un analista o da un incident responder in quanto il lavoro di integrazione si lega quasi più ad una figura sistemistica che ad un operatore della cybersecurity.

Non voglio aggiungere un altro ruolo a i mille già presenti nel settore ma la posizione ibrida tra il sistemista, che sa come modificare la configurazione e il security engineer che sa quali dati sono importanti per la detection e l’analisi credo possa giocare un ruolo centrale nel deploy di un SIEM.

La discussione è sicuramente aperta qui, su linkedin, o sul discord di Security Cert.

Diversi mesi fa parlavo di come gli EDR potessero avere più o meno visibilità in base alla loro telemetria e citavo il progetto EDR-telemetry; allo stesso modo, oggi vorrei parlare di un riscontro che sto avendo nell’ultimo anno, durante il quale mi sono dedicato alle integrazioni sui SIEM di diverso tipo.
In entrambi i casi l’obiettivo è lo stesso: ottenere la maggiore visibilità possibile da parte del prodotto scelto. E non parlo di detection, di SOAR o di altro, ma proprio di visibilità.

Si parte da questo aspetto per diversi motivi: poter capire la mole di dati che l’infrastruttura (on-prem o cloud) dovrà gestire e comprendere se l’analisi iniziale era corretta o se è necessario aumentare le risorse disponibili;
comprendere quali dati possiamo visualizzare all’interno del nostro SIEM, così da poter definire anche le regole e le automazioni che vogliamo predisporre;
verificare che il SIEM scelto possa eseguire il parsing dei log provenienti dalle fonti individuate;
infine, avere tutti i dati in caso di attacco, in quanto, se dovessero emergere riscontri durante la configurazione del SIEM, abbiamo già la possibilità di estrarre i log necessari.
In ambito IT spesso si gestiscono i vari prodotti tramite agent: installo l’agent EDR, l’agente per il monitoraggio, quello per il backup, e le configurazioni sono spesso già predisposte.

Nel caso del SIEM, invece, dobbiamo cambiare prospettiva e non fermarci a mettere la spunta sul fatto che stiamo raccogliendo i log di Windows Security da quel server, ma approfondire quali servizi e applicazioni sono presenti su quel server e procedere a inviare al SIEM ogni log possibile o compatibile. Il cambio di approccio è proprio nella visione del target host: non si tratta di spuntare la semplice raccolta log da quel server, ma di includere tutti i servizi presenti su di esso.

Un esempio pratico può essere quello delle richieste DNS demandate ai domain controller: queste, di default, non sono raccolte dal SIEM, e si potrebbe pensare che, una volta raccolti i log sul registro eventi dei domain controller, la gestione di questi server sia conclusa. In realtà, stiamo chiudendo gli occhi del nostro SIEM su uno dei dati che più può fornirci riscontri e feedback sulla rete aziendale.

Diventa quindi fondamentale analizzare in profondità le funzioni dei nostri host e assicurarsi che la raccolta avvenga per tutti i diversi applicativi e le funzionalità attive su di essi.

Come sempre, la discussione è aperta qui sotto nei commenti. Non nascondo che sono alla ricerca di un tool o di una piccola checklist per un deploy SIEM con i fiocchi.