🥇Flow-protokollid sisevõrgu turvamonitorimise tööriistana

Kui räägitakse ettevõtte sisevõrgu või osakonna võrgu turvamonitorimisest, tekib paljudel assotsiatsioon teabe lekkimise kontrollimise ja DLP-lahenduste rakendamisega. Ent kui proovida küsimust täpsustada ja küsida, kuidas te sisevõrgu rünnakuid tuvastate, on vastuseks tavaliselt mainimine rünnakute avastamise süsteemidest (intrusion detection systems, IDS). See, mis oli ainus variant veel 10–20 aastat tagasi, muutub täna anahroonismiks. On olemas tõhusam, kohati isegi ainus võimalik variant sisevõrgu jälgimiseks — kasutada flow-protokolle, mis algselt olid mõeldud võrguprobleemide leidmiseks (troubleshooting), kuid on aja jooksul kujunenud huvitavaks turvakasutuseks. Räägime, milliseid flow-protokolle on olemas ja millised neist aitavad paremini tuvastada võrgu rünnakuid, kus on kõige parem rakendada flow-monitooringut, millele tuleb tähelepanu pöörata sellise skeemi juurutamisel ja isegi sellest, kuidas seda kodumaisel varustusel „üles seada“.

Ma ei hakka küsimusele „Miks on vajalik sisemise infrastruktuuri turvalisuse jälgimine?” süvenema. Vastus sellele on nagu nii selge. Aga kui te ikka tahaksite veel kord veenduda, et tänapäeval on see hädavajalik, vaadake väike video, kus räägitakse, kuidas saab 17 erineva viisi kaudu tungida ettevõtte võrku, mida kaitseb tulemüür. Seega oletame, et me mõistame, et sisemine jälgimine on vajalik ning nüüd jääb vaid mõista, kuidas seda korraldada.

Nimetaksin kolme peamist andmeallikat võrgutasandi infrastruktuuri jälgimiseks:

„toores” liiklus, mida me tabame ja suuname analüüsisüsteemide jaoks,
sündmused võrgu seadmetest, mille kaudu liiklus voolab,
teave liikluse kohta, mida saadakse ühe flow-protokolli kaudu.

Toores liikluse salvestamine on turbeekspertide seas kõige populaarsem valik, kuna see ilmus ajaloos esimesena. Tavalised ründe avastamise võrgusüsteemid (esimene kommertsvahend rünnakute tuvastamiseks oli NetRanger ettevõttelt Wheel Group, mille Cisco ostis 1998. aastal) tegelesid just pakettide salvestamisega (hiljem ka sessioonidega), kus otsiti kindlaid allkirju („otsustavad reeglid“ FSTEK-i terminoloogias), mis viitavad rünnakutele. Loomulikult saab toorest liiklust analüüsida mitte ainult IDS-i abil, vaid ka teiste vahenditega (nagu Wireshark, tcpdump või Cisco IOS-i NBAR2 funktsionaalsus), kuid neil puudub tavaliselt teadmiste baas, mis eristab kaitsemeetmeid tavalistest IT- tööriistadest.

