Este es el segundo artículo de la serie, dedicado a la metodología para crear reglas de correlación listas para usar para los sistemas SIEM. En el artículo anterior , nos propusimos esta tarea, describimos las ventajas que se obtendrán en su implementación y también enumeramos los principales problemas que se interponen en nuestro camino. En este artículo, comenzaremos a buscar soluciones y comenzaremos con el problema de transformar el modelo del "mundo" , así como su manifestación en la etapa de normalización de los eventos.



El problema de transformar el modelo "mundial" se describió en el primer artículo. Recordemos brevemente su esencia: cuando se produce un fenómeno en el origen de los eventos (por ejemplo, al iniciar un proceso en el sistema operativo), se repara en diferentes formatos, primero en la memoria, luego en el registro de eventos del sistema operativo y luego en el sistema SIEM. Cada etapa del procesamiento va acompañada de pérdida de datos, ya que a nivel del sistema operativo hay un modelo "mundial", y en el registro del sistema operativo, otro, limitado por un conjunto de campos, por el esquema de registro. Por lo tanto, hay una reflexión (transformación) de un modelo con un gran número de parámetros a otro, con un número menor de ellos. Normalizar y guardar un evento en SIEM es otra transformación que también ocurre con la pérdida de datos, ya que SIEM también tiene su propio modelo "mundial".

Es difícil encontrar una manera que permita la transformación de un modelo en otro sin pérdida. Conociendo esta limitación, es necesario formular un enfoque de este tipo para la normalización y la formación de una lista de campos del esquema de eventos, en el que la información no se pierda, importante en la correlación e investigación adicional de incidentes de seguridad de la información.

Dentro del marco de SIEM, un modelo está representado por un esquema, un conjunto de campos en el que los datos del evento inicial se ajustan al proceso de normalización. En el futuro, será utilizado por especialistas en la creación de reglas de correlación. Para que los investigadores de incidentes y los responsables de desarrollar reglas de correlación interpreten sin ambigüedad los eventos normalizados, el esquema debe satisfacer las propiedades básicas:

• estar unificado para eventos de cualquier tipo y fuentes;
• describa claramente quién interactuó con quién y cómo;
• Mantener la esencia y el contexto de la interacción.

En el proceso de desarrollar reglas de normalización, la información sobre la interacción debe encontrarse en el evento inicial y descomponerse en campos especialmente designados. Lo mismo debe hacerse con el contexto y la esencia de la interacción (más sobre esto en el próximo artículo).

Surge la pregunta: ¿es posible identificar esquemas típicos para interacciones que satisfagan cualquier evento creado por todas las posibles fuentes de seguridad de la información y TI? Si es así, ¿cómo son estos esquemas?

Para encontrar la respuesta a estas preguntas, debe recurrir a la analítica e intentar analizar tantas reglas de normalización ya desarrolladas y que funcionen en las soluciones SIEM como sea posible para identificar patrones comunes. Como parte de dicho trabajo, fue posible analizar más de 3.000 reglas de normalización de más de 100 fuentes diferentes de soluciones como Positive Technologies MaxPatrol SIEM y Micro Focus ArcSight. El análisis arrojó las siguientes conclusiones:

1. Existen esquemas de interacción típicos.
2. En cada evento individual, como regla, hay información sobre la interacción a nivel de red y a nivel de aplicación .
3. Los patrones de interacción típicos pueden variar en diferentes niveles, y esto debe tenerse en cuenta.

Red y esquemas de comunicación de capa de aplicación

Describimos esquemas típicos para cada nivel. Antes de esto, debe resaltar las entidades que siempre están presentes en los eventos. Además, en base a ellos, se construirán esquemas de interacción. Estos incluyen:

