Cuando se trata de monitorear la seguridad de una red interna corporativa o departamental, muchos tienen una asociación con el control de fugas de información y la implementación de soluciones DLP. Y si intenta aclarar la pregunta y preguntar cómo detecta ataques en la red interna, la respuesta generalmente será la mención de los sistemas de detección de intrusos (IDS). Y lo que era la única opción hace 10-20 años, hoy se está convirtiendo en un anacronismo. Existe una opción más efectiva y, en algunos lugares, la única opción posible para monitorear la red interna: usar protocolos de flujo que fueron diseñados originalmente para buscar problemas de red (solución de problemas), pero que finalmente se transformaron en una herramienta de seguridad muy interesante. Hablaremos sobre qué son los protocolos de flujo y cuáles ayudan mejor a detectar ataques de red, dónde es mejor implementar el monitoreo de flujo, qué buscar al implementar dicho esquema e incluso cómo "recogerlo" en equipos domésticos como parte de este artículo
No me detendré en la pregunta "¿Por qué necesitamos monitorear la seguridad de la infraestructura interna?" La respuesta parece ser clara. Pero si, sin embargo, desea asegurarse una vez más de que hoy no hay ningún lugar sin esto,
vea un breve video con una historia sobre cómo puede ingresar a la red corporativa protegida por un firewall de 17 maneras. Por lo tanto, asumiremos que entendemos que el monitoreo interno es algo necesario y que solo queda entender cómo se puede organizar.
Destacaría tres fuentes de datos clave para monitorear la infraestructura a nivel de red:
- Tráfico "sin procesar", 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 utilizando uno de los protocolos de flujo.
Capturar tráfico en bruto es la opción más popular entre los guardias de seguridad, porque históricamente apareció como la primera. Los sistemas convencionales de detección de ataques basados en la red (el primer sistema comercial de detección de ataques fue el NetRanger de WheelR, adquirido en 1998 por Cisco) solo estaban en el negocio de capturar paquetes (y sesiones posteriores) que buscaban firmas específicas ("reglas decisivas" en terminología FSTEC), ataques de señalización. Por supuesto, puede analizar el tráfico sin procesar no solo usando IDS, sino también usando otras herramientas (por ejemplo, funcionalidad Wireshark, tcpdum o NBAR2 en Cisco IOS), pero generalmente carecen de una base de conocimiento que distinga una herramienta de seguridad de la información de una herramienta de TI normal.
Entonces, sistemas de detección de ataques. El método más antiguo y popular para detectar ataques a la red, que se adapta bien a su tarea en el perímetro (sin importar qué: corporativo, centro de datos, segmento, etc.), pero pasa en redes modernas conmutadas y definidas por software. En el caso de una red construida sobre la base de conmutadores convencionales, la infraestructura de los sensores de detección de ataques se vuelve demasiado grande: tendrá que colocar un sensor en cada conexión al host cuyos ataques desea monitorear. Cualquier fabricante, por supuesto, estará encantado de venderle cientos y miles de sensores, pero creo que su presupuesto no puede soportar tales costos. Puedo decir que incluso en Cisco (y somos los desarrolladores de NGIPS) no pudimos hacer esto, aunque parece que el problema del precio está por delante. no debería resistir, esta es nuestra propia decisión. Además, surge la pregunta, pero ¿cómo conectar el sensor en esta realización? A la brecha? ¿Y si el sensor en sí está desactivado? ¿Requiere un módulo de derivación en el sensor? ¿Usar divisores de tomas? Todo esto encarece la solución y la hace insoportable para una empresa de cualquier escala.
Puede intentar "colgar" el sensor en el puerto SPAN / RSPAN / ERSPAN y dirigir el tráfico hacia él desde los puertos necesarios en el conmutador. Esta opción elimina parcialmente el problema descrito en el párrafo anterior, pero plantea uno diferente: el puerto SPAN no puede aceptar absolutamente todo el tráfico que se le enviará, no tendrá suficiente ancho de banda. Acurrucarse algo para sacrificar. Deje parte de los nodos sin supervisión (luego debe priorizarlos primero) o no enrute todo el tráfico desde el nodo, sino solo un cierto tipo. En cualquier caso, podemos omitir algunos ataques. Además, el puerto SPAN se puede ocupar para otras necesidades. Como resultado, tendremos que revisar la topología de red existente y, posiblemente, hacer ajustes para cubrir su red al máximo con la cantidad de sensores que tiene (y coordinar esto con TI).
¿Y si su red utiliza rutas asimétricas? ¿Y si ha implementado o planea introducir SDN? ¿Y si necesita monitorear máquinas o contenedores virtualizados cuyo tráfico no llega al conmutador físico? A los fabricantes de IDS tradicionales no les gustan estas preguntas porque no saben cómo responderlas. Quizás lo inclinarán al hecho de que todas estas tecnologías de moda son exageradas y que no las necesita. Tal vez hablarán sobre la necesidad de comenzar de a poco. O tal vez dirán que necesita colocar una potente trilladora en el centro de la red y dirigir todo el tráfico hacia ella mediante equilibradores. Independientemente de la opción que se le ofrezca, debe comprender claramente por sí mismo cuánto le conviene. 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 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; los límites entre su organización e Internet, los límites entre el centro de datos y el resto de la red, los límites entre el ICS y el segmento corporativo. En estos lugares, los IDS / IPS clásicos todavía tienen derecho a existir y hacer un buen trabajo en sus tareas.
Pasemos a la segunda opción. Un análisis de eventos desde dispositivos de red también se puede utilizar para detectar ataques, pero no como el mecanismo principal, ya que le permite detectar solo una pequeña clase de intrusiones. Además, tiene cierta reactividad inherente: primero debe ocurrir un ataque, luego debe ser reparado por un dispositivo de red, que de una forma u otra indicará un problema con la seguridad de la información. Hay varias formas Puede ser syslog, RMON o SNMP. Los dos últimos protocolos para el monitoreo de la red en el contexto de la seguridad de la información se aplican solo si necesitamos detectar un ataque DoS en el equipo de la red en sí, ya que usando RMON y SNMP, por ejemplo, podemos monitorear la carga del procesador central del dispositivo o sus interfaces. Este es uno de los "más baratos" (todos tienen syslog o SNMP), pero también es la forma más ineficaz de monitorear la seguridad de la información de la infraestructura interna: muchos ataques simplemente están ocultos. Por supuesto, no deben descuidarse y el mismo análisis de syslog lo ayuda a identificar los cambios en la configuración del dispositivo de manera oportuna, es un compromiso, 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 admite uno de varios protocolos de flujo. En este caso, independientemente del protocolo, la infraestructura de flujo consta necesariamente de tres componentes:
- Generar o exportar 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 transfieren al módulo de recopilación. Por ejemplo, el protocolo Cisco Netflow no solo es compatible con enrutadores y conmutadores, incluidos los virtuales e industriales, sino también con controladores inalámbricos, firewalls e incluso servidores.
- Flujo de recolección. Dado que en una red moderna generalmente hay más de un dispositivo de red, surge el problema de recopilar y consolidar flujos, que se resuelve utilizando los llamados colectores, que procesan los flujos recibidos y luego los transmiten para su análisis.
- Análisis de flujo. El analizador asume la tarea intelectual principal y, aplicando varios algoritmos a los flujos, saca ciertas conclusiones. Por ejemplo, como parte de la función de TI, dicho analizador puede identificar cuellos de botella en la red o analizar el perfil de carga de tráfico para optimizar aún más la red. Y para IS, dicho analizador puede detectar fugas de datos, la propagación de código malicioso o ataques DoS.
No debe pensar que dicha arquitectura de tres niveles es demasiado complicada: todas las demás opciones (excepto, tal vez, los sistemas de monitoreo de red que funcionan con SNMP y RMON) también funcionan de acuerdo con ella. Tenemos un generador de datos para el análisis, que es un dispositivo de red o un sensor independiente. Tenemos un sistema de recolección de alarmas y un sistema de gestión para toda la infraestructura de monitoreo. Los dos últimos componentes se pueden combinar dentro de un solo nodo, pero en redes más o menos grandes generalmente están separados por al menos dos dispositivos para garantizar la escalabilidad y la confiabilidad.
A diferencia del análisis de paquetes, basado en el estudio del encabezado y el cuerpo de datos de cada paquete y las sesiones que consisten en ellos, el análisis de flujos se basa en la recopilación de metadatos sobre el tráfico de red. Cuándo, cuánto, dónde y dónde, cómo ... estas son las preguntas respondidas por el análisis de la telemetría de red utilizando varios protocolos de flujo. Inicialmente, se utilizaron para analizar estadísticas y buscar problemas de TI en la red, pero luego, con el desarrollo de mecanismos analíticos, fue posible aplicarlos a la misma telemetría y con fines de seguridad. Vale la pena mencionar aquí nuevamente que el análisis de flujo no reemplaza ni cancela la captura de paquetes. Cada uno de estos métodos tiene su propio campo de aplicación. Pero en el contexto de este artículo, es el análisis de flujo el más adecuado para monitorear la infraestructura interna. Tiene dispositivos de red (y no importa si funcionan en un paradigma definido por software o de acuerdo con reglas estáticas) que el ataque no puede pasar. Puede omitir el sensor IDS clásico, pero no hay ningún dispositivo de red que admita el protocolo de flujo. Esta es la ventaja de este método.
Por otro lado, si necesita evidencia para la aplicación de la ley 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 se puede utilizar para recopilar evidencia; Es necesario para la detección operativa y la toma de decisiones en el campo de la seguridad de la información. Por otro lado, utilizando el análisis de telemetría, puede "escribir" no todo el tráfico de la red (en todo caso, Cisco está involucrado en los centros de datos :-), pero solo el que está involucrado en el ataque. Las herramientas de análisis de telemetría a este respecto complementarán bien los mecanismos tradicionales de captura de paquetes, dando el comando para la captura y el almacenamiento selectivos. De lo contrario, debe tener una infraestructura de almacenamiento colosal.
Imagine una red que funciona a una velocidad de 250 Mbps. Si desea guardar todo este volumen, necesitará 31 MB de almacenamiento para un segundo de transferencia de tráfico, 1.8 GB por un minuto, 108 GB por una hora y 2.6 TB por un día. Para almacenar datos diarios de una red con un ancho de banda de 10 Gbit / s, necesita 108 TB de almacenamiento. Pero algunos reguladores requieren que almacene datos de seguridad durante años ... La grabación “a pedido”, que lo ayuda a implementar el análisis de flujo, ayuda a reducir estos valores en órdenes de magnitud. Por cierto, si hablamos de la relación del volumen registrado de datos de telemetría de red con respecto a la captura total de datos, entonces es de aproximadamente 1 a 500. Para los mismos valores anteriores, el almacenamiento del descifrado completo de todo el tráfico diario será de 5 y 216 GB, respectivamente (incluso puede escribir en una unidad flash USB normal) )
Si las herramientas de análisis de datos de red sin procesar tienen un método para capturarlas que es casi igual que el proveedor al proveedor, entonces la situación es diferente con el análisis de flujos. Hay varias opciones para los protocolos de flujo, las diferencias en las que necesita saber en el contexto de seguridad. El más popular es el protocolo Netflow desarrollado por Cisco. Existen varias versiones de este protocolo que difieren en sus capacidades y la cantidad de información registrada sobre el tráfico. La versión actual es la novena (Netflow v9), sobre la base de la cual se desarrolló el estándar de la industria Netflow v10, también conocido como IPFIX. Hoy en día, la mayoría de los proveedores de redes admiten exactamente Netflow o IPFIX en sus equipos. Pero hay varias otras opciones para protocolos de flujo: sFlow, jFlow, cFlow, rFlow, NetStream, etc., de las cuales sFlow es más popular. Es él quien más a menudo recibe el apoyo de los fabricantes nacionales de equipos de red debido a la facilidad de implementación. ¿Cuáles son las diferencias clave entre Netflow, como estándar de facto, y sFlow? Destacaría algunas claves. Primero, Netflow tiene campos definidos por el usuario en lugar de 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; a diferencia de sin muestrear en Netflow e IPFIX. ¿Cuál es la diferencia entre ellos?
Imagine que decidió leer el libro "
Centro de operaciones de seguridad: construcción, operación y mantenimiento de su SOC " de mis colegas: Gary MacIntyre, Joseph Muniz y Nadef Alfardan (puede descargar parte del libro desde el enlace). Tiene tres opciones para lograr su objetivo: leer todo el libro, revisarlo con los ojos, detenerse en cada página 10 o 20, o tratar de volver a contar conceptos clave en un blog o servicio como SmartReading. Entonces, la telemetría sin muestrear es leer cada "página" del tráfico de la red, es decir, analizar los metadatos para cada paquete. La telemetría de muestreo es un estudio selectivo del tráfico con la esperanza de que las muestras seleccionadas tengan lo que necesita. Dependiendo de la velocidad del canal, la telemetría muestreada enviará para su análisis cada paquete 64, 200, 500, 1000, 2000 o incluso 10000.
En el contexto de la supervisión 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ódigo malicioso, pero puede omitir ataques atómicos o de paquetes múltiples que no caen en la muestra enviada para su análisis. La telemetría sin muestrear no tiene tales deficiencias. Usar el rango de ataques detectables es mucho más amplio. Aquí hay una breve lista de eventos que pueden detectarse utilizando herramientas de análisis de telemetría de red.
Por supuesto, algunos analizadores de 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 un punto de vista de TI. Para identificar las amenazas de seguridad de la información basadas en el flujo, es necesario equipar el analizador con varios motores y algoritmos, que identificarán los problemas de ciberseguridad sobre la base de campos Netflow estándar o personalizados, enriquecerán los datos estándar con datos externos de varias fuentes de Inteligencia de amenazas, etc.
Por lo tanto, si tiene una opción, deténgala en Netflow o IPFIX. Pero incluso si su equipo solo funciona con sFlow, como los fabricantes nacionales, incluso en este caso puede beneficiarse de él en el contexto de seguridad.
En el verano de 2019, analicé las oportunidades que tienen los fabricantes rusos de hardware en red, y todos ellos, excepto NSG, Polygon y Craftway, declararon su apoyo a sFlow (al menos Zelax, Natex, Eltex, QTech, Rusteletech).
La siguiente pregunta que enfrentará es ¿dónde implementar el soporte de flujo con fines de seguridad? De hecho, la pregunta no es del todo correcta. En equipos modernos, el soporte para protocolos de flujo casi siempre está ahí. Por lo tanto, reformularía la pregunta de manera diferente: ¿cuál es la forma más eficiente de recopilar telemetría desde un punto de vista de 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 puede rastrear el tráfico P2P entre hosts, lo cual es crítico para detectar escaneos y y la difusión de código malicioso. En el nivel del kernel, es posible que no vea parte del tráfico, pero en el nivel del perímetro verá bien una cuarta parte de todo el tráfico de su red. Pero si, por alguna razón, se conectan 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 incluir la recolección de telemetría en el nivel de acceso. Al mismo tiempo, vale la pena señalar que incluso si estamos hablando 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 desde que mencioné el tema, necesito responder la pregunta, pero ¿qué pasa si, después de todo, el equipo, físico o virtual, no admite protocolos de flujo? ¿O está prohibida su inclusión (por ejemplo, en segmentos industriales para garantizar la fiabilidad)? ¿O su inclusión conduce a una alta utilización de la CPU (esto sucede en equipos obsoletos)? Para resolver este problema, hay sensores virtuales especializados (sensor de flujo), que son esencialmente divisores ordinarios que pasan el tráfico a través de ellos mismos y lo transmiten en forma de flujo al módulo de recolección. Es cierto que en este caso tenemos un montón de problemas de los que hablamos anteriormente en relación con las herramientas de captura de paquetes. Es decir, debe comprender no solo 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 aplicamos la métrica EPS (evento por segundo, eventos por segundo) a los medios convencionales para generar eventos de seguridad, entonces este indicador no se aplica al análisis de telemetría; se reemplaza por FPS (flujo por segundo). Como en el caso de EPS, no se puede calcular por adelantado, pero puede estimar el número aproximado de flujos que genera un dispositivo en particular dependiendo de su tarea. En Internet puede encontrar tablas con valores aproximados para diferentes tipos de dispositivos y condiciones corporativas, que le permitirán determinar 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 "tirará", y el colector de flujo tiene sus propias limitaciones, que deben entenderse. Por lo tanto, en grandes redes distribuidas geográficamente, generalmente hay varios depósitos. Cuando describí
cómo se monitorea la red dentro de Cisco , ya mencioné el número de nuestros recolectores: hay 21. Y esta es una red dispersa en los cinco continentes y que cuenta con aproximadamente medio millón de dispositivos activos).
Como sistema de monitoreo de Netflow, utilizamos nuestra propia
solución Cisco Stealthwatch , que se enfoca específicamente en resolver problemas de seguridad. Tiene muchos motores incorporados para detectar actividades anormales, sospechosas y obviamente maliciosas, lo que permite detectar una amplia gama de diversas amenazas, desde la minería criptográfica hasta fugas de información, desde la propagación de código malicioso hasta el fraude. Como la mayoría de los analizadores de flujo, Stealthwatch se construye de acuerdo con 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 consideración. Primero, se integra con soluciones de captura de paquetes (por ejemplo, Cisco Security Packet Analyzer), que le permite grabar sesiones de red seleccionadas para una investigación y análisis más detallados. En segundo lugar, especialmente para expandir las tareas de seguridad, desarrollamos un protocolo especial nvzFlow, que le permite "traducir" la actividad de las aplicaciones en los nodos finales (servidores, estaciones de trabajo, etc.) a 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) en el nivel de red, entonces el soporte nvzFlow permite que los datos se correlacionen también en el nivel del host. aumentando la eficiencia de todo el sistema y viendo más ataques que los analizadores de flujo de red convencionales.
Está claro que hablando de análisis de seguridad de sistemas Netflow, el mercado no se limita a una única solución de Cisco. Puede utilizar soluciones comerciales y gratuitas o shareware. Por extraño que parezca, si uso el blog de Cisco como un ejemplo de las soluciones de la competencia, diré algunas palabras sobre cómo se puede analizar la telemetría de red utilizando dos herramientas populares, de nombre similar, 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 American CERT / CC y que admite, en el contexto del artículo de hoy, Netflow (5 y 9, las versiones más populares), IPFIX y sFlow y el uso de diversas utilidades (rwfilter, rwcount, rwflowpack, etc.) para realizar diversas operaciones en la telemetría de red con el fin de detectar signos de acciones no autorizadas en ella. Pero hay un par de puntos importantes a tener en cuenta. SiLK es una herramienta de línea de comando y realiza análisis operacionales, todo el tiempo ingresa un comando del formulario (detección de paquetes ICMP mayores de 200 bytes):
rwfilter --flowtypes=all/all --proto=1 --bytes-per-packet=200- --pass=stdout | rwrwcut --fields=sIP,dIP,iType,iCode --num-recs=15No muy conveniente. Puede usar la GUI iSiLK, pero no le facilitará la vida al resolver solo la función de visualización, no el reemplazo del analista. Y este es el segundo punto. A diferencia de las soluciones comerciales, que ya tienen una base analítica sólida, algoritmos de detección de anomalías, algoritmos relacionados con el flujo de trabajo, etc., en el caso de SiLK, tendrá que hacer todo esto usted mismo, lo que requerirá que use competencias ligeramente diferentes de las que ya debe usar. Herramientas listas para usar. Esto es malo y no está mal: esta es una característica de casi cualquier herramienta gratuita que proviene del hecho de que sabes qué hacer, y solo te ayudará en esto (las herramientas comerciales dependen menos de las competencias de sus usuarios, aunque también supone que los analistas entienden al menos conceptos básicos de investigación y monitoreo de redes). Pero volvamos a SiLK. El ciclo de trabajo del analista con él es el siguiente:
- Formulación de una hipótesis. Debemos entender lo que buscaremos dentro de la telemetría de red, para conocer los atributos únicos por los cuales identificaremos ciertas anomalías o amenazas.
- Construyendo un modelo. Una vez formulada una hipótesis, la programamos utilizando la misma Python, shell u otras herramientas no incluidas en SiLK.
- Pruebas Es el turno de probar la validez 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 las preguntas “¿Encontramos lo que esperábamos?”, “¿Corresponde esto a nuestra hipótesis?”, “¿Cómo reducir el número de falsos positivos?”, “¿Cómo mejorar el nivel de reconocimiento? " etc.
- Mejora En la etapa final, mejoramos lo que se hizo antes: crear plantillas, mejorar y optimizar el código, reformular y refinar la hipótesis, etc.
Este ciclo será aplicable al mismo Cisco Stealthwatch, solo los últimos cinco pasos se automatizarán al máximo, reduciendo el número de errores de analistas y aumentando la velocidad de detección de incidentes. Por ejemplo, en SiLK, puede enriquecer las estadísticas de red con datos externos sobre IP maliciosa utilizando sus propios scripts, y en Cisco Stealthwatch, esta es una función incorporada que muestra inmediatamente una alarma si hay interacción con direcciones IP en la lista negra en el tráfico de red.
Si vamos más arriba en la pirámide "pagada" para el software de análisis de flujo, entonces el SiLK totalmente gratuito será seguido por el ELK shareware 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 tiene que escribir todo usted mismo, ELK ya tiene muchas bibliotecas / módulos listos (algunos son pagados, otros no) que automatizan el análisis de telemetría de red. Por ejemplo, el filtro GeoIP en Logstash le permite vincular las direcciones IP observadas a su ubicación geográfica (para Stealthwatch, esta es una 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, puede usar el módulo
elastiflow si no se siente cómodo con el Módulo Logstash Netflow, que solo es compatible con Netflow.
Dando más eficiencia en la recopilación de flujo y la búsqueda en él, ELK actualmente no cuenta con análisis integrados para detectar anomalías y amenazas en la telemetría de red. Es decir, siguiendo el ciclo de vida descrito anteriormente, tendrá que describir de forma independiente el modelo de violaciones y luego usarlo en el sistema de combate (no hay modelos incorporados allí).
Por supuesto, hay extensiones más sofisticadas para ELK que ya contienen algunos modelos para detectar anomalías en la telemetría de red, pero tales extensiones cuestan dinero y la pregunta es si el juego vale la pena: escriba el mismo modelo usted mismo, compre su implementación para su herramienta de monitoreo o compre solución llave en mano para la clase Network Traffic Analysis.
En general, no quiero entrar en el debate de que es mejor gastar dinero y comprar una solución llave en mano para monitorear anomalías y amenazas en la telemetría de red (por ejemplo, Cisco Stealthwatch) o resolverlo por su cuenta y girar las mismas herramientas SiLK, ELK o nfdump o OSU Flow (para cada nueva amenaza) ( ¿ Hablé de los dos últimos la última vez? Todos eligen por sí mismos 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 reponer la lista de la compañía cuyo nombre se menciona en los medios junto con los epítetos "pirateados", que no cumplieron con los requisitos de seguridad de la información "," Pensando en la seguridad de sus datos y los datos de los clientes ".
En resumen, me gustaría enumerar los consejos clave que debe seguir al construir el monitoreo de seguridad de la información de su infraestructura interna:- ¡No te limites solo al perímetro! Use (y elija) la infraestructura de red no solo para transferir tráfico del punto A al punto B, sino también para abordar problemas de ciberseguridad.
- Explore los mecanismos de monitoreo de seguridad existentes en su equipo de red e impleméntelos.
- 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, 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 flujos, use Netflow v9 o IPFIX: proporcionan más información en el contexto de seguridad y le permiten monitorear no solo IPv4, sino también IPv6, MPLS, etc.
- flow- – . , Netflow IPFIX.
- – flow-. Netflow Generation Appliance.
- – 100% .
- , , flow- SPAN/RSPAN-.
- / / ( ).
En cuanto al último consejo, me gustaría dar una ilustración, que ya he citado anteriormente. Verá que si antes el servicio Cisco IB construía casi por completo su sistema de monitoreo IS basado en sistemas de detección de intrusos y métodos de firma, ahora representan solo el 20% de los incidentes. Otro 20% se explica por los 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: infraestructura de red, inversiones en las que también se puede proteger mediante la asignación de funciones de monitoreo IS a la red.
Deliberadamente no toqué el tema de responder a las anomalías o amenazas identificadas en los flujos de red, pero creo que ya está claro que el monitoreo no debe completarse solo mediante la detección de una amenaza. Debe ir seguido de una respuesta y preferiblemente en modo automático o automatizado. Pero este es el tema de un material separado.Informacion adicional:Amenaza
Si le resulta más fácil escuchar todo lo que se escribió anteriormente, puede ver la presentación de una hora que formó la base de esta nota.