Evaluación de la eficacia del SIEM

Un SIEM es un sistema complejo que ofrece capacidades amplias y flexibles de detección de amenazas. Debido a su complejidad, su eficacia depende en gran medida de cómo se configure y de qué fuentes de datos se le conecten. Una configuración única del SIEM durante la implementación no es suficiente: tanto la infraestructura de la organización como las técnicas de los atacantes evolucionan con el tiempo. Para funcionar de manera eficaz, el sistema SIEM debe reflejar la situación actual.

Nosotros brindamos servicios para evaluar la eficacia del SIEM, permitiendo identificar problemas y ofreciendo opciones para la optimización del sistema. En este artículo, examinamos los errores operativos típicos del SIEM y cómo abordarlos. Para cada caso, también incluimos métodos de verificación independiente.

Este material se basa en una evaluación de la eficacia de Kaspersky SIEM, por lo tanto, todos los ejemplos específicos, comandos y nombres de campos provienen de esa solución. Sin embargo, la metodología de evaluación, los problemas que identificamos y las formas de mejorar la eficacia del sistema pueden extrapolarse fácilmente a cualquier otro sistema SIEM.

Metodología para evaluar la eficacia del SIEM

El público principal del informe de evaluación de eficacia son los equipos de soporte y operación del SIEM dentro de una organización. El objetivo principal es analizar en qué medida el uso del SIEM se alinea con sus objetivos. Por consiguiente, el alcance de las verificaciones puede variar según los objetivos establecidos. Se realiza una evaluación estándar en las siguientes áreas:

• Composición y alcance de las fuentes de datos conectadas
• Cobertura de las fuentes de datos
• Flujos de datos desde las fuentes existentes
• Corrección de la normalización de datos
• Operatividad de la lógica de detección
• Precisión de la lógica de detección
• Cobertura de la lógica de detección
• Uso de datos contextuales
• Integración técnica del SIEM en los procesos del Centro de Operaciones de Seguridad (SOC, por sus siglas en inglés)
• Manejo de las alertas en el SIEM por parte de los analistas del SOC
• Reenvío de alertas, datos de eventos de seguridad e información sobre incidentes a otros sistemas
• Arquitectura de implementación y documentación

Al mismo tiempo, estas áreas se examinan no solo de manera aislada, sino también en términos de su posible influencia mutua. Aquí hay un par de ejemplos que ilustran esta interdependencia:

• Problemas con la lógica de detección debido a una normalización incorrecta de los datos. Una regla de correlación con la condición deviceCustomString1 not contains <string> activa una gran cantidad de alertas. La lógica de detección en sí misma es correcta: el evento específico y el campo específico al que apunta no deberían generar un gran volumen de datos que cumplan con la condición. Nuestra revisión reveló que el problema estaba en los datos ingresados al SIEM, donde una codificación incorrecta provocó que la cadena a la que apuntaba la regla se transformara en otra. En consecuencia, todos los eventos cumplían con la condición y generaban alertas.
• Al analizar la cobertura para un tipo específico de fuente, descubrimos que el SIEM solo supervisaba el 5 % de todas las fuentes de ese tipo implementadas en la infraestructura. Sin embargo, ampliar esa cobertura aumentaría la carga del sistema y los requisitos de almacenamiento. Por lo tanto, además de conectar fuentes adicionales, sería necesario escalar los recursos para módulos específicos (almacenamiento, recopiladores o el correlador).

La evaluación de la eficacia tiene varias etapas:

• Recopilar y analizar la documentación, si está disponible. Esto permite evaluar los objetivos del SIEM, la configuración de implementación (idealmente, la configuración de implementación al momento de la evaluación), los procesos asociados, etc.
• Entrevistar a ingenieros de sistemas, analistas y administradores. Esto permite evaluar las tareas actuales y los problemas más urgentes, así como determinar exactamente cómo se está operando el SIEM. Las entrevistas suelen dividirse en dos fases: una entrevista introductoria, realizada al inicio del proyecto para recopilar información general, y una entrevista de seguimiento, realizada a mitad del proyecto para abordar las preguntas que surjan del análisis de los datos recopilados previamente.
• Recopilar información dentro del SIEM y luego analizarla. Esta es la parte más extensa de la evaluación, durante la cual a los expertos de Kaspersky se les otorga acceso de solo lectura al sistema o a una parte de él para recopilar datos concretos sobre su configuración, lógica de detección, flujos de datos, etc.

