Negli articoli precedenti abbiamo esaminato brevemente lo stack ELK e la configurazione del file di Logstash per il parser dei log; in questo articolo ci concentreremo sulla cosa più importante dal punto di vista analitico, ovvero ciò che si desidera vedere dal sistema e per cui è stato creato: grafici e tabelle uniti in dashboard. Oggi daremo un'occhiata più da vicino al sistema di visualizzazione Kibana, esamineremo come creare grafici, tabelle e alla fine costruiremo un semplice dashboard basato sui log del firewall Check Point.
Il primo passo per lavorare con Kibana è la creazione di un pattern dell'indice, che logicamente è un database di indici uniti secondo un principio specifico. Naturalmente, questa è solo una configurazione per consentire a Kibana di cercare le informazioni in tutti gli indici contemporaneamente in modo più conveniente. Si imposta confrontando una stringa, ad esempio “checkpoint-*”, con il nome dell'indice. Ad esempio, «checkpoint-2019.12.05» si adatta al pattern, mentre solo «checkpoint» no. È importante notare che non è possibile cercare informazioni su diversi pattern di indici contemporaneamente; più avanti, nei prossimi articoli, vedremo che le richieste API vengono effettuate o per nome dell'indice o per un singolo pattern di stringa, l'immagine è cliccabile:
Dopo di che verifichiamo nel menu Discover che tutti i log siano indicizzati e che il parser sia configurato correttamente. Se ci sono delle discrepanze, ad esempio, se è necessario cambiare il tipo di dati da stringa a intero, è necessario modificare il file di configurazione di Logstash; in questo modo, i nuovi log verranno registrati correttamente. Per fare in modo che i vecchi log, prima della modifica, assumano il formato desiderato, l'unico modo possibile è il processo di reindicizzazione; nei prossimi articoli esploreremo questa operazione in dettaglio. Assicuriamoci che sia tutto a posto, l'immagine è cliccabile:
I log sono al loro posto, il che significa che possiamo iniziare a costruire dashboard. Sulla base dell'analisi delle dashboard di prodotti di sicurezza, è possibile comprendere lo stato della sicurezza informatica nell'organizzazione, vedere chiaramente le aree vulnerabili nella politica attuale e sviluppare modi per affrontarle in futuro. Costruiamo un piccolo dashboard utilizzando diversi strumenti di visualizzazione. Il dashboard sarà composto da 5 componenti:
- una tabella per il conteggio del numero totale di log per blade
- una tabella per le firme critiche IPS
- grafico a torta sugli eventi di Threat Prevention
- grafico sui siti web più popolari visitati
- grafico sull'utilizzo delle applicazioni più pericolose
Per creare forme di visualizzazione, è necessario andare nel menu Visualizza, e scegliere la forma desiderata che vogliamo costruire! Procediamo con ordine.
Tabella per calcolare il numero totale di log per i blade
Per questo, scegliamo la forma Tabella Dati, ci addentriamo nello strumento per creare grafici, a sinistra si impostano le impostazioni della forma, a destra come apparirà con le attuali impostazioni. Prima mostrerò come apparirà la tabella finale, dopo di che passeremo alle impostazioni, l'immagine è cliccabile:
Impostazioni più dettagliate della forma, l'immagine è cliccabile:
Analizziamo le impostazioni.
Inizialmente si imposta metrica, questo è il valore su cui verranno aggregati tutti i campi. Le metriche vengono calcolate sulla base dei valori estratti in vari modi dai documenti. I valori vengono solitamente estratti da campi del documento, ma possono anche essere generati utilizzando script. In questo caso impostiamo in Aggregazione: Conteggio (numero totale di log).
Dopo di ciò, suddividiamo la tabella in segmenti (campi) su cui verrà calcolata la metrica. Questa funzione è svolta dall'impostazione Buckets, che a sua volta consiste in 2 opzioni di configurazione:
- split rows — aggiunta di colonne e successiva suddivisione della tabella in righe
- split table — suddivisione in più tabelle in base ai valori di un determinato campo.
In buckets è possibile aggiungere più suddivisioni per creare più colonne o tabelle, qui i limiti sono più logici. Nella aggregazione si può scegliere in quale modo avverrà la suddivisione in segmenti: ipv4 range, date range, Terms, ecc. La scelta più interessante è proprio Terms e Significant Terms, la suddivisione in segmenti avviene in base ai valori di un determinato campo dell'indice, la differenza tra di essi consiste nel numero di valori restituiti e nella loro visualizzazione. Poiché vogliamo suddividere la tabella in base ai nomi dei blade, selezioniamo il campo - product.keyword e stabiliamo la dimensione in 25 valori restituiti.
Invece delle righe in elasticsearch si utilizzano 2 tipi di dati - text e keyword. Se desideri eseguire una ricerca a testo completo, devi utilizzare il tipo text, molto utile quando si scrive il proprio servizio di ricerca, ad esempio, cercando un riferimento a una parola nel significato specifico del campo (testo). Se desideri solo una corrispondenza esatta, devi utilizzare il tipo keyword. Inoltre, il tipo di dati keyword deve essere utilizzato per i campi che richiedono ordinamento o aggregazione, cioè, nel nostro caso.
Di conseguenza, Elasticsearch conta il numero di log in un determinato intervallo di tempo aggregandoli in base al valore del campo product. Nel Custom Label impostiamo il nome della colonna che verrà visualizzato nella tabella, impostiamo il tempo per il quale raccogliamo i log, avviamo il rendering — Kibana invia una richiesta a Elasticsearch, attende la risposta e successivamente visualizza i dati ottenuti. La tabella è pronta!
Diagramma a torta sugli eventi di Threat Prevention
Un certo interesse è suscitato dall'informazione su quante reazioni ci siano in percentuale detect e prevent sugli incidenti di sicurezza informatica nella corrente politica di sicurezza. Per questo caso è molto adatto un diagramma a torta. Selezioniamo in Visualize — Pie chart. Inoltre, nella metrica impostiamo l'aggregazione in base al numero di log. In buckets impostiamo Terms => action.
A quanto pare, è tutto corretto, ma il risultato mostra valori per tutti i blade, è necessario filtrare solo quelli che operano nell'ambito di Threat Prevention. Quindi è fondamentale configurare il filtro in modo da cercare informazioni solo sui blade responsabili degli incidenti di sicurezza informatica — product: («Anti-Bot» OR «New Anti-Virus» OR «DDoS Protector» OR «SmartDefense» OR «Threat Emulation»). L'immagine è cliccabile:
E impostazioni più dettagliate, l'immagine è cliccabile:
Tabella sugli eventi IPS
Successivamente, è molto importante dal punto di vista della sicurezza informatica visualizzare e controllare gli eventi per il blade IPS e Emulazione delle minacce, che non vengono bloccati dalla politica attuale, affinché in seguito si possa o spostare la firma in prevent, o se il traffico è valido — non controllare la firma. Creiamo la tabella esattamente come per il primo esempio, solo con la differenza che creiamo più colonne: protections.keyword, severity.keyword, product.keyword, originsicname.keyword. È fondamentale configurare il filtro per cercare informazioni solo sui blade responsabili degli incidenti di sicurezza informatica — product: ( «SmartDefense» OR «Threat Emulation»). L'immagine è cliccabile:
Impostazioni più dettagliate, l'immagine è cliccabile:
Diagrammi sui siti web più popolari visitati
Per questo creiamo una figura — Barra verticale. Utilizziamo anche la metrica count (asse Y), mentre sull'asse X utilizzeremo come valori il nome dei siti visitati — “appi_name”. Qui c'è un piccolo trucco, se avviamo le impostazioni nella versione attuale, tutti i siti saranno contrassegnati sul grafico con un colore unico. Per farli diventare multicolori, utilizziamo un'impostazione aggiuntiva — “split series”, che consente di dividere la colonna già pronta in ulteriori valori, a seconda del campo selezionato, ovviamente! Questa divisione può essere utilizzata come un'unica colonna multicolore in modalità stacked, oppure in modalità normale per creare più colonne in base a valori specifici dell'asse X. In questo caso utilizziamo lo stesso valore dell'asse X, il che ci permette di rendere tutte le colonne multicolori, che saranno indicate a destra in alto con colori diversi. Nel filtro impostiamo — product:«URL Filtering» per vedere informazioni solo sui siti visitati, l'immagine è cliccabile:
Impostazioni:
Grafico sull'utilizzo delle applicazioni più pericolose
Per questo creiamo una figura — Vertical Bar. Utilizziamo anche la metrica count (asse Y), mentre sull'asse X utilizzeremo come valori il nome delle applicazioni utilizzate — “appi_name”. È fondamentale impostare il filtro — product: «Application Control» AND app_risk: (4 OR 5 OR 3 ) AND action:«accept». Filtriamo i log per il blade Application control, prendiamo solo i siti categorizzati come siti con rischio Critico, Alto, Medio e solo nel caso in cui l'accesso a questi siti sia consentito. L'immagine è cliccabile:
Impostazioni, cliccabili:
Dashboard
La visualizzazione e creazione dei dashboard si trovano in un punto menu separato — Dashboard. Qui è tutto semplice, si crea un nuovo dashboard, si aggiunge la visualizzazione, si dispone il tutto e via!
Creiamo un dashboard che permetta di comprendere la situazione di base della sicurezza delle informazioni nell'organizzazione, ovviamente solo a livello di Check Point, l'immagine è cliccabile:
Sulla base di questi grafici possiamo capire quali firme critiche non vengono bloccate sul firewall, dove si recano gli utenti, quali sono le applicazioni più pericolose che utilizzano.
Conclusione
Abbiamo esaminato le possibilità di visualizzazione di base in Kibana e abbiamo creato un dashboard, ma questo è solo una piccola parte. Proseguendo nel corso, approfondiremo la configurazione delle mappe, l'interazione con il sistema Elasticsearch, ci familiarizzeremo con le richieste API, l'automazione e molto altro!
Quindi, seguite gli aggiornamenti (, , , ), .
Fonte: habr.com