Seega, ründe tuvastamise süsteemid. Kõige vanem ja populaarsem meetod võrku kuuluvate rünnakute avastamiseks, mis on suuteline oma ülesandega rahuldavalt toime tulema perimeetril (olgu see siis ettevõtte, andmekeskuse, segmendi jne), kuid jääb jõuetuks tänapäevastes lülitustes ja tarkvaramugandustsüstemides. Kui tegemist on võrgu, mis on üles ehitatud tavaliste lülitite baasil, tundub tuvastamise sensorite infrastruktuur liiga ulatuslik — teil tuleb paigaldada iga ühenduse jaoks sensor, millel soovite rünnakute jälgimist. Iga tootja müüks heal meelel teile sadu ja isegi tuhandeid sensoreid, kuid teie eelarve ei pruugi sellist kulu taluda. Võin öelda, et isegi Cisco (kus me oleme NGIPS'i arendajad) ei suutnud seda teostada, kuigi hind ei tohiks justkui takistuseks olla — see on ju meie enda lahendus. Lisaks tekib küsimus, kuidas sellises variandis sensoreid ühendada? Katkestuse kaudu? Aga kui sensor ise on rikke tõttu välja lülitatud? Kas peaks nõudma, et sensoril oleks bypass-moodul? Kas kasutada jagureid (tap)? Kõik see suurendab lahenduse hinda ja muudab selle kätte saada keeruliseks igasuguste ettevõtete jaoks.

Saate proovida “riputada” sensori SPAN/RSPAN/ERSPAN-porti ja suunata sellele liiklust vajalikelt lülitite portidelt. See lahendus leevendab osaliselt eelnevas lõigus kirjeldatud probleemi, kuid toob kaasa teise — SPAN-port ei suuda vastu võtta kogu liiklust, mis sellele suunatakse, sest selle läbilaskevõime on piiratud. Tõttu tuleb millegagi leppida. Kas jätta osa sõlmedest jälgimata (sel juhul on enne vajalik nende prioriseerimine) või suunata mitte kogu liiklus sõlmest, vaid ainult teatud tüüpi. Igatahes võivad mõned rünnakud jääda tähelepanuta. Lisaks sellele võib SPAN-port olla hõivatud teiste ülesannete jaoks. Kokkuvõttes peame üle vaatama olemasoleva võrgutopoloogia ja võib-olla tegema sellesse muudatusi, et hõlmata teie võrgus võimalikult palju sensoreid (ja kooskõlastama seda IT-ga).

Ja kui teie võrk kasutab asümmeetrilisi marsruute? Ja kui teil on rakendatud või kavandatud SDN-i? Ja kui peate jälgima virtualiseeritud masinaid või konteinerite liiklust, mis ei jõua füüsilisse lülitisse? Need küsimused ei meeldi traditsioonilistele IDS-i tootjatele, sest nad ei tea, kuidas neile vastata. Võib-olla püüavad nad teid veenda, et kõik need moes tehnoloogiad on vaid hype ja te ei vaja neid. Võib-olla räägivad nad vajadusest alustada väikestest sammudest. Võib-olla ütlevad nad, et peate keskele paigaldama võimsa seadme ja suunama kogu liikluse selle kaudu koormuse jaotajate abil. Millist varianti ka ei pakutaks, peate ise selgelt mõistma, kui hästi see teile sobib. Ja ainult pärast seda võib võtta otsuse võrgu infrastruktuuri jälgimise lähenemise valimiseks. Naastes pakettide püüdmiseks, tahan öelda, et see meetod jääb endiselt väga populaarseks ja oluliseks, kuid selle peamine eesmärk on piiride kontroll; piiride vahel teie organisatsiooni ja Interneti vahel, piiride vahel andmekeskuse ja ülejäänud võrgu vahel, piirade vahel ASUT ja ettevõtte segmendi vahel. Nendes kohtades on klassikalised IDS/IPS endiselt õigustatud ja saavad oma ülesannetega hästi hakkama.

Liigume teise variandi juurde. Võrguseadmetest saadud sündmuste analüüsi saab samuti kasutada rünnakute tuvastamiseks, kuid mitte põhimehhanismina, kuna see võimaldab tuvastada vaid väikest klassi sissetunge. Lisaks on sellele iseloomulik teatud reaktiivsus - rünnak peab esmalt toimuma, seejärel peab see olema fikseeritud võrguseadmest, mis mingil moel annab märku probleemist IT-turbe osas. Selliseid viise on mitmeid. See võib olla syslog, RMON või SNMP. Viimaseid kahte protokolli kasutatakse võrgujälgimise kontekstis IT-turbe osas ainult siis, kui meil on vajalik avastada DoS-rünnak ise võrguseadmest, kuna RMON ja SNMP abil saab näiteks jälgida seadme keskprotsessori või selle liideste koormust. See on üks kõige "odavamaid" (syslog või SNMP on kõigil), kuid ka kõige ebaefektiivsem viise IT-turbe jälgimiseks sisemises infrastruktuuris - paljusid rünnakuid on sellest lihtsalt varjatud. Loomulikult ei tohiks neid eirata ja sama syslogi analüüs aitab teil õigeaegselt tuvastada seadme konfiguratsiooni muutusi, selle kompromiteerimist, kuid kogu võrku rünnakute tuvastamiseks ei sobi see liiga hästi.

Kolmas valik on teabe analüüs, mis puudutab seadmes voolavaid andmeid, mis toetab üht erinevatest voolusuundadest. Sellisel juhul koosneb voolude töötlemise infrastruktuur alati kolmest komponendist:

Voolu genereerimine või eksport. See roll lasub tavaliselt ruuteril, lülitil või muul võrguseadmest, mis suunab läbi enda võrguliiklust, et eraldada võtmeparameetrid, mis edastatakse seejärel kogumoodulile. Näiteks toetab Cisco Netflow protokolli mitte ainult ruuterites ja lülitites, sealhulgas virtuaalsetes ja tööstuslikes seadmetes, vaid ka traadita kontrollerites, tulemüürides ja isegi serverites.
Voolu kogumine. Arvestades, et tänapäevases võrgus on tavaliselt rohkem kui üks võrguseade, tekib voogude kogumise ja konsolideerimise ülesanne, mis lahendatakse nn kollektorite abil, mis töötlevad saadud vooge ja edastavad need seejärel analüüsiks.
Flow analüüs. Analüsaator võtab endale põhiteadmiste ülesande ja rakendab voogudele erinevaid algoritme, et teha teatud järeldusi. Näiteks IT-funktsiooni raames võib see analüsaator tuvastada võrgu kitsaskohad või analüüsida liikluskoormuse profiili, et optimeerida võrku. Infotehnoloogia kontekstis võib selline analüsaator tuvastada andmelekkeid, pahavara levikut või DoS-rünnakuid.

Ärge arvake, et selline kolmepunktiline arhitektuur on liiga keeruline — kõik muud variandid (välja arvatud võib-olla SNMP ja RMON-iga töötavad võrgujälgimisse loonud süsteemid) toimivad samuti vastavalt sellele. Meil on andmeanalüüsi generaator, milleks on võrguseade või eraldi sensor. Meil on häiresignaalide kogumise süsteem ja kogu jälgimisinfrastruktuuri haldamise süsteem. Viimased kaks komponenti võivad olla ühendatud ühe sõlme raames, kuid enam-vähem suurtes võrkudes on need tavaliselt jaotatud vähemalt kahe seadme vahel, et tagada skaleeritavus ja usaldusväärsus.

Erinevalt paketianalüüsist, mis põhineb iga paketi päise ja andmekeha ning nende sessioonide uuringul, tugineb voogude analüüs võrgu liikluse metaandmete kogumisele. Millal, kui palju, kust ja kuhu, kuidas… need on küsimused, millele vastab võrgu telemeetri analüüs erinevate voogude protokollide abil. Esialgu kasutati neid statistika analüüsimiseks ja IT-probleemide leidmiseks võrgus, kuid hiljem, analüütiliste mehhanismide arenguga, on nende rakendamine sama telemeetria ja turvatarbeks saanud võimalikuks. Siinkohal tasub veel kord rõhutada, et voogude analüüs ei asenda ega tühista pakettide püüdmist. Igal neist meetoditest on oma kasutusala. Kuid käesoleva artikli kontekstis sobib voogude analüüs kõige paremini sisemise infrastruktuuri jälgimiseks. Teil on võrgu seadmed (ja ei ole oluline, kas need töötavad tarkvarapiirangutega või staatiliste reeglite alusel), kus rünnak ei saa mööda minna. Klassikalise IDS-sensoriga suudab see mööduda, kuid võrgu seade, mis toetab voogude protokolli, mitte. See on selle meetodi eelis.

Teiselt poolt, kui vajate tõendite kogumist õiguskaitse ametitele või oma uuringugrupile, ei saa te pakettide püüdmisega hakkama — võrgutelemeetrija ei ole liikluskoopia, mida saab kasutada tõendite kogumisel; see on vajalik kiireks avastamiseks ja otsuste tegemiseks infoturbe valdkonnas. Teiselt poolt, kasutades telemeetrias analüüsi, võite „salvestada” mitte kogu võrgu liiklust (kui midagi, siis tegeleb Cisco ja andmekeskustega :-), vaid ainult selle, mis osaleb rünnakus. Telemeetrianalüüsi vahendid täiendavad traditsioonilisi paketipüüdemehhanisme, andes käsu valikuliseks püüdmiseks ja salvestamiseks. Vastasel juhul peate teil olema tohutu salvestusinfra.

Kujutame ette võrku, mis töötab kiirusel 250 Mbit/s. Kui soovite salvestada kogu selle mahu, vajate 31 MB salvestusruumi ühe sekundi edastamiseks, 1,8 GB ühe minuti jaoks, 108 GB ühe tunni jaoks ning 2,6 TB ühe päeva jaoks. 10 Gbit/s läbilaskevõimega võrgu päevase andmete salvestamiseks on vajalik 108 TB salvestusruumi. Ja mõned regulatsioonid nõuavad andmete säilitamist aastaid... "Nõudmisel" salvestamine, mida voogude analüüs aitab ellu viia, aitab neid väärtusi järsult vähendada. Muide, kui rääkida võrgu telemeetria salvestatavate andmete mahu ja täiesti andmete haaramise suhte kohta, siis see on umbes 1 kuni 500. Eeltoodud väärtuste puhul tähendab see, et kogu päevase liikluse täisregistreerimine oleks vastavalt 5 ja 216 GB (seda on isegi võimalik salvestada tavalisel mälupulgal).

Kui toores võrguandmete analüüsi meetodite hankimise viis ei erine peaaegu üksteisest tootjate vahel, siis vooanalüüsi puhul on olukord teine. On mitmeid flow-protokolle, mille erinevustest tuleb teada just turvalisuse kontekstis. Kõige populaarsem on Netflow protokoll, mille on välja töötanud ettevõte Cisco. Sellel protokollil on mitmed versioonid, mis erinevad oma võimekuse ja salvestatava liiklustee teabe mahu poolest. Praegune versioon on üheksas (Netflow v9), mille alusel on loodud tööstusstandard Netflow v10, tuntud ka kui IPFIX. Tänapäeval toetab enamik võrgu tootjatest just Netflow või IPFIX oma seadmetes. Kuid on ka erinevaid teisi flow-protokolle — sFlow, jFlow, cFlow, rFlow, NetStream jne, millest sFlow on populaarsuse poolest ülekaalus. Just tema toetavad sageli kodumaised võrgu seadmete tootjad, kuna selle elluviimine on lihtsam. Millised on peamised erinevused Netflow vahel, mis on de facto standard, ja sFlow vahel? Peame esile tooma mitu olulist punkti. Esiteks, Netflow sisaldab seadistatud kasutaja välju, erinevalt fikseeritud väljadest sFlow-s. Teiseks, ja see on meie kontekstis kõige olulisem, kogub sFlow nn proovimise telemeetriat, mis erineb Netflow ja IPFIX-i mitteproovimisest. Milles siis nende vahe on?

Kujutlege, et otsustasite tutvuda raamatu “Security Operations Center: Building, Operating, and Maintaining your SOC” minu kolleegide — Gary McIntyre, Joseph Muniz ja Nadem Alfarhadi — (linki kaudu saate alla laadida raamatu osa). Teil on kolm võimalust soovitud eesmärgi saavutamiseks — lugeda raamat täielikult, sirvida seda, peatudes iga 10. või 20. lehekülje juures, või proovida leida peamiste kontseptsioonide kokkuvõtet milleski blogis või teenuses nagu SmartReading. Niisiis, näidatud telemeetriaga on tegemist iga “lehe” võrgu liikluse lugemisega, see tähendab iga paketi metaandmete analüüsimisega. Proovitud telemeetriaga on tegemist valikulise liikluse uurimisega lootuses, et valitud proovides on see, mida vajate. Sõltuvalt kanalist edastab proovitud telemeetria analüüsiks iga 64., 200., 500., 1000., 2000. või isegi 10000. paketi.

Infotehnoloogia kontekstis tähendab see, et proovitud telemeetria sobib hästi DDoS-rünnakute, skaneerimise ja pahavara leviku tuvastamiseks, kuid võib mööda vaadata aatomaarsete või mitme paketi rünnakutest, mis ei jõudnud analüüsiks saadetud proovidesse. Proovimata telemeetrial pole selliseid puudusi ja selle abil on tuvastatavate rünnakute spekter palju laiem. Siin on väike nimekiri sündmustest, mida saab tuvastada võrgu telemeetriat analüüsivate vahenditega.

Muidugi ei lase mõni open source Netflow analüsaator teil seda teha, kuna selle põhieesmärk on koguda telemeetriat ja teha selle üle põhianalüüsi IT seisukohalt. Teenustest AHS tuvastamiseks on vajalik analüsaator varustada erinevate mootoritega ja algoritmidega, mis tuvastavad küberohtusid standardsete või kohandatud Netflow väljade abil, rikastades standardandmeid erinevatest Threat Intelligence allikatest jne.

Seega, kui teil on valida, siis valige Netflow või IPFIX. Kuid isegi kui teie riistvara toetab ainult sFlow, nagu Venemaa tootjate puhul, siis saate sellest ka sellega seoses turvalisuse kontekstis kasu.

Aastal 2019 suvel analüüsisin Venemaa võrku riistvarade tootjate võimalusi ja kõik, välja arvatud NSG, Poligon ja Kraftway, väitsid, et nad toetavad sFlow (minimaalselt Zeelax, Natex, Eltex, QTech, Rusteletech).

Järgmine küsimus, mis teie ees kerkib, on, kuhu määrata flow-toe rakendamine turvealaste eesmärkide saavutamiseks? Tegelikult on küsimus esitatud veidi valesti. Kaasaegsetes seadmetes on flow-protokollide tugi peaaegu alati olemas. Seetõttu sooviksin küsimust ümber sõnastada — kus on kõige tõhusam koguda telemeetria andmeid turvalisuse seisukohalt? Vastus on suhteliselt ilmselge — juurutamise tasemel, kus näete 100% kogu liiklust, kus teil on detailne teave hostide kohta (MAC, VLAN, liidese ID), ning kus suudate jälgida ka P2P-liiklust hostide vahel, mis on kriitilise tähtsusega skaneerimise ja kahjuliku koodi leviku avastamiseks. Süsteemi tasemel võite osa liiklusest lihtsalt mitte näha, ja piiripunktide tasemel näete oma võrgu liiklusest heal juhul vaid veerandi. Kuid kui mingil põhjusel on teie võrgus kolmandate osapoolte seadmeid, mis lubavad ründajatel "sisse ja välja" liikuda, mööda piiripunkti, ei too sellest telemeetria analüüs teile midagi. Seetõttu on maksimaalse katvuse saavutamiseks soovitatav alustada telemeetria kogumist just juurutamise tasemel. Samuti tasub märkida, et isegi kui räägime virtualiseerimisest või konteineritest, siis kaasaegsetes virtuaalsetes lülitites esineb samuti sageli flow-toe, mis võimaldab liiklust seal kontrollida.

Kuna ma juba teemat tõstatasin, on vaja vastata küsimusele, mis siis, kui varustus, olgu see füüsiline või virtuaalne, ei toeta voogude protokolle? Või kui selle lubamine on keelatud (näiteks tööstussektorites, et tagada usaldusväärsus)? Või kui selle lubamine põhjustab kõrge protsessorikoormuse (see juhtub vananenud seadmetel)? Selle probleemi lahendamiseks on olemas spetsialiseeritud virtuaalsed sensorid (voogu sensor), mis põhimõtteliselt toimivad nagu tavalised jaoturid, mis suunavad läbi liiklust ja edastavad seda voona kogumise moodulile. Tõsi, sel juhul saame kõikvõimalikud probleemid, millest oleme varem rääkinud, seoses paketisnorgimise vahenditega. Seega tuleb mõista mitte ainult voogude analüüsi tehnoloogia eeliseid, vaid ka selle piiranguid.

Veel oluline asi, mida meeles pidada, rääkides vooluanalüüsi vahenditest. Kui tavaliste turvaseisundite genereerimise vahendite puhul kasutame EPS-i (event per second, sündmused sekundis), siis telemeetriat analüüsides ei ole see näitaja rakendatav; see asendatakse FPS-iga (flow per second, voog sekundis). Nii nagu EPS-i puhul, ei saa selle väärtust eelnevalt arvutada, kuid ligikaudu voogude arvu, mida seade teatud ülesande täitmiseks genereerib, saab hinnata. Internetis leiate ligikaudseid väärtusi erinevat tüüpi ettevõtete seadmete ja tingimuste kohta, mis aitavad teil hinnata, millised load on analüüsivahenditele vajalikud ja milline on nende arhitektuur? Asi on selles, et IDS-anduril on piiratud läbilaskevõime, mida see suudab „tõmmata“, samuti on ka voogude kogujal oma piirangud, mida tuleb mõista. Seetõttu on suurtes, territoriaalselt jaotatud võrkudes tavaliselt mitu kogujaid. Kui ma kirjeldasin, kuidas jälgitakse Cisco sees võrku, olen juba maininud meie kogujate arvu — neid on 21. Ja see on võrgu jaoks, mis on jaotatud üle viie mandri ja hõlmab umbes pool miljonit aktiivset seadet).

