Mitä tulee sisäisen yritys- tai osastoverkon turvallisuuden valvontaan, monet yhdistävät sen tietovuotojen hallintaan ja DLP-ratkaisujen toteuttamiseen. Ja jos yrität selventää kysymystä ja kysyä, kuinka havaitset hyökkäykset sisäiseen verkkoon, vastaus on yleensä maininta tunkeutumisen havaitsemisjärjestelmistä (IDS). Ja mikä oli ainoa vaihtoehto 10-20 vuotta sitten, on nykyään anakronismia. On olemassa tehokkaampi ja paikoin ainoa mahdollinen vaihtoehto sisäisen verkon valvontaan - käyttämällä virtausprotokollia, jotka oli alun perin suunniteltu verkko-ongelmien etsimiseen (vianetsintä), mutta muuttuivat ajan myötä erittäin mielenkiintoiseksi tietoturvatyökaluksi. Puhumme siitä, millaisia virtausprotokollia on olemassa ja mitkä niistä tunnistavat paremmin verkkohyökkäykset, missä on parasta toteuttaa virtauksen valvonta, mitä ottaa huomioon otettaessa käyttöön tällaista järjestelmää ja jopa kuinka tämä kaikki "nostetaan". tämän artiklan soveltamisalaan kuuluvista kotitalouslaitteista.
En käsittele kysymystä "Miksi infrastruktuurin sisäistä turvallisuusseurantaa tarvitaan?" Vastaus näyttää olevan selvä. Mutta jos kuitenkin haluat vielä kerran varmistaa, että et voi elää ilman sitä tänään, lyhyt video siitä, kuinka voit tunkeutua palomuurilla suojattuun yritysverkkoon 17 eri tavalla. Siksi oletetaan, että ymmärrämme sisäisen valvonnan olevan välttämätön asia ja ei jää muuta kuin ymmärtää, miten se voidaan järjestää.
Haluaisin korostaa kolmea keskeistä tietolähdettä infrastruktuurin seurantaan verkkotasolla:
- "raaka" liikenne, jonka keräämme ja lähetämme analysoitavaksi tiettyihin analyysijärjestelmiin,
- tapahtumia verkkolaitteista, joiden kautta liikenne kulkee,
- liikennetiedot, jotka on vastaanotettu jonkin virtausprotokollan kautta.
Raakaliikenteen sieppaus on tietoturvaasiantuntijoiden suosituin vaihtoehto, koska se ilmestyi historiallisesti ja oli ensimmäinen. Perinteiset verkon tunkeutumisen havainnointijärjestelmät (ensimmäinen kaupallinen tunkeutumisen havainnointijärjestelmä oli NetRanger Wheel Groupilta, jonka Cisco osti vuonna 1998) olivat tarkasti mukana kaappaamassa paketteja (ja myöhempiä istuntoja), joissa etsittiin tiettyjä allekirjoituksia ("ratkaisevat säännöt" FSTEC-terminologia), signalointihyökkäykset. Tietysti voit analysoida raakaa liikennettä paitsi IDS:n avulla myös muilla työkaluilla (esim. Wireshark, tcpdum tai Cisco IOS:n NBAR2-toiminnallisuus), mutta niistä puuttuu yleensä tietopohja, joka erottaa tietoturvatyökalun tavallisesta. IT-työkalu.
Joten hyökkäysten havaitsemisjärjestelmät. Vanhin ja suosituin menetelmä verkkohyökkäysten havaitsemiseen, joka tekee hyvää työtä kehällä (riippumatta siitä, mikä - yritys, datakeskus, segmentti jne.), mutta epäonnistuu nykyaikaisissa kytketyissä ja ohjelmiston määrittämissä verkoissa. Perinteisten kytkimien pohjalta rakennetun verkon tapauksessa hyökkäyksentunnistusanturien infrastruktuuri kasvaa liian suureksi - joudut asentamaan anturi jokaiseen yhteyteen solmuun, johon hyökkäyksiä halutaan valvoa. Jokainen valmistaja tietysti myy sinulle mielellään satoja ja tuhansia antureita, mutta mielestäni budjettisi ei voi tukea tällaisia kuluja. Voin sanoa, että edes Ciscolla (ja me olemme NGIPS:n kehittäjät) emme pystyneet tekemään tätä, vaikka hintakysymys näyttäisi olevan edessämme. Minun ei pitäisi sietää - se on oma päätöksemme. Lisäksi herää kysymys, kuinka anturi kytketään tässä versiossa? Aukkoon? Entä jos anturi itse pettää? Vaaditaanko anturin ohitusmoduulia? Käytä jakajia (hanaa)? Kaikki tämä tekee ratkaisusta kalliimman ja tekee siitä mahdoton kaikenkokoiselle yritykselle.
Voit yrittää ripustaa anturin SPAN/RSPAN/ERSPAN-porttiin ja ohjata liikennettä tarvittavista kytkinporteista siihen. Tämä vaihtoehto poistaa osittain edellisessä kappaleessa kuvatun ongelman, mutta aiheuttaa toisen - SPAN-portti ei voi hyväksyä ehdottomasti kaikkea siihen lähetettävää liikennettä - sillä ei ole tarpeeksi kaistanleveyttä. Sinun on uhrattava jotain. Joko jätä osa solmuista ilman valvontaa (sen jälkeen sinun on priorisoitava ne ensin) tai ei lähetä kaikkea liikennettä solmusta, vaan vain tietyn tyyppinen. Joka tapauksessa saatamme missata joitain hyökkäyksiä. Lisäksi SPAN-porttia voidaan käyttää muihin tarpeisiin. Tämän seurauksena meidän on tarkistettava olemassa oleva verkkotopologia ja mahdollisesti tehtävä siihen muutoksia, jotta verkkosi kattaisi mahdollisimman paljon anturien lukumäärää (ja koordinoi tämä IT:n kanssa).
Entä jos verkkosi käyttää epäsymmetrisiä reittejä? Entä jos olet ottanut käyttöön tai aiot ottaa käyttöön SDN:n? Entä jos sinun on valvottava virtualisoituja koneita tai kontteja, joiden liikenne ei saavuta fyysistä kytkimiä ollenkaan? Nämä ovat kysymyksiä, joista perinteiset IDS-toimittajat eivät pidä, koska he eivät osaa vastata niihin. Ehkä he vakuuttavat sinut siitä, että kaikki nämä muodikkaat tekniikat ovat hypeä etkä tarvitse sitä. Ehkä he puhuvat tarpeesta aloittaa pienestä. Tai ehkä he sanovat, että sinun on asetettava tehokas puimakone verkon keskelle ja ohjattava kaikki liikenne siihen tasapainottimien avulla. Mitä tahansa vaihtoehtoa sinulle tarjotaan, sinun on ymmärrettävä selvästi, kuinka se sopii sinulle. Ja vasta sen jälkeen tee päätös lähestymistavan valinnasta verkkoinfrastruktuurin tietoturvan valvontaan. Palatakseni pakettikaappaukseen, haluan sanoa, että tämä menetelmä on edelleen erittäin suosittu ja tärkeä, mutta sen päätarkoitus on rajavalvonta; organisaatiosi ja Internetin väliset rajat, datakeskuksen ja muun verkon rajat, prosessinohjausjärjestelmän ja yrityssegmentin väliset rajat. Näissä paikoissa klassisilla IDS/IPS:illä on edelleen oikeus olemassaoloon ja selviytyä hyvin tehtävistään.
Siirrytään toiseen vaihtoehtoon. Verkkolaitteilta tulevien tapahtumien analysointia voidaan käyttää myös hyökkäysten havaitsemiseen, mutta ei päämekanismina, koska se mahdollistaa vain pienen luokan tunkeutumisen havaitsemisen. Lisäksi se liittyy tiettyyn reaktiivisuuteen - hyökkäyksen on ensin tapahduttava, sitten se on tallennettava verkkolaitteella, mikä tavalla tai toisella ilmoittaa tietoturvaongelmasta. Tällaisia tapoja on useita. Tämä voi olla syslog, RMON tai SNMP. Kahta viimeistä protokollaa verkon valvontaan tietoturvan yhteydessä käytetään vain, jos meidän on havaittava DoS-hyökkäys itse verkkolaitteistoon, koska RMON:n ja SNMP:n avulla voidaan esimerkiksi valvoa laitteen keskusyksikön kuormitusta. prosessori tai sen liitännät. Tämä on yksi "halvimmista" (kaikilla on syslog tai SNMP), mutta myös tehottomin kaikista sisäisen infrastruktuurin tietoturvan valvontamenetelmistä - monet hyökkäykset ovat yksinkertaisesti piilossa siltä. Niitä ei tietenkään pidä laiminlyödä, ja sama syslog-analyysi auttaa tunnistamaan ajoissa muutokset itse laitteen kokoonpanossa, sen kompromissi, mutta se ei ole kovin sopiva koko verkkoon kohdistuvien hyökkäysten havaitsemiseen.
Kolmas vaihtoehto on analysoida tietoja liikenteestä, joka kulkee laitteen kautta, joka tukee yhtä useista virtausprotokollasta. Tässä tapauksessa ketjutusinfrastruktuuri koostuu protokollasta riippumatta välttämättä kolmesta osasta:
- Virran tuottaminen tai vienti. Tämä rooli määrätään yleensä reitittimelle, kytkimelle tai muulle verkkolaitteelle, joka ohjaa verkkoliikennettä itsensä läpi mahdollistaa avainparametrien poimimisen siitä, jotka sitten siirretään keräysmoduuliin. Esimerkiksi Cisco tukee Netflow-protokollaa paitsi reitittimissä ja kytkimissä, myös virtuaalisissa ja teollisissa, myös langattomissa ohjaimissa, palomuureissa ja jopa palvelimissa.
- Keräyskulku. Ottaen huomioon, että nykyaikaisessa verkossa on yleensä useampi kuin yksi verkkolaite, syntyy virtojen keräämisen ja yhdistämisen ongelma, joka ratkaistaan niin sanotuilla keräilijöillä, jotka käsittelevät vastaanotetut virrat ja lähettävät ne sitten analysoitavaksi.
- Virtausanalyysi Analysaattori ottaa pääasiallisen älyllisen tehtävän ja tekee tiettyjä johtopäätöksiä soveltamalla virtoihin erilaisia algoritmeja. Esimerkiksi osana IT-toimintoa tällainen analysaattori voi tunnistaa verkon pullonkauloja tai analysoida liikenteen kuormitusprofiilia verkon lisäoptimointia varten. Tietoturvallisuuden vuoksi tällainen analysaattori voi havaita tietovuodot, haitallisen koodin leviämisen tai DoS-hyökkäykset.
Älä ajattele, että tämä kolmikerroksinen arkkitehtuuri on liian monimutkainen - kaikki muut vaihtoehdot (paitsi ehkä SNMP:n ja RMON:n kanssa toimivat verkonvalvontajärjestelmät) toimivat myös sen mukaan. Meillä on analysointia varten datageneraattori, joka voi olla verkkolaite tai erillinen anturi. Meillä on hälytyksen keräysjärjestelmä ja hallintajärjestelmä koko valvontainfrastruktuurille. Kaksi viimeistä komponenttia voidaan yhdistää yhden solmun sisällä, mutta enemmän tai vähemmän suurissa verkoissa ne on yleensä hajautettu vähintään kahdelle laitteelle skaalautuvuuden ja luotettavuuden varmistamiseksi.
Toisin kuin pakettianalyysi, joka perustuu kunkin paketin ja sen sisältämien istuntojen otsikko- ja runkotietojen tutkimiseen, virtausanalyysi perustuu metatietojen keräämiseen verkkoliikenteestä. Milloin, kuinka paljon, mistä ja mistä, miten... näihin kysymyksiin vastaa verkon telemetrian analyysi eri virtausprotokollia käyttäen. Aluksi niitä käytettiin tilastojen analysointiin ja IT-ongelmien etsimiseen verkosta, mutta sitten analyyttisten mekanismien kehittyessä niitä on mahdollista soveltaa samaan telemetriaan turvallisuussyistä. On jälleen syytä huomata, että vuoanalyysi ei korvaa tai korvaa pakettien sieppausta. Jokaisella näistä menetelmistä on oma sovellusalue. Mutta tämän artikkelin yhteydessä virtausanalyysi sopii parhaiten sisäisen infrastruktuurin seurantaan. Sinulla on verkkolaitteita (toimivatpa ne ohjelmiston määrittämän paradigman tai staattisten sääntöjen mukaisesti), joita hyökkäys ei voi ohittaa. Se voi ohittaa klassisen IDS-anturin, mutta virtausprotokollaa tukeva verkkolaite ei. Tämä on tämän menetelmän etu.
Toisaalta, jos tarvitset todisteita lainvalvontaviranomaisille tai omalle tapausten tutkintaryhmällesi, et tule toimeen ilman pakettien sieppausta - verkon telemetria ei ole kopio liikenteestä, jota voidaan käyttää todisteiden keräämiseen; sitä tarvitaan tietoturva-alan nopeaan havaitsemiseen ja päätöksentekoon. Toisaalta telemetria-analyysin avulla et voi "kirjoittaa" kaikkea verkkoliikennettä (jos mitään, Cisco käsittelee datakeskuksia :-), vaan vain sitä, mikä on mukana hyökkäyksessä. Telemetria-analyysityökalut täydentävät hyvin perinteisiä pakettien sieppausmekanismeja antaen komentoja valikoivaan sieppaukseen ja tallentamiseen. Muuten sinulla on oltava valtava tallennusinfrastruktuuri.
Kuvitellaan verkkoa, joka toimii nopeudella 250 Mbit/s. Jos haluat tallentaa kaiken tämän määrän, tarvitset 31 Mt tallennustilaa sekuntia liikenteen siirtoa varten, 1,8 Gt yhdelle minuutille, 108 Gt yhdelle tunnille ja 2,6 Tt yhdelle päivälle. Päivittäisen tiedon tallentamiseen verkosta, jonka kaistanleveys on 10 Gbit/s, tarvitset 108 Tt tallennustilaa. Mutta jotkut sääntelyviranomaiset vaativat, että tietoturvatiedot säilytetään vuosia... On-demand-tallennus, jonka kulkuanalyysi auttaa sinua toteuttamaan, auttaa vähentämään näitä arvoja suuruusluokkaa. Muuten, jos puhumme tallennetun verkon telemetriatietojen määrän ja täydellisen tiedonkeruun suhteesta, se on noin 1 - 500. Samoille yllä annetuille arvoille tallennetaan täydellinen transkriptio kaikesta päivittäisestä liikenteestä on 5 ja 216 Gt, vastaavasti (voit jopa tallentaa sen tavalliselle flash-asemalle ).
Jos verkkoraakatietojen analysointityökalujen osalta sen kaappausmenetelmä on lähes sama toimittajalta toiselle, niin virtausanalyysin tapauksessa tilanne on toinen. Vuoprotokollalle on useita vaihtoehtoja, joiden erot sinun on tiedettävä turvallisuuden yhteydessä. Suosituin on Ciscon kehittämä Netflow-protokolla. Tästä protokollasta on useita versioita, jotka eroavat ominaisuuksiltaan ja tallennettujen liikennetietojen määrältä. Nykyinen versio on yhdeksäs (Netflow v9), jonka pohjalta kehitettiin toimialastandardi Netflow v10, joka tunnetaan myös nimellä IPFIX. Nykyään useimmat verkkotoimittajat tukevat Netflow- tai IPFIX-laitteita laitteissaan. Mutta virtausprotokollalle on olemassa useita muita vaihtoehtoja - sFlow, jFlow, cFlow, rFlow, NetStream jne., joista sFlow on suosituin. Juuri tätä tyyppiä kotimaiset verkkolaitteiden valmistajat tukevat useimmiten sen helppokäyttöisyyden vuoksi. Mitkä ovat tärkeimmät erot netflow'n, josta on tullut de facto standardi, ja sFlow'n välillä? Haluaisin korostaa useita keskeisiä. Ensinnäkin Netflow:ssa on käyttäjän mukautettavat kentät sFlown kiinteiden kenttien sijaan. Ja toiseksi, ja tämä on meidän tapauksessamme tärkein asia, sFlow kerää ns. näytetelemetriaa; toisin kuin Netflow:n ja IPFIXin otostamaton. Mitä eroa niillä on?
Kuvittele, että päätät lukea kirjan "” kollegoistani - Gary McIntyre, Joseph Munitz ja Nadem Alfardan (voit ladata osan kirjasta linkistä). Sinulla on kolme vaihtoehtoa saavuttaaksesi tavoitteesi - lue koko kirja, selaa se läpi, pysähtyen joka 10. tai 20. sivulle tai yritä löytää uudelleenkerrontaa keskeisistä käsitteistä blogissa tai palvelussa, kuten SmartReading. Otantaton telemetria siis lukee jokaisen verkkoliikenteen "sivun", toisin sanoen analysoi jokaisen paketin metatietoja. Sampled telemetria on valikoiva liikenteen tutkimus siinä toivossa, että valitut näytteet sisältävät mitä tarvitset. Kanavan nopeudesta riippuen näytetelemetria lähetetään analysoitavaksi joka 64., 200., 500., 1000., 2000. tai jopa 10000. paketti.
Tietoturvavalvonnan kontekstissa tämä tarkoittaa, että näytteity telemetria soveltuu hyvin DDoS-hyökkäysten havaitsemiseen, skannaukseen ja haitallisen koodin levittämiseen, mutta saattaa jäädä huomiotta ydin- tai monipakettihyökkäykset, jotka eivät sisältyneet analysoitavaksi lähetetyssä otoksessa. Otottamattomalla telemetrialla ei ole tällaisia haittoja. Tämän ansiosta havaittujen hyökkäysten valikoima on paljon laajempi. Tässä on lyhyt luettelo tapahtumista, jotka voidaan havaita verkon telemetrian analyysityökaluilla.
Tietenkin jotkut avoimen lähdekoodin Netflow-analysaattorit eivät salli sinun tehdä tätä, koska sen päätehtävänä on kerätä telemetriaa ja suorittaa perusanalyysiä siitä IT-näkökulmasta. Tietoturvauhkien tunnistamiseksi virtaukseen perustuen on tarpeen varustaa analysaattori erilaisilla moottoreilla ja algoritmeilla, jotka tunnistavat kyberturvallisuusongelmat vakio- tai mukautettujen Netflow-kenttien perusteella, rikastavat standardidataa ulkoisilla tiedoilla eri Threat Intelligence -lähteistä jne.
Siksi, jos sinulla on valinnanvaraa, valitse Netflow tai IPFIX. Mutta vaikka laitteesi toimisi vain sFlow'n kanssa, kuten kotimaiset valmistajat, voit myös tässä tapauksessa hyötyä siitä tietoturvan kannalta.
Analysoin kesällä 2019 venäläisten verkkolaitteiden valmistajien ominaisuuksia ja ne kaikki NSG:tä, Polygonia ja Craftwayta lukuun ottamatta ilmoittivat tukevansa sFlow'ta (ainakin Zelax, Natex, Eltex, QTech, Rusteleteh).
Seuraava kysymys, johon kohtaat, on, missä virran tuki toteutetaan turvallisuussyistä? Itse asiassa kysymystä ei ole esitetty täysin oikein. Nykyaikaiset laitteet tukevat lähes aina virtausprotokollia. Siksi muotoilisin kysymyksen uudelleen toisin - missä on tehokkainta kerätä telemetriaa turvallisuusnäkökulmasta? Vastaus on melko ilmeinen - pääsytasolla, jossa näet 100% kaikesta liikenteestä, jossa sinulla on yksityiskohtaiset tiedot isännistä (MAC, VLAN, käyttöliittymätunnus), jossa voit jopa seurata P2P-liikennettä isäntien välillä, mikä on kriittinen haitallisen koodin havaitsemisessa ja levittämisessä. Ydintasolla et ehkä yksinkertaisesti näe osaa liikenteestä, mutta kehätasolla näet neljänneksen kaikesta verkkoliikenteestäsi. Mutta jos verkossasi on jostain syystä vieraita laitteita, joiden avulla hyökkääjät voivat "sisään ja poistua" ohittamatta kehää, telemetrian analysointi siitä ei anna sinulle mitään. Siksi parhaan kattavuuden saavuttamiseksi on suositeltavaa ottaa telemetrian kerääminen käyttöön käyttöoikeustasolla. Samalla kannattaa huomioida, että vaikka puhutaankin virtualisoinnista tai konteista, virtaustuki löytyy usein myös nykyaikaisista virtuaalikytkimistä, mikä mahdollistaa liikenteen ohjaamisen myös siellä.
Mutta koska otin aiheen esiin, minun on vastattava kysymykseen: entä jos laitteisto, fyysinen tai virtuaalinen, ei tue virtausprotokollia? Vai onko sen sisällyttäminen kielletty (esimerkiksi teollisuussegmenteillä luotettavuuden varmistamiseksi)? Vai johtaako sen käynnistäminen korkeaan suorittimen kuormitukseen (tätä tapahtuu vanhemmissa laitteissa)? Tämän ongelman ratkaisemiseksi on olemassa erikoistuneita virtuaalisia antureita (virtausantureita), jotka ovat pohjimmiltaan tavallisia jakajia, jotka ohjaavat liikennettä itsensä läpi ja lähettävät sen virtauksen muodossa keräysmoduuliin. Totta, tässä tapauksessa saamme kaikki ongelmat, joista puhuimme edellä pakettien sieppaustyökalujen suhteen. Eli sinun on ymmärrettävä virtausanalyysitekniikan edut, mutta myös sen rajoitukset.
Toinen seikka, joka on tärkeää muistaa puhuttaessa virtausanalyysityökaluista. Jos käytämme EPS-metriikkaa (tapahtuma per sekunti) tavanomaisiin tietoturvatapahtumien generointikeinoihin, tämä indikaattori ei sovellu telemetria-analyysiin; se korvataan FPS:llä (virtaus sekunnissa). Kuten EPS:n tapauksessa, sitä ei voi laskea etukäteen, mutta voit arvioida likimääräisen lankojen määrän, jonka tietty laite luo tehtävästään riippuen. Löydät Internetistä taulukoita likimääräisillä arvoilla erityyppisille yrityslaitteille ja -olosuhteille, joiden avulla voit arvioida, mitä lisenssejä tarvitset analyysityökaluihin ja mikä niiden arkkitehtuuri on? Tosiasia on, että IDS-anturia rajoittaa tietty kaistanleveys, jonka se voi "vetää", ja virtauskerääjällä on omat rajoituksensa, jotka on ymmärrettävä. Siksi suurissa, maantieteellisesti hajautetuissa verkoissa on yleensä useita kerääjiä. Kun kuvailin , olen jo antanut keräilijöidemme lukumäärän - niitä on 21. Ja tämä koskee verkkoa, joka on hajallaan viidellä mantereella ja jossa on noin puoli miljoonaa aktiivista laitetta).
Käytämme omaa ratkaisuamme Netflow-valvontajärjestelmänä , joka keskittyy erityisesti tietoturvaongelmien ratkaisemiseen. Siinä on monia sisäänrakennettuja moottoreita epänormaalin, epäilyttävän ja selvästi haitallisen toiminnan havaitsemiseen, mikä mahdollistaa monenlaisten uhkien havaitsemisen - kryptominoinnista tietovuotoihin, haitallisen koodin leviämisestä petokseen. Kuten useimmat virtausanalysaattorit, Stealthwatch on rakennettu kolmitasoisen järjestelmän mukaan (generaattori - kerääjä - analysaattori), mutta sitä on täydennetty useilla mielenkiintoisilla ominaisuuksilla, jotka ovat tärkeitä tarkasteltavan materiaalin yhteydessä. Ensinnäkin se integroituu pakettien sieppausratkaisuihin (kuten Cisco Security Packet Analyzer), jonka avulla voit tallentaa valitut verkkoistunnot myöhempää syvällistä tutkimusta ja analysointia varten. Toiseksi, erityisesti tietoturvatehtävien laajentamiseksi, olemme kehittäneet erityisen nvzFlow-protokollan, jonka avulla voit "lähettää" pääsolmujen (palvelimet, työasemat jne.) sovellusten toimintaa telemetriaan ja lähettää sen kerääjälle jatkoanalyysiä varten. Jos alkuperäisessä versiossaan Stealthwatch toimii minkä tahansa virtausprotokollan (sFlow, rFlow, Netflow, IPFIX, cFlow, jFlow, NetStream) kanssa verkkotasolla, niin nvzFlow-tuki mahdollistaa tietojen korreloinnin myös solmutasolla, jolloin. parantaa koko järjestelmän tehokkuutta ja nähdä enemmän hyökkäyksiä kuin perinteiset verkkovirta-analysaattorit.
On selvää, että kun Netflow-analyysijärjestelmistä puhutaan tietoturvan näkökulmasta, markkinat eivät rajoitu yhteen Ciscon ratkaisuun. Voit käyttää sekä kaupallisia että ilmaisia tai shareware-ratkaisuja. On aika outoa, jos mainitsen kilpailijoiden ratkaisuja esimerkkeinä Cisco-blogissa, joten sanon muutaman sanan siitä, kuinka verkon telemetriaa voidaan analysoida kahdella suositulla, samannimisellä, mutta silti erilaisella työkalulla - SiLK ja ELK.
SiLK on joukko työkaluja (System for Internet-Level Knowledge) liikenteen analysointiin, jonka on kehittänyt amerikkalainen CERT/CC ja joka tukee tämänpäiväisen artikkelin yhteydessä Netflowa (5. ja 9., suosituimmat versiot), IPFIX. ja sFlow ja käyttämällä erilaisia apuohjelmia (rwfilter, rwcount, rwflowpack jne.) erilaisten toimintojen suorittamiseen verkon telemetrialla havaitakseen merkkejä luvattomista toimista siinä. Mutta on pari tärkeää huomioitavaa. SiLK on komentorivityökalu, joka suorittaa online-analyysin syöttämällä tällaisia komentoja (yli 200 tavua suurempien ICMP-pakettien havaitseminen):
rwfilter --flowtypes=all/all --proto=1 --bytes-per-packet=200- --pass=stdout | rwrwcut --fields=sIP,dIP,iType,iCode --num-recs=15
ei kovin mukava. Voit käyttää iSiLK GUI:ta, mutta se ei helpota elämääsi paljon, ratkaisee vain visualisointitoiminnon eikä korvaa analyytikkoa. Ja tämä on toinen kohta. Toisin kuin kaupallisissa ratkaisuissa, joilla on jo vankka analyyttinen pohja, poikkeamien havaitsemisalgoritmit, vastaava työnkulku jne., SiLK:n tapauksessa sinun on tehtävä kaikki tämä itse, mikä vaatii sinulta hieman erilaista osaamista kuin jo valmiiksi käytettävät työkalut. Tämä ei ole hyvä eikä huono - tämä on melkein minkä tahansa ilmaisen työkalun ominaisuus, joka olettaa, että tiedät mitä tehdä, ja se auttaa sinua vain tässä (kaupalliset työkalut ovat vähemmän riippuvaisia käyttäjiensä osaamisesta, vaikka he myös olettavat että analyytikot ymmärtävät ainakin verkkotutkimuksen ja seurannan perusteet). Mutta palataanpa Silkkiin. Analyytikon työkierto sen kanssa näyttää tältä:
- Hypoteesin muotoileminen. Meidän on ymmärrettävä, mitä etsimme verkon telemetrian sisältä, tiedettävä ainutlaatuiset attribuutit, joiden avulla tunnistamme tietyt poikkeavuudet tai uhat.
- Mallin rakentaminen. Kun olet muotoillut hypoteesin, ohjelmoimme sen käyttämällä samaa Python-, shell- tai muita työkaluja, joita SiLK ei sisällä.
- Testaus. Nyt tulee vuoro tarkistaa hypoteesimme oikeellisuus, joka vahvistetaan tai kumotaan käyttämällä SiLK-apuohjelmia, jotka alkavat 'rw', 'set', 'bag'.
- Todellisten tietojen analyysi. Teollisessa käytössä SiLK auttaa meitä tunnistamaan jotain ja analyytikon tulee vastata kysymyksiin "Löysimmekö mitä odotimme?", "Vastaako tämä hypoteesiamme?", "Kuinka vähentää väärien positiivisten tulosten määrää?", "Miten parantaaksesi tunnustusta? » ja niin edelleen.
- Parantaminen. Viimeisessä vaiheessa parannamme aiemmin tehtyä - luomme malleja, parannamme ja optimoimme koodia, muotoilemme uudelleen ja selvennämme hypoteesia jne.
Tätä sykliä voidaan soveltaa myös Cisco Stealthwatchiin, vain viimeinen automatisoi nämä viisi vaihetta maksimissaan, mikä vähentää analyytikkovirheiden määrää ja lisää tapausten havaitsemisen tehokkuutta. Esimerkiksi SiLKissa voit rikastaa verkkotilastoja haitallisten IP-osoitteiden ulkoisilla tiedoilla käsin kirjoitetuilla skripteillä, ja Cisco Stealthwatchissa se on sisäänrakennettu toiminto, joka näyttää välittömästi hälytyksen, jos verkkoliikenne sisältää vuorovaikutuksia mustalla listalla olevien IP-osoitteiden kanssa.
Jos pääset korkeammalle virtausanalyysiohjelmiston "maksullisessa" pyramidissa, niin täysin ilmaisen SiLK:n jälkeen tulee shareware ELK, joka koostuu kolmesta avainkomponentista - Elasticsearch (indeksointi, haku ja data-analyysi), Logstash (tietojen syöttö/tulostus). ) ja Kibana (visualisointi). Toisin kuin SiLK, jossa sinun on kirjoitettava kaikki itse, ELK:lla on jo monia valmiita kirjastoja/moduuleja (osa maksullisia, osa ei), jotka automatisoivat verkon telemetrian analysoinnin. Esimerkiksi Logstashin GeoIP-suodattimen avulla voit liittää valvottuja IP-osoitteita niiden maantieteelliseen sijaintiin (Stealthwatchissa on tämä sisäänrakennettu ominaisuus).
ELK:lla on myös melko suuri yhteisö, joka täydentää tämän valvontaratkaisun puuttuvia komponentteja. Moduulia voidaan käyttää esimerkiksi Netflow:n, IPFIX:n ja sFlow:n kanssa työskentelemiseen , jos et ole tyytyväinen Logstash Netflow -moduuliin, joka tukee vain Netflow:ta.
Vaikka ELK tehostaa virtauksen keräämistä ja siinä etsimistä, siitä puuttuu tällä hetkellä rikas sisäänrakennettu analytiikka verkon telemetrian poikkeavuuksien ja uhkien havaitsemiseksi. Toisin sanoen yllä kuvattua elinkaaria noudattaen sinun on kuvattava itsenäisesti rikkomusmallit ja käytettävä sitä sitten taistelujärjestelmässä (siellä ei ole sisäänrakennettuja malleja).
ELK:lle on tietysti olemassa kehittyneempiä laajennuksia, jotka sisältävät jo joitakin malleja verkon telemetrian poikkeavuuksien havaitsemiseen, mutta tällaiset laajennukset maksavat rahaa ja tässä on kysymys, onko peli kynttilän arvoinen - kirjoita itse samanlainen malli, osta se toteutus seurantatyökalullesi tai osta verkkoliikenteen analysointiluokan valmis ratkaisu.
Yleisesti ottaen en halua mennä keskusteluun siitä, että on parempi käyttää rahaa ja ostaa valmis ratkaisu verkkotelemetrian poikkeavuuksien ja uhkien seurantaan (esim. Cisco Stealthwatch) tai keksiä se itse ja muokata sitä SiLK, ELK tai nfdump tai OSU Flow Tools jokaiselle uudelle uhalle (puhun niistä kahdesta viimeisestä viime kerta)? Jokainen valitsee itse ja jokaisella on omat motiivinsa valita jompikumpi kahdesta vaihtoehdosta. Halusin vain näyttää, että verkkotelemetria on erittäin tärkeä työkalu sisäisen infrastruktuurisi verkkoturvallisuuden varmistamisessa ja sitä ei pidä laiminlyödä, jotta et joutuisi joukkoon yrityksiä, joiden nimi mainitaan tiedotusvälineissä epiteettien kanssa ” hakkeroitu", "tietoturvavaatimusten vastainen" ", "ei ajattele tietojensa ja asiakastietojensa turvallisuutta."
Yhteenvetona haluaisin listata tärkeimmät vinkit, joita sinun tulee noudattaa rakentaessasi sisäisen infrastruktuurisi tietoturvavalvontaa:
- Älä rajoita itseäsi vain kehälle! Käytä (ja valitse) verkkoinfrastruktuuria paitsi liikenteen siirtämiseen pisteestä A pisteeseen B, myös kyberturvallisuusongelmien ratkaisemiseen.
- Tutustu verkkolaitteesi olemassa oleviin tietoturvan valvontamekanismeihin ja käytä niitä.
- Käytä sisäisessä valvonnassa etusijalle telemetria-analyysi - sen avulla voit havaita jopa 80-90% kaikista verkon tietoturvahäiriöistä, samalla kun teet sen, mikä on mahdotonta kaapattaessa verkkopaketteja ja säästää tilaa kaikkien tietoturvatapahtumien tallentamiseen.
- Voit seurata virtauksia käyttämällä Netflow v9:ää tai IPFIX:ää – ne tarjoavat enemmän tietoa suojauskontekstista ja mahdollistavat IPv4:n lisäksi myös IPv6:n, MPLS:n jne.
- Käytä otostamatonta kulkuprotokollaa – se tarjoaa lisätietoja uhkien havaitsemisesta. Esimerkiksi Netflow tai IPFIX.
- Tarkista verkkolaitteesi kuormitus - se ei ehkä pysty käsittelemään yhtä hyvin virtausprotokollaa. Harkitse sitten virtuaalisten antureiden tai Netflow Generation Appliancen käyttöä.
- Ota ohjaus käyttöön ennen kaikkea käyttöoikeustasolla - tämä antaa sinulle mahdollisuuden nähdä 100 % kaikesta liikenteestä.
- Jos sinulla ei ole vaihtoehtoja ja käytät venäläisiä verkkolaitteita, valitse sellainen, joka tukee vuoprotokollia tai jossa on SPAN/RSPAN-portit.
- Yhdistä tunkeutumisen/hyökkäyksen havaitsemis-/estojärjestelmät reunoilla ja virtausanalyysijärjestelmät sisäisessä verkossa (myös pilvissä).
Mitä tulee viimeiseen vihjeeseen, haluaisin antaa esimerkin, jonka olen jo antanut aiemmin. Näet, että jos aiemmin Ciscon tietoturvapalvelu rakensi tietoturvan valvontajärjestelmän lähes kokonaan tunkeutumisen havainnointijärjestelmien ja allekirjoitusmenetelmien pohjalta, niin nyt niiden osuus on vain 20 % tapauksista. Toinen 20 % kuuluu virtausanalyysijärjestelmiin, mikä viittaa siihen, että nämä ratkaisut eivät ole mielijohteesta, vaan todellisesta työkalusta nykyaikaisen yrityksen tietoturvapalveluiden toiminnassa. Lisäksi sinulla on tärkein asia niiden toteuttamiseen - verkkoinfrastruktuuri, johon tehdyt investoinnit voidaan suojata edelleen antamalla tietoturvan valvontatoimintoja verkkoon.
En erityisesti käsitellyt verkkovirroissa havaittuihin poikkeamiin tai uhkiin reagoimista, mutta mielestäni on jo nyt selvää, ettei seurannan pidä päättyä vain uhan havaitsemiseen. Sen jälkeen tulisi vastata ja mieluiten automaattisessa tai automatisoidussa tilassa. Mutta tämä on erillisen artikkelin aihe.
Lisätiedot:
PS. Jos sinun on helpompi kuulla kaikki yllä kirjoitettu, voit katsoa tunnin mittaisen esityksen, joka muodosti tämän muistiinpanon perustan.
Lähde: will.com