Concluimos la serie de artículos dedicados a las reglas de correlación que salen de la caja. Fijamos una meta para formular un enfoque que nos permitiera crear reglas de correlación que puedan funcionar "fuera de la caja" con un mínimo de falsos positivos.


Imagen: Marketing de software

Todos los puntos clave del artículo están disponibles en la conclusión , donde la metodología dada se presenta en forma de diagrama gráfico.

Brevemente sobre lo que sucedió en artículos anteriores: describieron cómo debería ser un conjunto de campos de un evento normalizado: un diagrama ; qué sistema de categorización de eventos usar; cómo, utilizando un sistema de categorización y un esquema, unificar el proceso de normalización de eventos. También examinamos el contexto de la implementación de las reglas de correlación y examinamos lo que SIEM debe saber sobre el Sistema Automatizado (AS) que está monitoreando y por qué.

Todos los enfoques y razonamientos anteriores son los bloques a partir de los cuales se construye la metodología para desarrollar reglas de correlación. Es hora de juntarlos y ver la imagen completa.

La metodología completa para desarrollar reglas de correlación consta de cuatro bloques:

• preparación de fuentes y alrededores;
• normalización de eventos y su enriquecimiento;
• adaptación de reglas de correlación al contexto de AS;
• formación de un acuerdo sobre aspectos positivos.

Preparación de fuentes y entornos.

Las reglas de correlación operan en eventos que generan fuentes. A este respecto, es extremadamente importante que las fuentes necesarias para las reglas de correlación estén presentes en los altavoces y estén configuradas correctamente.


Preparación de fuentes y entornos.

Paso 1 : Piense en la lógica general de la regla y comprenda qué fuentes de eventos se necesitan. Si está desarrollando desde cero o adoptando una regla de correlación Sigma ya preparada, debe comprender en función de los eventos de qué fuentes funcionará.

Paso 2 : asegúrese de que todas las fuentes necesarias estén en la empresa y que puedan recopilarse. Una situación es posible cuando una regla opera en una cadena de eventos de varias fuentes del formulario (evento A de la fuente 1) - (evento B de la fuente 2) - (evento C de la fuente 3) durante 5 minutos. Si su empresa no tiene al menos una fuente, dicha regla se vuelve inútil, ya que nunca funcionará. Debe comprender si, en principio, es posible recopilar eventos de las fuentes necesarias y si su SIEM puede proporcionarlo. Por ejemplo, la fuente escribe eventos en un archivo, pero el archivo está encriptado, o se usa una base de datos no estándar en la fuente para el almacenamiento, cuyo acceso no puede garantizarse a través del controlador ODBC / JDBC estándar.

Paso 3 : Conecte las fuentes a SIEM. No importa cuán trivial pueda parecer, pero en este paso es necesario implementar la colección de eventos. A menudo hay muchos problemas. Por ejemplo, problemas de organización, cuando la administración de TI prohíbe categóricamente conectarse a sistemas de misión crítica. O técnico, cuando sin configuraciones adicionales, el agente SIEM (SmartConnector, Universal Forwarder), al recopilar eventos, simplemente "mata" la fuente, lo que lleva a una denegación de servicio. Esto a menudo se puede observar cuando se conectan DBMS altamente cargados a SIEM.

Paso 4 : Asegúrese de que la auditoría en las fuentes esté configurada correctamente, los eventos necesarios para la correlación se reciben en SIEM. Las reglas de correlación esperan ciertos tipos de eventos. Deben ser generados por la fuente. A menudo sucede que para generar los eventos necesarios para las reglas, la fuente debe configurarse adicionalmente: la auditoría avanzada está habilitada y la salida del registro en un formato determinado está configurada.

