Qué logs enviar a un SIEM y cuáles no: fuentes prioritarias, retención y coste

En su quinto informe anual sobre riesgo de detección, CardinalOps analizó entornos SIEM en producción y encontró que las organizaciones ingieren datos suficientes para cubrir potencialmente el 90% de las técnicas de MITRE ATT&CK. Tienen detecciones para el 22% del total de técnicas.

El volumen no es la restricción. Los SIEM del estudio ingerían una media de 23.746 fuentes de log distintas repartidas en 259 tipos de fuente, un 18% y un 30% más que el año anterior, respectivamente. Más datos, cobertura casi igual: el año previo era del 19% y la media de los cinco años de la serie ronda el 20%.

La pregunta útil, entonces, no es cuántos logs mandas. Es cuáles, con qué campos, a qué capa y durante cuánto tiempo. Esta guía responde a eso: qué fuentes se ganan su sitio en la capa cara del SIEM, cuáles se pueden mandar a almacenamiento barato sin perder capacidad de investigar, cómo detectar que una fuente ha enmudecido, y qué exigen realmente el ENS y el reglamento técnico de DORA en materia de registro y retención.

¿Por qué mandarlo todo al SIEM sale mal?

Conectar cada fuente disponible tiene una lógica aparente: si el dato está, algún día servirá. Esa lógica se rompe por tres sitios distintos, y solo uno de ellos es el coste.

El modelo de precio castiga el volumen, no el valor

Casi todas las plataformas facturan por gigabyte ingerido o por capacidad diaria comprometida. Eso significa que un log de depuración de una aplicación interna, que no alimenta ninguna detección, cuesta exactamente lo mismo por gigabyte que los eventos de autenticación del directorio corporativo. Pagas por gigabyte, y el gigabyte no sabe si sirve para algo. Los dos candidatos a inflar la factura suelen ser los mismos: el tráfico de red en bruto y los registros de aplicación verbosos.

Una fuente sin regla no detecta nada

Ingerir es una condición necesaria y no suficiente. Que un log esté en el SIEM no crea una detección: alguien tiene que escribir la regla, asociarla a una técnica, ajustarla y mantenerla. El dato de partida de este artículo describe justamente esa brecha entre lo que se ingiere y lo que se detecta, y merece una precisión sobre cómo se mide. El informe define cobertura como la existencia de al menos una regla asociada a una técnica de ATT&CK: mide presencia, no eficacia. Una regla puede existir, estar asociada a su técnica y aun así detectar mal.

Las reglas se rompen, y se rompen por los datos

El mismo informe halló que el 10% de las reglas de un SIEM estaban rotas, sobre una media de 163 reglas por organización: unas dieciséis que no funcionan como se escribieron. La cifra ha mejorado respecto al 18% del año anterior, pero lo relevante es la causa. Las reglas fallan por fuentes mal configuradas, por campos que dejan de llegar y por errores de análisis sintáctico del log. Rara vez el problema es una lógica equivocada.

Un apunte de honestidad sobre la fuente: CardinalOps vende una plataforma de gestión de postura de detección, de modo que tiene interés en que estas cifras resulten llamativas. Su metodología, con todo, es de las pocas que trabajan sobre metadatos de configuración de SIEM reales en producción y no sobre encuestas, y el propio informe reconoce que cubrir el 100% de ATT&CK no es un objetivo razonable ni es lo que el marco fue diseñado para fomentar. Y una precisión para quien vaya al informe original: las cifras que aquí citamos son las de la muestra de 2025 que aparecen en el cuerpo del informe; su portada da un 21% de cobertura y un 13% de reglas rotas, referidos al agregado de los cinco años de la serie.

¿Qué preguntar antes de conectar una fuente?

El orden habitual es el inverso al que funciona. Se conecta lo que el fabricante trae con conector nativo y después se busca qué hacer con ello. Estas cuatro preguntas invierten esa secuencia y se responden en minutos por fuente:

1. ¿Qué detección concreta habilita? Si la respuesta es «visibilidad general», la fuente no entra en la capa cara. Deberías poder nombrar una regla o una hipótesis de búsqueda proactiva, y a ser posible la técnica de ATT&CK a la que corresponde.
2. ¿Trae los campos que esa detección necesita? Un log de acceso sin identidad de usuario, sin dirección de origen o sin resultado de la operación no sostiene ninguna regla de autenticación, por mucho volumen que ocupe.
3. ¿Es estable su formato? Los registros de aplicaciones propias y de servicios SaaS cambian de esquema sin previo aviso y rompen el análisis sintáctico. Esa inestabilidad es un coste de mantenimiento que hay que asumir a sabiendas y no descubrir más tarde.
4. ¿Necesita estar en la capa de análisis o basta con que sea buscable? Es la pregunta que más presupuesto ahorra, y la que menos se hace.

