Get best of the week

Integración de Netflow y soluciones de monitoreo SIEM

Los SIEM se han convertido en un estándar de facto en el análisis de eventos de seguridad y la detección de incidentes (aunque existe cierto movimiento para abandonar SIEM y reemplazarlos con soluciones para administrar registros con un complemento de tecnologías de aprendizaje automático), pero la efectividad de esta solución depende de con qué fuentes de datos funciona. Aún así, por lo general, los especialistas de SIEM trabajan principalmente con registros, dejando de lado una fuente de información tan importante como Netflow, que le permite ver algo que a menudo no entra en los registros o llega, pero es demasiado tarde. Esto plantea una serie de preguntas. ¿Por qué una solución SIEM moderna necesita soporte de Netflow? ¿Qué puede obtener SIEM del análisis de Netflow? ¿Qué opción para integrar SIEM con Netflow si hay fabricantes,quienes integran el soporte de Netflow directamente en sus soluciones, y hay quienes prefieren trabajar con varios recolectores de Netflow. ¿Cuáles son las características de trabajar con SIEM Netflow? Hablaremos de esto.

Netflow para detección de amenazas


En un artículo anteriorYa he descrito las posibilidades de usar Netflow para ciberseguridad. Permítame recordarle que, a diferencia de los registros de equipos de red o tráfico sin procesar, Netflow es un protocolo que le permite analizar el tráfico por metadatos recopilados de las sesiones de red. Estos no son solo direcciones y puertos de origen y destino, sino también tipos de mensajes y códigos para ICMP, tipos de servicios IP, tipos de protocolos IP, interfaces de red, duración de la sesión, horas de inicio y finalización, etc. Si los registros generalmente se generan en dispositivos terminales (por ejemplo, servidores, estaciones de trabajo y DBMS) o medios de protección, entonces qué hacer en una situación en la que los primeros no generan eventos de seguridad o no puede ponerles medios de seguridad,y estos últimos se instalan solo en el perímetro y no ven lo que sucede dentro de la red corporativa o departamental? Otra cosa es el equipo de red: conmutadores y enrutadores (hardware o virtuales), puntos de acceso inalámbrico y controladores. Se instalan en el interior y la interacción de usuarios, dispositivos, aplicaciones siempre pasa a través de ellos. ¡Es imposible pasarlos! Al transmitir datos sobre esta interacción a Netflow (incluso Cisco ASA o Firepower lo genera), obtenemos una valiosa fuente de información no solo para TI, sino también para la ciberseguridad. Cuando el equipo no comprende el protocolo de flujo, podemos utilizar exportadores especiales, soluciones de software o hardware que generan registros de flujo para el tráfico que pasa a través de ellos (con Cisco, el dispositivo Netflow Generation oque generan registros de flujo para el tráfico que pasa a través de ellos (con Cisco, Netflow Generation Appliance oque generan registros de flujo para el tráfico que pasa a través de ellos (con Cisco, Netflow Generation Appliance opuntos de acceso inalámbrico y controladores. Se instalan en el interior y la interacción de usuarios, dispositivos, aplicaciones siempre pasa a través de ellos. ¡Es imposible pasarlos! Al transmitir datos sobre esta interacción a Netflow (incluso Cisco ASA o Firepower lo genera), obtenemos una valiosa fuente de información no solo para TI, sino también para la ciberseguridad. Cuando el equipo no comprende el protocolo de flujo, podemos utilizar exportadores especiales, soluciones de software o hardware que generan registros de flujo para el tráfico que pasa a través de ellos (para Cisco, el dispositivo de generación Netflow opuntos de acceso inalámbrico y controladores. Se instalan en el interior y la interacción de usuarios, dispositivos, aplicaciones siempre pasa a través de ellos. ¡Es imposible pasarlos! Al transmitir datos sobre esta interacción a Netflow (incluso Cisco ASA o Firepower lo genera), obtenemos una valiosa fuente de información no solo para TI, sino también para la ciberseguridad. Cuando los equipos no entienden el protocolo de flujo, podemos usar exportadores especiales, soluciones de software o hardware que generan registros de flujo para el tráfico que pasa a través de ellos (para Cisco, el dispositivo de generación Netflow oAl transmitir datos sobre esta interacción a Netflow (incluso Cisco ASA o Firepower lo genera), obtenemos una valiosa fuente de información no solo para TI, sino también para la ciberseguridad. Cuando el equipo no comprende el protocolo de flujo, podemos utilizar exportadores especiales, soluciones de software o hardware que generan registros de flujo para el tráfico que pasa a través de ellos (con Cisco, el dispositivo Netflow Generation oAl transmitir datos sobre esta interacción a Netflow (incluso Cisco ASA o Firepower lo genera), obtenemos una valiosa fuente de información no solo para TI, sino también para la ciberseguridad. Cuando el equipo no comprende el protocolo de flujo, podemos utilizar exportadores especiales, soluciones de software o hardware que generan registros de flujo para el tráfico que pasa a través de ellos (para Cisco, el dispositivo de generación Netflow oque generan registros de flujo para el tráfico que pasa a través de ellos (con Cisco, Netflow Generation Appliance oque generan registros de flujo para el tráfico que pasa a través de ellos (con Cisco, Netflow Generation Appliance oSensor de flujo Stealthwatch ). Los algoritmos para detectar anomalías o firmas superpuestas en los flujos de Netflow, así como los métodos de aprendizaje automático, le permiten identificar desviaciones del comportamiento estándar del tráfico de red, que caracterizará las amenazas o problemas de seguridad de la información con la infraestructura de TI.

Vale la pena recordar que Netflow no puede decir qué se transmite dentro del tráfico de red (aunque ya existen tecnologías que le permiten reconocer las aplicaciones utilizadas y el código malicioso por Netflow), fue desarrollado para otras tareas. Pero puede decir quién "habló" y con quién, cómo y por cuánto tiempo. A pesar de la existencia de diferentes versiones de protocolos de flujo, la mayoría de ellos le permiten recopilar los siguientes datos:

  • Dirección IP de origen y destino
  • puertos de origen y destino
  • protocolo
  • tipo de servicio
  • interfaz fuente
  • marcas de tiempo de inicio y fin
  • La cantidad de información transmitida.

En algunas versiones, por ejemplo, en IPFIX o Netflow v9, puede extraer parte de la información del cuerpo de datos, lo que permite que el analizador Netflow (autónomo o integrado en SIEM) identifique las aplicaciones en ejecución. Toda esta información suele ser suficiente para detectar anomalías o incluso amenazas en el tráfico de red.

imagen

Netflow y SIEM: ¿cuál es la fuerza, hermano?


¿Qué sucede si el sistema de destino no genera registros o los intrusos los desactivan? ¿Qué hacer cuando simplemente no hay características de seguridad en el sistema de destino, porque cargan el procesador y ralentizan el sistema? ¿Qué hacer cuando un empleado trae su dispositivo personal que no está conectado a SIEM? Todavía tenemos la única fuente de información: el tráfico de red, que en cualquier caso es generado por el dispositivo objetivo. ¿Qué puede ayudar a identificar un Netflow "limpio" que pueda analizarse sin SIEM utilizando soluciones de Análisis de tráfico de red (NTA)? Aquí hay una breve lista de tales amenazas y anomalías:

  • código malicioso, ransomware y cripto mineros
  • interacción con servidores de comando
  • escaneo de red
  • Ataques de denegación de servicio
  • fuga de datos
  • hackear ssh o rdp
  • torrents y otras aplicaciones P2P
  • ,
  • ..

¿Y qué le dan los registros que recopila su SIEM? La capacidad de monitorear la actividad del usuario en los nodos, el acceso a los recursos, la entrada y salida de los sistemas, las alarmas de los equipos de red y las herramientas de seguridad, y mucho más. La combinación de registros y Netflow que llegan a SIEM y se analizan allí le permite identificar rápidamente nuevas sesiones y nuevo tráfico desde dispositivos que han sido atacados, incluidos aquellos que omiten su perímetro. Al combinar estos tipos de datos, también puede identificar características de seguridad de red configuradas incorrectamente. Netflow complementa las capacidades tradicionales de SIEM con la capacidad de detectar nuevos tipos de tráfico, sus ráfagas, interacción con recursos externos e internos, fugas de datos, distribución de código malicioso, interacción con los servidores del equipo,encapsulación de carga maliciosa en protocolos permitidos, etc.

La combinación de datos SIEM procesados ​​tradicionalmente con Netflow permite no solo ver más eventos de seguridad, sino también verlos más rápido, reduciendo el llamado parámetro TTD (Time-to-Detect) y, como resultado, el tiempo de respuesta. Está claro que el análisis SIEM y Netflow pueden funcionar de manera independiente y hacer bien su trabajo, pero es la combinación de estas dos soluciones lo que le permite lograr un efecto sinérgico.

Cambiar el patrón de comportamiento del tráfico puede indicar un comportamiento sospechoso o anormal. Por ejemplo, exceder el umbral para los datos cargados en Internet puede indicar una fuga. Un cambio en el tamaño de las consultas y respuestas de DNS en comparación con el RFC proporcionado puede caracterizar el hecho de la operación de código malicioso (según las estadísticas de Cisco, el 92% del malware usa DNS para recibir comandos, descargar datos o descargar actualizaciones). ¿Recuerdas la historia con Equifax? Luego, los atacantes pudieron acceder al portal web, y luego a los servidores de bases de datos internos, cargando lentamente grandes cantidades de datos al exterior. Por separado, todos estos eventos no fueron de gran interés y solo reunidos y enriquecidos con datos de Netflow, permitieron identificar incidentes de seguridad de la información. Este es otro caso para los sistemas de análisis de Netflow,que puede detectar un comportamiento no estándar tanto del portal web desde el que se frecuenta la consulta a la base de datos como de las bases de datos que de repente brindan muchos datos al portal. ya estoyDescribió este escenario en Habr anteriormente. SIEM, al recibir datos de Netflow, puede obtener un contexto adicional para eventos generados por IPS, ITU, proxies, antivirus, EDR, etc., para responder de manera más efectiva al incidente.

Otro ejemplo. Detección de ataques desconocidos para los que los sistemas de detección de intrusos no tienen firmas, debido a la correlación de anomalías de red y eventos de los hosts, así como a la activación de disparadores. Por ejemplo, escanear 100 nodos en 3 minutos puede caracterizar la operación de código malicioso que expande su cabeza de puente. Un aumento en el tiempo de respuesta del servidor puede caracterizar un ataque DDoS contra él y, por ejemplo, una falta de coincidencia en la cantidad de información recibida y enviada a través del protocolo DNS puede indicar una fuga de datos. Este es un caso que ya vimos anteriormente cuando hablé sobre encontrar una campaña de DNSpionage. Al mismo tiempo, puede observar que en un caso analizamos solo Netflow, y en el otro , también recopilamos datos de dispositivos terminales, cajas de arena, una puerta de enlace DNS, etc.

Otra área donde la integración de Netflow en SIEM puede ayudar es la conciencia situacional. Correlación de flujos con registros, contexto, información de geolocalización, actividad del usuario, datos de reputación. Por ejemplo, en una nota anterior, cité un caso con la detección de tráfico interno con nodos de Irán o Corea del Norte. Si no tiene contactos con estos países, tal vez esto sea una señal de código malicioso que roba información o piratas informáticos progubernamentales dirigidos a su empresa. Un sistema de análisis de anomalías de red puede hacer parte de este trabajo identificando la anomalía correspondiente. Pero si también desea comprender qué usuario estuvo involucrado en este incidente, necesitará un contexto adicional en forma de nombres de usuario de Active Directory.Netflow en sí no opera con esta información, por lo que debemos enriquecerla con información de AD. Si utilizaCisco Stealthwatch , para esto solo necesita integrarlo con Cisco ISE , que vinculará las direcciones IP y MAC con usuarios específicos y perfiles de dispositivos. ¿Qué sucede si Cisco ISE no se implementa en la red? La tarea de enriquecer Netflow con información del usuario es responsabilidad de SIEM.

Otro ejemplo. Tengo un sitio web ejecutándose en mi computadora que se utiliza para varias tareas. ¿Pero cuántos usuarios comunes pueden presumir de lo mismo? ¿De repente captura el tráfico inherente a la operación de un servidor web desde una computadora de usuario? O en el segmento donde se encuentran los usuarios que trabajan en una PC con Windows, de repente ves el tráfico inherente al sistema operativo Linux. ¿Quizás este usuario "práctico" decidió crear una máquina virtual con Linux, violando así la política de seguridad? Y también puede identificar utilidades para acceso remoto de esta manera (por ejemplo, RAT), criptomineros, aplicaciones en la nube o punto a punto, etc.

Si es partidario de un enfoque de proveedor único, la construcción de un sistema de seguridad basado en las soluciones de Cisco le permitirá reducir su dependencia de SIEM: todas las soluciones de Cisco, incluidos los firewalls, la protección de correo electrónico, el sandboxing, Cisco AMP para puntos finales y etc. puede intercambiar datos, contexto, eventos de seguridad, comandos entre ellos directamente. Pero si su infraestructura ha heredado muchas soluciones diferentes de diferentes fabricantes, entonces SIEM será el enlace que ayudará a construir una solución completa del zoológico de diferentes productos. En cualquier caso, el análisis del tráfico de red recolectado de la infraestructura de red existente, combinado con los datos que SIEM generalmente recolecta, expande los horizontes.La capacidad del servicio IS de ver más y responder más rápido.

Beneficios de usar Netflow en SIEM:

  • correlación de la actividad de la red con otra información sobre seguridad de la información recopilada del nivel de aplicaciones y PC / servidores
  • la capacidad de monitorear donde existen altos riesgos de violación de las leyes de privacidad (por ejemplo, GDPR) y puede analizar solo los encabezados o metadatos del tráfico de red, y no su contenido
  • detección de anomalías que caracterizan las primeras etapas del desarrollo de un incidente o ataques dirigidos
  • recopilación y almacenamiento de diversos datos que caracterizan el incidente y los proporcionan como parte de las investigaciones de SI o la interacción con las agencias de aplicación de la ley.

¿Bala de plata?


Pero no piense que Netflow es la bala de plata que todos han estado buscando durante tanto tiempo. También tiene desventajas. Por ejemplo, su procesamiento puede cargar el procesador y la memoria de equipos de red desactualizados o seleccionados incorrectamente y esto puede afectar negativamente su rendimiento y el ancho de banda de la red. Para trabajar eficazmente con Netflow, es posible que necesite su soporte de hardware o el uso de los llamados exportadores, quienes al pasar el tráfico a través de ellos mismos lo traducirán a Netflow (aquellos que han encontrado la introducción de IDS / COB en redes conmutadas, usaron las llamadas cintas o divisores para una tarea similar ) Ya he dado dos ejemplos de tales soluciones externas: Sensor de flujo Cisco Stealthwatchy el dispositivo Cisco Netflow Generation. Aunque, dada la reciente modernización de la red, se puede suponer que sus conmutadores y enrutadores ya admiten una u otra versión de Netflow y no necesitará ningún exportador adicional.

Otras características de Netflow que vale la pena conocer incluyen:

  • falsos positivos que pueden asociarse con una capacitación incorrecta o insuficiente del sistema de análisis, así como con un cambio en las operaciones de TI, sobre el cual el sistema de análisis aún no ha sido "informado"
  • Disminución del rendimiento y el impacto en el almacenamiento SIEM (hablaremos de esto aún más)
  • Los metadatos recopilados a través de Netflow no siempre permiten una investigación completa, lo que puede requerir tráfico sin procesar en el formato PCAP.

Opciones de integración SIEM con Netflow


¿Cuál de los SIEM en el mercado actual trabaja con tráfico de red? Debo decir que casi todo, pero de diferentes maneras y, a menudo, esto requiere una licencia paga por separado, que, a su vez, también se divide en opciones. Destacaría tres opciones para analizar Netflow en SIEM:

  • soporte integrado para Netflow en SIEM
  • exportadores / sensores propios para generar Netflow y transmitir a SIEM
  • Integración SIEM con soluciones externas de la clase Network Traffic Analysis (NTA).

SIEM con soporte integrado de Netflow


Por ejemplo, Microfocus ArcSight, que es bastante popular en el espacio SIEM soviético, tiene soporte incorporado para Netflow. Esta característica permite a SIEM correlacionar los flujos de red con otros eventos de seguridad sobre la marcha o enriquecerlos con datos de fuentes de Inteligencia de amenazas. Sin embargo, esta opción tiene sus inconvenientes, a saber:

  • -, , . ( , « », )?
  • -, Netflow SIEM, Netflow . ? SIEM , , , ? - «» Netflow ?

imagen

  • -, . ? VPN- ( ).
  • -, Netflow SIEM FPS ?
  • , , flow- (. ). Netflow, SIEM. Netflow — v5, , v9, IPv6, MPLS . Flexible Netflow ( Netflow v9), IPFIX, Netflow v10, sFlow, , , , NetStream, Jflow .. SIEM?

Si solo se enfrenta a la elección de SIEM, incluya en la lista de parámetros bajo consideración también el tipo de Netflow que genera su equipo. Si ya ha comprado SIEM, entonces no tiene muchas opciones. En este caso, debe considerar las siguientes opciones:

  • un analizador de anomalías de red IS separado (por ejemplo, Cisco Stealthwatch), que llevará a cabo todo el análisis por sí solo y dará sus resultados a SIEM
  • El recopilador de Netflow separado, que podrá enviar a SIEM resumen de análisis de flujos de red, y SIEM ya analizará estos datos.

¿Cuánto colgar en gramos, es decir, almacenado en bytes?


Por cierto, antes de pasar a la siguiente opción para integrar Netflow con SIEM, es hora de tocar la pregunta, ¿cuántos datos de Netflow recibiremos en nuestro sistema de análisis de eventos de seguridad? Para remedios o registros regulares, hay un número considerable de ejemplos y estadísticas sobre EPS (eventos por segundo). No hay muchos datos sobre FPS (flujo por segundo). El volumen promedio de Netflow es directamente proporcional a la cantidad de sockets TCP / UDP únicos creados por los dispositivos cliente y servidores en su red, que pueden variar mucho de un caso a otro. Y la inclusión del muestreo (es decir, la transferencia selectiva de datos de Netflow) también afecta la cantidad total de datos.

Entonces, ¿cuántos FPS podemos generar? Por supuesto, esto depende mucho de la situación, pero yo diría que para una estación de trabajo regular este número es, en promedio, 1.5 FPS y 6 FPS en la carga máxima. En otras palabras, si su red tiene 10 mil nodos y el FPS promedio para cada uno de ellos es 4, entonces la red genera aproximadamente 40 mil flujos por segundo. ¿Porque tanto? Como escribí anteriormente, depende de cuántas conexiones únicas generen sus aplicaciones o su red. Hoy en día, hay muchos programas "habladores" que se ejecutan en las computadoras de los usuarios, que cargan activamente contenido de Internet, como los navegadores, o constantemente buscan actualizaciones, como los antivirus. Aquí hay una lista de muestra de software y servicios que aumentan activamente el número de FPS en la red:

  • Adobe, antivirus, Java
  • Skype
  • clientes de correo electrónico
  • Netbios
  • navegadores
  • aplicaciones orientadas a la alimentación (Twitter, noticias, Telegram, etc.).

Una respuesta más precisa le indicará el análisis de Netflow en los segmentos de red que necesita, que se realiza con solo un comando en un dispositivo de red (según el fabricante).

La longitud de un registro de Netflow v5 es de 48 bytes. Para la novena versión de Netflow, no existe una cifra tan exacta, ya que esta versión le permite describir lo que incluirá en el registro y, por lo tanto, su longitud puede variar mucho. Pero si, más o menos, tomamos 100 bytes para la longitud promedio de un registro de flujo (y cada paquete de red puede generar 20-30 flujos), entonces podemos estimar cuántos datos se generarán y transferirán a SIEM. Al mismo tiempo, el volumen de almacenamiento SIEM para estos datos puede ser mayor (esto dependerá del formato de almacenamiento, indexación, compresión, copia de seguridad, etc.). Por cierto, al calcular la cantidad de FPS, recuerde que en el marco de un ataque DDoS, el concepto de "FPS promedio" no funciona, ya que cada conexión, cada paquete TCP SYN será una secuencia separada, y con un poderoso ataque DDoS, la cantidad de FPS en tu pico será muy grande.

Mencioné anteriormente que en el caso de transferir Netflow al SIEM central, tendrá que "manejarlo" a través de Internet. No piense que la generación de Netflow creará una gran carga en la red y reducirá su ancho de banda. Según nuestra investigación, dado que solo se transmite información de encabezado y telemetría adicional en Netflow, y no todo el cuerpo de datos, la carga aumentará en aproximadamente un 1-2% a la interfaz desde la que se exporta la telemetría de red (de hecho, utilizando muestreo y versiones de protocolo modernas Netflow este valor puede ser incluso menor en un orden de magnitud y variar al nivel de 0.1%).

Recolectar no puede ser analizado


Pero supongamos que aún decidió obtener un Netflow sin procesar en su SIEM. Este escenario tiene otro matiz. Es muy importante comprender que la disponibilidad del soporte de Netflow en SIEM no es suficiente; Es extremadamente importante poder manejar este Netflow desde un punto de vista de seguridad, es decir, tener reglas para analizar y correlacionar los flujos de Netflow integrados y actualizados constantemente para nuevos tipos de ataques. Digamos que Netflow nos da esta imagen:

imagen

Vemos un aumento en el protocolo SSH. De hecho, ahora estamos viendo la misma imagen con ataques al protocolo RDP. Esto es adivinar la contraseña. Pero esto se puede revelar solo con la condición de que tengamos una regla correspondiente, que de una serie de flujos de Netflow recopilará un evento "Contraseña coincidente". Entonces podemos decir que SIEM tiene soporte incorporado de Netflow y puede analizarlo desde un punto de vista de seguridad. Por lo tanto, al elegir este camino, debe preguntarle al vendedor qué puede analizar SIEM en Netflow "fuera de la caja" y, si nada, cuán laborioso es el proceso de describir sus propios procesadores Netflow y ¿tiene algún especialista que lo haga? Somos conscientes de que escribir un conector en Netflow no es tan difícil, a diferencia de las reglas para procesarlo e identificar anomalías en él que requieren un trabajo constante.Se trata de copiar el motor de otra persona para su IDS (Snort, Zeek o Suricata), pero no poder escribir firmas para ataques y exploits recientemente descubiertos de forma continua. En el ejemplo anterior, el sistema mismo debería reconocer un aumento en el tráfico en SSH y decirse que estos son ataques de "adivinación de contraseñas" en SSH (ya sea Telnet, RDP o FTP). Podría verse así (por ejemploCisco Stealthwatch Enterprise ):

imagen

Y luego puede investigar este incidente a un nivel más profundo, utilizando las capacidades proporcionadas por SIEM o una herramienta de análisis de Netflow separada. Sin la capacidad de "comprender" Netflow en términos de seguridad de la información, la presencia de soporte incorporado para Netflow es una ventaja dudosa para SIEM.

imagen

SIEM con su propio exportador de Netflow


Otro jugador en el mercado SIEM, LogRhythm, a su vez, ofrece un exportador adicional de transmisiones de NetMon, que puede ser útil en una infraestructura distribuida, así como en una red cuyo equipo no admite Netflow y requiere un generador de Netflow separado para el tráfico de red que pasa a través de él. De hecho, en esta realización, el fabricante SIEM asume las funciones de los proveedores de redes, desarrollando una solución para generar Netflow y reduciendo la carga en SIEM, lo que elimina la necesidad de procesar y almacenar Netflow sin procesar. La situación es similar al soporte de SSL Offload en muchos firewalls de nueva generación. Sí, existe allí, pero con un intercambio intensivo de tráfico HTTPS, la carga adicional en NGFW conduce a una disminución significativa en su rendimiento.Por lo tanto, en arquitecturas muy cargadas, generalmente se asigna un dispositivo separado para esta tarea, que asume la tarea de descifrar el tráfico SSL y luego devolverlo a NGFW. Lo mismo sucede con el procesamiento de SIEM Netflow en este escenario.

imagen

Está claro que este escenario también tiene un inconveniente: un aumento en el precio final de la solución, ya que además de pagar licencias por la cantidad de FPS analizados, también deberá pagar sensores adicionales que pasarán el tráfico a través de sí mismos y generarán Netflow. Además, deberá realizar cambios en la arquitectura de red, pero esto tendrá que hacerse de todos modos, por lo que lo llamaría no un inconveniente, sino una característica de este escenario. Si su equipo de red no sabe cómo generar Netflow y desea analizar las anomalías de la red, entonces la única opción para hacerlo es utilizar sensores separados. La única pregunta es qué será más barato: compre sensores del fabricante SIEM o use sensores de fabricantes de redes (por ejemplo, Cisco Netflow Generation Appliance) o desarrolladores de herramientas de análisis de anomalías de red (por ejemplo,Sensor de flujo de Cisco Stealthwatch Enterprise). En esta opción, también vale la pena averiguar si SIEM puede analizar Netflow desde el punto de vista de la seguridad de la información, o ¿solo tiene conectores en forma de exportadores / sensores extraídos (por lo general puede)?

SIEM, NTA


La tercera opción, la integración con soluciones de clase NTA, es bastante obvia, ya que, de hecho, NTA es el mismo generador de eventos de seguridad que NGFW, antivirus, escáner de seguridad, IPS, etc. Sin embargo, este escenario es interesante porque combina las dos herramientas de análisis de seguridad que tiene, pero puede trabajar con ellas por separado. NTA le permite realizar un análisis en profundidad del tráfico de red, detectar códigos maliciosos, ataques DDoS, fugas de información, monitorear usuarios remotos ... Al mismo tiempo, una buena herramienta de análisis de tráfico de red también le permite usar sensores separados en aquellos segmentos donde el equipo de red no es compatible con Netflow o sus La inclusión conduce a un aumento de la carga en el equipo de red. NTA en este escenario le permite agregar, procesar, analizar Netflow (en sus diferentes versiones),y en SIEM solo dan alarmas sobre el hecho de la detección de una u otra actividad maliciosa. Obviamente, esta opción también tiene sentido cuando usted o su personal de TI ya tienen una solución de clase NTA para la resolución de problemas de red y también se puede usar para tareas de seguridad de red. O cuando, por el contrario, desea compartir los gastos de la solución NTA con sus networkers, quienes la usarán para sus tareas y usted para las suyas.quién lo usará para sus tareas y usted para las suyas.quién lo usará para sus tareas y usted para las suyas.

La desventaja de esta opción es el costo adicional de una solución de clase NTA, así como la necesidad de una doble capacitación de especialistas en los conceptos básicos para trabajar con dos soluciones diferentes. Pero, por otro lado, una solución separada para analizar el tráfico de red permitirá realizar investigaciones de incidentes más profundas que con un solo SIEM con soporte incorporado de Netflow y aplicaciones más flexibles que con el fabricante SIEM que tiene sensores Netflow separados. Pero vale la pena recordar que cuando hablamos de una solución separada de la clase NTA, me refiero a la solución de seguridad, y no solo a una herramienta para analizar el tráfico de red o monitorear el rendimiento de la red. Por ejemplo, el SolarWinds NTA ya mencionado anteriormente analiza bien el tráfico de la red para soportar las tareas de TI, pero lo hace muy mal por motivos de seguridad de la información.Lo mismo ocurre con 5View de InfoVista o Visual TruView de Fluke. Y el mismo, por ejemplo,Cisco Stealthwatch Enterprise puede ser utilizado por ambos en la empresa.

imagen

¿Qué buscar al elegir?


Al elegir una solución NTA con fines de seguridad, así como al analizar exportadores / sensores proporcionados por SIEM o proveedores de SIEM con soporte de Netflow, recomendaría prestar atención a los siguientes criterios:

  • Tipos de actividad maliciosa detectable. Usted toma una herramienta para monitorear la seguridad de la información; Es lógico suponer que debe ser capaz de identificar varias anomalías y amenazas relacionadas con la seguridad de la información "fuera de la caja". Además, este parámetro se divide en tres partes: algoritmos integrados para detectar varios tipos de amenazas de seguridad de la información, escribir manejadores / reglas personalizadas y admitir fuentes externas de Inteligencia de amenazas para enriquecer los flujos analizados con datos sobre las amenazas.
  • Netflow. , , .
  • . , 1 ( FPS)? 60 FPS, NTA 40 , , , , , 80 FPS.
  • . , flat, … , . , . . , (, , Argus, Fluke, Plixer, Riverbed SolarWinds), , . , . , ; , . , , Cisco Stealthwatch.
  • . , , , , . — NTA. , Cisco nfdump OSU FlowTools Lancope, .
  • . , - . :

    • /
    • flow cache ( cash flow :-)
    • . MAC-, VLAN, MPLS, TCP, , , , , ( IPFIX ).
  • . Netflow SIEM, SIEM NTA . , , (, ) REST API, syslog ..

Si se tratara de qué elegir, independientemente de SIEM, también recomendaría mirar hacia las oportunidades de búsqueda de amenazas que ofrece la solución elegida. Pero dado que el tema de la nota se eligió un poco diferente, no prestaremos atención a este aspecto ahora.

Problema de precio


Si observa estas tres opciones desde el punto de vista de su costo, la tercera opción resultará ser la más costosa desde el punto de vista de los gastos de capital (sujeto a las mismas capacidades para el análisis de Netflow en los tres escenarios). Es entendible. Además del costo de SIEM, necesitará una solución separada para analizar el tráfico de red, que consistirá al menos en un sistema de control y el número requerido de recolectores que recolectan Netflow de varios exportadores / sensores. Por otro lado, no importa cuánto expanda la cobertura de su red con nuevos exportadores / sensores, no afectará el costo de SIEM y la infraestructura para ello, ya que funcionará con alarmas ya procesadas, y no con flujos de flujo Netflow “sin procesar”, que (señales) serán varios órdenes de magnitud menos.

La primera opción parece la más atractiva desde el punto de vista de su precio, ya que no tenemos que pagar más por la capacitación de analistas y administradores de NTA, o por exportadores / sensores adicionales; saber, transferir flujos de Netflow a SIEM y todo. Sin embargo, el costo de la infraestructura para SIEM aumentará significativamente, ya que tendrá que almacenar flujos de Netflow sin procesar, lo que requerirá expandir su almacenamiento existente. La segunda opción es intermedia entre los dos extremos, tanto en términos de capacidades de análisis de Netflow como en términos de costo. En cualquier caso, en las dos primeras opciones, vale la pena consultar con el fabricante de SIEM el costo total de propiedad de la solución en función de los desafíos, así como el FPS actual y esperado y, como resultado, los cambios en el costo de las licencias de SIEM y el almacenamiento para él. Toma por ejemploLogRhythm y su subsistema para el análisis de Netflow. Hay al menos tres opciones para su implementación y, como consecuencia, la fijación de precios. La opción más joven, Freemium solo puede enviar alarmas a SIEM, el ancho de banda no puede exceder 1 GB / s, la capacidad de almacenamiento es de solo 1 GB (esto es aproximadamente un día de almacenamiento de Netflow sin muestreo), el período de almacenamiento del índice no es más de 3 días, y no hay correlación con fuentes de datos adicionales, y el soporte funciona solo en línea y a través de la comunidad. En la próxima versión, NetMon, los indicadores son mejores (ancho de banda de hasta 10 GB / s para todos los exportadores, el almacenamiento es ilimitado, el índice se almacena hasta por un mes, pero tampoco hay correlación con otras fuentes). Y solo en la versión premium de NetworkXDR no tiene restricciones, pero se destaca como "un kilómetro de carreteras de Moscú", es decir, no es barato.

En uno de los proyectos, nos enfrentamos con el hecho de que con un volumen diario de telemetría de red de 1 TB y enviarlo a SIEM con soporte integrado de Netflow, el costo total de la solución fue de aproximadamente 600 mil dólares estadounidenses (incluso antes del próximo salto en el curso). Al mismo tiempo, parte de estos datos permanecieron sin procesar debido a la falta de reglas apropiadas en el SIEM y duplicados. El uso de una solución NTA separada (en nuestro caso fue Cisco Stealthwatch Enterprise ) condujo a una reducción del 80% en el volumen de datos transferidos a SIEM, y el costo de la solución se redujo a 99 mil dólares estadounidenses. Las matemáticas pueden diferir de un proyecto a otro, pero notamos que cuanto más Netflow necesitemos procesar, más costosa será la infraestructura de SIEM para procesarla. ¿Porqué es eso?

Veamos un ejemplo. Cuando un usuario se conecta al servidor, desde el punto de vista del análisis clásico de eventos de seguridad de la información, tratamos, condicionalmente, con un solo evento que "eliminamos" del servidor, enviándolo, por ejemplo, a través de syslog a SIEM (de hecho, habrá dos eventos: un intento conexión y su resultado). Si este evento se descompone en componentes de red, veremos que habrá un orden de magnitud más hilos generados. Por ejemplo, el número promedio de "salto" (salto) desde el cliente al servidor es 5-6 en la red promedio. Cada conmutador o enrutador a través del cual la solicitud pasa del cliente al lado del servidor genera sus entradas de Netflow que describen el tráfico que pasa. Además, esto se hace para cada dirección de la sesión (solicitud y respuesta) por separado. Resulta que allí,donde solo se generaron 1-2 eventos a nivel de aplicación, los flujos de Netflow requirieron al menos 10 veces más (en realidad aún más, ya que un paquete de red genera alrededor de 20-30 flujos de Netflow). Y no solo tendremos que pagar por todas estas docenas de hilos (aunque el evento aún es uno) y asignar espacio para su almacenamiento. Entonces, SIEM también tendrá que procesarlos, eliminar duplicados, combinar flujos multidireccionales dentro de una sesión y solo luego correlacionar estos datos con otros eventos. Por lo tanto, el costo total de una solución aparentemente obvia puede ser mayor que en el caso de un exportador de Netflow separado o una solución de análisis de anomalías de red independiente integrada con SIEM.entonces un paquete de red genera alrededor de 20-30 flujos de Netflow). Y no solo tendremos que pagar por todas estas docenas de hilos (aunque el evento aún es uno) y asignar espacio para su almacenamiento. Entonces, SIEM también tendrá que procesarlos, eliminar duplicados, combinar flujos multidireccionales dentro de una sesión y solo luego correlacionar estos datos con otros eventos. Por lo tanto, el costo total de una solución aparentemente obvia puede ser mayor que en el caso de un exportador de Netflow separado o una solución de análisis de anomalías de red independiente integrada con SIEM.entonces un paquete de red genera alrededor de 20-30 flujos de Netflow). Y no solo tendremos que pagar por todas estas docenas de hilos (aunque el evento aún es uno) y asignar espacio para su almacenamiento. Entonces, SIEM también tendrá que procesarlos, eliminar duplicados, combinar flujos multidireccionales dentro de una sesión y solo luego correlacionar estos datos con otros eventos. Por lo tanto, el costo total de una solución aparentemente obvia puede ser mayor que en el caso de un exportador de Netflow separado o una solución de análisis de anomalías de red independiente integrada con SIEM.para combinar flujos multidireccionales dentro de una sesión y solo entonces correlacionar estos datos con otros eventos. Por lo tanto, el costo total de una solución aparentemente obvia puede ser mayor que en el caso de un exportador de Netflow separado o una solución de análisis de anomalías de red independiente integrada con SIEM.para combinar flujos multidireccionales dentro de una sesión y solo entonces correlacionar estos datos con otros eventos. Por lo tanto, el costo total de una solución aparentemente obvia puede ser mayor que en el caso de un exportador de Netflow separado o una solución de análisis de anomalías de red independiente integrada con SIEM.

Y estos analizadores externos de Netflow pueden usarse en uno de dos escenarios. El primero es la transferencia a SIEM de telemetría optimizada, libre de repeticiones (deduplicado), combinando flujos multidireccionales. Según nuestra experiencia (y Stealthwatch Enterprise puede funcionar en este modo), puedo decir que esto reduce seis veces el volumen de telemetría transmitida a SIEM, que, en este escenario, aún debería poder analizar Netflow desde un punto de vista de seguridad.

imagen

El segundo escenario supone que todo el procesamiento se lleva a cabo en una solución de la clase NTA, y solo las alarmas recibidas como resultado del procesamiento de Netflow se reciben en SIEM. Esta opción reduce aún más datos enviados a SIEM, reduciendo el costo de sus licencias e infraestructura. Sí, y SIEM ya no es necesario para poder analizar Netflow en bruto, lo que amplía las posibilidades de elegir herramientas para analizar eventos de seguridad de la información.

imagen

¿Hay alguna alternativa?


Después de examinar las opciones para usar Netflow en SIEM para detectar más eventos de seguridad que sin Netflow, veamos posibles alternativas.

Herramientas de diagnóstico de red


Puede intentar usar las herramientas de diagnóstico de red utilizadas para evaluar el ancho de banda de la red, la disponibilidad de nodos y segmentos internos, cargas máximas, etc. Por ejemplo, SolarWinds NetFlow Traffic Analyzer. Estas soluciones no están diseñadas para detectar anomalías y amenazas de IS, pero se pueden usar para transferir información de flujo a SIEM, que puede analizar Netflow. Esto cargará SIEM, como describí anteriormente, y ¿tiene que decidir si está listo para esto? Es cierto que vale la pena aclarar primero si el analizador de red puede enviar datos de Netflow a sistemas externos. A veces solo pueden dar estadísticas resumidas o generar alarmas, lo que claramente no es suficiente para las tareas de IS.

imagen

Sistemas de detección de intrusos y NGFW


Network IPS y NGFW son otra alternativa. Pueden mirar dentro del tráfico de red y pueden detectar muchas amenazas a través de un mecanismo de inspección de red profunda ... pero en el perímetro. Aún así, generalmente NGFW e IPS se colocan en el borde de la red corporativa e Internet y solo ven lo que pasa a través de ellos. Instalar estos dispositivos, "de hierro" o virtuales, en todos los lugares que le interesen será demasiado costoso y, en algunos casos, técnicamente imposible. Hablando sobre el borde o el perímetro, vale la pena recordar que la interfaz entre el centro de datos corporativo y los segmentos de usuarios también es el borde. Y la unión entre la red corporativa e industrial, también. Pero, en cualquier caso, la instalación de sensores IPS o NGFW adicionales puede afectar su billetera dolorosamente, mientras que Netflow se recolectará de los equipos de red ya comprados e implementados.

Herramientas de investigación de incidentes de red


Las soluciones de clase de Network Forensics Tool (NFT) le permiten almacenar, procesar y analizar el tráfico de red para investigar incidentes. Pero hay una diferencia significativa entre este tipo de solución y NTA: NFT funciona con una copia completa del tráfico, es decir, generalmente con archivos PCAP y NTA con registros al respecto. Y si las soluciones de análisis de Netflow funcionan casi en tiempo real, entonces NFT, con un retraso significativo. Además, cualquier solución que funcione con PCAP (o de otra manera para capturar y guardar una copia de todo el tráfico de red) se encontrará con el problema de un lugar para almacenar todos los datos recopilados.

Imagine que tiene un puerto en un dispositivo de red de 1 Gb / s. Con una longitud de paquete de 64 bytes, este puerto podrá pasar a través de 1953125 paquetes por segundo, y con una longitud de 1500 bytes - 83,333 paquetes. Es decir, dependiendo de la longitud del paquete (y esto depende de las aplicaciones en la red), tendremos de aproximadamente 80 mil a 2 millones de paquetes por segundo, que tendremos que guardar. En un día, dicho puerto permitirá 86400 Gbit / so casi 11 TB. Casi 4 PB se ejecutarán durante el año, y esto es solo para un puerto, del cual podemos tener miles y decenas de miles en nuestra red. Incluso el almacenamiento selectivo del tráfico no facilitará en gran medida nuestras vidas. Por lo tanto, se necesitan soluciones de clase NFT, pero no pueden reemplazar a los analizadores de Netflow. Estas son herramientas que resuelven diferentes tareas: monitoreo e investigación de incidentes.Por lo general, estas soluciones funcionan en pares: Netflow nos permite identificar incidentes y NFT ya recopila datos detallados sobre ellos en forma de capturar todo el tráfico de red.

" Pero existe SIEM con NFT, por ejemplo, IBM QRadar Incident Forensics o RSA Security Analytics, que le permite trabajar con una copia completa del tráfico de red y todos los metadatos de Netflow estarán disponibles automáticamente en SIEM"¡Sí, lo hay! Además, la ventaja de esta solución es la posibilidad de reconstruir todas las sesiones de red de interés y visualizarlas, lo que puede facilitar la investigación de incidentes. Este SIEM le permite tomar el lugar del atacante y ver todo lo que ve. Pero esta ventaja está oculta y un serio inconveniente que mencioné anteriormente es que almacenar una copia completa del tráfico de red requiere un almacenamiento grande, no tan grande que puede costar como un SIEM separado, o incluso más (más que almacenar incluso solo Netflow sin procesar Es posible que deba elegir qué sesiones específicas guardar para ahorrar espacio, y esto puede conducir a la pérdida de tráfico. Además, en caso de cumplir con los requisitos legales para almacenar datos relacionados con incidentes,Tendrá que romperlos o pagar dinero extra por el almacenamiento. Otra característica de esta solución es la necesidad de guardar el tráfico que ya ha sido descifrado en SIEM, lo que significa que deberá revisar la arquitectura de su sistema de monitoreo para poder descifrar el tráfico y enviarlo a SIEM. Y no olvide que tales soluciones aún se centran en realizar investigaciones, lo que requiere personal calificado, y no en detectar anomalías y amenazas utilizando algoritmos listos para usar.sin embargo, tales decisiones se centran en realizar investigaciones, lo que requiere personal calificado, y no en detectar anomalías y amenazas utilizando algoritmos listos para usar.sin embargo, tales decisiones se centran en realizar investigaciones, lo que requiere personal calificado, y no en detectar anomalías y amenazas utilizando algoritmos listos para usar.

En este escenario, aún miraría el análisis inicial del tráfico de red usando Netflow, y solo entonces, para los eventos e incidentes que me interesen, permitiría el registro del tráfico de red. Esto ahorrará y no gastará recursos en el almacenamiento de "todo".

Conclusión


Entonces, para resumir brevemente. Netflow es una fuente valiosa de datos para monitorear la seguridad de las redes corporativas y departamentales, a menudo la única que se puede recopilar y en función de la cual puede tomar decisiones sobre la presencia o ausencia de amenazas en su entorno. En principio, Netflow también se puede analizar de forma independiente utilizando soluciones de clase NTA, que, con una gran base de reglas y algoritmos para detectar actividad maliciosa y anormal, pueden detectar incidentes rápidamente y responder a ellos. La integración de Netflow con los datos recopilados por SIEM nos brinda mucho más. SIEM comienza a ver lo que no ha visto antes y lo ve mucho antes de que podamos ser perjudicados. Al mismo tiempo, no necesitamos realizar cambios importantes en la infraestructura de monitoreo existente, ya que ya tenemos equipos de red,- solo necesita redirigir Netflow a SIEM, directamente o mediante soluciones intermedias. Habilitar Netflow también me permite lograr una victoria pequeña pero rápida: casi todos nuestros pilotos de solucionesCisco Stealthwatch Enterprise termina con el hecho de que detectamos ciertas infracciones de las políticas de IS que el servicio de IS no había visto anteriormente. Netflow les permitió ser vistos, y su integración con SIEM, para obtener un efecto sinérgico de las herramientas de monitoreo de red aplicadas y el sistema de actividad.

More articles:


All Articles