La evaluación genera una lista de recomendaciones. Algunas de estas pueden implementarse casi de inmediato, mientras que otras requieren cambios más integrales impulsados por la optimización de procesos o una transición hacia un enfoque más estructurado del uso del sistema.

Problemas derivados de las operaciones del SIEM

Los problemas que identificamos durante una evaluación de la eficacia del SIEM se pueden dividir en tres grupos:

• Problemas de rendimiento, es decir, errores operativos en diversos componentes del sistema. Estos problemas suelen resolverse mediante el soporte técnico, pero para prevenirlos, vale la pena verificar periódicamente el estado del sistema.
• Problemas de eficiencia: cuando el sistema funciona normalmente, pero aparentemente agrega poco valor o no se aprovecha todo su potencial. Esto suele deberse a que el cliente usa las capacidades del sistema de manera limitada, incorrecta o no según lo previsto por el desarrollador.
• Problemas de detección: cuando el SIEM está en funcionamiento y evoluciona continuamente de acuerdo con los procesos y enfoques definidos, pero las alertas son en su mayoría falsos positivos y el sistema no detecta incidentes. En su mayor parte, estos problemas están relacionados con el enfoque adoptado al desarrollar la lógica de detección.

Observaciones clave de la evaluación

Inventario de fuentes de eventos

Al crear el inventario de fuentes de eventos para un SIEM, seguimos el principio de control por capas: el sistema debe contar con información sobre todas las etapas detectables de un ataque. Este principio permite detectar ataques incluso si algunas acciones maliciosas individuales pasaron desapercibidas, y permite reconstruir retrospectivamente la cadena completa del ataque, comenzando desde el punto de entrada de los atacantes.

Problema: Durante las evaluaciones de eficacia, con frecuencia observamos que el inventario de tipos de fuentes conectadas no se actualiza cuando cambia la infraestructura. En algunos casos, no se actualizó desde la implementación inicial del SIEM, lo que limita las capacidades de detección de incidentes. En consecuencia, ciertos tipos de fuentes permanecen completamente invisibles para el sistema.

También nos encontramos con casos atípicos de inventario de fuentes incompleto. Por ejemplo, una infraestructura contiene hosts que ejecutan tanto Windows como Linux, pero la supervisión está configurada solo para una familia de sistemas operativos.

Cómo detectarlo: Para identificar los problemas descritos anteriormente, hay que determinar la lista de tipos de fuentes conectadas al SIEM y compararla con lo que realmente existe en la infraestructura. Identificar la presencia de sistemas específicos en la infraestructura requiere una auditoría. Sin embargo, esta tarea es una de las más críticas para muchas áreas de la ciberseguridad, y recomendamos llevarla a cabo de manera periódica.

Compilamos una hoja de referencia con los tipos de sistemas que se encuentran comúnmente en la mayoría de las organizaciones. Dependiendo del tipo de organización, la infraestructura y el modelo de amenaza, podemos reordenar las prioridades. Sin embargo, un buen punto de partida es el siguiente:

• Prioridad alta – fuentes asociadas con:
  • Provisión de acceso remoto
  • Servicios externos accesibles desde Internet
  • Perímetro externo
  • Sistemas operativos de endpoint
  • Herramientas de seguridad de la información
• Prioridad media – fuentes asociadas con:
  • Gestión del acceso remoto dentro del perímetro
  • Comunicación de la red interna
  • Disponibilidad de la infraestructura
  • Soluciones de virtualización y en la nube
• Prioridad baja – fuentes asociadas con:
  • Aplicaciones en empresas
  • Servicios internos de TI
  • Aplicaciones usadas por diversos equipos especializados (Recursos Humanos, Desarrollo, Relaciones Públicas, TI, etc.)