¿Qué fuentes se ganan su sitio en la capa cara?

La guía conjunta sobre registro de eventos y detección de amenazas que publicaron el 22 de agosto de 2024 el Centro Australiano de Ciberseguridad (ACSC), dependiente de la agencia ASD, junto a CISA, el FBI, la NSA, el NCSC británico y otros diez organismos de Canadá, Nueva Zelanda, Japón, Corea del Sur, Singapur y Países Bajos establece un criterio de priorización razonable: empezar por los sistemas críticos y los conjuntos de datos con más probabilidad de ser atacados, y por los servicios expuestos a internet, con el acceso remoto, los metadatos de red y el sistema operativo del servidor subyacente incluidos. En entornos industriales el criterio equivalente son los dispositivos críticos para la seguridad funcional y la prestación del servicio, salvo los sistemas aislados, más los expuestos a internet y los alcanzables a través de las fronteras de red.

Traducido a fuentes concretas, ordenadas por lo que suelen aportar en un entorno corporativo típico:

La lógica de la mitad superior de la tabla es sencilla: son las fuentes donde queda registrado el uso de una identidad y la ejecución de código, que es por donde pasa buena parte de las cadenas de ataque actuales. Un atacante que entra con credenciales válidas y usa herramientas del propio sistema no genera una alerta de antivirus, pero sí deja rastro en el directorio y en la telemetría del EDR. Esa es la razón por la que detectar Kerberoasting, abuso de AD CS o un Golden Ticket depende más de tener bien configurada la auditoría del directorio que de añadir una fuente nueva.

El borde de la red es caso aparte. Los dispositivos perimetrales suelen registrar poco y mal, y sin embargo son la puerta de entrada favorita cuando aparece un fallo explotado en masa. Ya escribimos en detalle sobre por qué esos equipos son un punto ciego del EDR y cómo cubrirlos sin agente; a efectos de esta guía basta con la consecuencia: un cortafuegos o una VPN que solo emite eventos de conexión aceptada y denegada no permite reconstruir un incidente.

Las fuentes de identidad tienen a su favor un segundo argumento que rara vez llega al inventario. Una vez que el atacante tiene una sesión válida, casi todo lo que hace después se parece a administración corriente, y por eso el secuestro de cuentas de Microsoft 365 mediante AiTM y robo de tokens solo suele verse en la telemetría de inicio de sesión y de auditoría.

¿Por qué la calidad del log importa más que el número de fuentes?

La misma guía conjunta insiste en algo que las hojas de cálculo de fuentes casi nunca recogen: el formato y la rapidez con que llega el dato condicionan la detección tanto como su existencia. Sus recomendaciones se resumen en cuatro exigencias concretas.

• Formato estructurado y coherente, como JSON, con el mismo esquema, el mismo formato y el mismo orden dentro de cada tipo de log.
• Normalización automática, especialmente importante en los registros que cambian con el tiempo o sin aviso, como los de software y servicios SaaS.
• Servidores de tiempo sincronizados y validados en todos los entornos, con UTC como referencia preferida y captura de eventos significativos como los arranques y reinicios de los dispositivos.
• Ingesta sin retrasos. Si se retrasa la generación, la recogida o la ingesta de los eventos, se retrasa en la misma medida la capacidad de identificar el incidente.

Para saber si un log concreto tiene calidad suficiente hay un atajo útil y de origen inesperado. El Esquema Nacional de Seguridad fija en la medida op.exp.8 el contenido mínimo de un registro de auditoría: identificador del usuario o entidad asociado al evento, fecha y hora, sobre qué información se realiza el evento, tipo de evento y resultado, éxito o fallo. Cinco campos. Un log al que le falte alguno de ellos difícilmente sostendrá una regla que aguante una investigación, sea o no de aplicación el ENS en tu caso.

¿Y si la fuente deja de enviar y nadie se entera?