La habilitación de la auditoría extendida a menudo afecta la cantidad de flujo de eventos (EPS) recibida en el SIEM desde la fuente. Debido al hecho de que la fuente misma y SIEM están en el área de responsabilidad de los diferentes departamentos, siempre existe el riesgo de que la auditoría extendida se pueda deshabilitar y, como resultado, los tipos de eventos necesarios dejarán de llegar a SIEM. Este problema puede detectarse parcialmente mediante el monitoreo del flujo de eventos para cada fuente, o más bien, monitoreando los cambios en Eventos por segundo (EPS).

Paso 5 : Verifique que los eventos estén en progreso y configure el monitoreo de origen. En cualquier infraestructura, tarde o temprano, aparecen fallas en la red o en la fuente misma. En este punto, SIEM pierde contacto con la fuente y no puede recibir eventos. Si la fuente es pasiva y escribe sus registros en un archivo o base de datos, los eventos no se perderán en caso de falla, y SIEM podrá recibirlos cuando se restablezca la comunicación. Si la fuente está activa y envía eventos a SIEM, por ejemplo, a través de syslog, sin guardarlos adicionalmente en ningún lugar, entonces, en caso de falla, los eventos se perderán y su regla de correlación simplemente no funcionará, porque el evento deseado no esperará. Al profundizar, puede ver que, incluso cuando se trabaja con una fuente pasiva, al restaurar la comunicación después de una falla, no hay garantía de que las reglas de correlación funcionen, especialmente aquellas que operan con ventanas de tiempo. Considere el ejemplo de regla descrito anteriormente: (evento A de la fuente 1) - (evento B de la fuente 2) - (evento C de la fuente 3) durante 5 minutos. Si ocurre una falla después del evento B y la conexión se restablece en una hora, la correlación no funcionará, ya que el evento C no llegará en los 5 minutos esperados.

Teniendo en cuenta estas características, debe configurar la supervisión de las fuentes de las que se recopilan los eventos. Este monitoreo debe monitorear la disponibilidad de fuentes, la puntualidad de la llegada de eventos de ellas, el poder del flujo de eventos recopilados (EPS).

La activación del sistema de monitoreo es la primera campana que habla de la aparición de un factor negativo que afecta el desempeño de todas o parte de las reglas de correlación.

Normalización de eventos y su enriquecimiento.

Recolectar los eventos necesarios para la correlación no es suficiente. Los eventos que lleguen a SIEM deben normalizarse estrictamente de acuerdo con las reglas aceptadas. Escribimos sobre los problemas de normalización y la formación de una metodología de normalización en un artículo separado. En general, este bloque puede caracterizarse como una lucha contra la basura que entra y sale ( GIGO ).


Normalización y enriquecimiento de eventos.

Paso 6 y Paso 7 : Categorización de eventos y normalización de eventos de acuerdo con la categoría, según la metodología. No nos detendremos en ellos en detalle, ya que consideramos estos pasos en detalle en el artículo "Metodología para normalizar eventos" .

Paso 8 : Enriquecimiento de eventos con información faltante y adicional, de acuerdo con la categoría. A menudo, los eventos entrantes no siempre contienen información en la medida necesaria para que las reglas de correlación funcionen. Por ejemplo, un evento contiene solo la dirección IP del host, pero no hay información sobre su FQDN o nombre de host. Otro ejemplo: un evento contiene una ID de usuario, pero no hay nombre de usuario en el evento. En este caso, la información necesaria debe extraerse de fuentes externas: bases de datos, controladores de dominio u otros directorios y agregarse al evento.

Es importante tener en cuenta que la categorización de eventos ocurre al principio, antes de la normalización. Además del hecho de que la categoría define las reglas para normalizar el evento, también establece la lista de datos que deben buscarse en fuentes externas si no están en el evento en sí.

Adaptación de reglas de correlación al contexto AS

Una vez que haya preparado los datos de entrada (eventos) y haya desarrollado las reglas de correlación, es necesario tener en cuenta los detalles de los eventos entrantes, el AS mismo y su variabilidad. Más sobre esto fue en el artículo "Modelo del sistema como contexto de las reglas de correlación" .