Monitoringsüsteemina Netflow kasutame meie enda lahendust Cisco Stealthwatch, которое специально ориентировано на решение задач безопасности. У него много встроенных движков обнаружения аномальной, подозрительной и явно вредоносной активности, позволяющей детектировать широкий спектр различных угроз — от криптомайнинга до утечек информации, от распространения вредоносного кода до мошенничества. Как и большинство анализаторов потоков Stealthwatch построен по трехуровневой схеме (генератор — коллектор — анализатор), но он дополнен рядом интересных особенностей, которые важны в контексте рассматриваемого материала. Во-первых, он интегрируется с решениями по захвату пакетов (например, Cisco Security Packet Analyzer), что позволяет записывать выбранные сетевые сессии для последующего глубокого расследования и анализа. Во-вторых, специально для расширения задач безопасности мы разработали специальный протокол nvzFlow, который позволяет “транслировать” активность приложений на оконечных узлах (серверах, рабочих станциях и т.п.) в телеметрию и передавать ее на коллектор для дальнейшего анализа. Если в своей исконном варианте Stealthwatch работает с любым flow-протоколом (sFlow, rFlow, Netflow, IPFIX, cFlow, jFlow, NetStream) на уровне сети, то поддержка nvzFlow позволяет проводить корреляцию данных еще и на уровне узла, тем самым. повышая эффективности всей системы и видя больше атак, чем обычные сетевые анализаторы потоков.