Este es el fallo silencioso del que casi nadie habla, y encaja con la estadística de reglas rotas. Una fuente que deja de enviar no genera una alerta: genera silencio, y el silencio se parece mucho a que no pasa nada. Un cambio de versión del agente, una rotación de credencial de la integración, una regla de cortafuegos nueva o un disco lleno bastan para que un tipo de evento desaparezca durante semanas sin que nadie lo note.

La normativa financiera europea es explícita en este punto y merece leerse aunque no seas una entidad financiera. El reglamento técnico que desarrolla DORA exige, entre las medidas de registro, disponer de mecanismos para detectar un fallo de los sistemas de registro. No detectar el ataque: detectar que el sistema que debía registrarlo ha dejado de funcionar. Es una de las pocas obligaciones normativas que se traduce directamente en una tarea de ingeniería.

Implementarlo no tiene misterio: tiene disciplina. Fija una referencia de volumen y frecuencia por fuente, alerta cuando el flujo cae por debajo de lo esperado dentro de una ventana definida y trata esa alerta con la misma seriedad que una de seguridad. La variante más fina es la que vigila la presencia de tipos de evento concretos y no solo el volumen agregado, porque una fuente puede seguir enviando su ruido habitual y haber dejado de enviar justo la categoría que alimenta tus tres mejores reglas.

¿Cuánto hay que conservar según el ENS y el reglamento técnico de DORA?

Circulan muchas cifras inventadas sobre esto. Los textos dicen bastante menos de lo que cuenta el folclore.

ENS: la retención la fijas tú, pero por escrito

El Real Decreto 311/2022 no impone un número universal de meses. La medida op.exp.8, «Registro de la actividad», se aplica según el nivel de la dimensión de trazabilidad, no según la categoría del sistema, y ese matiz se confunde a menudo. En el nivel bajo se exige el registro de auditoría con los cinco campos mínimos y la activación de registros en los servidores. En el nivel medio se añaden cuatro refuerzos: revisión periódica e informal de los registros en busca de patrones anormales, sincronización del reloj del sistema, retención y control de acceso.

El refuerzo de retención dice exactamente esto: en la documentación de seguridad del sistema deben indicarse los eventos de seguridad que serán auditados y el tiempo de retención de los registros antes de ser eliminados. El de control de acceso añade que los registros de actividad y sus copias de seguridad solo podrán ser accedidos o eliminados por personal debidamente autorizado, lo que impide que el administrador del sistema auditado borre su propio rastro.

En el nivel alto se añade el quinto refuerzo, y es el que convierte todo esto en un proyecto: herramientas para analizar y revisar la actividad del sistema y la información de auditoría en busca de compromisos posibles o reales, más un sistema automático de recolección de registros, correlación de eventos y respuesta automática ante ellos. Dicho de otro modo, en trazabilidad alta el ENS describe un SIEM con correlación y automatización sin llamarlo por su nombre. A eso se suma la medida op.mon.3, «Vigilancia», que sí se aplica por categoría y que en categoría alta encadena seis refuerzos, desde la correlación de eventos hasta las inspecciones periódicas de seguridad. Si estás preparando una certificación, el detalle importa: no todos los certificados ENS son iguales y manda el alcance.

DORA: cinco categorías de evento y una retención razonada

El Reglamento Delegado (UE) 2024/1774, que desarrolla los requisitos técnicos de gestión del riesgo de las TIC de DORA, dedica su artículo 12 al registro. Obliga a las entidades financieras a documentar procedimientos que identifiquen los eventos a registrar, el periodo de retención y las medidas para asegurar y tratar esos datos, y a alinear el nivel de detalle con la finalidad, de modo que permita detectar actividades anómalas de forma efectiva. Enumera además cinco categorías de eventos que deben registrarse en todo caso:

• Control de acceso lógico y físico, y gestión de identidades.
• Gestión de capacidad.
• Gestión de cambios.
• Operaciones TIC, incluida la actividad de los sistemas.
• Actividad del tráfico de red, incluido el rendimiento de las redes de TIC.

Y añade tres exigencias que suelen quedarse fuera de los proyectos: proteger los sistemas de registro y la información registrada frente a manipulación, borrado y acceso no autorizado en reposo, en tránsito y, cuando proceda, en uso; detectar los fallos de los sistemas de registro, el requisito ya citado más arriba; y sincronizar los relojes de cada uno de los sistemas de TIC de la entidad financiera con una fuente de tiempo de referencia fiable y documentada. Sobre el plazo, el reglamento tampoco da un número: obliga a establecerlo atendiendo a los objetivos de negocio y de seguridad de la información, al motivo por el que se registra el evento y al resultado del análisis de riesgos de TIC.

