Þegar kemur að því að fylgjast með öryggi innra fyrirtækja- eða deildarnets, tengja margir það við að stjórna upplýsingaleka og innleiða DLP lausnir. Og ef þú reynir að skýra spurninguna og spyr hvernig þú greinir árásir á innra netið, þá mun svarið venjulega vera minnst á innbrotsskynjunarkerfi (IDS). Og það sem var eini möguleikinn fyrir 10-20 árum er að verða tímabundið í dag. Það er skilvirkari, og sums staðar, eini mögulegi möguleikinn til að fylgjast með innra neti - með því að nota flæðisamskiptareglur, sem upphaflega voru hannaðar til að leita að netvandamálum (bilanaleit), en með tímanum breyttist í mjög áhugavert öryggistæki. Við munum tala um hvaða flæðisreglur eru til og hverjar eru betri í að greina netárásir, hvar er best að innleiða flæðisvöktun, hvað á að leita að þegar slíkt kerfi er notað og jafnvel hvernig á að „lyfta“ þessu öllu á heimilisbúnað innan gildissviðs þessarar greinar.
Ég mun ekki dvelja við spurninguna „Hvers vegna er þörf á öryggiseftirliti innri innviða? Svarið virðist vera skýrt. En ef þú vilt samt enn og aftur tryggja að þú getir ekki lifað án þess í dag, stutt myndband um hvernig þú getur komist inn í fyrirtækjanet sem er varið með eldvegg á 17 vegu. Þess vegna munum við gera ráð fyrir að við skiljum að innra eftirlit er nauðsynlegur hlutur og það eina sem er eftir er að skilja hvernig hægt er að skipuleggja það.
Ég myndi draga fram þrjár lykilgagnaheimildir til að fylgjast með innviðum á netstigi:
- „hrá“ umferð sem við tökum og sendum til greiningar í ákveðin greiningarkerfi,
- atburðir úr nettækjum sem umferð fer í gegnum,
- umferðarupplýsingar sem berast í gegnum eina af flæðisreglunum.
Að fanga óunna umferð er vinsælasti kosturinn meðal öryggissérfræðinga, vegna þess að hann birtist sögulega og var sá allra fyrsti. Hefðbundin innbrotsskynjunarkerfi (allra fyrsta innbrotsskynjunarkerfið í atvinnuskyni var NetRanger frá Wheel Group, keypt árið 1998 af Cisco) tóku einmitt þátt í að fanga pakka (og síðar fundir) þar sem leitað var að ákveðnum undirskriftum („afgerandi reglur“ í FSTEC hugtök), merkjaárásir. Auðvitað er hægt að greina hráa umferð ekki aðeins með því að nota IDS, heldur einnig með því að nota önnur verkfæri (til dæmis Wireshark, tcpdum eða NBAR2 virknina í Cisco IOS), en þau skortir venjulega þekkingargrunninn sem aðgreinir upplýsingaöryggisverkfæri frá venjulegu IT tól.
Svo, árásarskynjunarkerfi. Elsta og vinsælasta aðferðin til að greina netárásir, sem gerir gott starf við jaðarinn (sama hvað - fyrirtæki, gagnaver, hluti osfrv.), en mistekst í nútíma skiptum og hugbúnaðarskilgreindum netum. Ef um er að ræða netkerfi sem byggt er á hefðbundnum rofa, verða innviðir árásarskynjara of stórir - þú verður að setja upp skynjara á hverja tengingu við hnútinn sem þú vilt fylgjast með árásum á. Hvaða framleiðandi sem er, mun auðvitað vera fús til að selja þér hundruð og þúsundir skynjara, en ég held að fjárhagsáætlun þín geti ekki staðið undir slíkum útgjöldum. Ég get sagt að jafnvel hjá Cisco (og við erum þróunaraðilar NGIPS) gætum við ekki gert þetta, þó svo að það virðist sem verðmálið sé fyrir okkur. Ég ætti ekki að standa - það er okkar eigin ákvörðun. Að auki vaknar spurningin, hvernig á að tengja skynjarann í þessari útgáfu? Inn í skarðið? Hvað ef skynjarinn sjálfur bilar? Þarftu hjáveitueiningu í skynjaranum? Nota splittera (krakka)? Allt þetta gerir lausnina dýrari og gerir hana óviðráðanlega fyrir fyrirtæki af hvaða stærð sem er.
Þú getur reynt að „hengja“ skynjarann á SPAN/RSPAN/ERSPAN tengi og beina umferð frá nauðsynlegum skiptahöfnum til hans. Þessi valkostur fjarlægir að hluta til vandamálið sem lýst er í fyrri málsgrein, en skapar annað - SPAN tengið getur ekki samþykkt algerlega alla umferðina sem verður send til hennar - það mun ekki hafa næga bandbreidd. Þú verður að fórna einhverju. Annað hvort skildu suma hnútana eftir án eftirlits (þá þarftu að forgangsraða þeim fyrst), eða sendu ekki alla umferð frá hnútnum, heldur aðeins ákveðna tegund. Í öllum tilvikum gætum við misst af einhverjum árásum. Að auki er hægt að nota SPAN tengið fyrir aðrar þarfir. Þar af leiðandi verðum við að endurskoða núverandi svæðisfræði netkerfisins og hugsanlega gera breytingar á því til að ná sem mestu yfir netið þitt með fjölda skynjara sem þú hefur (og samræma þetta við upplýsingatækni).
Hvað ef netið þitt notar ósamhverfar leiðir? Hvað ef þú hefur innleitt eða ætlar að innleiða SDN? Hvað ef þú þarft að fylgjast með sýndarvélum eða gámum þar sem umferð nær alls ekki líkamlega rofanum? Þetta eru spurningar sem hefðbundnum IDS söluaðilum líkar ekki við vegna þess að þeir vita ekki hvernig á að svara þeim. Kannski munu þeir sannfæra þig um að öll þessi tískutækni sé efla og þú þarft þess ekki. Kannski munu þeir tala um nauðsyn þess að byrja smátt. Eða kannski munu þeir segja að þú þurfir að setja öfluga þrist í miðju netsins og beina allri umferð þangað með jafnvægistækjum. Hvaða valkostur sem þér býðst, þú þarft að skilja vel hvernig það hentar þér. Og aðeins eftir það taka ákvörðun um að velja nálgun til að fylgjast með upplýsingaöryggi netkerfisins. Aftur að pakkatöku vil ég segja að þessi aðferð heldur áfram að vera mjög vinsæl og mikilvæg, en megintilgangur hennar er landamæraeftirlit; mörk milli fyrirtækis þíns og internetsins, mörk milli gagnaversins og restarinnar af netkerfinu, mörk milli ferlistýringarkerfisins og fyrirtækjahluta. Á þessum stöðum eiga klassískt IDS/IPS enn tilverurétt og takast vel á við verkefni sín.
Við skulum halda áfram að seinni valkostinum. Greining á atburðum sem koma frá nettækjum er einnig hægt að nota til að greina árásir, en ekki sem aðalkerfi, þar sem það gerir aðeins kleift að greina lítinn flokk af innbrotum. Að auki er það fólgið í einhverri hvarfgirni - árásin verður fyrst að eiga sér stað, síðan verður hún að vera skráð af nettæki, sem á einn eða annan hátt mun gefa til kynna vandamál með upplýsingaöryggi. Það eru nokkrar slíkar leiðir. Þetta gæti verið syslog, RMON eða SNMP. Síðustu tvær samskiptareglur fyrir netvöktun í tengslum við upplýsingaöryggi eru aðeins notaðar ef við þurfum að greina DoS árás á netbúnaðinn sjálfan, þar sem með því að nota RMON og SNMP er td mögulegt að fylgjast með álagi á miðlægum tækisins. örgjörva eða viðmót hans. Þetta er eitt það „ódýrasta“ (allir eru með syslog eða SNMP), en líka sú árangurslausasta af öllum aðferðum til að fylgjast með upplýsingaöryggi innri innviða - margar árásir eru einfaldlega faldar fyrir því. Auðvitað ætti ekki að vanrækta þau og sama syslog greining hjálpar þér að greina tímanlega breytingar á uppsetningu tækisins sjálfs, málamiðlunina á því, en það er ekki mjög hentugur til að greina árásir á allt netið.
Þriðji valkosturinn er að greina upplýsingar um umferð sem fer í gegnum tæki sem styður eina af nokkrum flæðisreglum. Í þessu tilviki, óháð samskiptareglunni, samanstendur þráðauppbyggingin endilega af þremur hlutum:
- Myndun eða útflutningur flæðis. Þetta hlutverk er venjulega úthlutað til beini, rofa eða annars netbúnaðar, sem, með því að senda netumferð í gegnum sig, gerir þér kleift að draga lykilfæribreytur úr því, sem síðan eru sendar til safneiningarinnar. Til dæmis styður Cisco Netflow samskiptareglur ekki aðeins á beinum og rofum, þar á meðal sýndar- og iðnaðarbúnaði, heldur einnig á þráðlausum stjórnendum, eldveggjum og jafnvel netþjónum.
- Söfnunarflæði. Með hliðsjón af því að nútíma net hefur yfirleitt fleiri en eitt nettæki kemur upp vandamálið við að safna og sameina flæði sem er leyst með því að nota svokallaða safnara sem vinna úr mótteknu flæðinu og senda þau síðan til greiningar.
- Flæðisgreining Greiningartækið tekur að sér aðal vitsmunalega verkefnið og dregur ákveðnar ályktanir með því að beita ýmsum reikniritum á strauma. Til dæmis, sem hluti af upplýsingatækniaðgerð, getur slíkur greiningaraðili greint netflöskuhálsa eða greint umferðarálagssniðið til frekari fínstillingar netsins. Og fyrir upplýsingaöryggi getur slíkur greiningartæki greint gagnaleka, útbreiðslu skaðlegs kóða eða DoS árásir.
Ekki halda að þessi þriggja hæða arkitektúr sé of flókinn - allir aðrir valkostir (nema kannski netvöktunarkerfi sem vinna með SNMP og RMON) virka líka í samræmi við það. Við erum með gagnagjafa til greiningar, sem getur verið nettæki eða sjálfstæður skynjari. Við erum með viðvörunarsöfnunarkerfi og stjórnkerfi fyrir alla vöktunarinnviði. Síðustu tveir þættirnir geta verið sameinaðir innan eins hnúts, en í meira og minna stórum netum dreifast þeir venjulega á að minnsta kosti tvö tæki til að tryggja sveigjanleika og áreiðanleika.
Ólíkt pakkagreiningu, sem byggist á því að rannsaka haus- og líkamsgögn hvers pakka og lotunum sem hann samanstendur af, byggir flæðisgreining á því að safna lýsigögnum um netumferð. Hvenær, hversu mikið, hvaðan og hvaðan, hvernig... þessum spurningum er svarað með greiningu á netfjarmælingum með því að nota ýmsar flæðissamskiptareglur. Upphaflega voru þau notuð til að greina tölfræði og finna upplýsingatæknivandamál á netinu, en síðan, eftir því sem greiningaraðferðir þróuðust, varð mögulegt að beita þeim á sömu fjarmælinguna í öryggisskyni. Það er rétt að taka aftur fram að flæðisgreining kemur ekki í stað eða kemur í stað pakkatöku. Hver af þessum aðferðum hefur sitt eigið notkunarsvið. En í tengslum við þessa grein er það flæðisgreining sem hentar best til að fylgjast með innri innviðum. Þú ert með nettæki (hvort sem þau starfa í hugbúnaðarskilgreindri hugmyndafræði eða samkvæmt kyrrstæðum reglum) sem árás getur ekki farið framhjá. Það getur farið framhjá klassískum IDS skynjara, en nettæki sem styður flæðissamskiptareglur getur það ekki. Þetta er kosturinn við þessa aðferð.
Á hinn bóginn, ef þú þarft sönnunargögn fyrir löggæslu eða eigin atviksrannsóknarteymi, geturðu ekki verið án pakkafanga - netfjarmæling er ekki afrit af umferð sem hægt er að nota til að safna sönnunargögnum; það er nauðsynlegt fyrir skjóta uppgötvun og ákvarðanatöku á sviði upplýsingaöryggis. Á hinn bóginn, með því að nota fjarmælingagreiningu, geturðu "skrifað" ekki alla netumferð (ef eitthvað er, þá fjallar Cisco um gagnaver :-), heldur aðeins þá sem á þátt í árásinni. Fjarmælingargreiningartæki í þessu sambandi munu bæta við hefðbundnum pakkafangabúnaði vel og gefa skipanir fyrir sértæka handtöku og geymslu. Annars verður þú að hafa gríðarlegan geymsluinnviði.
Ímyndum okkur netkerfi sem starfar á 250 Mbit/sek. Ef þú vilt geyma allt þetta magn, þá þarftu 31 MB geymslupláss fyrir eina sekúndu af umferðarsendingum, 1,8 GB í eina mínútu, 108 GB í eina klukkustund og 2,6 TB í einn dag. Til að geyma dagleg gögn frá neti með 10 Gbit/s bandbreidd þarftu 108 TB geymslupláss. En sumir eftirlitsaðilar krefjast þess að öryggisgögn séu geymd í mörg ár... Upptaka á eftirspurn, sem flæðisgreining hjálpar þér að innleiða, hjálpar til við að draga úr þessum gildum um stærðargráður. Við the vegur, ef við tölum um hlutfallið á rúmmáli skráðra netfjarmælingagagna og fullkominnar gagnatöku, þá er það um það bil 1 til 500. Fyrir sömu gildi sem gefin eru upp hér að ofan, geymir heildarrit af allri daglegri umferð verður 5 og 216 GB, í sömu röð (þú getur jafnvel tekið það upp á venjulegu flash-drifi ).
Ef fyrir verkfæri til að greina hrá netgögn er aðferðin við að fanga þau nánast sú sama frá seljanda til söluaðila, þá er staðan önnur þegar um er að ræða flæðisgreiningu. Það eru nokkrir möguleikar fyrir flæðisreglur, muninn sem þú þarft að vita um í tengslum við öryggi. Vinsælast er Netflow siðareglur þróaðar af Cisco. Það eru nokkrar útgáfur af þessari samskiptareglu, mismunandi hvað varðar getu þeirra og magn umferðarupplýsinga sem skráðar eru. Núverandi útgáfa er sú níunda (Netflow v9), á grundvelli þess var iðnaðarstaðallinn Netflow v10, einnig þekktur sem IPFIX, þróaður. Í dag styðja flestir netframleiðendur Netflow eða IPFIX í búnaði sínum. En það eru ýmsir aðrir valkostir fyrir flæðisreglur - sFlow, jFlow, cFlow, rFlow, NetStream o.s.frv., þar af er sFlow vinsælastur. Það er þessi tegund sem er oftast studd af innlendum framleiðendum netbúnaðar vegna auðveldrar framkvæmdar. Hver er lykilmunurinn á Netflow, sem er orðinn raunverulegur staðall, og sFlow? Ég myndi draga fram nokkur lykilatriði. Í fyrsta lagi hefur Netflow reiti sem hægt er að sérsníða af notendum öfugt við fasta reiti í sFlow. Og í öðru lagi, og það er það mikilvægasta í okkar tilfelli, safnar sFlow svokallaðri sýnishornsfjarmælingu; öfugt við hið ósýnilega fyrir Netflow og IPFIX. Hver er munurinn á þeim?
Ímyndaðu þér að þú ákveður að lesa bókina “” samstarfsmanna minna - Gary McIntyre, Joseph Munitz og Nadem Alfardan (þú getur halað niður hluta bókarinnar af hlekknum). Þú hefur þrjá möguleika til að ná markmiði þínu - lestu alla bókina, flettu í gegnum hana, stoppaðu á 10. eða 20. hverri síðu eða reyndu að finna endursögn á lykilhugtökum á bloggi eða þjónustu eins og SmartReading. Þannig að ósýnileg fjarmæling er að lesa hverja „síðu“ netumferðar, það er að greina lýsigögn fyrir hvern pakka. Sýndarfjarmæling er sértæk rannsókn á umferð í von um að valin sýni innihaldi það sem þú þarft. Það fer eftir hraða rásarinnar, sýnishorn af fjarmælingum verður sent til greiningar á hverjum 64., 200., 500., 1000., 2000. eða jafnvel 10000.
Í samhengi við upplýsingaöryggiseftirlit þýðir þetta að sýnishorn af fjarmælingum hentar vel til að greina DDoS árásir, skanna og dreifa skaðlegum kóða, en gæti misst af atóm- eða fjölpakkaárásum sem voru ekki með í sýninu sem sent var til greiningar. Ósýnileg fjarmæling hefur ekki slíka ókosti. Með þessu er svið greindra árása miklu breiðari. Hér er stuttur listi yfir atburði sem hægt er að greina með því að nota netfjarmælingargreiningartæki.
Auðvitað mun einhver opinn uppspretta Netflow greiningartæki ekki leyfa þér að gera þetta, þar sem aðalverkefni hans er að safna fjarmælingum og framkvæma grunngreiningu á því frá upplýsingatæknisjónarmiði. Til að bera kennsl á ógnir upplýsingaöryggis byggðar á flæði er nauðsynlegt að útbúa greiningartækið með ýmsum vélum og reikniritum, sem munu bera kennsl á netöryggisvandamál út frá stöðluðum eða sérsniðnum Netflow sviðum, auðga staðlað gögn með utanaðkomandi gögnum frá ýmsum aðilum Threat Intelligence o.s.frv.
Þess vegna, ef þú hefur val, veldu þá Netflow eða IPFIX. En jafnvel þótt búnaðurinn þinn virki aðeins með sFlow, eins og innlendir framleiðendur, þá geturðu jafnvel í þessu tilfelli notið góðs af honum í öryggissamhengi.
Sumarið 2019 greindi ég þá möguleika sem rússneskir netvélbúnaðarframleiðendur hafa og allir, að NSG, Polygon og Craftway undanskildum, tilkynntu um stuðning við sFlow (að minnsta kosti Zelax, Natex, Eltex, QTech, Rusteleteh).
Næsta spurning sem þú munt standa frammi fyrir er hvar á að innleiða flæðisstuðning í öryggisskyni? Reyndar er spurningin ekki alveg rétt varpað fram. Nútímabúnaður styður næstum alltaf flæðisreglur. Þess vegna myndi ég endurorða spurninguna á annan hátt - hvar er árangursríkast að safna fjarmælingum frá öryggissjónarmiði? Svarið verður nokkuð augljóst - á aðgangsstigi, þar sem þú munt sjá 100% af allri umferð, þar sem þú munt hafa nákvæmar upplýsingar um vélar (MAC, VLAN, tengi auðkenni), þar sem þú getur jafnvel fylgst með P2P umferð milli gestgjafa, sem er mikilvægt til að skanna uppgötvun og dreifingu skaðlegs kóða. Á kjarnastigi gætirðu einfaldlega ekki séð hluta umferðarinnar, en á jaðarstigi muntu sjá fjórðung af allri netumferð þinni. En ef þú ert af einhverjum ástæðum með erlend tæki á netinu þínu sem leyfa árásarmönnum að „koma inn og út“ án þess að fara framhjá jaðarnum, þá mun það ekki gefa þér neitt að greina fjarmælinguna frá því. Þess vegna er mælt með því að virkja söfnun fjarmælinga á aðgangsstigi til að ná hámarksþekju. Á sama tíma er rétt að taka fram að jafnvel þótt við séum að tala um sýndarvæðingu eða gáma, þá er flæðisstuðningur líka oft að finna í nútíma sýndarrofum, sem gerir þér kleift að stjórna umferð þar líka.
En þar sem ég vakti umræðuna þarf ég að svara spurningunni: hvað ef búnaðurinn, líkamlegur eða sýndarbúnaður, styður ekki flæðisreglur? Eða er það bannað að taka það inn (til dæmis í iðnaðarhlutum til að tryggja áreiðanleika)? Eða leiðir það til mikils CPU-álags að kveikja á því (þetta gerist á eldri vélbúnaði)? Til að leysa þetta vandamál eru sérhæfðir sýndarskynjarar (flæðiskynjarar), sem eru í rauninni venjulegir klofnar sem fara í gegnum sig og senda hana í formi flæðis til safneiningarinnar. Það er satt, í þessu tilfelli fáum við öll vandamálin sem við ræddum um hér að ofan í tengslum við pakkatökutæki. Það er, þú þarft að skilja ekki aðeins kosti flæðigreiningartækni heldur einnig takmarkanir hennar.
Annað atriði sem mikilvægt er að muna þegar talað er um flæðigreiningartæki. Ef við notum EPS mæligildið (atburður á sekúndu) í tengslum við hefðbundnar leiðir til að búa til öryggisatburði, þá á þessi vísir ekki við um fjarmælingagreiningu; það er skipt út fyrir FPS (flæði á sekúndu). Eins og í tilviki EPS er ekki hægt að reikna það út fyrirfram, en þú getur áætlað áætlaða fjölda þráða sem tiltekið tæki býr til eftir verkefnum þess. Þú getur fundið töflur á netinu með áætluðum gildum fyrir mismunandi gerðir fyrirtækjatækja og skilyrða, sem gerir þér kleift að áætla hvaða leyfi þú þarft fyrir greiningartæki og hver arkitektúr þeirra verður? Staðreyndin er sú að IDS skynjarinn er takmarkaður af ákveðinni bandbreidd sem hann getur „togað“ og flæðisafnarinn hefur sínar takmarkanir sem þarf að skilja. Þess vegna eru í stórum, landfræðilega dreifðum netum venjulega nokkrir safnarar. Þegar ég lýsti , Ég hef þegar gefið upp fjölda safnara okkar - þeir eru 21. Og þetta er fyrir netkerfi sem er dreift um fimm heimsálfur og telur um hálfa milljón virkra tækja).
Við notum okkar eigin lausn sem Netflow eftirlitskerfi , sem beinist sérstaklega að því að leysa öryggisvandamál. Það hefur margar innbyggðar vélar til að greina afbrigðilega, grunsamlega og greinilega illgjarna virkni, sem gerir því kleift að greina margs konar ógnir - allt frá dulkóðun til upplýsingaleka, allt frá útbreiðslu illgjarns kóða til svika. Eins og flestir flæðigreiningartæki er Stealthwatch smíðað samkvæmt þriggja stiga kerfi (rafall - safnari - greiningartæki), en það er bætt við fjölda áhugaverðra eiginleika sem eru mikilvægir í samhengi við efnið sem er til skoðunar. Í fyrsta lagi samþættist það pakkafangalausnum (eins og Cisco Security Packet Analyzer), sem gerir þér kleift að taka upp valdar netlotur til síðari ítarlegrar rannsóknar og greiningar. Í öðru lagi, sérstaklega til að auka öryggisverkefni, höfum við þróað sérstaka nvzFlow samskiptareglur, sem gerir þér kleift að „útvarpa“ virkni forrita á endahnútum (þjónum, vinnustöðvum osfrv.) í fjarmælingar og senda það til safnarans til frekari greiningar. Ef í upprunalegri útgáfu Stealthwatch virkar með hvaða flæðissamskiptareglum sem er (sFlow, rFlow, Netflow, IPFIX, cFlow, jFlow, NetStream) á netstigi, þá leyfir nvzFlow stuðningur gagnafylgni einnig á hnútastigi, þar með. auka skilvirkni alls kerfisins og sjá fleiri árásir en hefðbundnir netflæðisgreiningartæki.
Ljóst er að þegar talað er um Netflow greiningarkerfi út frá öryggissjónarmiði er markaðurinn ekki bundinn við eina lausn frá Cisco. Þú getur notað bæði viðskiptalausnir og ókeypis eða deilihugbúnaðarlausnir. Það er frekar skrítið ef ég nefni lausnir samkeppnisaðila sem dæmi á Cisco blogginu, svo ég ætla að segja nokkur orð um hvernig hægt er að greina netfjarmælingar með því að nota tvö vinsæl, svipuð að nafni, en samt ólík verkfæri - SiLK og ELK.
SiLK er verkfærasett (System for Internet-Level Knowledge) fyrir umferðargreiningu, þróað af bandaríska CERT/CC og styður, í tengslum við greinina í dag, Netflow (5. og 9., vinsælustu útgáfurnar), IPFIX og sFlow og nota ýmis tól (rwfilter, rwcount, rwflowpack o.s.frv.) til að framkvæma ýmsar aðgerðir á netfjarmælingum til að greina merki um óheimilar aðgerðir í því. En það eru nokkur mikilvæg atriði sem þarf að hafa í huga. SiLK er skipanalínuverkfæri sem framkvæmir greiningu á netinu með því að slá inn skipanir eins og þessa (uppgötvun ICMP pakka stærri en 200 bæti):
rwfilter --flowtypes=all/all --proto=1 --bytes-per-packet=200- --pass=stdout | rwrwcut --fields=sIP,dIP,iType,iCode --num-recs=15
ekki mjög þægilegt. Þú getur notað iSiLK GUI, en það mun ekki gera líf þitt mikið auðveldara, aðeins leysa sjónræna aðgerðina og koma ekki í stað sérfræðingsins. Og þetta er annað atriðið. Ólíkt viðskiptalausnum, sem nú þegar hafa traustan greiningargrunn, reiknirit til að greina frávik, samsvarandi verkflæði o.s.frv., þegar um SiLK er að ræða, verður þú að gera allt þetta sjálfur, sem mun krefjast aðeins öðruvísi hæfni frá þér en að nota þegar tilbúið- til að nota verkfæri. Þetta er hvorki gott né slæmt - þetta er eiginleiki næstum hvaða ókeypis tól sem er sem gerir ráð fyrir að þú vitir hvað þú átt að gera, og það mun aðeins hjálpa þér með þetta (auglýsingatól eru minna háð hæfni notenda þess, þó þeir geri líka ráð fyrir að sérfræðingar skilji að minnsta kosti grunnatriði netrannsókna og eftirlits). En snúum okkur aftur að SiLK. Vinnulota sérfræðingsins með það lítur svona út:
- Að móta tilgátu. Við verðum að skilja hvað við munum leita að innan netfjarmælinga, þekkja einstaka eiginleika sem við munum bera kennsl á tiltekin frávik eða ógnir.
- Að byggja fyrirmynd. Eftir að hafa mótað tilgátu, forritum við hana með því að nota sama Python, skel eða önnur verkfæri sem ekki eru innifalin í SiLK.
- Prófanir. Nú er röðin komin að því að kanna réttmæti tilgátunnar okkar, sem er staðfest eða hrakin með því að nota SiLK tól sem byrja á 'rw', 'set', 'bag'.
- Greining á raunverulegum gögnum. Í iðnrekstri hjálpar SiLK okkur að bera kennsl á eitthvað og sérfræðingurinn verður að svara spurningunum „fundum við það sem við bjuggumst við?“, „Samsvarar þetta tilgátu okkar?“, „Hvernig á að fækka fölskum jákvæðum?“, „Hvernig til að bæta viðurkenningarstigið? » og svo framvegis.
- Umbætur. Á lokastigi bætum við það sem var gert fyrr - við búum til sniðmát, bætum og fínstillum kóðann, endurformum og skýrum tilgátuna o.s.frv.
Þessi hringrás mun einnig eiga við um Cisco Stealthwatch, aðeins sú síðasta gerir þessi fimm skref sjálfvirkt að hámarki, dregur úr fjölda villna greiningaraðila og eykur skilvirkni atviksgreiningar. Til dæmis, í SiLK er hægt að auðga nettölfræði með ytri gögnum um skaðlega IP-tölu með handskrifuðum skriftum og í Cisco Stealthwatch er það innbyggð aðgerð sem sýnir strax viðvörun ef netumferð inniheldur samskipti við IP-tölur af svarta listanum.
Ef þú ferð hærra í „greidda“ pýramídanum fyrir flæðisgreiningarhugbúnað, þá verður eftir algerlega ókeypis SiLK deilihugbúnaður ELK, sem samanstendur af þremur lykilþáttum - Elasticsearch (flokkun, leit og gagnagreining), Logstash (gagnainntak/úttak) ) og Kibana (sjónmynd). Ólíkt SiLK, þar sem þú þarft að skrifa allt sjálfur, hefur ELK nú þegar mörg tilbúin bókasöfn/einingar (sum greidd, önnur ekki) sem gera sjálfvirkan greiningu á netfjarmælingum. Til dæmis, GeoIP sían í Logstash gerir þér kleift að tengja vöktaðar IP tölur við landfræðilega staðsetningu þeirra (Stealthwatch hefur þennan innbyggða eiginleika).
ELK er líka með nokkuð stórt samfélag sem er að klára þá hluti sem vantar fyrir þessa vöktunarlausn. Til dæmis, til að vinna með Netflow, IPFIX og sFlow geturðu notað eininguna , ef þú ert ekki ánægður með Logstash Netflow Module, sem styður aðeins Netflow.
Þó að það veiti meiri skilvirkni við að safna flæði og leita í því, skortir ELK eins og er ríka innbyggða greiningu til að greina frávik og ógnir í netfjarmælingum. Það er, eftir lífsferilinn sem lýst er hér að ofan, verður þú að lýsa sjálfstætt brotalíkön og nota það síðan í bardagakerfinu (það eru engin innbyggð líkön þar).
Það eru auðvitað til flóknari viðbætur fyrir ELK, sem innihalda nú þegar nokkrar gerðir til að greina frávik í netfjarmælingum, en slíkar viðbætur kosta peninga og hér er spurning hvort leikurinn sé þess virði kertið virði - skrifaðu svipað líkan sjálfur, keyptu það útfærslu fyrir vöktunartólið þitt, eða keyptu tilbúna lausn af netumferðargreiningarflokknum.
Almennt vil ég ekki blanda mér í þá umræðu að það sé betra að eyða peningum og kaupa tilbúna lausn til að fylgjast með frávikum og ógnum í netfjarmælingum (til dæmis Cisco Stealthwatch) eða finna það út sjálfur og sérsníða það sama. SiLK, ELK eða nfdump eða OSU Flow Tools fyrir hverja nýja ógn (ég er að tala um síðustu tvær þeirra síðasta sinn)? Hver og einn velur fyrir sig og hver og einn hefur sínar ástæður fyrir því að velja einhvern af þessum tveimur valkostum. Mig langaði bara að sýna fram á að netfjarmæling er mjög mikilvægt tæki til að tryggja netöryggi innri innviða þinna og þú ættir ekki að vanrækja það, til að komast ekki á lista yfir fyrirtæki sem nefna nafnið í fjölmiðlum ásamt nafngiftunum " tölvusnápur", "samræmist ekki upplýsingaöryggiskröfum" ", "hugsar ekki um öryggi gagna þeirra og viðskiptavina."
Til að draga saman, langar mig að telja upp helstu ráðin sem þú ættir að fylgja þegar þú byggir upp upplýsingaöryggiseftirlit með innri innviðum þínum:
- Ekki takmarka þig bara við jaðarinn! Notaðu (og veldu) netkerfi ekki aðeins til að flytja umferð frá punkti A til punktar B, heldur einnig til að taka á netöryggismálum.
- Kynntu þér núverandi eftirlitskerfi upplýsingaöryggis í netbúnaði þínum og notaðu þær.
- Fyrir innra eftirlit skaltu velja fjarmælingargreiningu - það gerir þér kleift að greina allt að 80-90% af öllum netupplýsingaöryggisatvikum, á meðan þú gerir það sem er ómögulegt þegar þú tekur netpakka og sparar pláss til að geyma alla upplýsingaöryggisatburði.
- Til að fylgjast með flæði, notaðu Netflow v9 eða IPFIX - þau veita meiri upplýsingar í öryggissamhengi og gera þér kleift að fylgjast ekki aðeins með IPv4, heldur einnig IPv6, MPLS o.s.frv.
- Notaðu ósýnilega flæðissamskiptareglur - það veitir frekari upplýsingar til að greina ógnir. Til dæmis, Netflow eða IPFIX.
- Athugaðu álagið á netbúnaðinn þinn - hann gæti ekki séð um flæðissamskiptareglur líka. Íhugaðu síðan að nota sýndarskynjara eða Netflow Generation Appliance.
- Innleiða stjórn fyrst og fremst á aðgangsstigi - þetta gefur þér tækifæri til að sjá 100% af allri umferð.
- Ef þú hefur ekkert val og þú ert að nota rússneskan netbúnað, veldu þá einn sem styður flæðisamskiptareglur eða hefur SPAN/RSPAN tengi.
- Sameina innbrots-/árásaskynjunar-/forvarnarkerfi við jaðra og flæðisgreiningarkerfi í innra netinu (þar á meðal í skýjunum).
Varðandi síðustu ábendinguna vil ég gefa mynd sem ég hef þegar gefið áður. Þú sérð að ef áður fyrr byggði Cisco upplýsingaöryggisþjónustan nánast alfarið upplýsingaöryggiseftirlitskerfi sitt á grundvelli innbrotsskynjunarkerfa og undirskriftaraðferða, þá eru þau nú aðeins 20% atvika. Önnur 20% falla á flæðigreiningarkerfi, sem bendir til þess að þessar lausnir séu ekki duttlunga, heldur raunverulegt tæki í starfsemi upplýsingaöryggisþjónustu nútímafyrirtækis. Þar að auki hefur þú það mikilvægasta fyrir framkvæmd þeirra - netinnviði, fjárfestingar sem hægt er að vernda frekar með því að úthluta upplýsingaöryggiseftirlitsaðgerðum á netið.
Ég snerti ekki sérstaklega viðbrögð við frávikum eða ógnum sem greinast í netflæði, en ég held að það sé nú þegar ljóst að eftirlit ætti ekki að enda aðeins með því að greina ógn. Því ætti að fylgja svar og helst í sjálfvirkri eða sjálfvirkri stillingu. En þetta er efni fyrir sérstaka grein.
Aðrar upplýsingar:
PS. Ef það er auðveldara fyrir þig að heyra allt sem var skrifað hér að ofan, þá geturðu horft á klukkutímalanga kynninguna sem var grundvöllur þessarar athugasemdar.
Heimild: www.habr.com