Kur bĂ«het fjalĂ« pĂ«r monitorimin e sigurisĂ« sĂ« njĂ« rrjeti tĂ« brendshĂ«m korporativ ose tĂ« institucioneve, shumĂ« njerĂ«z shpesh e lidhin kĂ«tĂ« me kontrollin e rrjedhjeve tĂ« informacionit dhe implementimin e zgjidhjeve DLP. Por, nĂ«se pĂ«rpiqemi tĂ« saktĂ«sojmĂ« pyetjen dhe tĂ« pyesim se si zbuloni sulmet nĂ« rrjetin tuaj tĂ« brendshĂ«m, pĂ«rgjigjja zakonisht Ă«shtĂ« pĂ«rmendja e sistemeve tĂ« zbulimit tĂ« sulmeve (sistemet e zbulimit tĂ« sulmeve, IDS). Dhe ajo qĂ« ishte e vetmja mundĂ«si 10-20 vjet mĂ« parĂ«, sot Ă«shtĂ« bĂ«rĂ« njĂ« anahronizĂ«m. Ekziston njĂ« opsion mĂ« efektiv, dhe nĂ« disa raste edhe njĂ« mundĂ«si e vetme pĂ«r monitorimin e rrjetit tĂ« brendshĂ«m â pĂ«rdorimi i protokollave tĂ« flow, tĂ« cilat ishin fillimisht tĂ« destinuara pĂ«r gjetjen e problemeve tĂ« rrjetit (troubleshooting), por mĂ« vonĂ« u shndĂ«rruan nĂ« njĂ« instrument shumĂ« interesante pĂ«r sigurinĂ«. KĂ«tu do tĂ« flasim pĂ«r llojet e protokollave tĂ« flow qĂ« ekzistojnĂ«, se cilĂ«t prej tyre ndihmojnĂ« mĂ« mirĂ« nĂ« zbulimin e sulmeve nĂ« rrjet, ku Ă«shtĂ« mĂ« mirĂ« tĂ« implementohet monitorimi i flow, çfarĂ« duhet tĂ« keni parasysh kur e zhvilloni njĂ« skemĂ« tĂ« tillĂ«, dhe madje si ta 'ngisni' kĂ«tĂ« nĂ« pajisje vendase.
Nuk do të ndalem në pyetjen "Pse është i nevojshëm monitorimi i sigurisë së infrastrukturës së brendshme?" Përgjigjja për këtë duket e qartë. Por nëse e shqyrtoni përsëri, që sot nuk ka rrugë tjetër pa këtë, një video të shkurtër që tregon se si mund të hyhet në rrjetin korporativ të mbrojtur nga një firewall me 17 mënyra të ndryshme. Prandaj, do ta marrim si të sigurt që monitorimi i brendshëm është i nevojshëm dhe na mbetet vetëm të kuptojmë se si mund ta organizojmë atë.
Do të veçoja tri burime kryesore të të dhënave për monitorimin e infrastrukturës në nivel rrjeti:
- "trafiku" i papërpunuar, i cili kapet dhe analizohet nga disa sisteme analize,
- ngjarjet nga pajisjet rrjet që kalon trafiku,
- informacioni mbi trafikun, i marrë përmes një nga protokollet e flow.
Kapja e trafikut tĂ« papĂ«rpunuar Ă«shtĂ« opsioni mĂ« popullor pĂ«r sigurimin, sepse historikisht ka qene, dhe Ă«shtĂ«, mĂ« i pari. Sistemet e zakonshme tĂ« zbulimit tĂ« sulmeve nĂ« rrjet (sistemi i parĂ« komercial i zbulimit tĂ« sulmeve ishte NetRanger nga kompania Wheel Group, e blerĂ« nĂ« vitin 1998 nga Cisco) realisht merreshin me kapjen e paketave (dhe mĂ« vonĂ« dhe tĂ« seancave), ku kĂ«rkoheshin disa nĂ«nshkrime (ârregullat vendimtareâ nĂ« terminologjinĂ« e FSTEK), qĂ« sinjalizojnĂ« pĂ«r sulme. Sigurisht, Ă«shtĂ« e mundur tĂ« analizosh trafikun e papĂ«rpunuar jo vetĂ«m me ndihmĂ«n e IDS, por edhe me mjete tĂ« tjera (pĂ«r shembull, Wireshark, tcpdump ose funksionalitetin NBAR2 nĂ« Cisco IOS), por zakonisht atyre u mungon baza e njohurive qĂ« ndan mjetin e sigurimit nga njĂ« mjet i zakonshĂ«m IT.
Pra, sistemet e zbulimit tĂ« sulmeve. Metoda mĂ« e vjetĂ«r dhe mĂ« popullore pĂ«r zbulimin e sulmeve nĂ« rrjet, e cila bĂ«n mirĂ« detyrĂ«n e saj nĂ« kufi (nuk ka rĂ«ndĂ«si i cili â korporativ, DC, segmenti etj.), por dĂ«shton nĂ« rrjetet moderne tĂ« shkĂ«putjes dhe atyre tĂ« pĂ«rcaktuara nga programet. NĂ« rastin e njĂ« rrjeti tĂ« ndĂ«rtuar nĂ« bazĂ« tĂ« switch-eve tĂ« zakonshme, infrastruktura e sensorĂ«ve pĂ«r zbulimin e sulmeve bĂ«het shumĂ« e madhe â do t'ju duhet tĂ« vendosni njĂ« sensor pĂ«r çdo lidhje me nodin, sulmet e tĂ« cilit dĂ«shironi tĂ« monitoroni. Ădo prodhues do tĂ« ishte i lumtur t'ju shesĂ« qindra e mijĂ«ra sensorĂ«, por mendoj se buxheti juaj nuk do t'i pĂ«rballojĂ« kĂ«to shpenzime. Mund tĂ« them se edhe nĂ« Cisco (dhe ne jemi zhvillues tĂ« NGIPS) nuk mundĂ«m ta bĂ«jmĂ« kĂ«tĂ«, ndonĂ«se, duket se çështja e çmimit nuk duhet tĂ« paraqesĂ« vĂ«shtirĂ«si â ky Ă«shtĂ« zgjidhja jonĂ«. PĂ«r mĂ« tepĂ«r, ka njĂ« pyetje, si tĂ« lidhim sensorin nĂ« kĂ«tĂ« rast? NĂ« njĂ« ndĂ«rprerje? Dhe nĂ«se vetĂ« sensori dĂ«shtoi? TĂ« kĂ«rkosh qĂ« sensorĂ«t tĂ« kenĂ« njĂ« modul bypass? TĂ« pĂ«rdorĂ«sh ato qĂ« quhen tap? TĂ« gjitha kĂ«to i shtojnĂ« kostot zgjidhjes dhe e bĂ«jnĂ« atĂ« tĂ« papĂ«rballueshme pĂ«r kompanitĂ« e çdo shkalle.
Mund tĂ« provoni tĂ« "varni" sensorin nĂ« portĂ«n SPAN/RSPAN/ERSPAN dhe tĂ« drejtoni trafikun nga portat e nevojshme tĂ« switchit nĂ« tĂ«. Ky opsion pjesĂ«risht zgjidh problemin e pĂ«rshkruar nĂ« paragrafin e mĂ«parshĂ«m, por krijon njĂ« tjetĂ«r â porti SPAN nuk mund tĂ« pranojĂ« tĂ«rĂ« trafikun qĂ« do t'i drejtohet - nuk ka mjaftueshĂ«m kapacitet. Do tĂ« duhet tĂ« sakrifikoni diçka. Ose tĂ« lini disa nyje pa monitorim (nĂ« kĂ«tĂ« rast, duhet tĂ« bĂ«ni njĂ« prioritetizim tĂ« tyre paraprakisht), ose tĂ« drejtoni vetĂ«m njĂ« lloj tĂ« caktuar tĂ« trafikut nga nyja, jo tĂ«rĂ« atĂ«. NĂ« çdo rast, mund tĂ« humbasim disa sulme. PĂ«r mĂ« tepĂ«r, porti SPAN mund tĂ« jetĂ« i angazhuar pĂ«r nevoja tĂ« tjera. NĂ« fund, do tĂ« duhet tĂ« rishikoni topologjinĂ« ekzistuese tĂ« rrjetit dhe tĂ« bĂ«ni, ndoshta, disa ndryshime pĂ«r tĂ« pĂ«rfshirĂ« maksimalisht rrjetin tuaj me numrin e sensorĂ«ve nĂ« dispozicion (dhe ta konfirmoni kĂ«tĂ« me IT-nĂ«).
Por çfarĂ« ndodh nĂ«se rrjeti juaj pĂ«rdor rruge asimetrike? ĂfarĂ« ndodh nĂ«se keni implementuar ose planifikoni tĂ« implementoni SDN? ĂfarĂ« ndodh nĂ«se duhet tĂ« monitoroni makina tĂ« virtualizuara ose konteinerĂ«, trafiku i tĂ« cilave nuk arrin aspak nĂ« switchin fizik? KĂ«to pyetje nuk i pĂ«lqejnĂ« prodhuesve tĂ« IDS-ve tradicionale, sepse nuk dinĂ« si t'u japin pĂ«rgjigje. Ndoshta do t'ju nxisin qĂ« tĂ« konsideroni se tĂ« gjitha kĂ«to teknologji moderne janĂ« njĂ« bamĂ« dhe nuk keni nevojĂ« pĂ«r to. Ndoshta do tĂ« flasin pĂ«r nevojĂ«n tĂ« filloni me pak. Ose ndoshta do t'ju thonĂ« se duhet tĂ« vendosni njĂ« mulli tĂ« fuqishĂ«m nĂ« qendĂ«r tĂ« rrjetit dhe tĂ« drejtoni tĂ« gjithĂ« trafikun nĂ« tĂ« duke pĂ«rdorur balancuesit. ĂfarĂ«do opsioni t'ju ofrohet, ju nevojitet tĂ« kuptoni qartĂ« se sa i pĂ«rshtatshĂ«m Ă«shtĂ« ai pĂ«r ju. Dhe vetĂ«m pas kĂ«tij kuptimi duhet tĂ« merrni vendimin pĂ«r qasjen e monitorimit tĂ« infrastrukturĂ«s sĂ« sigurisĂ« sĂ« rrjetit. Duke u rikthyer te kapja e paketave, dĂ«shiroj tĂ« theksoj se ky metod vazhdon tĂ« mbetet shumĂ« i popullarizuar dhe i rĂ«ndĂ«sishĂ«m, por qĂ«llimi i tij kryesor Ă«shtĂ« tĂ« kontrollojĂ« kufijtĂ«; kufijtĂ« midis organizatĂ«s suaj dhe Internetit, kufijtĂ« midis QendrĂ«s sĂ« tĂ« DhĂ«nave dhe rrjetit tjetĂ«r, kufijtĂ« midis sistemit tĂ« automatizuar dhe segmentit korporativ. NĂ« kĂ«to vende, IDS/IPS klasike ndodhen ende nĂ« tĂ« drejtĂ«n e ekzistencĂ«s dhe pĂ«rballen mirĂ« me detyrat e caktuara.
TĂ« kalojmĂ« nĂ« variantin e dytĂ«. Analiza e ngjarjeve qĂ« vijnĂ« nga pajisjet rrjet, gjithashtu mund tĂ« pĂ«rdoret pĂ«r qĂ«llime zbardhjeje tĂ« sulmeve, por jo si mekanizmi kryesor, pasi ajo lejon tĂ« zbulohet vetĂ«m njĂ« klasĂ« tĂ« vogĂ«l tĂ« ndĂ«rhyrjeve. Gjithashtu, ajo ka njĂ«farĂ« reagueshmĂ«rie â sĂ« pari, sulmi duhet tĂ« ndodhĂ«, pastaj ai duhet tĂ« regjistrohet nga pajisja rrjet, e cila nĂ« njĂ« mĂ«nyrĂ« ose tjetĂ«r do tĂ« sinjalizojĂ« pĂ«r njĂ« problem me sigurinĂ« e informacionit. Ka disa mĂ«nyra pĂ«r kĂ«tĂ«. Mund tĂ« jetĂ« syslog, RMON ose SNMP. TĂ« dy protokollet e fundit pĂ«r monitorimin rrjet nĂ« kontekstin e sigurisĂ« sĂ« informacionit pĂ«rdoren vetĂ«m nĂ«se na nevojitet tĂ« zbulojmĂ« njĂ« sulm DoS ndaj pajisjes rrjet, pasi me ndihmĂ«n e RMON dhe SNMP mund tĂ« ndjekim, pĂ«r shembull, ngarkesĂ«n e procesorit qendror tĂ« pajisjes apo tĂ« interface-ve tĂ« tij. Ky Ă«shtĂ« njĂ« nga mĂ«nyrat mĂ« "tĂ« lira" (syslog ose SNMP janĂ« tĂ« pranishme nga tĂ« gjithĂ«), por gjithashtu dhe mĂ« pak efektive nga tĂ« gjitha mĂ«nyrat e monitorimit tĂ« sigurisĂ« sĂ« brendshme â shumĂ« sulme janĂ« thjesht tĂ« fshehura nga ajo. Natyrisht, nuk duhet injoruar dhe analiza e syslog ndihmon pĂ«r tĂ« identifikuar nĂ« kohĂ« ndryshimet nĂ« konfigurimin e pajisjes vetĂ«, komprometimin e saj, por nuk Ă«shtĂ« shumĂ« e pĂ«rshtatshme pĂ«r tĂ« zbuluar sulme nĂ« tĂ« gjithĂ« rrjetin.
Varianti i tretë është analiza e informacionit mbi trafikun që kalon përmes pajisjes, e cila mbështet një nga disa protokollet e rrjedhës. Në këtë rast, pavarësisht nga protokolli, infrastruktura e punës me rrjedhë përbëhet patjetër nga tre komponentë:
- Gjenerimi ose eksporti i rrjedhës. Kjo rol zakonisht i besohet ruterit, switch-it ose ndonjë pajisjeje tjetër rrjeti, e cila, duke kaluar përmes vetes trafikun rrjet, lejon të nxirren parametrat kyç, të cilët më pas dërgohen në modulin e mbledhjes. Për shembull, në Cisco, protokolli Netflow mbështetet jo vetëm në ruterat dhe switch-et, përfshirë ato virtuale dhe industriale, por edhe në kontrollet wireless, firewall-e dhe madje edhe në serverë.
- Mbledhja e rrjedhës. Duke pasur parasysh se në një rrjet modern zakonisht ka më shumë se një pajisje rrjeti, lind detyra e mbledhjes dhe konsolidimit të rrjedhave, e cila zgjidhet me ndihmën e atyre që quhen kolektues, të cilët kryejnë përpunimin e rrjedhave të marra dhe pastaj i dërgojnë ato për analizë.
- Analiza e fluksit. Analizatori merr përsipër detyrën kryesore intelektuale dhe, duke aplikuar algoritme të ndryshme në flukse, bën përfundime të ndryshme. Për shembull, në kuadër të funksionit IT, një analizator i tillë mund të identifikojë ngushticat e rrjetit ose të analizojë profilin e ngarkesës së trafikut për optimizimin e mëtejshëm të rrjetit. Ndërsa për sigurinë e informacionit, një analizator i tillë mund të zbulojë rrjedhjet e të dhënave, përhapjen e kodit të dëmshëm ose sulmet DoS.
Nuk duhet tĂ« mendoni se njĂ« arkitekturĂ« me tre nivele Ă«shtĂ« shumĂ« e komplikuar â tĂ« gjitha variantet e tjera (pĂ«rveç ndoshta sistemeve tĂ« monitorimit tĂ« rrjetit qĂ« punojnĂ« me SNMP dhe RMON) funksionojnĂ« gjithashtu sipas saj. Ne kemi njĂ« gjenerues tĂ« dhĂ«nash pĂ«r analizĂ«, i cili Ă«shtĂ« njĂ« pajisje rrjeti ose njĂ« sensor i pavarur. Ne kemi njĂ« sistem mbledhjeje tĂ« sinjalizimeve dhe njĂ« sistem menaxhimi tĂ« tĂ« gjithĂ« infrastrukturĂ«s sĂ« monitorimit. Dy komponentĂ«t e fundit mund tĂ« integrohen brenda njĂ« nyje, por nĂ« rrjetet mĂ« tĂ« mĂ«dha ata zakonisht shpĂ«rndahen nĂ« tĂ« paktĂ«n dy pajisje pĂ«r tĂ« siguruar shkallueshmĂ«rinĂ« dhe besueshmĂ«rinĂ«.
Dallimi nga analiza e paketeve, e cila bazohet nĂ« studimin e headers dhe trupit tĂ« tĂ« dhĂ«nave tĂ« çdo pakete dhe seancave qĂ« pĂ«rbĂ«hen prej tyre, analiza e flukseve mbĂ«shtetet nĂ« mbledhjen e metadatave mbi trafikun rrjetor. Kur, sa, nga ku dhe kah... kĂ«to janĂ« pyetje tĂ« cilave iu pĂ«rgjigjet analiza e telemetrisĂ« rrjetore pĂ«rmes protokolleve tĂ« ndryshme tĂ« fluksit. NĂ« fillim ato u pĂ«rdorĂ«n pĂ«r analizimin e statistikave dhe identifikimin e problemeve IT nĂ« rrjet, por mĂ« vonĂ«, me zhvillimin e mekanizmave analitikĂ«, u bĂ« e mundur qĂ« tĂ« pĂ«rdoren gjithashtu pĂ«r tĂ« njĂ«jtĂ«n telemetri dhe pĂ«r qĂ«llime sigurie. KĂ«tu duhet theksuar pĂ«rsĂ«ri se analiza e flukseve nuk zĂ«vendĂ«son dhe nuk anashkalon kapjen e paketeve. Ădo njĂ«ri nga kĂ«to metoda ka fushĂ«n e vet tĂ« pĂ«rdorimit. Por nĂ« kontekstin e kĂ«tij artikulli, analiza e flukseve Ă«shtĂ« mĂ« e pĂ«rshtatshme pĂ«r monitorimin e infrastrukturĂ«s sĂ« brendshme. Keni pajisje rrjeti (nuk ka rĂ«ndĂ«si nĂ«se ato funksionojnĂ« nĂ« njĂ« paradigmĂ« tĂ« definuar nga programi ose sipas rregullave statike), tĂ« cilat sulmi nuk mund tâi kalojĂ«. NjĂ« sensor klasik IDS mund ta kalojĂ«, por njĂ« pajisje rrjeti qĂ« mbĂ«shtet protokollin e fluksit jo. Kjo Ă«shtĂ« pĂ«rparĂ«sia e kĂ«tij metode.
Nga ana tjetĂ«r, nĂ«se ju nevojitet njĂ« provĂ« pĂ«r organet e zbatimit tĂ« ligjit ose grupin tuaj tĂ« hetimit tĂ« incidenteve, nuk do tĂ« kaloni dot pa kapjen e paketave â telemetria rrjetore nuk Ă«shtĂ« njĂ« kopje e trafikut qĂ« mund tĂ« pĂ«rdoret pĂ«r mbledhjen e dĂ«shmive; ajo Ă«shtĂ« e nevojshme pĂ«r zbulimin operativ dhe marrjen e vendimeve nĂ« fushĂ«n e sigurisĂ« sĂ« informacionit. Nga ana tjetĂ«r, duke pĂ«rdorur analizĂ«n e telemetrisĂ«, mund tĂ« "shkruani" jo tĂ« gjithĂ« trafikun rrjetor (nĂ«se Ă«shtĂ« ndonjĂ« gjĂ«, Cisco dhe qendrat e tĂ« dhĂ«nave merret :-), por vetĂ«m atĂ« qĂ« merr pjesĂ« nĂ« sulm. Mjetet e analizĂ«s sĂ« telemetrisĂ« nĂ« kĂ«tĂ« drejtim plotĂ«sojnĂ« mirĂ« mekanizmat tradicionalĂ« tĂ« kapjes sĂ« paketave, duke dhĂ«nĂ« njĂ« urdhĂ«r pĂ«r kapjen dhe ruajtjen selektive. PĂ«rndryshe, do t'ju duhet njĂ« infrastrukture tĂ« madhe pĂ«r ruajtje.
Imagjinoni një rrjet që punon me shpejtësi 250 Mbit/sec. Nëse dëshironi të ruani gjithë këtë volum, do t'ju nevojitet një hapësirë ruajtjeje prej 31 Mb për një sekondë të transmetimit 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 ruajtjen e të dhënave ditore nga një rrjet me kapacitet 10 Gbit/sec, do t'ju nevojitet një hapësirë ruajtjeje prej 108 Tb. Dhe disa rregullatorë kërkojnë të ruajnë të dhëna për sigurinë për vite... Regjistrimi "në kërkesë", që analiza e rrjedhave ndihmon të realizohet, ndihmon të zvogëlohen këto vlera me rend të madh. Për t'u folur për raportin midis volumit të të dhënave të regjistruara të telemetrisë rrjetore dhe kapjes së plotë të të dhënave, ai është rreth 1 në 500. Për vlerat e lartpërmendura, ruajtja e dekodimit të plotë të gjithë trafikut të përditshëm do të ishte 5 dhe 216 Gb përkatësisht (madje mund ta regjistroni edhe në një flash drive të zakonshëm).
NĂ«se metodologjia e analizes sĂ« tĂ« dhĂ«nave tĂ« papĂ«rpunuara tĂ« rrjetit ndryshon pak nga njĂ« prodhues nĂ« tjetrin, nĂ« rastin e analizĂ«s sĂ« rrjedhave situata Ă«shtĂ« e ndryshme. EkzistojnĂ« disa variante tĂ« protokolleve tĂ« rrjedhave, pĂ«r dallimet e tĂ« cilĂ«ve Ă«shtĂ« e nevojshme tĂ« dihet pikĂ«risht nĂ« kontekstin e sigurisĂ«. Protokolli mĂ« i njohur Ă«shtĂ« Netflow, i zhvilluar nga Cisco. EkzistojnĂ« disa versione tĂ« kĂ«tij protokolli, tĂ« cilat ndryshojnĂ« sipas mundĂ«sive tĂ« tyre dhe volumit tĂ« informacionit mbi trafikun qĂ« regjistrohet. Versioni aktual Ă«shtĂ« versioni i nĂ«ntĂ« (Netflow v9), mbi tĂ« cilin Ă«shtĂ« zhvilluar standardi industrial Netflow v10, gjithashtu i njohur si IPFIX. Sot shumica e prodhuesve tĂ« rrjetit mbĂ«shtesin pikĂ«risht Netflow ose IPFIX nĂ« pajisjet e tyre. Por ka dhe variante tĂ« tjera tĂ« protokolleve tĂ« rrjedhave â sFlow, jFlow, cFlow, rFlow, NetStream dhe kĂ«shtu me radhĂ«, nga tĂ« cilat sFlow Ă«shtĂ« mĂ« i njohur. Ky i fundit mbĂ«shtetet mĂ« shpesh nga prodhuesit vendas tĂ« pajisjeve tĂ« rrjetit pĂ«r shkak tĂ« thjeshtĂ«sisĂ« sĂ« implementimit. Cilat janĂ« dallimet kryesore midis Netflow, si njĂ« standard qĂ« Ă«shtĂ« bĂ«rĂ« de-facto, dhe sFlow? Dallimet kryesore do t'i pĂ«rmendja disa. SĂ« pari, Netflow ka fusha tĂ« personalizueshme nga pĂ«rdoruesi, pĂ«rndryshe nga fushat fikse nĂ« sFlow. SĂ« dyti, dhe kjo Ă«shtĂ« mĂ« e rĂ«ndĂ«sishmja nĂ« rastin tonĂ«, sFlow mbledh atĂ« qĂ« quhet telemetri e sampĂ«lluar; pĂ«r dallim nga telemetria e pasampĂ«lluar e Netflow dhe IPFIX. ĂfarĂ« Ă«shtĂ« ndryshe midis tyre?
Imagjinoni se keni vendosur tĂ« njiheni me librin ââ tĂ« kolegĂ«ve tĂ« mi â Gari McIntyre, Joseph Muniz dhe Nadem Alfarhan (nĂ« lidhjen mund tĂ« shkarkoni njĂ« pjesĂ« tĂ« librit). Keni tre mundĂ«si pĂ«r tĂ« arritur kĂ«tĂ« qĂ«llim â tĂ« lexoni librin e plotĂ«, ta kaloni me shikim, duke u ndalur nĂ« çdo faqe tĂ« 10-tĂ« ose tĂ« 20-tĂ«, ose tĂ« provoni tĂ« gjeni njĂ« pĂ«rmbledhje tĂ« koncepteve kryesore nĂ« ndonjĂ« blog apo shĂ«rbim si SmartReading. Pra, telemetria e pasampĂ«lluar Ă«shtĂ« leximi i çdo âfaqeâ tĂ« trafikut rrjetit, domethĂ«nĂ« analiza e metadatat pĂ«r çdo paketĂ«. Telemetria e sampĂ«lluar Ă«shtĂ« studimi selektiv i trafikut me shpresĂ«n se nĂ« mostra tĂ« zgjedhura do tĂ« gjendet ajo qĂ« ju nevojitet. NĂ« varĂ«si tĂ« shpejtĂ«sisĂ« sĂ« kanalit, telemetria e sampĂ«lluar do tĂ« kthejĂ« pĂ«r analizĂ« çdo 64-tĂ«, 200-tĂ«, 500-tĂ«, 1000-tĂ«, 2000-tĂ« ose madje 10000-tĂ« paketĂ«.
Në kontekstin e monitorimit të sigurisë, kjo nënkupton që telemetria e mostrave është e përshtatshme për zbulimin e sulmeve DDoS, skanimeve, përhapjes së kodit të dëmshëm, por mund të humbasë sulmet atomike ose shumë-pako, të cilat nuk kanë rënë në mostrat e dërguara për analizë. Telemetria e pazgjedhur nuk ka këto disavantazhe dhe me ndihmën e saj, spektri i sulmeve që mund të zbulohen është shumë më i gjerë. Ja një përmbledhje e vogël e ngjarjeve që mund të zbulohen me anë të mjeteve të analizës së telemetrisë rrjetit.
Sigurisht, ndonjë analizues open source Netflow nuk do t'ju lejojë këtë, pasi detyra e tij kryesore është të mbledhë telemetrinë dhe të kryejë një analizë themelore në pikëpamjen IT. Për të identifikuar kërcënimet e sigurisë së informacionit mbi bazën e flukseve, është e nevojshme të pajisni analizuesin me engine dhe algoritme të ndryshme, të cilat do të identifikojnë problemet e sigurisë kibernetike mbi bazën e fushave standarde ose të personalizuara të Netflow, të pasurojnë të dhënat standarde me të dhëna nga burime të ndryshme të Inteligjencës mbi Kërcënimet, etj.
Prandaj, nëse keni zgjedhje, zgjidhni Netflow ose IPFIX. Por edhe nëse pajisjet tuaja punojnë vetëm me sFlow, siç ndodh me prodhuesit vendas, atëherë edhe në këtë rast mund të nxirrni dobi prej tij në kontekstin e sigurisë.
Në verën e vitit 2019, unë kryeva një analizë të mundësive që kanë prodhuesit rusë të pajisjeve rrjetore dhe të gjithë ata, përveç NSG, Poligonit dhe Kraftveit, deklaruan mbështetje për sFlow (të paktën, Zelaks, Natex, Eltex, QTech, Rusteletech).
Pyetje e ardhshme qĂ« do t'ju dalĂ« Ă«shtĂ«, ku mund tĂ« integrohet mbĂ«shtetje pĂ«r flow pĂ«r qĂ«llime sigurie? NĂ« tĂ« vĂ«rtetĂ«, pyetja Ă«shtĂ« formuluar paksa gabim. NĂ« pajisjet moderne, mbĂ«shtetja pĂ«r protokollet flow Ă«shtĂ« pothuajse gjithmonĂ« e pranishme. Prandaj, unĂ« do ta riformuloja pyetjen ndryshe â ku Ă«shtĂ« mĂ« efikase tĂ« mblidhet telemetria nga pikĂ«pamja e sigurisĂ«? PĂ«rgjigjja do tĂ« jetĂ« mjaft e qartĂ« â nĂ« nivelin e qasjes, ku do tĂ« shihni 100% tĂ« gjithĂ« trafikut, ku do tĂ« keni informacion tĂ« detajuar pĂ«r host-et (MAC, VLAN, ID e ndĂ«rfaqes), ku do tĂ« mund tĂ« gjurmoni madje edhe trafikun P2P midis host-eve, çka Ă«shtĂ« thelbĂ«sore pĂ«r zbulimin e skanimeve dhe shpĂ«rndarjen e kodit tĂ« dĂ«mshĂ«m. NĂ« nivelin e kernelit, pjesa e trafikut mund tĂ« mos shihet as nuk do tĂ« shihni mĂ« shumĂ« se njĂ« e katĂ«rta e gjithĂ« trafikut tuaj rrjetor nĂ« nivelin e perimetrit. Por nĂ«se pĂ«r ndonjĂ« arsye keni pajisje tĂ« huaja nĂ« rrjetin tuaj, duke lejuar qĂ« sulmuesit tĂ« âhynĂ« dhe dalinâ, duke anashkaluar perimetrin, atĂ«herĂ« analiza e telemetrisĂ« nga ai do tĂ« mos ju sjellĂ« asgjĂ«. Prandaj, pĂ«r njĂ« mbulim maksimal, rekomandohet qĂ« mbledhja e telemetrisĂ« tĂ« bĂ«het pikĂ«risht nĂ« nivelin e qasjes. NĂ« tĂ« njĂ«jtĂ«n kohĂ«, duhet tĂ« theksohet se edhe nĂ«se flasim pĂ«r virtualizimin ose kontejnerĂ«t, nĂ« switch-at virtual modernĂ« shpesh gjendet mbĂ«shtetje pĂ«r flow, e cila lejon kontrollimin e trafikut edhe aty.
Por pasi e ngrita temën, duhet të përgjigjem në pyetjen, çfarë ndodh nëse pajisja, fizike ose virtuale, nuk mbështet protokollet flow? Apo aktivizimi i saj është i ndaluar (për shembull, në segmentet industriale për të siguruar besueshmërinë)? Ose aktivizimi i saj çon në një ngarkesë të lartë në procesorin qendror (në disa raste ndodh me pajisje të vjetra)? Për zgjidhjen e kësaj çështjeje ekzistojnë sensora virtualë të specializuar (flow sensor), të cilët në thelb janë thjesht deka, që kalojnë trafik dhe e transmetojnë atë në formën e flow në modulin e mbledhjes. Megjithatë, në këtë rast ne kemi të gjithë grumbullin e problemeve që përmendëm më lart në lidhje me mjetet e kapjes së paketave. Pra, duhet të kuptohet jo vetëm përfitimet e teknologjisë së analizës së protokolleve, por edhe kufizimet e saj.
NjĂ« tjetĂ«r çështje qĂ« Ă«shtĂ« e rĂ«ndĂ«sishme tĂ« kemi parasysh, kur flasim pĂ«r mjetet e analizĂ«s sĂ« rrjedhave. NĂ«se pĂ«r mjetet e zakonshme tĂ« gjenerimit tĂ« ngjarjeve tĂ« sigurisĂ« pĂ«rdorim metriken EPS (ngjarje pĂ«r sekondĂ«), pĂ«r analizĂ«n e telemetrisĂ« ky tregues nuk Ă«shtĂ« i aplikueshĂ«m; ai zĂ«vendĂ«sohet me FPS (rrjedha pĂ«r sekondĂ«). Po ashtu si me EPS, nuk mund tĂ« llogaritet paraprakisht, por mund tĂ« vlerĂ«sohet numri i pĂ«rafĂ«rt i rrjedhave qĂ« gjeneron njĂ« pajisje e caktuar nĂ« varĂ«si tĂ« detyrĂ«s sĂ« saj. NĂ« internet mund tĂ« gjeni tabela me vlera pĂ«rafĂ«rsisht pĂ«r disa lloje pajisjesh korporative dhe kushteve, qĂ« do t'ju ndihmojnĂ« tĂ« parashikoni se cilat licenca ju nevojiten pĂ«r mjetet e analizĂ«s dhe cila do tĂ« jetĂ« arkitektura e tyre. Problemi Ă«shtĂ« se sensorĂ«t IDS kanĂ« njĂ« kapacitet tĂ« caktuar qĂ« ata "shkarkojnĂ«", ashtu si kolektorĂ«t e rrjedhave kanĂ« kufizimet e tyre, tĂ« cilat duhet t'i kuptoni. Prandaj, nĂ« rrjetet e mĂ«dha dhe gjeografikisht tĂ« shpĂ«rndara zakonisht ka disa kolektorĂ«. Kur po pĂ«rshkruaja, , isha duke sjellĂ« numrin e kolektorĂ«ve tanĂ« â ata janĂ« 21. Dhe kjo Ă«shtĂ« pĂ«r njĂ« rrjet tĂ« shpĂ«rndarĂ« nĂ« pesĂ« kontinente dhe me rreth gjysmĂ« milioni pajisje aktive).
Si sistem monitorimi Netflow ne pĂ«rdorim zgjidhjen tonĂ« , i cili Ă«shtĂ« veçanĂ«risht i orientuar pĂ«r zgjidhjen e problemeve tĂ« sigurisĂ«. Ai ka shumĂ« motorĂ« tĂ« integruar pĂ«r zbulimin e aktivitetit anormal, dyshues dhe qartĂ« keqdashĂ«s, duke lejuar identifikimin e njĂ« gamĂ« tĂ« gjerĂ« kĂ«rcĂ«nimesh â nga minimi i criptove deri te rrjedhjet e informacionit, nga pĂ«rhapja e kodit tĂ« dĂ«mshĂ«m deri te mashtrimi. Si shumica e analizatorĂ«ve tĂ« rrjedhave, Stealthwatch Ă«shtĂ« ndĂ«rtuar sipas njĂ« skeme me tre nivele (gjenerator â mbledhĂ«s â analizues), por ai Ă«shtĂ« i plotĂ«suar me njĂ« sĂ«rĂ« veçorish interesante, tĂ« rĂ«ndĂ«sishme nĂ« kontekstin e materialit nĂ« shqyrtim. SĂ« pari, ai integrohet me zgjidhjet pĂ«r kapjen e paketeve (p.sh., Cisco Security Packet Analyzer), duke lejuar regjistrimin e seancave rrjetesh tĂ« zgjedhura pĂ«r hetim dhe analizĂ« tĂ« thellĂ« mĂ« vonĂ«. SĂ« dyti, pĂ«r tĂ« zgjeruar detyrat e sigurisĂ«, ne kemi zhvilluar njĂ« protokoll tĂ« veçantĂ« nvzFlow, i cili lejon âtransmetiminâ e aktivitetit tĂ« aplikacioneve nĂ« nyjat fundore (servera, stacione pune etj.) nĂ« telemetri dhe ta kalojĂ« atĂ« nĂ« mbledhĂ«s pĂ«r njĂ« analizĂ« tĂ« mĂ«tejshme. NĂ« versionin e tij origjinal, Stealthwatch punon me çdo protokoll rrjedhe (sFlow, rFlow, Netflow, IPFIX, cFlow, jFlow, NetStream) nĂ« nivelin e rrjetit, ndĂ«rsa mbĂ«shtetja pĂ«r nvzFlow lejon korrelacionin e tĂ« dhĂ«nave edhe nĂ« nivelin e nyjĂ«s, duke e rritur kĂ«shtu efikasitetin e gjithĂ« sistemit dhe duke parĂ« mĂ« shumĂ« sulme se analizatorĂ«t e zakonshĂ«m tĂ« rrjedhave tĂ« rrjetit.
ĂshtĂ« e qartĂ« se kur flasim pĂ«r sistemet e analizĂ«s sĂ« Netflow nga kĂ«ndvĂ«shtrimi i sigurisĂ«, tregu nuk Ă«shtĂ« i kufizuar vetĂ«m nĂ« njĂ« zgjidhje nga Cisco. Ju mund tĂ« pĂ«rdorni si zgjidhje komerciale, ashtu edhe me pĂ«rmbajtje falas ose gjysmĂ« tĂ« lirĂ«. ĂshtĂ« mjaft e çuditshme, nĂ«se unĂ« nĂ« blogun e Cisco do tĂ« pĂ«rmendja zgjidhjet e konkurrentĂ«ve, prandaj do tĂ« them disa fjalĂ« pĂ«r mĂ«nyrĂ«n se si telemetria rrjetore mund tĂ« analizohet me dy mjete tĂ« njohura, tĂ« ngjashme nĂ« emĂ«r, por gjithsesi tĂ« ndryshme â SiLK dhe ELK.
SiLK â Ă«shtĂ« njĂ« grup mjetesh (Sistemi pĂ«r NjohurinĂ« nĂ« Nivelin e Internetit) pĂ«r analizĂ«n e trafikut, i zhvilluar nga CERT/CC amerikan dhe qĂ« mbĂ«shtet, nĂ« kontekstin e kĂ«tij artikulli, Netflow (versionet e tij mĂ« tĂ« njohura 5 dhe 9), IPFIX dhe sFlow dhe, pĂ«rmes disa utilitarĂ«ve (rwfilter, rwcount, rwflowpack etj.), kryen operacione tĂ« ndryshme mbi telemetrinĂ« rrjetore me qĂ«llim identifikimin e shenjave tĂ« veprimeve tĂ« paautorizuara. Por duhet theksuar disa pika tĂ« rĂ«ndĂ«sishme. SiLK Ă«shtĂ« njĂ« mjet me komandĂ« dhe pĂ«r tĂ« kryer njĂ« analizĂ« operacionale, duhet tĂ« jepni vazhdimisht komanda tĂ« tipit (identifikimi i paketave ICMP mĂ« tĂ« mĂ«dha se 200 byte):
rwfilter --flowtypes=all/all --proto=1 --bytes-per-packet=200- --pass=stdout | rwrwcut --fields=sIP,dIP,iType,iCode --num-recs=15
nuk Ă«shtĂ« shumĂ« e pĂ«rshtatshme. Mund tĂ« pĂ«rdorni ndĂ«rfaqen grafike iSiLK, por ajo nuk do ta lehtĂ«sojĂ« shumĂ« jetĂ«n tuaj, duke zgjidhur vetĂ«m funksionin e vizualizimit dhe jo zĂ«vendĂ«simin e analistit. Dhe ky Ă«shtĂ« momenti i dytĂ«. Ndryshe nga zgjidhjet komerciale, tĂ« cilat kanĂ« njĂ« bazĂ« tĂ« fortĂ« analitike, algoritme pĂ«r identifikimin e anomalive, rrjedha pune etj., nĂ« rastin e SiLK, ju duhet ta bĂ«ni tĂ« gjithĂ« kĂ«tĂ« vetĂ«, e cila do t'ju kĂ«rkojĂ« disa kompetenca tĂ« ndryshme nga pĂ«rdorimi i mjeteve qĂ« janĂ« tashmĂ« gati pĂ«r punĂ«. Kjo nuk Ă«shtĂ« mirĂ« dhe as keq â Ă«shtĂ« njĂ« veçori e pothuajse çdo instrumenti falas, i cili nĂ«nkupton se ju dini se çfarĂ« tĂ« bĂ«ni dhe ai ju ndihmon vetĂ«m nĂ« kĂ«tĂ« proces (mjetet komerciale janĂ« mĂ« pak tĂ« varura nga kompetencat e pĂ«rdoruesve tĂ« tyre, megjithatĂ«, ato gjithashtu presin qĂ« analistĂ«t tĂ« kuptojnĂ« tĂ« paktĂ«n bazat e hetimeve dhe monitorimit tĂ« rrjetit). Por le tĂ« kthehemi te SiLK. Cikli i punĂ«s sĂ« analistit me tĂ« duket si mĂ« poshtĂ«:
- Formulimi i hipotezës. Duhet të kuptojmë se çfarë do të kërkojmë brenda telemetrisë rrjetore, të njohim atributet unike me të cilat do të identifikojmë anomalitë ose kërcënimet e caktuara.
- Ndërtimi i modelit. Pasi kemi formuluar hipotezën, ne e programojmë atë duke përdorur të njëjtin Python, shell apo mjete të tjera që nuk përfshihen në SiLK.
- Testimi. Tani vjen koha për të verifikuar saktësinë e hipotezës sonë, e cila konfirmohet ose mohohet përmes mjeteve të SiLK, që fillojnë me 'rw', 'set', 'bag'.
- Analiza e të dhënave reale. Në operimin industrial, SiLK na ndihmon të zbulojmë diçka, dhe analisti duhet të përgjigjet në pyetjet "A kemi gjetur atë që supozonim?", "A përputhet kjo me hipotezën tonë?", "Si ta zvogëlojmë numrin e alarmave false?", "Si ta përmirësojmë nivelin e njohjes?" etj.
- PĂ«rmirĂ«simi. NĂ« etapĂ«n pĂ«rfundimtare, ne pĂ«rmirĂ«sojmĂ« atĂ« qĂ« kemi bĂ«rĂ« mĂ« parĂ« â krijojmĂ« template, pĂ«rmirĂ«sojmĂ« dhe optimizojmĂ« kodin, riformulojmĂ« dhe saktĂ«sojmĂ« hipotezĂ«n etj.
Ky cikĂ«l do tĂ« jetĂ« i aplikueshĂ«m edhe pĂ«r Cisco Stealthwatch, vetĂ«m se ky i fundit maksimizuar automatikisht kĂ«to pesĂ« hapa, duke zvogĂ«luar numrin e gabimeve nga analisti dhe duke rritur shpejtĂ«sinĂ« e zbulimit tĂ« incidenteve. PĂ«r shembull, nĂ« SiLK, statistikĂ«n e rrjetit mund ta pasuruar me tĂ« dhĂ«na tĂ« jashtme pĂ«r IP-tĂ« keqdashĂ«se pĂ«rmes skripteve tĂ« shkruara vetĂ«, ndĂ«rsa nĂ« Cisco Stealthwatch â kjo Ă«shtĂ« njĂ« funksionalitet i ndĂ«rtuar, qĂ« menjĂ«herĂ« ju tregon njĂ« sinjal alarmi nĂ«se nĂ« trafikun e rrjetit hasni ndĂ«rveprime me IP-tĂ« nga lista e zezĂ«.
NĂ«se shohim mĂ« lart nĂ« piramidĂ«n e "pagesave" tĂ« softuerit pĂ«r analizĂ«n e flukseve, pas SiLK krejtĂ«sisht falas vjen ELK, i cili pĂ«rbĂ«het nga tre komponentĂ« kryesorĂ« â Elasticsearch (indeksimi, kĂ«rkimi dhe analiza e tĂ« dhĂ«nave), Logstash (hyrja/daljen e tĂ« dhĂ«nave) dhe Kibana (vizualizimi). Ndryshe nga SiLK, ku gjithçka duhet ta shkruani vetĂ«, ELK ka shumĂ« biblioteka/modula tĂ« gatshĂ«m (disa pagesĂ«, disa jo), qĂ« automatizojnĂ« analizĂ«n e telemetrisĂ« sĂ« rrjetit. PĂ«r shembull, filtri GeoIP nĂ« Logstash lejon lidhjen e IP-ve tĂ« vĂ«zhguara me pozitat e tyre gjeografike (nĂ« tĂ« njĂ«jtin Stealthwatch kjo Ă«shtĂ« njĂ« funksionalitet i ndĂ«rtuar).
ELK gjithashtu ka një komunitet të madh, që shkruan komponentët e munguar 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 e Netflow të Logstash, që mbështet vetëm Netflow.
Duke ofruar më shumë shpejtësi në mbledhjen e flukseve dhe kërkimin në to, ELK për momentin nuk ka një analizë të pasur të ndërtuar për zbulimin e anomalive dhe kërcënimeve në telemetrinë e rrjetit. Atëherë, duke ndjekur ciklin e jetës të përshkruar më sipër, do t'ju duhet t'i përshkruani vetë modelet e shkeljeve dhe më pas të përdorni ato në sistemin e luftës (nuk ka modele të ndërtuara atje).
Sigurisht, ekzistojnĂ« edhe zgjatje mĂ« tĂ« avancuara pĂ«r ELK, nĂ« tĂ« cilat janĂ« tĂ« inkorporuara disa modele pĂ«r identifikimin e anomali nĂ« telemetrinĂ« rrjetore, por kĂ«to zgjatje kushtojnĂ« para dhe kĂ«tu lind pyetja, a ia vlen pĂ«rpjekja â tĂ« shkruash njĂ« model tĂ« ngjashĂ«m vetĂ«, tĂ« blesh realizimin e tij pĂ«r mjetin tĂ«nd tĂ« monitorimit ose tĂ« blesh njĂ« zgjidhje tĂ« gatshme tĂ« klasĂ«s Analiza e Trafikut tĂ« Rrjetit.
Në të vërtetë, nuk dua të hyj në polemikë se është më mirë të shpenzosh para dhe të blesh një zgjidhje të gatshme për monitorimin e anomali dhe kërcënimeve në telemetrinë rrjetore (p.sh., Cisco Stealthwatch) ose të merresh me të vetë dhe të rregullosh për çdo kërcënim të ri të njëjtin SiLK, ELK ose nfdump ose OSU Flow Tools (kam parasysh dy të fundit). në herën e fundit)? Secili zgjedh për vete dhe çdo njërin e kanë motivet e veta për të zgjedhur një nga këto dy mundësi. Unë vetëm doja të tregoja se telemetria rrjetore është një mjet shumë i rëndësishëm në sigurimin e sigurisë së rrjetit të infrastrukturës së tij të brendshme dhe nuk duhet neglizhuar që të mos përfshin listën e kompanive, të cilat emri i tyre përmendet në media bashkë me epitetet "i hackuar", "nuk përmbushte kërkesat për siguri" dhe "nuk mendon për sigurinë e të dhënave të saj dhe të dhënave të klientëve".
Duke përmbledhur, do doja të përmend disa këshilla thelbësore, të cilave ia vlejnë të ndiqen gjatë ndërtimit të monitorimit të sigurisë së brendshme të infrastrukturës tuaj:
- Mos u kufizoni vetëm në perimetrin! Përdorni (dhe zgjidhni) infrastrukturën rrjetore jo vetëm për të transferuar trafik nga pika A në pikën B, por gjithashtu për të zgjidhur çështje të sigurisë kibernetike.
- Studoni mekanizmat ekzistues të monitorimit të sigurisë në pajisjet tuaja rrjetore dhe aktivizoni ato.
- PĂ«r monitorimin e brendshĂ«m, preferoni analizĂ«n e telemetrisĂ« â ajo mund tĂ« zbulojĂ« deri nĂ« 80-90% tĂ« tĂ« gjitha incidenteve tĂ« sigurisĂ« nĂ« rrjet, duke bĂ«rĂ« ato qĂ« janĂ« tĂ« pamundura me kapjen e paketave rrjetore dhe duke kursyer hapĂ«sirĂ« pĂ«r ruajtjen e tĂ« gjitha ngjarjeve tĂ« sigurisĂ«.
- Për monitorimin e flukseve përdorni Netflow v9 ose IPFIX - ato japin më shumë informacion në kontekstin e sigurisë dhe lejojnë monitorimin jo vetëm të IPv4, por edhe të IPv6, MPLS, etj.
- Përdorni protokollin e flukseve pa kampionim - ai ofron më shumë informacion për zbuluar kërcënime. Për shembull, Netflow ose IPFIX.
- Kontrolloni ngarkesĂ«n e pajisjeve tuaja rrjetore â ndoshta ato nuk do tĂ« jenĂ« nĂ« gjendje tĂ« pĂ«rballojnĂ« edhe protokollin flow. AtĂ«herĂ« mendoni pĂ«r aplikimin e sensorĂ«ve virtualĂ« ose Netflow Generation Appliance.
- Zbatoni kontrollin fillimisht nĂ« nivelin e aksesit â kjo do t'ju mundĂ«sojĂ« tĂ« shihni 100% tĂ« gjithĂ« trafikut.
- Nëse nuk keni ndonjë zgjedhje dhe përdorni pajisje rrjetore ruse, zgjidhni ato që mbështesin protokollet flow ose kanë porte SPAN/RSPAN.
- Kombinoni sistemet e zbulimit/ parandalimit të sulmeve në kufijtë dhe sistemet e analizës së flukseve brenda rrjetit (përfshirë edhe në cloud).
Sa i përket këshillës së fundit, do të doja të sillja një ilustrim që e kam përmendur më parë. Shihni, nëse më parë shërbimi i Sigurisë së Informacionit Cisco pothuajse e ndërtonte të tërin sistemin e tij të monitorimit të Sigurisë së Informacionit mbi sistemet e zbulimit të sulmeve dhe metodat me nënshkrim, tani ato përbëjnë vetëm 20% të incidenteve. Një tjetër 20% përputhet me sistemet e analizës së flukseve, që tregon se këto zgjidhje nuk janë një kapriciozitet, por një instrument real në veprimtarinë e shërbimeve të Sigurisë së Informacionit të një ndërmarrjeje moderne. Sidomos, pasi që keni infrastrukturën rrjetore për t'i zbatuar, investimet në të cilat mund t'i mbrohen në mënyrë shtesë duke ngarkuar edhe funksionet e monitorimit të Sigurisë së Informacionit.
Kisha për qëllim të mos merrem me temën e reagimit ndaj anomalive ose kërcënimeve të identifikuara në flukset rrjetore, por mendoj se është e qartë që monitorimi nuk duhet të përfundojë vetëm me identifikimin e kërcënimit. Pas kësaj duhet të ndiqet një reagim, dhe preferohet në mënyrë automatike ose të automatizuar. Por kjo është një temë e materialeve të ndara.
Informacion shtesë:
PS. Nëse ju duket më e lehtë të kuptoni fjalët e shkruara në mënyrë të dëgjueshme, mund të shikoni një prezantim njëorësh që shërbeu si bazë për këtë shënim.
Burimi: habr.com
