Durante los últimos años, muchas organizaciones han incorporado un SIEM como pieza clave de su estrategia de ciberseguridad. Centralizar logs, cumplir requisitos normativos y “tener visibilidad” suena, sobre el papel, como el paso definitivo hacia una seguridad madura.
Sin embargo, en la práctica, muchas de estas implantaciones acaban generando un problema distinto: una avalancha de eventos que nadie interpreta correctamente. Alertas constantes, falsos positivos, paneles llenos de gráficos… y muy poca capacidad real de detectar un incidente relevante a tiempo.
El problema no es el SIEM. El problema es la falta de contexto.
El error habitual: confundir logs con seguridad
Un SIEM hace exactamente lo que se le pide: recoger eventos. Registra accesos, errores, conexiones, cambios de configuración, ejecuciones de procesos, tráfico de red y un largo etcétera. El volumen crece rápido, especialmente en entornos modernos con nube, SaaS, APIs y trabajo híbrido.
Pero un evento aislado rara vez significa algo por sí mismo. Un login fallido puede ser un error de usuario. Un login exitoso puede ser completamente legítimo… o el inicio de un ataque. Una conexión desde una IP externa puede ser normal… o una señal de compromiso.
Sin contexto, el SIEM no sabe distinguir una cosa de la otra. Y el equipo de seguridad acaba atrapado en una dinámica de reacción constante, apagando alertas sin una visión clara del riesgo real.
Qué significa “contexto” en un SIEM
Hablar de contexto no es una abstracción teórica. En seguridad, el contexto responde a preguntas muy concretas como:
- Quién ha generado este evento.
- Qué identidad hay detrás (usuario, cuenta técnica, servicio).
- Desde qué dispositivo y con qué nivel de confianza.
- A qué sistema o recurso afecta.
- Qué privilegios tiene esa identidad.
- Si ese comportamiento es habitual o anómalo para ese actor.
Un SIEM que solo recibe logs “planos”, sin enriquecer, no puede responder a ninguna de estas preguntas de forma fiable.
Por eso, los estudios y marcos de referencia más utilizados insisten en que la correlación y el enriquecimiento de eventos son tan importantes como la recogida de logs.
La identidad como pieza central del contexto
En los entornos actuales, la mayoría de los incidentes relevantes giran en torno a identidades, como credenciales comprometidas, accesos indebidos, abuso de privilegios, cuentas obsoletas o rutas que se saltan los controles esperados.
Un SIEM sin información de identidad ve solo “eventos de autenticación”. Un SIEM con contexto ve personas, roles, permisos y comportamientos.
Integrar el SIEM con el proveedor de identidad (IdP), el directorio corporativo y los sistemas de autenticación multifactor permite responder preguntas clave:
- ¿Este usuario debería acceder a este sistema?
- ¿Este login ocurre desde un dispositivo gestionado o no?
- ¿Este acceso coincide con el rol y el horario habitual?
- ¿La cuenta está marcada como crítica o es un servicio técnico?
Sin esta capa de identidad, el SIEM pierde gran parte de su valor como herramienta de detección.
Activos y criticidad: no todo vale lo mismo
Otro error frecuente es tratar todos los eventos como si tuvieran la misma importancia. Un fallo de autenticación en un servidor de pruebas no tiene el mismo impacto que uno en un sistema de salud, financiero o de producción.
Aquí entra en juego el inventario de activos y la clasificación de criticidad. Cuando el SIEM conoce qué sistemas existen, cuál es su función, qué nivel de impacto tienen, podrás priorizar correctamente. Un evento “menor” en un activo crítico puede ser más relevante que decenas de eventos ruidosos en sistemas secundarios.
Sin inventario, el SIEM ve máquinas.Con inventario, el SIEM entiende del negocio.
Correlación: cuando el evento aislado deja de ser irrelevante
La mayoría de ataques modernos no se manifiestan en un solo evento claro, sino en una secuencia de acciones pequeñas y aparentemente normales: un login válido, una consulta a una API, un acceso lateral, un cambio de permisos.
La detección real ocurre cuando el SIEM es capaz de correlacionar eventos de autenticación, eventos de red, eventos de endpoint, eventos de identidad y permisos, y construir una historia coherente.
Sin esa correlación, el ataque pasa desapercibido. Con ella, incluso un comportamiento “legal” puede convertirse en una señal clara de compromiso.
Normativa y realidad: ENS no pide ruido, pide control
Desde el punto de vista del Esquema Nacional de Seguridad, registrar eventos no es un fin en sí mismo. La ENS exige capacidad de detección, análisis, auditoría y respuesta.
Sergio Vergara
Un SIEM que genera miles de alertas sin priorización ni interpretación no cumple el espíritu del control, aunque técnicamente “registre todo”. El objetivo no es almacenar logs indefinidamente, sino poder demostrar que la organización entiende lo que ocurre en sus sistemas y actúa en consecuencia.
Por eso, cada vez más auditorías ponen el foco no solo en si hay SIEM, sino en cómo se usa.
El enfoque correcto: menos ruido, más significado
Un SIEM bien planteado no es el centro de la seguridad, sino el punto donde confluyen varias capas, identidad centralizada, inventario de activos, clasificación de riesgos, telemetría de endpoints y red, criterios claros de qué es normal y qué no.
Cuando estas piezas encajan, el volumen de alertas baja, pero la calidad sube. El equipo deja de apagar fuegos y empieza a tomar decisiones informadas.
Conclusión
Un SIEM sin contexto no es inteligencia, es ruido organizado.
La seguridad moderna no consiste en ver más eventos, sino en entenderlos mejor. Y ese entendimiento solo llega cuando el SIEM se alimenta de identidad, activos, roles, permisos y comportamiento real.
En ITDO creemos que implantar un SIEM no es un proyecto de logs, sino un proyecto de arquitectura de seguridad. Porque la diferencia entre cumplir y estar realmente protegido no está en la herramienta, sino en el contexto que le das.
Referencias:
