Imagine la situación: pasó mucho tiempo escribiendo y depurando reglas de correlación, y un día después descubrió que no funcionaban. Como dicen, esto nunca ha sucedido y aquí de nuevo! Luego resulta que por la noche la red se actualizó una vez más y se reemplazaron un par de servidores, pero las reglas de correlación no tienen esto en cuenta. En este artículo, le mostraremos cómo enseñarle a SIEM a adaptarse al panorama cambiante de la infraestructura.



Nos estamos acercando cada vez más al final de la serie de artículos dedicados a la creación de reglas de correlación adaptativa que funcionan de forma inmediata. El artículo resultó ser largo, quien quiera puede llegar inmediatamente a conclusiones .

En el artículo "Metodología para normalizar eventos" resumimos técnicas que ayudarán a minimizar el problema de la pérdida de datos y la normalización incorrecta de los eventos iniciales. Sin embargo, ¿se puede argumentar que, si se reduce el papel de los errores de normalización, es posible hacer reglas de correlación que funcionen de forma inmediata? Teóricamente, sí, si el objeto de monitoreo monitoreado por SIEM sería estático y funcionaría exclusivamente como está escrito en los términos de referencia. Pero en la práctica resulta que en el mundo real no hay nada estático.

Por lo tanto, consideraremos con más detalle el objeto de monitoreo. SIEM recopila registros de fuentes, de ellos extrae direcciones IP, cuentas de usuario, acceso a archivos y claves de registro, interacciones de red. Si todo se resume, esto no es más que información sobre las etapas del ciclo de vida de un sistema automatizado (en adelante, AS). Por lo tanto, el objeto de monitoreo SIEM es un sistema automatizado en su totalidad o en parte.

Un sistema de altavoces no es un objeto estático, tiende a cambiar constantemente: se introducen nuevos trabajos y servidores, se desarma el equipo viejo y se reemplaza por uno nuevo, los sistemas se "bloquean" debido a errores y se restauran de las copias de seguridad. La dinámica a nivel de red, como el direccionamiento dinámico o el enrutamiento, cambia la cara de los altavoces todos los días. ¿Cómo verificarlo? Intente encontrar en su empresa un esquema L3 completo y actual de la red y verifique con los administradores de la red cuánto refleja el estado actual de las cosas.

Cuando desarrolle reglas de correlación, intente proceder de la apariencia de los hablantes aquí y ahora. Al probar las reglas de correlación, las refina a un estado en el que pueden trabajar con el menor número de falsos positivos en la configuración actual del altavoz. Como los hablantes cambian constantemente, las reglas de correlación, tarde o temprano, tendrán que actualizarse.

Ahora, compliquemos la tarea y consideremos las reglas proporcionadas por expertos externos, como los SOC comerciales, los integradores que implementan SIEM o los propios desarrolladores de soluciones SIEM. Estas reglas no incluyen las características de sus altavoces (el contexto de ejecución), no están optimizadas para ellos. Este problema es otro obstáculo en el concepto de reglas de correlación que funcionan de forma inmediata. Su solución puede ser ese SIEM dentro de sí mismo:

1. Construye un modelo de los altavoces observados.
2. Siempre mantiene este modelo actualizado.
3. Le permite usar este modelo como contexto de ejecución en las reglas de correlación.

Contexto - Modelo de sistema automatizado

Primero, describimos la composición del modelo de altavoz. Si pasamos a la definición clásica de un término de GOST 34.003-90 , entonces un AS es "un sistema que consiste en personal y un conjunto de herramientas de automatización para sus actividades que implementa tecnología de información para realizar funciones establecidas". Es importante que al implementar tecnología de la información, el personal (usuarios) y las herramientas de automatización operen con datos.

Dado que SIEM recopila información de muchas fuentes diferentes, incluidas TI, seguridad de la información y aplicaciones comerciales, todas las partes de esta definición serán "visibles" para nosotros directamente en los eventos.

