Kur bëhet fjalë për monitorimin e sigurisë së një rrjeti të brendshëm korporate ose departamenti, shumë e lidhin atë me kontrollin e rrjedhjeve të informacionit dhe zbatimin e zgjidhjeve DLP. Dhe nëse përpiqeni të sqaroni pyetjen dhe pyesni se si zbuloni sulmet në rrjetin e brendshëm, atëherë përgjigjja, si rregull, do të jetë një përmendje e sistemeve të zbulimit të ndërhyrjeve (IDS). Dhe ajo që ishte opsioni i vetëm 10-20 vjet më parë po bëhet një anakronizëm sot. Ekziston një opsion më efektiv, dhe në disa vende, i vetmi opsion i mundshëm për monitorimin e një rrjeti të brendshëm - përdorimi i protokolleve të rrjedhës, të cilat fillimisht ishin krijuar për të kërkuar problemet e rrjetit (zgjidhja e problemeve), por me kalimin e kohës u shndërruan në një mjet shumë interesant sigurie. Ne do të flasim për protokollet e rrjedhës dhe cilat janë më të mira në zbulimin e sulmeve në rrjet, ku është më mirë të zbatohet monitorimi i rrjedhës, çfarë të kërkoni kur vendosni një skemë të tillë dhe madje edhe si të "ngreni" të gjitha këto në pajisjet shtëpiake brenda objektit të këtij neni.
Nuk do të ndalem në pyetjen “Pse nevojitet monitorimi i sigurisë së infrastrukturës së brendshme?” Përgjigja duket se është e qartë. Por nëse, megjithatë, dëshironi të siguroheni edhe një herë që sot nuk mund të jetoni pa të, një video e shkurtër se si mund të depërtoni në një rrjet të korporatës të mbrojtur nga një mur zjarri në 17 mënyra. Prandaj, do të supozojmë se e kuptojmë se monitorimi i brendshëm është një gjë e nevojshme dhe ajo që mbetet është të kuptojmë se si mund të organizohet.
Do të theksoja tre burime kryesore të të dhënave për monitorimin e infrastrukturës në nivel rrjeti:
- Trafiku "i papërpunuar" që ne kapim dhe dorëzojmë për analizë në sisteme të caktuara analizash,
- ngjarje nga pajisjet e rrjetit nëpër të cilat kalon trafiku,
- informacioni i trafikut të marrë nëpërmjet një prej protokolleve të rrjedhës.
Kapja e trafikut të papërpunuar është opsioni më i popullarizuar midis specialistëve të sigurisë, sepse historikisht u shfaq dhe ishte i pari. Sistemet konvencionale të zbulimit të ndërhyrjeve në rrjet (sistemi i parë komercial i zbulimit të ndërhyrjeve ishte NetRanger nga Wheel Group, i blerë në 1998 nga Cisco) ishin të angazhuar pikërisht në kapjen e paketave (dhe seancat e mëvonshme) në të cilat kërkoheshin disa nënshkrime ("rregulla vendimtare" në Terminologjia FSTEC), sulmet sinjalizuese. Sigurisht, ju mund të analizoni trafikun e papërpunuar jo vetëm duke përdorur IDS, por edhe duke përdorur mjete të tjera (për shembull, Wireshark, tcpdum ose funksionalitetin NBAR2 në Cisco IOS), por zakonisht atyre u mungon baza e njohurive që dallon një mjet sigurie informacioni nga një mjet i rregullt. mjet IT.
Pra, sistemet e zbulimit të sulmit. Metoda më e vjetër dhe më e popullarizuar e zbulimit të sulmeve në rrjet, e cila bën një punë të mirë në perimetër (pa marrë parasysh se çfarë - korporata, qendra e të dhënave, segmenti, etj.), por dështon në rrjetet moderne të komutuara dhe të përcaktuara nga softueri. Në rastin e një rrjeti të ndërtuar në bazë të ndërprerësve konvencionalë, infrastruktura e sensorëve të zbulimit të sulmit bëhet shumë e madhe - do t'ju duhet të instaloni një sensor në secilën lidhje me nyjen në të cilën dëshironi të monitoroni sulmet. Çdo prodhues, sigurisht, do të jetë i lumtur t'ju shesë qindra e mijëra sensorë, por mendoj se buxheti juaj nuk mund të përballojë shpenzime të tilla. Mund të them që edhe në Cisco (dhe ne jemi zhvilluesit e NGIPS) nuk mund ta bënim këtë, megjithëse duket se çështja e çmimit është para nesh. Unë nuk duhet të qëndroj - është vendimi ynë. Për më tepër, lind pyetja, si ta lidhni sensorin në këtë version? Në hendek? Po nëse vetë sensori dështon? Kërkohet një modul anashkalimi në sensor? Përdorni ndarës (trokitje e lehtë)? E gjithë kjo e bën zgjidhjen më të shtrenjtë dhe e bën atë të papërballueshme për një kompani të çdo madhësie.
Mund të provoni të "varni" sensorin në një portë SPAN/RSPAN/ERSPAN dhe të drejtoni trafikun nga portat e kërkuara të kalimit në të. Ky opsion heq pjesërisht problemin e përshkruar në paragrafin e mëparshëm, por paraqet një tjetër - porti SPAN nuk mund të pranojë absolutisht të gjithë trafikun që do t'i dërgohet - nuk do të ketë gjerësi bande të mjaftueshme. Do t'ju duhet të sakrifikoni diçka. Ose lini disa nga nyjet pa monitorim (atëherë duhet t'i jepni përparësi atyre së pari), ose dërgoni jo të gjithë trafikun nga nyja, por vetëm një lloj të caktuar. Në çdo rast, mund të na mungojnë disa sulme. Përveç kësaj, porti SPAN mund të përdoret për nevoja të tjera. Si rezultat, ne do të duhet të rishikojmë topologjinë ekzistuese të rrjetit dhe ndoshta të bëjmë rregullime në të në mënyrë që të mbulojmë rrjetin tuaj në maksimum me numrin e sensorëve që keni (dhe ta koordinojmë këtë me IT).
Po sikur rrjeti juaj përdor rrugë asimetrike? Po sikur të keni zbatuar ose po planifikoni të zbatoni SDN? Po sikur të keni nevojë të monitoroni makinat ose kontejnerët e virtualizuar, trafiku i të cilëve nuk arrin fare në çelësin fizik? Këto janë pyetje që shitësve tradicionalë të IDS nuk u pëlqejnë sepse nuk dinë t'u përgjigjen atyre. Ndoshta ata do t'ju bindin se të gjitha këto teknologji në modë janë reklamë dhe ju nuk keni nevojë për të. Ndoshta ata do të flasin për nevojën për të filluar pak. Ose ndoshta ata do të thonë se duhet të vendosni një shirës të fuqishëm në qendër të rrjetit dhe të drejtoni të gjithë trafikun drejt tij duke përdorur balancues. Çfarëdo opsioni që ju ofrohet, duhet të kuptoni qartë se si ju përshtatet. Dhe vetëm pas kësaj merrni një vendim për zgjedhjen e një qasjeje për monitorimin e sigurisë së informacionit të infrastrukturës së rrjetit. Pas kthimit në kapjen e paketave, dua të them që kjo metodë vazhdon të jetë shumë e popullarizuar dhe e rëndësishme, por qëllimi kryesor i saj është kontrolli i kufirit; kufijtë midis organizatës suaj dhe internetit, kufijtë midis qendrës së të dhënave dhe pjesës tjetër të rrjetit, kufijtë midis sistemit të kontrollit të procesit dhe segmentit të korporatës. Në këto vende, ID -të klasike/IP -të ende kanë të drejtë të ekzistojnë dhe të përballojnë mirë me detyrat e tyre.
Le të kalojmë në opsionin e dytë. Analiza e ngjarjeve që vijnë nga pajisjet e rrjetit mund të përdoret gjithashtu për qëllime të zbulimit të sulmeve, por jo si mekanizmi kryesor, pasi lejon zbulimin e vetëm një klase të vogël ndërhyrjesh. Për më tepër, është e natyrshme në njëfarë reaktiviteti - fillimisht duhet të ndodhë sulmi, pastaj duhet të regjistrohet nga një pajisje rrjeti, e cila në një mënyrë ose në një tjetër do të sinjalizojë një problem me sigurinë e informacionit. Ka disa mënyra të tilla. Ky mund të jetë syslog, RMON ose SNMP. Dy protokollet e fundit për monitorimin e rrjetit në kontekstin e sigurisë së informacionit përdoren vetëm nëse duhet të zbulojmë një sulm DoS në vetë pajisjet e rrjetit, pasi duke përdorur RMON dhe SNMP është e mundur, për shembull, të monitorohet ngarkesa në qendrën e pajisjes. procesori ose ndërfaqet e tij. Kjo është një nga "më të lirat" (të gjithë kanë syslog ose SNMP), por edhe më joefektive nga të gjitha metodat e monitorimit të sigurisë së informacionit të infrastrukturës së brendshme - shumë sulme thjesht fshihen prej saj. Natyrisht, ato nuk duhen neglizhuar, dhe e njëjta analizë syslog ju ndihmon të identifikoni me kohë ndryshimet në konfigurimin e vetë pajisjes, komprometimin e tij, por nuk është shumë i përshtatshëm për zbulimin e sulmeve në të gjithë rrjetin.
Opsioni i tretë është të analizoni informacionin rreth trafikut që kalon përmes një pajisjeje që mbështet një nga disa protokolle të rrjedhës. Në këtë rast, pavarësisht nga protokolli, infrastruktura e filetimit përbëhet domosdoshmërisht nga tre komponentë:
- Gjenerimi ose eksporti i rrjedhës. Ky rol zakonisht i caktohet një router, ndërprerës ose pajisje tjetër rrjeti, e cila, duke kaluar trafikun e rrjetit përmes vetvetes, ju lejon të nxirrni parametrat kryesorë prej tij, të cilët më pas transmetohen në modulin e grumbullimit. Për shembull, Cisco mbështet protokollin Netflow jo vetëm në ruterat dhe çelsat, duke përfshirë ato virtuale dhe industriale, por edhe në kontrollorët me valë, muret e zjarrit dhe madje edhe serverët.
- Rrjedha e koleksionit. Duke marrë parasysh se një rrjet modern zakonisht ka më shumë se një pajisje rrjeti, lind problemi i grumbullimit dhe konsolidimit të flukseve, i cili zgjidhet duke përdorur të ashtuquajturat kolektorë, të cilët përpunojnë flukset e marra dhe më pas i transmetojnë ato për analizë.
- Analiza e rrjedhës Analizuesi merr përsipër detyrën kryesore intelektuale dhe, duke aplikuar algoritme të ndryshme në rrjedhat, nxjerr përfundime të caktuara. Për shembull, si pjesë e një funksioni IT, një analizues i tillë mund të identifikojë pengesat e rrjetit ose të analizojë profilin e ngarkesës së trafikut për optimizim të mëtejshëm të rrjetit. Dhe për sigurinë e informacionit, një analizues i tillë mund të zbulojë rrjedhjet e të dhënave, përhapjen e kodit me qëllim të keq ose sulmet DoS.
Mos mendoni se kjo arkitekturë me tre nivele është shumë e ndërlikuar - të gjitha opsionet e tjera (përveç, ndoshta, sistemet e monitorimit të rrjetit që punojnë me SNMP dhe RMON) gjithashtu funksionojnë sipas saj. Ne kemi një gjenerator të dhënash për analizë, i cili mund të jetë një pajisje rrjeti ose një sensor i pavarur. Ne kemi një sistem grumbullimi alarmi dhe një sistem menaxhimi për të gjithë infrastrukturën e monitorimit. Dy komponentët e fundit mund të kombinohen brenda një nyje të vetme, por në rrjete pak a shumë të mëdha ato zakonisht shpërndahen në të paktën dy pajisje për të siguruar shkallëzim dhe besueshmëri.
Ndryshe nga analiza e paketave, e cila bazohet në studimin e të dhënave të kokës dhe trupit të secilës paketë dhe seancat nga të cilat ajo përbëhet, analiza e rrjedhës mbështetet në mbledhjen e meta të dhënave rreth trafikut të rrjetit. Kur, sa, nga dhe ku, si... këto janë pyetjet që përgjigjet analiza e telemetrisë së rrjetit duke përdorur protokolle të ndryshme të rrjedhës. Fillimisht, ato u përdorën për të analizuar statistikat dhe për të gjetur probleme të TI-së në rrjet, por më pas, me zhvillimin e mekanizmave analitikë, u bë e mundur aplikimi i tyre në të njëjtën telemetri për qëllime sigurie. Vlen të përmendet përsëri se analiza e rrjedhës nuk zëvendëson ose zëvendëson kapjen e paketave. Secila prej këtyre metodave ka fushën e vet të aplikimit. Por në kontekstin e këtij artikulli, është analiza e rrjedhës që është më e përshtatshme për monitorimin e infrastrukturës së brendshme. Ju keni pajisje të rrjetit (pavarësisht nëse ato funksionojnë në një paradigmë të përcaktuar nga softveri ose sipas rregullave statike) që një sulm nuk mund të anashkalojë. Mund të anashkalojë një sensor klasik IDS, por një pajisje e rrjetit që mbështet protokollin e rrjedhës nuk mund. Ky është avantazhi i kësaj metode.
Nga ana tjetër, nëse keni nevojë për prova për zbatimin e ligjit ose ekipin tuaj të hetimit të incidentit, nuk mund të bëni pa kapjen e paketave - telemetria e rrjetit nuk është një kopje e trafikut që mund të përdoret për të mbledhur prova; është e nevojshme për zbulimin dhe vendimmarrjen e shpejtë në fushën e sigurisë së informacionit. Nga ana tjetër, duke përdorur analizën e telemetrisë, ju mund të "shkruani" jo të gjithë trafikun e rrjetit (nëse ka ndonjë gjë, Cisco merret me qendrat e të dhënave :-), por vetëm atë që përfshihet në sulm. Mjetet e analizës së telemetrisë në këtë drejtim do të plotësojnë mirë mekanizmat tradicionalë të kapjes së paketave, duke dhënë komanda për kapjen dhe ruajtjen selektive. Përndryshe, do t'ju duhet të keni një infrastrukturë kolosale magazinimi.
Le të imagjinojmë një rrjet që funksionon me një shpejtësi prej 250 Mbit/sek. Nëse dëshironi të ruani gjithë këtë vëllim, atëherë do t'ju nevojiten 31 MB hapësirë ruajtëse për një sekondë transmetimi të trafikut, 1,8 GB për një minutë, 108 GB për një orë dhe 2,6 TB për një ditë. Për të ruajtur të dhënat ditore nga një rrjet me një gjerësi brezi prej 10 Gbit/s, do t'ju duhet 108 TB hapësirë ruajtëse. Por disa rregullatorë kërkojnë ruajtjen e të dhënave të sigurisë për vite me radhë... Regjistrimi sipas kërkesës, të cilin analiza e rrjedhës ju ndihmon ta zbatoni, ndihmon në uljen e këtyre vlerave sipas rendit të madhësisë. Nga rruga, nëse flasim për raportin e vëllimit të të dhënave telemetrike të rrjetit të regjistruar dhe kapjen e plotë të të dhënave, atëherë është afërsisht 1 deri në 500. Për të njëjtat vlera të dhëna më sipër, ruajtja e një transkripti të plotë të të gjithë trafikut ditor do të jetë përkatësisht 5 dhe 216 GB (mund ta regjistroni edhe në një flash drive të rregullt).
Nëse për mjetet për analizimin e të dhënave të papërpunuara të rrjetit, metoda e kapjes së tyre është pothuajse e njëjtë nga shitësi në shitës, atëherë në rastin e analizës së rrjedhës situata është e ndryshme. Ekzistojnë disa opsione për protokollet e rrjedhës, ndryshimet në të cilat duhet të dini në kontekstin e sigurisë. Më i popullarizuari është protokolli Netflow i zhvilluar nga Cisco. Ekzistojnë disa versione të këtij protokolli, që ndryshojnë në aftësitë e tyre dhe sasinë e informacionit të trafikut të regjistruar. Versioni aktual është i nënti (Netflow v9), mbi bazën e të cilit u zhvillua standardi i industrisë Netflow v10, i njohur gjithashtu si IPFIX. Sot, shumica e shitësve të rrjetit mbështesin Netflow ose IPFIX në pajisjet e tyre. Por ka opsione të tjera të ndryshme për protokollet e rrjedhës - sFlow, jFlow, cFlow, rFlow, NetStream, etj., nga të cilat sFlow është më i popullarizuari. Është ky lloj që më së shpeshti mbështetet nga prodhuesit vendas të pajisjeve të rrjetit për shkak të lehtësisë së zbatimit të tij. Cilat janë ndryshimet kryesore midis Netflow, i cili është bërë një standard de fakto, dhe sFlow? Do të veçoja disa nga ato kryesore. Së pari, Netflow ka fusha të personalizueshme nga përdoruesi në krahasim me fushat fikse në sFlow. Dhe së dyti, dhe kjo është gjëja më e rëndësishme në rastin tonë, sFlow mbledh të ashtuquajturën telemetri të mostrës; në kontrast me atë të pa kampionuar për Netflow dhe IPFIX. Cili është ndryshimi midis tyre?
Imagjinoni që vendosni të lexoni librin "” e kolegëve të mi - Gary McIntyre, Joseph Munitz dhe Nadem Alfardan (mund të shkarkoni një pjesë të librit nga lidhja). Ju keni tre opsione për të arritur qëllimin tuaj - lexoni të gjithë librin, kaloni nëpër të, ndaloni në çdo faqe të 10-të ose të 20-të, ose përpiquni të gjeni një ritregim të koncepteve kryesore në një blog ose shërbim si SmartReading. Pra, telemetria pa mostër po lexon çdo "faqe" të trafikut të rrjetit, domethënë, duke analizuar metadatat për secilën paketë. Telemetria e mostrës është studimi selektiv i trafikut me shpresën se mostrat e përzgjedhura do të përmbajnë atë që ju nevojitet. Në varësi të shpejtësisë së kanalit, telemetria e mostrës do të dërgohet për analizë çdo paketë të 64-të, të 200-të, të 500-të, të 1000-të, të 2000-të apo edhe të 10000-të.
Në kontekstin e monitorimit të sigurisë së informacionit, kjo do të thotë se telemetria e mostrës është e përshtatshme për zbulimin e sulmeve DDoS, skanimin dhe përhapjen e kodit me qëllim të keq, por mund të humbasë sulmet atomike ose me shumë paketa që nuk janë përfshirë në mostrën e dërguar për analizë. Telemetria e pangopur nuk ka disavantazhe të tilla. Me këtë, gama e sulmeve të zbuluara është shumë më e gjerë. Këtu është një listë e shkurtër e ngjarjeve që mund të zbulohen duke përdorur mjetet e analizës së telemetrisë së rrjetit.
Sigurisht, disa analizues Netflow me burim të hapur nuk do t'ju lejojnë ta bëni këtë, pasi detyra e tij kryesore është mbledhja e telemetrisë dhe kryerja e analizave themelore mbi të nga pikëpamja e IT. Për të identifikuar kërcënimet e sigurisë së informacionit bazuar në rrjedhën, është e nevojshme të pajisni analizuesin me motorë dhe algoritme të ndryshme, të cilët do të identifikojnë problemet e sigurisë kibernetike bazuar në fushat standarde ose të personalizuara të Netflow, do të pasurojnë të dhënat standarde me të dhëna të jashtme nga burime të ndryshme të Inteligjencës së Kërcënimit, etj.
Prandaj, nëse keni një zgjedhje, atëherë zgjidhni Netflow ose IPFIX. Por edhe nëse pajisjet tuaja funksionojnë vetëm me sFlow, si prodhuesit vendas, atëherë edhe në këtë rast mund të përfitoni prej saj në një kontekst sigurie.
Në verën e vitit 2019, unë analizova aftësitë që kanë prodhuesit rusë të pajisjeve të rrjetit dhe të gjithë, duke përjashtuar NSG, Polygon dhe Craftway, njoftuan mbështetje për sFlow (të paktën Zelax, Natex, Eltex, QTech, Rusteleteh).
Pyetja tjetër me të cilën do të përballeni është se ku të zbatoni mbështetjen e rrjedhës për qëllime sigurie? Në fakt, pyetja nuk është shtruar plotësisht në mënyrë korrekte. Pajisjet moderne pothuajse gjithmonë mbështesin protokollet e rrjedhës. Prandaj, do ta riformuloja pyetjen ndryshe - ku është më efektive mbledhja e telemetrisë nga pikëpamja e sigurisë? Përgjigja do të jetë mjaft e qartë - në nivelin e aksesit, ku do të shihni 100% të të gjithë trafikut, ku do të keni informacion të detajuar për hostet (MAC, VLAN, ID e ndërfaqes), ku madje mund të monitoroni trafikun P2P midis hosteve, të cilat është kritike për skanimin e zbulimit dhe shpërndarjes së kodit me qëllim të keq. Në nivelin bazë, thjesht mund të mos shihni një pjesë të trafikut, por në nivelin e perimetrit, do të shihni një të katërtën e të gjithë trafikut të rrjetit tuaj. Por nëse për ndonjë arsye keni pajisje të huaja në rrjetin tuaj që lejojnë sulmuesit të "hyjnë dhe dalin" pa anashkaluar perimetrin, atëherë analizimi i telemetrisë prej tij nuk do t'ju japë asgjë. Prandaj, për mbulim maksimal, rekomandohet të mundësohet grumbullimi i telemetrisë në nivelin e aksesit. Në të njëjtën kohë, vlen të përmendet se edhe nëse po flasim për virtualizim ose kontejnerë, mbështetja e rrjedhës shpesh gjendet gjithashtu në çelsat moderne virtuale, gjë që ju lejon të kontrolloni trafikun edhe atje.
Por meqenëse e ngrita temën, më duhet t'i përgjigjem pyetjes: po sikur pajisja, fizike apo virtuale, të mos mbështesë protokollet e rrjedhës? Apo është e ndaluar përfshirja e tij (për shembull, në segmentet industriale për të siguruar besueshmërinë)? Apo ndezja e tij çon në ngarkesë të lartë të CPU-së (kjo ndodh në pajisje të vjetra)? Për të zgjidhur këtë problem, ekzistojnë sensorë virtualë të specializuar (sensorë rrjedhjeje), të cilët në thelb janë ndarës të zakonshëm që kalojnë trafikun përmes vetes dhe e transmetojnë atë në formën e rrjedhës në modulin e grumbullimit. Vërtetë, në këtë rast marrim të gjitha problemet për të cilat folëm më lart në lidhje me mjetet e kapjes së paketave. Kjo do të thotë, ju duhet të kuptoni jo vetëm avantazhet e teknologjisë së analizës së rrjedhës, por edhe kufizimet e saj.
Një pikë tjetër që është e rëndësishme të mbani mend kur flisni për mjetet e analizës së rrjedhës. Nëse në lidhje me mjetet konvencionale të gjenerimit të ngjarjeve të sigurisë përdorim metrikën EPS (ngjarje për sekondë), atëherë ky tregues nuk është i zbatueshëm për analizën telemetrike; ai zëvendësohet nga FPS (rrjedhja për sekondë). Ashtu si në rastin e EPS, nuk mund të llogaritet paraprakisht, por mund të vlerësoni numrin e përafërt të fijeve që gjeneron një pajisje e veçantë në varësi të detyrës së saj. Ju mund të gjeni tabela në internet me vlera të përafërta për lloje të ndryshme të pajisjeve dhe kushteve të ndërmarrjes, të cilat do t'ju lejojnë të vlerësoni se cilat licenca ju nevojiten për mjetet e analizës dhe cila do të jetë arkitektura e tyre? Fakti është se sensori IDS është i kufizuar nga një gjerësi bande e caktuar që mund të "tërheqë", dhe kolektori i rrjedhës ka kufizimet e veta që duhen kuptuar. Prandaj, në rrjete të mëdha, të shpërndara gjeografikisht, zakonisht ka disa koleksionistë. Kur përshkrova , Unë kam dhënë tashmë numrin e koleksionistëve tanë - janë 21. Dhe kjo është për një rrjet të shpërndarë në pesë kontinente dhe që numëron rreth gjysmë milioni pajisje aktive).
Ne përdorim zgjidhjen tonë si një sistem monitorimi Netflow , e cila fokusohet në mënyrë specifike në zgjidhjen e problemeve të sigurisë. Ka shumë motorë të integruar për zbulimin e aktivitetit anormal, të dyshimtë dhe qartësisht me qëllim të keq, i cili ju lejon të zbuloni një gamë të gjerë kërcënimesh të ndryshme - nga kriptominimi deri te rrjedhjet e informacionit, nga përhapja e kodit me qëllim të keq deri te mashtrimi. Ashtu si shumica e analizuesve të rrjedhës, Stealthwatch është ndërtuar sipas një skeme me tre nivele (gjenerator - kolektor - analizues), por plotësohet me një numër karakteristikash interesante që janë të rëndësishme në kontekstin e materialit në shqyrtim. Së pari, ai integrohet me zgjidhjet e kapjes së paketave (siç është Cisco Security Packet Analyzer), i cili ju lejon të regjistroni sesionet e zgjedhura të rrjetit për hetim dhe analizë të mëvonshme të thelluar. Së dyti, posaçërisht për të zgjeruar detyrat e sigurisë, ne kemi zhvilluar një protokoll të veçantë nvzFlow, i cili ju lejon të "transmetoni" aktivitetin e aplikacioneve në nyjet fundore (serverët, stacionet e punës, etj.) në telemetri dhe ta transmetoni atë te kolektori për analiza të mëtejshme. Nëse në versionin e tij origjinal Stealthwatch punon me çdo protokoll rrjedhjeje (sFlow, rFlow, Netflow, IPFIX, cFlow, jFlow, NetStream) në nivel rrjeti, atëherë mbështetja nvzFlow lejon korrelacionin e të dhënave edhe në nivelin e nyjeve. duke rritur efikasitetin e të gjithë sistemit dhe duke parë më shumë sulme sesa analizuesit konvencionalë të rrjedhës së rrjetit.
Është e qartë se kur flasim për sistemet e analizës Netflow nga pikëpamja e sigurisë, tregu nuk kufizohet në një zgjidhje të vetme nga Cisco. Ju mund të përdorni zgjidhje komerciale dhe falas ose shareware. Është mjaft e çuditshme nëse citoj zgjidhjet e konkurrentëve si shembuj në blogun e Cisco-s, kështu që do të them disa fjalë se si mund të analizohet telemetria e rrjetit duke përdorur dy mjete të njohura, të ngjashme në emër, por ende të ndryshme - SiLK dhe ELK.
SiLK është një grup mjetesh (Sistemi për Njohuri të Nivelit të Internetit) për analizën e trafikut, i zhvilluar nga CERT/CC Amerikan dhe që mbështet, në kontekstin e artikullit të sotëm, Netflow (versionet e 5-ta dhe të 9-ta më të njohura), IPFIX dhe sFlow dhe përdorimi i shërbimeve të ndryshme (rwfilter, rwcount, rwflowpack, etj.) për të kryer operacione të ndryshme në telemetrinë e rrjetit me qëllim zbulimin e shenjave të veprimeve të paautorizuara në të. Por ka disa pika të rëndësishme për t'u theksuar. SiLK është një mjet i linjës komanduese që kryen analiza on-line duke futur komanda si kjo (zbulimi i paketave ICMP më të mëdha se 200 bajt):
rwfilter --flowtypes=all/all --proto=1 --bytes-per-packet=200- --pass=stdout | rwrwcut --fields=sIP,dIP,iType,iCode --num-recs=15
jo shumë komode. Ju mund të përdorni ISILK GUI, por nuk do ta bëjë jetën tuaj shumë më të lehtë, duke zgjidhur vetëm funksionin e vizualizimit dhe duke mos zëvendësuar analistin. Dhe kjo është pika e dytë. Ndryshe nga zgjidhjet komerciale, të cilat tashmë kanë një bazë solide analitike, algoritme për zbulimin e anomalive, rrjedhën përkatëse të punës, etj., në rastin e SiLK-së do t'ju duhet t'i bëni të gjitha vetë, gjë që do të kërkojë kompetenca paksa më të ndryshme nga ju sesa nga përdorimi tashmë i gatshëm. mjetet e përdorimit. Kjo nuk është as e mirë as e keqe - kjo është një veçori e pothuajse çdo mjeti falas që supozon se ju dini çfarë të bëni dhe do t'ju ndihmojë vetëm me këtë (mjetet tregtare varen më pak nga kompetencat e përdoruesve të tij, megjithëse ata gjithashtu supozojnë që analistët i kuptojnë të paktën bazat e hetimeve dhe monitorimit të rrjetit). Por le të kthehemi te SILK. Cikli i punës i analistit me të duket kështu:
- Formulimi i një hipoteze. Ne duhet të kuptojmë se çfarë do të kërkojmë brenda telemetrisë së rrjetit, të dimë atributet unike me të cilat do të identifikojmë disa anomali ose kërcënime.
- Ndërtimi i një modeli. Pasi kemi formuluar një hipotezë, ne e programojmë atë duke përdorur të njëjtin Python, shell ose mjete të tjera që nuk përfshihen në SiLK.
- Duke testuar. Është koha për të kontrolluar korrektësinë e hipotezës sonë, e cila konfirmohet ose hidhet poshtë duke përdorur shërbimet SiLK duke filluar me 'rw', 'set', 'bag'.
- Analiza e të dhënave reale. Në funksionimin industrial, SiLK na ndihmon të identifikojmë diçka dhe analisti duhet t'i përgjigjet pyetjeve "A gjetëm atë që prisnim?", "A korrespondon kjo me hipotezën tonë?", "Si të zvogëlojmë numrin e pozitivëve të rremë?", "Si për të përmirësuar nivelin e njohjes? » e kështu me radhë.
- Përmirësimi. Në fazën përfundimtare, ne përmirësojmë atë që është bërë më parë - krijojmë shabllone, përmirësojmë dhe optimizojmë kodin, riformulojmë dhe sqarojmë hipotezën, etj.
Ky cikël do të jetë i zbatueshëm edhe për Cisco Stealthwatch, vetëm i fundit i automatizon këto pesë hapa në maksimum, duke reduktuar numrin e gabimeve të analistit dhe duke rritur efikasitetin e zbulimit të incidenteve. Për shembull, në SiLK mund të pasuroni statistikat e rrjetit me të dhëna të jashtme për IP-të me qëllim të keq duke përdorur skriptet e shkruara me dorë, dhe në Cisco Stealthwatch është një funksion i integruar që shfaq menjëherë një alarm nëse trafiku i rrjetit përmban ndërveprime me adresat IP nga lista e zezë.
Nëse shkoni më lart në piramidën "me pagesë" për softuerin e analizës së rrjedhës, atëherë pas SiLK absolutisht falas do të ketë një shareware ELK, i përbërë nga tre komponentë kryesorë - Elasticsearch (indeksimi, kërkimi dhe analiza e të dhënave), Logstash (hyrja/dalja e të dhënave ) dhe Kibana (vizualizimi). Ndryshe nga SiLK, ku duhet të shkruani gjithçka vetë, ELK tashmë ka shumë biblioteka/module të gatshme (disa me pagesë, disa jo) që automatizojnë analizën e telemetrisë së rrjetit. Për shembull, filtri GeoIP në Logstash ju lejon të lidhni adresat IP të monitoruara me vendndodhjen e tyre gjeografike (Stealthwatch e ka këtë veçori të integruar).
ELK gjithashtu ka një komunitet mjaft të madh që po plotëson komponentët që mungojnë për këtë zgjidhje monitorimi. Për shembull, për të punuar me Netflow, IPFIX dhe sFlow mund të përdorni modulin , nëse nuk jeni të kënaqur me Modulin Netflow Logstash, i cili mbështet vetëm Netflow.
Ndërsa jep më shumë efikasitet në mbledhjen e rrjedhës dhe kërkimin në të, ELK-së aktualisht i mungon analitika e pasur e integruar për zbulimin e anomalive dhe kërcënimeve në telemetrinë e rrjetit. Kjo do të thotë, duke ndjekur ciklin e jetës të përshkruar më sipër, do t'ju duhet të përshkruani në mënyrë të pavarur modelet e shkeljes dhe më pas ta përdorni atë në sistemin luftarak (nuk ka modele të integruara atje).
Ka, sigurisht, shtesa më të sofistikuara për ELK, të cilat tashmë përmbajnë disa modele për zbulimin e anomalive në telemetrinë e rrjetit, por zgjerime të tilla kushtojnë para dhe këtu pyetja është nëse loja ia vlen qiriri - shkruani vetë një model të ngjashëm, blini implementim për mjetin tuaj të monitorimit, ose blini zgjidhje të gatshme të klasës Analiza e Trafikut të Rrjetit.
Në përgjithësi, nuk dua të futem në debatin se është më mirë të shpenzoni para dhe të blini një zgjidhje të gatshme për monitorimin e anomalive dhe kërcënimeve në telemetrinë e rrjetit (për shembull, Cisco Stealthwatch) ose ta kuptoni vetë dhe të personalizoni të njëjtën gjë. SiLK, ELK ose nfdump ose OSU Flow Tools për çdo kërcënim të ri ( po flas për dy të fundit prej tyre Herën e fundit)? Secili zgjedh vetë dhe secili ka motivet e veta për të zgjedhur njërën nga dy opsionet. Thjesht doja të tregoja se telemetria e rrjetit është një mjet shumë i rëndësishëm për të garantuar sigurinë e rrjetit të infrastrukturës suaj të brendshme dhe nuk duhet ta neglizhoni atë, për të mos u futur në listën e kompanive emri i të cilave përmendet në media bashkë me epitetet “. hakuar", "jo në përputhje me kërkesat e sigurisë së informacionit" ", "duke mos menduar për sigurinë e të dhënave të tyre dhe të dhënave të klientit."
Për ta përmbledhur, do të doja të rendisja këshillat kryesore që duhet të ndiqni kur ndërtoni monitorimin e sigurisë së informacionit të infrastrukturës suaj të brendshme:
- Mos e kufizoni veten vetëm në perimetër! Përdorni (dhe zgjidhni) infrastrukturën e rrjetit jo vetëm për të lëvizur trafikun nga pika A në pikën B, por edhe për të adresuar çështjet e sigurisë kibernetike.
- Studioni mekanizmat ekzistues të monitorimit të sigurisë së informacionit në pajisjet e rrjetit tuaj dhe përdorni ato.
- Për monitorimin e brendshëm, jepni përparësi analizës së telemetrisë - ju lejon të zbuloni deri në 80-90% të të gjitha incidenteve të sigurisë së informacionit në rrjet, duke bërë atë që është e pamundur kur kapni paketat e rrjetit dhe kurseni hapësirë për ruajtjen e të gjitha ngjarjeve të sigurisë së informacionit.
- Për të monitoruar flukset, përdorni Netflow v9 ose IPFIX - ato ofrojnë më shumë informacion në një kontekst sigurie dhe ju lejojnë të monitoroni jo vetëm IPv4, por edhe IPv6, MPLS, etj.
- Përdorni një protokoll rrjedhës pa mostër - ai ofron më shumë informacion për zbulimin e kërcënimeve. Për shembull, Netflow ose IPFIX.
- Kontrolloni ngarkesën në pajisjen tuaj të rrjetit - mund të mos jetë në gjendje të trajtojë gjithashtu protokollin e rrjedhës. Më pas merrni parasysh përdorimin e sensorëve virtualë ose Netflow Generation Appliance.
- Zbatoni kontrollin para së gjithash në nivelin e aksesit - kjo do t'ju japë mundësinë të shihni 100% të të gjithë trafikut.
- Nëse nuk keni zgjidhje dhe jeni duke përdorur pajisje të rrjetit rus, atëherë zgjidhni një që mbështet protokollet e rrjedhës ose ka porte SPAN/RSPAN.
- Kombinoni sistemet e zbulimit/parandalimit të ndërhyrjeve/sulmeve në skajet dhe sistemet e analizës së rrjedhës në rrjetin e brendshëm (duke përfshirë retë).
Sa i përket këshillës së fundit, do të doja të bëja një ilustrim që e kam dhënë më parë. Ju shikoni se nëse më parë shërbimi i sigurisë së informacionit Cisco pothuajse tërësisht e ndërtoi sistemin e tij të monitorimit të sigurisë së informacionit në bazë të sistemeve të zbulimit të ndërhyrjeve dhe metodave të nënshkrimit, tani ato përbëjnë vetëm 20% të incidenteve. Një tjetër 20% bie në sistemet e analizës së rrjedhës, gjë që sugjeron që këto zgjidhje nuk janë një trill, por një mjet i vërtetë në aktivitetet e shërbimeve të sigurisë së informacionit të një ndërmarrje moderne. Për më tepër, ju keni gjënë më të rëndësishme për zbatimin e tyre - infrastrukturën e rrjetit, investimet në të cilat mund të mbrohen më tej duke caktuar funksionet e monitorimit të sigurisë së informacionit në rrjet.
Konkretisht nuk e preka temën e reagimit ndaj anomalive apo kërcënimeve të evidentuara në flukset e rrjetit, por mendoj se tashmë është e qartë që monitorimi nuk duhet të përfundojë vetëm me zbulimin e një kërcënimi. Duhet të pasohet nga një përgjigje dhe mundësisht në një mënyrë automatike ose të automatizuar. Por kjo është një temë për një artikull të veçantë.
Informacione Shtese:
PS. Nëse është më e lehtë për ju të dëgjoni gjithçka që u shkrua më lart, atëherë mund të shikoni prezantimin njëorësh që formoi bazën e këtij shënimi.
Burimi: www.habr.com