In eerdere artikelen hebben we ons een beetje vertrouwd gemaakt met de ELK-stack en het configuratiebestand van Logstash voor logparsing. In dit artikel zullen we ons richten op het belangrijkste aspect vanuit analytisch oogpunt: datgene wat je van het systeem wilt zien en waarvoor alles is opgezet — dat zijn de grafieken en tabellen samengebracht in dashboards. Vandaag zullen we nader kennismaken met het visualisatiesysteem Kibana, bekijken hoe we grafieken en tabellen kunnen maken, en uiteindelijk een eenvoudige dashboard op basis van de logs van de Check Point firewall opbouwen.
De eerste stap in het werken met Kibana is het creëren van een indexpatroon, logisch gezien is dit een verzameling indices die op een bepaalde manier samenkomen. Uiteraard is dit uitsluitend een instelling zodat Kibana informatie gemakkelijker kan zoeken over alle indices tegelijkertijd. Dit wordt ingesteld door het matchen van een string, bijvoorbeeld “checkpoint-*” met de naam van de index. Bijvoorbeeld, “checkpoint-2019.12.05” zou passen bij het patroon, maar gewoon “checkpoint” zou dat niet doen. Het is ook vermeldenswaardig dat je in de zoekfunctie niet tegelijkertijd informatie kunt zoeken over verschillende indexpatronen. Later in de volgende artikelen zullen we zien dat API-aanroepen worden gedaan op basis van de naam van de index of op basis van één regel patroon, klikbare afbeelding:
Daarna controleren we in het menu Ontdekken of alle logs worden geïndexeerd en of de juiste parser is ingesteld. Als er enige inconsistenties worden geconstateerd, zoals het wijzigen van het gegevenstype van string naar integer, moet het configuratiebestand van Logstash worden aangepast, waardoor nieuwe logs correct worden vastgelegd. Om oude logs vóór de wijziging in de gewenste vorm te krijgen, helpt alleen het proces van re-indexeren. In latere artikelen zal deze operatie gedetailleerder worden besproken. We zorgen ervoor dat alles in orde is, klikbare afbeelding:
De logs zijn op hun plek, dus we kunnen beginnen met het opbouwen van dashboards. Op basis van de analytische dashboards van security producten kunnen we de staat van de informatiebeveiliging in de organisatie begrijpen, kwetsbare plekken in het huidige beleid visueel identifiëren en in de toekomst manieren ontwikkelen om deze aan te pakken. We bouwen een klein dashboard op met behulp van verschillende visualisatiemiddelen. Het dashboard zal uit 5 componenten bestaan:
- een tabel voor het tellen van het totale aantal logs per blade
- een tabel voor kritieke IPS-handtekeningen
- een cirkeldiagram voor Threat Prevention-gebeurtenissen
- diagram van de meest populaire bezochte websites
- diagram van het gebruik van de meest gevaarlijke toepassingen
Om visualisatiefiguren te maken, moet je naar het menu gaan Visualiseren, en kies de gewenste figuur die je wilt bouwen! Laten we stap voor stap doorgaan.
Tabel voor het tellen van het totale aantal logs per blade
Kies hiervoor de figuur Data Tabel, dan gaan we naar de tool voor het maken van grafieken, aan de linkerkant worden de figuurinstellingen ingevuld, aan de rechterkant hoe deze eruit zal zien met de huidige instellingen. Eerst laat ik zien hoe de afgewerkte tabel eruit zal zien, daarna lopen we de instellingen door, de afbeelding is klikbaar:
Meer gedetailleerde figuurinstellingen, de afbeelding is klikbaar:
Laten we de instellingen doornemen.
Eerst wordt ingesteld de metriek, dit is de waarde waarop alle velden worden geaggregeerd. Metrics worden berekend op basis van waarden die op een bepaalde manier uit documenten zijn gehaald. Waarden worden meestal gehaald uit velden van het document, maar kunnen ook worden gegenereerd met behulp van scripts. In dit geval stellen we in Aggregatie: Aantal (totaal aantal logs).
Daarna splitsen we de tabel in segmenten (velden) waar de metriek over wordt berekend. Deze functie wordt uitgevoerd door de instelling Buckets, die op haar beurt uit 2 opties voor instellingen bestaat:
- split rows — kolommen toevoegen en de tabel vervolgens splitsen in rijen
- split table — splitsen in meerdere tabellen op basis van de waarden van een bepaald veld.
In buckets je kunt meerdere splitsingen toevoegen om meerdere kolommen of tabellen te maken, de beperkingen liggen hier meer in de logica. Bij aggregatie kan je kiezen op welke manier de splitsing in segmenten zal plaatsvinden: ipv4 range, date range, Terms, etc. De meest interessante keuze is Terms en Significant Terms, splitsing in segmenten gebeurt op basis van de waarden van een bepaald indexveld, het verschil ligt in het aantal teruggegeven waarden en hun weergave. Aangezien we de tabel willen splitsen op productnamen, kiezen we het veld — product.keyword en stellen we de grootte in op 25 teruggegeven waarden.
In plaats van rijen wordt in elasticsearch gebruik gemaakt van 2 datatypes — text en keyword. Als u een full-text zoekopdracht wilt uitvoeren, moet u het type text gebruiken, wat zeer handig is bij het schrijven van uw eigen zoekservice, bijvoorbeeld wanneer u een vermelding van een woord in een specifiek veld (tekst) zoekt. Als u alleen een exacte overeenkomst wilt, moet u het type keyword gebruiken. Het datatypes keyword moet ook worden gebruikt voor velden die sortering of aggregatie vereisen, dus in ons geval.
Als resultaat telt Elasticsearch het aantal logs over een bepaalde tijd met aggregatie op basis van de waarde in het veld product. In de Custom Label stellen we de naam van de kolom in die in de tabel wordt weergegeven, we stellen de tijd in waarvoor we de logs verzamelen, we starten de visualisatie - Kibana verzendt een verzoek naar Elasticsearch, wacht op een antwoord en visualiseert vervolgens de ontvangen gegevens. De tabel is klaar!
Cirkeldiagram van Threat Prevention-gebeurtenissen
Er is bepaalde belangstelling voor de informatie, in welk percentage reacties dit überhaupt is detecteren en voorkomen van beveiligingsincidenten in het huidige beveiligingsbeleid. Voor dit geval is een cirkeldiagram goed geschikt. We kiezen in Visualize - Cirkeldiagram. Ook in de metric stellen we de aggregatie in op het aantal logs. In buckets stellen we Terms => action in.
Het lijkt allemaal correct, maar het resultaat toont waarden van alle blades, dus we moeten alleen filteren op de blades die binnen Threat Prevention werken. Daarom configureren we absoluut de filter om informatie alleen te zoeken via de blades die verantwoordelijk zijn voor beveiligingsincidenten - product: ("Anti-Bot" OF "New Anti-Virus" OF "DDoS Protector" OF "SmartDefense" OF "Threat Emulation"). De afbeelding is klikbaar:
En meer gedetailleerde instellingen, de afbeelding is klikbaar:
Tabel van IPS-gebeurtenissen
Vervolgens is het erg belangrijk vanuit het oogpunt van IB om de gebeurtenissen per blade te bekijken en te controleren IPS en Threat Emulation, die niet worden geblokkeerd door het huidige beleid, zodat we later ofwel de handtekening naar prevent kunnen overbrengen, of als het verkeer geldig is - de handtekening niet controleren. We creëren de tabel ook zoals in het eerste voorbeeld, met als enige verschil dat we meerdere kolommen aanmaken: protections.keyword, severity.keyword, product.keyword, originsicname.keyword. We configureren absoluut een filter om informatie alleen te zoeken via de blades die verantwoordelijk zijn voor beveiligingsincidenten - product: ("SmartDefense" OF "Threat Emulation"). De afbeelding is klikbaar:
Meer gedetailleerde instellingen, de afbeelding is klikbaar:
Diagrammen van de meest populaire bezochte websites
Hiervoor creëren we een figuur — Verticale Staaf. We gebruiken ook de meting count (Y-as), en op de X-as gebruiken we de namen van de bezochte websites — “appi_name”. Hier is een kleine truc: als je de instellingen in de huidige variant uitvoert, worden alle websites getekend in één kleur op de grafiek. Om ze verschillende kleuren te geven, gebruiken we een extra instelling — “split series”, die het mogelijk maakt om de al gemaakte kolom in meerdere waarden te splitsen, afhankelijk van het geselecteerde veld natuurlijk! Deze splitsing kan worden gebruikt als één gekleurde kolom in de stacked modus, of in de normale modus om meerdere kolommen voor bepaalde waarden op de X-as te creëren. In dit geval gebruiken we dezelfde waarde als op de X-as, wat het mogelijk maakt om alle kolommen in verschillende kleuren weer te geven, rechtsboven worden ze aangeduid met kleuren. In de filter geven we in — product: «URL Filtering» om alleen informatie over de bezochte websites te zien, de afbeelding is klikbaar:
Instellingen:
Diagram over het gebruik van de meest gevaarlijke applicaties
Hiervoor creëren we een figuur — Verticale Staaf. We gebruiken ook de meting count (Y-as), en op de X-as gebruiken we de namen van de gebruikte applicaties — “appi_name”. Het belangrijkste is het instellen van de filter — product: «Application Control» EN app_risk: (4 OF 5 OF 3) EN action: «accept». We filteren de logs op de blade Application Control, nemen alleen die websites die zijn geclassificeerd als websites met het risico Kritisch, Hoog, Medium, en alleen als de toegang tot deze websites is toegestaan. De afbeelding is klikbaar:
Instellingen, klikbaar:
Dashboard
Zien en creëren van dashboards bevindt zich in een apart menu-item — Dashboard. Hier is het eenvoudig: er wordt een nieuw dashboard aangemaakt, visualisatie wordt toegevoegd, en alles wordt op zijn plaats gezet!
We creëren een dashboard waarmee de basisstatus van de informatiebeveiliging in de organisatie kan worden begrepen, duidelijk alleen op het niveau van Check Point, de afbeelding is klikbaar:
Op basis van deze grafieken kunnen we begrijpen welke kritieke handtekeningen niet worden geblokkeerd door de firewall, waar gebruikers naartoe gaan, en welke meest gevaarlijke applicaties ze gebruiken.
Conclusie
We hebben de mogelijkheden van basisvisualisatie in Kibana bekeken en een dashboard gemaakt, maar dat is nog maar een klein gedeelte. In de volgende lessen zullen we de configuratie van kaarten, het werken met het Elasticsearch-systeem, het leren kennen van API-aanroepen, automatisering en nog veel meer bespreken!
Dus houd de updates in de gaten (, , , ), .
Bron: habr.com
