God eftermiddag, i tidligere artikler stiftede vi bekendtskab med ELK Stacks arbejde. Lad os nu diskutere de muligheder, som en informationssikkerhedsspecialist kan implementere ved at bruge disse systemer. Hvilke logfiler kan og bør indtastes i elasticsearch. Lad os overveje hvilken statistik der kan fås ved at opsætte dashboards og om der er overskud i dette. Hvordan kan du implementere automatisering af informationssikkerhedsprocesser ved hjælp af ELK-stakken. Lad os tegne systemets arkitektur. Samlet set er implementeringen af al funktionalitet en meget stor og vanskelig opgave, så løsningen fik et særskilt navn - TS Total Sight.
I øjeblikket vinder løsninger, der konsoliderer og analyserer informationssikkerhedshændelser på ét logisk sted, hurtigt popularitet, som et resultat, modtager specialisten statistikker og en handlingsgrænse for at forbedre status for informationssikkerhed i organisationen. Vi satte os denne opgave i at bruge ELK-stakken, og som et resultat opdelte vi hovedfunktionaliteten i 4 sektioner:
- Statistik og visualisering;
- Detektion af informationssikkerhedshændelser;
- Hændelsesprioritering;
- Automatisering af informationssikkerhedsprocesser.
Dernæst vil vi se nærmere på hver enkelt.
Detektion af informationssikkerhedshændelser
Hovedopgaven ved at bruge elasticsearch i vores tilfælde er kun at indsamle informationssikkerhedshændelser. Du kan indsamle informationssikkerhedshændelser fra alle sikkerhedsmidler, hvis de understøtter i det mindste nogle måder at sende logfiler på, standarden er syslog eller scp-lagring til en fil.
Du kan give standardeksempler på sikkerhedsværktøjer og mere, hvorfra du skal konfigurere videresendelse af logfiler:
- Eventuelle NGFW-værktøjer (Check Point, Fortinet);
- Eventuelle sårbarhedsscannere (PT Scanner, OpenVas);
- Web Application Firewall (PT AF);
- netflow-analysatorer (Flowmon, Cisco StealthWatch);
- AD server.
Når du har konfigureret afsendelsen af logs og konfigurationsfiler i Logstash, kan du korrelere og sammenligne med hændelser, der kommer fra forskellige sikkerhedsværktøjer. For at gøre dette er det praktisk at bruge indekser, hvor vi gemmer alle hændelser relateret til en bestemt enhed. Med andre ord er ét indeks alle hændelser på én enhed. Denne fordeling kan implementeres på 2 måder.
første udførelsesform Dette er for at konfigurere Logstash-konfigurationen. For at gøre dette skal du duplikere loggen for visse felter til en separat enhed med en anden type. Og brug så denne type i fremtiden. I eksemplet klones logfiler fra IPS-bladet på Check Point-firewall'en.
filter {
if [product] == "SmartDefense" {
clone {
clones => ["CloneSmartDefense"]
add_field => {"system" => "checkpoint"}
}
}
}
For at gemme sådanne hændelser i et separat indeks afhængigt af logfelterne, f.eks. Destinations IP-angrebssignaturer. Du kan bruge en lignende konstruktion:
output {
if [type] == "CloneSmartDefense"{
{
elasticsearch {
hosts => [",<IP_address_elasticsearch>:9200"]
index => "smartdefense-%{dst}"
user => "admin"
password => "password"
}
}
}
Og på denne måde kan du gemme alle hændelser i et indeks, for eksempel efter IP-adresse eller efter domænenavn på maskinen. I dette tilfælde gemmer vi det i indekset "smartdefense-%{dst}", efter IP-adressen på signaturdestinationen.
Forskellige produkter vil dog have forskellige logfelter, hvilket vil føre til kaos og unødvendigt hukommelsesforbrug. Og her skal du enten omhyggeligt erstatte felterne i Logstash-konfigurationsindstillingerne med prædesignede, som vil være ens for alle typer hændelser, hvilket også er en vanskelig opgave.
Anden implementeringsmulighed - dette er at skrive et script eller en proces, der vil få adgang til den elastiske database i realtid, trække de nødvendige hændelser ud og gemme dem i et nyt indeks, dette er en vanskelig opgave, men det giver dig mulighed for at arbejde med logfiler, som du vil, og korrelerer direkte med hændelser fra andet sikkerhedsudstyr. Denne mulighed giver dig mulighed for at konfigurere arbejde med logs til at være mest anvendeligt for din sag med maksimal fleksibilitet, men her opstår problemet med at finde en specialist, der kan implementere dette.
Og selvfølgelig det vigtigste spørgsmål, og hvad kan korreleres og opdages??
Der kan være flere muligheder her, og det afhænger af, hvilke sikkerhedsværktøjer der bruges i din infrastruktur, et par eksempler:
- Den mest oplagte og, fra mit synspunkt, den mest interessante mulighed for dem, der har en NGFW-løsning og en sårbarhedsscanner. Dette er en sammenligning af IPS-logfiler og resultater fra sårbarhedsscanning. Hvis et angreb blev opdaget (ikke blokeret) af IPS-systemet, og denne sårbarhed ikke er lukket på slutmaskinen baseret på scanningsresultaterne, er det nødvendigt at fløjte, da der er stor sandsynlighed for, at sårbarheden er blevet udnyttet .
- Mange loginforsøg fra én maskine til forskellige steder kan symbolisere ondsindet aktivitet.
- Bruger downloader virusfiler på grund af at besøge et stort antal potentielt farlige websteder.
Statistik og visualisering
Den mest åbenlyse og forståelige ting, som ELK Stack er nødvendig for, er opbevaring og visualisering af logs, det blev vist, hvordan du kan oprette logfiler fra forskellige enheder ved hjælp af Logstash. Efter at loggene er gået til Elasticsearch, kan du opsætte dashboards, som også blev nævnt , med de oplysninger og statistikker, du har brug for gennem visualisering.
Eksempler:
- Dashboard til trusselsforebyggende begivenheder med de mest kritiske begivenheder. Her kan du afspejle, hvilke IPS-signaturer der blev opdaget, og hvor de kommer fra geografisk.
- Dashboard om brugen af de mest kritiske applikationer, for hvilke oplysninger kan lækkes.
- Scan resultater fra enhver sikkerhedsscanner.
- Active Directory-logfiler efter bruger.
- VPN-forbindelses dashboard.
I dette tilfælde, hvis du konfigurerer dashboards til at opdatere med få sekunders mellemrum, kan du få et ret praktisk system til overvågning af hændelser i realtid, som så kan bruges til den hurtigste reaktion på informationssikkerhedshændelser, hvis du placerer dashboards på en separat skærmen.
Hændelsesprioritering
Under forhold med stor infrastruktur kan antallet af hændelser gå ud over skala, og specialister vil ikke have tid til at håndtere alle hændelser i tide. I dette tilfælde er det først og fremmest nødvendigt kun at fremhæve de hændelser, der udgør en stor trussel. Derfor skal systemet prioritere hændelser ud fra deres alvor i forhold til din infrastruktur. Det er tilrådeligt at oprette en e-mail- eller telegramadvarsel for disse begivenheder. Prioritering kan implementeres ved at bruge standard Kibana-værktøjer ved at opsætte visualisering. Men med meddelelser er det vanskeligere; som standard er denne funktionalitet ikke inkluderet i den grundlæggende version af Elasticsearch, kun i den betalte version. Køb derfor enten en betalt version, eller skriv igen selv en proces, der vil underrette specialister i realtid via e-mail eller telegram.
Automatisering af informationssikkerhedsprocesser
Og en af de mest interessante dele er automatiseringen af handlinger for informationssikkerhedshændelser. Tidligere har vi implementeret denne funktionalitet til Splunk, du kan læse lidt mere i denne . Hovedtanken er, at IPS-politikken aldrig bliver testet eller optimeret, selvom den i nogle tilfælde er en kritisk del af informationssikkerhedsprocesser. For eksempel, et år efter implementeringen af NGFW og fraværet af handlinger til at optimere IPS, vil du akkumulere et stort antal signaturer med Detect-handlingen, som ikke vil blive blokeret, hvilket i høj grad reducerer tilstanden af informationssikkerhed i organisationen. Nedenfor er nogle eksempler på, hvad der kan automatiseres:
- Overførsel af IPS-signatur fra Detect til Prevent. Hvis Prevent ikke virker for kritiske signaturer, så er dette ude af drift og et alvorligt hul i beskyttelsessystemet. Vi ændrer handlingen i politikken til sådanne underskrifter. Denne funktionalitet kan implementeres, hvis NGFW-enheden har REST API-funktionalitet. Dette er kun muligt, hvis du har programmeringsfærdigheder; du skal udtrække de nødvendige oplysninger fra Elastcisearch og lave API-anmodninger til NGFW-administrationsserveren.
- Hvis flere signaturer blev opdaget eller blokeret i netværkstrafik fra én IP-adresse, giver det mening at blokere denne IP-adresse i et stykke tid i Firewall-politikken. Implementeringen består også i at bruge REST API.
- Kør en værtsscanning med en sårbarhedsscanner, hvis denne vært har et stort antal IPS-signaturer eller andre sikkerhedsværktøjer; hvis det er OpenVas, så kan du skrive et script, der forbinder via ssh til sikkerhedsscanneren og køre scanningen.
TS Total Syn
Samlet set er implementeringen af al funktionalitet en meget stor og vanskelig opgave. Uden at have programmeringsfærdigheder kan du konfigurere minimumsfunktionaliteten, som kan være tilstrækkelig til brug i produktionen. Men hvis du er interesseret i al funktionaliteten, kan du være opmærksom på TS Total Sight. Du kan finde flere detaljer på vores . Som et resultat vil hele driftsskemaet og arkitekturen se sådan ud:
Konklusion
Vi så på, hvad der kan implementeres ved hjælp af ELK Stack. I efterfølgende artikler vil vi særskilt overveje funktionaliteten af TS Total Sight mere detaljeret!
Så følg med (, , , ), .
Kilde: www.habr.com