A continuación, describiremos cómo se ve el modelo creado para entidades como el usuario, un conjunto de herramientas de automatización (en lo sucesivo, los sistemas de red y de computadora) y los datos.

Desafortunadamente, es bastante difícil modelar procesos tecnológicos dentro del marco de SIEM, porque esa clase de soluciones no está destinada a esto. Sin embargo, parte de los procesos es visible a través de los modelos de comportamiento de estas entidades.


Modelo de altavoz general

Además consideraremos cada entidad y nos detendremos en:

• identificación única;
• la composición del modelo;
• encontrar los datos necesarios para el modelo;
• la naturaleza del cambio en los datos de la entidad;
• actualizar datos en el modelo cuando cambian.

Modelo de usuario

Identificación

Un usuario de un AS debe entenderse como una persona específica: un empleado de una empresa, contratista o profesional independiente. Es importante que haya autorizado el acceso a los altavoces.

La información sobre los usuarios de AS generalmente está fragmentada en muchos sistemas. Para armarlo, debes hacer un esfuerzo. Veamos un ejemplo de dónde y qué información se puede recopilar para un usuario específico.

1. Microsoft Active Directory y Microsoft Exchange. De ellos podemos averiguar su nombre de usuario principal de dominio y dirección de correo electrónico.
2. El Cisco Identity Services Engine (ISE) almacena su segundo inicio de sesión para acceso remoto a través de VPN.
3. La base de datos del portal interno almacena su tercer inicio de sesión.
4. Si el usuario es un administrador de la base de datos, el cuarto inicio de sesión se almacena en el DBMS, y tal vez no uno.
5. Base de datos de recursos humanos, en la que se almacena su nombre completo (en caso de que Active Directory fuera demasiado vago para obtener al usuario de acuerdo con todas las reglas).

Por lo tanto, si la empresa no cuenta con soluciones de gestión de identidad o de derechos de usuario que al menos de alguna manera ayudan a reunir esta información de identificación dispareja, deberá hacerlo usted mismo en SIEM manualmente.

Para resumir:

1. SIEM requiere una sola identificación de usuario.
2. Cuando las cuentas de usuario aparecen en cualquier registro, en cualquier sistema, debemos identificarlo de manera única y colocar nuestro propio identificador de usuario único.

Composición modelo

Al componer un modelo de cualquier entidad, lo dividimos en dos bloques. El primer bloque se usa para almacenar información general sobre la entidad, el segundo es responsable de compilar un modelo del comportamiento de la entidad. Este perfil puede ser usado por las reglas de correlación para identificar desviaciones anormales en el comportamiento de una entidad.

Como mínimo, se debe incluir lo siguiente en el modelo de usuario general:

• ID de usuario único en SIEM
• Todos sus identificadores de varios sistemas, incluyendo:
  
  • direcciones de correo electrónico externas e internas;
  • Nombre completo;
  • Cuenta de sistema operativo local
  • cuenta de dominio;
  • Cuenta VPN
  • Cuenta proxy
  • Cuentas DBMS
  • Cuentas en otros sistemas de aplicación.
• Unidad organizativa en Microsoft Active Directory a la que pertenece el usuario;
• Grupos de Microsoft Active Directory a los que pertenece el usuario.

Como mínimo, el modelo de comportamiento de un usuario debe incluir:

• tipo de conexión utilizada (local, remota) y tipo de canal de comunicación (cableado, inalámbrico);
• dispositivos utilizados para acceder a la red corporativa;
• aplicaciones usadas;
• geo-encuadernación, especialmente para usuarios remotos;
• recursos de la empresa a los que se conecta el usuario;
• a quién y qué transferencias de datos (flujos de información).

Modelo de usuario

Perfilar los flujos de información es una tarea difícil para la cual SIEM a menudo carece de mecanismos convenientes y simples. Pero la creación de dicho perfil puede comenzar con el correo electrónico y los recursos de red compartidos utilizados.

Fuentes de datos para el modelo

