3. Elastic stack: analys av säkerhetsloggar. Dashboardar

I tidigare artiklar har vi bekantat oss lite med ELK-stacken och konfigurationen av Logstash för loggparsern. I denna artikel går vi vidare till det mest viktiga ur analytisk synpunkt, det som ni vill se från systemet och varför allt skapades - det är grafer och tabeller som förenas i dashboardar. I dag ska vi titta närmare på visualiseringssystemet Kibana, gå igenom hur man skapar grafer och tabeller, och i slutändan bygga ett enkelt dashboard baserat på loggar från Check Point-brandväggen.

Det första steget i arbetet med Kibana är att skapa indexmönster, vilket logiskt sett är en bas av index som enas enligt en viss princip. Självklart är detta helt enkelt en inställning för att Kibana ska kunna söka information mer bekvämt över alla index samtidigt. Det anges genom att matcha en sträng, till exempel “checkpoint-*”, och namnet på indexet. Till exempel passar «checkpoint-2019.12.05» in i mönstret, medan bara «checkpoint» inte gör det. Det bör också nämnas att det inte går att söka information enligt flera indexmönster samtidigt. Lite senare i kommande artiklar kommer vi att se att API-förfrågningar görs antingen enligt namnet på indexet eller enligt ett enda mönster, bilden är klickbar:

Efter detta kontrollerar vi i menyn Discover om alla loggar indexeras, och om rätt parser är inställd. Om det finns några avvikelser, till exempel att byta datatyp från sträng till heltal, måste du redigera konfigurationsfilen för Logstash. Som resultat kommer nya loggar att registreras korrekt. För att gamla loggar ska anta rätt form efter ändringen, hjälper bara reindexeringsprocessen. I kommande artiklar kommer denna operation att behandlas mer detaljerat. Låt oss försäkra oss om att allt är i ordning, bilden är klickbar:

Loggarna är på plats, vilket innebär att vi kan börja bygga dashboardar. Utifrån analyticsen av dashboardar från säkerhetsprodukter kan man förstå tillståndet för informationssäkerhet i organisationen, tydligt se sårbara punkter i den nuvarande policyn och vidare utveckla metoder för att åtgärda dem. Låt oss bygga ett litet dashboard med hjälp av flera visualiseringsverktyg. Dashboarden kommer att bestå av 5 komponenter:

1. en tabell för att räkna det totala antalet loggar per blade
2. en tabell för kritiska IPS-signaturer
3. ett cirkeldiagram för händelser av Threat Prevention
4. diagram över de mest populära webbplatserna
5. diagram över användningen av de mest riskfyllda programmen

För att skapa visualiseringsfigurer, gå till menyn Visualisera, och välj den figur vi vill bygga! Låt oss gå i ordning.

Tabell för att räkna det totala antalet loggar per blade

För detta väljer vi figuren Data Table, vi dyker ner i verktyget för att skapa diagram, till vänster ställs figurinställningarna in, till höger hur det kommer att se ut med de aktuella inställningarna. Först visar jag hur den färdiga tabellen kommer att se ut, efter detta går vi igenom inställningarna, bilden är klickbar:

Mer detaljerade figurinställningar, bilden är klickbar:

Låt oss gå igenom inställningarna.

Initialt ställs mätvärde, detta värde, efter vilket alla fält kommer att aggregeras. Metriker beräknas baserat på värden som på olika sätt extraheras från dokument. Värden extraheras vanligtvis från fälten i dokumentet, men kan också genereras med hjälp av skript. I det här fallet sätter vi i Aggregat: Antal (totalt antal loggar).

Efter detta delar vi tabellen enligt segment (fält) som metrik kommer att beräknas utifrån. Denna funktion utförs av inställningen Buckets, som i sin tur består av 2 alternativ för inställning:

1. split rows — lägga till kolumner och därefter dela tabellen i rader
2. split table — dela upp i flera tabeller baserat på värdena för ett specifikt fält.

I buckets Flera delningar kan läggas till för att skapa flera kolumner eller tabeller, begränsningarna här är snarare logiska. I aggregation kan du välja vilket sätt segmenteringen ska göras på: ipv4 range, date range, Terms etc. Det mest intressanta valet är faktiskt Terms och Significant Terms, segmenteringen sker baserat på värdena för ett specifikt indexfält, skillnaden mellan dem är mängden återlämnade värden och deras visning. Eftersom vi vill dela tabellen efter bladnamn, väljer vi fältet — product.keyword och ställer in storleken på 25 återlämnande värden.

Istället för rader i elasticsearch används 2 datatyper — text och keyword. Om du vill utföra en fulltext-sökning, måste du använda typ text, vilket är mycket användbart när du skriver din egen söktjänst, till exempel för att söka efter nämningar av ett ord i ett specifikt fält (text). Om du vill ha enbart exakt matchning måste du använda typ keyword. Typen keyword bör också användas för fält som kräver sortering eller aggregering, alltså i vårt fall.

