Ko gre za spremljanje varnosti notranjega omrežja podjetja ali oddelka, ga mnogi povezujejo z nadzorom uhajanja informacij in implementacijo rešitev DLP. In če poskušate razjasniti vprašanje in vprašati, kako zaznati napade na notranje omrežje, potem bo odgovor praviloma omemba sistemov za zaznavanje vdorov (IDS). In kar je bila pred 10-20 leti edina možnost, danes postaja anahronizem. Obstaja bolj učinkovita in ponekod edina možna možnost nadzora notranjega omrežja - uporaba pretočnih protokolov, ki so bili prvotno namenjeni iskanju omrežnih težav (odpravljanje težav), a so se sčasoma preoblikovali v zelo zanimivo varnostno orodje. Govorili bomo o tem, kateri protokoli pretoka obstajajo in kateri so boljši pri odkrivanju omrežnih napadov, kje je najbolje izvajati spremljanje pretoka, na kaj morate biti pozorni pri uvajanju takšne sheme in celo, kako vse to "dvigniti" na domači opremi v okviru tega člena.
Ne bom se ukvarjal z vprašanjem "Zakaj je potreben nadzor varnosti notranje infrastrukture?" Zdi se, da je odgovor jasen. Če pa bi se radi še enkrat prepričali, da danes brez tega ne morete živeti, kratek video o tem, kako lahko na 17 načinov prodrete v korporativno omrežje, zaščiteno s požarnim zidom. Zato bomo domnevali, da razumemo, da je interni nadzor nujen in ostane le še, da razumemo, kako ga je mogoče organizirati.
Izpostavil bi tri ključne vire podatkov za spremljanje infrastrukture na ravni omrežja:
- »surov« promet, ki ga zajamemo in oddamo v analizo določenim analitičnim sistemom,
- dogodki iz omrežnih naprav, skozi katere teče promet,
- prometne informacije, prejete prek enega od protokolov pretoka.
Zajem surovega prometa je najbolj priljubljena možnost med varnostnimi strokovnjaki, saj se je zgodovinsko pojavila in je bila prva. Običajni sistemi za zaznavanje vdorov v omrežje (prvi komercialni sistem za zaznavanje vdorov je bil NetRanger od Wheel Group, ki ga je leta 1998 kupil Cisco) so se ukvarjali ravno z zajemom paketov (in kasneje sej), v katerih so iskali določene podpise (»odločilna pravila« v FSTEC terminologija), signaliziranje napadov. Seveda lahko neobdelani promet analizirate ne samo z uporabo IDS, ampak tudi z drugimi orodji (na primer Wireshark, tcpdum ali funkcionalnost NBAR2 v Cisco IOS), vendar jim običajno manjka baza znanja, po kateri se orodje za informacijsko varnost razlikuje od navadnega IT orodje.
Torej, sistemi za odkrivanje napadov. Najstarejša in najbolj priljubljena metoda zaznavanja omrežnih napadov, ki se dobro obnese na obodu (ne glede na to, katerega - podjetja, podatkovnega centra, segmenta itd.), vendar odpove v sodobnih komutiranih in programsko definiranih omrežjih. V primeru omrežja, ki je zgrajeno na osnovi običajnih stikal, postane infrastruktura senzorjev za zaznavanje napadov prevelika – senzor boste morali namestiti na vsako povezavo do vozlišča, na katerem želite nadzorovati napade. Vsak proizvajalec vam bo seveda z veseljem prodal na stotine in tisoče senzorjev, vendar mislim, da vaš proračun ne more podpreti takšnih stroškov. Lahko rečem, da tudi pri Ciscu (in smo razvijalci NGIPS) tega nismo mogli storiti, čeprav se zdi, da je pred nami vprašanje cene. Ne bi smel stati - to je naša lastna odločitev. Poleg tega se postavlja vprašanje, kako povezati senzor v tej različici? V vrzel? Kaj pa, če sam senzor odpove? Potrebujete obvodni modul v senzorju? Uporabite razdelilnike (pipa)? Vse to podraži rešitev in jo naredi nedosegljivo za podjetje katere koli velikosti.
Senzor lahko poskusite »obesiti« na vrata SPAN/RSPAN/ERSPAN in nanj usmeriti promet iz zahtevanih vrat stikala. Ta možnost delno odpravi težavo, opisano v prejšnjem odstavku, vendar predstavlja drugo - vrata SPAN ne morejo sprejeti absolutno vsega prometa, ki mu bo poslan - ne bodo imela dovolj pasovne širine. Nekaj boste morali žrtvovati. Pustite nekatera vozlišča brez nadzora (takrat jim morate najprej dati prednost) ali pa ne pošiljajte celotnega prometa iz vozlišča, temveč samo določeno vrsto. V vsakem primeru lahko zgrešimo kakšen napad. Poleg tega se vrata SPAN lahko uporabljajo za druge potrebe. Posledično bomo morali pregledati obstoječo topologijo omrežja in jo morebiti prilagoditi, da bi čim bolj pokrili vaše omrežje s številom senzorjev, ki jih imate (in to uskladiti z IT).
Kaj pa, če vaše omrežje uporablja asimetrične poti? Kaj pa, če ste implementirali ali nameravate implementirati SDN? Kaj pa, če morate nadzorovati virtualizirane stroje ali vsebnike, katerih promet sploh ne doseže fizičnega stikala? To so vprašanja, ki jih tradicionalni prodajalci IDS ne marajo, ker ne vedo, kako nanje odgovoriti. Morda vas bodo prepričali, da so vse te modne tehnologije hype in jih ne potrebujete. Morda bodo govorili o tem, da je treba začeti z majhnimi. Ali pa bodo morda rekli, da morate v središče omrežja postaviti zmogljivo mlatilnico in ves promet usmeriti nanjo z uporabo balansirnih elementov. Ne glede na možnost, ki vam je ponujena, morate jasno razumeti, kako vam ustreza. In šele po tem se odločite za izbiro pristopa k spremljanju informacijske varnosti omrežne infrastrukture. Če se vrnem k zajemanju paketov, želim povedati, da je ta metoda še vedno zelo priljubljena in pomembna, vendar je njen glavni namen nadzor meja; meje med vašo organizacijo in internetom, meje med podatkovnim centrom in preostalim omrežjem, meje med sistemom za nadzor procesov in segmentom podjetja. V teh krajih imajo klasični IDS/IPS še vedno pravico do obstoja in se dobro spopadajo s svojimi nalogami.
Preidimo na drugo možnost. Analizo dogodkov, ki prihajajo iz omrežnih naprav, lahko uporabimo tudi za namene odkrivanja napadov, vendar ne kot glavni mehanizem, saj omogoča odkrivanje le majhnega razreda vdorov. Poleg tega je neločljivo povezana z določeno reaktivnostjo - napad se mora najprej zgoditi, nato pa ga mora zabeležiti omrežna naprava, ki bo na tak ali drugačen način signalizirala težavo z varnostjo informacij. Takih načinov je več. To je lahko sistemski dnevnik, RMON ali SNMP. Zadnja dva protokola za nadzor omrežja v kontekstu informacijske varnosti uporabljamo le, če moramo zaznati DoS napad na samo omrežno opremo, saj je z uporabo RMON in SNMP mogoče npr. spremljati obremenitev centrale naprave. procesorja ali njegovih vmesnikov. To je eden "najcenejših" (vsi imajo syslog ali SNMP), a tudi najbolj neučinkovit od vseh načinov spremljanja informacijske varnosti notranje infrastrukture - številni napadi so preprosto skriti pred njim. Seveda jih ne smemo zanemariti in ista analiza syslog vam pomaga pravočasno prepoznati spremembe v konfiguraciji same naprave, njeno ogroženost, vendar ni zelo primerna za odkrivanje napadov na celotno omrežje.
Tretja možnost je analiza informacij o prometu, ki poteka skozi napravo, ki podpira enega od več protokolov pretoka. V tem primeru, ne glede na protokol, je nitna infrastruktura nujno sestavljena iz treh komponent:
- Generiranje ali izvoz toka. Ta vloga je običajno dodeljena usmerjevalniku, stikalu ali drugi omrežni napravi, ki s prepuščanjem omrežnega prometa skozi sebe omogoča, da iz njega izvlečete ključne parametre, ki se nato posredujejo v zbirni modul. Na primer, Cisco podpira protokol Netflow ne samo na usmerjevalnikih in stikalih, vključno z virtualnimi in industrijskimi, temveč tudi na brezžičnih krmilnikih, požarnih zidovih in celo strežnikih.
- Tok zbiranja. Glede na to, da ima sodobno omrežje običajno več kot eno omrežno napravo, se pojavi problem zbiranja in konsolidacije tokov, ki ga rešujemo s tako imenovanimi kolektorji, ki prejete tokove obdelajo in nato posredujejo v analizo.
- Analiza pretoka Analizator prevzame glavno intelektualno nalogo in z uporabo različnih algoritmov za tokove pripravi določene zaključke. Na primer, kot del funkcije IT lahko tak analizator identificira ozka grla v omrežju ali analizira profil prometne obremenitve za nadaljnjo optimizacijo omrežja. Za varnost informacij lahko tak analizator zazna uhajanje podatkov, širjenje zlonamerne kode ali napade DoS.
Ne mislite, da je ta trinivojska arhitektura preveč zapletena - vse druge možnosti (razen morda sistemov za nadzor omrežja, ki delujejo s SNMP in RMON) delujejo tudi v skladu z njo. Za analizo imamo generator podatkov, ki je lahko mrežna naprava ali samostojni senzor. Imamo sistem za zbiranje alarmov in sistem za upravljanje celotne nadzorne infrastrukture. Zadnji dve komponenti sta lahko združeni znotraj enega vozlišča, vendar sta v bolj ali manj velikih omrežjih običajno razpršeni na vsaj dve napravi, da se zagotovi razširljivost in zanesljivost.
Za razliko od analize paketov, ki temelji na preučevanju podatkov glave in telesa vsakega paketa in sej, iz katerih je sestavljen, analiza toka temelji na zbiranju metapodatkov o omrežnem prometu. Kdaj, koliko, od kod in kje, kako ... so vprašanja, na katera odgovarja analiza omrežne telemetrije z različnimi pretočnimi protokoli. Sprva so jih uporabljali za analizo statističnih podatkov in iskanje težav IT v omrežju, nato pa, ko so se razvili analitični mehanizmi, jih je postalo mogoče uporabiti za isto telemetrijo za varnostne namene. Ponovno je treba omeniti, da analiza toka ne nadomešča zajemanja paketov. Vsaka od teh metod ima svoje področje uporabe. Toda v kontekstu tega članka je analiza toka najbolj primerna za spremljanje notranje infrastrukture. Imate omrežne naprave (ne glede na to, ali delujejo v programsko določeni paradigmi ali v skladu s statičnimi pravili), ki jih napad ne more obiti. Lahko obide klasičen IDS senzor, omrežna naprava, ki podpira protokol flow, pa ne. To je prednost te metode.
Po drugi strani pa, če potrebujete dokaze za organe pregona ali lastno ekipo za preiskavo incidentov, ne morete storiti brez zajemanja paketov - omrežna telemetrija ni kopija prometa, ki bi se lahko uporabila za zbiranje dokazov; potreben je za hitro odkrivanje in odločanje na področju informacijske varnosti. Po drugi strani pa s pomočjo telemetrične analize ne morete "zapisati" celotnega omrežnega prometa (če kaj, Cisco se ukvarja s podatkovnimi centri :-), ampak samo tistega, ki je vključen v napad. Orodja za analizo telemetrije bodo v zvezi s tem dobro dopolnjevala tradicionalne mehanizme zajemanja paketov, saj bodo dajala ukaze za selektivno zajemanje in shranjevanje. V nasprotnem primeru boste morali imeti ogromno infrastrukturo za shranjevanje.
Predstavljajmo si omrežje, ki deluje s hitrostjo 250 Mbit/s. Če želite shraniti vso to količino, boste potrebovali 31 MB prostora za eno sekundo prenosa prometa, 1,8 GB za eno minuto, 108 GB za eno uro in 2,6 TB za en dan. Za shranjevanje dnevnih podatkov iz omrežja s pasovno širino 10 Gbit/s boste potrebovali 108 TB prostora za shranjevanje. Toda nekateri regulatorji zahtevajo shranjevanje varnostnih podatkov več let ... Snemanje na zahtevo, ki vam ga pomaga implementirati analiza toka, pomaga zmanjšati te vrednosti za velikostne rede. Mimogrede, če govorimo o razmerju med količino posnetih omrežnih telemetričnih podatkov in popolnim zajemom podatkov, potem je to približno 1 proti 500. Za enake vrednosti, navedene zgoraj, shranjevanje celotnega prepisa celotnega dnevnega prometa bo 5 oziroma 216 GB (lahko ga posnamete celo na običajni bliskovni pogon).
Če je pri orodjih za analizo neobdelanih omrežnih podatkov način zajema od prodajalca do ponudnika skoraj enak, je pri analizi toka situacija drugačna. Obstaja več možnosti za pretočne protokole, razlike v katerih morate poznati v kontekstu varnosti. Najbolj priljubljen je protokol Netflow, ki ga je razvil Cisco. Obstaja več različic tega protokola, ki se razlikujejo po zmogljivostih in količini zabeleženih prometnih informacij. Trenutna različica je deveta (Netflow v9), na podlagi katere je bil razvit industrijski standard Netflow v10, znan tudi kot IPFIX. Danes večina prodajalcev omrežij podpira Netflow ali IPFIX v svoji opremi. Vendar obstajajo različne druge možnosti za pretočne protokole - sFlow, jFlow, cFlow, rFlow, NetStream itd., med katerimi je sFlow najbolj priljubljen. To vrsto najpogosteje podpirajo domači proizvajalci omrežne opreme zaradi enostavnosti izvedbe. Kakšne so ključne razlike med Netflowom, ki je postal de facto standard, in sFlow? Izpostavil bi več ključnih. Prvič, Netflow ima polja, ki jih lahko prilagodi uporabnik, v nasprotju s fiksnimi polji v sFlow. In drugič, kar je v našem primeru najpomembnejše, sFlow zbira tako imenovano vzorčeno telemetrijo; v nasprotju z nevzorčenim za Netflow in IPFIX. Kakšna je razlika med njimi?
Predstavljajte si, da se odločite prebrati knjigo "” mojih kolegov - Garyja McIntyra, Josepha Munitza in Nadema Alfardana (del knjige si lahko prenesete s povezave). Imate tri možnosti, da dosežete svoj cilj – preberite celotno knjigo, jo preletite in se ustavite na vsaki 10. ali 20. strani ali pa poskusite najti ponovitev ključnih pojmov na blogu ali storitvi, kot je SmartReading. Nevzorčena telemetrija torej bere vsako »stran« omrežnega prometa, torej analizira metapodatke za vsak paket. Vzorčena telemetrija je selektivna študija prometa v upanju, da bodo izbrani vzorci vsebovali tisto, kar potrebujete. Odvisno od hitrosti kanala bo vzorčena telemetrija poslana v analizo vsak 64., 200., 500., 1000., 2000. ali celo 10000. paket.
V kontekstu nadzora informacijske varnosti to pomeni, da je vzorčena telemetrija zelo primerna za odkrivanje napadov DDoS, skeniranje in širjenje zlonamerne kode, vendar lahko zgreši atomske ali večpaketne napade, ki niso bili vključeni v vzorec, poslan v analizo. Nevzorčena telemetrija nima takšnih slabosti. S tem je obseg zaznanih napadov veliko širši. Tukaj je kratek seznam dogodkov, ki jih je mogoče zaznati z orodji za analizo omrežne telemetrije.
Seveda vam kakšen odprtokodni analizator Netflow tega ne bo omogočil, saj je njegova glavna naloga zbiranje telemetrije in izvajanje osnovne analize na njej z vidika IT. Za identifikacijo groženj informacijski varnosti na podlagi pretoka je potrebno opremiti analizator z različnimi motorji in algoritmi, ki bodo na podlagi standardnih ali prilagojenih polj Netflow prepoznavali probleme kibernetske varnosti, standardne podatke obogatili z zunanjimi podatki iz različnih virov Threat Intelligence itd.
Zato, če imate izbiro, izberite Netflow ali IPFIX. Toda tudi če vaša oprema deluje samo s sFlow, kot domači proizvajalci, potem vam lahko tudi v tem primeru koristi v varnostnem kontekstu.
Poleti 2019 sem analiziral zmogljivosti, ki jih imajo ruski proizvajalci omrežne strojne opreme in vsi, razen NSG, Polygon in Craftway, so napovedali podporo za sFlow (vsaj Zelax, Natex, Eltex, QTech, Rusteleteh).
Naslednje vprašanje, s katerim se boste soočili, je, kje implementirati podporo za pretok za varnostne namene? Pravzaprav vprašanje ni zastavljeno povsem pravilno. Sodobna oprema skoraj vedno podpira pretočne protokole. Zato bi vprašanje preoblikoval drugače – kje je z varnostnega vidika najbolj učinkovito zbirati telemetrijo? Odgovor bo povsem očiten – na nivoju dostopa, kjer boste videli 100% vsega prometa, kjer boste imeli podrobne informacije o gostiteljih (MAC, VLAN, ID vmesnika), kjer boste lahko celo spremljali P2P promet med gostitelji, kar je ključnega pomena za odkrivanje skeniranja in distribucijo zlonamerne kode. Na ravni jedra morda preprosto ne vidite dela prometa, na ravni perimetra pa boste videli četrtino vsega svojega omrežnega prometa. Če pa imate v omrežju iz nekega razloga tuje naprave, ki napadalcem omogočajo "vstop in izstop", ne da bi obšli perimeter, vam analiza telemetrije iz njega ne bo dala ničesar. Zato je za največjo pokritost priporočljivo omogočiti zbiranje telemetrije na ravni dostopa. Ob tem velja omeniti, da tudi če govorimo o virtualizaciji ali vsebnikih, podporo pretoku pogosto najdemo tudi v sodobnih virtualnih stikalih, kar omogoča nadzor prometa tudi tam.
Ker pa sem sprožil to temo, moram odgovoriti na vprašanje: kaj če oprema, fizična ali virtualna, ne podpira pretočnih protokolov? Ali pa je njegova vključitev prepovedana (na primer v industrijskih segmentih za zagotovitev zanesljivosti)? Ali pa vklop povzroči visoko obremenitev procesorja (to se zgodi pri starejši strojni opremi)? Za rešitev tega problema obstajajo specializirani virtualni senzorji (senzorji pretoka), ki so v bistvu navadni razdelilniki, ki skozi sebe prepuščajo promet in ga v obliki toka oddajajo v zbirni modul. Res je, v tem primeru dobimo vse težave, o katerih smo govorili zgoraj v zvezi z orodji za zajem paketov. To pomeni, da morate razumeti ne le prednosti tehnologije analize toka, ampak tudi njene omejitve.
Še ena točka, ki si jo je pomembno zapomniti, ko govorimo o orodjih za analizo toka. Če v zvezi s konvencionalnimi načini generiranja varnostnih dogodkov uporabljamo metriko EPS (dogodek na sekundo), potem ta indikator ni uporaben za analizo telemetrije; nadomesti ga FPS (flow per second). Tako kot v primeru EPS ga ni mogoče izračunati vnaprej, lahko pa ocenite približno število niti, ki jih posamezna naprava ustvari glede na svojo nalogo. Na internetu lahko najdete tabele s približnimi vrednostmi za različne vrste poslovnih naprav in pogojev, ki vam bodo omogočile oceno, katere licence potrebujete za orodja za analizo in kakšna bo njihova arhitektura? Dejstvo je, da je senzor IDS omejen z določeno pasovno širino, ki jo lahko "vleče", pretočni kolektor pa ima svoje omejitve, ki jih je treba razumeti. Zato je v velikih, geografsko porazdeljenih omrežjih običajno več zbiralnikov. Ko sem opisal , sem že navedel število naših zbiralcev - teh je 21. In to za omrežje, ki je razpršeno na petih celinah in šteje približno pol milijona aktivnih naprav).
Kot nadzorni sistem Netflow uporabljamo lastno rešitev , ki je posebej usmerjeno v reševanje varnostnih problemov. Ima veliko vgrajenih mehanizmov za odkrivanje nenormalnih, sumljivih in očitno zlonamernih dejavnosti, ki vam omogočajo odkrivanje širokega nabora različnih groženj – od kriptokopanja do uhajanja informacij, od širjenja zlonamerne kode do goljufij. Kot večina analizatorjev pretoka je tudi Stealthwatch zgrajen po trinivojski shemi (generator - kolektor - analizator), vendar je dopolnjen s številnimi zanimivimi funkcijami, ki so pomembne v kontekstu obravnavanega materiala. Prvič, integrira se z rešitvami za zajem paketov (kot je Cisco Security Packet Analyzer), ki omogoča snemanje izbranih omrežnih sej za poznejšo poglobljeno preiskavo in analizo. Drugič, posebej za razširitev varnostnih nalog smo razvili poseben protokol nvzFlow, ki vam omogoča, da "oddajate" aktivnost aplikacij na končnih vozliščih (strežnikih, delovnih postajah itd.) v telemetrijo in jo posredujete zbiralniku za nadaljnjo analizo. Če v originalni različici Stealthwatch deluje s katerim koli protokolom toka (sFlow, rFlow, Netflow, IPFIX, cFlow, jFlow, NetStream) na omrežni ravni, potem podpora nvzFlow omogoča korelacijo podatkov tudi na ravni vozlišča, torej. povečanje učinkovitosti celotnega sistema in opazovanje več napadov kot običajni analizatorji omrežnega toka.
Jasno je, da ko govorimo o sistemih za analizo Netflow z varnostnega vidika, trg ni omejen na eno samo Ciscovo rešitev. Uporabljate lahko komercialne in brezplačne rešitve ali rešitve za skupno rabo. Precej nenavadno je, če na blogu Cisco kot primere navajam rešitve konkurentov, zato bom povedal nekaj besed o tem, kako je mogoče analizirati omrežno telemetrijo z dvema priljubljenima, podobnima po imenu, a še vedno različnima orodjema - SiLK in ELK.
SiLK je nabor orodij (The System for Internet-Level Knowledge) za analizo prometa, ki ga je razvil ameriški CERT/CC in ki v kontekstu današnjega članka podpira Netflow (5. in 9., najbolj priljubljeni različici), IPFIX in sFlow ter uporabo različnih pripomočkov (rwfilter, rwcount, rwflowpack itd.) za izvajanje različnih operacij na omrežni telemetriji z namenom odkrivanja znakov nepooblaščenih dejanj v njem. Vendar je treba upoštevati nekaj pomembnih točk. SiLK je orodje ukazne vrstice, ki izvaja spletno analizo z vnosom takih ukazov (zaznavanje paketov ICMP, večjih od 200 bajtov):
rwfilter --flowtypes=all/all --proto=1 --bytes-per-packet=200- --pass=stdout | rwrwcut --fields=sIP,dIP,iType,iCode --num-recs=15
ni zelo udobno. Uporabite lahko iSiLK GUI, vendar vam ne bo olajšal življenja, saj bo le rešil funkcijo vizualizacije in ne bo nadomestil analitika. In to je druga točka. Za razliko od komercialnih rešitev, ki že imajo trdno analitično osnovo, algoritme za odkrivanje anomalij, ustrezen potek dela ipd., boste morali v primeru SiLK-a vse to narediti sami, kar bo od vas zahtevalo nekoliko drugačne kompetence kot pri uporabi že pripravljenih orodja za uporabo. To ni niti dobro niti slabo – to je značilnost skoraj vsakega brezplačnega orodja, ki predvideva, da veste, kaj morate storiti, in vam bo pri tem samo pomagalo (komercialna orodja so manj odvisna od kompetenc svojih uporabnikov, čeprav tudi domnevajo, da analitiki razumejo vsaj osnove omrežnih preiskav in spremljanja). A vrnimo se k SiLK. Delovni cikel analitika z njim izgleda takole:
- Oblikovanje hipoteze. Razumeti moramo, kaj bomo iskali znotraj omrežne telemetrije, poznati edinstvene atribute, po katerih bomo identificirali določene anomalije ali grožnje.
- Gradnja modela. Ko oblikujemo hipotezo, jo programiramo z uporabo istega Pythona, lupine ali drugih orodij, ki niso vključena v SiLK.
- Testiranje. Zdaj je na vrsti preverjanje pravilnosti naše hipoteze, ki jo potrdimo ali ovržemo s pripomočki SiLK, ki se začnejo z 'rw', 'set', 'bag'.
- Analiza realnih podatkov. Pri industrijskem delovanju nam SiLK pomaga nekaj identificirati in analitik mora odgovoriti na vprašanja »Ali smo našli tisto, kar smo pričakovali?«, »Ali to ustreza naši hipotezi?«, »Kako zmanjšati število lažno pozitivnih rezultatov?«, »Kako izboljšati stopnjo prepoznavnosti? » in tako naprej.
- Izboljšava. V končni fazi izboljšamo tisto, kar je bilo narejeno prej - ustvarimo predloge, izboljšamo in optimiziramo kodo, preformuliramo in pojasnimo hipotezo itd.
Ta cikel bo uporaben tudi za Cisco Stealthwatch, le da zadnji maksimalno avtomatizira teh pet korakov, zmanjša število analitičnih napak in poveča učinkovitost zaznavanja incidentov. V SiLK lahko na primer obogatite omrežno statistiko z zunanjimi podatki o zlonamernih naslovih IP z ročno napisanimi skripti, v Cisco Stealthwatch pa je to vgrajena funkcija, ki takoj prikaže alarm, če omrežni promet vsebuje interakcije z naslovi IP s črnega seznama.
Če greste višje v "plačljivi" piramidi programske opreme za analizo toka, potem bo za popolnoma brezplačnim SiLK-jem na voljo še programska oprema ELK, ki jo sestavljajo tri ključne komponente - Elasticsearch (indeksiranje, iskanje in analiza podatkov), Logstash (vnos/izhod podatkov). ) in Kibana (vizualizacija). Za razliko od SiLK, kjer morate vse napisati sami, ima ELK že veliko pripravljenih knjižnic/modulov (nekatere plačljive, nekatere ne), ki avtomatizirajo analizo omrežne telemetrije. Na primer, filter GeoIP v Logstash vam omogoča, da spremljane naslove IP povežete z njihovo geografsko lokacijo (Stealthwatch ima to vgrajeno funkcijo).
ELK ima tudi precej veliko skupnost, ki dopolnjuje manjkajoče komponente za to rešitev za spremljanje. Na primer, za delo z Netflow, IPFIX in sFlow lahko uporabite modul , če niste zadovoljni z modulom Logstash Netflow, ki podpira samo Netflow.
Medtem ko zagotavlja večjo učinkovitost pri zbiranju toka in iskanju v njem, ELK trenutno nima bogate vgrajene analitike za odkrivanje nepravilnosti in groženj v omrežni telemetriji. To pomeni, da boste morali po zgoraj opisanem življenjskem ciklu samostojno opisati modele kršitev in jih nato uporabiti v bojnem sistemu (tam ni vgrajenih modelov).
Seveda obstajajo bolj sofisticirane razširitve za ELK, ki že vsebujejo nekaj modelov za odkrivanje nepravilnosti v omrežni telemetriji, vendar takšne razširitve stanejo in tukaj je vprašanje, ali je igra vredna sveče - sami napišite podoben model, kupite ga implementacijo za vaše orodje za nadzor ali kupite že pripravljeno rešitev razreda Analiza omrežnega prometa.
Na splošno se nočem spuščati v debato o tem, da je bolje porabiti denar in kupiti že pripravljeno rešitev za spremljanje nepravilnosti in groženj v omrežni telemetriji (na primer Cisco Stealthwatch) ali pa jo ugotoviti sam in jo prilagoditi. SiLK, ELK ali nfdump ali OSU Flow Tools za vsako novo grožnjo (govorim o zadnjih dveh prejšnjič)? Vsak izbira zase in vsak ima svoje motive, zakaj se odloči za eno od obeh možnosti. Želel sem le pokazati, da je omrežna telemetrija zelo pomembno orodje pri zagotavljanju omrežne varnosti vaše notranje infrastrukture in je ne smete zanemariti, da se ne bi pridružili seznamu podjetij, katerih ime se v medijih omenja z epiteti “ vdrli«, »neizpolnjujejo zahteve glede informacijske varnosti«, »ne razmišljajo o varnosti svojih podatkov in podatkov o strankah«.
Če povzamem, bi rad navedel ključne nasvete, ki jih morate upoštevati pri izgradnji nadzora informacijske varnosti vaše notranje infrastrukture:
- Ne omejujte se le na obseg! Uporabite (in izberite) omrežno infrastrukturo ne le za premikanje prometa od točke A do točke B, ampak tudi za reševanje vprašanj kibernetske varnosti.
- Preučite obstoječe mehanizme nadzora varnosti informacij v vaši omrežni opremi in jih uporabite.
- Za interni nadzor dajte prednost telemetrični analizi - omogoča vam odkrivanje do 80-90% vseh varnostnih incidentov v omrežju, pri čemer naredite tisto, kar je nemogoče pri zajemanju omrežnih paketov in prihranite prostor za shranjevanje vseh informacijsko-varnostnih dogodkov.
- Za spremljanje tokov uporabite Netflow v9 ali IPFIX - nudita več informacij v varnostnem kontekstu in vam omogočata spremljanje ne samo IPv4, ampak tudi IPv6, MPLS itd.
- Uporabite nevzorčen protokol pretoka - ponuja več informacij za odkrivanje groženj. Na primer Netflow ali IPFIX.
- Preverite obremenitev vaše omrežne opreme - morda ne bo zmožna obvladati tudi protokola toka. Nato razmislite o uporabi virtualnih senzorjev ali Netflow Generation Appliance.
- Izvedite nadzor najprej na ravni dostopa - tako boste imeli priložnost videti 100% vsega prometa.
- Če nimate izbire in uporabljate rusko omrežno opremo, izberite tisto, ki podpira pretočne protokole ali ima vrata SPAN/RSPAN.
- Združite sisteme za zaznavanje/preprečevanje vdorov/napadov na robovih in sisteme za analizo toka v notranjem omrežju (tudi v oblakih).
Glede zadnjega nasveta bi rad podal ilustracijo, ki sem jo že podal. Vidite, da če je prej storitev za informacijsko varnost Cisco skoraj v celoti zgradila svoj sistem za nadzor informacijske varnosti na podlagi sistemov za odkrivanje vdorov in metod podpisovanja, zdaj predstavljajo le 20% incidentov. Drugih 20% pade na sisteme za analizo toka, kar nakazuje, da te rešitve niso muhavost, ampak resnično orodje v dejavnostih storitev informacijske varnosti sodobnega podjetja. Poleg tega imate za njihovo izvedbo najpomembnejše – omrežno infrastrukturo, vlaganja v katero lahko dodatno zaščitite tako, da omrežju dodelite nadzorne funkcije informacijske varnosti.
Teme odzivanja na anomalije ali grožnje, ugotovljene v omrežnih tokovih, se sicer nisem dotaknil, menim pa, da je že zdaj jasno, da se nadzor ne sme končati samo z zaznavo grožnje. Sledi mu odgovor in po možnosti v samodejnem ali avtomatiziranem načinu. Toda to je tema za ločen članek.
Dodatne informacije:
PS. Če vam je lažje slišati vse zgoraj napisano, si lahko ogledate enourno predstavitev, ki je bila osnova tega zapisa.
Vir: www.habr.com