Selge on, et kui rääkida Netflow analüüsisüsteemidest turvalisuse vaatepunktist, ei piirdu turg ainult Cisco lahendustega. Saate kasutada nii kommertslikke kui ka tasuta või osaliselt tasuta lahendusi. Veidi kummaline oleks, kui tointrodukksin Cisco blogis konkurentide lahendusi, seetõttu ütlen paar sõna, kuidas saab võrgu telemeetriat analüüsida kahe populaarse, kuigi nimetuse poolest sarnase, kuid siiski erineva tööriista — SiLK ja ELK abil.

SiLK on tööriistade kogum (Internetitasandi Teadmiste Süsteem), mis on välja töötatud Ameerika CERT/CC poolt ja mis toetab, seoses tänase artikliga, Netflow (5. ja 9. kõige populaarsemad versioonid), IPFIX ja sFlow, tehes erinevate utiliitide (nt rwfilter, rwcount, rwflowpack ja muud) abil erinevaid toiminguid võrgu telemeetriaga, et tuvastada selles volitamata tegevuse märke. Kuid tasub märkida paar olulist punkti. SiLK on käsurea tööriist ja operatiivanalüüsi tegemiseks tuleb pidevalt sisestada käske, nagu (tuvastamine ICMP-pakettide suurusega üle 200 bait):

