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

Kui räägitakse siseettevõtte või ametivõimu võrgu turvamonitorimisest, seostavad paljud seda teabelekke kontrolli ja DLP-lahenduste rakendamisega. Aga kui üritada küsimust täpsustada ja küsida, kuidas te avastate rünnakuid sisevõrgus, siis on vastuseks reeglina ründeavastussüsteemide (intrusion detection systems, IDS) mainimine. Ja see, mis oli ainus variant umbes 10-20 aastat tagasi, on täna muutumas anahrooniliseks. On olemas tõhusam ja mõnes osas ainus võimalik variant sisevõrgu jälgimiseks — kasutada flow-protokolle, mis algselt olid mõeldud võrguprobleemide leidmiseks (troubleshooting), kuid on aja jooksul muutunud väga huvitavaks turvaks. Räägime selles artiklis, millised flow-protokollid on olemas ja millised neist aitavad paremini avastada võrgurünnakuid, kus on parim koht flow-monitooringu rakendamiseks, millele tähelepanu pöörata sellise skeemi juurutamisel ja isegi, kuidas seda kodumaisel varustusel „üles tõsta“.

Ma ei pea vajalikuks peatuda küsimusel „Miks on siseinfrastruktuuri turvamonitorimine vajalik?“ Vastus sellele on nagu ka nii selge. Kuid kui soovite veelkord veenduda, et tänapäeval on see vältimatu, vaadake väike video 17 viisi kohta, kuidas siseneda ettevõtte võrku, mida kaitseb tulemüür. Seetõttu võime öelda, et mõistame, et sisemine jälgimine on vajalik ning nüüd jääb vaid mõista, kuidas seda korraldada.

Kiineldaks kolme peamist andmeallikat võrgu tasandi infrastruktuuri jälgimiseks:

„toores“ liiklus, mille me salvestame ja suuname analüüsidesse mingitesse analüüsisüsteemidesse,
sündmused võrgu seadmetest, mille kaudu liiklus läbib,
teave liikluse kohta, saadud ühe flow-protokolli kaudu.

Toores liikluse jäädvustamine on turvateenuste seas kõige populaarsem variant, kuna see ilmus ajalooliselt kõige esimesena. Tavalised rünnakute tuvastamise võrgusüsteemid (esimene kommertssüsteem rünnakute tuvastamiseks oli NetRanger ettevõttelt Wheel Group, mille Cisco ostis 1998. aastal) tegelesid just pakettide (ja hiljem seansside) jäädvustamisega, milles otsiti teatud allkirju ("otsustavad reeglid" FSTEK-i terminoloogias), mis andsid märku rünnakutest. Loomulikult saab toore liiklust analüüsida mitte ainult IDS-i abil, vaid ka teiste vahendite, nagu Wireshark, tcpdump või NBAR2 funktsionaalsus Cisco IOS, abil, kuid neil puudub tavaliselt teadmistebaas, mis eristab infoturbe vahendit tavalistest IT-tööriistadest.

Nii et, rünnakute tuvastamissüsteemid. Kõige vanem ja kõige populaarsem meetod võrgurünnakute tuvastamiseks, mis täidab oma ülesannet perimeetril (olgu see siis ettevõtte, andmekeskuse, segmendi jne), kuid jääb hätta kaasaegsete lülitite ja programmiga määratletud võrkude puhul. Kui võrgu ehitus põhineb tavalistel lülititel, muutub rünnakute tuvastamise sensorite infrastruktuur liiga suureks - peate igas ühenduses, mida soovite jälgida, paigaldama ühe sensori. Igatelt tootjatelt, loomulikult, võetakse rõõmuga vastu, et müüa teile sadu ja tuhandeid sensoreid, kuid arvan, et teie eelarve ei kesta selliseid kulusid. Võin öelda, et isegi Cisco (ja me oleme NGIPS-i arendajad), ei suutnud me seda teha, kuigi hind ei tohiks olla meie ees. Lisaks tekib küsimus, kuidas sellises variandis sensorit ühendada? Katkestuses? Kui sensor ise rikki läheb? Kas sensor peab olema bypass-mooduliga varustatud? Kas kasutada jagureid (tap)? Kõik see tõstab lahenduse hinda ja muudab selle mis tahes suurusega ettevõttele ületamatuks.

