SIEM corporativo: cómo centralizar la telemetría de seguridad y detectar amenazas en tiempo real.
Autor: Vidal Huillca | Especialista en Seguridad Defensiva.
Administrar la seguridad de una organización sin visibilidad centralizada obliga al equipo técnico a revisar por separado los registros de endpoints, firewalls, servidores, Active Directory y servicios en la nube. En ese escenario, un inicio de sesión fallido puede parecer irrelevante aunque forme parte de un ataque distribuido. Un SIEM en tiempo real reúne esa telemetría, normaliza los eventos y relaciona señales que aisladas perderían contexto. Sin embargo, instalar la plataforma no basta: la calidad de la detección y respuesta de amenazas depende de las fuentes conectadas, las reglas ajustadas al entorno, la priorización del SOC y una automatización aplicada con límites seguros.
¿Qué convierte los registros en una detección útil?
NIST define un SIEM como una aplicación capaz de recopilar datos de seguridad de los componentes de un sistema y presentarlos como información accionable. Esa última palabra marca la diferencia entre almacenar registros y operar seguridad defensiva.
El recorrido técnico puede resumirse así:
Fuente de telemetría → recolección → decodificación → normalización → correlación → alerta → investigación → respuesta
Arquitectura de un SIEM: agentes en el endpoint, motor de análisis (decodificación, correlación, active response) e indexador/dashboard central.
La normalización transforma formatos distintos en campos comparables. Por ejemplo, un evento 4625 de Windows y un mensaje Failed password de SSH expresan fallos de autenticación, aunque su estructura original sea diferente. Una vez normalizados, el SIEM puede relacionarlos por usuario, IP de origen, activo, periodo y resultado. Así, el analista no recibe únicamente “un error de contraseña”, sino una secuencia contextualizada que puede corresponder a fuerza bruta, password spraying o credenciales mal configuradas.
El 4 de septiembre de 2026, Wazuh publicó el caso más reciente localizado sobre el uso de su plataforma en servicios SOC. La experiencia de E Defence destaca el monitoreo y la detección en tiempo real, además del soporte a ISO 27001 y PCI DSS. Aunque se trata de una aplicación empresarial y no de un hallazgo de malware, confirma una lección operativa: la plataforma necesita reglas, análisis y procesos adaptados a cada organización.
Caso práctico: del evento 4625 a una alerta priorizada
Supongamos que el controlador de dominio DC-UMAYUQ.UMAYUQ.COM registra varios intentos contra la cuenta admin desde 192.168.81.129. Windows genera el evento 4625 y el agente de Wazuh lo envía al servidor. El decoder reconoce windows_eventchannel y extrae, entre otros, estos campos:
Evento 4625 recopilado desde el canal Security de un equipo Windows, tal como llega al SIEM antes de ser decodificado.
El decodificador JSON de Wazuh completa la Fase 2 (“Completed decoding”) y estructura el evento recopilado en campos consultables.
Un solo fallo no justifica bloquear una dirección. La regla debe observar repetición y contexto. En Wazuh puede crearse una regla local que se active cuando una regla base de autenticación fallida se repita cinco veces desde la misma IP durante 120 segundos:
Regla base 60122 que dispara ante el evento 4625/529, enriquecida con la técnica MITRE ATT&CK T1531 — la condición sobre la que se apoya la regla local anterior.
Antes de llevarla a producción, el equipo debe validarla con wazuh-logtest, comprobar qué campo contiene realmente la IP y ajustar frecuencia y ventana según el comportamiento normal. También debe excluir escáneres autorizados, servidores de salto y procesos que puedan generar fallos legítimos. Este ajuste reduce falsos positivos sin ocultar ataques lentos.
SCA y vulnerabilidades: priorizar el riesgo con contexto
Una alerta gana valor cuando se relaciona con la postura del activo. Wazuh SCA puede comprobar, por ejemplo, si un servidor permite autenticación SSH insegura mediante /etc/ssh/sshd_config. A la vez, Vulnerability Detection compara el inventario de paquetes del endpoint con información de vulnerabilidades conocidas.
Check SCA 3003 (“SSH Hardening: No Public Key authentication”) en estado Failed, con su justificación y remediación sugerida: modificar PubkeyAuthentication en sshd_config.
Si el SIEM observa intentos repetidos contra un servidor expuesto y SCA indica una configuración débil, el SOC tiene una condición de riesgo más urgente que un fallo aislado en un equipo de pruebas. La prioridad aumenta todavía más si el inventario identifica un paquete vulnerable explotable en ese activo. La correlación útil no es “hay una CVE”, sino: existe una debilidad, el activo está expuesto y ya presenta actividad compatible con abuso.
La remediación debe ejecutarse en la fuente. Para SSH, esto puede implicar corregir la directiva afectada, validar la sintaxis con sshd -t y recargar el servicio en una ventana controlada. El SIEM verifica después si la comprobación SCA pasa y conserva evidencia del cambio.
Tras aplicar la remediación, el check 3003 cambia a Passed: evidencia verificable de que la corrección se aplicó correctamente.
Panel de Vulnerability Detection: severidad, top de CVE, agentes y paquetes afectados — el inventario que se correlaciona con la actividad detectada por el SIEM.
Active Response sin convertir una alerta en una interrupción
Active Response permite ejecutar una acción cuando una regla alcanza el nivel definido. En el caso anterior, Wazuh podría llamar a firewall-drop para bloquear temporalmente 192.168.81.129, siempre que el decoder entregue la dirección atacante en el campo que consume el script de respuesta:
El tiempo de 600 segundos limita el impacto de un falso positivo. En producción también se necesita una lista de exclusión para DNS, VPN, proxies, balanceadores, administradores y sistemas críticos. Las respuestas de mayor impacto —aislar un endpoint, deshabilitar una cuenta o bloquear una IP en un firewall perimetral— deberían exigir enriquecimiento adicional o aprobación humana. La automatización madura no responde a todo; responde cuando la evidencia y el riesgo superan un umbral definido.
Monitoreo SOC, retención y cumplimiento normativo
ISO 27001, PCI DSS y los controles de NIST requieren evidencias, trazabilidad y procesos de respuesta, pero un SIEM no concede cumplimiento por sí solo. La organización debe definir qué registra, quién puede consultar o modificar la información, cuánto tiempo la conserva y cómo protege su integridad.
Una estrategia de retención por niveles mantiene los eventos recientes en almacenamiento hot para búsquedas rápidas, mueve información menos consultada a warm y conserva evidencia histórica en cold o snapshots protegidos. La duración no debe copiarse de una plantilla: depende de obligaciones legales, necesidades forenses, volumen diario, capacidad disponible y riesgo del negocio.
Ciclo de vida de los índices (ISM) en Wazuh Indexer: transición automática entre las fases hot → warm → cold → delete según la política de retención definida.
Para conservar valor probatorio, los sistemas deben mantener tiempo sincronizado, acceso basado en roles, cifrado, registros de auditoría y copias verificables. También debe documentarse la zona horaria y preservarse el evento original junto con la alerta normalizada. De esa manera, el informe de cumplimiento demuestra tanto la existencia del control como su funcionamiento.
Cómo UMAYUQ ayuda a fortalecer la detección
Security Configuration Assessment: evalúa configuraciones contra líneas base como CIS, identifica desviaciones en servicios críticos y entrega una remediación verificable.
Diseño y Arquitectura de Ciberseguridad: define fuentes de telemetría, capacidad de almacenamiento, segregación de roles, retención e integración segura entre infraestructura local y nube.
DISEÑO Y ARQUITECTURA DE CIBERSEGURIDAD
Evaluación Ofensiva: reproduce técnicas como fuerza bruta y abuso de credenciales de forma controlada para comprobar si las reglas detectan el comportamiento y si la respuesta funciona sin afectar la operación.
Conclusión
Un SIEM no es solo un recolector de datos; es la capacidad operativa de reaccionar antes de que un incidente se convierta en una brecha. Un SIEM en tiempo real mejora la detección y respuesta de amenazas cuando conecta telemetría relevante, normaliza correctamente, correlaciona señales con la postura del activo y automatiza únicamente acciones seguras y reversibles.
¿Tu organización cuenta con visibilidad total sobre sus eventos de seguridad? En UMAYUQ diseñamos e implementamos soluciones de monitoreo, SIEM y estrategias de seguridad defensiva adaptadas a la exigencia de tu entorno.
Contáctanos para fortalecer la detección de tu infraestructura
Preguntas frecuentes:
¿Un SIEM reemplaza al analista SOC?
No. Centraliza y prioriza información, pero el analista valida el contexto, investiga el alcance y decide las respuestas de mayor impacto.
¿Todos los eventos deben generar alertas?
No. Los eventos aportan evidencia; las alertas deben reservarse para condiciones relevantes. Alertar por todo aumenta el ruido y oculta incidentes reales.
¿Active Response debe bloquear automáticamente cualquier IP?
No. Debe aplicarse con umbrales, tiempo limitado, exclusiones, registro de la acción y un procedimiento de reversión.
Fuentes consultadas:
- https://csrc.nist.gov/glossary/term/security_information_and_event_management_tool
- https://attack.mitre.org/techniques/T1110/
- https://documentation.wazuh.com/current/getting-started/use-cases/log-analysis.html
- https://documentation.wazuh.com/current/user-manual/ruleset/ruleset-xml-syntax/rules.html
- https://documentation.wazuh.com/current/user-manual/capabilities/active-response/index.html
- https://documentation.wazuh.com/current/user-manual/capabilities/sec-config-assessment/index.html
- https://documentation.wazuh.com/current/user-manual/capabilities/vulnerability-detection/index.html
- https://documentation.wazuh.com/current/user-manual/indexer-api/index-lifecycle-management.html
- https://wazuh.com/blog/wazuh-and-e-defence-announce-partnership-to-improve-soc-services/
Buen aporte!