Qué es un SIEM: definición, cómo funciona y casos de uso

Un SIEM (Security Information and Event Management) es la plataforma que recoge logs y eventos de toda la infraestructura de una empresa, los normaliza, los correlaciona y dispara alertas de seguridad en tiempo real. Es el cerebro de cualquier SOC: convierte millones de líneas de log dispersas (firewall, EDR, Active Directory, cloud, SaaS) en un puñado de alertas accionables que un analista puede investigar y responder. Sin SIEM, los logs existen pero nadie los mira; con SIEM bien configurado, una intrusión que tardaría meses en notarse se detecta en minutos.

Esta guía explica qué es un SIEM, cómo funciona internamente, en qué se diferencia de un SOAR y un XDR, los casos de uso típicos, las plataformas más usadas en el mercado español y cómo encaja en NIS2, ENS, ISO 27001 y PCI DSS.

Qué es un SIEM: definición técnica

Un SIEM es una plataforma de seguridad que centraliza, normaliza y correlaciona eventos procedentes de toda la superficie tecnológica de una organización para detectar amenazas, investigar incidentes y demostrar cumplimiento normativo. La sigla viene del inglés Security Information and Event Management y unifica dos disciplinas que antes iban por separado:

• SIM (Security Information Management): la recogida y conservación a largo plazo de logs.
• SEM (Security Event Management): la correlación y alerta en tiempo real sobre eventos.

La combinación es lo que hace al SIEM útil: recopila histórico para forense y compliance, y al mismo tiempo dispara alertas en cuanto detecta un patrón sospechoso.

Cómo funciona un SIEM por dentro

El flujo operativo de cualquier SIEM, sea Splunk, Microsoft Sentinel, Elastic Security o Wazuh, sigue siempre los mismos seis bloques:

1. Ingesta. Los logs llegan a la plataforma desde decenas de fuentes: firewalls, EDR, servidores, Active Directory, IdP cloud (Okta, Entra ID), aplicaciones, contenedores, SaaS críticos, CloudTrail, Azure Activity Logs y Google Cloud Audit Logs.
2. Normalización. Cada fuente envía los eventos en su formato propio. El SIEM los transforma a un esquema común (campos como user, src_ip, dst_ip, action, timestamp) para poder correlacionarlos entre sí.
3. Enriquecimiento. La plataforma añade contexto a cada evento: geolocalización de IPs, reputación de dominios, identidad del usuario, criticidad del activo, threat intelligence externa (feeds de IoC).
4. Correlación y detección. Reglas y modelos analizan los eventos. Una regla puede ser tan simple como "más de 10 logins fallidos seguidos" o tan compleja como "login desde país nuevo + descarga masiva + creación de regla de reenvío en menos de 15 minutos". Los SIEM modernos suman análisis de comportamiento (UEBA) y machine learning para detectar lo que las reglas estáticas no ven.
5. Alertado y dashboards. Las alertas priorizadas llegan a los analistas L1 del SOC con todo el contexto necesario para triarlas. Los dashboards muestran salud operativa, métricas de cobertura y tendencias.
6. Retención. Los eventos se conservan durante el período exigido por la normativa o las políticas internas. ENS categoría alta exige meses; PCI DSS exige al menos 12 meses; NIS2 no fija plazo concreto pero presupone trazabilidad para investigación de incidentes.

SIEM, SOAR y XDR: en qué se diferencian

Los tres términos se mezclan en pliegos comerciales y no son lo mismo:

• SIEM. Centraliza logs y eventos, correlaciona y alerta. Es la base de detección.
• SOAR (Security Orchestration, Automation and Response). Automatiza la respuesta a las alertas: aislar un endpoint, deshabilitar una cuenta, abrir un ticket, notificar al usuario. Suele integrarse con el SIEM para cerrar el ciclo detect, decide, respond.
• XDR (Extended Detection and Response). Una evolución más reciente, centrada en la telemetría unificada de endpoint, red, identidad y cloud, con detección y respuesta integradas de forma nativa en una sola plataforma del proveedor.

La regla rápida: un SOC moderno usa SIEM como pipeline de eventos, SOAR para orquestar respuesta y XDR como capa profunda de telemetría sobre dominios concretos (típicamente endpoint y cloud).

Casos de uso típicos de un SIEM