Saate proovida "riputada" anduri SPAN/RSPAN/ERSPAN-porti ja suunata selle kaudu liiklust vajalike lülitite portidelt. See variant leevendab osaliselt probleemi, millest räägiti eelnevas lõigus, kuid tekitab teise — SPAN-port ei suuda vastu võtta kogu liiklust, mis sinna suunatakse — tal ei piisa läbilaskevõimest. Peab millelegi loobuma. Võite kas jätta osa sõlmedest jälgimata (enne tuleb teha prioriseerimine) või suunata mitte kogu liiklust sõlmest, vaid ainult kindlat tüüpi. Igal juhul võime teatud rünnakud lihtsalt vahele jätta. Lisaks võib SPAN-port olla hõivatud muude vajaduste jaoks. Seega peame üle vaatama olemasoleva võrgu topoloogia ja võib-olla tegema sellele muudatusi, et maksimaalselt katab teie võrgus olemasolevate andurite arvu (ja kokku leppima IT-ga).

Ent kui teie võrk kasutab asümmeetrilisi marsruute? Ent kui teil on rakendatud või kavatsetakse rakendada SDN-i? Ent kui peate jälgima virtualiseeritud masinaid või konteinerite liiklust, mis ei jõua füüsilise lülitini? Need küsimused ei meeldi traditsiooniliste IDS-i tootjatele, sest nad ei tea, kuidas neile vastata. Võib-olla üritavad nad suunata teid uskumisele, et kõik need moodsad tehnoloogiad on hype ja et neid ei ole vaja. Võib-olla räägivad nad vajalikkusest alustada väikeselt. Võib-olla ütlevad nad, et peate paigaldama võimsa Purustaja võrgu keskmesse ja suunama kogu liikluse sinna kaudu tasakaalustajate abil. Milline variant iganes teile ette pannakse, peate ise selgelt aru saama, kui sobiv see teile on. Ja ainult seejärel võtma vastu otsuse, kuidas läheneda võrgu infrastruktuuri turvamonitorimisele. Tagasi jääkide püüdmise juurde — tahan öelda, et see meetod jääb endiselt väga populaarseks ja oluliseks, kuid selle peamine eesmärk on kontrollida piire; piire teie organisatsiooni ja interneti vahel, piire andmekeskuse ja ülejäänud võrgu vahel, piire automaatikaseadmete ja ettevõtte segmendi vahel. Nendes kohtades on klassikalised IDS/IPS endiselt õigustatud ja teevad oma ülesandeid hästi.

Liigume teise variandi juurde. Võrgu seadmetelt saadud sündmuste analüüsi saab samuti kasutada rünnakute avastamise eesmärkidel, kuid mitte peamise mehhanismina, kuna see võimaldab tuvastada vaid väikest klassi sissetungi. Lisaks on sellele iseloomulik teatav reaktiivsus — rünnak peab esmalt toimuma, seejärel peab see olema fikseeritud võrgu seadmega, mis mingil viisil signaalib probleemist IBe. Selliseid meetodeid on mitmeid. See võib olla syslog, RMON või SNMP. Viimased kaks protokolli võrgu jälgimiseks kontekstis IBe kasutatakse ainult siis, kui meil on vaja tuvastada DoS-rünnak võrgu varustusele, kuna RMONi ja SNMP abil on võimalik näiteks jälgida seadme keskprotsessori või selle liideste koormust. See on üks “odavamaid” (syslog või SNMP on kõigil), kuid ka kõige ebaefektiivsem viiside seas IBe sisemise infrastruktuuri jälgimiseks — paljud rünnakud jäävad sellest lihtsalt varjatuks. Loomulikult ei tohi neist kõrvale hiilida ja sama syslogi analüüs aitab teil õigeaegselt tuvastada seadme konfiguratsiooni muutusi või selle kompromiteerimist, kuid rünnakute avastamine kogu võrku selle meetodiga ei sobi hästi.