¿Dónde obtener los datos necesarios para construir el modelo? Considere los dos principios principales para obtener información disponible en la mayoría de los SIEM: métodos de recopilación activos y pasivos.

Con el método activo, SIEM se convierte en fuentes que contienen los datos necesarios para construir el modelo.
Con el método pasivo, el modelo se llena en base a datos de eventos recibidos en SIEM de fuentes.

Como regla general, para obtener el modelo más completo, es mejor combinar dos métodos.

Es importante comprender que los datos recopilados en el marco del modelo deben actualizarse constantemente y hacerse en modo automático en lugar de manual. Exactamente los mismos métodos que se utilizan para su recopilación inicial serán adecuados para actualizar los datos.

Considere qué fuentes pueden proporcionar datos para construir el modelo y de qué manera puede obtener la información necesaria de ellos.

Modelo de red y sistemas informáticos

Identificación

Por elementos de red y sistemas informáticos nos referimos a estaciones de trabajo, servidores y equipos de red, y herramientas de seguridad de la información. Por el momento, en SIEM y en las soluciones de gestión de vulnerabilidades, se denominan activos.

Parece bastante obvio que dichos activos se pueden identificar fácilmente por dirección IP, dirección MAC, FQDN o nombre de host (en adelante, las claves de identificación originales). ¿Es este siempre el caso? Como se indicó anteriormente, algunos cambios tienen lugar constantemente en la UA. Veamos algunos de estos cambios y pensemos en cómo se comportan nuestras claves de identificación originales.

1. Usar en una red DHCP. Las direcciones IP de los activos están cambiando.
2. Cambio de nodos en una configuración de clúster. Dependiendo del tipo de agrupación, MAC e IP pueden cambiar.
3. Restaurar un sistema desde una copia de seguridad en otro servidor debido a una falla crítica. Las direcciones MAC cambian, a veces IP, FQDN y nombre de host.
4. Reemplazo planificado, modernización de equipos o partes de altavoces. Casi todas las llaves pueden cambiar.

En una empresa pequeña, estos cambios pueden ser extremadamente raros y pueden ser manejados por los expertos a cargo de SIEM. Pero, ¿y si una empresa con una amplia red de sucursales? Y lejos de siempre, el servicio de IS tiene comunicaciones bien establecidas con el servicio de TI, lo que significa que el experto SIEM puede no obtener la información necesaria sobre los cambios en el AS.

Dado que no puede confiar en IP, MAC, FQDN o nombre de host por separado para identificar un activo, puede intentar identificarlo de inmediato mediante los 4 parámetros. Aquí nos enfrentamos a un problema global: SIEM opera en eventos y casi nunca contienen todas las claves de identificación originales al mismo tiempo.

¿Cómo se puede resolver? Veamos algunas opciones:

1. Método activo que utiliza soluciones del nivel de la base de datos de gestión de configuración (CMDB) . Se puede obtener información sobre las claves de identificación originales desde allí. ¿Pero el CMDB contiene todas las claves de origen de los activos necesarios para la identificación? Y, lo más importante, ¿tiene en cuenta los cambios en los altavoces descritos anteriormente? También es importante tener en cuenta el tiempo de actualización de datos en CMDB, si los datos se retrasan docenas de minutos u horas detrás del estado real del AS; lo más probable es que esta solución no sea adecuada para su uso en la correlación de eventos en SIEM.
2. Forma activa utilizando la solución de gestión de vulnerabilidades . Puede cargar sus informes a SIEM, como, por ejemplo, Micro focus ArcSight. ¿Pero hay una garantía de que un escáner de terceros traerá todos los datos necesarios para la identificación? Cuán relevantes serán si los escaneos se realizan no más de una vez al mes (promedio para grandes empresas), y lejos de cubrir toda la infraestructura.
3. Forma pasiva . Identifique activos de eventos, a pesar de sus datos incompletos e inexactos. Los eventos no contienen todas las claves; diferentes fuentes envían diferentes conjuntos de claves. Sin embargo, esta es la forma más rápida de obtener información sobre los cambios en los altavoces. Las fuentes, por regla general, generan eventos en todas las situaciones descritas anteriormente, con la excepción del reemplazo planificado del equipo.
4. Forma híbrida . Aproveche todos los enfoques a la vez:
   
   • La recolección activa con CMDB permite el llenado inicial rápido de activos SIEM.
   • La integración con Vulnerability Management agregará la información que falta.
   • Un análisis de eventos le permitirá actualizar rápidamente el modelo, teniendo en cuenta los detalles de cada fuente individualmente.
   
   El método híbrido le permite nivelar los problemas de los demás, pero es difícil de implementar.

