Dobar dan, u prethodnim člancima smo se upoznali sa radom ELK Stacka. Hajde sada da razgovaramo o mogućnostima koje može da realizuje stručnjak za informacionu bezbednost u korišćenju ovih sistema. Koje trupce se mogu i trebaju unijeti u elasticsearch. Razmotrimo kakve se statistike mogu dobiti postavljanjem nadzornih ploča i ima li u tome profita. Kako možete implementirati automatizaciju procesa sigurnosti informacija koristeći ELK stek. Hajde da nacrtamo arhitekturu sistema. Sve u svemu, implementacija svih funkcionalnosti je vrlo veliki i težak zadatak, pa je rješenje dobilo poseban naziv - TS Total Sight.
Trenutno, rješenja koja objedinjuju i analiziraju incidente u informacijskoj sigurnosti na jednom logičnom mjestu brzo dobijaju na popularnosti, kao rezultat toga, stručnjak dobija statistiku i granicu djelovanja za poboljšanje stanja informacione sigurnosti u organizaciji. Ovaj zadatak smo si postavili korištenjem ELK steka, i kao rezultat toga podijelili smo glavnu funkcionalnost u 4 dijela:
- Statistika i vizualizacija;
- Otkrivanje incidenata sigurnosti informacija;
- Određivanje prioriteta incidenata;
- Automatizacija procesa informacione sigurnosti.
Zatim ćemo pobliže pogledati svaki ponaosob.
Detekcija incidenata sigurnosti informacija
Glavni zadatak korištenja elasticsearch u našem slučaju je prikupljanje samo incidenata sigurnosti informacija. Incidente sigurnosti informacija možete prikupiti sa bilo kojeg sigurnosnog sredstva ako podržavaju barem neke načine slanja dnevnika, standard je syslog ili scp spremanje u datoteku.
Možete dati standardne primjere sigurnosnih alata i još mnogo toga, odakle biste trebali konfigurirati prosljeđivanje dnevnika:
- Bilo koji NGFW alat (Check Point, Fortinet);
- Bilo koji skeneri ranjivosti (PT Scanner, OpenVas);
- Zaštitni zid web aplikacija (PT AF);
- analizatori mrežnog toka (Flowmon, Cisco StealthWatch);
- AD server.
Kada konfigurišete slanje dnevnika i konfiguracionih fajlova u Logstash-u, možete da povežete i uporedite sa incidentima koji dolaze iz različitih bezbednosnih alata. Da biste to učinili, prikladno je koristiti indekse u koje ćemo pohraniti sve incidente vezane za određeni uređaj. Drugim riječima, jedan indeks su svi incidenti na jednom uređaju. Ova distribucija se može implementirati na 2 načina.
Prva opcija Ovo je za konfiguraciju Logstash konfiguracije. Da biste to učinili, morate duplicirati dnevnik za određena polja u zasebnu jedinicu drugog tipa. I onda koristite ovu vrstu u budućnosti. U primjeru, zapisnici su klonirani iz IPS blade-a Check Point firewall-a.
filter {
if [product] == "SmartDefense" {
clone {
clones => ["CloneSmartDefense"]
add_field => {"system" => "checkpoint"}
}
}
}
Da bi se takvi događaji spremili u poseban indeks u zavisnosti od polja dnevnika, na primjer, kao što su potpisi napada odredišne IP adrese. Možete koristiti sličnu konstrukciju:
output {
if [type] == "CloneSmartDefense"{
{
elasticsearch {
hosts => [",<IP_address_elasticsearch>:9200"]
index => "smartdefense-%{dst}"
user => "admin"
password => "password"
}
}
}
I na ovaj način možete sve incidente pohraniti u indeks, na primjer, po IP adresi ili po imenu domene mašine. U ovom slučaju, spremamo ga u indeks "smartdefense-%{dst}", po IP adresi odredišta potpisa.
Međutim, različiti proizvodi će imati različita polja dnevnika, što će dovesti do haosa i nepotrebne potrošnje memorije. I ovdje ćete morati pažljivo zamijeniti polja u postavkama Logstash konfiguracije unaprijed dizajniranim, što će biti isto za sve vrste incidenata, što je također težak zadatak.
Druga opcija implementacije - ovo je pisanje skripte ili procesa koji će pristupiti elastičnoj bazi podataka u realnom vremenu, izvući potrebne incidente i spremiti ih u novi indeks, ovo je težak zadatak, ali vam omogućava da radite s logovima kako želite, i direktno koreliraju sa incidentima sa druge sigurnosne opreme. Ova opcija vam omogućava da konfigurirate rad sa evidencijama tako da bude najkorisniji za vaš slučaj uz maksimalnu fleksibilnost, ali ovdje nastaje problem u pronalaženju stručnjaka koji to može implementirati.
I naravno, najvažnije pitanje, i šta se može povezati i detektovati??
Ovdje može postojati nekoliko opcija, a ovisi o tome koji se sigurnosni alati koriste u vašoj infrastrukturi, nekoliko primjera:
- Najočiglednija i, sa moje tačke gledišta, najzanimljivija opcija za one koji imaju NGFW rješenje i skener ranjivosti. Ovo je poređenje IPS logova i rezultata skeniranja ranjivosti. Ako je IPS sistem detektovao (nije blokirao) napad, a ova ranjivost nije zatvorena na krajnjoj mašini na osnovu rezultata skeniranja, potrebno je zazviždati, jer postoji velika verovatnoća da je ranjivost iskorišćena .
- Mnogi pokušaji prijavljivanja s jedne mašine na različita mjesta mogu simbolizirati zlonamjernu aktivnost.
- Korisnik preuzima virusne datoteke zbog posjete ogromnom broju potencijalno opasnih stranica.
Statistika i vizualizacija
Najočiglednija i najrazumljivija stvar za koju je ELK Stack potreban je skladištenje i vizualizacija dnevnika, prikazano je kako možete kreirati dnevnike sa raznih uređaja koristeći Logstash. Nakon što logovi odu u Elasticsearch, možete postaviti nadzorne ploče, koje su također spomenute , sa informacijama i statistikom koja vam je potrebna kroz vizualizaciju.
primjeri:
- Kontrolna tabla za događaje prevencije prijetnji s najkritičnijim događajima. Ovdje možete prikazati koji su IPS potpisi otkriveni i odakle dolaze geografski.
- Kontrolna tabla o korištenju najkritičnijih aplikacija za koje informacije mogu procuriti.
- Rezultati skeniranja sa bilo kojeg sigurnosnog skenera.
- Dnevnici iz Active Directory po korisniku.
- Kontrolna tabla za VPN vezu.
U ovom slučaju, ako konfigurirate kontrolne ploče da se ažuriraju svakih nekoliko sekundi, možete dobiti prilično zgodan sistem za praćenje događaja u realnom vremenu, koji se onda može koristiti za najbrži odgovor na incidente sigurnosti informacija ako kontrolne ploče postavite na zaseban ekran.
Određivanje prioriteta incidenta
U uslovima velike infrastrukture, broj incidenata može prevazići razmere, a stručnjaci neće imati vremena da se pozabave svim incidentima na vreme. U ovom slučaju potrebno je, prije svega, istaknuti samo one incidente koji predstavljaju veliku prijetnju. Stoga, sistem mora dati prioritet incidentima na osnovu njihove ozbiljnosti u odnosu na vašu infrastrukturu. Preporučljivo je postaviti upozorenje putem e-pošte ili telegrama za ove događaje. Određivanje prioriteta se može implementirati pomoću standardnih Kibana alata postavljanjem vizualizacije. Ali s obavijestima je teže; prema zadanim postavkama, ova funkcionalnost nije uključena u osnovnu verziju Elasticsearch-a, već samo u plaćenu verziju. Stoga, ili kupite plaćenu verziju, ili, opet, sami napišite proces koji će obavijestiti stručnjake u stvarnom vremenu putem e-pošte ili telegrama.
Automatizacija procesa informacione sigurnosti
A jedan od najzanimljivijih dijelova je automatizacija akcija za incidente informacione sigurnosti. Ranije smo implementirali ovu funkcionalnost za Splunk, možete pročitati malo više u ovome . Glavna ideja je da se IPS politika nikada ne testira ili optimizuje, iako je u nekim slučajevima kritičan dio procesa informacione sigurnosti. Na primjer, godinu dana nakon implementacije NGFW-a i izostanka radnji za optimizaciju IPS-a, skupit ćete veliki broj potpisa sa akcijom Detect, koji neće biti blokirani, što uvelike smanjuje stanje informacione sigurnosti u organizaciji. Ispod su neki primjeri onoga što se može automatizirati:
- Prijenos IPS potpisa sa Detect na Prevent. Ako Prevent ne radi za kritične potpise, to je u kvaru i predstavlja ozbiljan jaz u sistemu zaštite. Mijenjamo radnju u politici na takve potpise. Ova funkcionalnost se može implementirati ako NGFW uređaj ima REST API funkcionalnost. Ovo je moguće samo ako imate vještine programiranja; potrebno je izvući potrebne informacije iz Elastcisearch-a i uputiti API zahtjeve NGFW serveru za upravljanje.
- Ako je više potpisa otkriveno ili blokirano u mrežnom prometu sa jedne IP adrese, onda ima smisla blokirati ovu IP adresu na neko vrijeme u politici zaštitnog zida. Implementacija se također sastoji od korištenja REST API-ja.
- Pokrenite skeniranje hosta sa skenerom ranjivosti, ako ovaj host ima veliki broj IPS potpisa ili drugih sigurnosnih alata; ako je to OpenVas, onda možete napisati skriptu koja će se povezati preko ssh-a sa sigurnosnim skenerom i pokrenuti skeniranje.
TS Total Sight
Sve u svemu, implementacija svih funkcionalnosti je veoma veliki i težak zadatak. Bez znanja programiranja, možete konfigurirati minimalnu funkcionalnost, koja može biti dovoljna za korištenje u proizvodnji. Ali ako vas zanima sve funkcionalnosti, možete obratiti pažnju na TS Total Sight. Više detalja možete pronaći na našoj stranici . Kao rezultat, cijela shema rada i arhitektura će izgledati ovako:
zaključak
Pogledali smo šta se može implementirati koristeći ELK Stack. U narednim člancima ćemo posebno detaljnije razmotriti funkcionalnost TS Total Sight!
Zato ostanite sa nama (, , , ), .
izvor: www.habr.com