Control del flujo de datos desde las fuentes

Por muy buena que sea la lógica de detección, no puede funcionar sin la telemetría de las fuentes de datos.

Problema: El núcleo del SIEM no recibe eventos de fuentes o recopiladores específicos. Según todas las evaluaciones realizadas, la proporción promedio de recopiladores que están configurados con fuentes pero que no transmiten eventos es del 38 %. Puede que existan reglas de correlación para estas fuentes, pero, por supuesto, nunca se activarán. También es importante recordar que un solo recopilador puede dar servicio a cientos de fuentes (como estaciones de trabajo), por lo que la pérdida del flujo de datos de incluso un solo recopilador puede significar la pérdida de visibilidad de control para una parte significativa de la infraestructura.

Cómo detectarlo: El proceso de localizar fuentes que no están transmitiendo datos se puede dividir en dos componentes.

1. Verificar el estado de los recopiladores. Busca el estado de los recopiladores (consulta el sitio web de soporte para conocer los pasos a seguir en Kaspersky SIEM) e identifica aquellos con estado Offline, Stopped, Disabled, etc.
2. Verificar el flujo de eventos. En Kaspersky SIEM, esto se puede hacer recopilando estadísticas mediante la siguiente consulta (contando el número de eventos recibidos de cada recopilador durante un período determinado):

Es esencial especificar un intervalo de tiempo óptimo para recopilar estas estadísticas. Un intervalo demasiado amplio puede aumentar la carga en el SIEM, mientras que uno demasiado corto puede proporcionar información inexacta para una verificación puntual, especialmente en el caso de fuentes que transmiten telemetría con poca frecuencia, por ejemplo, una vez a la semana. Por lo tanto, es recomendable elegir un intervalo de tiempo más corto, como de 2 a 4 días, pero ejecutar varias consultas para diferentes períodos del pasado.

Además, para un enfoque más integral, se recomienda usar la funcionalidad integrada o una lógica personalizada implementada mediante reglas de correlación y listas para controlar el flujo de eventos. Esto ayudará a automatizar el proceso de detección de problemas con las fuentes.

Cobertura de fuentes de eventos

Problema: El sistema no recibe eventos de todas las fuentes de un tipo determinado que existen en la infraestructura. Por ejemplo, la empresa usa estaciones de trabajo y servidores que ejecutan Windows. Durante la implementación del SIEM, las estaciones de trabajo se conectan de inmediato para su control, mientras que el segmento de servidores se pospone por una u otra razón. Como resultado, el SIEM recibe eventos de los sistemas Windows, el flujo se normaliza y las reglas de correlación funcionan, pero un incidente en el segmento de servidores no controlado pasaría desapercibido.

Cómo detectarlo: A continuación, se presentan variantes de consultas que se pueden usar para buscar fuentes no conectadas.

• SELECT count(distinct, DeviceAddress), DeviceVendor, DeviceProduct FROM `events` GROUP BY DeviceVendor, DeviceProduct ORDER BY count(ID)

  1	SELECT count(distinct, DeviceAddress), DeviceVendor, DeviceProduct FROM `events` GROUP BY DeviceVendor, DeviceProduct ORDER BY count(ID)

• SELECT count(distinct, DeviceHostName), DeviceVendor, DeviceProduct FROM `events` GROUP BY DeviceVendor, DeviceProduct ORDER BY count(ID)

  1	SELECT count(distinct, DeviceHostName), DeviceVendor, DeviceProduct FROM `events` GROUP BY DeviceVendor, DeviceProduct ORDER BY count(ID)

Dividimos la consulta en dos variantes porque, según la fuente y la configuración de integración de DNS, algunos eventos pueden tener el campo DeviceAddress o DeviceHostName.

Estas consultas ayudarán a determinar la cantidad de fuentes de datos únicas que envían registros de un tipo específico. Esta cantidad debe compararse con la cantidad real de fuentes de ese tipo, obtenida de los propietarios del sistema.

Conservación de datos sin procesar

