🥇TS Total Sight. Værktøj til indsamling af begivenheder, analyse af hændelser og automatisering af reaktioner på trusler

Goddag, i tidligere artikler har vi set på, hvordan ELK Stack fungerer. Nu vil vi diskutere de muligheder, som en ekspert inden for informationssikkerhed kan realisere ved brug af disse systemer. Hvilke logs bør og kan indsamles i Elasticsearch? Vi vil se nærmere på, hvilken statistik der kan opnås ved at konfigurere dashboards, og om der er profit i dette. Hvordan kan man implementere automatisering af informationssikkerhedsprocesser ved at bruge ELK-stakken? Vi vil sammensætte systemets arkitektur. Samlet set er implementeringen af al funktionalitet en meget stor og tung opgave, hvorfor løsningen har fået et særskilt navn — TS Total Sight.

I øjeblikket vinder løsninger, der konsoliderer og analyserer informationssikkerhedshændelser på ét logisk sted, stærkt i popularitet. Resultatet er, at specialisten får statistik og handlingspunkter til at forbedre informationssikkerhedstilstanden i organisationen. Denne opgave har vi sat os for i brugen af ELK-stakken, hvor vi har opdelt den primære funktionalitet i 4 sektioner:

Statistik og visualisering;
Opdagelse af informationssikkerhedshændelser;
Prioritering af hændelser;
Automatisering af informationssikkerhedsprocesser.

Lad os derefter se nærmere på hver af dem.

Opdagelse af informationssikkerhedshændelser

Hovedformålet med at bruge Elasticsearch i vores tilfælde er at indsamle kun informationssikkerhedshændelser. Hændelser kan indsamles fra alle former for beskyttelsesmidler, hvis de understøtter nogen form for logoverførselsmetoder, typisk syslog eller ved at gemme til fil via SCP.

Her er nogle standardeksempler på beskyttelsesmidler, hvorfra logoverførsel skal konfigureres:

Enhver form for NGFW (Check Point, Fortinet);
Enhver sårbarhedsscanner (PT Scanner, OpenVas);
Web Application Firewall (PT AF);
Netflow-analyzere (Flowmon, Cisco StealthWatch);
AD-server.

Når logoverførsel og konfigurationsfiler er indstillet til Logstash, kan vi korrelere og sammenligne hændelser indkommet fra forskellige sikkerhedsmidler. Det er praktisk at bruge indekser, hvor vi vil gemme alle hændelser relateret til en bestemt enhed. Med andre ord, et indeks indeholder alle hændelser for én enhed. Dette opdelingsformat kan implementeres på 2 måder.

Den første mulighed Dette er at konfigurere Logstash. For at gøre dette er det nødvendigt at duplikere loggen efter bestemte felter i en separat enhed med en anden type. Og derefter bruge denne type i fremtiden. I eksemplet kloneres loggene for IPS-blade fra Check Point firewall.

filter {
    if [product] == "SmartDefense" {
        clone {
	    clones => ["CloneSmartDefense"]
	    add_field => {"system" => "checkpoint"}
	}
    }
}

For at gemme sådanne hændelser i en separat indeks afhængigt af logfelterne, f.eks. som Destination IP for angrebssignaturer. Kan du bruge en lignende konstruktion:

output {
    if [type] == "CloneSmartDefense"{
    {
         elasticsearch {
    	 hosts => [",:9200"]
    	 index => "smartdefense-%{dst}"
    	 user => "admin"
    	 password => "password"
  	 }
    }
}

Og på den måde kan man gemme i indekset alle hændelser, for eksempel, efter IP-adresse eller efter domænenavnet på maskinen. I dette tilfælde gemmer vi i indekset «smartdefense-%{dst}», efter IP-adresse for angrebssignatur.

Men forskellige produkter vil have forskellige felter for logs, hvilket vil føre til kaos og unødigt forbrug af hukommelse. Her skal enten felterne i Logstash-konfigurationen omhyggeligt ændres til de forudbestemte, der vil være ens for alle typer hændelser, hvilket også er en vanskelig opgave.

Den anden implementeringsmulighed — er at skrive et script eller en proces, der i realtid kontakter Elasticsearch-databasen, henter de nødvendige hændelser og gemmer dem i en ny indeks. Dette er en krævende opgave, men giver mulighed for at arbejde med logs, som man ønsker, og korrelere direkte med hændelser fra andre sikkerhedsværktøjer. Denne mulighed gør det muligt at optimere logarbejde maksimalt til dit specifikke behov med maksimal fleksibilitet, men her opstår problemet med at finde den specialist, der kan implementere det.

Og selvfølgelig, det allervigtigste spørgsmål, hvad der overhovedet kan korreleres og opdages?

Her kan der være flere muligheder, og det afhænger af, hvilke sikkerhedsværktøjer der anvendes i din infrastruktur. Et par eksempler:

Den mest åbenlyse og efter min mening mest interessante løsning for dem, der har en NGFW-løsning og en sårbarhedsscanner, er at sammenligne loggene fra IPS med resultaterne fra sårbarhedsscanningen. Hvis der er registreret et angreb (som ikke blev blokeret) af IPS-systemet, og denne sårbarhed ikke er lukket på den endelige maskine baseret på scanningsresultaterne, skal der råbes i alle rør, da der er en stor sandsynlighed for, at sårbarheden er blevet udnyttet.
Mange loginforsøg fra én maskine til forskellige steder kan symbolisere ondsindet aktivitet.
Download af virusfiler af brugeren som følge af besøg på et stort antal potentielt farlige websteder.

Statistik og visualisering

Det mest åbenlyse og forståelige formål med ELK Stack er opbevaring og visualisering af logs, som blev vist i tidligere artikler, der viste, hvordan man kan indsamle logs fra forskellige enheder ved hjælp af Logstash. Når loggene sendes til Elasticsearch, kan der oprettes dashboards, som også blev nævnt, som blev vist i tidligere artikler,, med den nødvendige information og statistik via visualisering.

Eksempler:

Dashboard for begivenheder i Threat Prevention med de mest kritiske hændelser. Her kan man vise, hvilke IPS-signaturer der er blevet opdaget, og hvor de geografisk stammer fra.
Dashboard for brug af de mest kritiske applikationer, hvor information kan lække.
Resultaterne af scanningerne fra enhver sikkerhedsscanner.
Logs fra Active Directory for brugere.
Dashboard for VPN-forbindelser.

I dette tilfælde, hvis man konfigurerer dashboards til at opdatere hvert par sekunder, kan man få et ret praktisk system til overvågning af begivenheder i realtid, som derefter kan bruges til hurtigere reaktion på IT-sikkerheds hændelser, hvis man placerer dashboards på en separat skærm.

Prioritering af hændelser

I store store store store store store store store store store store store store store store store store store store store store store store store. Vhovedsagen til at udskille de højeste risici kan være svært eller nemt. For at gøre dette skal systemet prioritere kun de hændelser, der udgør den største trussel. Det anbefales at opsætte varsel via e-mail eller Telegram for disse hændelser. Prioritering kan implementeres ved hjælp af standardfunktionerne i Kibana gennem opsætning af visualisering. Det er dog vanskeligere med advarsler; denne funktionalitet er ikke som standard inkluderet i den grundlæggende version af Elasticsearch, kun i den betalte version. Så man skal enten købe den betalte version eller selv skrive en proces, der vil underrette specialisterne i realtid via e-mail eller Telegram.

Automatisering af informationssikkerhedsprocesser

En af de mest interessante dele er automatiseringen af handlinger ved informationssikkerhedshændelser. Tidligere har vi implementeret denne funktionalitet til Splunk; du kan læse lidt mere om det her artikel. Hovedideen er, at IPS-politikken aldrig bliver kontrolleret eller optimeret, selvom det i nogle tilfælde er en vigtig del af informationssikkerhedsprocesserne. For eksempel, efter et år med implementering af NGFW og fraværet af optimeringshandlinger, vil der opsamles et stort antal signaturer med handlingsniveauet Detect, som ikke vil blive blokeret, hvilket alvorligt underminerer informationssikkerhedstilstanden i organisationen. Her er nogle eksempler på, hvad der kan automatiseres:

Ændring af IPS-signatur fra Detect til Prevent. Hvis kritiske signaturer ikke fungerer med Prevent, er det ikke i orden, og der er et alvorligt hul i beskyttelsessystemet. Ændring af handlingen i politikken for disse signaturer. Denne funktionalitet kan implementeres, hvis NGFW-enheden har REST API-funktionalitet. Det er kun muligt, hvis man har programmeringsevner; man skal hente de nødvendige oplysninger fra Elasticsearch og udføre API-anmodninger til NGFW-administrationsserveren.
Hvis en stor mængde signaturer opdages eller blokeres fra én IP-adresse i netværkstrafikken, giver det mening at blokere denne IP-adresse midlertidigt i Firewall-politikken. Implementeringen indebærer også brugen af REST API.
Kør en hostcheck med en sårbarhedsscanner, hvis denne host har et stort antal signaturer i IPS eller andre sikkerhedsværktøjer; hvis det er OpenVas, kan man skrive et script, der connecter via SSH til sikkerhedsscanneren og starter scanning.

TS Total Sight

Sammenfattende er implementeringen af al funktionalitet en meget stor og tung opgave. Uden programmeringsevner kan man opsætte den minimale funktionalitet, som kan være tilstrækkelig til brug i produktionen. Men hvis du er interesseret i al funktionalitet, kan du se nærmere på TS Total Sight. Du kan læse mere om det på vores websitet. Som resultat vil hele arbejdsplanen og arkitekturen se således ud: