Negli articoli precedenti ci siamo avvicinati allo stack ELK e alla configurazione del file di Logstash per il parsing dei log; in questo articolo ci concentreremo su ciò che è più rilevante dal punto di vista analitico: i grafici e le tabelle unite in dashboard. Oggi approfondiremo il sistema di visualizzazione Kibana, analizzeremo come creare grafici e tabelle, e alla fine costruiremo un semplice dashboard basato sui log del firewall Check Point.
Il primo passo per lavorare con Kibana è creare un index pattern, che logicamente è un database di indici unici in base a un determinato principio. Ovviamente, questo è solo un'impostazione per facilitare la ricerca delle informazioni da parte di Kibana su tutti gli indici contemporaneamente. Questa viene definita confrontando una stringa, ad esempio "checkpoint-*" e il nome dell'indice. Ad esempio, "checkpoint-2019.12.05" si adatterà al pattern, mentre semplicemente "checkpoint" no. È importante notare che non è possibile cercare informazioni su diversi pattern di indici contemporaneamente; in articoli futuri vedremo che le richieste API possono essere effettuate o per nome dell'indice o per un singolo pattern di stringa, l'immagine è cliccabile:
Dopo questo controlliamo nel menu Discover che tutti i log siano indicizzati e che il parser sia configurato correttamente. Se si riscontrano delle incongruenze, ad esempio, la necessità di cambiare il tipo di dati da stringa a numero intero, occorre modificare il file di configurazione di Logstash, in modo che i nuovi log vengano registrati correttamente. Per rendere i vecchi log conformi al nuovo formato, è necessaria solo la procedura di reindicizzazione, che sarà trattata più in dettaglio in articoli successivi. Assicuriamoci che tutto sia in ordine, l'immagine è cliccabile:
I log sono al loro posto, quindi possiamo procedere alla costruzione dei dashboard. Sulla base dell'analisi dei dashboard dei prodotti di sicurezza è possibile comprendere lo stato della sicurezza informatica nell'organizzazione, identificare visivamente i punti vulnerabili nella politica attuale e successivamente elaborare modi per affrontarli. Creeremo un piccolo dashboard utilizzando diversi strumenti di visualizzazione. Il dashboard sarà composto da 5 elementi:
- tabella per calcolare il numero totale di log per blade
- tabella per le firme critiche IPS
- grafico a torta per eventi di Threat Prevention
- grafico per i siti più visitati
- grafico per l'uso delle applicazioni più pericolose
Per creare le figure di visualizzazione, è necessario andare nel menu Visualize, e selezionare la figura desiderata che vogliamo costruire! Procediamo per ordine.
Tabella per calcolare il numero totale di log per blade
Per questo selezioniamo la figura Data Table, poi accediamo all'utile per la creazione dei grafici, a sinistra si impostano le configurazioni della figura, a destra come apparirà con le impostazioni correnti. Prima mostrerò come apparirà la tabella completata, poi passeremo alle impostazioni, l'immagine è cliccabile:
Impostazioni più dettagliate della figura, l'immagine è cliccabile:
Esaminiamo le impostazioni.
All'inizio si configura metrica, questo valore sarà utilizzato per aggregare tutti i campi. Le metriche vengono calcolate sulla base dei valori estratti in vari modi dai documenti. I valori di solito vengono estratti dai campi del documento, ma possono anche essere generati utilizzando script. In questo caso impostiamo Aggregation: Count (numero totale di log).
Dopo di che la tabella viene suddivisa in segmenti (campi) per i quali verrà calcolata la metrica. Questa funzione è svolta dalle impostazioni Buckets, che a loro volta sono composte da 2 varianti di configurazione:
- split rows — aggiunta di colonne e successivo divisione della tabella in righe
- split table — divisione in più tabelle in base ai valori di un campo specifico.
In buckets è possibile aggiungere diverse suddivisioni per creare più colonne o tabelle; qui le limitazioni sono più logiche. Nella aggregazione si può scegliere con quale metodo avverrà la divisione in segmenti: ipv4 range, date range, Terms, ecc. La scelta più interessante è proprio Terms e Significant Terms, la divisione in segmenti si basa sui valori di un determinato campo dell'indice; la differenza tra loro sta nel numero di valori restituiti e nella loro visualizzazione. Poiché vogliamo suddividere la tabella in base ai nomi dei blade, scegliamo il campo — product.keyword e impostiamo la dimensione a 25 valori restituiti.
Invece delle righe, in Elasticsearch vengono utilizzati 2 tipi di dati — text e keyword. Se desideri eseguire una ricerca full-text, devi utilizzare il tipo text, molto utile nella scrittura del tuo servizio di ricerca, ad esempio, per cercare la menzione di una parola in un determinato campo (testo). Se desideri solo una corrispondenza esatta, devi utilizzare il tipo keyword. Inoltre, il tipo di dato 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 certo periodo aggregando per valore nel campo product. In Custom Label impostiamo il nome della colonna che verrà visualizzato nella tabella, definiamo il tempo per il quale raccogliamo i log, avviamo la visualizzazione — Kibana invia una richiesta a elasticsearch, attende la risposta e poi visualizza i dati ottenuti. La tabella è pronta!
Diagramma a torta degli eventi di Threat Prevention
È particolarmente interessante sapere qual è la percentuale delle reazioni detect e prevent sugli incidenti di sicurezza informatica nella politica di sicurezza attuale. In questo caso, è utile un diagramma a torta. Selezioniamo in Visualize — Pie chart. Inoltre, nella metrica impostiamo l'aggregazione per il numero di log. Nei buckets impostiamo Terms => action.
Sembra tutto corretto, ma il risultato mostra valori per tutte le blade, è necessario filtrare solo quelle blade che operano nell'ambito di Threat Prevention. Pertanto, è indispensabile configurare un filtro per cercare informazioni solo sulle 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 ulteriori impostazioni, l'immagine è cliccabile:
Tabella sugli eventi IPS
In seguito, è soprattutto importante dal punto di vista della sicurezza informatica visualizzare e controllare gli eventi sulla blade IPS e Emulazione delle Minacce, che non bloccati nella politica attuale, per poter eventualmente passare la firma in prevent, oppure se il traffico è valido — non controllare la firma. Creiamo la tabella nello stesso modo del primo esempio, solo con la differenza che creiamo diverse colonne: protections.keyword, severity.keyword, product.keyword, originsicname.keyword. È essenziale configurare un filtro per cercare informazioni solo sulle blade responsabili degli incidenti di sicurezza informatica — product: («SmartDefense» OR «Threat Emulation»). L'immagine è cliccabile:
Ulteriori impostazioni, l'immagine è cliccabile:
Diagrammi sui siti più visitati
Per questo creiamo una figura — Vertical Bar. Utilizziamo anche count come metrica (asse Y), mentre sull'asse X utilizzeremo i nomi dei siti visitati — “appi_name”. Qui c'è un piccolo trucco, se avviamo le impostazioni nell'attuale variante, tutti i siti verranno segnati sul grafico con lo stesso colore, per rendere i colori diversi utilizziamo un'impostazione aggiuntiva — “split series”, che consente di dividere una colonna già pronta in ulteriori valori, a seconda del campo selezionato, naturalmente! Questa divisione può essere usata come una colonna multicolore basata sui valori in modalità stacked o in modalità normal per creare più colonne a seconda di un valore sull'asse X. In questo caso, qui utilizziamo lo stesso valore che sull'asse X, il che consente di rendere tutte le colonne multicolori, a destra in alto saranno designate con colori. Nel filtro impostiamo — product:«URL Filtering» per visualizzare informazioni solo sui siti visitati, l'immagine è cliccabile:
Impostazioni:
Diagramma sull'uso delle applicazioni più pericolose
Per questo creiamo una figura — Vertical Bar. Utilizziamo anche count come metrica (asse Y), mentre sull'asse X utilizzeremo i nomi delle applicazioni utilizzate — “appi_name”. La cosa più importante è impostare il filtro — product: «Application Control» AND app_risk: (4 OR 5 OR 3 ) AND action:«accept». Filtriamo i log sulla blade Application control, prendendo solo quei siti che sono categorizzati come siti a rischio Critico, Alto, Medio solo nel caso in cui l'accesso a questi siti sia consentito. L'immagine è cliccabile:
Impostazioni, cliccabile:
Dashboard
La visualizzazione e la creazione di dashboard si trovano in un'apposita voce di menu — Dashboard. Qui è tutto semplice, si crea un nuovo dashboard, si aggiunge una visualizzazione, si sistemano i vari elementi e il gioco è fatto!
Creiamo un dashboard per comprendere la situazione di base dello stato di sicurezza informatica nell'organizzazione, chiaro, solo a livello di Check Point, l'immagine è cliccabile:
Sulla base di questi grafici possiamo capire quali firme critiche non vengono bloccate dal firewall, dove navigano gli utenti, quali applicazioni più pericolose stanno utilizzando.
Conclusione
Abbiamo esaminato le possibilità di base della visualizzazione in Kibana e abbiamo creato un dashboard, ma questo è solo un piccolo assaggio. Nel corso, tratteremo in dettaglio la configurazione delle mappe, il lavoro con il sistema Elasticsearch, ci familiarizzeremo con le richieste API, l'automazione e molto altro!
Quindi segui gli aggiornamenti (, , , ), .
Fonte: habr.com