Los datos sin procesar pueden ser útiles para desarrollar normalizadores personalizados o para almacenar eventos no usados en la correlación que podrían ser necesarios durante la investigación de incidentes. Sin embargo, el uso descuidado de esta configuración puede causar mucho más daño que beneficio.

Problema: Habilitar la opción Keep raw event (Conservar evento sin procesar) duplica efectivamente el tamaño de los eventos en la base de datos, ya que almacena dos copias: la original y la versión normalizada. Esto es particularmente crítico para los recopiladores de gran volumen que reciben eventos de fuentes como NetFlow, DNS, firewalls y otras. Vale la pena señalar que esta opción se usa típicamente para probar un normalizador, pero a menudo se olvida y se deja habilitada una vez completada su configuración.

Cómo detectarlo: Esta opción se aplica a nivel del normalizador. Por lo tanto, es necesario revisar todos los normalizadores activos y determinar si es necesario conservar los datos sin procesar para su funcionamiento.

Normalización

Al igual que con la ausencia de eventos de las fuentes, los problemas de normalización provocan que la lógica de detección falle, ya que esta lógica se basa en encontrar información específica en un campo específico del evento.

Problema: Se pueden identificar varios problemas relacionados con la normalización:

• El flujo de eventos no se normaliza en absoluto.
• Los eventos solo se normalizan parcialmente; esto es particularmente relevante para los normalizadores personalizados que no son predeterminados.
• El normalizador que se usa solo analiza encabezados, como syslog_headers, y coloca todo el cuerpo del evento en un solo campo, que en la mayoría de los casos es Message.
• Se usa un normalizador predeterminado desactualizado.

Cómo detectarlo: Identificar problemas de normalización es más difícil que detectar problemas en las fuentes debido al gran volumen de telemetría y a la variedad de analizadores. A continuación se presentan varios enfoques para acotar la búsqueda:

• Primero, verifica qué normalizadores incluidos con el SIEM usa la organización y si sus versiones están actualizadas. En nuestras evaluaciones, con frecuencia encontramos eventos de auditd que son normalizados por el normalizador obsoleto, Linux audit and iptables syslog v2 para Kaspersky SIEM. El nuevo normalizador rediseña y optimiza por completo el esquema de normalización para los eventos de esta fuente.
• Ejecuta la consulta:

Esta consulta recopila estadísticas sobre los eventos de cada recopilador, desglosadas por los campos DeviceVendor y DeviceProduct. Aunque estos campos no son obligatorios, están presentes en casi cualquier esquema de normalización. Por lo tanto, su ausencia total o la presencia de valores vacíos pueden indicar problemas de normalización. Recomendamos incluir estos campos al desarrollar normalizadores personalizados.

Para simplificar la identificación de problemas de normalización al desarrollar normalizadores personalizados, puedes implementar el siguiente mecanismo. Para cada evento normalizado con éxito, agrega el campo Name (Nombre), que se complete con una constante o con el propio evento. Para un normalizador final que procese todos los eventos sin analizar, establezca el valor constante: Name = unparsed event. Esto permitirá posteriormente identificar eventos no normalizados mediante una búsqueda simple en este campo.

Cobertura de la lógica de detección

Los eventos recopilados por sí solos son, en la mayoría de los casos, útiles solo para investigar un incidente que ya fue identificado. Para que un SIEM funcione a su máximo potencial, es necesario desarrollar lógicas de detección que permitan descubrir posibles incidentes de seguridad.

Problema: La cobertura promedio de reglas de correlación de las fuentes, determinada en todas nuestras evaluaciones, es del 43 %. Si bien esta cifra es solo aproximada (ya que los diferentes tipos de fuentes proporcionan información diferente), para calcularla definimos “cobertura” como la presencia de al menos una regla de correlación para una fuente. Esto significa que, para más de la mitad de las fuentes conectadas, el SIEM no está realizando una detección activa. Mientras tanto, se invierten esfuerzos y recursos del SIEM en conectar, mantener y configurar estas fuentes. En algunos casos, esto está formalmente justificado; por ejemplo, si los registros solo son necesarios para cumplir con requisitos normativos. Sin embargo, esto es una excepción más que la regla.

