Mis puutub ettevõtte või osakondade sisevõrgu turvalisuse jälgimisse, siis paljud seostavad seda infolekete kontrolli ja DLP-lahenduste juurutamisega. Ja kui proovite küsimust täpsustada ja küsida, kuidas tuvastate sisevõrgu rünnakuid, on vastuseks reeglina sissetungituvastussüsteemide (IDS) mainimine. Ja see, mis oli 10-20 aastat tagasi ainus võimalus, on tänapäeval muutumas anakronismiks. Sisevõrgu jälgimiseks on tõhusam ja kohati ka ainuvõimalik võimalus – vooprotokollide kasutamine, mis olid algselt mõeldud võrguprobleemide otsimiseks (tõrkeotsing), kuid aja jooksul muutusid väga huvitavaks turvatööriistaks. Räägime sellest, millised vooprotokollid on olemas ja millised on võrgurünnakute tuvastamisel paremad, kus on kõige parem rakendada vooseiret, mida otsida sellise skeemi juurutamisel ja isegi kuidas seda kõike kodumaistele seadmetele "tõsta" selle artikli ulatuses.
Ma ei peatu küsimusel “Miks on vaja sisemist infrastruktuuri turvaseiret?” Vastus näib olevat selge. Kuid kui soovite siiski veel kord veenduda, et täna ei saa te ilma selleta elada, lühike video sellest, kuidas pääseda tulemüüriga kaitstud ettevõtte võrku 17 viisil. Seetõttu eeldame, et mõistame, et siseseire on vajalik asi ja jääb üle vaid mõista, kuidas seda korraldada.
Tooksin esile kolm peamist andmeallikat infrastruktuuri jälgimiseks võrgu tasandil:
- "toores" liiklus, mille jäädvustame ja esitame analüüsimiseks teatud analüüsisüsteemidele,
- sündmused võrguseadmetest, mida liiklus läbib,
- ühe vooprotokolli kaudu saadud liiklusteave.
Toorliikluse jäädvustamine on turvaspetsialistide seas populaarseim variant, kuna see ilmus ajalooliselt ja oli esimene. Tavapärased võrgu sissetungimise tuvastamise süsteemid (kõige esimene kaubanduslik sissetungimise tuvastamise süsteem oli NetRanger Wheel Groupilt, mille Cisco ostis 1998. aastal) tegelesid täpselt pakettide (ja hilisemate seansside) hõivamisega, mille käigus otsiti teatud allkirju (“otsustavad reeglid” FSTEC terminoloogia), signalisatsioonirünnakud. Muidugi saab töötlemata liiklust analüüsida mitte ainult IDS-i, vaid ka muude tööriistade (nt Wireshark, tcpdum või Cisco IOS-i NBAR2 funktsionaalsus) abil, kuid tavaliselt puudub neil teadmistebaas, mis eristab infoturbetööriista tavalisest. IT-tööriist.
Niisiis, rünnakute tuvastamise süsteemid. Vanim ja populaarseim meetod võrgurünnete tuvastamiseks, mis teeb head tööd perimeetril (ükskõik mis - ettevõtte, andmekeskuse, segmendi jne), kuid ebaõnnestub tänapäevastes kommuteeritud ja tarkvaraga määratletud võrkudes. Tavaliste kommutaatorite baasil ehitatud võrgu puhul muutub ründetuvastusandurite infrastruktuur liiga suureks - igale ühendusele sõlmega, mille ründeid soovite jälgida, tuleb paigaldada andur. Muidugi müüb iga tootja teile hea meelega sadu ja tuhandeid andureid, kuid ma arvan, et teie eelarve ei suuda selliseid kulutusi toetada. Võin öelda, et isegi Ciscos (ja me oleme NGIPS-i arendajad) ei saanud me seda teha, kuigi tundub, et hinna küsimus on meie ees. Ma ei peaks taluma – see on meie enda otsus. Lisaks tekib küsimus, kuidas selles versioonis andurit ühendada? Vahesse? Mis siis, kui andur ise ebaõnnestub? Kas anduris on vaja möödaviigumoodulit? Kas kasutada splittereid (kraan)? Kõik see muudab lahenduse kallimaks ja muudab selle taskukohaseks mistahes suurusega ettevõttele.
Võite proovida anduri "riputada" SPAN/RSPAN/ERSPAN porti ja suunata liiklust vajalikest lülitiportidest sinna. See valik eemaldab osaliselt eelmises lõigus kirjeldatud probleemi, kuid tekitab veel ühe – SPAN-port ei saa vastu võtta absoluutselt kogu sellele saadetavat liiklust – sellel ei ole piisavalt ribalaiust. Peate midagi ohverdama. Kas jätke osa sõlmedest ilma jälgimiseta (siis peate need esmalt prioritiseerima) või saatke sõlmest mitte kogu liiklus, vaid ainult teatud tüüpi liiklus. Igal juhul võime mõne rünnaku vahele jätta. Lisaks saab SPAN-porti kasutada muudeks vajadusteks. Selle tulemusena peame üle vaatama olemasoleva võrgutopoloogia ja võimalusel seda kohandama, et teie võrk oleks teie andurite arvuga maksimaalselt kaetud (ja kooskõlastama selle IT-ga).
Mis siis, kui teie võrk kasutab asümmeetrilisi marsruute? Mida teha, kui olete SDN-i juurutanud või kavatsete seda rakendada? Mida teha, kui teil on vaja jälgida virtualiseeritud masinaid või konteinereid, mille liiklus füüsilise lülitini üldse ei jõua? Need on küsimused, mis traditsioonilistele IDS-i müüjatele ei meeldi, sest nad ei tea, kuidas neile vastata. Võib-olla veenavad nad teid, et kõik need moodsad tehnoloogiad on reklaamid ja te ei vaja seda. Võib-olla räägivad nad vajadusest alustada väikeselt. Või äkki nad ütlevad, et peate võrgu keskele panema võimsa viljapeksu ja suunama kogu liikluse tasakaalustajate abil sellele. Ükskõik, millist võimalust teile pakutakse, peate selgelt aru saama, kuidas see teile sobib. Ja alles pärast seda tehke otsus võrgu infrastruktuuri infoturbe jälgimise lähenemisviisi valimisel. Tulles tagasi pakettide püüdmise juurde, tahan öelda, et see meetod on jätkuvalt väga populaarne ja oluline, kuid selle peamine eesmärk on piirikontroll; piirid teie organisatsiooni ja Interneti vahel, piirid andmekeskuse ja ülejäänud võrgu vahel, piirid protsesside juhtimissüsteemi ja ettevõtte segmendi vahel. Nendes kohtades on klassikalistel IDS/IPS-idel endiselt õigus eksisteerida ja oma ülesannetega hästi toime tulla.
Liigume edasi teise variandi juurde. Võrguseadmetest tulevate sündmuste analüüsi saab kasutada ka rünnakute tuvastamiseks, kuid mitte peamise mehhanismina, kuna see võimaldab tuvastada vaid väikese klassi sissetungi. Lisaks on see omane teatud reaktiivsusele – esmalt peab rünnak toimuma, seejärel peab selle võrguseade salvestama, mis ühel või teisel viisil annab märku infoturbe probleemist. Selliseid viise on mitu. See võib olla syslog, RMON või SNMP. Kaht viimast võrguseire protokolli infoturbe kontekstis kasutatakse ainult siis, kui meil on vaja tuvastada DoS-rünnak võrguseadmetele endale, kuna RMON-i ja SNMP-d kasutades on võimalik näiteks jälgida seadme keskseadme koormust. protsessor või selle liidesed. See on üks "odavamaid" (kõigil on syslog või SNMP), kuid ka kõige ebaefektiivsem kõigist sisemise infrastruktuuri infoturbe jälgimise meetoditest - paljud rünnakud on selle eest lihtsalt peidetud. Loomulikult ei tohiks neid tähelepanuta jätta ja seesama syslogi analüüs aitab õigeaegselt tuvastada muudatusi seadme enda konfiguratsioonis, selle kompromissi, kuid see ei ole eriti sobiv kogu võrgu rünnakute tuvastamiseks.
Kolmas võimalus on analüüsida teavet liikluse kohta, mis läbib seadet, mis toetab ühte mitmest vooprotokollist. Sel juhul koosneb keermestamise infrastruktuur protokollist sõltumata tingimata kolmest komponendist:
- Voolu genereerimine või eksport. See roll määratakse tavaliselt ruuterile, kommutaatorile või muule võrguseadmele, mis võrguliiklust endast läbi juhtides võimaldab teil sealt välja võtta võtmeparameetrid, mis seejärel kogumismoodulisse edastatakse. Näiteks Cisco toetab Netflow protokolli mitte ainult ruuteritel ja kommutaatoritel, sealhulgas virtuaalsetel ja tööstuslikel, vaid ka juhtmeta kontrolleritel, tulemüüridel ja isegi serveritel.
- Kogumisvoog. Arvestades, et kaasaegses võrgus on tavaliselt rohkem kui üks võrguseade, tekib voogude kogumise ja koondamise probleem, mille lahendamiseks kasutatakse nn kollektoreid, mis töötlevad vastuvõetud vooge ja edastavad need seejärel analüüsiks.
- Voolu analüüs Analüsaator võtab enda peale peamise intellektuaalse ülesande ja, rakendades voogudele erinevaid algoritme, teeb teatud järeldused. Näiteks IT-funktsiooni osana saab selline analüsaator tuvastada võrgu kitsaskohti või analüüsida liikluskoormuse profiili võrgu edasiseks optimeerimiseks. Ja infoturbe huvides suudab selline analüsaator tuvastada andmelekkeid, pahatahtliku koodi levikut või DoS rünnakuid.
Ärge arvake, et see kolmetasandiline arhitektuur on liiga keeruline - kõik muud võimalused (välja arvatud võib-olla SNMP ja RMON-iga töötavad võrguseiresüsteemid) töötavad ka selle järgi. Meil on analüüsimiseks andmegeneraator, milleks võib olla võrguseade või iseseisev andur. Meil on häirete kogumise süsteem ja juhtimissüsteem kogu seireinfrastruktuuri jaoks. Viimaseid kahte komponenti saab kombineerida ühe sõlme sees, kuid enam-vähem suurtes võrkudes on need mastaapsuse ja töökindluse tagamiseks tavaliselt hajutatud vähemalt kahe seadme vahel.
Erinevalt pakettanalüüsist, mis põhineb iga paketi päise ja kehaandmete ning sellest koosnevate seansside uurimisel, põhineb vooanalüüs võrguliikluse metaandmete kogumisel. Millal, kui palju, kust ja kust, kuidas... sellistele küsimustele annab vastuseid erinevaid vooprotokolle kasutades võrgu telemeetria analüüs. Algselt kasutati neid statistika analüüsimiseks ja IT-probleemide leidmiseks võrgus, kuid siis, kui analüütilised mehhanismid arenesid, tekkis võimalus neid turvalisuse eesmärgil rakendada samale telemeetriale. Tasub veel kord märkida, et vooanalüüs ei asenda ega asenda pakettide püüdmist. Igal neist meetoditest on oma rakendusvaldkond. Kuid selle artikli kontekstis sobib sisemise infrastruktuuri jälgimiseks kõige paremini vooanalüüs. Teil on võrguseadmed (kas need töötavad tarkvaraga määratletud paradigmas või staatiliste reeglite järgi), millest rünnak ei saa mööda minna. See võib klassikalisest IDS-andurist mööda minna, kuid vooprotokolli toetav võrguseade mitte. See on selle meetodi eelis.
Teisest küljest, kui vajate tõendeid õiguskaitseorganitele või oma intsidentide uurimisrühmale, ei saa te ilma pakettide püüdmiseta hakkama – võrgu telemeetria ei ole liikluse koopia, mida saaks kasutada tõendite kogumiseks; see on vajalik infoturbe valdkonna kiireks tuvastamiseks ja otsuste tegemiseks. Teisest küljest ei saa telemeetriaanalüüsi kasutades “kirjutada” mitte kogu võrguliiklust (kui üldse, siis Cisco tegeleb andmekeskustega :-), vaid ainult seda, mis on seotud rünnakuga. Sellega seoses täiendavad telemeetriaanalüüsi tööriistad hästi traditsioonilisi pakettide püüdmise mehhanisme, andes käsud valikuliseks hõivamiseks ja salvestamiseks. Vastasel juhul peab teil olema kolossaalne salvestusinfrastruktuur.
Kujutagem ette võrku, mis töötab kiirusega 250 Mbit/sek. Kui soovite kogu selle mahu salvestada, vajate liikluse edastamiseks sekundiks 31 MB, üheks minutiks 1,8 GB, üheks tunniks 108 GB ja üheks päevaks 2,6 TB salvestusruumi. Igapäevaste andmete salvestamiseks võrgust, mille ribalaius on 10 Gbit/s, vajate 108 TB salvestusruumi. Kuid mõned regulaatorid nõuavad turvaandmete säilitamist aastaid... Nõudmisel salvestamine, mida vooanalüüs aitab teil rakendada, aitab neid väärtusi suurusjärkude võrra vähendada. Muide, kui me räägime salvestatud võrgu telemeetriaandmete mahu ja täieliku andmehõive suhtest, siis on see ligikaudu 1 kuni 500. Ülalpool toodud samade väärtuste puhul salvestatakse kogu igapäevase liikluse täielik ärakiri. on vastavalt 5 ja 216 GB (saate salvestada isegi tavalisele mälupulgale).
Kui võrgu toorandmete analüüsimise tööriistade puhul on nende hõivamise meetod hankijati peaaegu sama, siis vooanalüüsi puhul on olukord erinev. Vooluprotokollide jaoks on mitu võimalust, mille erinevusi peate turvalisuse kontekstis teadma. Kõige populaarsem on Cisco välja töötatud Netflow protokoll. Sellel protokollil on mitu versiooni, mis erinevad oma võimaluste ja salvestatud liiklusteabe hulga poolest. Praegune versioon on üheksas (Netflow v9), mille põhjal töötati välja tööstusstandard Netflow v10, tuntud ka kui IPFIX. Tänapäeval toetab enamik võrgumüüjaid oma seadmetes Netflow või IPFIX-i. Kuid vooprotokollide jaoks on mitmeid muid võimalusi - sFlow, jFlow, cFlow, rFlow, NetStream jne, millest sFlow on kõige populaarsem. Just seda tüüpi toetavad kodumaised võrguseadmete tootjad selle rakendamise lihtsuse tõttu. Millised on peamised erinevused Netflow, millest on saanud de facto standard, ja sFlow vahel? Tooksin esile mitu peamist. Esiteks on Netflow'l kasutaja kohandatavad väljad, mitte sFlow fikseeritud väljad. Ja teiseks, ja see on meie puhul kõige olulisem, kogub sFlow nn proovi telemeetriat; erinevalt Netflow ja IPFIX jaoks mõeldud valimiteta. Mis vahe neil on?
Kujutage ette, et otsustate lugeda raamatut "” minu kolleegidest - Gary McIntyre'ist, Joseph Munitzist ja Nadem Alfardanist (osa raamatust saate alla laadida lingilt). Eesmärgi saavutamiseks on teil kolm võimalust – lugeda terve raamat läbi, sirvida see läbi, peatuda igal 10. või 20. leheküljel või proovida leida ajaveebis või teenuses nagu SmartReading võtmemõisteid ümber jutustada. Seega loeb valimiteta telemeetria võrguliikluse iga "lehekülge", st analüüsib iga paketi metaandmeid. Valimiline telemeetria on liikluse selektiivne uuring lootuses, et valitud proovid sisaldavad seda, mida vajate. Sõltuvalt kanali kiirusest saadetakse näidistelemeetria analüüsimiseks iga 64., 200., 500., 1000., 2000. või isegi 10000. paketi järel.
Infoturbe monitooringu kontekstis tähendab see, et sämplitud telemeetria sobib hästi DDoS rünnakute tuvastamiseks, skannimiseks ja pahatahtliku koodi levitamiseks, kuid võib jääda märkamata aatomi- või mitmepaketilised rünnakud, mida analüüsiks saadetud proovis ei olnud. Disamplemata telemeetrial selliseid puudusi pole. Sellega on tuvastatud rünnakute hulk palju laiem. Siin on lühike loend sündmustest, mida saab võrgu telemeetria analüüsitööriistade abil tuvastada.
Muidugi ei võimalda mõni avatud lähtekoodiga Netflow analüsaator teil seda teha, kuna selle põhiülesanne on koguda telemeetriat ja viia läbi selle põhianalüüs IT-vaatest. Voopõhise infoturbeohtude tuvastamiseks on vajalik analüsaator varustada erinevate mootorite ja algoritmidega, mis tuvastavad küberturvaprobleemid standardsete või kohandatud Netflow väljade alusel, rikastavad standardandmeid erinevate Threat Intelligence allikate väliste andmetega jne.
Seega, kui teil on valida, valige Netflow või IPFIX. Kuid isegi kui teie seadmed töötavad ainult sFlow-ga, nagu kodumaised tootjad, saate isegi sel juhul sellest turvalisuse kontekstis kasu saada.
2019. aasta suvel analüüsisin Venemaa võrguriistvaratootjate võimalusi ja kõik need, välja arvatud NSG, Polygon ja Craftway, teatasid sFlow toetusest (vähemalt Zelax, Natex, Eltex, QTech, Rusteleteh).
Järgmine küsimus, millega silmitsi seisate, on see, kus rakendada turvalisuse eesmärgil vootoetust? Tegelikult pole küsimus päris õigesti püstitatud. Kaasaegsed seadmed toetavad peaaegu alati vooprotokolle. Seetõttu sõnastaksin küsimuse ümber teisiti – kus on turvalisuse seisukohalt kõige efektiivsem telemeetriat koguda? Vastus on üsna ilmne - juurdepääsutasemel, kus näete 100% kogu liiklusest, kus on üksikasjalik teave hostide kohta (MAC, VLAN, liidese ID), kus saate isegi jälgida P2P-liiklust hostide vahel, mis on pahatahtliku koodi tuvastamiseks ja levitamiseks kriitilise tähtsusega. Põhitasandil ei pruugi te osa liiklusest lihtsalt näha, kuid perimeetri tasemel näete veerandit kogu võrguliiklusest. Kuid kui teie võrgus on mingil põhjusel võõraid seadmeid, mis võimaldavad ründajatel perimeetrit mööda hiilimata "siseneda ja väljuda", siis ei anna selle telemeetria analüüsimine teile midagi. Seetõttu on maksimaalse katvuse saavutamiseks soovitatav lubada telemeetria kogumine juurdepääsu tasemel. Samas väärib märkimist, et isegi kui räägime virtualiseerimisest või konteineritest, leidub voo tugi sageli ka tänapäevastes virtuaalses kommutaatoris, mis võimaldab ka seal liiklust juhtida.
Aga kuna ma teema tõstatasin, siis pean vastama küsimusele: mis siis, kui seadmed, füüsilised või virtuaalsed, ei toeta vooprotokolle? Või on selle kaasamine keelatud (näiteks töökindluse tagamiseks tööstussegmentides)? Või põhjustab selle sisselülitamine protsessori suure koormuse (see juhtub vanema riistvara puhul)? Selle probleemi lahendamiseks on spetsiaalsed virtuaalsed andurid (vooluandurid), mis on sisuliselt tavalised jaoturid, mis juhivad liiklust ise läbi ja edastavad selle voo kujul kogumismoodulisse. Tõsi, sel juhul saame kõik probleemid, millest me eespool seoses pakettide hõivamise tööriistadega rääkisime. See tähendab, et peate mõistma mitte ainult vooluanalüüsi tehnoloogia eeliseid, vaid ka selle piiranguid.
Veel üks punkt, mida on oluline meeles pidada, kui räägime vooluanalüüsi tööriistadest. Kui tavaliste turvasündmuste genereerimise vahenditega seoses kasutame EPS-i mõõdikut (sündmus sekundis), siis telemeetriaanalüüsi puhul see näitaja ei kehti; see asendatakse FPS-iga (voog sekundis). Nagu EPS-i puhul, ei saa seda ette arvutada, kuid saate hinnata ligikaudset lõimede arvu, mille konkreetne seade sõltuvalt selle ülesandest genereerib. Internetist leiate tabeleid erinevate ettevõtte seadmete ja tingimuste ligikaudsete väärtustega, mis võimaldavad teil hinnata, milliseid litsentse vajate analüüsitööriistade jaoks ja milline on nende arhitektuur? Fakt on see, et IDS-andurit piirab teatud ribalaius, mida see saab "tõmmata", ja voolukollektoril on oma piirangud, mida tuleb mõista. Seetõttu on suurtes geograafiliselt hajutatud võrkudes tavaliselt mitu kollektorit. Kui ma kirjeldasin , olen juba andnud meie kollektsionääride arvu – neid on 21. Ja see on võrgu jaoks, mis on hajutatud üle viie kontinendi ja milles on umbes pool miljonit aktiivset seadet).
Kasutame Netflow monitooringusüsteemina oma lahendust , mis on spetsiaalselt keskendunud turvaprobleemide lahendamisele. Sellel on palju sisseehitatud mootoreid anomaalsete, kahtlaste ja selgelt pahatahtlike tegevuste tuvastamiseks, mis võimaldab tuvastada väga erinevaid ohte – krüptomineerimisest infolekkeni, pahatahtliku koodi levikust pettuseni. Nagu enamik vooluanalüsaatoreid, on ka Stealthwatch üles ehitatud kolmetasandilise skeemi järgi (generaator - kollektor - analüsaator), kuid seda on täiendatud mitmete huvitavate omadustega, mis on vaadeldava materjali kontekstis olulised. Esiteks integreerub see pakettide püüdmise lahendustega (nt Cisco Security Packet Analyzer), mis võimaldab salvestada valitud võrguseansse hilisemaks põhjalikuks uurimiseks ja analüüsiks. Teiseks oleme spetsiaalselt turvaülesannete laiendamiseks välja töötanud spetsiaalse nvzFlow protokolli, mis võimaldab lõppsõlmedel (serverid, tööjaamad jne) olevate rakenduste tegevust telemeetriasse “levitada” ja edastada kollektorile edasiseks analüüsiks. Kui oma algses versioonis töötab Stealthwatch võrgu tasandil mis tahes vooprotokolliga (sFlow, rFlow, Netflow, IPFIX, cFlow, jFlow, NetStream), siis nvzFlow tugi võimaldab andmete korrelatsiooni ka sõlme tasemel, seeläbi. suurendada kogu süsteemi efektiivsust ja näha rohkem rünnakuid kui tavalised võrguvoo analüsaatorid.
On selge, et kui rääkida Netflow analüüsisüsteemidest turvalisuse vaatenurgast, siis turg ei piirdu vaid ühe Cisco lahendusega. Kasutada saab nii kommerts- kui ka tasuta või jagamisvaralahendusi. On üsna kummaline, kui ma toon Cisco ajaveebis näidetena konkurentide lahendusi, seega räägin paar sõna sellest, kuidas võrgutelemeetriat saab analüüsida kahe populaarse, nime poolest sarnase, kuid siiski erineva tööriistaga - SiLK ja ELK.
SiLK on liiklusanalüüsi tööriistade komplekt (Internet-Level Knowledge süsteem), mille on välja töötanud Ameerika CERT/CC ja mis toetab tänase artikli kontekstis Netflow'i (5. ja 9., kõige populaarsemad versioonid), IPFIX. ja sFlow ning erinevate utiliitide (rwfilter, rwcount, rwflowpack jne) kasutamine võrgu telemeetriaga erinevate toimingute tegemiseks, et tuvastada selles volitamata toimingute märke. Kuid tuleb märkida paar olulist punkti. SiLK on käsurea tööriist, mis teostab on-line analüüsi, sisestades selliseid käske (üle 200 baidi suuruste ICMP-pakettide tuvastamine):
rwfilter --flowtypes=all/all --proto=1 --bytes-per-packet=200- --pass=stdout | rwrwcut --fields=sIP,dIP,iType,iCode --num-recs=15
mitte eriti mugav. Võite kasutada iSiLK GUI-d, kuid see ei tee teie elu palju lihtsamaks, lahendades ainult visualiseerimisfunktsiooni, mitte asendades analüütikut. Ja see on teine punkt. Erinevalt kommertslahendustest, millel on juba kindel analüütiline baas, anomaaliate tuvastamise algoritmid, vastav töövoog jms, tuleb SiLK puhul seda kõike ise teha, mis nõuab sinult veidi teistsuguseid kompetentse kui juba valmis kasutatavad tööriistad. See ei ole hea ega halb – see on peaaegu iga tasuta tööriista funktsioon, mis eeldab, et tead, mida teha, ja see aitab sind ainult selles (kommertstööriistad sõltuvad vähem nende kasutajate pädevusest, kuigi nad eeldavad ka et analüütikud mõistaksid vähemalt võrgu uurimise ja seire põhitõdesid). Aga tuleme tagasi SiLK juurde. Analüütiku töötsükkel sellega näeb välja järgmine:
- Hüpoteesi formuleerimine. Peame mõistma, mida me võrgu telemeetriast otsime, teadma unikaalseid atribuute, mille abil tuvastame teatud kõrvalekaldeid või ohte.
- Mudeli ehitamine. Olles püstitanud hüpoteesi, programmeerime selle sama Pythoni, shelli või muude vahenditega, mida SiLK ei sisalda.
- Testimine. Nüüd tuleb kord kontrollida meie hüpoteesi õigsust, mis kinnitatakse või lükatakse ümber SiLK utiliitide abil, mis algavad tähega 'rw', 'set', 'bag'.
- Reaalsete andmete analüüs. Tööstuslikus töös aitab SiLK meil midagi tuvastada ja analüütik peab vastama küsimustele “Kas leidsime selle, mida ootasime?”, “Kas see vastab meie hüpoteesile?”, “Kuidas vähendada valepositiivsete arvu?”, “Kuidas tunnustamise taseme parandamiseks? » ja nii edasi.
- Parandamine. Lõppfaasis täiustame varem tehtut - loome malle, täiustame ja optimeerime koodi, sõnastame ümber ja täpsustame hüpoteesi jne.
See tsükkel rakendub ka Cisco Stealthwatchile, ainult viimane automatiseerib need viis sammu maksimaalselt, vähendades analüütikute vigade arvu ja suurendades intsidentide tuvastamise tõhusust. Näiteks SiLK-s saab käsitsi kirjutatud skripte kasutades rikastada võrgustatistikat pahatahtlike IP-de väliste andmetega ning Cisco Stealthwatchis on see sisseehitatud funktsioon, mis kuvab kohe häire, kui võrguliiklus sisaldab interaktsioone musta nimekirja IP-aadressidega.
Kui minna vooanalüüsi tarkvara “tasulises” püramiidis kõrgemale, siis peale täiesti tasuta SiLK-i tuleb jagamisvara ELK, mis koosneb kolmest põhikomponendist - Elasticsearch (indekseerimine, otsimine ja andmete analüüs), Logstash (andmete sisestamine/väljund ) ja Kibana (visualiseerimine). Erinevalt SiLK-st, kus tuleb kõik ise kirjutada, on ELK-l juba palju valmis teeke/mooduleid (mõni tasuline, osa mitte), mis automatiseerivad võrgu telemeetria analüüsi. Näiteks võimaldab Logstashi GeoIP-filter seostada jälgitavaid IP-aadresse nende geograafilise asukohaga (Stealthwatchil on see sisseehitatud funktsioon).
ELK-l on ka üsna suur kogukond, kes selle seirelahenduse jaoks puuduvaid komponente täiendab. Näiteks Netflow, IPFIX ja sFlowga töötamiseks võite kasutada moodulit , kui te ei ole rahul Logstash Netflow mooduliga, mis toetab ainult Netflow'i.
Kuigi ELK-l on voo kogumise ja selles otsimise tõhusus, puudub praegu rikkalik sisseehitatud analüüs võrgu telemeetria anomaaliate ja ohtude tuvastamiseks. See tähendab, et ülalkirjeldatud elutsüklit järgides peate iseseisvalt kirjeldama rikkumiste mudeleid ja seejärel kasutama seda lahingusüsteemis (seal pole sisseehitatud mudeleid).
ELK-le on muidugi ka keerukamaid laiendusi, mis juba sisaldavad mõningaid mudeleid võrgu telemeetria anomaaliate tuvastamiseks, kuid sellised laiendused maksavad raha ja siin on küsimus, kas mäng on küünalt väärt - kirjuta ise sarnane mudel, osta see oma monitooringu tööriista juurutamist või ostke võrguliikluse analüüsi klassi valmislahendus.
Üldiselt ei taha ma laskuda vaidlusse, et parem on kulutada raha ja osta võrgutelemeetria anomaaliate ja ohtude jälgimiseks valmis lahendus (näiteks Cisco Stealthwatch) või ise välja mõelda ja sama kohandada. SiLK, ELK või nfdump või OSU Flow Tools iga uue ohu jaoks ( ma räägin neist kahest viimasest viimane kord)? Igaüks valib ise ja igaühel on oma motiivid, miks need kaks võimalust valivad. Tahtsin lihtsalt näidata, et võrgu telemeetria on teie sisemise infrastruktuuri võrguturvalisuse tagamisel väga oluline tööriist ja te ei tohiks seda tähelepanuta jätta, et mitte sattuda nende ettevõtete nimekirja, kelle nime meedias koos epiteetidega mainitakse. häkitud“, „infoturbenõuetele mittevastav“, „ei mõtle oma andmete ja kliendiandmete turvalisusele“.
Kokkuvõtteks tahaksin loetleda peamised näpunäited, mida peaksite oma sisemise infrastruktuuri infoturbe monitooringu loomisel järgima:
- Ärge piirduge ainult perimeetriga! Kasutage (ja valige) võrguinfrastruktuuri mitte ainult liikluse liigutamiseks punktist A punkti B, vaid ka küberturvalisuse probleemide lahendamiseks.
- Uurige oma võrguseadmetes olemasolevaid infoturbe jälgimismehhanisme ja kasutage neid.
- Sisejälgimisel eelista telemeetriaanalüüsi – see võimaldab tuvastada kuni 80-90% kõigist võrgu infoturbe intsidentidest, tehes samas võrgupakettide hõivamisel võimatut ja säästes ruumi kõikide infoturbesündmuste salvestamiseks.
- Voogude jälgimiseks kasuta Netflow v9 või IPFIX – need annavad turvakontekstis rohkem infot ja võimaldavad jälgida lisaks IPv4-le ka IPv6, MPLS jne.
- Kasutage valimimata vooprotokolli – see annab ohtude tuvastamiseks rohkem teavet. Näiteks Netflow või IPFIX.
- Kontrollige oma võrguseadmete koormust – see ei pruugi samuti vooprotokolliga hakkama saada. Seejärel kaaluge virtuaalsete andurite või Netflow Generation Appliance'i kasutamist.
- Rakendage kontrolli ennekõike juurdepääsu tasemel - see annab teile võimaluse näha 100% kogu liiklusest.
- Kui teil pole valikut ja kasutate Venemaa võrguseadmeid, valige see, mis toetab vooprotokolle või millel on SPAN/RSPAN-pordid.
- Kombineerida sissetungimise/ründe tuvastamise/tõkestamise süsteeme servades ja vooluanalüüsi süsteeme sisevõrgus (sh pilvedes).
Viimase näpunäide kohta tahaksin tuua illustratsiooni, mille olen juba varem andnud. Näete, et kui varem ehitas Cisco infoturbeteenistus oma infoturbe seiresüsteemi peaaegu täielikult sissetungituvastussüsteemide ja signatuurimeetodite baasil, siis nüüd moodustavad need vaid 20% intsidentidest. Veel 20% langeb vooanalüüsisüsteemidele, mis viitab sellele, et need lahendused pole kapriis, vaid reaalne tööriist kaasaegse ettevõtte infoturbeteenuste tegevuses. Pealegi on teil nende rakendamiseks kõige olulisem - võrguinfrastruktuur, millesse tehtud investeeringuid saab veelgi kaitsta, määrates võrgule infoturbe monitooringu funktsioonid.
Võrguvoogudes tuvastatud anomaaliatele või ohtudele reageerimise teemat ma konkreetselt ei puudutanud, kuid arvan, et juba praegu on selge, et seire ei tohiks lõppeda ainult ohu tuvastamisega. Sellele peaks järgnema vastus ja eelistatavalt automaatses või automatiseeritud režiimis. Kuid see on eraldi artikli teema.
Lisainfo:
PS. Kui teil on lihtsam kuulata kõike, mis ülal oli kirjutatud, siis saate vaadata tunniajalist esitlust, mis oli selle märkme aluseks.
Allikas: www.habr.com