Cuando se trata de monitorear la seguridad de una red interna corporativa o departamental, muchos lo asocian con controlar las fugas de información e implementar soluciones DLP. Y si intenta aclarar la pregunta y pregunta cómo se detectan ataques en la red interna, la respuesta, por regla general, será una mención de los sistemas de detección de intrusos (IDS). Y lo que hace 10 o 20 años era la única opción se está convirtiendo hoy en un anacronismo. Existe una opción más eficaz y, en algunos lugares, la única posible para monitorear una red interna: utilizar protocolos de flujo, que originalmente fueron diseñados para buscar problemas de red (solución de problemas), pero que con el tiempo se transformaron en una herramienta de seguridad muy interesante. Hablaremos sobre qué protocolos de flujo existen y cuáles son mejores para detectar ataques a la red, dónde es mejor implementar el monitoreo de flujo, qué buscar al implementar un esquema de este tipo e incluso cómo "levantar" todo esto en equipos domésticos. dentro del alcance de este artículo.
No me detendré en la pregunta "¿Por qué es necesaria la supervisión de la seguridad de la infraestructura interna?" La respuesta parece ser clara. Pero si aún así quieres asegurarte una vez más de que hoy no puedes vivir sin él, un breve vídeo sobre cómo penetrar una red corporativa protegida por un firewall de 17 maneras. Por tanto, asumiremos que entendemos que el seguimiento interno es algo necesario y sólo queda entender cómo se puede organizar.
Destacaría tres fuentes de datos clave para monitorear la infraestructura a nivel de red:
- Tráfico "bruto" que capturamos y enviamos para su análisis a ciertos sistemas de análisis,
- eventos de dispositivos de red a través de los cuales pasa el tráfico,
- información de tráfico recibida a través de uno de los protocolos de flujo.
La captura de tráfico sin procesar es la opción más popular entre los especialistas en seguridad, porque apareció históricamente y fue la primera. Los sistemas convencionales de detección de intrusiones en la red (el primer sistema comercial de detección de intrusiones fue NetRanger del Wheel Group, adquirido en 1998 por Cisco) se dedicaban precisamente a capturar paquetes (y sesiones posteriores) en los que se buscaban determinadas firmas (“reglas decisivas” en Terminología FSTEC), ataques de señalización. Por supuesto, es posible analizar el tráfico sin procesar no solo utilizando IDS, sino también con otras herramientas (por ejemplo, Wireshark, tcpdum o la funcionalidad NBAR2 en Cisco IOS), pero generalmente carecen de la base de conocimientos que distingue una herramienta de seguridad de la información de una normal. Herramienta informática.
Entonces, sistemas de detección de ataques. El método más antiguo y popular para detectar ataques a la red, que hace un buen trabajo en el perímetro (sin importar qué: corporativo, centro de datos, segmento, etc.), pero falla en las redes modernas conmutadas y definidas por software. En el caso de una red construida sobre la base de conmutadores convencionales, la infraestructura de sensores de detección de ataques se vuelve demasiado grande: deberá instalar un sensor en cada conexión al nodo en el que desea monitorear los ataques. Cualquier fabricante, por supuesto, estará encantado de venderle cientos y miles de sensores, pero creo que su presupuesto no puede cubrir esos gastos. Puedo decir que incluso en Cisco (y somos los desarrolladores de NGIPS) no pudimos hacer esto, aunque parecería que la cuestión del precio está ante nosotros. No debería soportarlo, es nuestra propia decisión. Además, surge la pregunta, ¿cómo conectar el sensor en esta versión? ¿En la brecha? ¿Qué pasa si el sensor falla? ¿Requiere un módulo de derivación en el sensor? ¿Usar divisores (toque)? Todo esto encarece la solución y la hace inasequible para una empresa de cualquier tamaño.
Puede intentar "colgar" el sensor en un puerto SPAN/RSPAN/ERSPAN y dirigir el tráfico desde los puertos del switch requeridos hacia él. Esta opción elimina parcialmente el problema descrito en el párrafo anterior, pero plantea otro: el puerto SPAN no puede aceptar absolutamente todo el tráfico que se le enviará, no tendrá suficiente ancho de banda. Tendrás que sacrificar algo. Deje algunos de los nodos sin monitoreo (entonces primero debe priorizarlos) o no envíe todo el tráfico desde el nodo, sino solo un tipo determinado. En cualquier caso, es posible que nos perdamos algunos ataques. Además, el puerto SPAN se puede utilizar para otras necesidades. Como resultado, tendremos que revisar la topología de la red existente y posiblemente hacerle ajustes para cubrir su red al máximo con la cantidad de sensores que tiene (y coordinar esto con TI).
¿Qué pasa si su red utiliza rutas asimétricas? ¿Qué pasa si ha implementado o planea implementar SDN? ¿Qué sucede si necesita monitorear máquinas virtualizadas o contenedores cuyo tráfico no llega en absoluto al conmutador físico? Éstas son preguntas que a los proveedores tradicionales de IDS no les gustan porque no saben cómo responderlas. Quizás te convenzan de que todas estas tecnologías de moda son una exageración y no las necesitas. Quizás hablen de la necesidad de empezar poco a poco. O tal vez digan que es necesario colocar una trilladora potente en el centro de la red y dirigir todo el tráfico hacia ella mediante equilibradores. Cualquiera que sea la opción que se le ofrezca, debe comprender claramente cómo se adapta a sus necesidades. Y solo después de eso, tome la decisión de elegir un enfoque para monitorear la seguridad de la información de la infraestructura de la red. Volviendo a la captura de paquetes, quiero decir que este método sigue siendo muy popular e importante, pero su objetivo principal es el control de fronteras; límites entre su organización e Internet, límites entre el centro de datos y el resto de la red, límites entre el sistema de control de procesos y el segmento corporativo. En estos lugares, los IDS/IPS clásicos todavía tienen derecho a existir y cumplir bien con sus tareas.
Pasemos a la segunda opción. El análisis de eventos procedentes de dispositivos de red también se puede utilizar con fines de detección de ataques, pero no como mecanismo principal, ya que permite detectar sólo una pequeña clase de intrusiones. Además, es inherente a cierta reactividad: el ataque primero debe ocurrir y luego debe ser registrado por un dispositivo de red, lo que de una forma u otra indicará un problema con la seguridad de la información. Hay varias formas de hacerlo. Podría ser syslog, RMON o SNMP. Los dos últimos protocolos de monitoreo de red en el contexto de la seguridad de la información se utilizan solo si necesitamos detectar un ataque DoS en el propio equipo de red, ya que usando RMON y SNMP es posible, por ejemplo, monitorear la carga en la central del dispositivo. procesador o sus interfaces. Este es uno de los métodos "más baratos" (todos tienen syslog o SNMP), pero también el más ineficaz de todos los métodos para monitorear la seguridad de la información de la infraestructura interna: muchos ataques simplemente se le ocultan. Por supuesto, no deben descuidarse, y el mismo análisis de syslog ayuda a identificar oportunamente cambios en la configuración del dispositivo en sí, su peligro, pero no es muy adecuado para detectar ataques en toda la red.
La tercera opción es analizar información sobre el tráfico que pasa a través de un dispositivo que admita uno de varios protocolos de flujo. En este caso, independientemente del protocolo, la infraestructura de subprocesos consta necesariamente de tres componentes:
- Generación o exportación de flujo. Esta función generalmente se asigna a un enrutador, conmutador u otro dispositivo de red que, al pasar el tráfico de red a través de sí mismo, le permite extraer parámetros clave del mismo, que luego se transmiten al módulo de recopilación. Por ejemplo, Cisco admite el protocolo Netflow no solo en enrutadores y conmutadores, incluidos los virtuales e industriales, sino también en controladores inalámbricos, firewalls e incluso servidores.
- Flujo de recogida. Teniendo en cuenta que una red moderna suele tener más de un dispositivo de red, surge el problema de recopilar y consolidar flujos, que se resuelve mediante los llamados recolectores, que procesan los flujos recibidos y luego los transmiten para su análisis.
- Análisis de flujo El analizador asume la principal tarea intelectual y, aplicando varios algoritmos a los flujos, saca ciertas conclusiones. Por ejemplo, como parte de una función de TI, un analizador de este tipo puede identificar cuellos de botella en la red o analizar el perfil de carga de tráfico para una mayor optimización de la red. Y para la seguridad de la información, un analizador de este tipo puede detectar fugas de datos, la propagación de códigos maliciosos o ataques DoS.
No crea que esta arquitectura de tres niveles es demasiado complicada: todas las demás opciones (excepto, quizás, los sistemas de monitoreo de red que funcionan con SNMP y RMON) también funcionan de acuerdo con ella. Contamos con un generador de datos para análisis, que puede ser un dispositivo de red o un sensor autónomo. Disponemos de un sistema de recogida de alarmas y un sistema de gestión de toda la infraestructura de monitorización. Los dos últimos componentes se pueden combinar dentro de un único nodo, pero en redes más o menos grandes suelen estar repartidos en al menos dos dispositivos para garantizar escalabilidad y fiabilidad.
A diferencia del análisis de paquetes, que se basa en el estudio de los datos del encabezado y el cuerpo de cada paquete y las sesiones que lo componen, el análisis de flujo se basa en la recopilación de metadatos sobre el tráfico de la red. Cuándo, cuánto, desde dónde y dónde, cómo… estas son las preguntas que responde el análisis de la telemetría de red mediante diversos protocolos de flujo. Inicialmente, se utilizaron para analizar estadísticas y encontrar problemas de TI en la red, pero luego, a medida que se desarrollaron mecanismos analíticos, fue posible aplicarlos a la misma telemetría por motivos de seguridad. Vale la pena señalar nuevamente que el análisis de flujo no reemplaza ni reemplaza la captura de paquetes. Cada uno de estos métodos tiene su propia área de aplicación. Pero en el contexto de este artículo, el análisis de flujo es el más adecuado para monitorear la infraestructura interna. Tiene dispositivos de red (ya sea que operen en un paradigma definido por software o según reglas estáticas) que un ataque no puede eludir. Puede omitir un sensor IDS clásico, pero un dispositivo de red que admita el protocolo de flujo no puede. Ésta es la ventaja de este método.
Por otro lado, si necesita pruebas para las autoridades o su propio equipo de investigación de incidentes, no puede prescindir de la captura de paquetes: la telemetría de red no es una copia del tráfico que pueda utilizarse para recopilar pruebas; es necesario para una rápida detección y toma de decisiones en el campo de la seguridad de la información. Por otro lado, utilizando el análisis de telemetría, no se puede "escribir" todo el tráfico de la red (en todo caso, Cisco se ocupa de los centros de datos :-), sino solo el que está involucrado en el ataque. Las herramientas de análisis de telemetría en este sentido complementarán bien los mecanismos tradicionales de captura de paquetes, proporcionando comandos para la captura y el almacenamiento selectivos. De lo contrario, tendrás que disponer de una infraestructura de almacenamiento colosal.
Imaginemos una red funcionando a una velocidad de 250 Mbit/seg. Si desea almacenar todo este volumen, necesitará 31 MB de almacenamiento para un segundo de transmisión de tráfico, 1,8 GB para un minuto, 108 GB para una hora y 2,6 TB para un día. Para almacenar datos diarios de una red con un ancho de banda de 10 Gbit/s, necesitará 108 TB de almacenamiento. Pero algunos reguladores exigen almacenar datos de seguridad durante años... El registro bajo demanda, cuyo análisis de flujo le ayuda a implementar, ayuda a reducir estos valores en órdenes de magnitud. Por cierto, si hablamos de la relación entre el volumen de datos de telemetría de red registrados y la captura completa de datos, entonces es aproximadamente de 1 a 500. Para los mismos valores indicados anteriormente, se almacena una transcripción completa de todo el tráfico diario. serán de 5 y 216 GB, respectivamente (incluso puedes grabarlo en una unidad flash normal).
Si en el caso de las herramientas para analizar datos de red sin procesar, el método de captura es casi el mismo de un proveedor a otro, en el caso del análisis de flujo la situación es diferente. Hay varias opciones para los protocolos de flujo, cuyas diferencias es necesario conocer en el contexto de la seguridad. El más popular es el protocolo Netflow desarrollado por Cisco. Existen varias versiones de este protocolo, que se diferencian en sus capacidades y en la cantidad de información de tráfico registrada. La versión actual es la novena (Netflow v9), a partir de la cual se desarrolló el estándar industrial Netflow v10, también conocido como IPFIX. Hoy en día, la mayoría de los proveedores de redes admiten Netflow o IPFIX en sus equipos. Pero existen otras opciones para los protocolos de flujo: sFlow, jFlow, cFlow, rFlow, NetStream, etc., de los cuales sFlow es el más popular. Es este tipo el que suelen admitir los fabricantes nacionales de equipos de red debido a su facilidad de implementación. ¿Cuáles son las diferencias clave entre Netflow, que se ha convertido en un estándar de facto, y sFlow? Destacaría varios de los más importantes. Primero, Netflow tiene campos personalizables por el usuario a diferencia de los campos fijos en sFlow. Y en segundo lugar, y esto es lo más importante en nuestro caso, sFlow recopila la llamada telemetría muestreada; en contraste con el no muestreado para Netflow e IPFIX. ¿Cuál es la diferencia entre ellos?
Imagina que decides leer el libro”” de mis colegas: Gary McIntyre, Joseph Munitz y Nadem Alfardan (puedes descargar parte del libro desde el enlace). Tiene tres opciones para lograr su objetivo: leer el libro completo, hojearlo, deteniéndose en cada página 10 o 20, o intentar encontrar un recuento de los conceptos clave en un blog o servicio como SmartReading. Entonces, la telemetría sin muestrear lee cada “página” del tráfico de la red, es decir, analiza los metadatos de cada paquete. La telemetría muestreada es el estudio selectivo del tráfico con la esperanza de que las muestras seleccionadas contengan lo que necesita. Dependiendo de la velocidad del canal, la telemetría muestreada se enviará para su análisis cada 64.º, 200.º, 500.º, 1000.º, 2000.º o incluso 10000.º paquete.
En el contexto del monitoreo de la seguridad de la información, esto significa que la telemetría muestreada es muy adecuada para detectar ataques DDoS, escanear y difundir códigos maliciosos, pero puede pasar por alto ataques atómicos o de múltiples paquetes que no se incluyeron en la muestra enviada para análisis. La telemetría no muestreada no tiene tales desventajas. Con esto, el abanico de ataques detectados es mucho más amplio. A continuación se muestra una breve lista de eventos que se pueden detectar utilizando herramientas de análisis de telemetría de red.
Por supuesto, algunos analizadores Netflow de código abierto no le permitirán hacer esto, ya que su tarea principal es recopilar telemetría y realizar análisis básicos desde el punto de vista de TI. Para identificar amenazas a la seguridad de la información basándose en el flujo, es necesario equipar el analizador con varios motores y algoritmos, que identificarán problemas de ciberseguridad basándose en campos Netflow estándar o personalizados, enriquecerán los datos estándar con datos externos de varias fuentes de Threat Intelligence, etc.
Por lo tanto, si tiene la opción, elija Netflow o IPFIX. Pero incluso si su equipo sólo funciona con sFlow, como los fabricantes nacionales, incluso en este caso podrá beneficiarse de ello en un contexto de seguridad.
En el verano de 2019, analicé las capacidades que tienen los fabricantes rusos de hardware de red y todos ellos, excepto NSG, Polygon y Craftway, anunciaron soporte para sFlow (al menos Zelax, Natex, Eltex, QTech, Rusteleteh).
La siguiente pregunta que enfrentará es ¿dónde implementar el soporte de flujo por motivos de seguridad? De hecho, la pregunta no está planteada del todo correctamente. Los equipos modernos casi siempre admiten protocolos de flujo. Por lo tanto, reformularía la pregunta de otra manera: ¿dónde es más eficaz recopilar telemetría desde el punto de vista de la seguridad? La respuesta será bastante obvia: en el nivel de acceso, donde verá el 100% de todo el tráfico, donde tendrá información detallada sobre los hosts (MAC, VLAN, ID de interfaz), donde incluso podrá monitorear el tráfico P2P entre hosts, lo que es fundamental para la detección y distribución de códigos maliciosos. En el nivel central, es posible que simplemente no vea parte del tráfico, pero en el nivel perimetral verá una cuarta parte de todo el tráfico de su red. Pero si por alguna razón tiene dispositivos extraños en su red que permiten a los atacantes "entrar y salir" sin pasar por el perímetro, entonces analizar la telemetría no le dará nada. Por lo tanto, para una cobertura máxima, se recomienda habilitar la recopilación de telemetría en el nivel de acceso. Al mismo tiempo, vale la pena señalar que incluso si hablamos de virtualización o contenedores, el soporte de flujo también se encuentra a menudo en los conmutadores virtuales modernos, lo que le permite controlar el tráfico allí también.
Pero ya que planteé el tema, necesito responder la pregunta: ¿y si el equipo, físico o virtual, no soporta protocolos de flujo? ¿O está prohibida su inclusión (por ejemplo, en segmentos industriales para garantizar la confiabilidad)? ¿O encenderlo genera una carga alta de la CPU (esto sucede en hardware más antiguo)? Para resolver este problema, existen sensores virtuales especializados (sensores de flujo), que son esencialmente divisores ordinarios que pasan el tráfico a través de sí mismos y lo transmiten en forma de flujo al módulo de recolección. Es cierto que en este caso tenemos todos los problemas de los que hablamos anteriormente en relación con las herramientas de captura de paquetes. Es decir, es necesario comprender no sólo las ventajas de la tecnología de análisis de flujo, sino también sus limitaciones.
Otro punto que es importante recordar cuando se habla de herramientas de análisis de flujo. Si en relación a los medios convencionales de generación de eventos de seguridad utilizamos la métrica EPS (evento por segundo), entonces este indicador no es aplicable al análisis de telemetría; se reemplaza por FPS (flujo por segundo). Como en el caso de EPS, no se puede calcular de antemano, pero se puede estimar el número aproximado de subprocesos que genera un dispositivo en particular en función de su tarea. Puede encontrar tablas en Internet con valores aproximados para diferentes tipos de dispositivos y condiciones empresariales, que le permitirán estimar qué licencias necesita para las herramientas de análisis y cuál será su arquitectura. El hecho es que el sensor IDS está limitado por un cierto ancho de banda que puede "tirar", y el colector de flujo tiene sus propias limitaciones que deben entenderse. Por lo tanto, en redes grandes y distribuidas geográficamente suele haber varios recopiladores. cuando describí , ya he dado el número de nuestros coleccionistas: hay 21. Y esto es para una red repartida por los cinco continentes y que cuenta con aproximadamente medio millón de dispositivos activos).
Utilizamos nuestra propia solución como sistema de monitorización Netflow , que está específicamente enfocado a resolver problemas de seguridad. Tiene muchos motores integrados para detectar actividades anómalas, sospechosas y claramente maliciosas, lo que le permite detectar una amplia gama de amenazas diferentes, desde criptominería hasta fugas de información, desde la propagación de códigos maliciosos hasta fraudes. Como la mayoría de los analizadores de flujo, Stealthwatch está construido según un esquema de tres niveles (generador - colector - analizador), pero se complementa con una serie de características interesantes que son importantes en el contexto del material en cuestión. En primer lugar, se integra con soluciones de captura de paquetes (como Cisco Security Packet Analyzer), lo que le permite grabar sesiones de red seleccionadas para su posterior investigación y análisis en profundidad. En segundo lugar, específicamente para ampliar las tareas de seguridad, hemos desarrollado un protocolo especial nvzFlow, que le permite "transmitir" la actividad de las aplicaciones en los nodos finales (servidores, estaciones de trabajo, etc.) en telemetría y transmitirla al recopilador para su posterior análisis. Si en su versión original Stealthwatch funciona con cualquier protocolo de flujo (sFlow, rFlow, Netflow, IPFIX, cFlow, jFlow, NetStream) a nivel de red, entonces el soporte de nvzFlow permite la correlación de datos también a nivel de nodo, por lo que. aumentando la eficiencia de todo el sistema y viendo más ataques que los analizadores de flujo de red convencionales.
Está claro que cuando se habla de sistemas de análisis Netflow desde el punto de vista de la seguridad, el mercado no se limita a una única solución de Cisco. Puede utilizar soluciones tanto comerciales como gratuitas o shareware. Es bastante extraño si cito las soluciones de la competencia como ejemplos en el blog de Cisco, por lo que diré algunas palabras sobre cómo se puede analizar la telemetría de red utilizando dos herramientas populares, similares en nombre, pero aún diferentes: SiLK y ELK.
SiLK es un conjunto de herramientas (el Sistema para el Conocimiento a Nivel de Internet) para el análisis del tráfico, desarrollado por el CERT/CC americano y que soporta, en el contexto del artículo de hoy, Netflow (5ª y 9ª, las versiones más populares), IPFIX y sFlow y utilizando varias utilidades (rwfilter, rwcount, rwflowpack, etc.) para realizar diversas operaciones en la telemetría de la red con el fin de detectar signos de acciones no autorizadas en la misma. Pero hay un par de puntos importantes a tener en cuenta. SiLK es una herramienta de línea de comandos que realiza análisis en línea ingresando comandos como este (detección de paquetes 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 muy cómodo. Puede utilizar la GUI de iSiLK, pero no le hará la vida mucho más fácil, solo resolverá la función de visualización y no reemplazará al analista. Y este es el segundo punto. A diferencia de las soluciones comerciales, que ya cuentan con una base analítica sólida, algoritmos de detección de anomalías, flujo de trabajo correspondiente, etc., en el caso de SiLK tendrá que hacer todo esto usted mismo, lo que requerirá de su parte competencias ligeramente diferentes a las del uso ya preparado. herramientas de uso. Esto no es ni bueno ni malo: es una característica de casi cualquier herramienta gratuita que supone que usted sabe qué hacer y solo lo ayudará con esto (las herramientas comerciales dependen menos de las competencias de sus usuarios, aunque también asumen que los analistas comprendan al menos los conceptos básicos de las investigaciones y el monitoreo de redes). Pero volvamos a SiLK. El ciclo de trabajo del analista con él se ve así:
- Formular una hipótesis. Debemos entender qué buscaremos dentro de la telemetría de la red, conocer los atributos únicos mediante los cuales identificaremos ciertas anomalías o amenazas.
- Construyendo un modelo. Una vez formulada una hipótesis, la programamos utilizando el mismo Python, shell u otras herramientas no incluidas en SiLK.
- Pruebas. Ahora llega el turno de comprobar la exactitud de nuestra hipótesis, que se confirma o refuta utilizando las utilidades SiLK que comienzan con 'rw', 'set', 'bag'.
- Análisis de datos reales. En la operación industrial, SiLK nos ayuda a identificar algo y el analista debe responder a las preguntas “¿Encontramos lo que esperábamos?”, “¿Corresponde esto a nuestra hipótesis?”, “¿Cómo reducir el número de falsos positivos?”, “¿Cómo para mejorar el nivel de reconocimiento? » etcétera.
- Mejora. En la etapa final, mejoramos lo hecho anteriormente: creamos plantillas, mejoramos y optimizamos el código, reformulamos y aclaramos la hipótesis, etc.
Este ciclo también será aplicable a Cisco Stealthwatch, solo que el último automatiza al máximo estos cinco pasos, reduciendo el número de errores de los analistas y aumentando la eficiencia en la detección de incidentes. Por ejemplo, en SiLK puede enriquecer las estadísticas de la red con datos externos sobre IP maliciosas utilizando scripts escritos a mano, y en Cisco Stealthwatch es una función incorporada que muestra inmediatamente una alarma si el tráfico de la red contiene interacciones con direcciones IP de la lista negra.
Si sube más en la pirámide "paga" del software de análisis de flujo, después del SiLK, absolutamente gratuito, aparecerá el shareware ELK, que consta de tres componentes clave: Elasticsearch (indexación, búsqueda y análisis de datos), Logstash (entrada/salida de datos). ) y Kibana (visualización). A diferencia de SiLK, donde tienes que escribir todo tú mismo, ELK ya tiene muchas bibliotecas/módulos listos para usar (algunos pagos, otros no) que automatizan el análisis de la telemetría de la red. Por ejemplo, el filtro GeoIP en Logstash le permite asociar direcciones IP monitoreadas con su ubicación geográfica (Stealthwatch tiene esta función incorporada).
ELK también tiene una comunidad bastante grande que está completando los componentes que faltan para esta solución de monitoreo. Por ejemplo, para trabajar con Netflow, IPFIX y sFlow puedes utilizar el módulo , si no está satisfecho con el módulo Logstash Netflow, que solo admite Netflow.
Si bien ofrece más eficiencia en la recopilación de flujo y la búsqueda en él, ELK actualmente carece de análisis integrados enriquecidos para detectar anomalías y amenazas en la telemetría de la red. Es decir, siguiendo el ciclo de vida descrito anteriormente, tendrás que describir de forma independiente los modelos de infracción y luego usarlos en el sistema de combate (no hay modelos integrados allí).
Por supuesto, existen extensiones más sofisticadas para ELK, que ya contienen algunos modelos para detectar anomalías en la telemetría de la red, pero tales extensiones cuestan dinero y aquí la pregunta es si el juego vale la pena: escriba un modelo similar usted mismo, cómprelo. implementación para su herramienta de monitoreo, o compre una solución ya preparada de la clase Análisis de tráfico de red.
En general, no quiero entrar en el debate de que es mejor gastar dinero y comprar una solución ya preparada para monitorear anomalías y amenazas en la telemetría de la red (por ejemplo, Cisco Stealthwatch) o descubrirlo usted mismo y personalizarlo. SiLK, ELK o nfdump u OSU Flow Tools para cada nueva amenaza (me refiero a las dos últimas). ultima vez)? Cada uno elige por sí mismo y cada uno tiene sus propios motivos para elegir cualquiera de las dos opciones. Solo quería mostrar que la telemetría de red es una herramienta muy importante para garantizar la seguridad de la red de su infraestructura interna y no debe descuidarla para no unirse a la lista de empresas cuyo nombre se menciona en los medios junto con los epítetos ". pirateado”, “incumplimiento de los requisitos de seguridad de la información””, “no pensar en la seguridad de sus datos y los de los clientes”.
Para resumir, me gustaría enumerar los consejos clave que debe seguir al crear un monitoreo de seguridad de la información de su infraestructura interna:
- ¡No te limites sólo al perímetro! Utilice (y elija) la infraestructura de red no sólo para mover el tráfico del punto A al punto B, sino también para abordar cuestiones de ciberseguridad.
- Estudie los mecanismos de monitoreo de seguridad de la información existentes en sus equipos de red y utilícelos.
- Para el monitoreo interno, dé preferencia al análisis de telemetría: le permite detectar hasta el 80-90% de todos los incidentes de seguridad de la información de la red, mientras hace lo que es imposible al capturar paquetes de red y ahorrar espacio para almacenar todos los eventos de seguridad de la información.
- Para monitorear los flujos, use Netflow v9 o IPFIX: brindan más información en un contexto de seguridad y le permiten monitorear no solo IPv4, sino también IPv6, MPLS, etc.
- Utilice un protocolo de flujo sin muestrear: proporciona más información para detectar amenazas. Por ejemplo, Netflow o IPFIX.
- Verifique la carga en su equipo de red; es posible que tampoco pueda manejar el protocolo de flujo. Entonces considere usar sensores virtuales o Netflow Generation Appliance.
- Implemente el control en primer lugar en el nivel de acceso; esto le dará la oportunidad de ver el 100% de todo el tráfico.
- Si no tiene otra opción y está utilizando equipos de red rusos, elija uno que admita protocolos de flujo o que tenga puertos SPAN/RSPAN.
- Combinar sistemas de detección/prevención de intrusiones/ataques en los bordes y sistemas de análisis de flujo en la red interna (incluidas las nubes).
Respecto al último consejo, me gustaría dar un ejemplo que ya he dado antes. Verá que si antes el servicio de seguridad de la información de Cisco construía casi por completo su sistema de monitoreo de seguridad de la información sobre la base de sistemas de detección de intrusos y métodos de firma, ahora representan solo el 20% de los incidentes. Otro 20% corresponde a sistemas de análisis de flujo, lo que sugiere que estas soluciones no son un capricho, sino una herramienta real en las actividades de los servicios de seguridad de la información de una empresa moderna. Además, tiene lo más importante para su implementación: la infraestructura de red, cuyas inversiones pueden protegerse aún más asignando funciones de monitoreo de seguridad de la información a la red.
Específicamente no toqué el tema de responder a anomalías o amenazas identificadas en los flujos de la red, pero creo que ya está claro que el monitoreo no debe terminar solo con la detección de una amenaza. Debe ir seguido de una respuesta y preferiblemente en modo automático o automatizado. Pero este es un tema para un artículo aparte.
Información adicional:
PD. Si le resulta más fácil escuchar todo lo escrito anteriormente, puede ver la presentación de una hora que formó la base de esta nota.
Fuente: habr.com