Adaptación de reglas de correlación al contexto AS

Paso 9 : Comprenda la frecuencia de los eventos de cada fuente, determine la ventana de tiempo para la correlación. Muy a menudo, las reglas de correlación usan ventanas de tiempo cuando es necesario esperar la llegada de un determinado evento dentro de un intervalo de tiempo determinado. Al desarrollar tales reglas, es importante considerar el retraso en la recepción de eventos. Generalmente son causados ​​por dos factores.

En primer lugar , la fuente en sí misma no puede escribir eventos de inmediato en la base de datos, en un archivo o enviarlo a través de syslog. El tiempo de este retraso debe ser estimado y tomado en cuenta en la regla.

En segundo lugar , hay un retraso en la entrega de eventos a SIEM. Por ejemplo, la recopilación de eventos de la base de datos se configura para que la solicitud de eventos se realice una vez cada 10 minutos, por supuesto, que la ventana de correlación de 5 minutos no sea la mejor solución en esta situación.

El problema se agrava cuando es necesario desarrollar una regla de correlación que funcione con eventos de varias fuentes a la vez. En este caso, es importante entender que pueden tener diferentes tiempos de entrega. En el peor de los casos, los eventos vendrán en orden aleatorio con una violación de la cronología. En tal situación, el desarrollador de las reglas de correlación necesita comprender claramente a qué hora el SIEM realiza la correlación (en el momento del evento o cuando el evento llegó a SIEM). Observo que la correlación en el momento de llegada de los eventos es la opción más simple técnicamente y más común para procesar eventos en modo pseudo-tiempo real. Sin embargo, esta opción solo exacerba los problemas anteriores y no los resuelve.

Si su SIEM proporciona una correlación en el tiempo del evento, lo más probable es que haya mecanismos para reordenar eventos que puedan restaurar la cronología real de los eventos.

En el caso de que comprenda que la ventana de tiempo es demasiado grande para hacer la correlación en la secuencia, debe usar el mecanismo de correlación retro, en el que los eventos ya guardados se seleccionan de la base de datos SIEM de acuerdo con la programación y se ejecutan a través de las reglas de correlación.

Paso 10 : Establecer un mecanismo de excepción. En el mundo real, siempre habrá un objeto con un comportamiento especial que no debe ser manejado por una regla de correlación específica, ya que esto conduce a un falso positivo. Por lo tanto, en la etapa de desarrollo de las reglas, se deben establecer mecanismos para agregar tales objetos a las excepciones. Por ejemplo, si su regla funciona con las direcciones IP de las máquinas, necesita una lista de tabla donde puede agregar direcciones para las que la regla no funcionará. Del mismo modo, si una regla funciona con inicios de sesión de usuario o nombres de proceso, es necesario trabajar preliminarmente con listas de exclusión de tablas en la lógica de la regla.

Este enfoque le permitirá agregar objetos automática o manualmente a las excepciones sin tener que reescribir el cuerpo de la regla.

Paso 11 : Defina los límites físicos y lógicos de aplicabilidad de la regla de correlación. Al desarrollar una regla de correlación, es importante comprender inicialmente los límites de aplicabilidad (alcance) de la regla y si existen en absoluto. Al resolver la lógica y depurar la regla, es necesario centrarse en los detalles de esta área. Si una regla comienza a funcionar con datos que van más allá del alcance de esta área, la probabilidad de falsos positivos aumenta.

Se pueden distinguir dos tipos de alcance: físico y lógico. El alcance físico son las redes adyacentes y de la compañía, y el área lógica son las partes del AS, las aplicaciones comerciales o los procesos comerciales. Ejemplos del área física: segmento DMZ, subredes internas y externas, redes de acceso remoto. Ejemplos del alcance lógico de las reglas: control de procesos, contabilidad, segmento PCI DSS, segmento PD, o simplemente roles de equipos específicos: controladores de dominio, conmutadores de acceso, enrutadores centrales.