No recomendamos resolver este problema simplemente dejando de conectar las fuentes al SIEM. Por el contrario, las fuentes deben conectarse, pero esto debe hacerse al mismo tiempo que se desarrolla la lógica de detección correspondiente. De lo contrario, puede olvidarse o posponerse indefinidamente, mientras la fuente consume recursos del sistema sin necesidad.

Cómo detectarlo: Esto nos lleva de vuelta a la auditoría, un proceso que puede facilitarse mediante la creación y el mantenimiento de un registro de la lógica de detección desarrollada. Dado que no todas las reglas de lógica de detección indican explícitamente el tipo de fuente de la que esperan recibir telemetría, su descripción debe agregarse a este registro durante la fase de desarrollo.

Si no tienes descripciones de las reglas de correlación, puedes referirte a lo siguiente:

• El nombre de la lógica de detección. Con un enfoque estandarizado para nombrar las reglas de correlación, el nombre puede indicar la fuente asociada o proporcionar una breve descripción de lo que detecta.
• El uso de campos dentro de las reglas, tales como DeviceVendor, DeviceProduct (otro argumento a favor de incluir estos campos en el normalizador), Name, DeviceAction, DeviceEventCategory, DeviceEventClassID y otros. Estos pueden ayudar a identificar la fuente real.

Exceso de alertas generadas por la lógica de detección

Uno de los criterios para evaluar la eficacia de las reglas de correlación es una baja tasa de falsos positivos.

Problema: La lógica de detección genera una cantidad anormalmente alta de alertas que son físicamente imposibles de procesar, sin importar el tamaño del equipo del SOC.

Cómo detectarlo: En primer lugar, la lógica de detección debe someterse a pruebas durante el desarrollo y perfeccionarse para lograr una tasa de falsos positivos aceptable. Sin embargo, incluso una regla de correlación bien ajustada puede comenzar a producir alertas excesivas debido a cambios en el flujo de eventos o en la infraestructura conectada. Para identificar estas reglas, recomendamos ejecutar periódicamente la siguiente consulta:

En Kaspersky SIEM, un valor de 3 en el campo Type (tipo) indica un evento de correlación.

Posteriormente, para cada regla identificada con un recuento anómalo de alertas, se debe verificar la corrección de la lógica que usa y la integridad del flujo de eventos que la activó.

Dependiendo del problema identificado, la solución puede implicar modificar la lógica de detección, agregar excepciones (por ejemplo, suele ocurrir que el 99 % del spam proviene de tan solo 1 a 5 objetos específicos, como una dirección IP, un parámetro de comando o una URL) o ajustar la recopilación y normalización de eventos.

Falta de integración con indicadores de compromiso

Las integraciones del SIEM con otros sistemas suelen ser una parte fundamental tanto del procesamiento de eventos como del enriquecimiento de alertas. En al menos un caso específico, su presencia influye directamente en el desempeño de la detección: la integración con datos técnicos de Inteligencia de amenazas o IoC (indicadores de compromiso).

Un SIEM permite verificar fácilmente los objetos contra diversas bases de datos de reputación o listas de bloqueo. Además, existen varias fuentes de estos datos que están listas para integrarse de manera nativa con un SIEM o que requieren un esfuerzo mínimo para incorporarlas.

Problema: No hay integración con los datos de TI.

Cómo detectarlo: Por lo general, los IoC se integran en un SIEM a nivel de configuración del sistema durante la implementación o la optimización posterior. El uso de TI dentro de un SIEM puede implementarse en varios niveles:

• A nivel de la fuente de datos. Algunas fuentes, como los NGFW, agregan esta información a los eventos relacionados con objetos relevantes.
• A nivel de la funcionalidad nativa del SIEM. Por ejemplo, Kaspersky SIEM integra indicadores de CyberTrace, que agregan información sobre la reputación de los objetos en el momento de procesar un evento de una fuente.
• A nivel de la lógica de detección. La información sobre los IoC se almacena en diversas listas activas, y las reglas de correlación comparan los objetos con estas para enriquecer el evento.