NIS2 empuja en la misma dirección por la vía de las medidas de gestión de riesgos y del tratamiento de incidentes, con el detalle técnico remitido a actos de ejecución para determinados tipos de entidad. La consecuencia práctica para quien tiene que decidir hoy es la misma en los tres marcos: el plazo lo eliges tú, y tienes que poder justificar por qué.

¿Cómo se resuelve la tensión entre detectar y conservar?

Separarlas resuelve el problema, en lugar de pagar el precio de la detección por todo el volumen. La mayoría de las plataformas ofrecen ya capas de almacenamiento con distinto precio y distintas capacidades de consulta. Microsoft, por ejemplo, documenta varias capas de almacenamiento en Azure Monitor con costes y limitaciones distintos, y el resto de fabricantes tiene equivalentes con otros nombres.

El reparto que funciona es directo. En la capa de análisis va lo que consultan las reglas en tiempo real y lo que se usa a diario en la investigación: identidad, endpoint, borde, plano de control de la nube. En la capa barata va el volumen que se necesita para reconstruir un incidente o para cumplir un plazo de retención, pero que no alimenta ninguna regla: registros de flujo, tráfico interno, histórico antiguo de las fuentes caras.

La contrapartida hay que decirla entera, porque los fabricantes tienden a omitirla. Lo que se manda a la capa barata suele perder correlación en tiempo real, consultar más despacio y admitir menos operaciones: sirve para buscar y no siempre para detectar. Mover una fuente allí es una decisión de detección antes que de coste, y se toma mirando qué reglas dependen de esa fuente, no la factura. La guía conjunta apunta al mismo modelo cuando recomienda centralizar y agregar los eventos y reenviar después a las herramientas analíticas solo los registros seleccionados y ya procesados.

¿Por dónde empezar si el SIEM ya está lleno?

Pocos equipos parten de cero. Lo habitual es heredar un SIEM con doscientas fuentes conectadas, un coste que nadie sabe justificar del todo y una sensación difusa de que se detecta poco. El orden que da resultado es el inverso al catálogo de fuentes.

1. Escribe la lista de amenazas que de verdad te importan, a partir de tu sector y de tus activos críticos, y no del catálogo completo de ATT&CK.
2. Por cada una, define la detección que la cubriría y anota qué campos exige esa detección.
3. Comprueba si alguna fuente conectada entrega esos campos hoy. Es aquí donde aparecen las sorpresas: fuentes presentes que no traen el campo, o que lo traen truncado.
4. Revisa qué reglas existentes dependen de fuentes que ya no envían o que cambiaron de esquema. Esa revisión suele recuperar más cobertura que conectar cualquier fuente nueva.
5. Solo entonces decide qué fuente añadir, y mándala a la capa que corresponda a su uso real.

Es trabajo lento y no hay herramienta que lo haga sola. En Hard2bit este trabajo cae dentro del SOC gestionado y de los proyectos de adecuación al ENS y a DORA. Las tres conversaciones acaban en la misma pregunta: qué se registra, con qué calidad y durante cuánto tiempo. Si aún estás decidiendo el modelo operativo antes que las fuentes, empieza por nuestra guía sobre qué es un SOC y qué servicios puede incluir.

La conclusión que dejan los números del principio es poco intuitiva y bastante liberadora. La mayoría de las organizaciones no necesita más datos en el SIEM: necesita detecciones sobre los datos que ya tiene, campos completos en las fuentes que ya paga y un aviso cuando alguna de ellas se calla. Antes de aprobar la siguiente ampliación de licencia, prueba a comprobar cuántas de tus reglas actuales dispararían hoy si alguien reprodujera en tu red la técnica que cada una dice cubrir. Ese porcentaje orienta el presupuesto mejor que cualquier catálogo de fuentes.

Esta guía recoge criterios generales de arquitectura de registro y detección con una finalidad divulgativa y defensiva. Las prioridades de fuentes, los plazos de retención y el reparto por capas deben ajustarse al modelo de amenaza, a la arquitectura y al marco normativo aplicable a cada organización, y validarse en un entorno de pruebas antes de cambiar nada en producción. La interpretación del ENS, de DORA y de NIS2 aquí expuesta no sustituye al asesoramiento normativo sobre un caso concreto. Si necesitas revisar tu estrategia de registro y detección, en Hard2bit podemos ayudarte.