Puede establecer ámbitos para las reglas de correlación a través de listas de tablas. Se pueden llenar de forma manual o automática. Si encuentra tiempo en su empresa para la gestión de activos (gestión de activos), es posible que todos los datos necesarios ya estén contenidos en el modelo AS creado en SIEM. La generación automática de tales listas tabulares le permite incluir dinámicamente en el alcance nuevos activos que aparecen en la empresa. Por ejemplo, si tenía una regla que funcionaba exclusivamente con controladores de dominio, la adición de un nuevo controlador al bosque de dominio se solucionará en el modelo y entrará en el alcance de su regla.

En general, las listas de tablas utilizadas para excepciones pueden considerarse como listas negras, y las listas responsables del alcance de las reglas como listas blancas.

Paso 12 : use el modelo de altavoz para aclarar el contexto. En el proceso de desarrollar una regla de correlación que identifique acciones maliciosas, es importante asegurarse de que realmente se puedan implementar. Si esto no se tiene en cuenta, la activación de la regla que reveló el posible ataque resultará ser falsa, ya que este tipo de ataque simplemente puede no ser aplicable a su infraestructura. Explicaré con un ejemplo:

1. Supongamos que tenemos una regla de correlación que detecta conexiones RDP remotas a los servidores.
2. El firewall muestra un intento de conectarse al servidor TCP 3389 del servidor myserver.local.
3. La regla se dispara y usted comienza a analizar un posible incidente con alta prioridad.

Durante la investigación, descubres rápidamente que en myserver.local 3389 está cerrado y nunca ha sido abierto por ningún servicio y Linux está allí. Este es un falso positivo que te llevó tiempo investigar.

Otro ejemplo: IPS envía un evento desencadenante de firma cuando se intenta explotar la vulnerabilidad CVE-2017-0144, pero durante la investigación resulta que el parche correspondiente está instalado en la máquina atacada y no hay necesidad de responder a dicho incidente con la máxima prioridad.
El uso de datos del modelo de altavoz ayudará a nivelar este problema.

Paso 13 : Use identificadores de entidad, no sus claves de origen. Como ya se describió en el artículo "Modelo del sistema como contexto de las reglas de correlación", la dirección IP, el FQDN e incluso el MAC de un activo pueden cambiar. Por lo tanto, si utiliza los identificadores de origen del activo en la regla de correlación o en la lista de la tabla, después de un tiempo existe una alta probabilidad de recibir falsos positivos por una razón completamente banal, por ejemplo, el servidor DHCP simplemente emitió esta IP a otra máquina.

Si su SIEM tiene un mecanismo para identificar activos, rastrear sus cambios y permitirle operar con sus identificadores, debe usar identificadores, no las claves de origen del activo.

Formación de un acuerdo positivo.

Al acercarnos al bloque final de creación de la regla de correlación, recordamos que el resultado de la regla es un incidente planteado en SIEM. Los profesionales responsables deben responder a tal incidente. Aunque el propósito de esta serie de artículos no incluye la consideración del proceso de respuesta a incidentes, debe tenerse en cuenta que parte de la información sobre el incidente ya se genera en la etapa de creación de la regla de correlación correspondiente.

A continuación, consideramos los puntos básicos que deben tenerse en cuenta al configurar los parámetros para activar la regla de correlación y generar un incidente.


Formación de un acuerdo positivo.

Paso 14 : Determine las condiciones de agregación y apagado en caso de una gran cantidad de falsos positivos. En la etapa de depuración, y en el proceso de su funcionamiento, si no se adhiere a esta técnica :), pueden producirse falsas alarmas de las reglas. Es bueno si hay uno o dos viajes por día, pero ¿qué pasa si una regla tiene miles o decenas de miles de viajes? Por supuesto, esto sugiere que la regla debe desarrollarse más. Sin embargo, es necesario asegurar que en tales situaciones un falso positivo tan masivo:

1. No afectó el rendimiento de SIEM.
2. Entre la masa de falsos positivos, no se perdieron incidentes realmente importantes. Incluso hay un tipo separado de ataque destinado a ocultar la principal actividad maliciosa detrás de muchas actividades falsas.

Los problemas de este tipo pueden resolverse si, al crear una regla de correlación a nivel de todo el sistema en su conjunto, o para cada regla individualmente, establece las condiciones para la agregación de incidentes y las condiciones para el cierre de emergencia de la regla.

El mecanismo de agregación de incidentes permitirá no crear millones de incidentes idénticos, sino "pegar" incidentes nuevos a uno, siempre que sean idénticos. En casos extremos, cuando incluso la agregación de incidentes genera una carga significativa, se recomienda establecer la regla de correlación para que se apague automáticamente cuando se excede el número especificado de operaciones por unidad de tiempo (minuto, hora, día).

Paso 15 : Defina las reglas para generar el nombre del incidente. Este elemento a menudo se descuida, especialmente si no están desarrollando reglas para su compañía, por ejemplo, si una compañía externa es responsable de implementar SIEM y desarrollar reglas. El nombre de la regla de correlación, así como el incidente que generó, debe ser breve y reflejar claramente la esencia de una regla en particular.

Si más de una persona trabaja con incidentes y reglas de correlación en su empresa, se recomienda que desarrolle reglas de nomenclatura. Deben ser entendidos y aceptados por todo el equipo que trabaja con SIEM.

Paso 16 : Defina las reglas para dar forma a la importancia del incidente. La mayoría de las soluciones SIEM en la última etapa de la creación de un incidente le permiten establecer su importancia y significado. Algunas decisiones incluso calculan la importancia automáticamente, según el contexto del incidente y los objetos involucrados en él.

En el caso de que su SIEM opere un cálculo exclusivamente automático de la importancia de los incidentes, vale la pena averiguar sobre la base de qué y por qué fórmula se calcula. Por ejemplo, si la importancia se calcula sobre la base de la importancia de los activos involucrados en el incidente, debe tomar en serio los problemas de Gestión de activos en una empresa de antemano.

Si establece la importancia de un incidente manualmente, se recomienda que desarrolle una fórmula de cálculo que tenga en cuenta al menos lo siguiente:

1. La importancia del alcance en el que funciona la regla. Por ejemplo, un incidente en la zona de sistemas de misión crítica puede ser más crítico que si ocurriera exactamente el mismo incidente en la zona de sistemas críticos de negocios.
2. La importancia de los activos y las cuentas de usuario involucradas en el incidente.
3. La recurrencia de este incidente en la empresa.

Además, como en el nombramiento de incidentes, es importante que todas las partes interesadas comprendan de manera clara e igual las reglas por las cuales se forma la importancia de un incidente.

Conclusiones

Resumiendo los resultados de nuestra serie de artículos, noto que es posible, en mi opinión, crear reglas de correlación que funcionen de manera inmediata. La solución puede ser una fusión de enfoques organizativos y técnicos. El SIEM en sí mismo debe poder hacer algo, pero los especialistas que lo operan deben hacer y saber algo.

Para resumir:

1. El método consta de los siguientes bloques:
   
   • Preparación de fuentes y entornos.
   • Normalización de eventos y su enriquecimiento.
   • Adaptación de las reglas de correlación al contexto AS.
   • Formación de un acuerdo sobre aspectos positivos.
2. Cada unidad tiene componentes organizativos y técnicos.
3. , SIEM, .
4. , , SIEM-.
5. . .

, « »

, , . — . .

---

:

SIEM: « ». 1: ?

SIEM: « ». 2. «»

SIEM: « ». Parte 3.1.

SIEM: « ». 3.2.

SIEM: « ». 4.

SIEM: « ». 5. ( )