Por el momento, solo trabajé con dos soluciones en las que los fabricantes tenían la experiencia para implementar este enfoque: IBM QRadar (descripción general por referencia , los detalles del algoritmo están cerrados) y Positive Technologies MaxPatrol SIEM (los detalles del algoritmo están cerrados). Por el momento, ambas compañías continúan usando y mejorando con precisión el enfoque híbrido.

Entonces

1. Las estaciones de trabajo, los equipos de red y servidor deben identificarse de manera híbrida, agregando datos de CMDB, sistemas de gestión de vulnerabilidades y eventos de las propias fuentes.
2. Para la correcta combinación y actualización de la información recopilada para su identificación, es necesario contar con mecanismos expertos que tengan en cuenta las características de cada fuente.

Composición modelo

Los sistemas informáticos, incluidos los sistemas y aplicaciones de software instalados en ellos, llevan mucha información necesaria para mejorar la precisión de las reglas de correlación.

Al igual que el modelo de usuario, el modelo de red y sistemas informáticos consta de una parte común y de comportamiento.

La composición del modelo general de red y sistemas informáticos debe incluir al menos:

• hardware (incluidos dispositivos externos);
• usuarios terminados;
• servicios instalados y su paquete con puertos abiertos;
• software instalado y su versión;
• actualizaciones instaladas;
• vulnerabilidades existentes;
• tareas programadas
• lista de software para el inicio;
• tablas de enrutamiento;
• recursos de red compartidos

La composición del modelo de comportamiento de la red y los sistemas informáticos debe incluir al menos:

• Interacciones de red de L3 y L4 (con qué interactúa y según qué protocolos);
• La cantidad promedio de datos transmitidos por semana;
• qué usuarios están usando;
• desde qué nodos se implementa el control remoto;
• estadísticas del funcionamiento de las funciones de seguridad para este host (red y local).

Modelo de red y sistemas informáticos

Fuentes de datos para el modelo

La recopilación de información para este modelo es posible de dos maneras: activa y pasiva.

Considere el modelo general:

Modelo de datos protegidos

Identificación

Pasemos al último componente del contexto: el modelo de datos protegidos.

La mayoría de las veces, SIEM no se usa para monitorear datos protegidos, ya que existen soluciones para la clase de Prevención de Fugas de Datos (DLP) para esto. Sin embargo, este conocimiento ayuda a evaluar con mayor precisión la importancia del incidente. Por ejemplo, al escribir una regla de correlación, sería útil saber que el incidente no solo ocurre en alguna estación de trabajo, sino en la estación que actualmente almacena el informe financiero del año u otra información confidencial.

La identificación de la información confidencial se implementa mediante un motor de búsqueda de huellas digitales en la propia solución DLP. La especificidad del mecanismo no permite implementarlo dentro de SIEM. Por lo tanto, en términos de identificación de datos protegidos, es posible utilizar solo una estrecha integración con soluciones de clase DLP.

Composición modelo

Debido al hecho de que DLP implementa la mayor parte del monitoreo y protección de la información confidencial, la composición del modelo en SIEM es bastante compacta.

Como mínimo, se debe incluir lo siguiente en el modelo general de datos protegidos:

• en qué activos se almacena la información confidencial;
• qué usuarios tienen acceso a información confidencial.

Al menos lo siguiente debe incluirse en el modelo de comportamiento de los datos protegidos:

• entre qué activos se transmite información confidencial;
• entre qué usuarios se transmite información confidencial.

Modelo de datos protegidos

Fuentes de datos para el modelo

Para construir un modelo de datos protegidos, también están disponibles dos métodos para obtener información: activa y pasiva.

Considere el modelo general:

Modelos de mecanismos de implementación en SIEM

Veamos cómo es posible implementar un modelo de altavoz en SIEM. Para hacer esto, a nivel SIEM, se deben abordar dos cuestiones principales:

1. Cómo implementar la recopilación de datos activa y pasiva.
2. Dónde y de qué forma almacenar el modelo.

La recopilación de datos activos para el modelo, por regla general, se lleva a cabo mediante mecanismos de integración SIEM con escáneres de seguridad. Además, la recopilación activa se puede realizar descargando datos de fuentes externas, por ejemplo, bases de datos.

La recolección pasiva se lleva a cabo analizando los eventos que pasan por el SIEM.

Como regla general, en SIEM de la generación actual para almacenar los datos del modelo anterior, se utilizan las listas de tablas / Lista activa / Conjunto de referencia del conjunto y similares. Con la recopilación de datos activa, las tareas planificadas se crean para completarlas desde fuentes externas. Con la recopilación pasiva, se crean reglas de correlación separadas, dentro de las cuales, cuando aparecen los eventos necesarios (creación del usuario, eliminación de software, transferencia de archivos, etc.), los datos del evento se insertan en la lista de la tabla.

En el caso general, todas las soluciones SIEM modernas contienen todos los elementos necesarios para crear y completar los datos del modelo de CA descrito.

La historicidad del modelo.

El AS está cambiando constantemente, es importante tener en cuenta, si no en las reglas de correlación, ya que operan en modo casi en tiempo real y operan en el estado actual del AS, luego cuando se investiga un incidente. Pueden transcurrir minutos, horas y, a veces, meses desde el momento en que comienza un incidente hasta su investigación. Con algunos ataques, pueden transcurrir hasta 6 meses entre la introducción de un atacante en el sistema y la detección de sus actividades por el SIEM ( Estudio de costo de una violación de datos de 2018 por Ponemon ). Durante este tiempo, el panorama del sistema puede cambiar drásticamente: los usuarios se agregan y eliminan, la configuración del equipo ha cambiado, el equipo importante para la investigación del incidente ha dejado de funcionar y los datos copiados por el atacante de un host se han "derramado" a otro. Por lo tanto, durante la investigación es importante observar el modelo del sistema en el estado en que se encontraba en el momento del incidente, y no en el actual, cuando recién comenzamos a investigarlo.

La conclusión de todo esto es la siguiente: el que está construido dentro de SIEM debe tener un historial al que se pueda acceder en cualquier momento.


Cambio de modelo a lo largo del tiempo

Conclusiones

Para resumir:

1. Para que las reglas de correlación funcionen con un número mínimo de falsos positivos, deben tener en cuenta el contexto en el que trabajan.
2. El contexto para las reglas de correlación es el modelo del sistema automatizado de la compañía.
3. SIEM está obligado a construir este modelo en el curso de su trabajo.
4. El modelo de sistema automatizado consta de tres partes principales:
   
   • modelo de usuario y comportamiento;
   • modelo de red y sistemas informáticos, sus conexiones de red y su comportamiento;
   • modelo de datos protegidos y su comportamiento.
5. Los datos necesarios para el modelo se pueden recopilar de dos maneras:
   
   • ;
   • .
6. , . .
7. .
8. , , , .
9. SIEM .

---

:

SIEM: « ». 1: ?

SIEM: « ». 2. «»

SIEM: « ». 3.1.

SIEM: « ». 3.2.

SIEM: « ». 4. ( )

SIEM: « ». 5.