Kolmas variant on liikluse teabe analüüs, mis läbib seadmeid, mis toetavad ühte mitmest voolu-protokollist. Antud juhul, olenemata protokollist, koosneb voolu töötlemise infrastruktuur tingimata kolmest komponendist:

Voolu genereerimine või eksport. See roll lasub tavaliselt ruuteril, lülitil või muul võrgu seadmel, mis, laskudes läbi võrguliiklusest, võimaldab eristada võtmeparameetreid, mis edastatakse seejärel kogumoodulile. Näiteks Cisco toetab Netflow protokolli mitte ainult ruuterites ja lülitites, sealhulgas virtuaalsetes ja tööstuslikes seadmetes, vaid ka traadita kontrollerites, tulemüürites ja isegi serverites.
Voolu kogumine. Arvestades, et kaasaegses võrgus on tavaliselt rohkem kui üks võrgu seade, tekib voolu kogumise ja konsolideerimise ülesanne, mille lahendab nn kollektsioon, mis töötleb saadud vooge ja edastab neid seejärel analüüsimiseks.
Flow analüüs. Analüsaator võtab enda peale peamise intellektuaalse ülesande ja rakendab voogudele erinevaid algoritme, tehes üht või teist järeldust. Näiteks IT-funktsiooni raames võib selline analüsaator paljastada võrgu kitsaskohti või analüüsida liikluskoormuse profiili edasiseks võrgu optimeerimiseks. Infotehnoloogia jaoks võib analüsaator tuvastada andmelekkeid, kahjulike koodide levikut või DoS-rünnakuid.

Ei tasu arvata, et see kolmeastmeline arhitektuur on liiga keeruline — kõik muud variandid (välja arvatud võib-olla võrgu jälgimisseadmed, mis töötavad SNMP ja RMON-i alusel) toimivad samuti selle järgi. Meil on andme genereerimise seade analüüsi jaoks, milleks on võrguseade või eraldiseisev sensor. Meil on häiresignaale kogumise süsteem ning kogu jälgimisinfrastruktuuri juhtimise süsteem. Viimased kaks komponenti võivad olla ühendatud ühte sõlme, kuid enam-vähem suurtes võrkedes on need tavaliselt hajutatud vähemalt kahe seadme vahel, et tagada skaleeritavus ja usaldusväärsus.

Teistsugune kui pakettide analüüs, mis põhineb iga paketi pealkirja ja kehas oleva teabe uurimisel ning neist koosnevate sessioonide analüüsil, toetub voogude analüüs võrgu liikluse metateabe kogumisele. Millal, kui palju, kust ja kuhu, kuidas... need on küsimused, millele vastab võrgu telemeetriate analüüs erinevate voogude protokollide abil. Alguses kasutati neid statistika analüüsimiseks ja IT-probleemide leidmiseks võrgus, kuid hiljem, analüütiliste mehhanismide arendamisega, on neid võimalik rakendada ka sama telemeetriaga ja turvakaalutlusteks. Siinkohal tasub veel kord märkida, et voogude analüüs ei asenda ega tühista pakettide jäädvustamist. Igal neist meetoditest on oma rakendusvaldkond. 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 tarkvara määratletud paradigma alusel või staatiliste reeglite alusel), mida rünnak ei suuda vältida. Klassikalise IDS sensori võib rünnak mööda pääseda, kuid voogu toetav võrgu seade ei saa. See on selle meetodi eelis.

Teiselt poolt, kui vajate tõendusmaterjali õiguskaitseasutustele või enda uurimisgrupile, ei saa te ilma pakettide püüdmiseta hakkama — võrgu telemeetrianäidud ei ole liikluskoopia, mida saab kasutada tõendite kogumiseks; neid on vaja operatiivseks avastamiseks ja otsuste tegemiseks IT-valdkonnas. Samas, kasutades telemeetriat, saate "salvestada" mitte kogu võrgu liiklust (kui nii on, tegeleb Cisco ja andmekeskustega :-), vaid ainult seda, mis osaleb rünnakus. Telemeetria analüüsivahendid täiustavad traditsioonilisi pakettide püüdmismehhanisme, võimaldades meeskonnal valida sihitud püüdmist ja salvestamist. Vastasel juhul peate omama tohutut salvestusstruktuuri.