rwfilter --flowtypes=all/all --proto=1 --bytes-per-packet=200- --pass=stdout | rwrwcut --fields=sIP,dIP,iType,iCode --num-recs=15

see, et ei ole väga mugav. Võite kasutada graafilist liidest iSiLK, kuid see ei tee teie elu palju kergemaks, lahendades vaid visualiseerimise funktsiooni, mitte analüütiku asendamise. Ja see on teine moment. Erinevalt kommertslahendustest, millel on juba tugev analüütikabaas, anomaaliate tuvastamise algoritmid, vastavad töövood jne, peate SiLKi puhul kõike selle ise tegema, mis nõuab teilt veidi teistsuguseid oskusi kui valmis lahenduste kasutamine. See ei ole halb ega hea — see on peaaegu iga tasuta tööriista omadus, mis eeldab, et te tead, mis teha, ja see aitab teil seda teha (kommerts tööriistad on vähem sõltuvad oma kasutajate oskustest, kuigi eeldavad ka, et analüütikud mõistavad vähemalt võrguuurimise ja jälgimise põhialuseid). Aga naaseme SiLKi juurde. Analüütiku töötsükkel selle kasutamisel on järgmine:

Hüpoteesi sõnastamine. Me peame mõistma, mida me otsime võrgu telemeetriast, teadma ainulaadseid atribuute, mille alusel tuvastame teatud kõrvalekaldeid või ohte.
Mudeli koostamine. Hüpoteesi sõnastanuna programmeerime selle sama Pythoniga, shelliga või muude tööriistadega, mis ei kuulu SiLK-i.
Testimine. Jõuab kätte meie hüpoteesi kontrollimise aeg, mis kinnitatakse või ümber lükatakse SiLK-i utiliitide abil, mis algavad 'rw', 'set', 'bag'.
Reaalsete andmete analüüs. SiLK tööstuslikus kasutuses aitab meil tuvastada midagi ning analüütik peab vastama küsimustele 'Kas me leidsime selle, mida eeldasime?', 'Kas see vastab meie hüpoteesile?', 'Kuidas vähendada valehäirete arvu?', 'Kuidas parandada tuvastamise taset?' ja nii edasi.
Parandamine. Lõppfaasis parandame varem tehtut — loome malle, täiustame ja optimeerime koodi, sõnastame hüpoteesi uuesti ja täpsustame seda jne.

