Kada je u pitanju praćenje sigurnosti interne korporativne ili mreže odjela, mnogi ga povezuju s kontrolom curenja informacija i implementacijom DLP rješenja. A ako pokušate da precizirate pitanje i pitate kako detektujete napade na internu mrežu, onda će odgovor obično biti pominjanje sistema za otkrivanje upada (IDS). A ono što je bila jedina opcija prije 10-20 godina danas postaje anahronizam. Postoji efikasnija, a na nekim mjestima i jedina moguća opcija za praćenje interne mreže - korištenje protokola protoka, prvobitno dizajniranih za traženje mrežnih problema (otklanjanje problema), ali s vremenom pretvorenih u vrlo zanimljiv sigurnosni alat. Ovdje ćemo govoriti o tome koji su protokoli protoka i koji pomažu da se bolje otkriju mrežni napadi, gdje je najbolje implementirati praćenje toka, na šta treba obratiti pažnju prilikom implementacije takve sheme, pa čak i kako to sve "podići" na domaću opremu , razgovaraćemo u okviru ovog članka.
Neću se zadržavati na pitanju „Zašto trebamo pratiti sigurnost interne infrastrukture?“ Odgovor na to je nekako očigledan. Ali ako se ipak želite još jednom uvjeriti da danas ne možete bez toga, kratak video sa pričom o tome kako možete ući u korporativnu mrežu zaštićenu firewall-om na 17 načina. Stoga ćemo pretpostaviti da razumijemo da je interni monitoring neophodna stvar i ostaje samo razumjeti kako se može organizirati.
Izdvojio bih tri ključna izvora podataka za praćenje infrastrukture na nivou mreže:
- “sirov” promet koji hvatamo i predajemo na analizu nekim sistemima za analizu,
- događaji sa mrežnih uređaja kroz koje prolazi saobraćaj,
- informacije o prometu primljene putem jednog od protokola protoka.
Snimanje sirovog saobraćaja je najpopularnija opcija među ljudima iz obezbeđenja, jer se istorijski pojavila i bila prva. Konvencionalni sistemi za otkrivanje upada u mrežu (prvi komercijalni sistem za otkrivanje upada bio je NetRanger iz Wheel Group, koji je 1998. godine kupio Cisco) upravo su bili angažovani na hvatanju paketa (i kasnijih sesija) u kojima su traženi određeni potpisi („odlučujuća pravila“ u terminologija FSTEC), signaliziranje napada. Naravno, možete analizirati sirovi promet ne samo pomoću IDS-a, već i drugih alata (na primjer, Wireshark, tcpdum ili NBAR2 funkcionalnost u Cisco IOS), ali im obično nedostaje baza znanja koja razlikuje alat za sigurnost informacija od običan IT alat.
Dakle, sistemi za otkrivanje upada. Najstarija i najpopularnija metoda za otkrivanje mrežnih napada, koja dobro radi na perimetru (bez obzira na sve - korporativni, data centar, segment, itd.), ali ne uspijeva u modernim komutiranim i softverski definiranim mrežama. U slučaju mreže izgrađene na bazi konvencionalnih prekidača, infrastruktura senzora za otkrivanje upada postaje prevelika – morat ćete staviti senzor na svaku konekciju s hostom na koju želite da nadgledate napade. Svaki proizvođač će vam, naravno, rado prodati stotine i hiljade senzora, ali mislim da vaš budžet ne može izdržati takve troškove. Mogu reći da ni u Cisco-u (a mi smo programeri NGIPS-a) to nismo mogli učiniti, iako je, čini se, pitanje cijene pred nama. ne treba stajati - to je naša vlastita odluka. Osim toga, postavlja se pitanje kako spojiti senzor u ovoj verziji? U prazninu? Šta ako sam senzor pokvari? Zahtijevate bypass modul u senzoru? Koristiti razdjelnike (tap)? Sve to povećava cijenu rješenja i čini ga nedostupnim za kompaniju bilo koje veličine.
Možete pokušati "okačiti" senzor na SPAN/RSPAN/ERSPAN port i usmjeriti promet na njega sa potrebnih portova prekidača. Ova opcija djelimično uklanja problem opisan u prethodnom paragrafu, ali postavlja još jedan - SPAN port ne može primiti apsolutno sav promet koji će mu biti poslan - neće imati dovoljno propusnog opsega. Spremni da žrtvuju nešto. Ili ostavite neke od čvorova bez nadzora (onda im prvo morate odrediti prioritet), ili pošaljite ne sav promet s čvora, već samo određeni tip. U svakom slučaju, možemo propustiti neke napade. Osim toga, SPAN port se može zauzeti za druge potrebe. Kao rezultat toga, morat ćemo pregledati postojeću topologiju mreže i eventualno je prilagoditi kako bismo maksimalno pokrili vašu mrežu brojem senzora koje imate (i to koordinirati s IT-om).
Što ako vaša mreža koristi asimetrične rute? A ako ste implementirali ili planirate implementirati SDN? Ali šta ako trebate da nadgledate virtuelizovane mašine ili kontejnere čiji saobraćaj uopšte ne stiže do fizičkog prekidača? Ovo su pitanja koja tradicionalni IDS dobavljači ne vole jer ne znaju kako da odgovore na njih. Možda će vas uvjeriti da su sve te moderne tehnologije hype i da vam ne trebaju. Možda će razgovarati o potrebi da se počne sa malim. Ili će možda reći da morate postaviti moćnu vršalicu u centar mreže i usmjeriti sav promet na nju pomoću balansera opterećenja. Koja god opcija da vam se ponudi, sami morate jasno shvatiti kako vam ona odgovara. I tek nakon toga donijeti odluku o izboru pristupa praćenju sigurnosti informacija mrežne infrastrukture. Vraćajući se na hvatanje paketa, želim da kažem da je ova metoda i dalje veoma popularna i važna, ali njena glavna svrha je kontrola granica; granice između vaše organizacije i Interneta, granice između data centra i ostatka mreže, granice između sistema kontrole procesa i korporativnog segmenta. Na ovim mjestima klasični IDS/IPS i dalje imaju pravo na postojanje i dobro obavljaju svoje zadatke.
Pređimo na drugu opciju. Analiza događaja koji dolaze od mrežnih uređaja također se može koristiti u svrhu otkrivanja upada, ali ne kao glavni mehanizam, jer otkriva samo malu klasu upada. Osim toga, njemu je svojstvena određena reaktivnost - prvo se mora dogoditi napad, a zatim ga mora popraviti mrežni uređaj, koji će na ovaj ili onaj način signalizirati problem sa sigurnošću informacija. Postoji nekoliko takvih metoda. To može biti syslog, RMON ili SNMP. Posljednja dva protokola za praćenje mreže u kontekstu informacione sigurnosti koristimo se samo ako trebamo otkriti DoS napad na samu mrežnu opremu, jer korištenjem RMON i SNMP možete npr. pratiti opterećenje centralnog procesora uređaja ili njegove interfejse. Ovo je jedan od „najjeftinijih“ (svi imaju syslog ili SNMP), ali i najneefikasniji od svih načina praćenja sigurnosti informacija interne infrastrukture – mnogi napadi su jednostavno skriveni od njega. Naravno, ne treba ih zanemariti, a ista syslog analiza pomaže vam da na vrijeme prepoznate promjene u konfiguraciji samog uređaja, kompromitirajući ga, ali nije baš pogodna za otkrivanje napada na cijelu mrežu.
Treća opcija je analiza informacija o prometu koji prolazi kroz uređaj koji podržava jedan od nekoliko protokola protoka. U ovom slučaju, bez obzira na protokol, streaming infrastruktura se nužno sastoji od tri komponente:
- Tok generiranja ili izvoza. Ova uloga se obično dodjeljuje ruteru, prekidaču ili drugom mrežnom uređaju, koji, propuštajući mrežni promet kroz sebe, omogućava da iz njega izvučete ključne parametre, koji se zatim prenose modulu za prikupljanje. Na primjer, Ciscoov Netflow protokol je podržan ne samo na ruterima i prekidačima, uključujući virtuelne i industrijske, već i na bežičnim kontrolerima, zaštitnim zidovima, pa čak i serverima.
- Tok prikupljanja. S obzirom na to da u modernoj mreži obično postoji više od jednog mrežnog uređaja, javlja se problem prikupljanja i konsolidacije tokova, koji se rješava uz pomoć tzv. kolektora koji obrađuju primljene tokove i potom ih šalju na analizu.
- analiza protoka. Analizator preuzima glavni intelektualni zadatak i, primjenjujući različite algoritme na tokove, izvodi određene zaključke. Na primjer, unutar IT funkcije, takav analizator može identificirati uska grla u mreži ili analizirati profil opterećenja prometa kako bi dalje optimizirao mrežu. A za sigurnost informacija, takav analizator može otkriti curenje podataka, širenje zlonamjernog koda ili DoS napade.
Nemojte misliti da je takva troslojna arhitektura previše komplikovana - sve druge opcije (sa mogućim izuzetkom sistema za praćenje mreže koji rade sa SNMP-om i RMON-om) također rade prema njoj. Imamo generator podataka za analizu, koji je mrežni uređaj ili samostalni senzor. Imamo sistem prikupljanja alarma i imamo sistem upravljanja za cjelokupnu infrastrukturu za nadzor. Posljednje dvije komponente mogu se kombinirati unutar jednog čvora, ali u manje-više velikim mrežama obično su raspoređene na najmanje dva uređaja kako bi se osigurala skalabilnost i pouzdanost.
Za razliku od analize paketa, koja se zasniva na proučavanju zaglavlja i tijela podataka svakog paketa i sesija koje se od njih sastoje, analiza toka se oslanja na prikupljanje metapodataka o mrežnom prometu. Kada, koliko, odakle i gdje, kako... to su pitanja na koja analiza mrežne telemetrije daje odgovore koristeći različite protokole protoka. U početku su korišćeni za analizu statistike i traženje IT problema u mreži, ali je potom, razvojem analitičkih mehanizama, postalo moguće primeniti ih na istu telemetriju u bezbednosne svrhe. Ovdje je vrijedno ponoviti da analiza toka ne zamjenjuje niti zamjenjuje hvatanje paketa. Svaka od ovih metoda ima svoj opseg. Ali u kontekstu ovog članka, analiza toka je ta koja je najprikladnija za praćenje interne infrastrukture. Imate mrežne uređaje (bilo da rade u softverski definiranoj paradigmi ili prema statičkim pravilima) koje napad ne može zaobići. Može zaobići klasični IDS senzor, ali ne i mrežni uređaj koji podržava protokol protoka. Ovo je prednost ove metode.
S druge strane, ako vam je potrebna baza dokaza za provođenje zakona ili vaš vlastiti tim za istragu incidenta, ne možete bez hvatanja paketa – mrežna telemetrija nije kopija saobraćaja koja se može koristiti za prikupljanje dokaza; potrebno je za brzo otkrivanje i donošenje odluka u oblasti informacione bezbednosti. S druge strane, pomoću telemetrijske analize možete „upisati“ ne sav mrežni saobraćaj (ako ništa drugo, Cisco je uključen i u data centre :-), već samo onaj koji je uključen u napad. Alati za telemetrijsku analizu u ovom pogledu će dobro nadopuniti tradicionalne mehanizme hvatanja paketa, dajući naredbu za selektivno hvatanje i skladištenje. U suprotnom, moraćete da imate kolosalnu infrastrukturu za skladištenje.
Zamislite mrežu koja radi na 250 Mbps. Ako želite da sačuvate sav ovaj volumen, onda će vam trebati 31 MB prostora za skladištenje za jednu sekundu prenosa saobraćaja, 1,8 GB za jedan minut, 108 GB za jedan sat i 2,6 TB za jedan dan. Za pohranjivanje dnevnih podataka iz mreže sa propusnim opsegom od 10 Gb/s, trebat će vam 108 TB prostora za pohranu. Ali neki regulatori zahtijevaju da sigurnosne podatke pohranjujete godinama... Snimanje na zahtjev te analize protoka pomaže vam da smanjite ove vrijednosti na red veličine. Usput, ako govorimo o omjeru volumena snimljenih podataka mrežne telemetrije i potpunog hvatanja podataka, onda je to otprilike 1 prema 500. Za iste vrijednosti gore navedene, pohrana potpune dešifriranja ukupnog dnevnog prometa će biti 5 odnosno 216 GB (možete čak i pisati na običan fleš disk).
Ako je metoda hvatanja sirovih mrežnih podataka za alate za analizu gotovo ista od dobavljača do dobavljača, onda je u slučaju analize toka situacija drugačija. Postoji nekoliko varijanti protokola protoka, razlike u kojima morate znati u kontekstu sigurnosti. Najpopularniji je protokol Netflow koji je razvio Cisco. Postoji nekoliko verzija ovog protokola koje se razlikuju po svojim mogućnostima i količini zabilježenih informacija o prometu. Trenutna verzija je deveta (Netflow v9), iz koje je razvijen industrijski standard Netflow v10, također poznat kao IPFIX. Danas većina dobavljača mreže podržava Netflow ili IPFIX u svojoj opremi. Ali postoje razne druge varijante protokola protoka - sFlow, jFlow, cFlow, rFlow, NetStream, itd., od kojih je sFlow najpopularniji. Upravo njega najčešće podržavaju domaći proizvođači mrežne opreme zbog jednostavnosti implementacije. Koje su ključne razlike između Netflowa, kao de facto standarda, i istog sFlowa? Istaknuo bih nekoliko ključnih. Prvo, Netflow ima polja koja mogu konfigurirati korisnik za razliku od fiksnih polja u sFlowu. I drugo, a to je najvažnija stvar u našem slučaju, sFlow prikuplja takozvanu uzorkovanu telemetriju; za razliku od neuzorkovanog Netflowa i IPFIX-a. Koja je razlika između njih?
Zamislite da odlučite da pročitate knjigu “” moje kolege Gary McIntyre, Joseph Munitz i Nadem Alfardan (dio knjige možete preuzeti sa linka). Imate tri opcije da postignete svoj cilj - pročitajte knjigu u cijelosti, prelistajte je, zaustavljajući se na svakoj 10. ili 20. stranici ili pokušajte pronaći prepričavanje ključnih koncepata na blogu ili servisu poput SmartReadinga. Dakle, neuzorkovana telemetrija je čitanje svake „stranice“ mrežnog saobraćaja, odnosno analiza metapodataka za svaki paket. Uzorkovana telemetrija je selektivna studija prometa u nadi da će odabrani uzorci biti ono što vam treba. Ovisno o brzini kanala, uzorkovana telemetrija će poslati svaki 64., 200., 500., 1000., 2000. ili čak 10000. paket na analizu.
U kontekstu nadzora sigurnosti informacija, to znači da je uzorkovana telemetrija vrlo pogodna za otkrivanje DDoS napada, skeniranje, širenje zlonamjernog koda, ali može propustiti atomske ili višepaketne napade koji nisu uključeni u uzorak poslan na analizu. Ni nepometena telemetrija nema takvih nedostataka. korištenje raspona otkrivenih napada je mnogo šire. Evo male liste događaja koji se mogu otkriti pomoću alata za analizu mrežne telemetrije.
Naravno, neki open-source Netflow analizator vam to neće dozvoliti, jer je njegov glavni zadatak da prikupi telemetriju i izvrši osnovnu analizu na njoj sa IT tačke gledišta. Za identifikaciju prijetnji IS-a na osnovu protoka, potrebno je opremiti analizator različitim motorima i algoritmima, koji će identificirati probleme cyber sigurnosti na osnovu standardnih ili prilagođenih Netflow polja, obogatiti standardne podatke vanjskim podacima iz različitih izvora Threat Intelligence, itd.
Stoga, ako imate izbora, zaustavite ga na Netflow ili IPFIX. Ali čak i ako vaša oprema radi samo sa sFlowom, kao kod domaćih proizvođača, onda čak iu ovom slučaju možete imati koristi od toga u kontekstu sigurnosti.
U ljeto 2019. analizirao sam mogućnosti koje imaju ruski proizvođači mrežnog željeza i svi su, izuzev NSG, Polygon i Craftway, najavili podršku za sFlow (barem Zelaks, Natex, Eltex, QTech, Rusteletech).
Sljedeće pitanje koje će se pojaviti pred vama je gdje implementirati podršku protoka u svrhu sigurnosti? Zapravo, pitanje nije sasvim ispravno postavljeno. Na modernoj opremi, protokoli protoka su gotovo uvijek podržani. Stoga bih drugačije formulisao pitanje – gdje je najefikasniji način prikupljanja telemetrije sa sigurnosne tačke gledišta? Odgovor će biti sasvim očigledan - na nivou pristupa, gde ćete videti 100% celokupnog saobraćaja, gde ćete imati detaljne informacije o hostovima (MAC, VLAN, ID interfejsa), gde možete pratiti čak i P2P saobraćaj između hostova, koji je ključno za otkrivanje skeniranja i distribuciju zlonamjernog koda. Na nivou jezgre, možda jednostavno nećete vidjeti dio saobraćaja, ali na nivou perimetra ćete dobro vidjeti četvrtinu vašeg mrežnog prometa. Ali ako iz nekog razloga imate vanjske uređaje na vašoj mreži koji dozvoljavaju napadačima da "uđu i izađu" zaobilazeći perimetar, onda vam analiza telemetrije iz nje neće dati ništa. Stoga, za maksimalnu pokrivenost, preporučljivo je omogućiti prikupljanje telemetrije na nivou pristupa. Istovremeno, vrijedi napomenuti da čak i ako govorimo o virtualizaciji ili kontejnerima, moderni virtualni prekidači također često podržavaju protok, što vam omogućava da i tamo kontrolirate promet.
Ali pošto sam pokrenuo temu, onda moram da odgovorim na pitanje, šta ako, ipak, oprema, fizička ili virtuelna, ne podržava protokole protoka? Ili je njegovo uključivanje zabranjeno (na primjer, u industrijske segmente kako bi se osigurala pouzdanost)? Ili njegovo uključivanje uzrokuje veliku upotrebu CPU-a (ovo se događa na starijem hardveru)? Za rješavanje ovog problema postoje specijalizirani virtualni senzori (flow sensor), koji su u suštini obični razdjelnici koji propuštaju promet kroz sebe i emituju ga u obliku toka do modula za prikupljanje. Istina, u ovom slučaju dobijamo čitavu gomilu problema o kojima smo gore govorili u vezi sa alatima za hvatanje paketa. Odnosno, potrebno je razumjeti ne samo prednosti tehnologije analize protoka, već i njena ograničenja.
Još jedna stvar koju je važno zapamtiti kada govorimo o alatima za analizu protoka. Ako primenimo metriku EPS (događaj u sekundi, događaj u sekundi) u odnosu na uobičajena sredstva za generisanje bezbednosnih događaja, onda ovaj indikator nije primenljiv na telemetrijsku analizu; zamjenjuje se sa FPS (protok u sekundi, protok u sekundi). Kao iu slučaju EPS-a, ne može se unaprijed izračunati, ali je moguće procijeniti približan broj niti koje određeni uređaj generiše u zavisnosti od njegovog zadatka. Na internetu možete pronaći tabele sa približnim vrijednostima zajoza različite tipovenauredaiiними uvjetima mogu vam omogućiti da procijenite koje su vam licence potrebne za alate za analizu i kakva će biti njihova arhitektura? Činjenica je da je IDS senzor ograničen na određeni propusni opseg, koji će "izvući", a kolektor protoka ima svoja ograničenja koja se moraju razumjeti. Stoga, u velikim, geografski raspoređenim mrežama, obično postoji nekoliko kolektora. Kada sam opisao , već sam naveo broj naših sakupljača - ima ih 21. I to za mrežu raštrkanu na pet kontinenata i koja broji oko pola miliona aktivnih uređaja).
Koristimo vlastito rješenje kao Netflow monitoring sistem , koja je posebno usmjerena na rješavanje sigurnosnih problema. Ima mnogo ugrađenih mehanizama za otkrivanje anomalnih, sumnjivih i očigledno zlonamjernih aktivnosti, što vam omogućava da otkrijete širok spektar različitih prijetnji - od kriptominiranja do curenja informacija, od distribucije zlonamjernog koda do prijevare. Kao i većina analizatora protoka, Stealthwatch je izgrađen na tri nivoa (generator - kolektor - analizator), ali je dopunjen nizom zanimljivih karakteristika koje su važne u kontekstu materijala koji se razmatra. Prvo, integriše se sa rešenjima za hvatanje paketa (kao što je Cisco Security Packet Analyzer), što vam omogućava da snimite odabrane mrežne sesije za kasniju dubinsku istragu i analizu. Drugo, posebno za proširenje sigurnosnih zadataka, razvili smo poseban nvzFlow protokol koji vam omogućava da “emitujete” aktivnost aplikacije na krajnjim čvorovima (serverima, radnim stanicama, itd.) u telemetriju i prenesete je u kolektor za dalju analizu. Ako u svojoj originalnoj verziji Stealthwatch radi sa bilo kojim protokolom protoka (sFlow, rFlow, Netflow, IPFIX, cFlow, jFlow, NetStream) na nivou mreže, tada podrška za nvzFlow omogućava korelaciju podataka i na nivou čvora, na taj način. poboljšanje ukupne efikasnosti sistema i uočavanje više napada od konvencionalnih analizatora protoka mreže.
Jasno je da kada se govori o sistemima za analizu Netflow sa sigurnosne tačke gledišta, tržište nije ograničeno na jedno rešenje kompanije Cisco. Možete koristiti i komercijalna i besplatna ili shareware rješenja. Prilično je čudno ako citiram rješenja konkurenata na Cisco blogu, pa ću reći nekoliko riječi o tome kako se mrežna telemetrija može analizirati pomoću dva popularna, slična po imenu, ali ipak različita alata - SiLK i ELK.
SiLK je skup alata (Sistem znanja na nivou Interneta) za analizu saobraćaja koji je razvio američki CERT/CC i koji podržava, u kontekstu današnjeg članka, Netflow (5. i 9., najpopularnije verzije), IPFIX i sFlow i korištenjem raznih uslužnih programa (rwfilter, rwcount, rwflowpack, itd.) za izvođenje različitih operacija na mrežnoj telemetriji kako bi se otkrili znakovi neovlaštenih radnji u njoj. Ali treba napomenuti nekoliko važnih stvari. SiLK je alat za komandnu liniju i vrši online analizu, sve dok kucate naredbu u obliku (otkrivanje ICMP paketa većih od 200 bajtova):
rwfilter --flowtypes=all/all --proto=1 --bytes-per-packet=200- --pass=stdout | rwrwcut --fields=sIP,dIP,iType,iCode --num-recs=15
nije baš udobno. Možete koristiti iSiLK GUI, ali on vam neće mnogo olakšati život tako što ćete riješiti samo funkciju vizualizacije, a ne zamjenu analitičara. A ovo je druga tačka. Za razliku od komercijalnih rješenja, koja već imaju solidnu analitičku osnovu, algoritme za otkrivanje anomalija koje odgovaraju toku rada itd., u slučaju SiLK-a, sve ćete to morati učiniti sami, što će od vas zahtijevati nešto drugačije kompetencije od korištenja već spremnih -to-use toolkit. Ovo nije dobro i nije loše – ovo je karakteristika gotovo svakog besplatnog alata koja proizlazi iz činjenice da znate što trebate učiniti, a samo će vam pomoći u tome (komercijalni alati manje ovise o kompetencijama svojih korisnika, iako također pretpostavlja da analitičari razumiju barem osnove provođenja mrežnih istraživanja i praćenja). Ali vratimo se na SiLK. Radni ciklus analitičara s njim je sljedeći:
- Formulisanje hipoteze. Moramo razumjeti šta ćemo tražiti unutar mrežne telemetrije, znati jedinstvene atribute po kojima ćemo identificirati određene anomalije ili prijetnje.
- Izgradnja modela. Nakon što smo formulirali hipotezu, programiramo je koristeći isti Python, shell ili druge alate koji nisu uključeni u SiLK.
- Testiranje. Vrijeme je da provjerimo ispravnost naše hipoteze, koja je potvrđena ili opovrgnuta korištenjem SiLK uslužnih programa počevši od 'rw', 'set', 'bag'.
- Analiza stvarnih podataka. U komercijalnom poslovanju, SiLK nam pomaže da nešto identificiramo i analitičar mora odgovoriti na pitanja “Jesmo li pronašli ono što smo očekivali?”, “Da li ovo odgovara našoj hipotezi?”, “Kako će smanjiti broj lažnih pozitivnih rezultata?”, „Kako poboljšati nivo prepoznavanja?» i tako dalje.
- Poboljšanje. U završnoj fazi poboljšavamo ono što je ranije urađeno - kreiramo šablone, poboljšavamo i optimiziramo kod, preformulišemo i preciziramo hipotezu itd.
Ovaj ciklus će biti primenljiv na isti Cisco Stealthwatch, samo poslednjih pet koraka se automatizuju do maksimuma, smanjujući broj grešaka analitičara i povećavajući efikasnost detekcije incidenata. Na primjer, u SiLK-u možete obogatiti mrežnu statistiku vanjskim podacima o zlonamjernim IP adresama koristeći vlastite skripte, a u Cisco Stealthwatchu, ovo je ugrađena funkcija koja vam odmah prikazuje alarm ako dođe do interakcije sa IP adresama na crnoj listi u mreži. saobraćaja.
Ako se popnete na piramidu "plaćenog" softvera za analizu protoka, onda će apsolutno besplatan SiLK biti praćen shareware ELK, koji se sastoji od tri ključne komponente - Elasticsearch (indeksiranje, pretraživanje i analiza podataka), Logstash (unos / izlaz podataka ) i Kibana (vizuelizacija). Za razliku od SiLK-a, gdje sve morate sami napisati, ELK već ima mnogo gotovih biblioteka/modula (neke su plaćene, neke nisu) koje automatiziraju analizu mrežne telemetrije. Na primjer, GeoIP filter u Logstash-u omogućava vam da povežete nadgledane IP adrese za njihovu geografsku lokaciju (isti Stealthwatch ima ovu ugrađenu funkciju).
ELK također ima prilično veliku zajednicu koja dodaje komponente koje nedostaju ovom rješenju za praćenje. Na primjer, za rad sa Netflow, IPFIX i sFlow možete koristiti modul ako niste zadovoljni Logstash Netflow modulom koji podržava samo Netflow.
Dajući veću efikasnost u prikupljanju toka i pretraživanju u njemu, ELK trenutno nema bogatu ugrađenu analitiku za otkrivanje anomalija i prijetnji u mrežnoj telemetriji. Odnosno, nakon gore opisanog životnog ciklusa, morat ćete samostalno opisati modele kršenja, a zatim ih koristiti u borbenom sistemu (nema ugrađenih modela).
Naravno, postoje i sofisticiranija proširenja za ELK, koja već sadrže neke modele za otkrivanje anomalija u mrežnoj telemetriji, ali takva proširenja koštaju i pitanje je da li je igra vrijedna svijeće - sami napišite sličan model, kupite njegovu implementaciju za vaš alat za praćenje ili kupite rješenje po principu "ključ u ruke" klase Network Traffic Analysis.
Općenito, ne želim ulaziti u polemiku oko toga da li je bolje potrošiti novac i kupiti gotovo rješenje za praćenje anomalija i prijetnji u mrežnoj telemetriji (na primjer, Cisco Stealthwatch) ili ga sami shvatiti i podesiti isti SiLK, ELK ili nfdump ili OSU Flow Tools za svaku novu prijetnju (govorim o posljednje dvije od njih zadnji put)? Svako bira za sebe i svako ima svoje motive da izabere bilo koju od dve opcije. Hteo sam samo da pokažem da je mrežna telemetrija veoma važan alat u obezbeđivanju mrežne bezbednosti vaše interne infrastrukture i da je ne treba zanemariti, kako ne biste na listu dodali kompaniju čije se ime u medijima pominje uz epitete “hakovani”, “neusklađeni sa zahtjevima sigurnosti informacija”, ne razmišljajući o sigurnosti svojih podataka i podataka o klijentima.
Sumirajući, želio bih navesti ključne savjete koje biste trebali slijediti kada gradite nadzor sigurnosti informacija vaše interne infrastrukture:
- Nemojte se ograničavati samo na perimetar! Koristite (i birajte) mrežnu infrastrukturu ne samo za prijenos prometa od tačke A do tačke B, već i za rješavanje problema kibernetičke sigurnosti.
- Proučite postojeće mehanizme nadzora sigurnosti informacija u vašoj mrežnoj opremi i koristite ih.
- Za interni nadzor, dajte prednost telemetrijskoj analizi - ona vam omogućava da otkrijete do 80-90% svih incidenata u vezi sa sigurnošću mrežnih informacija, dok radite ono što je nemoguće kada hvatate mrežne pakete i štedite prostor za skladištenje za sve događaje bezbednosti informacija.
- Za praćenje tokova koristite Netflow v9 ili IPFIX - oni daju više informacija u kontekstu sigurnosti i omogućavaju vam da nadgledate ne samo IPv4, već i IPv6, MPLS, itd.
- Koristite neuzorkovani protokol toka - on pruža više informacija za otkrivanje prijetnji. Na primjer, Netflow ili IPFIX.
- Provjerite opterećenje vaše mrežne opreme - možda neće moći podnijeti i obradu protokola protoka. Zatim razmislite o korištenju virtualnih senzora ili uređaja za generiranje Netflow.
- Implementirajte kontrolu na prvom mjestu na nivou pristupa - ovo će vam dati priliku da vidite 100% cjelokupnog prometa.
- Ako nemate izbora i koristite rusku mrežnu opremu, odaberite onu koja podržava protokole protoka ili ima SPAN / RSPAN portove.
- Kombinujte otkrivanje upada/napada/prevenciju na granicama i sisteme za analizu protoka u internoj mreži (uključujući u oblacima).
Što se tiče posljednjeg savjeta, želio bih dati ilustraciju koju sam već dao. Možete vidjeti da ako je ranije Cisco IS servis gotovo u potpunosti izgradio svoj sistem za praćenje IS-a zasnovan na sistemima za otkrivanje upada i metodama potpisa, sada oni čine samo 20% incidenata. Još 20% otpada na sisteme analize toka, što sugeriše da ova rješenja nisu hir, već pravi alat u aktivnostima službi informacione sigurnosti savremenog preduzeća. Štaviše, imate ono najvažnije za njihovu implementaciju - mrežnu infrastrukturu, ulaganja u koju se mogu dodatno zaštititi dodjeljivanjem funkcija nadzora sigurnosti informacija mreži.
Namerno se nisam dotakao teme reagovanja na anomalije ili pretnje koje se identifikuju u mrežnim tokovima, ali mislim da je jasno da monitoring ne treba da se završava samo otkrivanjem pretnje. Trebalo bi da bude praćeno odgovorom i po mogućnosti u automatskom ili automatizovanom režimu. Ali ovo je tema za poseban članak.
Dodatne informacije:
PS. Ako vam je lakše slušati sve što je gore napisano, onda možete pogledati jednosatnu prezentaciju koja je bila osnova ove bilješke.
izvor: www.habr.com