Quan es tracta de supervisar la seguretat d'una xarxa interna corporativa o departamental, molts l'associen amb el control de fuites d'informació i la implementació de solucions DLP. I si intenteu aclarir la pregunta i pregunteu com detecteu atacs a la xarxa interna, la resposta sol ser una menció als sistemes de detecció d'intrusions (IDS). I la que era l'única opció fa 10-20 anys s'està convertint en un anacronisme avui. Hi ha una opció més eficaç i, en alguns llocs, l'única possible per supervisar una xarxa interna: utilitzant protocols de flux, que es van dissenyar originalment per buscar problemes de xarxa (resolució de problemes), però que amb el temps es van transformar en una eina de seguretat molt interessant. Parlarem de quins protocols de flux hi ha i quins són millors per detectar atacs a la xarxa, on és millor implementar el control de flux, què cal buscar quan es desplega aquest esquema i fins i tot com "aixecar" tot això en equips domèstics. dins l'àmbit d'aplicació d'aquest article.
No em detendré en la pregunta "Per què és necessària la vigilància de la seguretat de la infraestructura interna?" La resposta sembla clara. Però si, tanmateix, voldries assegurar-te una vegada més que avui no pots viure sense ell, un vídeo breu sobre com podeu penetrar en una xarxa corporativa protegida per un tallafoc de 17 maneres. Per tant, assumirem que entenem que el seguiment intern és una cosa necessària i només queda entendre com es pot organitzar.
Destacaria tres fonts de dades clau per supervisar la infraestructura a nivell de xarxa:
- trànsit "brut" que capturem i enviem per a l'anàlisi a determinats sistemes d'anàlisi,
- esdeveniments de dispositius de xarxa pels quals passa el trànsit,
- informació de trànsit rebuda mitjançant un dels protocols de flux.
La captura de trànsit brut és l'opció més popular entre els especialistes en seguretat, perquè històricament va aparèixer i va ser la primera. Els sistemes convencionals de detecció d'intrusions a la xarxa (el primer sistema comercial de detecció d'intrusions va ser NetRanger de Wheel Group, comprat el 1998 per Cisco) es dedicaven precisament a la captura de paquets (i sessions posteriors) en què es buscaven certes signatures ("regles decisives" en terminologia FSTEC), atacs de senyalització. Per descomptat, podeu analitzar el trànsit en brut no només utilitzant IDS, sinó també utilitzant altres eines (per exemple, Wireshark, tcpdum o la funcionalitat NBAR2 a Cisco IOS), però normalment no tenen la base de coneixement que distingeix una eina de seguretat de la informació d'una normal. eina informàtica.
Per tant, sistemes de detecció d'atacs. El mètode més antic i popular per detectar atacs a la xarxa, que fa una bona feina al perímetre (sigui el que sigui: corporatiu, centre de dades, segment, etc.), però falla a les xarxes modernes commutades i definides per programari. En el cas d'una xarxa construïda sobre la base d'interruptors convencionals, la infraestructura de sensors de detecció d'atacs es fa massa gran: haureu d'instal·lar un sensor per a cada connexió al node en què voleu controlar els atacs. Qualsevol fabricant, per descomptat, estarà encantat de vendre't centenars i milers de sensors, però crec que el teu pressupost no pot suportar aquestes despeses. Puc dir que fins i tot a Cisco (i som els desenvolupadors de NGIPS) no podríem fer això, tot i que sembla que el tema del preu està davant nostre. No m'hauria de suportar, és la nostra pròpia decisió. A més, sorgeix la pregunta, com connectar el sensor en aquesta versió? Al buit? Què passa si el sensor mateix falla? Necessites un mòdul de bypass al sensor? Utilitzeu separadors (toc)? Tot això fa que la solució sigui més cara i la fa inassequible per a una empresa de qualsevol mida.
Podeu provar de "penjar" el sensor en un port SPAN/RSPAN/ERSPAN i dirigir-hi el trànsit des dels ports de commutació necessaris. Aquesta opció elimina parcialment el problema descrit al paràgraf anterior, però en planteja un altre - el port SPAN no pot acceptar absolutament tot el trànsit que se li enviarà - no tindrà prou amplada de banda. Haureu de sacrificar alguna cosa. O deixeu alguns dels nodes sense control (aleshores primer cal que els prioritzeu) o no envieu tot el trànsit des del node, sinó només un determinat tipus. En qualsevol cas, podem perdre alguns atacs. A més, el port SPAN es pot utilitzar per a altres necessitats. Com a resultat, haurem de revisar la topologia de xarxa existent i, possiblement, fer-hi ajustaments per tal de cobrir al màxim la vostra xarxa amb el nombre de sensors que teniu (i coordinar-ho amb TI).
Què passa si la vostra xarxa utilitza rutes asimètriques? Què passa si heu implementat o teniu previst implementar SDN? Què passa si necessiteu supervisar màquines virtualitzades o contenidors el trànsit dels quals no arriba a l'interruptor físic? Són preguntes que als venedors tradicionals d'IDS no els agraden perquè no saben com respondre-les. Potser et persuadiran que totes aquestes tecnologies de moda són bombo i que no ho necessites. Potser parlaran de la necessitat de començar petit. O potser us diran que heu de posar un potent trillador al centre de la xarxa i dirigir-hi tot el trànsit mitjançant equilibradors. Sigui quina sigui l'opció que us ofereixi, heu d'entendre clarament com us convé. I només després d'això, prendre una decisió sobre l'elecció d'un enfocament per supervisar la seguretat de la informació de la infraestructura de xarxa. Tornant a la captura de paquets, vull dir que aquest mètode continua sent molt popular i important, però el seu objectiu principal és el control de fronteres; límits entre la vostra organització i Internet, límits entre el centre de dades i la resta de la xarxa, límits entre el sistema de control de processos i el segment corporatiu. En aquests llocs, els IDS/IPS clàssics encara tenen dret a existir i a afrontar bé les seves tasques.
Passem a la segona opció. L'anàlisi d'esdeveniments procedents de dispositius de xarxa també es pot utilitzar per a la detecció d'atacs, però no com a mecanisme principal, ja que permet detectar només una petita classe d'intrusions. A més, és inherent a certa reactivitat: primer s'ha de produir l'atac, després ha de ser gravat per un dispositiu de xarxa, que d'una manera o altra indicarà un problema amb la seguretat de la informació. Hi ha diverses maneres d'aquest tipus. Pot ser syslog, RMON o SNMP. Els dos últims protocols de monitorització de la xarxa en el context de la seguretat de la informació només s'utilitzen si necessitem detectar un atac DoS al propi equip de xarxa, ja que mitjançant RMON i SNMP és possible, per exemple, controlar la càrrega a la central del dispositiu. processador o les seves interfícies. Aquest és un dels "més barats" (tothom té syslog o SNMP), però també el més ineficaç de tots els mètodes de control de la seguretat de la informació de la infraestructura interna: molts atacs simplement s'hi oculten. Per descomptat, no s'han de descuidar, i la mateixa anàlisi de syslog us ajuda a identificar oportunament els canvis en la configuració del propi dispositiu, el seu compromís, però no és molt adequat per detectar atacs a tota la xarxa.
La tercera opció és analitzar la informació sobre el trànsit que passa per un dispositiu que admet un dels diversos protocols de flux. En aquest cas, independentment del protocol, la infraestructura de threading consta necessàriament de tres components:
- Generació o exportació de flux. Aquesta funció normalment s'assigna a un encaminador, commutador o un altre dispositiu de xarxa que, en passar el trànsit de xarxa per si mateix, permet extreure'n paràmetres clau, que després es transmeten al mòdul de recollida. Per exemple, Cisco admet el protocol Netflow no només en encaminadors i commutadors, inclosos els virtuals i industrials, sinó també en controladors sense fil, tallafocs i fins i tot servidors.
- Flux de recollida. Tenint en compte que una xarxa moderna acostuma a tenir més d'un dispositiu de xarxa, sorgeix el problema de la recollida i consolidació de fluxos, que es resol mitjançant els anomenats col·lectors, que processen els fluxos rebuts i després els transmeten per analitzar-los.
- Anàlisi de flux L'analitzador assumeix la tasca intel·lectual principal i, aplicant diversos algorismes als fluxos, en treu certes conclusions. Per exemple, com a part d'una funció informàtica, aquest analitzador pot identificar colls d'ampolla de la xarxa o analitzar el perfil de càrrega de trànsit per a una millor optimització de la xarxa. I per a la seguretat de la informació, aquest analitzador pot detectar fuites de dades, la propagació de codi maliciós o atacs DoS.
No us penseu que aquesta arquitectura de tres nivells és massa complicada: totes les altres opcions (excepte, potser, els sistemes de monitorització de xarxa que funcionen amb SNMP i RMON) també funcionen d'acord amb ella. Disposem d'un generador de dades per analitzar, que pot ser un dispositiu de xarxa o un sensor autònom. Disposem d'un sistema de recollida d'alarmes i un sistema de gestió de tota la infraestructura de monitoratge. Els dos darrers components es poden combinar dins d'un sol node, però en xarxes més o menys grans solen estar distribuïts en almenys dos dispositius per tal de garantir l'escalabilitat i la fiabilitat.
A diferència de l'anàlisi de paquets, que es basa en l'estudi de les dades de la capçalera i del cos de cada paquet i les sessions en què consisteix, l'anàlisi de flux es basa en la recollida de metadades sobre el trànsit de xarxa. Quan, quant, des d'on i on, com... aquestes són les preguntes que respon l'anàlisi de la telemetria de xarxa mitjançant diversos protocols de flux. Inicialment, s'utilitzaven per analitzar estadístiques i trobar problemes informàtics a la xarxa, però després, a mesura que es desenvolupaven els mecanismes analítics, es va poder aplicar a la mateixa telemetria amb finalitats de seguretat. Val la pena assenyalar de nou que l'anàlisi de flux no substitueix ni substitueix la captura de paquets. Cadascun d'aquests mètodes té la seva pròpia àrea d'aplicació. Però en el context d'aquest article, és l'anàlisi de flux el que s'adapta millor per controlar la infraestructura interna. Teniu dispositius de xarxa (tant si funcionen en un paradigma definit per programari o segons regles estàtiques) que un atac no pot evitar. Pot obviar un sensor IDS clàssic, però un dispositiu de xarxa que admeti el protocol de flux no. Aquest és l'avantatge d'aquest mètode.
D'altra banda, si necessiteu proves per a l'aplicació de la llei o el vostre propi equip d'investigació d'incidents, no podeu prescindir de la captura de paquets: la telemetria de xarxa no és una còpia del trànsit que es pugui utilitzar per recollir proves; és necessari per a una ràpida detecció i presa de decisions en l'àmbit de la seguretat de la informació. D'altra banda, mitjançant l'anàlisi de telemetria, podeu "escriure" no tot el trànsit de xarxa (si és que Cisco tracta els centres de dades :-), sinó només el que està implicat en l'atac. Les eines d'anàlisi de telemetria en aquest sentit complementaran bé els mecanismes de captura de paquets tradicionals, donant ordres per a la captura i l'emmagatzematge selectius. En cas contrari, haureu de disposar d'una infraestructura d'emmagatzematge colossal.
Imaginem una xarxa que funciona a una velocitat de 250 Mbit/s. Si voleu emmagatzemar tot aquest volum, necessitareu 31 MB d'emmagatzematge per a un segon de transmissió de trànsit, 1,8 GB durant un minut, 108 GB durant una hora i 2,6 TB durant un dia. Per emmagatzemar dades diàries d'una xarxa amb una amplada de banda de 10 Gbit/s, necessitareu 108 TB d'emmagatzematge. Però alguns reguladors requereixen emmagatzemar dades de seguretat durant anys... L'enregistrament a demanda, que l'anàlisi de flux us ajuda a implementar, ajuda a reduir aquests valors en ordres de magnitud. Per cert, si parlem de la relació entre el volum de dades de telemetria de xarxa enregistrades i la captura de dades completa, llavors és d'aproximadament 1 a 500. Per als mateixos valors donats anteriorment, emmagatzemar una transcripció completa de tot el trànsit diari. serà de 5 i 216 GB, respectivament (fins i tot el podeu gravar en una unitat flaix normal).
Si per a les eines per analitzar dades de xarxa en brut, el mètode de captura és gairebé el mateix d'un proveïdor a un altre, aleshores en el cas de l'anàlisi de flux la situació és diferent. Hi ha diverses opcions per als protocols de flux, les diferències en què cal conèixer en el context de la seguretat. El més popular és el protocol Netflow desenvolupat per Cisco. Hi ha diverses versions d'aquest protocol, que es diferencien per les seves capacitats i la quantitat d'informació de trànsit registrada. La versió actual és la novena (Netflow v9), sobre la base de la qual es va desenvolupar l'estàndard de la indústria Netflow v10, també conegut com IPFIX. Avui dia, la majoria de proveïdors de xarxa admeten Netflow o IPFIX als seus equips. Però hi ha altres opcions per als protocols de flux: sFlow, jFlow, cFlow, rFlow, NetStream, etc., dels quals sFlow és el més popular. Aquest tipus és el que sovint és compatible amb els fabricants nacionals d'equips de xarxa a causa de la seva facilitat d'implementació. Quines són les diferències clau entre Netflow, que s'ha convertit en un estàndard de facto, i sFlow? En destacaria algunes de claus. En primer lloc, Netflow té camps personalitzables per l'usuari a diferència dels camps fixos a sFlow. I en segon lloc, i això és el més important en el nostre cas, sFlow recull l'anomenada telemetria mostrejada; en contrast amb el sense mostrejar per a Netflow i IPFIX. Quina diferència hi ha entre ells?
Imagina que decideixes llegir el llibre "” dels meus companys - Gary McIntyre, Joseph Munitz i Nadem Alfardan (pots descarregar-te part del llibre des de l'enllaç). Tens tres opcions per assolir el teu objectiu: llegir el llibre sencer, repassar-lo, aturar-te a cada 10a o 20a pàgina, o intentar trobar una revisió dels conceptes clau en un bloc o servei com SmartReading. Per tant, la telemetria sense mostrejar està llegint cada "pàgina" del trànsit de xarxa, és a dir, analitzant les metadades de cada paquet. La telemetria mostrada és l'estudi selectiu del trànsit amb l'esperança que les mostres seleccionades continguin el que necessiteu. Depenent de la velocitat del canal, la telemetria mostrada s'enviarà per a l'anàlisi cada paquet 64, 200, 500, 1000, 2000 o fins i tot 10000.
En el context de la vigilància de la seguretat de la informació, això significa que la telemetria mostrada és molt adequada per detectar atacs DDoS, escanejar i difondre codi maliciós, però pot perdre atacs atòmics o multipaquets que no s'inclouen a la mostra enviada per a l'anàlisi. La telemetria sense mostrejar no té aquests inconvenients. Amb això, el ventall d'atacs detectats és molt més ampli. Aquí hi ha una breu llista d'esdeveniments que es poden detectar mitjançant eines d'anàlisi de telemetria de xarxa.
Per descomptat, algun analitzador de Netflow de codi obert no us permetrà fer-ho, ja que la seva tasca principal és recollir la telemetria i fer-ne una anàlisi bàsica des del punt de vista informàtic. Per identificar les amenaces de seguretat de la informació en funció del flux, és necessari equipar l'analitzador amb diversos motors i algorismes, que identificaran problemes de ciberseguretat a partir de camps de Netflow estàndard o personalitzats, enriquiran les dades estàndard amb dades externes de diverses fonts d'intel·ligència d'amenaces, etc.
Per tant, si teniu una opció, trieu Netflow o IPFIX. Però fins i tot si el vostre equip només funciona amb sFlow, com els fabricants nacionals, fins i tot en aquest cas us podeu beneficiar en un context de seguretat.
A l'estiu del 2019, vaig analitzar les capacitats que tenen els fabricants de maquinari de xarxa russos i tots ells, excepte NSG, Polygon i Craftway, van anunciar suport per a sFlow (almenys Zelax, Natex, Eltex, QTech, Rusteleteh).
La següent pregunta que trobareu és on implementar el suport de flux amb finalitats de seguretat? De fet, la pregunta no es planteja del tot correctament. Els equips moderns gairebé sempre admeten protocols de flux. Per tant, reformularia la pregunta d'una altra manera: on és més efectiu recollir la telemetria des del punt de vista de la seguretat? La resposta serà força òbvia: al nivell d'accés, on veureu el 100% de tot el trànsit, on tindreu informació detallada sobre els amfitrions (MAC, VLAN, identificador d'interfície), on fins i tot podeu controlar el trànsit P2P entre amfitrions, que és fonamental per escanejar la detecció i la distribució de codi maliciós. Al nivell bàsic, és possible que simplement no vegeu part del trànsit, però al nivell del perímetre, veureu una quarta part de tot el trànsit de la vostra xarxa. Però si per algun motiu teniu dispositius estrangers a la vostra xarxa que permeten als atacants "entrar i sortir" sense passar per alt el perímetre, aleshores analitzar la telemetria des d'aquest no us donarà res. Per tant, per a una cobertura màxima, es recomana habilitar la recollida de telemetria al nivell d'accés. Al mateix temps, val la pena assenyalar que encara que parlem de virtualització o contenidors, el suport de flux també es troba sovint als commutadors virtuals moderns, la qual cosa permet controlar-hi també el trànsit.
Però com que he plantejat el tema, he de respondre a la pregunta: què passa si l'equip, físic o virtual, no admet protocols de flux? O està prohibida la seva inclusió (per exemple, en segments industrials per garantir la fiabilitat)? O activar-lo comporta una càrrega elevada de la CPU (això passa amb el maquinari més antic)? Per solucionar aquest problema, hi ha sensors virtuals especialitzats (sensors de flux), que són essencialment divisors ordinaris que passen el trànsit per ells mateixos i el transmeten en forma de flux al mòdul de recollida. És cert que en aquest cas tenim tots els problemes dels quals hem parlat anteriorment en relació a les eines de captura de paquets. És a dir, cal entendre no només els avantatges de la tecnologia d'anàlisi de flux, sinó també les seves limitacions.
Un altre punt que és important recordar quan es parla d'eines d'anàlisi de flux. Si en relació als mitjans convencionals de generació d'esdeveniments de seguretat utilitzem la mètrica EPS (esdeveniment per segon), aleshores aquest indicador no és aplicable a l'anàlisi de telemetria; es substitueix per FPS (flux per segon). Com en el cas de l'EPS, no es pot calcular per endavant, però es pot estimar el nombre aproximat de fils que genera un determinat dispositiu en funció de la seva tasca. Podeu trobar taules a Internet amb valors aproximats per a diferents tipus de dispositius i condicions empresarials, que us permetran estimar quines llicències necessiteu per a les eines d'anàlisi i quina serà la seva arquitectura? El fet és que el sensor IDS està limitat per un cert ample de banda que pot "estirar", i el col·lector de flux té les seves pròpies limitacions que s'han d'entendre. Per tant, a les grans xarxes distribuïdes geogràficament hi acostumen a haver diversos col·lectors. Quan vaig descriure , ja he donat el nombre dels nostres col·leccionistes: n'hi ha 21, i això és per a una xarxa repartida pels cinc continents i amb uns mig milió de dispositius actius.
Utilitzem la nostra pròpia solució com a sistema de monitorització de Netflow , que està específicament enfocat a resoldre problemes de seguretat. Té molts motors integrats per detectar activitats anòmales, sospitoses i clarament malicioses, que us permeten detectar una àmplia gamma d'amenaces diferents, des de la criptomineria fins a filtracions d'informació, des de la propagació de codi maliciós fins al frau. Com la majoria dels analitzadors de flux, Stealthwatch es construeix segons un esquema de tres nivells (generador - col·lector - analitzador), però es complementa amb una sèrie de característiques interessants que són importants en el context del material considerat. En primer lloc, s'integra amb solucions de captura de paquets (com ara Cisco Security Packet Analyzer), que us permeten registrar sessions de xarxa seleccionades per a una investigació i anàlisi en profunditat posterior. En segon lloc, específicament per ampliar les tasques de seguretat, hem desenvolupat un protocol especial nvzFlow, que permet "difondre" l'activitat de les aplicacions als nodes finals (servidors, estacions de treball, etc.) a la telemetria i transmetre-la al col·lector per a una anàlisi posterior. Si en la seva versió original Stealthwatch funciona amb qualsevol protocol de flux (sFlow, rFlow, Netflow, IPFIX, cFlow, jFlow, NetStream) a nivell de xarxa, el suport de nvzFlow permet la correlació de dades també a nivell de node, per tant. augmentant l'eficiència de tot el sistema i veient més atacs que els analitzadors de flux de xarxa convencionals.
És evident que quan es parla de sistemes d'anàlisi Netflow des del punt de vista de la seguretat, el mercat no es limita a una única solució de Cisco. Podeu utilitzar solucions comercials i gratuïtes o de programari compartit. És força estrany si cito les solucions dels competidors com a exemples al bloc de Cisco, així que diré algunes paraules sobre com es pot analitzar la telemetria de xarxa mitjançant dues eines populars, similars en nom, però encara diferents: SiLK i ELK.
SiLK és un conjunt d'eines (el System for Internet-Level Knowledge) per a l'anàlisi del trànsit, desenvolupat pel nord-americà CERT/CC i que admet, en el context de l'article d'avui, Netflow (5è i 9è, les versions més populars), IPFIX. i sFlow i utilitzant diverses utilitats (rwfilter, rwcount, rwflowpack, etc.) per realitzar diverses operacions sobre la telemetria de xarxa per tal de detectar indicis d'accions no autoritzades en ella. Però hi ha un parell de punts importants a destacar. SiLK és una eina de línia d'ordres que realitza anàlisis en línia introduint ordres com aquesta (detecció de paquets ICMP de més de 200 bytes):
rwfilter --flowtypes=all/all --proto=1 --bytes-per-packet=200- --pass=stdout | rwrwcut --fields=sIP,dIP,iType,iCode --num-recs=15
no gaire còmode. Podeu utilitzar la GUI iSiLK, però no us farà la vida molt més fàcil, només resoldrà la funció de visualització i no substituirà l'analista. I aquest és el segon punt. A diferència de les solucions comercials, que ja disposen d'una sòlida base analítica, algorismes de detecció d'anomalies, flux de treball corresponent, etc., en el cas de SiLK tot això ho hauràs de fer tu mateix, la qual cosa requerirà competències lleugerament diferents de les de l'ús ja preparat. eines per utilitzar. Això no és ni bo ni dolent: aquesta és una característica de gairebé qualsevol eina gratuïta que suposa que sabeu què fer, i només us ajudarà amb això (les eines comercials depenen menys de les competències dels seus usuaris, tot i que també assumeixen que els analistes entenguin almenys els fonaments bàsics de les investigacions i la supervisió de la xarxa). Però tornem a la seda. El cicle de treball de l'analista amb ell és el següent:
- Formulació d'una hipòtesi. Hem d'entendre què buscarem dins de la telemetria de xarxa, conèixer els atributs únics pels quals identificarem certes anomalies o amenaces.
- Construir un model. Un cop formulada una hipòtesi, la programem utilitzant el mateix Python, shell o altres eines no incloses a SiLK.
- Prova. Ara ve el torn de comprovar la correcció de la nostra hipòtesi, que es confirma o refuta mitjançant les utilitats SiLK que comencen per 'rw', 'set', 'bag'.
- Anàlisi de dades reals. En el funcionament industrial, SiLK ens ajuda a identificar alguna cosa i l'analista ha de respondre a les preguntes "Hem trobat el que esperàvem?", "Això correspon a la nostra hipòtesi?", "Com reduir el nombre de falsos positius?", "Com per millorar el nivell de reconeixement? etcètera.
- Millora. En l'etapa final, millorem el que es va fer abans: creem plantilles, millorem i optimitzem el codi, reformulem i aclarim la hipòtesi, etc.
Aquest cicle també serà aplicable a Cisco Stealthwatch, només el darrer automatitza al màxim aquests cinc passos, reduint el nombre d'errors dels analistes i augmentant l'eficiència de la detecció d'incidents. Per exemple, a SiLK podeu enriquir les estadístiques de xarxa amb dades externes sobre IP malicioses mitjançant scripts escrits a mà, i a Cisco Stealthwatch és una funció integrada que mostra immediatament una alarma si el trànsit de xarxa conté interaccions amb adreces IP de la llista negra.
Si pugeu més amunt la piràmide "pagada" per al programari d'anàlisi de flux, després del SiLK absolutament gratuït hi haurà un ELK de shareware, format per tres components clau: Elasticsearch (indexació, cerca i anàlisi de dades), Logstash (entrada/sortida de dades). ) i Kibana (visualització). A diferència de SiLK, on has d'escriure-ho tot tu mateix, ELK ja té moltes biblioteques/mòduls preparats (alguns de pagament, altres no) que automatitzen l'anàlisi de la telemetria de la xarxa. Per exemple, el filtre GeoIP de Logstash us permet associar adreces IP supervisades amb la seva ubicació geogràfica (Stealthwatch té aquesta funció integrada).
ELK també té una comunitat bastant gran que està completant els components que falten per a aquesta solució de monitorització. Per exemple, per treballar amb Netflow, IPFIX i sFlow podeu utilitzar el mòdul , si no esteu satisfet amb el mòdul Logstash Netflow, que només admet Netflow.
Tot i que ofereix més eficiència a l'hora de recopilar el flux i cercar-hi, actualment ELK no té una anàlisi integrada rica per detectar anomalies i amenaces en la telemetria de la xarxa. És a dir, seguint el cicle de vida descrit anteriorment, haureu de descriure de manera independent els models de violació i després utilitzar-los al sistema de combat (no hi ha models integrats).
Hi ha, per descomptat, extensions més sofisticades per a ELK, que ja contenen alguns models per detectar anomalies en la telemetria de la xarxa, però aquestes extensions costen diners i aquí la pregunta és si el joc val la pena: escriu tu mateix un model similar, compra-lo. implementació per a la vostra eina de supervisió o compreu una solució ja feta de la classe d'anàlisi de trànsit de xarxa.
En general, no vull entrar en el debat que és millor gastar diners i comprar una solució ja feta per controlar anomalies i amenaces en la telemetria de xarxa (per exemple, Cisco Stealthwatch) o esbrinar-ho tu mateix i personalitzar-ho. SiLK, ELK o nfdump o OSU Flow Tools per a cada nova amenaça (estic parlant de les dues últimes l'última vegada)? Cadascú tria per si mateix i cadascú té els seus motius per triar qualsevol de les dues opcions. Només volia demostrar que la telemetria de xarxa és una eina molt important per garantir la seguretat de la xarxa de la vostra infraestructura interna i que no l'has de descuidar, per no unir-te a la llista d'empreses el nom de les quals s'esmenta als mitjans juntament amb els epítets " piratejat", "no compleix els requisits de seguretat de la informació", "no pensa en la seguretat de les seves dades i les dades dels clients".
Per resumir, m'agradaria enumerar els consells clau que hauríeu de seguir quan creeu un control de seguretat de la informació de la vostra infraestructura interna:
- No et limites només al perímetre! Utilitzeu (i trieu) la infraestructura de xarxa no només per traslladar el trànsit del punt A al punt B, sinó també per abordar problemes de ciberseguretat.
- Estudieu els mecanismes de control de seguretat de la informació existents al vostre equip de xarxa i utilitzeu-los.
- Per a la supervisió interna, doneu preferència a l'anàlisi de telemetria: us permet detectar fins a un 80-90% de tots els incidents de seguretat de la informació de la xarxa, alhora que feu el que és impossible quan captureu paquets de xarxa i estalvieu espai per emmagatzemar tots els esdeveniments de seguretat de la informació.
- Per controlar els fluxos, utilitzeu Netflow v9 o IPFIX: proporcionen més informació en un context de seguretat i us permeten supervisar no només IPv4, sinó també IPv6, MPLS, etc.
- Utilitzeu un protocol de flux sense mostrejar: proporciona més informació per detectar amenaces. Per exemple, Netflow o IPFIX.
- Comproveu la càrrega del vostre equip de xarxa; és possible que també no pugui gestionar el protocol de flux. A continuació, considereu utilitzar sensors virtuals o Netflow Generation Appliance.
- Implementeu el control en primer lloc al nivell d'accés: això us donarà l'oportunitat de veure el 100% de tot el trànsit.
- Si no teniu cap opció i utilitzeu un equip de xarxa rus, trieu-ne un que admeti protocols de flux o que tingui ports SPAN/RSPAN.
- Combina sistemes de detecció/prevenció d'intrusions/atacs a les vores i sistemes d'anàlisi de flux a la xarxa interna (inclosos als núvols).
Pel que fa a l'últim consell, m'agradaria donar una il·lustració que ja he donat abans. Veu que si abans el servei de seguretat de la informació de Cisco construïa gairebé íntegrament el seu sistema de monitorització de la seguretat de la informació sobre la base de sistemes de detecció d'intrusions i mètodes de signatura, ara només representen el 20% dels incidents. Un altre 20% recau en els sistemes d'anàlisi de flux, la qual cosa suggereix que aquestes solucions no són un caprici, sinó una eina real en les activitats dels serveis de seguretat de la informació d'una empresa moderna. A més, teniu el més important per a la seva implementació: la infraestructura de xarxa, les inversions en les quals es poden protegir encara més assignant funcions de control de seguretat de la informació a la xarxa.
Concretament no vaig tocar el tema de respondre a anomalies o amenaces identificades en els fluxos de xarxa, però crec que ja està clar que el monitoratge no ha d'acabar només amb la detecció d'una amenaça. Ha d'anar seguit d'una resposta i preferiblement en mode automàtic o automatitzat. Però aquest és un tema per a un article separat.
Informació Addicional:
PS. Si us resulta més fàcil escoltar tot el que s'ha escrit més amunt, podeu veure la presentació d'una hora que va ser la base d'aquesta nota.
Font: www.habr.com