Las cinco aplicaciones operativas que justifican un SIEM en una empresa real:

1. Detección de amenazas en tiempo real. Reglas que disparan alertas ante intentos de fuerza bruta, credential stuffing, escalada de privilegios, exfiltración de datos o uso anómalo de cuentas privilegiadas.
2. Detección de comportamiento anómalo (UEBA). Machine learning que aprende el patrón normal de cada usuario y activo y avisa cuando algo se desvía: un empleado de marketing que de pronto consulta bases de RRHH a las 3 AM, una cuenta de servicio que empieza a iterar sobre buckets S3.
3. Investigación forense. Cuando ocurre un incidente, el SIEM permite reconstruir la cronología completa del ataque. Sin SIEM, los logs viven en cada servidor y la reconstrucción tarda semanas.
4. Cumplimiento normativo. Conservación de logs, evidencias auditables, informes recurrentes para cumplir NIS2, ENS, ISO 27001, RGPD o PCI DSS sin construirlos a mano.
5. Threat hunting. Analistas L3 lanzan queries proactivas sobre el histórico de eventos buscando patrones de TTP del MITRE ATT&CK que las reglas estáticas no detectan.

Plataformas SIEM más habituales en el mercado español

El mercado se reparte entre cinco familias principales que conviene reconocer al evaluar proveedores:

• Splunk Enterprise Security. El líder histórico. Muy potente, muy escalable, con coste por GB ingestado que dispara la factura si no se filtra bien la ingesta.
• Microsoft Sentinel. SIEM cloud-native sobre Azure. Atractivo cuando el cliente ya está en Microsoft 365 o Azure por la integración nativa con Defender, Entra ID y Microsoft Graph.
• IBM QRadar. Tradicional en banca y administración pública. Potente correlación, modelo de licencia complejo.
• Elastic Security (ELK Stack). Basado en Elasticsearch. Open source con plan comercial. Flexible y barato a pequeña escala, complejo de operar a escala.
• Wazuh. SIEM open source de origen español, fork de OSSEC. Muy popular en mid-market y administraciones por su modelo gratuito y comunidad activa.
• Sumo Logic, LogRhythm, Securonix, Exabeam. Otras plataformas que aparecen ocasionalmente en pliegos.

La elección no se hace por marca, se hace por volumen de eventos esperado, presupuesto, integraciones existentes y madurez del equipo que va a operar el SIEM.

SIEM y compliance: NIS2, ENS, ISO 27001, PCI DSS

El SIEM es la pieza tecnológica que evidencia varios controles obligatorios en los marcos que aplican a empresas y administraciones en España y la UE:

• NIS2 (artículo 21). Las medidas de gestión de riesgos exigen capacidades de detección, registro y análisis de eventos. Un SIEM operativo es la prueba habitual de cumplimiento.
• ENS (Real Decreto 311/2022). Las medidas op.exp.10 (registro de la actividad), op.mon.1 (detección de intrusiones) y op.exp.8 (registro y revisión) presuponen una plataforma de gestión de logs y eventos centralizada.
• ISO 27001 (controles A.8.15 Logging, A.8.16 Monitoring activities). Exigen registro y revisión sistemática de eventos.
• PCI DSS v4.0 (req. 10). Define detalladamente qué eventos hay que registrar, durante cuánto tiempo (mínimo 12 meses) y cómo revisarlos diariamente. Un SIEM facilita el cumplimiento automatizado.

Si tu organización está bajo cualquiera de estos marcos, el SIEM no es opcional, es la base sobre la que construyes la evidencia.

Cómo elegir un SIEM: cuatro criterios prácticos

Cuatro decisiones marcan el resultado del proyecto:

1. Volumen de eventos esperado y modelo de licencia. Splunk cobra por GB ingestado, Sentinel por GB de retención, Wazuh es gratis pero hay que operarlo. Calcula el volumen real (no el deseado) antes de pedir oferta.

2. Integraciones nativas con tu stack actual. Si ya estás en Microsoft 365, Sentinel se conecta sin esfuerzo. Si tu telemetría viene de un EDR de CrowdStrike, sus integraciones con Splunk y Sentinel son maduras. Las integraciones a medida son donde mueren los proyectos.

