Un Security Information and Event Management, un sistema SIEM, è uno strumento completo che
agisce come centro nevralgico delle operazioni di sicurezza di un'organizzazione.
Raccoglie logs e dati relativi alla sicurezza da una vasta gamma di fonti attraverso l'
infrastruttura digitale, inclusi endpoints, server, dispositivi di rete, servizi cloud,
e vari strumenti di sicurezza come firewall o sistemi antivirus.
Il vantaggio principale di un SIEM è la sua capacità di centralizzare questi dati, che è cruciale
per un monitoraggio e un'analisi efficaci. Questo permette ai team di sicurezza di avere una visione
unificata di tutti gli eventi di sicurezza e logs permettendo un rilevamento,
un'investigazione e una risposta più rapidi alle potenziali minacce.
Una delle capacità primarie di un SIEM è il log management centralizzato.
Aggrega logs da diverse fonti come Syslog, Windows event logs,
e servizi cloud-based, snellendo il processo di gestione di grandi volumi
di dati. Questo approccio centralizzato non solo
semplifica lo storage dei dati ma migliora anche l'efficienza
delle operazioni di sicurezza poiché gli analisti possono accedere rapidamente e correlare dati da
vari sistemi. I sistemi SIEM offrono anche una significativa threat
visibility. Correlando eventi da multiple
fonti possono rilevare pattern sospetti che indicano potenziali
minacce come lateral movement all'interno di una rete
o tentativi di privilege escalation all'interno di un host.
Per esempio, se un utente con diritti di accesso limitati
improvvisamente prova ad accedere a dati sensibili, un SIEM segnalerebbe questo come un potenziale
incidente di sicurezza. Inoltre, i sistemi SIEM giocano un ruolo
cruciale nell'aiutare le organizzazioni a mantenere la security compliance.
Possono essere configurati per soddisfare vari standard normativi
come PCI DSS, NIST, o ISO 27001. Garantendo che le pratiche di sicurezza
siano allineate con i requisiti del settore per questa compliance.
Questi requisiti spesso richiedono un logging dettagliato
e monitoraggio in tempo reale, entrambe funzioni core dei sistemi SIEM.
Per esempio, una società di vendita al dettaglio potrebbe usare un sistema SIEM per monitorare i suoi sistemi
di elaborazione pagamenti. Un sistema potrebbe essere configurato per inviare un alert
se vengono fatti tentativi di login fuori dall'orario lavorativo
da un indirizzo IP straniero, segnalando una potenziale violazione della sicurezza.
Questo alert automatizzato permette al team di sicurezza di investigare la
situazione e intraprendere azioni prima che avvenga un attacco su vasta scala.
I SIEM iniziano la loro operazione raccogliendo logs da una varietà di data
sources all'interno dell'infrastruttura di un'organizzazione.
Queste fonti includono endpoint, server, switch,
router, firewall, e appliance di sicurezza,
tutti i quali generano logs in formati diversi.
Per dare un senso a questi dati disparati, i SIEM impiegano un processo di log
normalization. Questo processo comporta la conversione di logs da vari formati
in una struttura unificata, permettendo loro di essere analizzati e
correlati efficientemente. Il processo tecnico di log collection
tipicamente coinvolge collectors o agents come NXLog,
Winlogbeat, o Beats da ELK Stack, Fluentd, o altri
che estraggono dati da queste risorse. Questi agents sono responsabili di raccogliere
i logs e inviarli al SIEM per l'elaborazione.
Una volta raccolti, i logs vengono normalizzati usando regole di parsing predefinite e
field mappings. Questo passaggio converte i dati in uno schema
coerente come il Common Event Format (CEF) o JSON.
Questi formati standardizzano la struttura dei logs, rendendoli
più facili da analizzare e cercare attraverso l'intero sistema,
indipendentemente dalla fonte originale. Un altro aspetto critico della normalizzazione
è l'unificazione del timestamp. Dato che i logs sono generati in diversi
potrebbero essere generati in fusi orari diversi o potrebbero sperimentare clock drifts,
è essenziale allineare i timestamp per garantire che gli eventi siano
accuratamente correlati attraverso i sistemi.
Senza l'unificazione del timestamp, i logs da diverse fonti potrebbero apparire fuori
sequenza, rendendo difficile tracciare il flusso degli
eventi e identificare incidenti di sicurezza. Per esempio, immaginate un sistema SIEM
che riceve logs da un firewall Cisco ASA
e un set di server Linux. Ognuna di queste fonti può generare logs in
formati diversi. Il sistema SIEM standardizzerà
questi logs così una singola ricerca può cercare tentativi di
login SSH attraverso entrambi i sistemi indipendentemente dal fatto che i logs provengano
da un firewall o dai server. Questa normalizzazione abilita gli analisti a
correlare rapidamente ed efficientemente gli eventi portando a una più veloce
identificazione di potenziali minacce di sicurezza.
In sintesi, i SIEM si affidano alla log collection e normalization
per trasformare dati diversi in un formato strutturato
che può essere efficacemente analizzato e correlato. Questo processo garantisce che
i team di sicurezza possano identificare rapidamente e rispondere agli incidenti
indipendentemente dai sistemi che generano i dati.
Le capacità tecniche dei SIEM abilitano loro di eseguire
il tipo di analisi sofisticata. I Correlation engines
sono al cuore di questa funzionalità. Questi motori abbinano pattern usando
regole predefinite o stabilendo behavioral
baselines. Facendo ciò, il SIEM può rilevare anomalie
che deviano dal comportamento normale di un sistema
o un utente come un numero insolitamente alto di login falliti in un breve
periodo. Soglie ed euristiche vengono poi
applicate per determinare quando questi pattern dovrebbero attivare un alert,
aiutando a ridurre il rumore e focalizzando l'attenzione su eventi che sono più
probabili indicare un incidente di sicurezza. I SIEM offrono anche la flessibilità di
personalizzare le regole di alert per bisogni specifici.
Per esempio, puoi creare regole basate su firme di attacco note
come specifici pattern di traffico di rete associati a malware
o su anomalie comportamentali come orari di login insoliti
o attività fuori dalle normali ore lavorative.
Inoltre, molte piattaforme SIEM supportano scripting di regole personalizzate
in linguaggi come Lucene, SPL, Search Processing Language che è in
Splunk, Sigma o
Kibana Query Language (KQL) e altri, permettendo ai team di sicurezza di adattare le loro
capacità di rilevamento al loro ambiente specifico.
Un esempio di come la correlazione SIEM funziona in pratica potrebbe essere quando un utente fa login
da due località geograficamente distanti come New York
e Singapore nel giro di pochi minuti.
Questo evento potrebbe essere segnalato dal sistema SIEM usando una regola personalizzata di geolocation
velocity. Questa regola compara i pattern di login dell'utente
contro le località geografiche note e segnala un cambio rapido come una
potenziale indicazione di compromissione delle credenziali o account takeover.
Correlando questi eventi, il sistema SIEM può fornire agli analisti di
sicurezza alert azionabili che richiedono ulteriore investigazione.
In sintesi, i SIEM usano la correlazione dei dati per collegare eventi e scoprire complessi
pattern di attacco. Combinando regole predefinite, analisi
comportamentale e condizioni di alert personalizzabili, i sistemi SIEM possono aiutare
le organizzazioni a rilevare e rispondere agli incidenti di sicurezza più
efficacemente ed efficientemente.
Le SIEM dashboards sono strumenti essenziali per gli analisti di sicurezza fornendo
visualizzazione in tempo reale delle attività di rete e sistema.
Queste dashboard aiutano i team di sicurezza a monitorare indicatori chiave
di performance come tentativi di login falliti,
dinieghi del firewall e rilevamenti di virus. Mostrando queste informazioni in un formato
facile da capire, le SIEM dashboards permettono
agli analisti di identificare rapidamente e agire su
potenziali minacce di sicurezza, riducendo il tempo che serve per rispondere agli
incidenti. Una delle caratteristiche chiave delle SIEM dashboards
è l'abilità di mostrare il volume degli eventi,
livelli di gravità e alert attivi in tempo reale.
Questa vista dinamica aiuta gli analisti a tracciare il flusso dei dati di sicurezza e
dare priorità alla risposta basandosi sulla criticità di ogni evento.
Per esempio, se c'è un'impennata nei tentativi di login falliti o un improvviso
picco in attività di rete sospetta, sarà immediatamente
visibile sulla dashboard, sollecitando ulteriore
investigazione. Inoltre, molte SIEM
dashboards includono viste drill-down.
Questo permette agli analisti di cliccare su specifiche anomalie o alert ed esaminare
i dettagli come la fonte dell'attività,
l'utente o dispositivo associato e altre informazioni
contestuali. Questa capacità velocizza il processo di
investigazione, abilitando gli analisti a prendere decisioni informate rapidamente.
I sistemi SIEM forniscono anche capacità di reporting,
offrendo template predefiniti che possono essere personalizzati per soddisfare bisogni
organizzativi o requisiti normativi. Questi report aiutano a garantire la conformità con
standard come PCI DSS o GDPR e sono spesso usati per audit
o sommari esecutivi. L'abilità di pianificare questi report garantisce che
le parti interessate rimangano informate sulla postura di sicurezza e che la compliance
sia continuamente monitorata. Per esempio, un Security Operation Center,
un team SOC, potrebbe usare la dashboard del SIEM per monitorare tentativi di login
SSH attraverso i server di produzione. Se avvengono più di 10 tentativi di login falliti
entro cinque minuti su qualsiasi server, il sistema può attivare un alert.
Questo permette ai team SOC di investigare potenziali tentativi di attacco brute force,
prendendo rapidamente azione per prevenire una
intrusione di successo. In sintesi, le SIEM dashboards sono molto cruciali
per fornire visibilità in tempo reale negli eventi di sicurezza
e snellire il processo investigativo. Combinando funzionalità di
monitoraggio live, analisi drill-down e reporting automatizzato, i SIEM potenziano
i team di sicurezza per rispondere più velocemente e mantenere la compliance all'interno degli
standard organizzativi e normativi.
Quindi, come possiamo vedere, una delle capacità chiave del SIEM
è il rilevamento di comportamento insolito. Per esempio, se un utente fa login
a orari strani, come alle 3 del mattino, o da una geolocalizzazione
non familiare, il SIEM può segnalare questa attività come sospetta.
È come User Behavior Analytics (UBA). Queste anomalie possono essere indicative di
credenziali compromesse o tentativi di accesso non autorizzato.
Un'altra caratteristica potente è l'abilità di correlare eventi multipli in un
singolo alert consolidato. Per esempio, un SIEM può rilevare una serie di
tentativi di login falliti, seguiti da un login di successo e successiva
privilege escalation. Quando questi eventi accadono in stretta successione,
il SIEM li collega insieme, attivando un alert che aiuta i team di sicurezza
a identificare potenziali attacchi come tentativi di login brute force
o lateral movement all'interno della rete. Inoltre, i SIEM possono
integrarsi con feed di threat intelligence, per abbinare attività contro
indicatori noti di compromissione, come indirizzi IP,
file hashes o nomi di dominio associati a
comportamento dannoso. Questo permette loro di segnalare traffico
o azioni che si allineano con pattern di attacco noti,
aggiungendo un altro strato di contesto e precisione al processo di rilevamento.
I SIEM possono anche estrarre threat intelligence e
indicators of compromise per aiutare altri SIEM a rispondere
a tali attività. Vediamo, per esempio, immaginate un SIEM che rileva un
login di account utente alle 3 del mattino
da un indirizzo IP straniero. Se l'utente poi accede a
file sensibili, il sistema può attivare un alert basato su
regole di correlazione preconfigurate che collegano il
comportamento di login insolito con il successivo accesso a dati sensibili.
Quindi è come una kill chain. Questa sarà identificata dal SIEM.
Questo rilevamento precoce aiuta i team di sicurezza a rispondere prontamente,
minimizzando il rischio di un data breach.
I SIEM moderni hanno capacità avanzate che vanno oltre
il solo rilevare minacce. Possono anche attivare azioni predefinite
in risposta a specifici alert, il che riduce significativamente la necessità di
intervento manuale e accelera il processo di contenimento
dell'incidente. Questa automazione permette ai team di
sicurezza di rispondere a potenziali minacce più velocemente e più efficientemente,
minimizzando l'impatto delle violazioni di sicurezza. Per esempio, un SIEM può automaticamente
bloccare indirizzi IP, naturalmente, inviando una regola firewall allo specifico
firewall che sono coinvolti in attività dannose,
come quando si è in un tentativo di login brute force o attacchi DDoS.
Quando molteplici tentativi di login falliti sono stati rilevati, il SIEM può attivare un'
azione per bloccare l'indirizzo IP sospetto,
prevenendo ulteriori tentativi di accesso non autorizzato.
Un'altra azione che i SIEM intraprendono è disabilitare automaticamente account compromessi.
Se il sistema rileva comportamento di login insolito, come login da
altre località o orari strani, può istantaneamente disabilitare
l'account affetto per prevenire qualsiasi potenziale data breach o escalation.
Quindi può essere integrato il SIEM con firewall o controlli di accesso identità
per revocare diritti ed effettivamente rispondere all'
alert. In aggiunta, i SIEM possono inviare alert in tempo reale ai team di
sicurezza via vari canali come email, Slack,
o integrazione con strumenti di Security Orchestration, Automation
and Response, come chiamiamo SOAR. Questo garantisce che le persone giuste
siano notificate immediatamente, permettendo loro di intraprendere azione rapida.
Facciamo un esempio. Immaginate che un SIEM rilevi multipli tentativi di login SSH
falliti, seguiti da un login di successo da una
fonte non familiare. Rilevando questo pattern, il SIEM
potrebbe automaticamente bloccare l'indirizzo IP sospetto
attraverso il firewall per prevenire ulteriori tentativi di accesso.
Simultaneamente, potrebbe inviare una notifica email al Security Operation
Center, al team SOC, con i dettagli dell'incidente per ulteriore
investigazione. Vediamo uno strumento specifico, Splunk.
Splunk è una soluzione SIEM commerciale nota per la sua scalabilità,
ricca visualizzazione e potenti capacità di ricerca.
Ingerisce logs e dati macchina da un'ampia varietà di fonti, abilitando
monitoraggio in tempo reale, rilevamento minacce e reporting di conformità.
Una delle caratteristiche chiave di Splunk è la sua Search Processing Language,
anche come la chiamiamo SPL. SPL è un linguaggio di query
domain-specific che abilita ricerche complesse, analisi statistica e la
creazione di dashboard visuali. Gli analisti usano SPL di Splunk
per immergersi nei dati e identificare potenziali minacce.
Fornisce un'esperienza di ricerca altamente personalizzabile,
aiutando gli analisti a identificare minacce e outlier
in grandi dataset, come ripetuti tentativi di login falliti
o pattern di traffico di rete insoliti. Un altro potente strumento in Splunk è il
Machine Learning Toolkit, che permette agli utenti di costruire modelli predittivi
per il rilevamento di anomalie e User Behavior Analytics,
UEBA. Questo toolkit aiuta a rilevare minacce sconosciute identificando
pattern insoliti nei dati, che potrebbero non essere segnalati dai tradizionali
metodi di rilevamento basati su regole. Abilita Splunk ad andare oltre le ricerche base
e fornire intuizioni sul comportamento futuro, aiutando gli analisti
a rilevare minacce avanzate come insider threats o attacchi zero-day.
L'Enterprise Security module di Splunk aggiunge un livello addizionale di
funzionalità su misura per le operazioni di sicurezza.
Include dashboard specifiche per la sicurezza, integrazione di threat intelligence
e funzionalità di revisione incidenti. Questo modulo snellisce il rilevamento e la
gestione degli incidenti di sicurezza offrendo strumenti specializzati per il threat
hunting e incident response, rendendo più facile per gli analisti
investigare e mitigare potenziali minacce attraverso l'infrastruttura.
Per esempio, un analista di sicurezza potrebbe usare SPL
per cercare tentativi di login falliti attraverso vari sistemi nella rete.
La query potrebbe essere qualcosa come index equals
auth sourcetype equals linux_secure action equals failed
e poi stats count by user and source.
Questo permette all'analista di individuare rapidamente comportamento anormale come un grande
numero di login falliti da un singolo utente o indirizzo IP,
che potrebbe indicare un attacco brute force. Usando SPL, l'analista può
immediatamente intraprendere azioni come bloccare account o
bloccare indirizzi IP dannosi per prevenire ulteriore escalation
della minaccia. La combinazione di Splunk di querying avanzato, machine
learning e moduli di sicurezza su misura lo rende uno
strumento essenziale per operazioni di sicurezza su larga scala.
Abilita le organizzazioni a rilevare e rispondere alle minacce
più velocemente, fornendo visibilità e intuizioni
azionabili sulla postura di sicurezza della rete.
Un altro strumento, un SIEM, è l'ELK Stack, che è basato su Elasticsearch,
Logstash e Kibana. Questa è un'alternativa open-source che ha guadagnato
significativa trazione nelle implementazioni SIEM ultimamente.
Mentre richiede più setup e configurazione comparato a soluzioni
commerciali come Splunk, fornisce alle organizzazioni
flessibilità e controllo dei costi. Questo lo rende particolarmente
attraente per aziende con team DevOps o SecOps in-house.
L'ELK Stack offre potenti capacità per aggregazione log, analisi e
visualizzazione, che è chiave per mantenere un efficace
monitoraggio della sicurezza. Al cuore dell'ELK Stack c'è Elasticsearch,
un motore di ricerca veloce e distribuito progettato per indicizzare e cercare vaste
quantità di dati log. Permette querying più in tempo reale,
rendendolo ideale per recuperare e analizzare rapidamente dati log.
Elasticsearch eccelle nel gestire grandi dataset, garantendo rapidi tempi
di risposta anche quando si tratta di ricerche complesse.
Questo garantisce che i team di sicurezza possano interrogare i dati efficientemente
e identificare pattern o anomalie in maniera tempestiva.
Successivamente, Logstash gestisce l'ingestion dei dati
e la trasformazione. Estrae log dai dati, i dati log da varie risorse,
li parsa e poi invia i dati processati a Elasticsearch.
Il ruolo di Logstash è critico perché i logs sono spesso generati in formati
diversi attraverso sistemi multipli. Garantisce che i dati siano standardizzati,
parsati correttamente e poi arricchiti con contesto addizionale dove necessario,
rendendoli pronti per l'analisi. Senza questo passaggio i logs sarebbero difficili da lavorare
e ostacolerebbero qualsiasi investigazione significativa.
Infine, Kibana serve come strato di visualizzazione dell'ELK Stack.
Abilita gli utenti a creare dashboard interattive ed eseguire query usando
sintassi basata su Lucene. Supportano Kibana Query Language (KQL), Elastic Query
Language e così via. Kibana permette agli analisti di sicurezza di visualizzare
trend di dati, identificare potenziali minacce e tracciare
metriche chiave in tempo reale. Attraverso dashboard personalizzabili, gli utenti possono
facilmente monitorare anomalie, creare report e rispondere a eventi di sicurezza
emergenti con una chiara panoramica visuale che Kibana fornisce.
Per esempio, quando si monitora per attacchi brute force SSH,
Logstash può essere impostato per parsare i log SSH
dalla cartella /var/log/auth.log dove i tentativi di login sono registrati su un sistema
Linux. Questi log sono processati e indicizzati da
Elasticsearch, un database NoSQL, rendendoli facili da cercare e interrogare.
Kibana può poi visualizzare i tentativi di login falliti nel tempo.
Mostrando trend e mappando gli IP sorgente.
Questo setup permette ai team di sicurezza di identificare rapidamente pattern anormali,
come multipli tentativi falliti da un singolo IP, che possono segnalare
un attacco brute force.
Quando si comparano Splunk e l'ELK Stack, ci sono diverse differenze chiave in
termini di funzionalità, licensing e scalabilità.
Comprendere queste differenze può aiutare le organizzazioni
a scegliere la soluzione giusta per i loro bisogni di monitoraggio di sicurezza e log management.
Il licensing è uno dei contrasti più
significativi tra i due. Splunk opera su un modello
di prezzo a livelli commerciale, significando che l'organizzazione deve pagare basandosi sulla
quantità di dati ingeriti. Mentre questo modello offre robusto supporto
enterprise, può diventare molto costoso all'aumentare del volume di dati.
D'altra parte, l'ELK Stack è open source, il che significa che è gratuito da usare.
Tuttavia, le organizzazioni che richiedono supporto addizionale,
Elastic, l'azienda dietro l'ELK Stack,
offre opzioni di supporto a pagamento, fornendo la flessibilità
di scalare secondo necessità senza un significativo investimento
iniziale in licensing. In termini di linguaggio di query, Splunk usa il suo proprio
Search Processing Language proprietario, SPL. SPL è altamente
flessibile e potente, permettendo agli utenti di eseguire ricerche complesse,
analisi statistica, e persino creare dashboard personalizzate.
Mentre SPL offre capacità avanzate, può anche avere una curva di
apprendimento più ripida per utenti non familiari con questi blocchi
decisionali. L'ELK Stack, in contrasto, usa
Lucene e Kibana Query Language, entrambi i quali sono più standardizzati
e più facili da imparare, ma meno avanzati comparati a SPL.
Per coloro che hanno già familiarità con SQL, come
linguaggio di query, Kibana Query Language offre un punto di ingresso più accessibile.
Sembra simile a SQL, ma potrebbe supportare,
potrebbe non supportare, il livello di querying complesso che fa SPL.
Quando si tratta di complessità di setup, Splunk è noto per essere facile da deployare,
specialmente con le sue opzioni di supporto enterprise.
Questo lo rende ideale per organizzazioni che hanno bisogno di una soluzione
rapida out-of-the-box con configurazione minima.
L'ELK Stack, tuttavia, richiede più configurazione manuale e tuning.
Può essere impostato per soddisfare requisiti specifici, ma questo significa anche che è necessario più
sforzo per il deployment, specialmente quando si scala
attraverso ambienti multipli. Le capacità di integrazione variano anche tra le due
soluzioni. Splunk offre estese integrazioni
built-in e add-on, rendendolo più facile da incorporare in un ambiente
esistente. Queste integrazioni pre-costruite con
sistemi popolari e strumenti aiutano a snellire i processi di deployment.
Nel frattempo, l'ELK Stack è altamente estensibile,
offrendo la flessibilità di integrarsi con molti sistemi attraverso plugin
e Beats, leggeri data shippers. Gli agent su ELK
si chiamano Beats. Questa estensibilità permette all'ELK Stack di
essere personalizzato e su misura per specifici casi d'uso.
Tuttavia, potrebbe richiedere configurazioni addizionali
per garantire integrazione senza interruzioni con i sistemi.
Infine, la scalabilità è un'area dove entrambe le soluzioni differiscono.
Splunk è cloud-native, offrendo capacità di scaling che sono gestite da
Splunk cloud stesso. Questo rende più facile per le organizzazioni
scalare verso l'alto secondo necessità senza il peso di gestire l'infrastruttura.
D'altra parte, ELK Stack richiede più gestione manuale del cluster per
lo scaling. Mentre può scalare per gestire grandi dataset,
questo processo richiede più sforzo pratico, inclusa la gestione dei
nodi, gestione della distribuzione dati, e garanzia di alta disponibilità del
sistema stesso. Graylog è una piattaforma di log management
open-source comunemente usata per deployment SIEM di medie dimensioni.
È costruita sopra Elasticsearch e MongoDB,
offrendo una soluzione user-friendly, flessibile, ed estensibile
per gestione e analisi dei log. Nota per la sua semplicità, Graylog è
particolarmente adatta per ambienti dove facilità di setup e personalizzazione
sono cruciali, tuttavia mantiene potenti caratteristiche che soddisfano le
domande dei team di sicurezza. Una delle caratteristiche di spicco di Graylog
è la sua architettura modulare. Usa componenti come inputs,
extractors, e pipelines per processare, filtrare, e arricchire logs,
che fornisce flessibilità in come i dati log sono ingeriti, parsati, e analizzati.
Questa architettura permette alle organizzazioni di adattare le loro pipeline di elaborazione log
per adattarsi a bisogni specifici, rendendo Graylog una soluzione
adattabile per vari casi d'uso. Graylog fornisce anche
filtraggio stream-based, che aiuta gli utenti a instradare logs in specifici stream
basandosi sul loro contenuto. Questo abilita alerting personalizzato e
dashboarding basato sui tipi di log che sono più importanti
per il team di sicurezza. Per esempio, se ci sono certi logs associati
con sistemi critici o particolari minacce,
Graylog può essere configurato per dare priorità a questi eventi e attivare
alert di conseguenza. Alerting e correlazione sono componenti core
di Graylog, offrendo capacità di monitoraggio in tempo reale.
Gli utenti possono configurare condizioni di alert basate su soglie o specifici pattern
all'interno dello stream di logs. Per esempio, se una soglia predefinita
è superata, come multipli tentativi di login falliti,
in un breve periodo di tempo, Graylog può attivare un alert,
notificando il team di sicurezza di potenziali minacce.
Un esempio, un amministratore di rete imposta uno stream per monitorare login SSH
falliti. Lo stream filtra logs dove event
dot action equals SSH login failed. E se più di 10
fallimenti accadono entro un minuto dallo stesso indirizzo IP, Graylog attiva un
alert, aiutando a identificare potenziali attacchi brute-force.
Da una prospettiva tecnica, Graylog supporta diversi
metodi di ingestion, inclusi Syslog,
GELF, che è Graylog Extended Log Format, e REST APIs è supportato,
rendendo Graylog compatibile con un'ampia gamma di fonti log.
La piattaforma usa Elasticsearch ancora per indicizzazione,
che fornisce capacità di ricerca e query veloci attraverso i
grandi dataset. Inoltre, l'ecosistema di plugin di Graylog è
un altro punto saliente, offrendo integrazioni per geolocalizzazione,
threat intelligence, e altri casi d'uso avanzati.
Questa flessibilità permette alle organizzazioni di estendere la funzionalità di Graylog
e adattarsi ai loro specifici bisogni di sicurezza e operativi.
IBM QRadar è una piattaforma SIEM completa di livello enterprise,
ampiamente usata in settori regolamentati, particolarmente dove robusta
sicurezza e requisiti di conformità sono essenziali.
Noto per il suo motore di correlazione avanzato e capacità di integrazione,
QRadar è progettato per gestire ambienti di sicurezza complessi con facilità,
fornendo profonde intuizioni e rilevamento di minacce in tempo reale.
Una delle caratteristiche più notevoli di QRadar è il suo
auto-correlation engine, che usa una logica basata su
regole per rilevare pattern di sicurezza attraverso multiple fonti log.
Questo motore correla automaticamente eventi da vari sistemi,
come firewall, endpoint, e server, per identificare attività sospette.
Un'altra caratteristica chiave di QRadar è la sua capacità di asset modeling.
La piattaforma costruisce dinamicamente un inventario degli asset basato su osservazioni
di traffico di rete, dando ai team di sicurezza una chiara visione
delle vulnerabilità dei loro asset. Questo asset modeling li aiuta a
identificare sistemi critici che vengono presi di mira
e abilita le organizzazioni a dare priorità alle risposte di conseguenza.
Feed di minacce integrati sono un altro vantaggio significativo di QRadar.
Si connette senza interruzioni con threat intelligence esterna,
con provider come IBM X-Force e altri feed di terze parti,
arricchendo il processo di rilevamento e correlazione.
Questa integrazione permette a QRadar di incrociare dati log in arrivo
con indicatori di attacco noti e threat intelligence in evoluzione,
migliorando l'accuratezza degli alert e aiutando i team di sicurezza a rispondere più
proattivamente. Vediamo un esempio d'uso. QRadar
potrebbe correlare ripetuti login falliti da multipli utenti sulla stessa subnet,
seguiti da un login di successo da uno degli altri utenti.
Questa sequenza suggerisce un attacco di credential stuffing, dove gli attaccanti usano
credenziali rubate per ottenere accesso non autorizzato. L'auto correlation engine di QRadar
genererà un'offesa (offense) ad alta gravità,
avvisando il team di sicurezza di una potenziale compromissione delle credenziali.
Da una prospettiva tecnica, QRadar è altamente scalabile,
supportando l'ingestion di log da migliaia di fonti, inclusi firewall,
endpoint, e piattaforme cloud. Questo rende QRadar ben adatto per
grandi ambienti complessi che richiedono log management centralizzato e rilevamento
di minacce. Inoltre, QRadar ha flow analytics integrati
attraverso QFlow che gli permette di ispezionare
traffico Layer 7, fornendo visibilità in attività a livello applicazione,
che è essenziale per rilevare attacchi più avanzati.
QRadar sfrutta anche il database Ariel per ricerche ad alta velocità attraverso
terabyte di dati log, abilitando performance di query veloci,
anche in deployment su larga scala. Questo permette agli analisti di sicurezza di cercare
rapidamente attraverso log estesi e identificare eventi di sicurezza critici,
che è vitale per mantenere capacità di monitoraggio in tempo reale.
Microsoft Sentinel è una soluzione SIEM cloud-native che è strettamente
integrata con Azure, offrendo scalabilità,
potenti analytics, e capacità di risposta automatizzata.
Sfrutta l'AI di Microsoft, machine learning,
e security graph intelligence per fornire rilevamento intelligente delle minacce
e operazioni di sicurezza snellite, rendendolo particolarmente adatto per
imprese che usano già Azure o altri servizi Microsoft.
Uno dei punti di forza chiave di Sentinel è il suo uso di un
Kusto Query Language, KQL, un linguaggio di query veloce e flessibile
ottimizzato per analisi log su larga scala.
KQL permette agli analisti di sicurezza di cercare e analizzare rapidamente vaste
quantità di dati log, rendendolo uno strumento essenziale per identificare
minacce in tempo reale. Il linguaggio è abbastanza potente
da gestire query complesse mentre è abbastanza efficiente
da lavorare alla scala di ambienti enterprise.
Un'altra importante capacità di Sentinel
sono i suoi behavior analytics, che includono User Behavior Analytics,
UEBA. Questa funzione analizza il comportamento utente e di
sistema, per trovare anomalie di dati che potrebbero indicare attività dannosa.
Monitorando continuamente le azioni di utenti ed entità,
Sentinel può identificare deviazioni dal comportamento normale,
come orari di login insoliti, pattern di accesso atipici,
o accesso non autorizzato a risorse, che sono spesso segni di insider threats
o account compromessi. I Playbooks in Microsoft Sentinel,
che sono basati su SOAR, Security Orchestration, Automation and Response,
abilitano le organizzazioni ad automatizzare la risposta agli incidenti.
Usando Azure Logic Apps, i playbooks possono eseguire flussi di lavoro
predefiniti per rispondere agli incidenti di sicurezza automaticamente.
Questi playbooks aiutano a ridurre il tempo di risposta agli incidenti,
garantendo una reazione rapida e coerente alle comuni minacce di sicurezza.
Vediamo un esempio. Le capacità di rilevamento minacce di Sentinel
è la sua abilità di segnalare login impossibili (impossible logins).
Supponiamo che un utente faccia login dalla Germania e poi dagli USA, entro una finestra di due minuti,
Sentinel userebbe query KQL sui
log di accesso per segnalare questo come un'anomalia. Interrogando i
dati GeoIP e timestamp, Sentinel può immediatamente identificare e alertare
sullo scenario impossibile, indicando una potenziale compromissione di credenziali
o un tentativo di accesso non autorizzato. Da una prospettiva tecnica, Microsoft
Sentinel fornisce integrazione senza interruzioni con i
servizi Microsoft, come Microsoft 365, Defender e Azure
activity logs. Questa stretta integrazione aiuta i team di sicurezza
a ottenere visibilità completa attraverso i loro
ambienti cloud e on-premises. Inoltre,
Sentinel supporta un'ampia gamma di terze parti
e connettori come AWS, Cisco e Palo Alto,
che permettono alle organizzazioni di ingerire dati, di ingerire
dati da multiple fonti in una piattaforma centralizzata
per rilevamento e analisi minacce più completi.
Per iniziare a utilizzare Splunk, per esempio, per analisi dati log, è
importante capire ogni passo del processo per ingestion e
configurazione dei dati log. Il primo stadio è navigare su
impostazioni (settings) e add data, che apre un flusso di lavoro semplice e
intuitivo per aggiungere le tue fonti dati.
Questo processo è critico in quanto garantisce che la tua istanza di Splunk
possa propriamente raccogliere dati da una varietà di fonti,
sia da file o monitoraggio in tempo reale. La prima azione
qui è selezionare monitor files and directories.
Questo ti permette di specificare quali file di log tracciare per
collezione in tempo reale. Per esempio, se vuoi
monitorare log di autenticazione da un sistema Linux, potresti
scegliere file come /var/log/auth.log o /var/log/secure kernel o
qualsiasi cosa. Scegliendo l'opzione files and directories
stai dicendo a Splunk di cercare nuove voci di log
che appaiono all'interno di questi file o directory,
che verranno poi indicizzati per ricerca successiva.
Questo è chiave perché significa che Splunk è costantemente consapevole di nuovi eventi,
rendendo più facile rilevare problemi man mano che sorgono in tempo reale.
Successivamente, una delle decisioni più cruciali nel processo di setup è
selezionare un source type per i dati log.
Il source type definisce come Splunk dovrebbe interpretare
e parsare i dati log grezzi. Senza un source type appropriato,
Splunk non sarebbe in grado di estrarre campi significativi
o strutturare i dati correttamente. Per esempio, log di autenticazione Linux
tipicamente usano il source type linux_secure.
Assegnando il source type appropriato,
garantisci che Splunk capisca il formato del log
e possa correttamente scomporre i log in campi come nomi utente,
timestamp, status di login come successo, fallimento, e così via.
Dopo aver definito il source type, il passo successivo è configurare un index.
L'index agisce come un contenitore per i log
ed è essenziale per organizzare le grandi quantità di dati
che possono essere ingerite in Splunk. Per esempio, log di sicurezza potrebbero essere piazzati
in un index chiamato "security_logs", che renderebbe facile
in seguito filtrare e cercare solo attraverso gli eventi relativi alla sicurezza nel tuo
sistema. Raggruppando i log in diversi index,
Splunk può recuperare più efficientemente i dati necessari per l'analisi senza
setacciare informazioni irrilevanti, migliorando
la performance e garantendo che le query di ricerca
siano più veloci e rilevanti. Una volta completata la configurazione di source type e
index, Splunk inizierà automaticamente
ad ingerire i dati log dai file specificati nel database.
Mentre ingerisce quei log, Splunk parsa le voci di log grezze in
eventi strutturati secondo il source type.
Ogni evento contiene importanti campi di metadati come time,
host, source e source type che aiutano a categorizzare i dati e renderli
cercabili. Per esempio, il campo timestamp
last_time ti permetterà di cercare log per data e ora.
Host ti dirà da quale macchina il log è originato
e source type ti aiuterà a identificare il tipo di log,
se è un log di sistema, log applicazione, log di sicurezza e così via.
Questi campi rendono i dati molto più utilizzabili e ti permettono di trovare rapidamente
voci rilevanti in un grande dataset. Una volta che i log sono stati ingeriti
e parsati negli eventi, il passo finale è validare i dati eseguendo
ricerche. È qui che la potenza di Splunk
brilla davvero. Interrogando specifici index e source type,
puoi filtrare rapidamente attraverso i log per scoprire intuizioni preziose.
Per esempio, per tracciare tentativi di login falliti, potresti cercare tutte le voci di
password fallite nei log di sicurezza usando una
query come index=security_logs sourcetype=linux_secure
e poi il messaggio "failed password".
Questa query restituirà tutte le voci che corrispondono a quella stringa di ricerca
che sarebbe incredibilmente utile per identificare potenziali violazioni di
sicurezza, attacchi brute force o misconfigurazioni nel sistema.
Una volta che i tuoi log sono ingeriti in Splunk il passo successivo
è analizzarli usando SPL, il Search Processing
Language. Una delle query più fondamentali in SPL
è usare il comando stats per calcolare metriche attraverso diversi campi nei tuoi
log. Per esempio, se vuoi analizzare quanti
eventi stanno arrivando da diverse fonti log,
puoi usare la seguente query SPL index=security_logs
| stats count by source. Questo fornirà una ripartizione dei conteggi
degli eventi da ogni fonte log aiutando a identificare quali fonti sono più attive.
Questa analisi è importante per i team di sicurezza per monitorare i sistemi
poiché picchi insoliti negli eventi da fonti specifiche potrebbero indicare un
potenziale incidente di sicurezza. Un'altra caratteristica chiave di SPL è il
comando top che identifica i valori più
frequenti in un campo specifico. Per esempio, se vuoi vedere quali source
type sono più comuni nei tuoi log, potresti usare la query
index=security_logs | top sourcetype.
I source type sono categorie essenziali che Splunk assegna ai log basandosi sul
loro formato. Identificando i
source type più frequenti puoi valutare se le fonti log sono
appropriate categorizzate e se ci sono eventuali tipi di log
inaspettati presentati. Questi source type inaspettati potrebbero puntare
a sistemi mal configurati o nel caso peggiore potenziali
rischi di sicurezza come una nuova fonte di dati non rilevata.
Con questi comandi puoi facilmente immergerti nei tuoi dati log e iniziare a
scoprire intuizioni preziose. Il linguaggio SPL supporta anche
caratteristiche più avanzate come subsearches,
field extractions e analytics basate sul tempo.
Per esempio, se vuoi focalizzarti su log da uno specifico
intervallo di tempo o filtrare eventi specifici che non sono rilevanti
per la tua investigazione, SPL ti permette di raffinare
le tue query secondo il tempo. Questo lo rende uno strumento versatile non solo per
la risposta agli incidenti di sicurezza ma anche per il monitoraggio operativo
continuo. Per rilevare tentativi di brute force, un
metodo efficace usando Splunk è esaminare log per ripetuti
messaggi di login fallito. Gli attacchi brute force spesso coinvolgono un
attacco che prova ripetutamente password diverse in un tentativo di ottenere accesso
non autorizzato al sistema. Questi tentativi falliti sono tipicamente
registrati in log come SSH o log di autenticazione
il che li rende essenziali per rilevare attività dannosa.
Analizzando quei log puoi identificare pattern che indicano attacchi brute force
in corso. Un modo per rilevare un attacco brute force è usando
query nell'analisi log. Quindi index=security_logs "failed
password" quindi questo è il messaggio che dovrebbe apparire nei logs
e poi | stats count by source. Questo comando è specificamente progettato
per trovare istanze dove tentativi di login falliscono. Ecco come funziona.
index=security_logs specifica che la query dovrebbe cercare all'interno dell'
index security logs che probabilmente contiene voci
relative ai tentativi di login. "failed password" cerca eventi
nei log che contengono la frase "failed password"
che è comunemente usata per loggare tentativi di login non riusciti.
| stats count by source è una funzione statistica che conta le
occorrenze quante volte per esempio questa occorrenza è apparsa
raggruppate per indirizzo IP sorgente. Per esempio dovrebbe essere
un indirizzo IP e poi quante password fallite
erano su uno specifico IP. Essenzialmente questa parte del comando aggrega i
dati per mostrare quanti tentativi di login falliti sono venuti da
ogni indirizzo IP unico. Il risultato da questa query potrebbe apparire
così IP address e l'indirizzo IP
quanti tentativi di login falliti sono apparsi
20 per esempio index=security_logs "failed password" | top user
questa query funziona leggermente diversamente ma mira ancora a identificare
l'attacco brute force. Di nuovo security logs è l'
index e failed password è la frase dentro i log.
Il | top user è una funzione che restituisce i nomi utente più frequentemente
presi di mira. Aggrega i dati basandosi sul
numero di volte che ogni username appare nei tentativi di login falliti
essenzialmente classificando i nomi utente basandosi su quante volte sono stati
presi di mira quindi fornirà il numero più alto di
nomi utente che sono stati provati per questi tentativi di login.
Quindi quello è il comando top. Spiegheremo così che il risultato sarà come
username root che è molto comune 15 tentativi username admin 10
tentativi username super user qualsiasi
numero di tentativi. Questo significa che i nomi utente root e admin sono stati
specificamente presi di mira. Tali risultati suggeriscono che gli attaccanti
si stanno concentrando su account di alto valore dalla root dell'admin
e stanno effettivamente provando a fare attacchi brute force sui sistemi.
Visualizzare i dati log è essenziale per individuare rapidamente attività sospette
o comportamento anormale in tempo reale. Le dashboard in strumenti SIEM come Splunk
forniscono un'interfaccia interattiva per tracciare e analizzare trend
come picchi nei tentativi di login falliti o attacchi ripetuti.
Queste visualizzazioni aiutano gli analisti di sicurezza a monitorare potenziali minacce
senza bisogno di setacciare i dati log grezzi manualmente
permettendo una risposta più efficiente ed efficace.
Per tracciare tentativi brute force o altri fallimenti di login
nel tempo puoi usare la query come quella che abbiamo spiegato security logs
"failed password" e poi | timechart span=1h count by source.
Questa query genera un time chart che
traccia tentativi di login falliti per indirizzo IP sorgente su un periodo di tempo specifico
in questo caso orario ogni ora. Scomponendo i dati in incrementi basati sul
tempo puoi visualizzare come i tentativi di login evolvono e identificare improvvisi
picchi o pattern che potrebbero indicare un attacco in corso.
Per creare una rappresentazione visuale di questa query in Splunk
chiudi i passi naviga alla sezione dashboard e seleziona create new
dashboard. Scegli il tipo di grafico che vuoi usare
come un grafico a linee o un grafico a colonne usa la query
index=security_logs "failed password"
| timechart span=1h count by source come fonte dati per il tuo grafico.
Imposta un intervallo di tempo significativo come le ultime 24 ore per fornire la rilevante
vista dell'attività che stai monitorando. L'output atteso è un grafico basato sul
tempo dove puoi tracciare tentativi di login falliti per
IP sorgente. Il grafico mostrerà quali indirizzi IP
stanno tentando login in certi orari e puoi facilmente individuare qualsiasi indirizzo IP
con una frequenza insolitamente alta di tentativi falliti.
Questi sono probabili essere fonti di attacchi brute force.
Con questa visualizzazione puoi rapidamente identificare i più attivi e
potenzialmente dannosi indirizzi IP permettendoti di
intraprendere azione immediata come bloccare l'IP
o investigare ulteriormente l'attività.
Logstash è un potente strumento nell'ELK Stack progettato per ingestione, elaborazione
e inoltro di dati log da multiple risorse.
Quando configuri Logstash per gestire log da un firewall
gioca un ruolo vitale nello strutturare dati log grezzi
in formati significativi e cercabili. Il processo inizia con l'
installazione di Logstash sul tuo server che può essere fatta
usando package manager o scaricando direttamente i binari.
Una volta installato passi alla configurazione della pipeline Logstash
che consiste di tre sezioni principali input, filter e output.
Nella sezione input Logstash è impostato per estrarre log dal file log del tuo firewall
o output syslog. Per esempio i log firewall sono spesso memorizzati in
file come /var/log/firewall.log
e a Logstash deve essere detto dove trovarli.
L'opzione start position beginning garantisce che Logstash processi i log
iniziando dall'inizio del file di log.
Una volta che Logstash ha ingerito i log la sezione filter entra in gioco.
Qui puoi usare filtri come Grok per parsare ed estrarre
specifici campi dati dai log grezzi. Per esempio potresti usare il filtro
Grok per estrarre l'IP sorgente, l'IP destinazione e l'azione intrapresa dal
firewall. Questo passaggio è essenziale per
trasformare dati log non strutturati in campi
strutturati che possono essere indicizzati e analizzati. Infine la sezione output
della configurazione definisce dove andranno i dati parsati.
In questo caso puoi configurare Logstash per inoltrare i dati processati a
Elasticsearch dove saranno indicizzati e resi disponibili per
ricerca e analisi. I log sono solitamente memorizzati in un
index format come "firewall_logs-date" o qualsiasi nome
permettendo facile organizzazione e query basate sulla data in cui i
log sono stati creati o su una diversa tattica e metodologia.
Una volta che il setup è completo e Logstash sta attivamente processando i log
l'output consisterà di dati strutturati che possono essere interrogati e
visualizzati usando strumenti di visualizzazione come Kibana.
Le sue voci firewall come una dell'indirizzo IP
destinazione e sorgente con azione di accept saranno scomposte in
diversi campi rendendo facile cercare trend, identificare pattern
e ottenere intuizioni negli eventi di sicurezza di rete.
Questa integrazione di Logstash e Elasticsearch ti abilita a creare un robusto
sistema di log management che migliora la tua abilità di monitorare e
mettere in sicurezza la tua rete. Una volta che i log sono indicizzati in Elastic
search puoi usare le sue potenti capacità di query per rilevare
potenziali minacce di sicurezza. Costruendo query mirate puoi
identificare problemi live come accesso non autenticato
e tentativi brute force. Questa query permette un efficiente
monitoraggio dell'attività di rete rendendo più facile identificare
incidenti di sicurezza. Un modo per rilevare attività sospetta è
cercare traffico da uno specifico indirizzo IP sorgente.
Per esempio usando la query source_ip:
e poi l'indirizzo IP AND action:deny
filtrerà i log dove traffico dall'indirizzo IP
l'indirizzo specifico è stato negato dal firewall.
Questo può aiutarti a identificare una particolare fonte se sta tentando
accesso non autorizzato o provando ripetutamente a violare il firewall.
Un tipico output potrebbe mostrare log indicando che a questo indirizzo IP
è stato negato l'accesso multiple volte a diverse destinazioni
suggerendo potenziale attività dannosa. Questi tipi di log sono
utili per rilevare primi segni di attacco permettendo tempestivo
intervento. Un'altra importante query si concentra sul rilevare insoliti pattern
di accesso per porte specifiche. Per esempio destination_port:80
AND action:allow cerca traffico permesso mirato alla porta 80.
Dato che la porta 80 è comunemente usata per traffico web monitorarla per
attività insolita può rivelare se ci sono pattern di accesso anormali
come connessioni frequenti che potrebbero non corrispondere a regolare comportamento di navigazione
web. I risultati potrebbero mostrare una lista di voci di traffico
permesso ma è la frequenza e il contesto di queste connessioni che
aiuterà a determinare se l'attività è legittima o
indicativa di un tentativo di exploit. Revisionando regolarmente quei pattern
gli amministratori di rete possono individuare le irregolarità e rispondere.
Per rilevare attacchi brute force puoi cercare fallimenti di
login multipli come abbiamo visto su Splunk come source_ip AND action:deny
| stats count by source_ip. Questa query aiuta a identificare ripetuti
tentativi di login negati per uno specifico indirizzo IP un segno comune di
attacco brute force. I risultati potrebbero mostrare che l'indirizzo
IP ha fatto un alto numero di tentativi di login falliti
indicando un attacco automatizzato o una misconfigurazione di sicurezza che richiede
attenzione. Tali query sono particolarmente utili
per individuare attività ad alto rischio e naturalmente
ELK Stack può essere modellato può essere personalizzato
per usare le migliori le migliori query possibili per l'infrastruttura.
Come abbiamo detto Kibana è lo strumento potente per visualizzare i dati memorizzati in
Elasticsearch sull'ELK Stack e ti permette di creare
dashboard interattive per tracciare e analizzare gli eventi.
Usando Kibana i team di sicurezza possono facilmente identificare i trend anomalie
e monitorare metriche di sicurezza chiave in tempo reale.
Per iniziare puoi aprire Kibana e navigare alla sezione dashboard.
Da lì puoi creare una nuova dashboard specificamente per i tuoi bisogni di monitoraggio
eventi di sicurezza. Aggiungendo varie visualizzazioni alla dashboard
ti aiuterà a tracciare importanti eventi firewall e ottenere
diverse intuizioni nell'attività di rete. Una delle prime visualizzazioni
che potresti voler aggiungere è il grafico a barre per top
indirizzi IP negati. Questo grafico ti mostrerà gli indirizzi IP
sorgente a cui è stato per lo più frequentemente
negato l'accesso dal firewall. Per configurare questo aggregherai
dati per il campo source IP e mostrerai il conteggio delle azioni di deny.
Questo ti darà una vista rapida di quali indirizzi IP stanno tentando accesso
ed essendo bloccati più spesso o potenzialmente evidenziando fonti di
attività sospetta. Un'altra visualizzazione utile è il
grafico a torta per ripartizione delle azioni. Questo scomporrà le azioni intraprese
dal firewall come allow contro deny. Il grafico a torta può essere configurato
per aggregare dati per il campo action fornendo una rappresentazione facile da leggere
della distribuzione dei tipi di traffico. Questa visualizzazione è particolarmente
utile per comprendere il comportamento generale della rete dell'
attività del firewall per esempio. Infine puoi creare un grafico a linee
per accesso negato dettagliato. Questa visualizzazione ti permetterà di
tracciare il numero di connessioni negate per giorno
che può aiutarti a individuare trend nel tempo.
Configurare questo grafico a linee con un intervallo di tempo di 24 ore o cinque o
sette giorni ti permetterà di monitorare se ci sono picchi nel traffico negato
che potrebbero indicare tentativi in corso o ricorrenti di violare
il firewall o i sistemi.