Un SIEM recopila logs, normaliza campos, ejecuta reglas de correlación y genera alertas para triaje. Aprende el recorrido con un ejemplo ejecutable.
Cuando un equipo de seguridad dice que "vio el ataque", normalmente quiere decir que el ataque dejó registros en varios lugares y que un sistema los juntó y levantó una alerta. Ese sistema suele ser un SIEM, por sus siglas en inglés, security information and event management, o gestión de información y eventos de seguridad. Gran parte del trabajo diario de un SOC empieza ahí: el analista abre una alerta, revisa los eventos que hay detrás y decide si alguien tiene que actuar.
Este artículo explica qué hace un SIEM, paso a paso. Verás de dónde vienen los datos, por qué los logs necesitan reorganizarse antes de servir para algo, cómo las reglas de correlación convierten eventos en alertas y qué pasa después de que una alerta se dispara. También verás dónde se ubica el SIEM frente a las herramientas EDR y SOAR, y asociaremos una alerta de ejemplo con una técnica de MITRE ATT&CK para entender cómo una detección se conecta con el comportamiento del atacante.
No necesitas un laboratorio para esta parte. La práctica es un pequeño script en Python que corre en cualquier máquina con Python 3.12, usando logs sintéticos. Genera una alerta real a partir de líneas sin procesar, y puedes cambiar los datos para ver cómo cambia el resultado. Si prefieres una pila completa, las últimas secciones mencionan dos opciones gratuitas que puedes instalar tú mismo.
Un SIEM hace tres trabajos en una misma plataforma. Recopila datos de logs y de eventos de muchas fuentes. Los almacena para que puedas buscarlos después. Y ejecuta reglas sobre esos datos que generan alertas cuando algo coincide con un patrón.
La guía de la NIST sobre gestión de logs de seguridad informática, SP 800-92, describe orientaciones prácticas para desarrollar, implementar y mantener la gestión de logs en una organización. La guía trata la gestión de logs como una práctica continua que el equipo debe planificar y mantener. Un SIEM es una forma común de ejecutar esa práctica a escala, pero no es la única. Un equipo pequeño puede hacer mucho con un servidor central de logs y unas cuantas búsquedas bien escritas.
La palabra "seguridad" del nombre importa menos que la palabra "evento". Un SIEM no sabe por defecto qué es un evento malo. Conoce los eventos que le envías y las reglas que escribes. Su calidad depende de los datos que entran y de las detecciones que corren encima.
Los atacantes casi nunca producen una señal clara. Un fallo de inicio de sesión, una tarea programada nueva y una conexión saliente a un host desconocido son cosas comunes por separado. Juntas pueden describir una intrusión. El SIEM es útil porque puede poner esos registros uno al lado del otro, entre equipos, cuentas y momentos. Una persona que lee archivos sueltos en equipos sueltos no puede hacer eso a escala.
El volumen es la otra razón. Una organización con algunos cientos de equipos puede generar millones de líneas de log al día. Ningún analista las lee todas. El trabajo del SIEM es reducir ese volumen a una lista corta de cosas que una persona debe mirar, con suficiente contexto para decidir rápido.
Un SIEM trabaja por etapas. Cada etapa puede fallar, y muchos problemas de detección se deben a una de ellas.
Una fuente de log es cualquier cosa que escriba un registro de algo que ocurrió. En la mayoría de los entornos, las más comunes son:
Cada fuente describe el mundo desde su propio punto de vista. Un firewall ve una conexión. Un host Windows ve un inicio de sesión. Ninguno ve la historia completa.
La recolección lleva los registros desde la fuente hasta el SIEM. Los métodos habituales son un agente instalado en el host, un reenviador que lee archivos de log, mensajes syslog enviados por la red o una API que extrae eventos de un servicio en la nube. Los agentes pueden capturar más detalle del host. Syslog es simple y muy compatible, pero puede perder mensajes bajo carga si nada los almacena temporalmente.
Los fallos de recolección son silenciosos. Si un servidor deja de enviar logs, el SIEM no muestra un error por defecto. Simplemente no tiene nada que decir de ese servidor, y el silencio puede parecer calma. Los equipos buenos vigilan el volumen de eventos por fuente y crean una alerta cuando una fuente se queda muda.
Cada fuente usa su propio formato. Un sistema escribe el nombre de usuario como user, otro como account, un tercero como subject.name dentro de un JSON anidado. La normalización asigna esos campos a un esquema común, para que una regla pueda decir "el campo de usuario" y referirse a lo mismo en todas las fuentes.
La mayoría de los productos SIEM hacen esto por ti, con parsers integrados o con un esquema publicado. Sea cual sea el producto, el objetivo es el mismo: después de normalizar, una búsqueda de inicios de sesión fallidos se ve igual, venga el evento de Linux, de Windows o de un proveedor de identidad en la nube.
El script de ejemplo de más abajo hace esto a pequeña escala. Toma una línea SSH sin procesar y produce un diccionario con los mismos nombres de campo siempre.
La retención es el tiempo que conservas los logs antes de borrarlos. Suena administrativo, pero decide lo que puedes investigar. Una intrusión descubierta tres meses después necesita logs de hace tres meses. Si la retención es de dos semanas, la evidencia ya desapareció cuando alguien mira.
El período correcto depende de tu política, de las obligaciones legales y regulatorias y del costo del almacenamiento. Las guías de gestión de logs, como la NIST SP 800-92, cubren toda la vida de los datos de log. Por eso la retención debe estar en el plan desde el inicio, y no aparecer cuando el disco se llena. Anota qué guardas, por cuánto tiempo y quién puede leerlo. Después verifica que el borrado ocurra de verdad.
Los datos recientes suelen quedarse en almacenamiento rápido y caro. Los datos antiguos pueden pasar a un almacenamiento más barato y más lento de consultar. La compensación es simple: cuanto más antiguo es el evento, más tarda encontrarlo.
La correlación es el paso en el que el SIEM mira a través de varios eventos, en lugar de dentro de uno solo. Una regla de correlación describe un patrón: una condición, una ventana de tiempo y una clave de agrupación. Cuando aparece el patrón, la regla crea una alerta.
Aquí tienes una regla en lenguaje sencillo para password spraying. La probaremos en la sección práctica.
Group events by source IP over a 10-minute window.
Count distinct user accounts with a failed login from that source.
If the count is 4 or more, and the same source later has a successful login,
create an alert with the source IP, the accounts and the successful login.Dos cosas hacen útil una regla así. Usa más de un evento, de modo que un solo inicio fallido se queda callado. Y agrupa por una clave que encaja con el ataque. Los atacantes que adivinan contraseñas suelen probar una misma contraseña contra muchas cuentas desde un mismo lugar, y esa forma se ve con claridad cuando agrupas por origen.
Una alerta es una afirmación de que algo necesita atención. No es la conclusión de que hubo un ataque. El triaje es la primera decisión después de que la alerta se dispara. El analista se hace cuatro preguntas: si la alerta se basa en datos reales, si la cuenta o el host importan, qué pasó antes y después, y cuál es el siguiente paso. Muchas alertas se cierran aquí como benignas, por ejemplo un escaneo de vulnerabilidades que lanzaste tú mismo, o un usuario que escribió mal la contraseña después de un cambio.
El resultado de un buen triaje es una decisión y una nota. La nota registra qué revisó el analista, para que la siguiente persona no repita el trabajo. Los equipos que se saltan la nota terminan investigando la misma alerta benigna cada semana.
Tres términos aparecen juntos en la mayoría de los SOC, y sus alcances se solapan.
Un SIEM recopila y correlaciona registros de muchas fuentes en todo el entorno. Su fuerza es la amplitud y el historial. Su límite es que solo ve lo que cada fuente informa.
EDR, endpoint detection and response, o detección y respuesta en endpoints, observa los endpoints en detalle. Registra actividad de procesos, cambios en archivos y conexiones de red en cada host, y a menudo puede aislar la máquina. Su fuerza es la profundidad en el endpoint. No ve un log de firewall ni un registro de auditoría de la nube, salvo que lo conectes a ellos.
SOAR, security orchestration, automation and response, u orquestación, automatización y respuesta de seguridad, ejecuta playbooks. Un playbook puede enriquecer una alerta con una consulta de reputación, abrir un ticket, desactivar una cuenta tras una aprobación o avisar a quien esté de guardia. Su fuerza es la respuesta repetible. Sus resultados dependen de la calidad de las alertas que recibe.
Este ejercicio solo necesita Python 3.12. Los logs son sintéticos y usan direcciones del bloque 192.0.2.0/24, reservado para documentación. No tocas ningún sistema. El script lee las líneas, las normaliza, aplica la regla de password spraying y muestra el resultado.
Guárdalo como siem_demo.py:
# Synthetic logs only. 192.0.2.0/24 is a documentation range (TEST-NET-1).
import re
from collections import defaultdict
RAW = """\
2026-11-07T10:00:01Z sshd[811]: Failed password for alice from 192.0.2.44 port 50111
2026-11-07T10:00:03Z sshd[812]: Failed password for bob from 192.0.2.44 port 50112
2026-11-07T10:00:05Z sshd[813]: Failed password for carol from 192.0.2.44 port 50113
2026-11-07T10:00:07Z sshd[814]: Failed password for dave from 192.0.2.44 port 50114
2026-11-07T10:00:09Z sshd[815]: Failed password for erin from 192.0.2.44 port 50115
2026-11-07T10:00:11Z sshd[816]: Accepted password for erin from 192.0.2.44 port 50116
2026-11-07T10:02:00Z sshd[820]: Accepted password for frank from 192.0.2.10 port 50200
2026-11-07T10:03:00Z sshd[821]: Failed password for frank from 192.0.2.10 port 50201
"""
PATTERN = re.compile(
r"^(?P<ts>\S+) sshd\[\d+\]: (?P<outcome>Failed|Accepted) password for "
r"(?P<user>\S+) from (?P<src>\S+) port \d+$"
)
def normalize(line):
m = PATTERN.match(line)
if not m:
return None
return {
"timestamp": m["ts"],
"event_type": "authentication",
"outcome": "success" if m["outcome"] == "Accepted" else "failure",
"user": m["user"],
"source_ip": m["src"],
}
events = [e for e in (normalize(l) for l in RAW.splitlines()) if e]
print(f"normalized {len(events)} events")
# Rule: one source IP fails against 4+ different accounts, then gets a success from that IP.
fails = defaultdict(set)
successes = defaultdict(list)
for e in events:
if e["outcome"] == "failure":
fails[e["source_ip"]].add(e["user"])
else:
successes[e["source_ip"]].append(e)
for ip, users in fails.items():
if len(users) >= 4 and successes.get(ip):
s = successes[ip][0]
print(f"ALERT src={ip} failed_accounts={len(users)} then_success_user={s['user']} at={s['timestamp']}")
print(" mapped: T1110 Brute Force, sub-technique T1110.003 Password Spraying (candidate)")Ejecútalo desde la carpeta donde lo guardaste:
python -I siem_demo.pyLa opción -I ejecuta Python en modo aislado. Ignora las variables de entorno y evita que la carpeta del script entre en la ruta de importación. Es buena costumbre cuando ejecutas un script que no escribiste tú.
En la máquina Windows 11 donde se revisó este artículo, con Python 3.12.10, la salida fue:
normalized 8 events
ALERT src=192.0.2.44 failed_accounts=5 then_success_user=erin at=2026-11-07T10:00:11Z
mapped: T1110 Brute Force, sub-technique T1110.003 Password Spraying (candidate)El script mantiene la regla corta a propósito. No aplica la ventana de 10 minutos de la versión en lenguaje sencillo ni comprueba que el éxito llegara después de los fallos. Una regla en producción haría ambas cosas.
Cinco cuentas fallaron desde una misma dirección en unos diez segundos. Después, erin inició sesión con éxito desde esa misma dirección. La regla se disparó porque se cumplieron las dos condiciones: muchas cuentas, pocos intentos en cada una, y un éxito después. Un error de tecleo o una contraseña guardada rara vez se ven así.
Ahora mira la segunda fuente, 192.0.2.10. Frank inició sesión con éxito, y más tarde apareció un fallo. La regla no se disparó, porque solo una cuenta falló desde esa dirección. Ahí está la función de la clave de agrupación. Un solo inicio fallido es ruido. Cinco cuentas distintas fallando desde un mismo lugar forman un patrón.
Cambia los datos para ver las compensaciones. Si borras la línea de éxito de erin, la alerta desaparece aunque los fallos sigan ahí, porque la regla exige ambas cosas. Si subes el umbral a 6, la alerta también desaparece, ya que solo fallaron cinco cuentas. En producción, una regla más estricta deja pasar ataques lentos, y una regla más laxa se dispara con más comportamiento normal.
MITRE ATT&CK es una base de conocimiento pública sobre el comportamiento de los adversarios. Cada técnica tiene un ID, una táctica y una descripción, y la guía de detección de algunas técnicas enumera las fuentes de datos que las revelan.
La alerta encaja con T1110, Brute Force, dentro de la táctica Credential Access. ATT&CK describe la fuerza bruta como intentos repetidos de acceder a cuentas cuando el atacante no conoce la contraseña. Enumera cuatro subtécnicas. Password Spraying (T1110.003) consiste en probar una o pocas contraseñas contra muchas cuentas, lo que evita bloquear cualquier cuenta concreta. Password Guessing (T1110.001) prueba muchas contraseñas contra una sola cuenta. Credential Stuffing (T1110.004) reutiliza contraseñas filtradas de otros servicios. La página también apunta a una estrategia de detección que correlaciona fallos de autenticación entre plataformas, la misma idea que nuestra regla pequeña.
Fíjate en la palabra "candidato" de la salida. La regla coincide con un patrón, y ese patrón es compatible con spraying. También es compatible con un servicio mal configurado que prueba varias credenciales guardadas, o con una prueba interna. El triaje tiene que comprobar cuál de los casos es. El mapeo con ATT&CK indica dónde mirar y qué comportamiento relacionado revisar después, como el uso de cuentas válidas (T1078) tras un inicio de sesión exitoso. No prueba que el ataque ocurrió.
Puedes aprender la mayor parte de esto sin comprar nada. Dos opciones abiertas cubren el camino desde la recolección hasta la alerta. Ejecuta cualquiera de las dos en un equipo libre o en una máquina virtual.
La documentación de Wazuh lo describe como una plataforma de seguridad gratuita y de código abierto que unifica capacidades de XDR y SIEM. Tiene tres componentes centrales, el indexador de Wazuh, el servidor de Wazuh y el panel de Wazuh, más un agente universal instalado en los sistemas que monitorizas. La guía de primeros pasos ofrece un quickstart que instala la pila en pocos minutos. También documenta instalaciones paso a paso, máquinas virtuales, Docker y Kubernetes. Revisa la documentación vigente para la versión y los comandos exactos, porque cambian entre lanzamientos.
Para practicar, instala un agente en una máquina virtual Linux. Desde una segunda máquina virtual que controles, haz algunos intentos de inicio de sesión SSH fallidos y observa cómo llegan los eventos al panel. Eso cubre recolección, normalización y alertas en un pipeline real.
Elastic Security documenta un SIEM construido sobre Elastic Stack. Su visión general describe la recolección de datos mediante integraciones y Elastic Agent, la detección con reglas predefinidas, reglas propias y machine learning, el triaje de alertas, Timeline para la caza de amenazas y Cases para registrar investigaciones. Qué funciones de estas incluye una instalación autogestionada depende del nivel de licencia, así que lee la página de suscripciones de Elastic antes de desplegar. La visión general no enumera qué funciones de SIEM recibe una instalación autogestionada sin costo, así que no des por hecho que un plan gratuito cubra una función de detección concreta.
Empieza por la guía NIST SP 800-92. Es organizativa y de alto nivel, así que léela por las preguntas que plantea, como quién es responsable de cada fuente de log y cuánto tiempo guardas cada una. Después abre la página de ATT&CK para T1110 y lee las notas de detección junto a las subtécnicas.
Luego instala Wazuh o Elastic en una máquina virtual y envía logs de una fuente que controles. Escribe una regla que coincida con un patrón que puedas disparar a propósito, y después escribe la nota de triaje como si un colega fuera a retomarla mañana.
El siguiente artículo de esta serie trata del registro de eventos de Windows y de los ID de evento que dependen muchas reglas de correlación, lo que facilita leerlas: registros de eventos de Windows e IDs de evento. Si quieres ver cómo se escribe una detección en la práctica, escribir una regla YARA contra un archivo de prueba benigno muestra la misma idea de probar una regla con datos conocidos antes de confiar en ella.
Detección y blue team
Lee el registro Security de Windows: auditoría, eventos 4624, 4625, 4634, 4672, 4688 y 1102, qué agrega Sysmon y un inicio de sesión fallido tuyo.
Detección y blue team
Escribe una regla Sigma para fallos de inicio de sesión en Windows, valida, convierte a Splunk y prueba con eventos buenos y malos.