Som ett resultat räknar Elasticsearch antalet loggar under en viss tid med aggregering efter värdet i fältet product. I Custom Label anger vi namnet på kolumnen som kommer att visas i tabellen, vi anger tid för vilken vi samlar loggar, startar visualiseringen - Kibana skickar en förfrågan till elasticsearch, väntar på svar och visualiserar de erhållna data. Tabellen är klar!

Cirkeldiagram över händelser i Threat Prevention

Informationen om hur många procent av reaktionerna är särskilt intressant detect och prevent på incidenter inom informationssäkerhetsaktuell säkerhetspolicy. För detta ändamål passar ett cirkeldiagram bra. Vi väljer i Visualize - Pie chart. I metrik väsentligen anger vi aggregering efter antal loggar. I buckets sätter vi Terms => action.

Allt verkar korrekt, men resultaten visar värden för alla blades, vi måste filtrera så att vi endast visar de blades som arbetar inom Threat Prevention. Därför konfigurerar vi ett filter för att söka information endast om blades som ansvarar för incidenter inom informationssäkerhet - product: ("Anti-Bot" OR "New Anti-Virus" OR "DDoS Protector" OR "SmartDefense" OR "Threat Emulation"). Bilden är klickbar:

Och mer detaljerade inställningar, bilden är klickbar:

Tabell över händelser i IPS

Vidare är det mycket viktigt ur perspektivet av informationssäkerhet att granska och kontrollera händelser för blade IPS och Hotemulering, som som inte blockeras av den aktuella policyn, för att i ett senare skede antingen överföra signaturen till prevent, eller om trafiken är giltig - inte kontrollera signaturen. Tabellen skapar vi på samma sätt som för första exemplet, med den skillnaden att vi skapar flera kolumner: protections.keyword, severity.keyword, product.keyword, originsicname.keyword. Vi konfigurerar nödvändigtvis ett filter för att söka information endast om blades som ansvarar för incidenter inom informationssäkerhet - product: ("SmartDefense" OR "Threat Emulation"). Bilden är klickbar:

Mer detaljerade inställningar, bilden är klickbar:

Diagram över de mest populära besökta webbplatserna

För detta skapar vi en figur — Vertical Bar. Vi använder också metriken count (Y-axeln), och på X-axeln kommer vi att använda namnen på de besökta webbplatserna — “appi_name”. Här finns en liten trick, om inställningarna körs i nuvarande form, kommer alla webbplatser att markeras med en färg på diagrammet. För att göra dem flerfärgade använder vi en extra inställning — “split series”, som gör att vi kan dela den redan färdiga kolumnen i flera värden, beroende på det valda fältet såklart! Denna uppdelning kan antingen användas som en flerfärgad kolumn efter värden i läget stacked, eller i det normala läget för att skapa flera kolumner baserade på ett specifikt värde från X-axeln. I detta fall använder vi samma värde som på X-axeln, vilket gör att alla kolumner kan bli flerfärgade, och de kommer att representeras med färger längst uppe till höger. I filtret ställer vi in — product:«URL Filtering» för att se information endast om de besökta webbplatserna, bilden är klickbar:

Inställningar:

Diagram över användningen av de mest farliga applikationerna

För detta skapar vi en figur — Vertical Bar. Vi använder också metriken count (Y-axeln), och på X-axeln kommer vi att använda namnen på de använda-apparna — “appi_name”. Det viktigaste är att ange filtret — product: «Application Control» AND app_risk: (4 OR 5 OR 3) AND action: «accept». Vi filtrerar loggarna efter bladet Application Control, och tar endast de webbplatser som är kategoriserade som webbplatser med risk för Critical, High, Medium och endast i de fall där åtkomsten till dessa webbplatser är tillåten. Bilden är klickbar:

Inställningar, klickbart:

Dashboard

Visning och skapande av dashboards finns i en separat menypunkt — Dashboard. Här är det enkelt, en ny dashboard skapas, visualisering läggs till, placeras och allt är klart!

Vi skapar en dashboard där vi kan förstå den grundläggande situationen av cybersäkerhet i organisationen, klart, endast på Check Point-nivå, bilden är klickbar:

Baserat på dessa diagram kan vi förstå vilka kritiska signaturer som inte blockeras av brandväggen, vart användarna går och vilka de mest farliga applikationerna de använder.

Slutsats

Vi har gått igenom grundläggande visualiseringsmöjligheter i Kibana och skapat ett dashboard, men detta är bara en liten del. I kursen kommer vi separerat att gå igenom inställningarna för kartor, arbete med Elasticsearch-systemet, bekanta oss med API-förfrågningar, automatisering och mycket mer!

Så håll utkik efter uppdateringar (Telegram, Facebook, VK, TS Solution Blog), Yandex.Dzen.

Källa: habr.com