3. Madurez del equipo que va a operar el SIEM. Wazuh y ELK son baratos pero requieren equipo capaz de mantener la plataforma. Splunk y Sentinel son caros pero el proveedor sostiene gran parte de la operativa. Si no tienes equipo interno, contratar un MSSP / MDR que opere el SIEM por ti suele ser lo más eficiente.

4. Casos de uso prioritarios. ¿Necesitas UEBA potente desde el día uno? Securonix o Exabeam destacan. ¿Compliance pesado? QRadar tiene plantillas. ¿Threat hunting flexible? Splunk y Elastic.

Errores comunes al implementar un SIEM

Tres formas habituales de tirar el presupuesto:

1. Ingerir todo sin filtrar. La factura crece sin control y los analistas se ahogan en eventos irrelevantes. Filtra logs ruidosos en origen y prioriza fuentes que aportan valor de detección real.
2. Reglas genéricas del fabricante sin adaptar. Las reglas out-of-the-box generan miles de falsos positivos en cualquier entorno real. Hace falta un trabajo continuo de detection engineering para que el SIEM sea útil.
3. Sin equipo que opere las alertas. Un SIEM sin analistas que respondan a las alertas es un repositorio caro de eventos. Si no vas a montar un SOC, contrata uno gestionado.

Preguntas frecuentes

¿Qué diferencia hay entre un SIEM y un SOC?

El SIEM es la plataforma; el SOC es el equipo y los procesos que la operan. Un SIEM sin SOC genera alertas que nadie investiga. Un SOC sin SIEM no puede correlacionar eventos a escala. Funcionan en pareja.

¿Cuánto cuesta un SIEM?

El coste varía enormemente según el volumen de eventos y el modelo. Wazuh es gratis (sólo pagas operación). Splunk y Sentinel pueden ir desde varios miles a decenas de miles de euros al mes según volumen. La factura real depende del filtrado de ingesta, la retención y los addons. Lo razonable es pedir POC con tu volumen real antes de comprometer licencia.

¿Qué es un SIEM cloud-native?

Un SIEM diseñado nativamente para operar en cloud, con modelo de pago por consumo y escalado automático. Microsoft Sentinel es el ejemplo más claro. Elimina el coste de mantener infraestructura propia y suele integrarse mejor con servicios cloud (CloudTrail, Azure Activity, Google Cloud Audit).

¿Sirve un SIEM open source como Wazuh para una empresa mediana?

Sí, con condiciones. Wazuh cubre detección, file integrity monitoring, gestión de vulnerabilidades y compliance básico, y muchas administraciones y mid-market lo usan en producción. Lo que paga la versión gratuita es operación interna: necesitas equipo que mantenga la plataforma, ajuste reglas y atienda alertas. Si no lo tienes, un MSSP que opere Wazuh por ti es opción habitual.

¿Cuánto tiempo hay que conservar los logs en el SIEM?

Depende del marco que aplique. PCI DSS exige al menos 12 meses (con 3 meses inmediatamente accesibles). ENS y RGPD no fijan plazo único, pero la práctica común va de 6 a 24 meses según criticidad. NIS2 presupone trazabilidad suficiente para investigar incidentes, lo que en la práctica significa al menos 12 meses.

¿El SIEM detecta ransomware?

Sí, cuando está bien configurado. Las reglas detectan patrones típicos del ransomware moderno: cifrado masivo de archivos, eliminación de copias de seguridad (shadow copies), creación de procesos sospechosos, comunicación con C2 conocidos, escalada de privilegios y movimiento lateral. El SIEM, combinado con un EDR, es la capa que reduce el tiempo entre el primer movimiento del atacante y la contención.

Recursos relacionados

• Qué es un SOC: el equipo y los procesos que operan el SIEM.
• Qué es un pentesting: cómo el pentesting alimenta las reglas de detección del SIEM.
• Auditoría NIS2 paso a paso: cómo se evidencia la capacidad de detección con un SIEM.
• Servicio de ciberseguridad gestionada: SIEM, EDR y respuesta humana 24/7 integrados.

El SIEM en Secra

En Secra integramos el SIEM dentro del servicio de SIEM gestionado y de ciberseguridad gestionada, con plataforma operada por nuestro equipo, reglas adaptadas al sector del cliente y detection engineering continuo para que la cobertura crezca con la organización. Si quieres una propuesta concreta para tu volumen y stack actual, escríbenos a través de contacto.