Kujutage ette võrku, mis töötab kiirusel 250 Mbit/s. Kui soovite salvestada kogu selle mahu, vajate ühte sekundit andmete edastamiseks 31 MB salvestust, 1,8 GB ühe minuti jaoks, 108 GB ühe tunni jaoks ja 2,6 TB ühe päeva jaoks. 10 Gbit/s läbilaskevõimega võrgu päevaandmete salvestamiseks vajate 108 TB salvestust. Ja mõned reguleerivad asutused nõuavad andmete säilitamist aastate viisi... Nõudmisel salvestamine, mida aitab realiseerida voogude analüüs, aitab neid väärtusi järsult vähendada. Üksikasjalikult rääkides, võrgu telemeetria salvestatavate andmete ja täieliku andmeosade salvestamise suhe on umbes 1:500. Ülaltoodud väärtuste jaoks väljatoodud täieliku päevase liikluse dešifreerimise salvestamine oleks vastavalt 5 ja 216 GB (isegi tavalisele mälupulgale saab salvestada).

Kui toore võrgudünaamika analüüsimise meetodite puhul ei erine nende püüdmisviis peaaegu üldse tarnijate vahel, siis voogude analüüsi puhul on olukord teine. On olemas mitmeid voogude protokolle, millest on oluline teada erinevusi just turvaseisukohalt. Kõige populaarsem on protokoll Netflow, mille on välja töötanud ettevõte Cisco. Sellel protokollil on erinevad versioonid, mis varieeruvad oma võimaluste ja salvestatava liiklusinfo mahutavuse poolest. Praegune versioon on üheksas (Netflow v9), mille alusel on välja töötatud tööstusstandard Netflow v10, tuntud ka kui IPFIX. Tänapäeval toetab enamik võrgutarnijaid just Netflow või IPFIX oma seadmetes. Aga on ka mitmeid teisi voogude protokollide variante — sFlow, jFlow, cFlow, rFlow, NetStream jne., millest sFlow on kõige populaarsem. Just tema toetust leidub kõige sagedamini kodumaiste võrguseadmete tootjate seas, kuna selle rakendamine on lihtne. Millised on peamised erinevused Netflow vahel, mis de facto on standardiks saanud, ja sFlow vahel? Peamised erinevused on mitmed. Esiteks, Netflow'il on kohandatavad kasutaja väljad, erinevalt sFlow fikseeritud väljadest. Teiseks, ja see on meie kontekstis kõige olulisem, kogub sFlow nn proovitud telemeetria; erinevalt Netflow ja IPFIX mitteproovitud telemeetriast. Mis on nende vahe?

Kujutage ette, et otsustasite tutvuda raamatu “Security Operations Center: Building, Operating, and Maintaining your SOC” minu kolleegide — Gary MacIntyre, Joseph Munizza ja Nadem Alfardan — teosega (linki klõpsates saate alla laadida raamatu osa). Teil on kolm võimalust seatud eesmärgi saavutamiseks — lugeda raamatut tervikuna, sirvida seda, peatudes iga 10. või 20. lehe juures, või proovida leida öeldud põhimõtete kokkuvõtte mõnest blogist või teenusest nagu SmartReading. Nii et mitteproovitud telemeetria on iga „lehe” lugemine võrgu liiklusest, st andmete analüüs iga paketi kohta. Proovitud telemeetria on liikluse valikuline uurimine lootuses, et valitud proovides on see, mis teil vaja on. Sõltuvalt kanali kiirusest annab proovitud telemeetria analüüsi jaoks iga 64., 200., 500., 1000., 2000. või isegi 10000. paketi.

Informatsiooni turbe jälgimise kontekstis tähendab see, et proovitellimus on hästi sobiv DDoS-rünnakute, skaneerimise, pahavara levitamise tuvastamiseks, kuid võib mööda lasta aatom- või mitme paketi rünnakutest, mis ei jõudnud analüüsi jaoks saadetud proovidesse. Proovitellimustel puuduvad sellised puudused ja nende abiga on tuvastatavate rünnakute spekter palju laiem. Siin on väike loetelu sündmustest, mida saab tuvastada võrgu telemeetria analüüsivahendite abil.