• Sujeto Una entidad que afecta a un objeto. Por ejemplo, un usuario que cambia una clave de registro o un host con IP 10.0.0.1 y envía un paquete a un host con IP 20.0.0.1.
• Objeto . La entidad afectada por el Sujeto.
• Fuente Como regla general, un host que registra la interacción del Sujeto con el Objeto y genera el evento en sí. Por ejemplo, la Fuente será un cortafuegos que registró la transmisión de paquetes desde el host, el Asunto con IP 10.0.0.1, al host, el Objeto con IP 20.0.0.1.
• Transmisor Hay casos en que SIEM recibe eventos no directamente de la fuente, sino de un servidor intermedio a través del cual pasan estos eventos. El ejemplo más simple es un servidor syslog intermedio. Un ejemplo es más complicado: cuando el Transmisor puede ser un servidor de administración, por ejemplo, Kaspersky Security Center. En este caso, la Fuente es un agente específico de Kaspersky Endpoint Security.

Sin embargo, no todas las entidades pueden representarse simultáneamente en el evento (más sobre esto más adelante), por lo tanto, es importante celebrar acuerdos inicialmente, ya que en este caso se llenan los campos correspondientes del esquema. Esto ayudará en el futuro a distinguir claramente entre casos en los que estos campos no se completaron debido a un error por parte de un especialista que está desarrollando reglas de normalización a partir de casos en los que el evento original realmente no contenía datos sobre ninguna entidad.

Pasemos a patrones de interacción y ejemplos de eventos. Para mayor claridad, todos los ejemplos se darán sobre la base de registros de archivos, mensajes de syslog o registros en una base de datos relacional, pero se pueden usar para otros formatos de registro, por ejemplo, binarios.

Nivel de red

El identificador principal para las entidades de nivel de red son las direcciones IP. Es importante comprender que puede haber otros identificadores relacionados (direcciones MAC a nivel de canal, FQDN) a nivel de aplicación. Surge la pregunta: ¿están hablando de la misma entidad o diferente? ¿Pueden estos identificadores cambiar con el tiempo con la misma entidad? Se dedicará un artículo separado a esto. Ahora analicemos el hecho de que el identificador principal para los modelos de interacción a nivel de red es la dirección IP.

Por lo tanto, los esquemas de interacción típicos de este nivel se pueden dividir en dos clases: básica y degenerada.

Esquemas básicos de interacción

Esquema 1. Esquema de interacción completo

Dentro del marco de este modelo, en el evento recibido en la entrada SIEM, se pueden distinguir todas las entidades principales: Sujeto, Objeto, Fuente, Transmisor. En el esquema de interacción, el Sujeto actúa sobre el Objeto. Este efecto registra (observa) el origen y genera un evento. El evento desde la Fuente ingresa al Transmisor y desde él ingresa al SIEM.

El evento a continuación captura la resolución de la interacción de red entre los hosts mediante el firewall de Stonesoft (ahora Forcepoint), mientras que el evento en sí no ingresa a SIEM directamente, sino desde un servidor syslog intermedio.



Aquí:
40.0.0.1 - Transmisor (servidor syslog intermedio),
30.0.0.1 - Fuente (nodo de firewall),
10.0.0.1 - Asunto (envío de paquetes UDP),
20.0.0.1 - Un objeto (que recibe paquetes UDP).


Diagrama 2: Diagrama de recolección directa sin transmisor

No siempre en el esquema de interacción hay un transmisor. Como regla, está presente cuando se utiliza un servidor intermedio (por ejemplo, un servidor syslog) para transmitir eventos, o cuando la solución de la que se recopilan los eventos tiene un sistema de administración centralizado, por ejemplo, Kaspersky Security Center, Check Point Smart Console o Cisco Prime. Bajo este esquema, los eventos caen en SIEM directamente desde la Fuente. La mayoría de todos los eventos se describen mediante este esquema particular. Por cierto, un ejemplo de tal evento se puede ver en la Figura 1 , si no había un servidor syslog intermedio y recibimos eventos directamente desde el firewall.



Aquí:
30.0.0.1 - Fuente (nodo de firewall),
10.0.0.1 - Asunto (envío de paquetes UDP),
20.0.0.1 - Un objeto (que recibe paquetes UDP).


