¿Qué es SIEM y cómo funciona desde la recopilación de logs hasta el Incidente?

¿Por qué una organización necesita un SIEM?

El primer objetivo es la visibilidad centralizada. Cuando un usuario se conecta desde un país anómalo, su estación de trabajo ejecuta PowerShell, el DNS se conecta a un nuevo dominio y el Firewall detecta tráfico saliente, cada registro por sí solo puede parecer inofensivo. La conexión entre ellos dentro de una ventana de tiempo y en el contexto del mismo usuario y activo puede indicar una cuenta comprometida.

El segundo objetivo es la coherencia. SIEM permite a la organización definir Use Cases, Severity, Owners, Playbooks y criterios de cierre. En lugar de que cada analista decida de nuevo cómo verificar un Password Spray o una alerta de Malware, el equipo trabaja según una lógica y documentación que se puede medir y mejorar.

El tercer objetivo es la retención y la investigación histórica. A veces, la organización descubre un Indicator solo semanas después de la intrusión. Si se guardaron los logs relevantes, se puede buscar la IP, el hash, el dominio o la cuenta hacia atrás, construir una Timeline y evaluar el alcance del daño. La Retention debe definirse según el riesgo, la regulación, el costo y las necesidades de investigación, no según una configuración predeterminada aleatoria.

Primera etapa: fuentes de datos y recopilación

Un Data Source es el lugar donde se origina el evento: Windows Security Log, Syslog de Firewall, Audit log de SaaS, Telemetry de EDR o Authentication log de VPN. La recopilación se realiza mediante Agent, Data Connector, API, Syslog/CEF, Event Forwarding o un servicio en la nube integrado. Cada método tiene ventajas, limitaciones y permisos.

Antes de conectar una fuente, se define el propósito de la recopilación. La pregunta no es "¿qué logs se pueden enviar?", sino "¿qué comportamiento queremos detectar o investigar, y qué campos son necesarios para ello?". Un Password Spray, por ejemplo, requiere al menos tiempo, resultado del inicio de sesión, usuario, dirección de origen y, a veces, aplicación o Tenant. Si falta el campo de usuario, una Rule sofisticada no resolverá el problema.

Parsing, Normalization y Enriquecimiento

Después de la ingesta, el sistema necesita comprender el registro. El Parsing extrae campos de un texto o JSON. La Normalization mapea diferentes nombres a un modelo consistente: src_ip, sourceAddress y ClientIP pueden representar la misma idea. En Microsoft, ASIM proporciona un modelo de normalización que permite escribir Query o Detection contra un Schema uniforme en lugar de adaptar la lógica a cada producto por separado.

La Normalization no elimina la fuente. Es recomendable guardar también el evento sin procesar para verificar detalles e investigar errores de Parsing. Cuando un Parser cambia, una Rule puede dejar de funcionar silenciosamente. Por lo tanto, se miden los Schema changes, los campos vacíos, el Ingestion delay y el volumen anómalo.

El Enrichment agrega contexto que no apareció en el log: la criticidad del activo, el propietario del sistema, el departamento, GeoIP, Threat Intelligence, si la cuenta es Privileged, si la IP pertenece a una VPN corporativa y si la actividad coincide con un Change aprobado. El enriquecimiento cambia la calidad de la decisión. Un intento de inicio de sesión fallido a un servidor de pruebas no es lo mismo que el mismo intento de inicio de sesión a una cuenta de Domain Admin.

Detección: de Query a alerta

Una Detection rule examina los datos según una condición. Puede buscar un Indicator conocido, una secuencia de eventos, un Threshold, una desviación de un Baseline o una combinación de fuentes. Una Scheduled rule ejecuta una Query en intervalos de tiempo y examina una Lookback window. Si los resultados superan un umbral, se crea un Alert. Otros productos importan Alerts ya preparados, y el SIEM puede agrupar varios de ellos en un único Incident.

Una buena Rule comienza con un Use Case y una hipótesis, no con un comando técnico. Debe definirse el comportamiento, qué fuentes son necesarias, qué es una unidad de resultado, qué Entities se mapearán, cuál es la Severity, cuál es el Expected noise y qué debe hacer el analista. Una Rule que no se puede investigar crea una carga incluso si "atrapa" muchos eventos.