Además, los datos de TI no aparecen en un SIEM de la nada. Son proporcionados por proveedores externos (de forma comercial o en un formato abierto) o forman parte de la funcionalidad integrada de las herramientas de seguridad en uso. Por ejemplo, varios sistemas NGFW pueden verificar adicionalmente la reputación de las direcciones IP externas o los dominios a los que acceden los usuarios. Por lo tanto, el primer paso es determinar si se está recibiendo información sobre indicadores de compromiso y en qué forma (si se integraron fuentes de proveedores externos o si las herramientas de seguridad implementadas cuentan con esta capacidad). Cabe destacar que recibir datos de TI únicamente a nivel de las herramientas de seguridad no siempre cubre todos los tipos de IoC.

Si se reciben datos de alguna forma, el siguiente paso es verificar que el SIEM los esté usando. Para los eventos relacionados con TI que provienen de las herramientas de seguridad, el SIEM necesita una regla de correlación desarrollada para generar alertas. Por lo tanto, verificar la integración en este caso implica determinar las capacidades de las herramientas de seguridad, buscar los eventos correspondientes en el SIEM e identificar si existe una lógica de detección asociada a estos eventos. Si faltan eventos de las herramientas de seguridad, se debe evaluar la configuración de auditoría de la fuente para ver si el tipo de telemetría en cuestión se está reenviando al SIEM. Si el problema es la normalización, se debe evaluar la precisión del análisis sintáctico y volver a configurar el normalizador.

Si los datos de TI provienen de proveedores externos, hay que determinar cómo se procesan dentro de la organización. ¿Existe un sistema centralizado para agregar y gestionar datos de amenazas (como CyberTrace), o la información se almacena, por ejemplo, en archivos CSV?

En el primer caso (cuando existe un sistema de agregación y gestión de datos de amenazas), hay que verificar si está integrado con el SIEM. Para Kaspersky SIEM y CyberTrace, esta integración se gestiona a través de la interfaz del SIEM. Posteriormente, los flujos de eventos del SIEM se dirigen al sistema de agregación y gestión de datos de amenazas, donde se identifican las coincidencias y se generan alertas, y luego ambas se envían de vuelta al SIEM. Por lo tanto, verificar la integración implica asegurarse de que todos los recopiladores que reciben eventos que puedan contener IoC los reenvíen al sistema de agregación y gestión de datos de amenazas. También recomendamos verificar si el SIEM cuenta con una regla de correlación que genere una alerta al detectar coincidencias entre objetos y IoC.

En el segundo caso (donde la información de amenazas se almacena en archivos), hay que confirmar que el SIEM tenga un recopilador y un normalizador configurados para cargar estos datos en el sistema como eventos. Además, hay que verificar que la lógica esté configurada para almacenar estos datos dentro del SIEM para su uso en la correlación. Esto se suele hacer con la ayuda de listas que tienen los IoC obtenidos. Por último, verificar si existe una regla de correlación que compare el flujo de eventos con estas listas de IoC.

Como ilustran los ejemplos, la integración con TI en escenarios estándar se reduce, en última instancia, a desarrollar una regla de correlación final que active una alerta al detectar una coincidencia con IoC conocidos. Dada la variedad de métodos de integración, es difícil crear y proporcionar una regla universal lista para usar. Por lo tanto, en la mayoría de los casos, para garantizar que los IoC estén conectados al SIEM, es necesario determinar si la empresa desarrolló esa regla (la existencia de la regla) y si se configuró correctamente. Si no existe ninguna regla de correlación en el sistema, recomendamos crear una basada en los métodos de integración de TI implementados en la infraestructura. Si existe una regla, se debe verificar su funcionalidad: si no genera alertas, analiza sus condiciones de activación comparándolas con los datos de eventos visibles en el SIEM y ajústala según corresponda.

El SIEM no se mantiene actualizado