Esquema 3. Interacción con muchos objetos.

Este esquema de interacción a nivel de red es bastante raro y, como regla, es típico para eventos de equipos de red. En el esquema, un Sujeto interactúa con muchos Objetos, una interacción similar está presente en eventos que describen transmisiones multicast, unicast o broadcast.

Tenga en cuenta que a veces muchos objetos pueden estar unidos por un identificador común: una dirección de subred o una dirección de difusión. Esto debe recordarse, ya que al analizar eventos, incluso a nivel de reglas de correlación, puede omitir fácilmente la interacción potencialmente importante, ya que en dicho esquema la dirección del Objeto se oculta detrás de la dirección del grupo.

El siguiente ejemplo muestra un evento desde un servidor de retransmisión IGMP a través del cual se transmite una solicitud de membresía de multidifusión.



Aquí:
30.0.0.1 - Fuente (servidor de retransmisión IGMP),
10.0.0.1 - Asunto (solicitud de membresía en un grupo),
224.0.0.252 : el objeto (dirección de multidifusión).

Esquemas degenerados

Sujeto, Objeto y Fuente son las entidades básicas en el grupo de esquemas de interacción básicos. Sin embargo, hay casos en que una de las entidades puede estar ausente en el evento.


Esquema 4. Interacción sin un objeto

A menudo, este patrón es típico en situaciones en las que el Sujeto informa un cambio en su estado interno, es decir, actúa simultáneamente en el papel del Sujeto y el Objeto. Por ejemplo, esta interacción se puede observar en cambios de configuración o eventos de detección de malware en la estación de trabajo. Pero esta información no es registrada por el propio sujeto, sino por un sistema de gestión centralizado y almacenado en su diario.

El ejemplo muestra cómo Symantec Management Server captura que el agente de Symantec Endpoint Protection que administra ha detectado un archivo malicioso en su host.



Aquí:
30.0.0.1 - Fuente (Symantec Management Server),
10.0.0.1 - Asunto (Agente de Symantec Endpoint Protection).


Esquema 5. Combinando el papel del Sujeto y el Objeto en la Fuente

El último esquema de interacción degenerada es típico para una situación en la que SIEM recibe eventos de una Fuente que informa un cambio en su estado interno: por ejemplo, reconfigurar un dispositivo o software, habilitar o deshabilitar un puerto de red. En tal esquema, el rol de la Fuente coincide con el rol del Sujeto y el Objeto. A diferencia del esquema anterior, aquí los eventos en SIEM vienen directamente.

En este ejemplo, un conmutador basado en Cisco IOS informa que su interfaz ha pasado al estado UP.



Aquí 30.0.0.1 es la fuente (interruptor).

Nivel de aplicación

En este nivel, hay interacciones de entidades ya conocidas: Sujeto, Objeto. Sin embargo, toda la información sobre la Fuente y el Transmisor permanece directamente en el nivel de la red y no se refleja en el nivel de la aplicación.

La mayoría de todos los tipos de eventos incorporan interacciones simultáneamente a nivel de red y de aplicación. Sin embargo, observamos que los eventos generados directamente por el software de la aplicación, por ejemplo, 1C: Enterprise, Microsoft SQL Server u Oracle Database, pueden contener exclusivamente interacciones a nivel de aplicación.

Además, aparece una entidad de Recursos adicional en el nivel de aplicación.

Un recurso es una entidad intermedia a través de la cual el Sujeto ejerce influencia sobre el Objeto sin interacción directa. Por ejemplo, otorgarle a Alex los derechos para acceder a MyFile a Bob. Aquí Alex es el sujeto, Bob es el objeto, MyFile es el recurso. Tenga en cuenta que en este ejemplo, Alex no interactúa directamente con Bob.

Importante : los eventos en el nivel de aplicación pueden contener parámetros adicionales del Asunto y el Objeto, así como el Recurso en sí. Por ejemplo, los parámetros adicionales de un recurso como un "archivo" pueden ser el directorio en el que se encuentra o su tamaño.
En este caso, el Asunto, el Objeto y el Recurso se identifican por nombre o identificador único: dirección de correo electrónico, nombre de archivo, nombre de directorio, nombre de tabla en la base de datos.

Considere patrones de interacción adicionales específicos del nivel de aplicación.


Figura 6. Interacción de recursos

En este diagrama, el Sujeto actúa indirectamente sobre el Objeto a través de un Recurso intermedio. Como regla general, los eventos con dicho esquema son claramente visibles en los registros de auditoría de la base de datos o cuando se trabaja con derechos de acceso a archivos y directorios a nivel del sistema operativo.

El ejemplo muestra una entrada de la base de datos de auditoría de la base de datos Oracle. Soluciona el proceso de revocar un rol de un usuario.



Aquí:
"ALEX" - Asunto (nombre de usuario que retira el rol),
"BOB" - Objeto (nombre del usuario que está siendo revocado),
"PAPEL" - Recurso (nombre del rol revocado).


Diagrama 7. Interacción con muchos recursos.

A nivel de aplicación, así como a nivel de red, existen tales tipos de eventos en los cuales el Sujeto interactúa con el Objeto inmediatamente a través de muchos Recursos. Es muy raro, pero hay ocasiones en que la cantidad de Objetos también es más de uno. Este tipo de eventos aparecen al arreglar operaciones masivas. Por ejemplo, otorgar acceso a varios archivos a un usuario o cambiar el conjunto de reglas incluidas en la política.

En el ejemplo, la solución para proteger entornos virtuales vGate Security Code captura la incorporación de nuevas políticas al conjunto.



Aquí:
"Admin @ VGATE" - Asunto (nombre del usuario que cambia el conjunto de políticas)
"Base" - Objeto (conjunto de políticas)
"Instalación y mantenimiento de la integridad del sistema de archivos", "Comprobación de la configuración del agente SNMP", "Desactivación de la instalación automática de VMware Tools" - Recursos (nombres de políticas adicionales)

El modelo del canal de interacción entre el Sujeto y el Objeto.

En todos los esquemas, distinguimos diferentes entidades (sujetos, objetos, recursos, fuentes, transmisores) y notamos el llamado canal de interacción entre ellos. Detengámonos con más detalle en el penúltimo componente del modelo grande del "mundo" con el que SIEM debe operar: en los modelos del canal de interacción entre el Sujeto y el Objeto. Recuerde que el último componente es el contexto de interacción (el siguiente artículo se dedicará a esto).

Entonces, hay dos entidades que interactúan entre sí. Como parte de esta interacción, los datos se transfieren de una entidad a otra. Estos pueden ser paquetes de red con datos, archivos o comandos de administración. En este caso, el canal formado puede representarse en forma de una "tubería" a lo largo de la cual hay un flujo dirigido de datos y comandos. Tal modelo es claramente visible a nivel de red, pero menos pronunciado a nivel de aplicación (ver ejemplo ).


Modelo de canal de datos

Basado en dicho modelo, cada evento que recibe el SIEM puede contener información que describe:

• Los parámetros del canal en sí son la "tubería",
• Los datos transmitidos a través de este "tubo".

Típicamente, un canal se describe mediante parámetros como el identificador de sesión, el protocolo de transferencia de datos, el tiempo de establecimiento del canal, el tiempo de finalización y la duración. Los datos en eventos se caracterizan por el formato utilizado por los algoritmos de cifrado, el número de paquetes transmitidos, el número de bytes transmitidos.

Considere un ejemplo de un evento que contiene datos sobre el canal de interacción. Aquí hay un evento del Cisco Identity Services Engine (ISE), un sistema de gestión de procesos para identificar y controlar el acceso, que registra la sesión de red de un usuario como parte del procedimiento de contabilidad (contabilidad).




Aquí:
"Acct-Session-Id = 1A346216", "Acct-Session-Time = 50", "Service-Type = Framed", "Framed-Protocol = PPP" - parámetros del canal de comunicación,
“Acct-Input-Octets = 43525”, “Acct-Output-Octets = 122215”, “Acct-Input-Packets = 234”, “Acct-Output-Packets = 466” - parámetros de los datos transmitidos por el canal.

Un ejemplo de modelos de interacción de entidades y el canal en un evento.

Entonces, examinamos los esquemas de interacción de los niveles y las aplicaciones de la red, así como el modelo del canal de interacción. A continuación, mostramos un ejemplo de cómo en un caso se combinan los esquemas de interacción de diferentes niveles y se utiliza la información sobre el modelo de canal.

Aquí vemos un evento desde el firewall: el dispositivo de seguridad adaptable de Cisco (ASA), en el que se repara una conexión TCP saliente.



El ejemplo muestra claramente que dentro de un evento hay entidades del nivel de red y el nivel de aplicación. A nivel de red, un esquema de interacción entre el Sujeto y el Objeto, que se fija mediante la Fuente. No hay transmisor.

Aquí:
30.0.0.1 - Fuente (Cisco ASA),
10.0.0.1 - Asunto (la dirección de quien se conecta),
20.0.0.1 - Un objeto (la dirección de aquel a quien se conectan).

A nivel de aplicación, un esquema simple en el que solo el Asunto y el Objeto están presentes:
"ALEX" - Asunto (nombre de usuario que se conecta),
"BOB" : el objeto (el nombre del usuario al que se conectan).

También en este caso hay una descripción del canal de transmisión de datos, pero no hay una descripción de los datos en sí:
"TCP" es el protocolo en base al cual se creó el canal,
"136247" es el identificador de sesión del canal.

Conclusiones

¿Cómo pueden ayudar los esquemas de interacción típicos resaltados por nosotros?

• Primero , al escribir reglas de correlación y analizar eventos, un experto debe comprender qué entidades están presentes dentro de cada evento que llega a SIEM. Para esto, es necesario, en la etapa de normalización de los eventos, distinguir claramente las entidades: Sujeto, Objeto, Recurso, Fuente y Transmisor.
• En segundo lugar , durante la normalización, es importante tener en cuenta que el evento contiene información sobre la interacción del nivel de red y el nivel de aplicación. Ambas interacciones pueden estar presentes simultáneamente en un evento.
• En tercer lugar , la interacción en sí misma es una estructura compuesta en la que hay información sobre el canal formado y sobre los datos transmitidos a través de este canal.

Por lo tanto, el modelo del "mundo", que está construido en SIEM y está representado por un conjunto de campos (un esquema), debe contener secciones para describir:

1. A nivel de red :
   
   • Sujeto;
   • El objeto;
   • Fuente;
   • Transmisor
   • Canal de interacción;
   • Datos transmitidos por el canal.
   
   
2. A nivel de aplicación :
   
   • Sujeto;
   • Un objeto o una pluralidad de objetos;
   • Un recurso o múltiples recursos.
   
   

Para cada entidad, es necesario definir un conjunto de propiedades que lo identifiquen de forma exclusiva. A nivel de red, las entidades se identifican por IP, MAC o FQDN. A nivel de aplicación, por nombre o ID. El esquema debe tener campos dedicados para almacenar estos identificadores.

Existen esquemas de interacción degenerados en los que una entidad puede combinar varios roles a la vez. Al normalizar tales eventos, es necesario definir explícitamente la regla para completar todos los campos del esquema que son responsables de todo el conjunto de entidades. En el futuro, esto ayudará a las reglas de correlación a no perder parte de las interacciones.

Expliquemos: tomemos el caso de combinar el papel del Sujeto y el Objeto en la Fuente. , , , , .

, . , .

, , :


,

— «» SIEM , . , , Alex , — , , , . , . , - , , SIEM .

, , . , , .

---

:

SIEM: « ». 1: ?

SIEM: « ». 2. «» ( )

SIEM: « ». 3.1.

SIEM: « ». 3.2.

SIEM: « ». 4.

SIEM: « ». 5.