La Correlation conecta eventos. Puede identificar cinco fallos seguidos de un éxito, un Process sospechoso después de un nuevo inicio de sesión, o la misma IP frente a muchos usuarios. Es importante recordar: una coincidencia con la regla es una pista para la investigación, no una prueba de ataque. Un analista debe verificar la fuente, el contexto, la Timeline y las explicaciones legítimas.

Incident y Case Management

Un Alert describe una coincidencia específica. Un Incident es un caso de investigación que centraliza Alerts, Entities, Evidence, Timeline, Tasks, Owner, Severity, Status y respuestas. El Case Management permite el Hand-off, la escalada, la documentación y la generación de métricas. El sistema debe mantener una separación entre hechos, interpretación y decisión.

Al abrir un Incident, el analista verifica: quién es el usuario y el activo, cuál es el tiempo de actividad, qué fuentes participaron, si existen Alerts adicionales, cuál es la criticidad del activo y qué ha cambiado en relación con el hábito. Luego ejecuta Queries complementarias, verifica Indicators, construye una Timeline y decide si se trata de un False Positive, Benign Positive o True Positive.

Escenario: Evento de inicio de sesión del servidor a la pantalla del analista

1. Un servidor Windows registra un evento de inicio de sesión con tiempo, usuario, Logon type y dirección de origen.
2. Un Forwarder o Connector envía el evento al SIEM. El sistema agrega el tiempo de ingesta e identifica la fuente de datos.
3. El Parser extrae Account, Computer, Source IP y Result. La capa de Normalization los mapea a campos uniformes.
4. El Enrichment indica que la cuenta es Privileged y que el servidor es Production. Threat Intelligence no identifica la IP, pero GeoIP señala un país inesperado.
5. La Rule identifica varios fallos seguidos de un éxito dentro de una ventana de tiempo. Mapea User, Host e IP y crea un Alert.
6. Otra Alert de EDR identifica un Process anómalo en la misma estación de trabajo. El Alert grouping agrupa ambos en un Incident.
7. El analista verifica MFA, VPN, Process tree, DNS y actividad adicional, construye una Timeline y decide sobre el Containment y la escalada.

Lo que SIEM no hace por sí solo

SIEM no garantiza que todos los datos sean existentes o correctos. No reemplaza el Asset inventory, un IAM correcto, EDR, Network controls o profesionales. Tampoco sabe automáticamente qué es normal para la organización. Sin Owners y Tuning, el sistema puede inundar de Alerts o crear una falsa sensación de seguridad.

La automatización puede enriquecer, abrir un Ticket o aislar un activo, pero una acción automática debe coincidir con el nivel de certeza y el impacto. Bloquear un usuario crítico basándose en una Rule ruidosa puede causar una interrupción. Por lo tanto, se definen Approval, Exceptions, Rollback y Audit trail.

SIEM frente a sistemas relacionados

Checklist para la implementación de un Use Case

• ✓Se definió el comportamiento y no solo el nombre de la Rule.
• ✓Las fuentes de datos y los campos necesarios están disponibles.
• ✓El tiempo de los eventos está sincronizado y la zona horaria es clara.
• ✓Parsing y Normalization se verificaron con ejemplos reales.
• ✓Entities y criticidad de los activos están mapeados.
• ✓Se definieron Threshold, Severity y Expected noise.
• ✓Existe un Playbook con Queries complementarias y una ruta de escalada.
• ✓Se establecieron Owner, Review date y métricas de calidad.
• ✓Se verificaron Retention, costo y permisos de acceso.

Errores comunes

• Conectar todas las fuentes posibles antes de definir Use Cases.
• Confiar en el Timestamp de ingesta en lugar del tiempo del evento.
• Asumir que cada campo llamado user representa la misma identidad.
• Crear una Rule sin Entity mapping o instrucciones de investigación.
• Cerrar Alerts como ruido sin enviar comentarios al Detection owner.
• Mostrar un Dashboard verde cuando una fuente de datos dejó de enviar.
• Guardar logs por un período que no permite la investigación histórica.

Resumen y CTA

Elija un Use Case — por ejemplo, Password Spray — y trace toda la cadena: fuente, campos, Parser, Query, Entity, Incident y acción del analista. Luego, pase a la guía KQL para escribir la primera búsqueda. En el itinerario Cybersecurity & AI de HPI, se practica SIEM como parte de un proceso de investigación completo, incluyendo logs, redes, Windows y respuesta a incidentes.

Preguntas frecuentes