Para que un SIEM funcione de manera eficaz, debe contener datos actuales sobre la infraestructura que controla y las amenazas que debe detectar. Ambos elementos cambian con el tiempo: se introducen nuevos sistemas y software, usuarios, políticas de seguridad y procesos en la infraestructura, mientras que los atacantes desarrollan nuevas técnicas y herramientas. Es razonable suponer que un sistema SIEM perfectamente configurado e implementado ya no podrá detectar completamente la infraestructura modificada ni las nuevas amenazas después de cinco años de funcionamiento sin configuración adicional. Por lo tanto, prácticamente todos los componentes (la recopilación de eventos, la detección, las integraciones adicionales para información contextual y las exclusiones) deben mantenerse y actualizarse.

Además, es importante reconocer que es imposible cubrir el 100 % de todas las amenazas. Es imprescindible la investigación continua de los ataques, el desarrollo de métodos de detección y la configuración de las reglas correspondientes. El propio SOC también evoluciona. A medida que alcanza ciertos niveles de madurez, se abren nuevas oportunidades de crecimiento para el equipo, lo que requiere el uso de nuevas capacidades.

Problema: El SIEM no evolucionó desde su implementación inicial.

Cómo detectarlo: Compara el enunciado de trabajo original u otra documentación de implementación con el estado actual del sistema. Si no hubo cambios, o solo cambios mínimos, es muy probable que el SIEM tenga áreas de mejora y optimización. Cualquier infraestructura es dinámica y requiere una adaptación continua.

Otros problemas con la implementación y el funcionamiento del SIEM

En este artículo, describimos los principales problemas que identificamos durante las evaluaciones de eficacia del SIEM, pero esta lista no es exhaustiva. También nos encontramos frecuentemente con:

• Desajuste entre la capacidad de la licencia y la carga real del SIEM. El problema casi siempre es la ausencia de eventos de las fuentes, más que una evaluación inicial incorrecta de las necesidades de la organización.
• Falta de gestión de derechos de usuario dentro del sistema (por ejemplo, a todos los usuarios se les asigna el rol de administrador).
• Mala organización de los recursos personalizables del SIEM (reglas, normalizadores, filtros, etc.). Algunos ejemplos incluyen convenciones de nomenclatura caóticas, agrupaciones no óptimas y contenido obsoleto o de prueba mezclado con contenido activo. Nos encontramos con nombres de recursos confusos como [dev] test_Add user to admin group_final2.
• Uso de recursos predeterminados sin adaptarlos a la infraestructura de la organización. Para maximizar el valor de un SIEM, es esencial, como mínimo, completar las listas de excepciones y especificar los parámetros de infraestructura: listas de administradores, así como de servicios y hosts críticos.
• Integraciones nativas deshabilitadas con sistemas externos, como LDAP, DNS y GeoIP.

En general, la mayoría de los problemas relacionados con la eficacia del SIEM se derivan de la degradación natural (acumulación de errores) de los procesos implementados dentro del sistema. Por lo tanto, en la mayoría de los casos, mantener la eficacia implica estructurar estos procesos, supervisar la calidad de la implementación del SIEM en todas las etapas (incorporación de fuentes, desarrollo de reglas de correlación, normalización, etc.) y realizar revisiones periódicas de todos los componentes y recursos del sistema.

Conclusión

Un SIEM es una herramienta poderosa para controlar y detectar amenazas, capaz de identificar ataques en diversas etapas en casi cualquier punto de la infraestructura de una organización. Sin embargo, si se configura y opera de manera inadecuada, puede volverse ineficaz o incluso inútil, a la vez que consume recursos importantes. Por lo tanto, es crucial auditar periódicamente los componentes, la configuración, las reglas de detección y las fuentes de datos del SIEM.

Si un SOC está sobrecargado o no puede identificar de manera independiente problemas operativos con su SIEM, ofrecemos a los usuarios de la plataforma Kaspersky SIEM un servicio para evaluar su funcionamiento. Tras la evaluación, proporcionamos una lista de recomendaciones para resolver los problemas que identificamos. Dicho esto, es importante aclarar que no se trata de instrucciones estrictas y prescriptivas, sino que más bien se destacan áreas que merecen atención y análisis para mejorar el desempeño del producto, aumentar la precisión en la detección de amenazas y permitir un uso más eficiente del SIEM.