Kada je riječ o nadzoru sigurnosti unutarnje korporativne ili odjelske mreže, mnogi ga povezuju s kontrolom curenja informacija i implementacijom DLP rješenja. A ako pokušate razjasniti pitanje i pitati kako otkrivate napade na internu mrežu, tada će odgovor u pravilu biti spominjanje sustava za otkrivanje upada (IDS). I ono što je prije 10-20 godina bila jedina opcija, danas postaje anakronizam. Postoji učinkovitija, a ponegdje i jedina moguća opcija za nadzor interne mreže - korištenje protokola protoka, koji su izvorno bili dizajnirani za traženje mrežnih problema (troubleshooting), ali su se s vremenom transformirali u vrlo zanimljiv sigurnosni alat. Razgovarat ćemo o tome koji protokoli protoka postoje i koji su bolji u otkrivanju mrežnih napada, gdje je najbolje implementirati nadzor protoka, na što treba obratiti pozornost pri implementaciji takve sheme, pa čak i kako sve to "podići" na domaćoj opremi u okviru ovog članka.
Neću se zadržavati na pitanju "Zašto je potreban nadzor sigurnosti unutarnje infrastrukture?" Čini se da je odgovor jasan. Ali ako se ipak želite još jednom uvjeriti da danas ne možete bez njega, kratki video o tome kako možete prodrijeti u korporativnu mrežu zaštićenu vatrozidom na 17 načina. Stoga ćemo pretpostaviti da razumijemo da je interni nadzor nužna stvar i preostaje samo razumjeti kako se on može organizirati.
Istaknuo bih tri ključna izvora podataka za praćenje infrastrukture na mrežnoj razini:
- “sirov” promet koji hvatamo i predajemo na analizu određenim sustavima za analizu,
- događaje s mrežnih uređaja kroz koje prolazi promet,
- informacije o prometu primljene preko jednog od protokola protoka.
Hvatanje sirovog prometa najpopularnija je opcija među sigurnosnim stručnjacima, jer se povijesno pojavila i bila prva. Konvencionalni sustavi za detekciju upada u mrežu (prvi komercijalni sustav za detekciju upada bio je NetRanger od Wheel Group, koji je 1998. kupio Cisco) bavili su se upravo hvatanjem paketa (i kasnijih sesija) u kojima su se tražili određeni potpisi ("odlučujuća pravila" u FSTEC terminologija), signalizacija napada. Naravno, sirovi promet možete analizirati ne samo pomoću IDS-a, već i pomoću drugih alata (na primjer, Wireshark, tcpdum ili funkcionalnost NBAR2 u Cisco IOS-u), ali njima obično nedostaje baza znanja koja razlikuje alat za informacijsku sigurnost od običnog IT alat.
Dakle, sustavi za detekciju napada. Najstarija i najpopularnija metoda otkrivanja mrežnih napada, koja dobro obavlja svoj posao na perimetru (bez obzira na bilo koji - korporativni, podatkovni centar, segment itd.), ali ne uspijeva u modernim komutiranim i softverski definiranim mrežama. U slučaju mreže izgrađene na temelju konvencionalnih preklopnika, infrastruktura senzora za detekciju napada postaje prevelika - morat ćete instalirati senzor na svaku vezu s čvorom na kojem želite pratiti napade. Bilo koji proizvođač, naravno, rado će vam prodati stotine i tisuće senzora, ali mislim da vaš proračun ne može podnijeti takve troškove. Mogu reći da čak ni u Ciscu (a mi smo programeri NGIPS-a) to nismo mogli učiniti, iako se čini da je pitanje cijene pred nama. Ne bih trebao stajati - to je naša vlastita odluka. Osim toga, postavlja se pitanje kako spojiti senzor u ovoj verziji? U prazninu? Što ako sam senzor pokvari? Potreban vam je modul premosnice u senzoru? Koristiti razdjelnike (tap)? Sve to poskupljuje rješenje i čini ga nedostupnim tvrtki bilo koje veličine.
Možete pokušati "objesiti" senzor na SPAN/RSPAN/ERSPAN port i usmjeriti promet sa potrebnih portova prekidača na njega. Ova opcija djelomično uklanja problem opisan u prethodnom odlomku, ali postavlja još jedan - SPAN port ne može prihvatiti apsolutno sav promet koji će mu biti poslan - neće imati dovoljnu propusnost. Morat ćete nešto žrtvovati. Ili ostavite neke od čvorova bez nadzora (tada im prvo morate dati prioritet) ili ne šaljite sav promet s čvora, već samo određenu vrstu. U svakom slučaju, možda ćemo propustiti neke napade. Osim toga, SPAN port se može koristiti i za druge potrebe. Zbog toga ćemo morati pregledati postojeću topologiju mreže i eventualno je prilagoditi kako bismo maksimalno pokrili vašu mrežu s brojem senzora koje imate (i to uskladiti s IT-om).
Što ako vaša mreža koristi asimetrične rute? Što ako ste implementirali ili planirate implementirati SDN? Što ako trebate nadzirati virtualizirane strojeve ili spremnike čiji promet uopće ne doseže fizički prekidač? To su pitanja koja tradicionalni prodavači IDS-a ne vole jer na njih ne znaju odgovoriti. Možda će vas uvjeriti da su sve te moderne tehnologije hype i da vam ne trebaju. Možda će govoriti o potrebi da se počne s malim. Ili će možda reći da trebate staviti moćnu vršalicu u središte mreže i usmjeriti sav promet na nju pomoću balansera. Koja god opcija da vam se ponudi, morate jasno razumjeti kako vam odgovara. I tek nakon toga donijeti odluku o odabiru pristupa nadzoru informacijske sigurnosti mrežne infrastrukture. Vraćajući se na snimanje paketa, želim reći da je ova metoda i dalje vrlo popularna i važna, ali njena glavna svrha je kontrola granica; granice između vaše organizacije i interneta, granice između podatkovnog centra i ostatka mreže, granice između sustava kontrole procesa i korporativnog segmenta. Na tim mjestima klasični IDS/IPS još uvijek imaju pravo postojati i dobro se nositi sa svojim zadacima.
Prijeđimo na drugu opciju. Analiza događaja koji dolaze s mrežnih uređaja također se može koristiti za otkrivanje napada, ali ne kao glavni mehanizam, budući da omogućuje otkrivanje samo male klase upada. Osim toga, inherentna je određena reaktivnost - napad se prvo mora dogoditi, a zatim ga mora snimiti mrežni uređaj, što će na ovaj ili onaj način signalizirati problem s informacijskom sigurnošću. Postoji nekoliko takvih načina. To može biti syslog, RMON ili SNMP. Posljednja dva protokola za nadzor mreže u kontekstu informacijske sigurnosti koriste se samo ako treba detektirati DoS napad na samu mrežnu opremu, budući da je korištenjem RMON-a i SNMP-a moguće npr. pratiti opterećenje centrale uređaja. procesor ili njegova sučelja. Ovo je jedna od “najjeftinijih” (svatko ima syslog ili SNMP), ali i najneučinkovitija od svih metoda praćenja informacijske sigurnosti unutarnje infrastrukture - mnogi napadi su jednostavno skriveni od nje. Naravno, ne treba ih zanemariti, a ista syslog analiza pomaže vam da pravovremeno prepoznate promjene u konfiguraciji samog uređaja, njegovu kompromitaciju, ali nije baš pogodna za otkrivanje napada na cijelu mrežu.
Treća opcija je analiza podataka o prometu koji prolazi kroz uređaj koji podržava jedan od nekoliko protokola protoka. U ovom slučaju, bez obzira na protokol, infrastruktura niti se nužno sastoji od tri komponente:
- Generiranje ili izvoz protoka. Ova se uloga obično dodjeljuje usmjerivaču, preklopniku ili drugom mrežnom uređaju koji, propuštajući mrežni promet kroz sebe, omogućuje izdvajanje ključnih parametara iz njega, koji se zatim prenose u modul za prikupljanje. Na primjer, Cisco podržava Netflow protokol ne samo na usmjerivačima i preklopnicima, uključujući virtualne i industrijske, već i na bežičnim kontrolerima, vatrozidima, pa čak i poslužiteljima.
- Tijek prikupljanja. S obzirom da suvremena mreža obično ima više od jednog mrežnog uređaja, javlja se problem prikupljanja i konsolidacije tokova koji se rješava tzv. kolektorima koji primljene tokove obrađuju i prosljeđuju na analizu.
- Analiza protoka Analizator preuzima glavni intelektualni zadatak i, primjenjujući različite algoritme na tokove, donosi određene zaključke. Na primjer, kao dio IT funkcije, takav analizator može identificirati mrežna uska grla ili analizirati profil opterećenja prometa za daljnju optimizaciju mreže. A za informacijsku sigurnost, takav analizator može otkriti curenje podataka, širenje zlonamjernog koda ili DoS napade.
Nemojte misliti da je ova troslojna arhitektura previše komplicirana - sve druge opcije (osim, možda, sustava za nadzor mreže koji rade sa SNMP i RMON) također rade u skladu s njom. Imamo generator podataka za analizu, koji može biti mrežni uređaj ili samostalni senzor. Imamo sustav prikupljanja alarma i sustav upravljanja za cjelokupnu infrastrukturu nadzora. Posljednje dvije komponente mogu se kombinirati unutar jednog čvora, ali u više ili manje 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 temelji na proučavanju podataka zaglavlja i tijela svakog paketa i sesija od kojih se sastoji, analiza toka oslanja se na prikupljanje metapodataka o mrežnom prometu. Kada, koliko, odakle i gdje, kako... pitanja su na koja odgovara analiza mrežne telemetrije pomoću različitih protokola protoka. U početku su se koristili za analizu statistike i pronalaženje IT problema na mreži, ali zatim, kako su se razvili analitički mehanizmi, postalo ih je moguće primijeniti na istu telemetriju u sigurnosne svrhe. Ponovno je vrijedno napomenuti da analiza toka ne zamjenjuje niti zamjenjuje hvatanje paketa. Svaka od ovih metoda ima svoje područje primjene. Ali u kontekstu ovog članka, analiza toka je ta koja je najprikladnija za praćenje interne infrastrukture. Imate mrežne uređaje (bez obzira rade li 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 mrežni uređaj koji podržava flow protokol ne može. To je prednost ove metode.
S druge strane, ako trebate dokaze za provedbu zakona ili vlastiti tim za istraživanje incidenta, ne možete bez hvatanja paketa - mrežna telemetrija nije kopija prometa koja se može koristiti za prikupljanje dokaza; potrebna je za brzu detekciju i donošenje odluka u području informacijske sigurnosti. S druge strane, korištenjem telemetrijske analize možete “pisati” ne sav mrežni promet (ako ništa, Cisco se bavi podatkovnim centrima :-), već samo onaj koji je uključen u napad. Alati za analizu telemetrije u tom će pogledu dobro nadopuniti tradicionalne mehanizme za hvatanje paketa, dajući naredbe za selektivno hvatanje i pohranu. U suprotnom, morat ćete imati kolosalnu infrastrukturu za pohranu.
Zamislimo mrežu koja radi brzinom od 250 Mbit/s. Ako želite pohraniti sav ovaj volumen, trebat će vam 31 MB prostora za jednu sekundu prijenosa prometa, 1,8 GB za jednu minutu, 108 GB za jedan sat i 2,6 TB za jedan dan. Za pohranjivanje dnevnih podataka s mreže s propusnošću od 10 Gbit/s trebat će vam 108 TB prostora za pohranu. Ali neki regulatori zahtijevaju pohranjivanje sigurnosnih podataka godinama... Snimanje na zahtjev, koje vam analiza protoka pomaže implementirati, pomaže smanjiti ove vrijednosti za nekoliko redova veličine. Usput, ako govorimo o omjeru količine snimljenih mrežnih telemetrijskih podataka i potpunog snimanja podataka, onda je to otprilike 1 prema 500. Za iste vrijednosti dane gore, pohranjivanje punog prijepisa cjelokupnog dnevnog prometa bit će 5 odnosno 216 GB (možete ga čak snimiti na obični flash pogon).
Ako je za alate za analizu sirovih mrežnih podataka metoda njihovog snimanja gotovo ista od dobavljača do dobavljača, onda je u slučaju analize protoka situacija drugačija. Postoji nekoliko opcija za protokole protoka, čije razlike trebate znati u kontekstu sigurnosti. Najpopularniji je protokol Netflow koji je razvio Cisco. Postoji nekoliko inačica ovog protokola, koje se razlikuju po svojim mogućnostima i količini snimljenih prometnih informacija. Trenutna verzija je deveta (Netflow v9), na temelju koje je razvijen industrijski standard Netflow v10, poznat i kao IPFIX. Danas većina mrežnih dobavljača podržava Netflow ili IPFIX u svojoj opremi. Ali postoje razne druge opcije za protokole protoka - sFlow, jFlow, cFlow, rFlow, NetStream itd., od kojih je sFlow najpopularniji. Upravo ovu vrstu najčešće podržavaju domaći proizvođači mrežne opreme zbog jednostavnosti implementacije. Koje su ključne razlike između Netflowa, koji je postao de facto standard, i sFlowa? Istaknuo bih nekoliko ključnih. Prvo, Netflow ima polja koja korisnik može prilagoditi za razliku od fiksnih polja u sFlowu. I drugo, a to je najvažnije u našem slučaju, sFlow prikuplja tzv. uzorkovanu telemetriju; za razliku od neuzorkovanog za Netflow i IPFIX. Koja je razlika među njima?
Zamislite da odlučite pročitati knjigu “” mojih kolega - Garyja McIntyrea, Josepha Munitza i Nadema Alfardana (dio knjige možete preuzeti s poveznice). Imate tri mogućnosti da postignete svoj cilj - pročitajte cijelu knjigu, preletite je, zaustavljajući se na svakoj 10. ili 20. stranici, ili pokušajte pronaći prepričavanje ključnih pojmova na blogu ili usluzi poput SmartReadinga. Dakle, neuzorkovana telemetrija čita svaku “stranicu” mrežnog prometa, odnosno analizira metapodatke za svaki paket. Uzorkovana telemetrija selektivno je proučavanje prometa u nadi da će odabrani uzorci sadržavati ono što vam je potrebno. Ovisno o brzini kanala, uzorkovana telemetrija bit će poslana na analizu svakih 64., 200., 500., 1000., 2000. ili čak 10000. paketa.
U kontekstu nadzora informacijske sigurnosti, to znači da je uzorkovana telemetrija prikladna za otkrivanje DDoS napada, skeniranje i širenje zlonamjernog koda, ali može propustiti atomske ili višepaketne napade koji nisu bili uključeni u uzorak poslan na analizu. Neuzorkovana telemetrija nema takve nedostatke. Time je raspon otkrivenih napada puno širi. Ovdje je kratki popis događaja koji se mogu otkriti pomoću alata za analizu mrežne telemetrije.
Naravno, neki Netflow analizator otvorenog koda vam to neće dopustiti, budući da je njegova glavna zadaća prikupljanje telemetrije i provođenje osnovne analize na njoj s IT gledišta. Za prepoznavanje informacijskih sigurnosnih prijetnji na temelju protoka potrebno je opremiti analizator različitim motorima i algoritmima, koji će identificirati kibersigurnosne probleme na temelju standardnih ili prilagođenih Netflow polja, obogatiti standardne podatke vanjskim podacima iz različitih Threat Intelligence izvora itd.
Stoga, ako imate izbora, odaberite Netflow ili IPFIX. Ali čak i ako vaša oprema radi samo sa sFlowom, poput domaćih proizvođača, čak iu ovom slučaju možete imati koristi od nje u sigurnosnom kontekstu.
U ljeto 2019. analizirao sam mogućnosti koje ruski proizvođači mrežnog hardvera imaju i svi su, osim NSG-a, Polygona i Craftwaya, najavili podršku za sFlow (barem Zelax, Natex, Eltex, QTech, Rusteleteh).
Sljedeće pitanje s kojim ćete se suočiti je gdje implementirati podršku protoka u sigurnosne svrhe? Zapravo, pitanje nije sasvim ispravno postavljeno. Moderna oprema gotovo uvijek podržava protokole protoka. Stoga bih drugačije preformulirao pitanje – gdje je sigurnosno najučinkovitije prikupljati telemetriju? Odgovor će biti sasvim očit - na razini pristupa, gdje ćete vidjeti 100% cjelokupnog prometa, gdje ćete imati detaljne informacije o hostovima (MAC, VLAN, ID sučelja), gdje čak možete pratiti P2P promet između hostova, koji kritičan je za otkrivanje skeniranjem i distribuciju zlonamjernog koda. Na razini jezgre možda jednostavno nećete vidjeti dio prometa, ali na perimetarskoj razini vidjet ćete četvrtinu svog mrežnog prometa. Ali ako iz nekog razloga na svojoj mreži imate strane uređaje koji napadačima omogućuju "ulazak i izlazak" bez zaobilaženja perimetra, analiza telemetrije s njega neće vam dati ništa. Stoga se za maksimalnu pokrivenost preporuča omogućiti prikupljanje telemetrije na pristupnoj razini. Istodobno, vrijedi napomenuti da čak i ako govorimo o virtualizaciji ili spremnicima, podrška za protok također se često nalazi u modernim virtualnim preklopnicima, što vam također omogućuje kontrolu prometa tamo.
Ali budući da sam pokrenuo temu, moram odgovoriti na pitanje: što ako oprema, fizička ili virtualna, ne podržava protok protokola? Ili je njegovo uključivanje zabranjeno (na primjer, u industrijskim segmentima kako bi se osigurala pouzdanost)? Ili njegovo uključivanje dovodi do velikog opterećenja procesora (to se događa na starijem hardveru)? Za rješavanje ovog problema postoje specijalizirani virtualni senzori (senzori protoka), koji su u biti obični razdjelnici koji kroz sebe propuštaju promet i emitiraju ga u obliku protoka do sabirnog modula. Istina, u ovom slučaju dobivamo sve probleme o kojima smo gore govorili u vezi s alatima za snimanje paketa. To jest, morate razumjeti ne samo prednosti tehnologije analize toka, već i njezina ograničenja.
Još jedna točka koju je važno zapamtiti kada govorimo o alatima za analizu protoka. Ako u odnosu na konvencionalne načine generiranja sigurnosnih događaja koristimo EPS metriku (događaj u sekundi), tada ovaj pokazatelj nije primjenjiv na telemetrijsku analizu; zamjenjuje ga FPS (flow per second). Kao i u slučaju EPS-a, ne može se unaprijed izračunati, ali možete procijeniti približan broj niti koje određeni uređaj generira ovisno o zadatku. Na internetu možete pronaći tablice s približnim vrijednostima za različite vrste poslovnih uređaja i uvjeta, koje će 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 određenom širinom pojasa koju može "vuć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. Kad sam opisao , već sam naveo broj naših kolekcionara - ima ih 21. I to za mrežu raspršenu na pet kontinenata koja broji oko pola milijuna aktivnih uređaja).
Kao Netflow nadzorni sustav koristimo vlastito rješenje , koji je posebno usmjeren na rješavanje sigurnosnih problema. Ima mnogo ugrađenih mehanizama za otkrivanje nenormalnih, sumnjivih i očito zlonamjernih aktivnosti, što vam omogućuje otkrivanje širokog spektra različitih prijetnji - od kriptomanija do curenja informacija, od širenja zlonamjernog koda do prijevara. Kao i većina analizatora protoka, Stealthwatch je izgrađen prema shemi od tri razine (generator - kolektor - analizator), ali je dopunjen nizom zanimljivih značajki koje su važne u kontekstu materijala koji se razmatra. Prvo, integrira se s rješenjima za snimanje paketa (kao što je Cisco Security Packet Analyzer), što vam omogućuje snimanje odabranih mrežnih sesija za kasniju dubinsku istragu i analizu. Drugo, posebno za proširenje sigurnosnih zadataka, razvili smo poseban protokol nvzFlow, koji vam omogućuje "emitiranje" aktivnosti aplikacija na krajnjim čvorovima (poslužiteljima, radnim stanicama, itd.) u telemetriju i slanje kolektoru na daljnju analizu. Ako u svojoj izvornoj verziji Stealthwatch radi s bilo kojim protokom protokola (sFlow, rFlow, Netflow, IPFIX, cFlow, jFlow, NetStream) na mrežnoj razini, tada podrška za nvzFlow omogućuje korelaciju podataka i na razini čvora, dakle. povećanje učinkovitosti cijelog sustava i uočavanje više napada od konvencionalnih analizatora protoka mreže.
Jasno je da kada govorimo o sustavima za analizu Netflow sa sigurnosne točke gledišta, tržište nije ograničeno samo na jedno Ciscovo rješenje. Možete koristiti i komercijalna i besplatna ili shareware rješenja. Prilično je čudno ako na Cisco blogu navodim rješenja konkurenata kao primjere, pa ću reći nekoliko riječi o tome kako se mrežna telemetrija može analizirati pomoću dva popularna, po imenu slična, ali ipak različita alata - SiLK i ELK.
SiLK je skup alata (The System for Internet-Level Knowledge) za analizu prometa, 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 te korištenjem raznih uslužnih programa (rwfilter, rwcount, rwflowpack itd.) za obavljanje raznih operacija na mrežnoj telemetriji kako bi se otkrili znakovi neovlaštenih radnji u njoj. Ali postoji nekoliko važnih točaka koje treba napomenuti. SiLK je alat naredbenog retka koji provodi on-line analizu unošenjem naredbi poput ove (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š ugodno. Možete koristiti iSiLK GUI, ali on vam neće puno olakšati život, samo će riješiti funkciju vizualizacije, a ne zamijeniti analitičara. A ovo je druga točka. Za razliku od komercijalnih rješenja, koja već imaju solidnu analitičku bazu, algoritme za otkrivanje anomalija, odgovarajući tijek rada itd., u slučaju SiLK-a sve ćete to morati učiniti sami, što će od vas zahtijevati nešto drugačije kompetencije nego korištenje već gotovih alati za korištenje. Ovo nije ni dobro ni loše - ovo je značajka gotovo svakog besplatnog alata koji pretpostavlja da znate što treba učiniti, au tome će vam samo pomoći (komercijalni alati manje ovise o kompetencijama svojih korisnika, iako također pretpostavljaju da analitičari razumiju barem osnove mrežnih istraživanja i praćenja). No, vratimo se SiLK-u. Radni ciklus analitičara s njim izgleda ovako:
- Formuliranje hipoteze. Moramo razumjeti što ćemo tražiti unutar mrežne telemetrije, znati jedinstvene atribute pomoću kojih ćemo identificirati određene anomalije ili prijetnje.
- Izrada modela. Nakon što smo formulirali hipotezu, programiramo je koristeći isti Python, shell ili druge alate koji nisu uključeni u SiLK.
- Testiranje. Sada dolazi red da provjerimo točnost naše hipoteze, koja se potvrđuje ili opovrgava korištenjem SiLK pomoćnih programa koji počinju s 'rw', 'set', 'bag'.
- Analiza stvarnih podataka. U industrijskom radu, SiLK nam pomaže identificirati nešto i analitičar mora odgovoriti na pitanja "Jesmo li pronašli ono što smo očekivali?", "Odgovara li to našoj hipotezi?", "Kako smanjiti broj lažno pozitivnih rezultata?", "Kako poboljšati razinu prepoznavanja? » i tako dalje.
- Poboljšanje. U završnoj fazi poboljšavamo ono što je ranije učinjeno - stvaramo predloške, poboljšavamo i optimiziramo kod, preformuliramo i pojašnjavamo hipotezu itd.
Ovaj ciklus će biti primjenjiv i na Cisco Stealthwatch, samo što posljednji maksimalno automatizira ovih pet koraka, smanjujući broj pogrešaka analitičara i povećavajući učinkovitost otkrivanja incidenata. Na primjer, u SiLK-u možete obogatiti mrežnu statistiku vanjskim podacima o zlonamjernim IP adresama koristeći rukom pisane skripte, au Cisco Stealthwatchu to je ugrađena funkcija koja odmah prikazuje alarm ako mrežni promet sadrži interakcije s IP adresama s crne liste.
Ako odete više u "plaćenoj" piramidi za softver za analizu toka, tada će nakon apsolutno besplatnog SiLK-a doći shareware ELK, koji se sastoji od tri ključne komponente - Elasticsearch (indeksiranje, pretraživanje i analiza podataka), Logstash (unos/izlaz podataka ) i Kibana (vizualizacija). Za razliku od SiLK-a, gdje sve morate napisati sami, ELK već ima mnogo gotovih biblioteka/modula (neki se plaćaju, neki ne) koji automatiziraju analizu mrežne telemetrije. Na primjer, GeoIP filter u Logstashu omogućuje vam pridruživanje nadziranih IP adresa s njihovim zemljopisnim položajem (Stealthwatch ima ovu ugrađenu značajku).
ELK također ima prilično veliku zajednicu koja dovršava komponente koje nedostaju za ovo rješenje za praćenje. Na primjer, za rad s Netflow, IPFIX i sFlow možete koristiti modul , ako niste zadovoljni Logstash Netflow modulom, koji podržava samo Netflow.
Iako daje veću učinkovitost u prikupljanju protoka i pretraživanju u njemu, ELK trenutno nema bogatu ugrađenu analitiku za otkrivanje anomalija i prijetnji u mrežnoj telemetriji. To jest, slijedeći gore opisani životni ciklus, morat ćete samostalno opisati modele kršenja, a zatim ih koristiti u borbenom sustavu (ondje nema ugrađenih modela).
Postoje, naravno, 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 ovdje je pitanje je li igra vrijedna svijeće - sami napišite sličan model, kupite ga implementaciju za vaš alat za praćenje ili kupite gotovo rješenje klase Analiza mrežnog prometa.
Općenito, ne želim ulaziti u raspravu da je bolje potrošiti novac i kupiti gotovo rješenje za praćenje anomalija i prijetnji u mrežnoj telemetriji (npr. Cisco Stealthwatch) ili ga sami smisliti i prilagoditi sebi SiLK, ELK ili nfdump ili OSU Flow Tools za svaku novu prijetnju (govorim o zadnje dvije od njih posljednji put)? Svatko bira za sebe i svatko ima svoje motive za odabir bilo koje od dvije opcije. Htio sam samo pokazati da je mrežna telemetrija vrlo važan alat u osiguravanju mrežne sigurnosti vaše interne infrastrukture i ne smijete je zanemariti kako se ne biste pridružili popisu tvrtki čije se ime u medijima spominje uz epitete “ hakiran”, “neusklađen sa zahtjevima informacijske sigurnosti””, “ne razmišlja o sigurnosti svojih podataka i podataka o klijentima.”
Ukratko, želio bih navesti ključne savjete koje biste trebali slijediti prilikom izgradnje nadzora informacijske sigurnosti vaše interne infrastrukture:
- Nemojte se ograničavati samo na perimetar! Koristite (i odaberite) mrežnu infrastrukturu ne samo za premještanje prometa od točke A do točke B, već i za rješavanje problema kibernetičke sigurnosti.
- Proučite postojeće mehanizme nadzora informacijske sigurnosti u svojoj mrežnoj opremi i upotrijebite ih.
- Za interni nadzor dajte prednost telemetrijskoj analizi - ona vam omogućuje otkrivanje do 80-90% svih incidenata sigurnosti mrežnih informacija, dok činite ono što je nemoguće pri hvatanju mrežnih paketa i štedite prostor za pohranu svih događaja sigurnosti informacija.
- Za nadzor protoka koristite Netflow v9 ili IPFIX - oni pružaju više informacija u sigurnosnom kontekstu i omogućuju vam nadzor ne samo IPv4, već i IPv6, MPLS itd.
- Koristite neuzorkovani protokol protoka - 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 protokol protoka. Zatim razmislite o korištenju virtualnih senzora ili Netflow Generation Appliance.
- Provedite kontrolu prije svega na razini pristupa - to će vam dati priliku da vidite 100% svog prometa.
- Ako nemate izbora i koristite rusku mrežnu opremu, odaberite onu koja podržava protok protokola ili ima SPAN/RSPAN portove.
- Kombinirajte sustave za otkrivanje/sprečavanje upada/napada na rubovima i sustave za analizu protoka u internoj mreži (uključujući i oblake).
Što se tiče posljednjeg savjeta, želio bih dati ilustraciju koju sam već dao prije. Vidite da ako je prethodno Cisco služba za informacijsku sigurnost gotovo u potpunosti gradila svoj sustav nadzora informacijske sigurnosti na temelju sustava za otkrivanje upada i metoda potpisa, sada oni čine samo 20% incidenata. Još 20% otpada na sustave za analizu protoka, što sugerira da ova rješenja nisu hir, već pravi alat u aktivnostima usluga informacijske sigurnosti modernog poduzeća. Štoviše, za njihovu implementaciju imate ono najvažnije - mrežnu infrastrukturu, ulaganja u koju možete dodatno zaštititi dodjeljivanjem funkcija nadzora informacijske sigurnosti mreži.
Nisam se konkretno doticao teme odgovora na anomalije ili prijetnje identificirane u mrežnim tokovima, ali mislim da je već sada jasno da nadzor ne treba završiti samo detekcijom prijetnje. Nakon njega bi trebao uslijediti odgovor i to po mogućnosti u automatskom ili automatiziranom načinu rada. Ali ovo je tema za poseban članak.
Dodatne informacije:
P.S. Ako vam je lakše čuti sve što je gore napisano, onda možete pogledati jednosatnu prezentaciju koja je bila temelj ove bilješke.
Izvor: www.habr.com