See tsükkel kehtib ka Cisco Stealthwatchile, kuid viimane automatiseerib need viis sammu maksimaalselt, vähendades analüütiku vigu ja suurendades juhtumite avastamise kiirus. Näiteks SiLKis saate võrgu statistikat rikastada väliste andmetega pahatahtlike IP-de kohta oma käega kirjutatud skriptide abil, samas kui Cisco Stealthwatchis on see sisseehitatud funktsioon, mis näitab teile kohe häiresignaali, kui võrgu liikluses ilmneb suhtlemine musta nimekirja kantud IP-aadressidega.

Kui liikuda kõrgemale flow analüüsi tarkvara 'taseme' püramiidis, siis täiesti tasuta SiLK-i kõrval on tinglikult tasuta ELK, mis koosneb kolmest põhikomponendist — Elasticsearch (andmete indekseerimine, otsing ja analüüs), Logstash (andmete sisend/väljund) ja Kibana (visualiseerimine). Erinevalt SiLK-ist, kus tuleb kõik ise kirjutada, on ELK-l juba palju valmis raamatukogusid/moduule (osa tasulisi, osa tasuta), mis automatiseerivad võrgu telemeetriate analüüsi. Näiteks Logstashis olev GeoIP filter võimaldab seostada jälgitavad IP-aadressid nende geograafilise asukohaga (samuti Stealthwatchis on see sisseehitatud funktsioon).

ELK-l on samuti piisavalt suur kogukond, kes kirjutab selle jälgimislahenduse puuduolevaid komponente. Näiteks, et töötada Netflow, IPFIX ja sFlow'ga, võite kasutada moodulit elastiflow, kui te ei ole rahul Logstashi Netflow mooduliga, mis toetab ainult Netflow'd.

Pakub rohkem operatiivsust voogude kogumisel ja nende otsimisel, kuid ELK-l puudub praegu rikkalik sisseehitatud analüütika võrgu telemeetria anomaaliate ja ohtude avastamiseks. See tähendab, et järgides eeltoodud elutsüklit, peate ise kirjeldama rikkumismudeleid ja siis neid juba reaalses süsteemis kasutama (sisseehitatud mudeleid seal ei ole).

Loomulikult on olemas ka keerukamaid laiendeid ELK-le, milles on juba sünkroniseeritud mõned võrgu telemeetrias esinevate anomaaliate tuvastamise mudelid, kuid sellised laiendid maksavad raha ja siin on küsimus, kas tasub häda — luua sarnane mudel ise, osta selle rakendus oma jälgimisvahendi jaoks või osta valmis lahendus, mis kuulub võrgu liikluse analüüsi klassi.

Ma ei taha üldse arutellu sukelduda, kas on mõistlik raha kulutada ja osta valmis lahendus võrgu telemeetria anomaaliate ja ohtude jälgimiseks (näiteks Cisco Stealthwatch) või lahendada probleem ise, kohandades iga uue ohu jaoks SiLK, ELK või nfdumpi või OSU Flow Tools (mõtlen viimasena nimetatud kahele). rääkinud Eelmine kord? Igaühel on oma valik ja igaühel on oma põhjused valida üks kahest variandist. Ma tahtsin lihtsalt näidata, et võrgu telemeetria on väga oluline tööriist oma sisemiste infrastruktuuride küberturvalisuse tagamisel ja selle ignoreerimine ei ole soovitatav, et mitte sattuda ettevõtete nimekirja, kelle nimesid mainitakse meedias koos epiteetidega "ründe all", "küberhügieeni eirav", "turvalisusega mittearvestav" ja "klientide andmete kaitsele mitte mõtlev".

Kokkuvõtteks tahaksin välja tuua peamised nõuanded, mida tasub järgida oma sisevõrgu küberturbe jälgimise ülesehitamisel:

Ärge piirduge vaid perimeetriga! Kasutage (ja valige) võrgu infrastruktuuri mitte ainult liikluse edastamiseks punktist A punkti B, vaid ka küberturbe probleemide lahendamiseks.
Uurige olemasolevaid infosüsteemide jälgimise mehhanisme oma võrgutarvikutes ja rakendage neid.
Sisemiseks jälgimiseks eelistage telemeetriat — see võimaldab tuvastada kuni 80-90% kõikidest võrgu infosüsteemide sündmustest, tehes samal ajal seda, mida on võimatu saavutada võrgupakettide jäädvustamisega ja säästes ruumi kõikide infosüsteemide sündmuste jaoks.
Voogude jälgimiseks kasutage Netflow v9 või IPFIX – need annavad rohkem teavet turvalisuse kontekstis ja võimaldavad jälgida mitte ainult IPv4, vaid ka IPv6, MPLS jne.
Kasutage mitte-sammustatud voo protokolli – see annab rohkem teavet ohtude tuvastamiseks. Näiteks Netflow või IPFIX.
Kontrollige oma võrgu seadmete koormust – võib juhtuda, et nad ei suuda ka vooprotokolli töödelda. Siis mõelge virtuaalsete sensorite või Netflow Generatsiooni Aplikaatori rakendamisele.
Rakendage kontrolli peamiselt juurdepääsu tasemel – see annab võimaluse näha 100% kogu liiklusest.
Kui teil pole valikut ja kasutate Venemaa võrguteenuseid, valige seade, mis toetab voogude protokolle või millel on SPAN/RSPAN-portide tugi.
Kombineerige sissetungimise ja rünnaku avastamise/ennetamise süsteemid piiril koos voogude analüüsi süsteemidega sisevõrgus (sealhulgas pilvekeskkondades).

Mis puudutab viimast soovitust, siis sooviksin tuua näite, mida olen juba varem jaganud. Näete, et kui varem rajas Cisco küberturbe teenus oma jälgimissüsteemi valdavalt sissetungimise avastamise ja allkirjade meetodite baasil, siis nüüd katab nende osakaal ainult 20% juhtumitest. Veel 20% kuulub voogude analüüsi süsteemidele, mis tõestab, et need lahendused ei ole liig, vaid tõeline tööriist tänapäeva ettevõtte küberturbe teenuste tegevuses. Eriti arvestades, et teil on nende rakendamiseks kõige olulisem — võrgustruktuur, mille investeeringuid on võimalik täiendavalt kaitsta, määrates võrgule ka küberturbe jälgimise funktsioonid.

Ma ei käsitlenud spetsiaalselt võrguvoogudes avastatud anomaaliate või ohtude reageerimise teemat, kuid usun, et on selge, et jälgimine ei tohiks piirduda ainult ohu tuvastamisega. Sellele peaks järgima reageerimine, eelistatult automaatset või automatiseeritud režiimi. Kuid see on juba eraldi teema.