Muidugi ei luba mingisugune avatud lähtekoodiga Netflow analüsaator seda, kuna tema peamine ülesanne on koguda telemeetriat ja viia läbi selle põhianalüüs IT seisukohalt. Turbeohte leidmiseks flow baasil on vajalik varustada analüsaator erinevate mootorite ja algoritmidega, mis suudavad standardsete või kohandatud Netflow väljade põhjal tuvastada küberturbeprobleeme, rikastada standardandmeid väliste andmetega erinevatest Threat Intelligence allikatest jne.

Seega, kui teil on valik, siis valige Netflow või IPFIX. Kuid isegi kui teie seadmed töötavad ainult sFlow'ga, nagu kodumaiste tootjate puhul, saate isegi sel juhul turvalisuse kontekstis sellest kasu.

Suvel 2019. aastal tegin analüüsi võimaluste kohta, mis on Venemaa võrgu riistvara tootjatel, ja kõik nad, välja arvatud NSG, Poligon ja Kraftway, teatasid sFlow toe olemasolust (vähemalt Zelaks, Natex, Eltex, QTech, Rusteletech).

Järgmine küsimus, mis teie ees tõuseb, on see, kus rakendada flow-tugede toetust turvalisuse eesmärkidel? Tegelikult ei ole küsimus täiesti korrektne. Kaasaegse riistvara puhul on flow-protokollide tugi peaaegu alati olemas. Seetõttu ma reformuleeriksin küsimuse teisiti — kus on kõige tõhusam koguda telemeetriat turvalisuse vaatenurgast? Vastus on piisavalt ilmselge — juurdepääsu tasandil, kus näete 100% kogu liiklust, kus teil on üksikasjalik teave hostide kohta (MAC, VLAN, liidese ID), kus te saate jälgida isegi P2P-liiklust hostide vahel, mis on kriitiline skaneerimise ja kahjuliku koodi leviku tuvastamise jaoks. Südametasandil võite osa liiklusest lihtsalt mitte näha, ja perimeetri tasandil näete hästi, kui veerandi kogu teie võrguliiklust. Kuid kui mingil põhjusel on teie võrgus tekkimas kõrvaliseadmed, mis võimaldavad ründajatel „sisse ja välja“ liikuda, mööda minnes perimeetrist, siis ei too telemeetriaanalüüs sellest teile mitte midagi. Seetõttu on maksimaalse katvuse tagamiseks soovitatav alustada telemeetriakogumist just juurdepääsu tasandil. Samas on oluline märkida, et isegi kui räägime virtualiseerimisest või konteineritest, siis kaasaegsetes virtuaalsetes lülitites esineb samuti sageli flow-toe, mis võimaldab seal liiklust kontrollida.

Aga kuna tõstsin teema esile, tuleb vastata küsimusele, mis siis, kui riistvara, olgu see füüsiline või virtuaalne, ei toeta flow-protokolle? Või selle aktiveerimine on keelatud (näiteks tööstussektorites usaldusväärsuse tagamiseks)? Või selle aktiveerimine põhjustab suure koormuse keskseks protsessoriks (selline juhtub vananenud varustuses)? Selle ülesande lahendamiseks on olemas spetsialiseeritud virtuaalsed sensorid (flow sensor), mis on sisuliselt tavalised jaoturid, mis lasevad läbi liikluse ja edastavad selle flow-vormingus kogumoodulisse. Tõsi, sel juhul saame meil kogu hulga probleeme, millest me rääkisime ülal pakettide püügivahendite osas. Ehk tuleb mõista mitte ainult voogude analüüsi tehnoloogia eeliseid, vaid ka selle piiranguid.

Siin on veel üks oluline aspekt, mida meeles pidada voogude analüüsimise tööriistade kohta. Kui tavapäraste turvaseisundite genereerimise tööriistade puhul rakendame EPS (event per second, sündmused sekundis) mõõdikut, siis telemeetriat analüüsimisel see mõõdik ei kehti; see asendatakse FPS-iga (flow per second, voog sekundis). Nagu EPS-i puhul, ei saa me seda eelnevalt arvutada, kuid saame ligikaudu hinnata voogude arvu, mida erinev seade genereerib sõltuvalt oma ülesandest. Internetis on saadaval tabelid ligikaudsete väärtustega erinevat tüüpi ettevõtte seadmete kohta, mis aitab teil hinnata, kui palju litsentse vajate analüüsitööriistade jaoks ja milline saab olema nende arhitektuur. Probleem on selles, et IDS-anduris on teatud läbilaskevõime, mida ta „tõmbab“, ja voogude kollektsionääril on oma piirangud, mida tuleb mõista. Seetõttu on suurtes, territoriaalselt jaotatud võrkudes tavaliselt mitu kollektsionääri. Kui ma kirjeldasin, kuidas Cisco võrku jälgib, nimetasime meie kollektsionääride arvu — neid on 21. Ja see on võrk, mis on hajutatud viiele mandrile ja milles on umbes pool miljonit aktiivset seadet).

Netflow jälgimissüsteemina kasutame meie enda lahendust Cisco Stealthwatch, mis on spetsiaalselt suunatud turbeprobleemide lahendamisele. Sellel on palju sisseehitatud mootoreid, mis avastavad ebanormaalset, kahtlast ja selgelt kahjulikku tegevust, võimaldades tuvastada laia valiku erinevaid ohte — alates krüptoraha kaevandamisest kuni teabe lekke, kahjulike koodide levitamise ja pettusteni. Nagu enamik Stealthwatchi voogude analüsaatoritest, on ka see üles ehitatud kolmekihilisele skeemile (generaator — koguja — analüsaator), kuid sellega on kaasas mitmed huvitavad omadused, mis on olulised käsitletava materjali kontekstis. Esiteks, see integreerub pakettide hõivamise lahendustega (näiteks Cisco Security Packet Analyzer), mis võimaldab jäädvustada valitud võrgu sessioone edasise süvaanalüüsi ja uurimise jaoks. Teiseks, turbelahenduste laienemise nimel oleme välja töötanud spetsiaalse protokolli nvzFlow, mis võimaldab

Jah, on selge, et rääkides Netflow analüüsimise süsteemidest turvalisuse vaatenurgast, ei piirdu turg ainult Cisco lahendusega. Saate kasutada nii kommertslike kui ka tasuta või tingimuslikult tasuta lahendusi. On üsna kummaline, kui ma Cisco blogis toodan näiteid konkurentide lahendustest, seega ütlen paar sõna sellest, kuidas võrgu telemeetria võib olla analüüsitud kahe populaarse, sarnase nimega, kuid siiski erineva tööriista — SiLK ja ELK — abil.

SiLK — on tööriistade komplekt (System for Internet-Level Knowledge), mis on loodud liikluse analüüsimiseks USA CERT/CC poolt. Artikli kontekstis toetab see Netflow’d (5. ja 9. versioon, kõige populaarsemad), IPFIX ja sFlow. Erinevate utiliitide (rwfilter, rwcount, rwflowpack jms) abil võimaldab see teostada erinevaid toiminguid võrgutelemeetria üle, eesmärgiga tuvastada selles volitamata tegevuse märke. Tuleb siiski märkida paar olulist punkti. SiLK on käsurea tööriist ja operatiivse analüüsi tegemine eeldab, et sisestate käske näiteks (ICMP-paketid, mille suurus on üle 200 bait):

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

ei ole eriti mugav. Saate kasutada graafilist liidest iSiLK, kuid see ei hõlbusta teie elu, täites vaid visualiseerimise funktsiooni, mitte analüütiku asendamist. See on teine punkt. Erinevalt kommertslahendustest, mille sisse on ehitatud tugev analüüsibaas, anomaaliate tuvastamise algoritmid ja vastavad töövood jne, peate SiLK-i kasutades kõik need sammud ise läbi viima, mis nõuab teilt veidi erinevaid pädevusi võrreldes juba valmis tööriistade kasutamisega. See ei ole mitte hea ega halb — see on peaaegu iga tasuta tööriista omadus, mis eeldab, et te teate, mida teha, ning see aitab teid ainult selles. (Kommertsinstrumendid ei sõltu nii palju kasutajate pädevustest, kuigi nad eeldavad, et analüütikud mõistavad vähemalt võrguraportite ja jälgimise põhialuseid.) Aga naaseme SiLK-i juurde. Analüütiku töötsükkel SiLK-iga näeb välja järgmine:

Hüpoteesi sõnastamine. Me peame mõistma, mida me võrgutelemeetriast otsime, teadma unikaalseid atribuute, mille põhjal tuvastame erinevad anomaaliad või ohud.
Mudeli loomine. Hüpoteesi sõnastamisel programmeerime selle Python’i, shell’i või muude tööriistade abil, mis ei kuulu SiLK-i.
Testimine. Jõuab kätte aeg meie hüpoteesi õigsuse kontrollimiseks, mis kinnitatakse või lükatakse tagasi SiLK-i utiliitide abil, mis algavad ‘rw’, ‘set’, ‘bag’.
Reaalsete andmete analüüs. SiLK-i tööstuslikus kasutuses aitab meil tuvastada midagi ning analüütik peab vastama küsimustele nagu "Kas me leidsime selle, mida eeldasime?", "Kas see vastab meie hüpoteesile?", "Kuidas vähendada valehäirete arvu?", "Kuidas parandada tuvastamise taset?" jne.
Parendamine. Lõppfaasis täiustame eelnevalt tehtut — loome malle, parendame ja optimeerime koodi, sõnastame ja täpsustame hüpoteesi jne.

See tsükkel rakendub ka Cisco Stealthwatchile, kus viies etapp automatiseeritakse maksimaalselt, vähendades analüütiku vigu ning suurendades intsidentide tuvastamise operatiivsust. Näiteks SiLK-is saate võrgustiku statistikat rikastada pahatahtlike IP-de väliste andmetega enda kirjutatud skriptide abil, kuid Cisco Stealthwatchis on see sisseehitatud funktsioon, mis hoiatab teid kohe, kui võrguliiklus sisaldab musta nimekirja kuuluvaid IP-aadresse.

Kui liikuda kõrgemale voogude analüüsi tarkvara "tasude" püramiidis, siis täiesti tasuta SiLK-i kõrval on tinglikult tasuta ELK, mis koosneb kolmest peamisest komponendist — Elasticsearch (andmete indekseerimine, otsimine ja analüüs), Logstash (andmete sisend/väljund) ja Kibana (visualiseerimine). Erinevalt SiLK-ist, kus tuleb kõik ise kirjutada, on ELK-il juba palju valmis raamatukogusid/moduule (mõned tasulised, mõned tasuta), mis automatiseerivad võrgutelemtrite analüüsi. Näiteks Logstashis olev GeoIP filter võimaldab siduda jälgitavaid IP-aadresse nende geograafilise asukohaga (Stealthwatchil on see sisseehitatud funktsioon).

ELK-il on ka üsna suur kogukond, kes kirjutab puuduvaid komponente selle jälgimise lahenduse jaoks. Näiteks võite kasutada Netflow, IPFIX ja sFlow töötlemiseks moodulit elastiflow, kui Logstash Netflow moodul, mis toetab ainult Netflow, ei rahulda teid.

ELK-l, mis pakub rohkem operatiivsust voogude kogumisel ja otsimisel, puudub praegu sisseehitatud rikkalik analüütika anomaaliate ja ohtude tuvastamiseks võrgutelemtrites. See tähendab, et järgides ülalkirjeldatud elu tsüklit, peate ise kirjeldama rikkumise mudeleid ja seejärel neid rakendama aktiivsüsteemis (seal ei ole sisseehitatud mudeleid).

Muidugi on olemas ka keerukamaid laiendusi ELK jaoks, kus on juba sisse ehitatud mõned mudelid võrgu telemeetria anomalioone tuvastamiseks, kuid sellised laiendused maksavad raha ja siin on küsimus, kas tasub see vaeva — kirjutada samalaadne mudel ise, osta selle teostus oma jälgimisvahendile või osta valmis lahendus, mis kuulub võrgu liikluse analüüsi klassi.

Ma ei taha üldse arutellu laskuda, et kas on parem raha investeerida ja osta valmis lahendus võrgu telemeetria anomalioonte ja ohtude jälgimiseks (näiteks Cisco Stealthwatch) või üritada ise selgeks saada ja arendada samad SiLK, ELK või nfdump või OSU Flow Tools (ma räägin kahest viimastest, mida mainisin eelmisel korral). sellest, Igaüks valib endale sobiva variandi ja igaühel on omad motiivid, miks valida kumbki variant. Ma tahtsin lihtsalt näidata, et võrgu telemeetria on väga oluline tööriist, et tagada oma siseinfrastruktuuri võrgu turvalisus, ja sellest ei tasu mööda vaadata, et mitte liituda ettevõtete nimekirjaga, kelle nimi kajab meedias koos omadustega nagu „ründetud“, „julgeoleku nõudeid eiranud“, „turvalisusele ja klientide andmete kaitsele mitte mõtleva”.

Kokkuvõtteks tahaksin loetleda peamised soovitused, mida järgida oma siseinfrastruktuuri julgeoleku jälgimise ülesehitamisel:

Ärge piirduge ainult perimeetriga! Kasutage (ja valige) võrguinfrastruktuuri mitte ainult liikluse edastamiseks punktist A punkti B, vaid ka küberjulgeoleku küsimuste lahendamiseks.
Uurige olemasolevaid IPS-julgeoleku jälgimise mehhanisme oma võrgu seadmetes ja rakendage neid.
Sisejälgimiseks eelistage telemeetria analüüsi — see võimaldab avastada kuni 80–90% kõikidest võrgu IPS-juhudest, tehes seda, mis ei ole võimalik võrgu pakettide püüdmisel, ning säästes IPS-sündmuste salvestamisele ruumi.
Liiklusvoogude jälgimiseks kasutage Netflow v9 või IPFIX — need pakuvad rohkem teavet turvalisuse kontekstis ja võimaldavad jälgida mitte ainult IPv4, vaid ka IPv6, MPLS jne.
Kasutage mitte-sämpleeritud voogude protokolli — see annab rohkem teavet ohtude avastamiseks. Näiteks Netflow või IPFIX.
Kontrollige oma võrguseadmete koormust – võib-olla ei suuda need täiendavat flow-protokolli töödelda. Siis mõelge virtuaalsete sensorite või Netflow Generation Appliance'i kasutusele.
Rakendage kontrolli esmalt juurdepääsu tasandil – see annab teile võimaluse näha 100% kogu liiklust.
Kui teil pole valikut ja kasutate Venemaa võrguseadmeid, valige need, mis toetavad flow-protokolle või omavad SPAN/RSPAN porte.
Kombineerige sissetungi-/rünnakute avastamise süsteeme äärel ja voogude analüüsi süsteeme sisevõrgus (sealhulgas ka pilves).

Mis puutub viimasesse nõuandesse, siis tahaksin tuua näite, mida olen juba varem maininud. Näete, et kui varem rajas Cisco kyberjulgeoleku teenistus oma monitorimissüsteemi peamiselt sissetungi avastamise ja allkirjameetodite põhjal, siis praegu moodustavad need vaid 20% juhtumitest. Veel 20% kuulub voogude analüüsisüsteemidele, mis näitab, et need lahendused ei ole luksus, vaid reaalsed tööriistad kaasaegse ettevõtte turvameetmete tegevuses. Eriti kuna teil on nende rakendamiseks olemas kõige olulisem – võrguinfrastruktuur, mille investeeringuid saab veelgi kaitsta, määrates võrgule ka küberjulgeoleku jälgimise funktsioonid.

Ma ei puudutanud tahtlikult nähtud ebanormaalsuste või ohtude reageerimise teemat, kuid arvan, et on selge, et jälgimine ei tohiks lõppeda ainult ohu tuvastamisega. Sellele peaks järgima reageerimine ja soovitatavalt automaatne või automatiseeritud režiim. Kuid see on juba eraldi teema.