Buongiorno, nei precedenti articoli abbiamo esaminato il funzionamento della ELK Stack. Ora discuteremo delle possibilità che un esperto di sicurezza informatica può realizzare utilizzando questi sistemi. Quali log è possibile e necessario registrare in Elasticsearch? Esamineremo quali statistiche è possibile ottenere impostando i dashboard e se ci sono vantaggi in questo. Come è possibile implementare l'automazione dei processi di sicurezza informatica utilizzando la ELK Stack. Compilaremo l'architettura del funzionamento del sistema. In totale, l'implementazione di tutte le funzionalità è un compito molto grande e complicato, quindi la soluzione è stata denominata separatamente — TS Total Sight.
Attualmente stanno guadagnando popolarità le soluzioni che consolidano e analizzano gli incidenti di sicurezza informatica in un unico luogo logico, da cui il professionista ottiene statistiche e un piano di azione per migliorare la sicurezza informatica nell'organizzazione. Questo è l'obiettivo che ci siamo posti nell'utilizzo della ELK Stack, e in seguito abbiamo suddiviso le funzionalità principali in 4 sezioni:
- Statistiche e visualizzazione;
- Rilevamento degli incidenti di sicurezza informatica;
- Priorità agli incidenti;
- Automazione dei processi di sicurezza informatica.
Dopo esamineremo ciascuno di essi in dettaglio.
Rilevamento degli incidenti di sicurezza informatica
Il compito principale nell'uso di Elasticsearch in questo caso è la raccolta esclusivamente degli incidenti di sicurezza informatica. Gli incidenti di sicurezza informatica possono essere raccolti da qualsiasi strumento di protezione, purché supportino almeno alcune modalità di invio dei log, la modalità standard è syslog o il salvataggio tramite SCP in un file.
Possono essere forniti esempi standard di strumenti di protezione e non solo, da cui è necessario impostare l'invio dei log:
- Qualsiasi strumento NGFW (Check Point, Fortinet);
- Qualsiasi scanner di vulnerabilità (PT Scanner, OpenVas);
- Web Application Firewall (PT AF);
- Analizzatori netflow (Flowmon, Cisco StealthWatch);
- Server AD.
Dopo aver configurato l'invio dei log e i file di configurazione in Logstash, è possibile correlare e confrontare gli incidenti provenienti da diversi strumenti di sicurezza. È utile utilizzare indici in cui memorizzare tutti gli incidenti relativi a un dispositivo specifico. In altre parole, un indice contiene tutti gli incidenti di un dispositivo. Tale distribuzione può essere attuata in 2 modi.
Prima opzione questo è per configurare Logstash. Per questo è necessario duplicare i log su determinati campi in una singola unità con un altro tipo. E poi usarlo in seguito. Nell'esempio vengono clonati i log del blade IPS del firewall Check Point.
filter {
if [product] == "SmartDefense" {
clone {
clones => ["CloneSmartDefense"]
add_field => {"system" => "checkpoint"}
}
}
}
Per salvare eventi in un indice separato a seconda dei campi dei log, ad esempio come l'indirizzo IP di destinazione della firma dell'attacco. Si può utilizzare una costruzione simile:
output {
if [type] == "CloneSmartDefense"{
{
elasticsearch {
hosts => [",:9200"]
index => "smartdefense-%{dst}"
user => "admin"
password => "password"
}
}
}
In questo modo è possibile salvare nell'indice tutti gli incidenti, ad esempio, per indirizzo IP o nome di dominio della macchina. In questo caso salviamo nell'indice «smartdefense-%{dst}», per indirizzo IP del valore della firma.
Tuttavia, diversi prodotti avranno campi di log diversi, il che porterà a confusione e a un uso eccessivo della memoria. Qui sarà necessario sostituire con attenzione nei parametri di configurazione di Logstash i campi con quelli predeterminati, che saranno uguali per tutti i tipi di incidenti, il che è anch'esso un compito complesso.
La seconda opzione di implementazione è scrivere uno script o un processo che, in tempo reale, interagisca con il database Elasticsearch, estraendo gli incidenti necessari e salvandoli in un nuovo indice; questo è un compito impegnativo, ma consente di lavorare con i log come si desidera e di correlare direttamente con gli incidenti di altri strumenti di sicurezza. Questa opzione permette di gestire i log in modo altamente utile per il tuo caso specifico con la massima flessibilità, ma qui si pone il problema di trovare uno specialista in grado di realizzarlo.
E, naturalmente, la domanda principale, è cosa si può davvero correlare e scoprire?
Qui potrebbero esserci diversi scenari, e dipende dai mezzi di sicurezza utilizzati nella tua infrastruttura; ecco un paio di esempi:
- L'opzione più ovvia e, a mio avviso, più interessante per coloro che hanno una soluzione NGFW e uno scanner di vulnerabilità è il confronto dei log tra IPS e i risultati della scansione delle vulnerabilità. Se un attacco è stato rilevato (non bloccato) dal sistema IPS, e questa vulnerabilità è attiva sulla macchina finale in base ai risultati della scansione, è necessario dare l'allerta, poiché esiste una grande probabilità che la vulnerabilità sia stata sfruttata.
- Molti tentativi di login da una singola macchina in posti diversi possono simboleggiare un'attività malevola.
- Download da parte dell'utente di file infetti a causa della visita a un gran numero di siti potenzialmente pericolosi.
Statistiche e visualizzazione
Il motivo più ovvio e comprensibile per cui è necessario ELK Stack è l'archiviazione e la visualizzazione dei log, è stato mostrato come raccogliere log da diversi dispositivi utilizzando Logstash. Dopo che i log arrivano in Elasticsearch, è possibile configurare i dashboard, di cui si è già parlato , con le informazioni e le statistiche di cui hai bisogno tramite visualizzazione.
Esempi:
- Dashboard sugli eventi di Threat Prevention con gli eventi più critici. Qui puoi riflettere quali firme IPS sono state rilevate e da dove provengono geograficamente.
- Dashboard sull'utilizzo delle applicazioni più critiche, da cui potrebbero trapelare informazioni.
- Risultati della scansione da qualsiasi scanner di sicurezza.
- Log di Active Directory per gli utenti.
- Dashboard sulle connessioni VPN.
In questo caso, se configuri i dashboard per aggiornarsi ogni pochi secondi, puoi ottenere un sistema piuttosto comodo per il monitoraggio degli eventi in tempo reale, che può poi essere utilizzato per la risposta più rapida agli incidenti di sicurezza informatica, se imposti i dashboard su uno schermo separato.
Prioritizzazione degli incidenti
In un contesto di grandi infrastrutture, il numero di incidenti può essere elevato e gli specialisti non riusciranno a gestire tempestivamente tutti gli incidenti. In questo caso, è necessario prima di tutto identificare solo quegli incidenti che presentano una minaccia rilevante. Pertanto, il sistema deve dare priorità agli incidenti in base al loro livello di pericolo rispetto alla vostra infrastruttura. È consigliabile configurare una notifica via email o Telegram per questi eventi. La priorizzazione può essere realizzata con gli strumenti standard di Kibana, configurando la visualizzazione. Tuttavia, per quanto riguarda le notifiche, è più complesso, poiché per impostazione predefinita questa funzionalità non è inclusa nella versione base di Elasticsearch, ma solo in quella a pagamento. Dunque, si può decidere di acquistare la versione a pagamento, oppure sviluppare un processo che notifichi gli specialisti in tempo reale via email o Telegram.
Automazione dei processi di sicurezza informatica
Una delle parti più interessanti è l'automazione delle azioni sugli incidenti di sicurezza informatica. In precedenza, abbiamo implementato questa funzionalità per Splunk; puoi leggere in modo più dettagliato in questo . L'idea principale è che la politica IPS non venga mai verificata o ottimizzata, sebbene in alcuni casi sia una parte fondamentale dei processi di sicurezza informatica. Ad esempio, un anno dopo l'implementazione di un NGFW e l'assenza di interventi per ottimizzare l'IPS, accumulerai un numero elevato di firme con l'azione Detect, che non verranno bloccate, riducendo drasticamente lo stato della sicurezza informatica nell'organizzazione. Di seguito alcuni esempi di ciò che si può automatizzare:
- Cambio dell'azione della firma IPS da Detect a Prevent. Se per firme critiche non funziona Prevent, si tratta di un problema serio e di una falla nel sistema di protezione. Cambiamo l'azione nella politica per queste firme. Questa funzionalità può essere implementata se il dispositivo NGFW dispone della funzionalità REST API. Ciò è possibile solo possedendo abilità di programmazione, bisogna estrarre le informazioni necessarie da Elasticsearch ed eseguire richieste API sul server di gestione del NGFW.
- Se da un indirizzo IP nel traffico di rete vengono rilevate o bloccate molte firme, ha senso bloccare per un certo periodo l'indirizzo IP nella politica del Firewall. L'implementazione prevede anche l'uso della REST API.
- Avviare la scansione dell'host con uno scanner di vulnerabilità se su questo host ci sono molte firme da IPS o altri strumenti di sicurezza. Se si tratta di OpenVas, è possibile creare uno script che si connetta tramite ssh allo scanner di sicurezza e avvii la scansione.
TS Total Sight
In sintesi, l'implementazione di tutte le funzionalità rappresenta un compito molto grande e complesso. Senza competenze di programmazione, è possibile configurare funzionalità minime, che potrebbero essere sufficienti per l'uso in produzione. Tuttavia, se siete interessati a tutte le funzionalità, potete prestare attenzione a TS Total Sight. Potete approfondire ulteriormente sul nostro . Di conseguenza, l'intero schema di lavoro e l'architettura appariranno in questo modo:
Conclusione
Abbiamo esaminato ciò che è possibile realizzare utilizzando l'ELK Stack. Negli articoli successivi esamineremo più dettagliatamente le funzionalità di TS Total Sight!
Quindi, seguite gli aggiornamenti (, , , ), .
Fonte: habr.com
