În articolele anterioare, ne-am familiarizat puțin cu stiva ELK și cu configurarea fișierului Logstash pentru parserul de loguri. În acest articol, vom trece la ceea ce este cel mai important din punctul de vedere al analizei, la ceea ce doriți să vedeți din sistem și pentru care a fost creat totul — graficile și tabelele unite în dashboards. Astăzi ne vom familiariza mai bine cu sistemul de vizualizare Kibana, vom explora cum să creăm grafice, tabele și, în cele din urmă, vom construi un dashboard simplu pe baza logurilor de la firewall-ul Check Point.
Primul pas în lucrul cu Kibana este crearea index pattern, logic, aceasta este o bază a indicilor unificată după un anumit principiu. Desigur, aceasta este exclusiv o configurare pentru ca Kibana să caute mai convenabil informațiile în toate indicii simultan. Aceasta se stabilește prin corespondența unei șiruri, să spunem “checkpoint-*” și numele indexului. De exemplu, „checkpoint-2019.12.05” se potrivește cu modelul, dar simplu „checkpoint” nu se potrivește. Merită menționat în mod separat că, la căutare, nu se poate căuta informația pe diferite modele de index simultan; un pic mai târziu, în articolele următoare, vom vedea că cererile API se fac fie după numele indexului, fie conform unui singur model de este, imaginea este clicabilă:
După aceasta, verificăm în meniul Discover dacă toate logurile sunt indexate și dacă parserul este corect configurat. Dacă se constată vreo discrepanță, de exemplu, schimbarea tipului de date din șir în număr întreg, trebuie să edităm fișierul de configurare Logstash, rezultând că noile loguri vor fi înregistrate corect. Pentru ca logurile vechi să primească forma dorită înainte de modificare, ajută doar procesul de reindexare; în articolele următoare, această operațiune va fi discutată mai detaliat. Să ne asigurăm că totul este în ordine, imaginea este clicabilă:
Logurile s-au aflat la locul lor, așa că putem începe construirea dashboard-urilor. Pe baza analizei dashboard-urilor produselor de securitate, se poate înțelege starea securității informației în organizație, vizualizând locurile vulnerabile în politica actuală și dezvoltând ulterior modalități de remediere. Să construim un mic dashboard, folosind câteva instrumente de vizualizare. Dashboard-ul va consta din 5 componente:
- un tabel pentru numărarea numărului total de loguri pe blade-uri
- un tabel pentru semnăturile critice IPS
- diagramă circulară pentru evenimente Threat Prevention
- diagramă pentru cele mai populare site-uri vizitate
- diagramă pentru utilizarea celor mai periculoase aplicații
Pentru a crea figurile de vizualizare, trebuie să accesați meniul Vizualizați, și să selectați figura dorită pe care vrem să o construim! Să procedăm pas cu pas.
Tabel pentru numărarea totalului logurilor pe blade-uri
Pentru aceasta, alegem figura Tabel de date, intrăm în instrumentul pentru crearea grafica, setările figurii sunt plasate în stânga, iar aspectul acesteia în setările curente este pe dreapta. Mai întâi, voi demonstra cum va arăta tabelul final, după care vom trece prin setări, imaginea este clicabilă:
Setări mai detaliate pentru figură, imaginea este clicabilă:
Să analizăm setările.
În primul rând, se configurează metrica, aceasta este valoarea pe baza căreia vor fi agregate toate câmpurile. Metricile sunt calculate pe baza valorilor extrase prin diferite metode din documente. Valorile sunt de obicei extrase din câmpurile documentului, dar pot fi generate și folosind scripturi. În acest caz, stabilim în Agregare: Număr (numărul total de loguri).
După aceasta, împărțim tabelul în segmente (câmpuri), pe care se va calcula metrica. Această funcție este îndeplinită de configurația Buckets, care la rândul său constă în 2 opțiuni de configurare:
- split rows — adăugarea coloanelor și ulterior împărțirea tabelului în rânduri
- split table — împărțirea în mai multe tabele în funcție de valorile unui câmp specific.
În buckets putem adăuga mai multe diviziuni pentru crearea mai multor coloane sau tabele, limitările sunt mai degrabă logice. În agregare se poate alege metoda prin care se va face divizarea în segmente: ipv4 range, date range, Terms etc. Alegerile cele mai interesante sunt Terms și Termeni semnificativi, divizarea în segmente se efectuează în funcție de valorile dintr-un câmp specific al indexului, diferența dintre ele constă în numărul de valori returnate și afișarea lor. Deoarece vrem să împărțim tabelul în funcție de denumirea blade-urilor, alegem câmpul — product.keyword și stabilim dimensiunea la 25 de valori returnate.
În loc de rânduri, în elasticsearch se folosesc 2 tipuri de date — text și keyword. Dacă doriți să efectuați o căutare full-text, trebuie să utilizați tipul text, ceea ce este foarte convenabil atunci când scrieți propriul serviciu de căutare, de exemplu, căutând menționarea unui cuvânt într-un anumit câmp (text). Dacă doriți doar o potrivire exactă, trebuie să utilizați tipul keyword. De asemenea, tipul de date keyword ar trebui folosit pentru câmpuri care necesită sortare sau agregare, adică, în cazul nostru.
Ca rezultat, Elasticsearch numără logurile pentru o anumită perioadă de timp, agregându-le după valoarea din câmpul product. În Custom Label, specificăm numele coloanei care va fi afișată în tabel, stabilim timpul pentru care colectăm logurile, lansăm generarea — Kibana trimite o cerere către Elasticsearch, așteaptă un răspuns și apoi vizualizează datele obținute. Tabelul este gata!
Diagramă circulară pentru evenimentele de prevenire a amenințărilor
O informație deosebit de interesantă este procentajul reacțiilor detect și prevent privind incidentele de securitate cibernetică în politica de securitate actuală. Pentru un astfel de caz, diagramă circulară este potrivită. Alegeți în Visualize — Pie chart. De asemenea, în metrică stabilim agregarea după numărul de loguri. În buckets punem Terms => action.
Se pare că totul este corect, dar valorile arată pentru toate blade-urile, trebuie să filtrăm doar blade-urile care funcționează în cadrul prevenției amenințărilor. Așadar, este esențial să configurăm filtrul pentru a căuta informații doar pe blade-urile care răspund de incidentele de securitate cibernetică — product: ("Anti-Bot" OR "New Anti-Virus" OR "DDoS Protector" OR "SmartDefense" OR "Threat Emulation"). Imaginea este clicabilă:
Și setările mai detaliate, imaginea este clicabilă:
Tabelul pentru evenimentele IPS
Apoi, foarte important din perspectiva securității cibernetice este vizualizarea și verificarea evenimentelor pe blade IPS și Emularea Amenințărilor, care nu sunt blocate de politica actuală, pentru a putea ulterior fie să trecem semnătura în prevent, fie, dacă traficul este valid — să nu verificăm semnătura. Tabelul se creează la fel ca în primul exemplu, cu diferența că creăm mai multe coloane: protections.keyword, severity.keyword, product.keyword, originsicname.keyword. Este esențial să configurăm filtrul pentru a căuta informații doar pe blade-urile care răspund de incidentele de securitate cibernetică — product: ("SmartDefense" OR "Threat Emulation"). Imaginea este clicabilă:
Setări mai detaliate, imaginea este clicabilă:
Grafice despre cele mai populare site-uri vizitate
Pentru aceasta, creăm o figură — Bară verticală. De asemenea, folosim metrica count (axa Y), iar pe axa X, ca valori, vom folosi denumirile site-urilor vizitate — “appi_name”. Aici există o mică inginerie: dacă rulăm setările în varianta actuală, toate site-urile vor fi marcate pe grafic cu o singură culoare. Pentru a le face colorate, folosim o setare suplimentară — “split series”, care permite împărțirea coloanei deja existente în mai multe valori, în funcție de câmpul selectat, desigur! Aceasta împărțire poate fi utilizată fie ca o coloană colorată, în modul stacked, fie în modul normal, pentru a crea mai multe coloane pe baza unei valori de pe axa X. În acest caz, folosim aceeași valoare ca pe axa X, ceea ce permite colorarea tuturor coloanelor, iar în partea dreaptă sus, acestea vor fi marcate cu culori. În filtrul stabilim — product:«URL Filtering» pentru a vedea informații doar despre site-urile vizitate, imaginea este clicabilă:
Setări:
Grafic despre utilizarea celor mai periculoase aplicații
Pentru aceasta, creăm o figură — Bară verticală. De asemenea, folosim metrica count (axa Y), iar pe axa X, ca valori, vom folosi denumirile aplicațiilor utilizate — “appi_name”. Cel mai important este să stabilim filtrul — product: «Application Control» AND app_risk: (4 OR 5 OR 3) AND action:«accept». Filtrăm jurnalele pe blade-ul Application control, luând doar acele site-uri care sunt catalogate ca având risc Critic, Ridicat, Mediu, și doar în cazul în care accesul la aceste site-uri este permis. Imaginea este clicabilă:
Setări, clicabil:
Tabloul de bord
Vizualizarea și crearea tablourilor de bord se află într-un punct de meniu separat — Tabloul de bord. Aici totul este simplu, se creează un nou tablou de bord, în care se adaugă vizualizări, se aranjează și totul!
Creăm un tablou de bord care va oferi o înțelegere a stării de bază a securității informațiilor în organizație, bineînțeles, doar la nivelul Check Point, imaginea este clicabilă:
Pe baza acestor grafice, putem înțelege ce semnături critice nu sunt blocate de firewall, unde navighează utilizatorii, care sunt cele mai periculoase aplicații pe care le utilizează.
Concluzie
Am analizat posibilitățile de vizualizare de bază în Kibana și am construit un tablou de bord, dar aceasta este doar o mică parte. În continuare, în curs, vom explora setările hartelor, lucrul cu sistemul Elasticsearch, ne vom familiariza cu cererile API, automatizarea și multe altele!
Așadar, urmăriți actualizările (, , , ), .
Sursa: habr.com
