God ettermiddag, i tidligere artikler ble vi kjent med arbeidet til ELK Stack. La oss nå diskutere mulighetene som kan realiseres av en informasjonssikkerhetsspesialist ved bruk av disse systemene. Hvilke logger kan og bør legges inn i elasticsearch. La oss vurdere hvilken statistikk som kan fås ved å sette opp dashboards og om det er noe overskudd i dette. Hvordan kan du implementere automatisering av informasjonssikkerhetsprosesser ved hjelp av ELK-stakken. La oss tegne opp arkitekturen til systemet. Totalt sett er implementering av all funksjonalitet en veldig stor og vanskelig oppgave, så løsningen fikk et eget navn – TS Total Sight.
For tiden øker løsninger som konsoliderer og analyserer informasjonssikkerhetshendelser på ett logisk sted raskt popularitet, som et resultat av at spesialisten mottar statistikk og en handlingsgrense for å forbedre tilstanden til informasjonssikkerhet i organisasjonen. Vi satte oss denne oppgaven ved å bruke ELK-stakken, og som et resultat delte vi hovedfunksjonaliteten inn i 4 seksjoner:
- Statistikk og visualisering;
- Deteksjon av informasjonssikkerhetshendelser;
- Hendelsesprioritering;
- Automatisering av informasjonssikkerhetsprosesser.
Deretter skal vi se nærmere på hver enkelt.
Deteksjon av informasjonssikkerhetshendelser
Hovedoppgaven med å bruke elasticsearch i vårt tilfelle er kun å samle informasjonssikkerhetshendelser. Du kan samle informasjonssikkerhetshendelser fra alle sikkerhetsmetoder hvis de støtter minst noen moduser for å sende logger, standarden er syslog eller scp-lagring til en fil.
Du kan gi standard eksempler på sikkerhetsverktøy og mer, hvorfra du bør konfigurere videresending av logger:
- Eventuelle NGFW-verktøy (Check Point, Fortinet);
- Eventuelle sårbarhetsskannere (PT Scanner, OpenVas);
- Brannmur for nettapplikasjoner (PT AF);
- netflowanalysatorer (Flowmon, Cisco StealthWatch);
- AD server.
Når du har konfigurert sending av logger og konfigurasjonsfiler i Logstash, kan du korrelere og sammenligne med hendelser som kommer fra ulike sikkerhetsverktøy. For å gjøre dette er det praktisk å bruke indekser der vi vil lagre alle hendelser knyttet til en bestemt enhet. Med andre ord, én indeks er alle hendelser til én enhet. Denne distribusjonen kan implementeres på 2 måter.
Det første alternativet Dette er for å konfigurere Logstash-konfigurasjonen. For å gjøre dette må du duplisere loggen for visse felt til en egen enhet med en annen type. Og så bruk denne typen i fremtiden. I eksemplet klones logger fra IPS-bladet til Check Point-brannmuren.
filter {
if [product] == "SmartDefense" {
clone {
clones => ["CloneSmartDefense"]
add_field => {"system" => "checkpoint"}
}
}
}
For å lagre slike hendelser i en egen indeks avhengig av loggfeltene, for eksempel, for eksempel Destination IP-angrepssignaturer. Du kan bruke en lignende konstruksjon:
output {
if [type] == "CloneSmartDefense"{
{
elasticsearch {
hosts => [",<IP_address_elasticsearch>:9200"]
index => "smartdefense-%{dst}"
user => "admin"
password => "password"
}
}
}
Og på denne måten kan du lagre alle hendelser i en indeks, for eksempel etter IP-adresse eller etter domenenavn på maskinen. I dette tilfellet lagrer vi det i indeksen "smartdefense-%{dst}", etter IP-adressen til signaturdestinasjonen.
Forskjellige produkter vil imidlertid ha ulike loggfelt, noe som vil føre til kaos og unødvendig minneforbruk. Og her må du enten forsiktig erstatte feltene i Logstash-konfigurasjonsinnstillingene med forhåndsdesignede, som vil være de samme for alle typer hendelser, noe som også er en vanskelig oppgave.
Andre implementeringsalternativ - dette er å skrive et skript eller en prosess som vil få tilgang til den elastiske databasen i sanntid, trekke ut de nødvendige hendelsene og lagre dem i en ny indeks, dette er en vanskelig oppgave, men det lar deg jobbe med logger som du vil, og korrelerer direkte med hendelser fra annet sikkerhetsutstyr. Dette alternativet lar deg konfigurere arbeid med logger til å være mest nyttig for din sak med maksimal fleksibilitet, men her oppstår problemet med å finne en spesialist som kan implementere dette.
Og selvfølgelig det viktigste spørsmålet, og hva kan korreleres og oppdages??
Det kan være flere alternativer her, og det avhenger av hvilke sikkerhetsverktøy som brukes i infrastrukturen din, et par eksempler:
- Det mest åpenbare og, fra mitt ståsted, det mest interessante alternativet for de som har en NGFW-løsning og en sårbarhetsskanner. Dette er en sammenligning av IPS-logger og resultater av sårbarhetsskanning. Hvis et angrep ble oppdaget (ikke blokkert) av IPS-systemet, og denne sårbarheten ikke er lukket på sluttmaskinen basert på skanneresultatene, er det nødvendig å blåse i fløyta, siden det er stor sannsynlighet for at sårbarheten har blitt utnyttet .
- Mange påloggingsforsøk fra én maskin til forskjellige steder kan symbolisere ondsinnet aktivitet.
- Bruker som laster ned virusfiler på grunn av å besøke et stort antall potensielt farlige nettsteder.
Statistikk og visualisering
Det mest åpenbare og forståelige som ELK Stack er nødvendig for er lagring og visualisering av logger, det ble vist hvordan du kan lage logger fra ulike enheter ved hjelp av Logstash. Etter at loggene går til Elasticsearch, kan du sette opp dashboards, som også ble nevnt , med informasjonen og statistikken du trenger gjennom visualisering.
Eksempler:
- Dashboard for trusselforebyggende hendelser med de mest kritiske hendelsene. Her kan du reflektere hvilke IPS-signaturer som ble oppdaget og hvor de kommer fra geografisk.
- Dashboard om bruk av de mest kritiske applikasjonene som informasjon kan lekkes for.
- Skann resultater fra hvilken som helst sikkerhetsskanner.
- Active Directory-logger etter bruker.
- Dashboard for VPN-tilkobling.
I dette tilfellet, hvis du konfigurerer dashbordene til å oppdatere med noen sekunders mellomrom, kan du få et ganske praktisk system for å overvåke hendelser i sanntid, som deretter kan brukes for raskest respons på informasjonssikkerhetshendelser hvis du plasserer dashbordene på en separat skjerm.
Hendelsesprioritering
Under forhold med stor infrastruktur kan antallet hendelser gå av skala, og spesialister vil ikke ha tid til å sortere ut alle hendelsene i tide. I dette tilfellet er det først og fremst nødvendig å fremheve bare de hendelsene som utgjør en stor trussel. Derfor må systemet prioritere hendelser ut fra deres alvorlighetsgrad i forhold til din infrastruktur. Det anbefales å sette opp et e-post- eller telegramvarsel for disse hendelsene. Prioritering kan implementeres ved å bruke standard Kibana-verktøy ved å sette opp visualisering. Men med varsler er det vanskeligere som standard, denne funksjonaliteten er ikke inkludert i den grunnleggende versjonen av Elasticsearch, bare i den betalte versjonen. Kjøp derfor enten en betalt versjon, eller skriv igjen en prosess selv som vil varsle spesialister i sanntid via e-post eller telegram.
Automatisering av informasjonssikkerhetsprosesser
Og en av de mest interessante delene er automatisering av handlinger for informasjonssikkerhetshendelser. Tidligere har vi implementert denne funksjonaliteten for Splunk, du kan lese litt mer i denne . Hovedideen er at IPS-policyen aldri blir testet eller optimalisert, selv om den i noen tilfeller er en kritisk del av informasjonssikkerhetsprosesser. For eksempel, et år etter implementeringen av NGFW og fraværet av handlinger for å optimalisere IPS, vil du akkumulere et stort antall signaturer med Detect-handlingen, som ikke vil bli blokkert, noe som i stor grad reduserer tilstanden til informasjonssikkerhet i organisasjonen. Nedenfor er noen eksempler på hva som kan automatiseres:
- Overføring av IPS-signatur fra Detect til Prevent. Hvis Prevent ikke fungerer for kritiske signaturer, så er dette ute av drift og et alvorlig hull i beskyttelsessystemet. Vi endrer handlingen i policyen til slike signaturer. Denne funksjonaliteten kan implementeres hvis NGFW-enheten har REST API-funksjonalitet. Dette er bare mulig hvis du har programmeringskunnskaper du trenger å trekke ut nødvendig informasjon fra Elastcisearch og sende API-forespørsler til NGFW-administrasjonsserveren.
- Hvis flere signaturer ble oppdaget eller blokkert i nettverkstrafikk fra én IP-adresse, er det fornuftig å blokkere denne IP-adressen en stund i brannmurpolicyen. Implementeringen består også av bruk av REST API.
- Kjør en vertsskanning med en sårbarhetsskanner, hvis denne verten har et stort antall IPS-signaturer eller andre sikkerhetsverktøy hvis det er OpenVas, så kan du skrive et skript som kobler til sikkerhetsskanneren via ssh og kjører skanningen.
TS Totalt syn
Totalt sett er implementering av all funksjonalitet en veldig stor og vanskelig oppgave. Uten å ha programmeringskunnskaper kan du konfigurere minimumsfunksjonaliteten, som kan være tilstrekkelig for bruk i produksjonen. Men hvis du er interessert i all funksjonalitet, kan du ta hensyn til TS Total Sight. Du kan finne flere detaljer på vår . Som et resultat vil hele driftsskjemaet og arkitekturen se slik ut:
Konklusjon
Vi så på hva som kan implementeres ved hjelp av ELK Stack. I påfølgende artikler vil vi separat vurdere funksjonaliteten til TS Total Sight mer detaljert!
Så følg med, , , ), .
Kilde: www.habr.com