Un incidente de seguridad rara vez llega sin avisar. Casi siempre deja un rastro: un intento de acceso repetido, un usuario que aparece en un servidor donde nunca había entrado, una conexión saliente hacia una dirección desconocida a las tres de la madrugada. El problema es que esas señales están registradas, pero nadie las está mirando. Viven dispersas en decenas de ficheros de log que solo se abren cuando ya es demasiado tarde.
Un SIEM (Security Information and Event Management) existe precisamente para cerrar esa brecha: recoge los eventos de toda la infraestructura en un único punto, les da un formato común, los correlaciona buscando patrones de ataque y avisa cuando algo no encaja. En este artículo repasamos el problema de los logs dispersos, qué es exactamente un SIEM, sus componentes, los casos de uso reales, las herramientas disponibles, los retos de operarlo y qué exigen normativas como NIS2, el ENS y la ISO 27001.
El Problema de los Logs Dispersos
Cualquier infraestructura genera un caudal continuo de registros. El firewall anota conexiones aceptadas y rechazadas; cada servidor guarda intentos de autenticación, escaladas de privilegios y arranques de servicio; las aplicaciones registran errores y accesos; el balanceador, el hipervisor, el backup, el antivirus y el switch producen sus propios logs. En una empresa mediana pueden ser fácilmente decenas de fuentes generando millones de líneas al día.
El primer problema es que esos registros están aislados. Un intento de fuerza bruta en el firewall y un login exitoso en un servidor son, por separado, dos entradas anodinas en dos ficheros distintos que casi nadie relaciona. El segundo problema es aún más grave: los logs locales se rotan y se borran. Cuando por fin se detecta un incidente y alguien va a buscar las pruebas, es habitual descubrir que el fichero relevante ya se sobrescribió hace semanas, o peor, que el propio atacante lo borró para cubrir su rastro.
A esto se suma que investigar a mano es inviable. Reconstruir la cronología de un incidente saltando por SSH entre servidores, abriendo ficheros con formatos diferentes y sin poder cruzar información no escala. Por eso el primer paso hacia una seguridad madura es centralizar los logs en un sistema externo, seguro y con retención garantizada. Es la misma filosofía que aplicamos a la observabilidad con métricas, logs y trazas, pero enfocada específicamente a la seguridad.
Qué es un SIEM
SIEM son las siglas de Security Information and Event Management. Es una plataforma que centraliza, normaliza y correlaciona los eventos de seguridad de toda la infraestructura para detectar amenazas en tiempo real. No es un simple almacén de logs: su valor está en la inteligencia de seguridad que aplica sobre ellos. Donde un archivo de logs solo guarda líneas, un SIEM entiende qué significan y busca activamente combinaciones sospechosas.
El concepto nació de la fusión de dos disciplinas: el SIM (Security Information Management), centrado en el almacenamiento y análisis histórico de logs, y el SEM (Security Event Management), centrado en el análisis en tiempo real y las alertas. Un SIEM moderno combina ambos: retiene la información para investigar el pasado y correlaciona el flujo entrante para alertar del presente. El resultado es una única consola desde la que un analista ve lo que ocurre en toda la organización, sin saltar de servidor en servidor.
Componentes: de la Recolección al Forense
Un SIEM se articula en una cadena de procesamiento donde cada etapa aporta una capa de valor sobre la anterior:
- check_circle Recolección: agentes instalados en los equipos, protocolo syslog para dispositivos de red, y APIs para servicios cloud y SaaS envían los eventos al SIEM desde cada fuente.
- check_circle Normalización y parseo: cada fuente escribe en un formato distinto. El SIEM traduce todos los eventos a un esquema común (usuario, IP origen, acción, resultado, timestamp) para poder compararlos entre sí.
- check_circle Correlación por reglas: el motor cruza eventos de fuentes distintas buscando patrones. "Diez fallos de login seguidos de un acceso correcto y una conexión saliente" es una regla de correlación, no un simple filtro.
- check_circle Alertas: cuando una regla se dispara, el SIEM genera una alerta priorizada por severidad y la envía por correo, chat o ticket para que un analista la investigue.
- check_circle Dashboards: paneles visuales que muestran el estado de seguridad en tiempo real, las tendencias y los indicadores clave para la dirección y el equipo técnico.
- check_circle Retención: el almacenamiento a largo plazo de los eventos, imprescindible para el análisis forense tras un incidente y para demostrar cumplimiento ante una auditoría.
La clave está en la correlación:
Centralizar logs resuelve el dónde busco. La correlación resuelve el qué significa. Sin correlación tienes un buen buscador de logs; con ella tienes un sistema que detecta ataques que ninguna fuente individual podría revelar por sí sola.
Casos de Uso: Qué Amenazas Detecta
La utilidad de un SIEM se ve mejor con los escenarios concretos que permite detectar y que, con logs dispersos, pasarían desapercibidos:
- check_circle Fuerza bruta y password spraying: ráfagas de intentos fallidos de autenticación contra SSH, RDP, VPN o el panel de correo, incluso repartidos entre varias IP para evadir bloqueos simples.
- check_circle Movimiento lateral: una cuenta que, tras iniciar sesión en un equipo, empieza a autenticarse en otros servidores donde nunca había entrado, señal clásica de un atacante desplazándose por la red.
- check_circle Exfiltración de datos: transferencias salientes anormalmente grandes o hacia destinos desconocidos, especialmente fuera del horario habitual de trabajo.
- check_circle Cambios no autorizados: modificaciones en ficheros críticos del sistema, creación de nuevas cuentas con privilegios o alteraciones de la configuración de seguridad sin un ticket que las respalde.
- check_circle Correlación entre fuentes: el verdadero superpoder del SIEM es unir puntos. Un login exitoso justo después de una alerta del antivirus y seguido de una conexión a un dominio recién registrado cuenta una historia que ninguna fuente aislada revela.
Para orientar qué recoger primero, esta tabla resume fuentes de log habituales, qué ayudan a detectar y qué prioridad conviene darles en una implantación por fases:
| Fuente de log | Qué detecta | Prioridad |
|---|---|---|
| Autenticación (SSH, RDP, VPN) | Fuerza bruta, accesos no autorizados, cuentas comprometidas | Alta |
| Firewall / IDS-IPS | Escaneos, conexiones a C2, exfiltración, tráfico anómalo | Alta |
| Sistema operativo / auditoría | Escalada de privilegios, cambios de cuentas, movimiento lateral | Alta |
| Aplicación web / WAF | Inyección SQL, XSS, abuso de API, enumeración | Media |
| Antivirus / EDR | Malware, ransomware, procesos sospechosos | Alta |
| Cloud / SaaS (IAM, M365) | Accesos imposibles, permisos alterados, apps no autorizadas | Media |
| DNS / proxy | Dominios maliciosos, tunneling, comunicación con C2 | Media |
| Backup / almacenamiento | Borrado o cifrado masivo, manipulación de copias | Media |
SIEM vs Agregación de Logs: SOC y SOAR
Es fácil confundir un SIEM con una plataforma de agregación de logs como Loki o el stack ELK (Elasticsearch, Logstash, Kibana). Ambas centralizan y permiten buscar, pero la diferencia es de propósito: la agregación resuelve la observabilidad (¿qué está haciendo mi sistema?), mientras que el SIEM añade una capa de inteligencia de seguridad encima (¿me están atacando?). Un SIEM incorpora reglas de correlación de seguridad, catálogos de amenazas, enriquecimiento con threat intelligence y flujos de investigación que una herramienta de logs genérica no trae de fábrica.
Alrededor del SIEM conviven otros dos conceptos que no hay que mezclar. El SOC (Security Operations Center) es el equipo de personas y procesos que vigila la seguridad, normalmente usando un SIEM como herramienta central. El SOAR (Security Orchestration, Automation and Response) es la capa que automatiza la respuesta: cuando una alerta se dispara, un SOAR puede aislar un equipo, bloquear una IP o abrir un ticket sin intervención humana. Dicho de forma simple: el SIEM detecta, el SOAR responde de forma automatizada y el SOC es el equipo que orquesta ambos.
Herramientas SIEM: Open Source y Comerciales
El ecosistema ofrece opciones para cada presupuesto y nivel de madurez, tanto de código abierto como comerciales:
- arrow_right Wazuh: la referencia open source. Combina SIEM y XDR con agentes ligeros, detección de intrusiones, monitorización de integridad de ficheros y reglas de cumplimiento listas para usar. Excelente relación coste/capacidad para pymes.
- arrow_right Elastic Security: construido sobre el stack Elastic, aporta detección basada en reglas y en machine learning, con gran capacidad de búsqueda y visualización sobre grandes volúmenes.
- arrow_right Graylog: gestión de logs con una capa de seguridad muy sólida, alertas flexibles y un modelo de despliegue sencillo, popular en entornos que quieren empezar de forma gradual.
- arrow_right Splunk y Microsoft Sentinel: las referencias comerciales. Splunk destaca por su potencia de análisis y su ecosistema de apps; Sentinel es un SIEM nativo en la nube de Azure con integración directa en el ecosistema Microsoft. Ambos son muy capaces, pero su coste por volumen de ingesta escala rápido.
La elección no depende solo de la herramienta, sino de quién la va a operar. Un SIEM sin gente que ajuste sus reglas y revise sus alertas acaba siendo un panel bonito que nadie mira. Por eso muchas organizaciones lo integran dentro de un servicio de monitorización gestionada en lugar de montarlo por su cuenta.
Retos: Volumen, Ruido y Personal 24/7
Desplegar un SIEM no es solo instalar software; conlleva tres retos que conviene anticipar. El primero es el volumen de datos y su coste: ingerir y almacenar millones de eventos diarios consume capacidad de cómputo y, sobre todo, de almacenamiento. Muchas plataformas comerciales facturan por gigabyte ingerido, de modo que enviarlo todo sin criterio dispara la factura. La estrategia sensata es filtrar en origen, priorizar las fuentes de alto valor y aplicar retención por capas.
El segundo reto es el ruido y la fatiga de alertas. Un SIEM recién instalado genera cientos de alertas al día, la mayoría falsos positivos. Si el equipo se acostumbra a ignorarlas, la alerta real pasará desapercibida entre el ruido. La solución es el tuning continuo: afinar reglas, ajustar umbrales y silenciar el comportamiento legítimo hasta que cada alerta que llega merezca ser investigada. Es un trabajo constante, no una configuración de una sola vez.
El tercer reto es el personal. Los ataques no respetan el horario de oficina; muchos se lanzan de madrugada o en fin de semana precisamente porque saben que nadie mira. Mantener vigilancia 24/7 exige turnos y un equipo especializado que la mayoría de pymes no puede permitirse. Por eso lo habitual es externalizar la operación a un SOC gestionado o a un servicio MDR (Managed Detection and Response), que aporta la tecnología, los analistas y la respuesta continua sin la carga de construir un equipo interno. Complementa muy bien un ejercicio previo de auditoría de ciberseguridad para saber qué proteger primero.
Cumplimiento y Retención de Logs: NIS2, ENS e ISO 27001
Más allá de la detección, un SIEM se ha convertido en una pieza para cumplir la normativa. La directiva NIS2, el Esquema Nacional de Seguridad (ENS) y la norma ISO 27001 exigen —cada una con su alcance— registrar y monitorizar los eventos de seguridad, ser capaz de detectar incidentes y demostrar que se dispone de trazabilidad. No basta con decir que se vigila: hay que poder probarlo con registros conservados y consultables.
Esto convierte la retención en un requisito de primer orden. Los logs también necesitan capacidad, y a veces inmutabilidad: si un atacante o un error pueden alterar los registros, dejan de servir como prueba. Por eso la buena práctica es almacenar los eventos en un repositorio externo, con control de acceso estricto y, para el material forense, en soportes de solo lectura tipo WORM. Como referencia, se suele mantener entre 6 y 12 meses de logs consultables en caliente y varios años en almacenamiento inmutable de bajo coste para auditoría e investigación. Puedes profundizar en el marco general en nuestra sección de seguridad gestionada.
EasyDataHost: Monitorización Gestionada y Retención de Logs
En EasyDataHost ayudamos a que la centralización de logs deje de ser un proyecto pendiente y se convierta en una capacidad operativa real:
- arrow_right Monitorización gestionada de tu infraestructura, con recogida y correlación de eventos para detectar amenazas sin que tengas que montar y operar la plataforma por tu cuenta.
- arrow_right Almacenamiento para retención de logs con capacidad escalable y opciones de inmutabilidad, para cumplir los plazos que exigen NIS2, el ENS y la ISO 27001.
- arrow_right Datacenter propio en España, con certificación ISO 27001 y conformidad ENS, para que tus registros de seguridad no salgan de una infraestructura soberana.
- arrow_right Soporte 24/7 y acompañamiento técnico para definir qué fuentes recoger primero y cómo priorizar las alertas según tu perfil de riesgo.
Si quieres dejar de tener logs dispersos y empezar a detectar antes de lamentar, nuestro servicio de monitorización gestionada es el punto de partida. Contacta con nuestro equipo para un análisis técnico sin compromiso.
Preguntas Frecuentes
¿Qué diferencia hay entre un SIEM y una simple agregación de logs?
Una plataforma de agregación como Loki o ELK centraliza los logs y permite buscarlos, pero no incluye inteligencia de seguridad. Un SIEM añade normalización, reglas de correlación entre fuentes distintas, alertas priorizadas y retención orientada al cumplimiento. Gracias a esa correlación detecta patrones de ataque que un log aislado nunca revela, como una fuerza bruta seguida de un acceso exitoso y una conexión saliente inusual.
¿Necesita una pyme un SOC 24/7 propio para aprovechar un SIEM?
No necesariamente en propiedad. Un SIEM solo genera valor si alguien revisa y ajusta continuamente sus alertas para reducir el ruido. Muchas pymes externalizan esa operación a un SOC gestionado o a un servicio MDR, obteniendo monitorización y respuesta 24/7 sin tener que mantener un equipo de seguridad interno ni cubrir turnos de noche y fines de semana.
¿Cuánto tiempo hay que conservar los logs de seguridad?
Depende de la normativa aplicable. El ENS y la norma ISO 27001 exigen registrar y monitorizar los eventos de seguridad, y marcos como NIS2 refuerzan la obligación de trazabilidad. Como referencia práctica, se suele conservar entre 6 y 12 meses de logs consultables en caliente y hasta varios años en almacenamiento inmutable para poder realizar análisis forense y responder a auditorías.
Conclusión
Los logs dispersos son una promesa de evidencia que casi nunca se cumple: cuando los necesitas, ya se han rotado, borrado o son imposibles de cruzar. Un SIEM transforma ese caos en capacidad de detección:
- arrow_right Centraliza y normaliza los eventos de toda la infraestructura en un único punto seguro y con retención garantizada.
- arrow_right Correlaciona fuentes distintas para detectar fuerza bruta, movimiento lateral, exfiltración y cambios no autorizados que ningún log aislado revela.
- arrow_right El SIEM detecta, el SOAR responde y el SOC es el equipo: la tecnología sola no basta, hace falta tuning continuo y vigilancia, por eso muchas pymes optan por un SOC gestionado o MDR.
- arrow_right Es también cumplimiento: NIS2, ENS e ISO 27001 exigen registro, monitorización y retención, a menudo con inmutabilidad para que los logs sirvan como prueba.