Desplegar SIEM por primera vez: la guía sin vueltas
En pocas palabras: Un SIEM centraliza y correlaciona logs de servidores, firewalls y aplicaciones para detectar amenazas. En un primer despliegue (documentado el 30 de julio de 2026 en un lab CloudShare), lo típico es fallar en la conectividad: puertos cerrados y agentes mal configurados. Empezá con Wazuh o el stack ELK.
Desplegar SIEM por primera vez es una mezcla rara de emoción y desconcierto: montás el stack, empezás a mandar logs y de golpe descubrís que un puerto que jurabas abierto estaba cerrado. Eso le pasó a quien documentó su primer despliegue en un laboratorio CloudShare esta semana (30 de julio de 2026): nada explotó, pero varias cosas se prendieron fuego en sentido figurado.
Un SIEM (Security Information and Event Management) es un sistema que centraliza, correlaciona y analiza logs de múltiples equipos para detectar amenazas, auditar actividad y cumplir requisitos regulatorios. Reúne eventos de servidores Windows, workstations Linux, firewalls y aplicaciones en un solo lugar, y dispara alertas cuando aparece un patrón sospechoso. Las opciones más habituales para arrancar son Wazuh, el stack ELK y plataformas comerciales.
En 30 segundos
- Qué es: un SIEM centraliza logs de todos tus equipos para detectar ataques, auditar y cumplir normativas, en vez de tener los registros dispersos en cada máquina.
- Con qué arrancar: Wazuh es una opción popular por ser gratuita y tener comunidad activa; ELK es más flexible pero pide más laburo manual.
- El paso clave en Windows: instalar Sysmon v14 con el archivo
sysmonconfig-export.xmly habilitar la Auditoría Avanzada por Group Policy (gpedit.msc) antes de centralizar nada. - Qué capturar: creación de procesos, conexiones de red y actividad de PowerShell, todo hacia el canal
Microsoft-Windows-Sysmon/Operational. - El error clásico: no sincronizar la hora entre equipos, lo que rompe la correlación de eventos y te deja el dashboard mintiendo.
¿Qué es un SIEM y por qué lo necesitás en tu infraestructura?
Un SIEM es la herramienta que junta todos los logs de tu red en un punto central y los analiza en busca de comportamiento sospechoso. Sin él, cada servidor guarda sus registros por separado, y cuando pasa algo raro tenés que entrar máquina por máquina a leer archivos gigantes. Con un SIEM, todo llega a un mismo dashboard.
Pensá en un caso concreto. Alguien intenta loguearse a tu Windows Server 50 veces en dos minutos y falla siempre. Si los logs están dispersos, quizás lo ves la semana que viene (si es que lo ves). Con un SIEM que correlaciona eventos de logon, salta una alerta al toque y sabés que hay un intento de fuerza bruta en curso.
El valor real está en tres frentes: detección temprana de amenazas, auditoría forense y cumplimiento. Y hay un beneficio extra que se subestima: centralizar los logs los protege. Si un atacante entra a un equipo y borra los registros locales, la copia ya viajó al SIEM. Esa inmutabilidad es lo que hace que un análisis forense sea confiable. Relacionado: soluciones de Microsoft versus GitHub.
¿Qué requisitos necesitás antes de desplegar SIEM?
Para desplegar SIEM necesitás tres cosas: cómputo suficiente para procesar el volumen de logs, conectividad entre los equipos y el colector, y algo que casi todos olvidan, la sincronización de fecha y hora entre todos los sistemas. Sin reloj sincronizado, la correlación de eventos se vuelve imposible y las alertas pierden sentido.
En el laboratorio del artículo original, la topología era tres máquinas virtuales: un Windows Server como objetivo, una workstation Ubuntu Linux y el stack SIEM propiamente dicho. Es el mínimo razonable para probar: un emisor de logs, un cliente y el cerebro que los junta.
- Cómputo y almacenamiento: los logs se acumulan rápido, sobre todo con Sysmon capturando cada proceso. Reservá disco de sobra desde el día uno; subestimar el almacenamiento es de los tropiezos más comunes.
- Conectividad: los agentes tienen que alcanzar el servidor SIEM por los puertos correspondientes. Acá es donde aparece el clásico “¿por qué este puerto está cerrado otra vez?”.
- Sincronización horaria: configurá NTP en todos los equipos antes de ingerir nada. Si un servidor está 10 minutos adelantado, el SIEM correlaciona mal y te muestra ataques que no existen (o esconde los que sí).
- Permisos administrativos: vas a tocar Group Policy y a instalar servicios, así que necesitás credenciales de administrador en cada máquina.
Si vas a montar el stack sobre un VPS o servidor cloud en Argentina, en donweb.com tenés infraestructura para levantar el entorno sin depender de un laboratorio prestado.
¿Qué herramientas SIEM podés elegir para tu primer despliegue?
Para un primer despliegue, las tres opciones más habituales son Wazuh, el stack ELK y las plataformas comerciales tipo Fortinet. Wazuh es una de las más elegidas porque es gratuita, de código abierto y tiene guías en castellano, según coberturas como la de nextret.net sobre Wazuh.
El tema es que cada una pega distinto según tu curva de aprendizaje. Wazuh viene preconfigurada con agentes, reglas de detección y dashboard listo; te sentás y arrancás. ELK (Elasticsearch, Logstash y Kibana) es más flexible y potente, pero tenés que ensamblar y configurar cada pieza vos. Las comerciales resuelven mucho de fábrica a cambio de licenciamiento.
| Herramienta | Costo | Curva de aprendizaje | Soporte en español | Ideal para |
|---|---|---|---|---|
| Wazuh | Gratis (open source) | Media, viene preconfigurada | Amplio, guías en castellano | Primer despliegue, PyMEs |
| ELK Stack | Gratis (base) / pago avanzado | Alta, ensamblás cada componente | Comunidad grande, menos en español | Equipos que quieren control total |
| Fortinet (FortiSIEM) | Comercial, con licencia | Media, soporte de fabricante | Soporte oficial pago | Empresas con presupuesto de licencia |
¿Mi recomendación para empezar? Wazuh. No porque sea “mejor” en abstracto, sino porque el objetivo de un primer despliegue es aprender el flujo completo (generar log, reenviarlo, verlo en el dashboard) sin pelearte con la instalación. Eso sí: si tu equipo ya vive en Elasticsearch, ELK tiene sentido.
¿Cómo instalar y configurar Sysmon en Windows Server?
Sysmon (System Monitor) es una herramienta de Microsoft que registra actividad detallada del sistema (creación de procesos, conexiones de red, cambios de archivos) en el registro de eventos de Windows. En el despliegue documentado se usó Sysmon v14 con un archivo de configuración personalizado, sysmonconfig-export.xml, para volcar todo al canal Microsoft-Windows-Sysmon/Operational. Esto se conecta con lo que analizamos en malware detectado en repositorios.
La instalación en sí es corta. Descargás Sysmon desde la documentación oficial de Microsoft, lo instalás desde la línea de comandos apuntando al archivo de configuración y listo: el servicio empieza a registrar. Lo importante no es el binario, es el XML de configuración, porque ahí definís qué eventos capturar y cuáles ignorar.
- Creación de procesos: cada vez que se lanza un ejecutable queda registrado. Combinado con el logging de línea de comandos, ves exactamente qué comando se corrió.
- Conexiones de red: Sysmon anota qué proceso abrió qué conexión saliente, clave para detectar malware que llama a casa.
- Actividad de PowerShell: uno de los vectores de ataque más usados; capturarlo es prioritario.
Un detalle que suma un montón: habilitar “Include command line in process creation”. Sin eso, ves que se ejecutó powershell.exe pero no qué le pasaron como argumento. Con eso, ves el comando entero. La diferencia entre “corrió PowerShell” y “corrió PowerShell con un script codificado en base64” es enorme para un analista.
¿Cómo habilitar la auditoría avanzada en Windows?
La auditoría avanzada se habilita por Group Policy: abrís gpedit.msc y navegás a Computer Configuration > Windows Settings > Security Settings > Advanced Audit Policy Configuration. Ahí activás como mínimo Audit Logon (éxito y fallo) y Audit Process Creation. Sin este paso, Windows ni siquiera genera muchos de los eventos que el SIEM espera recolectar.
¿Por qué es crítico hacerlo antes de centralizar? Simple: si el evento no se genera en el origen, no hay nada para reenviar. Muchos primerizos configuran todo el pipeline, prenden el SIEM y se quejan de que el dashboard está vacío. El problema no era el SIEM, era que Windows nunca estuvo auditando en el nivel de detalle necesario.
Auditar los logon te da el rastro de quién entró y quién falló al intentarlo. Auditar la creación de procesos te da el rastro de qué se ejecutó. Con esos dos activados ya tenés material serio para detectar tanto accesos no autorizados como ejecución de código sospechoso. Cubrimos ese tema en detalle en monitorear caídas en DNS.
¿Cómo centralizar logs desde varios servidores a tu SIEM?
La centralización se logra reenviando los eventos desde cada equipo al servidor SIEM, ya sea con agentes (como los de Wazuh), con Windows Event Forwarding (WEF) mediante suscripciones de eventos, o con reenvío syslog en equipos Linux y dispositivos de red. El agente lee el log local y lo empuja al colector central.
En un stack Wazuh, instalás el agente en el Windows Server y en la workstation Ubuntu, los apuntás al manager y automáticamente empiezan a reportar. Para equipos Linux, el reenvío por syslog es el camino estándar. La gracia es que, sin importar el sistema operativo de origen, todo aterriza en el mismo lugar con un formato normalizado.
Acá viene lo bueno: una vez que los agentes reportan, esa copia centralizada es tu red de seguridad forense. Aunque un atacante limpie los logs de la máquina comprometida, el registro ya viajó y quedó fuera de su alcance.
Errores comunes al desplegar un SIEM por primera vez
El primer despliegue casi siempre destapa problemas de configuración que no viste venir. Estos son los que más se repiten.
- No sincronizar la hora entre equipos: es el error número uno. Si los relojes no coinciden, la correlación de eventos falla y el SIEM te muestra una línea de tiempo falsa. Corrección: configurá NTP en todos los sistemas antes de ingerir el primer log.
- Olvidar habilitar la auditoría antes de centralizar: si Windows no audita, no hay eventos para mandar. Corrección: activá la Advanced Audit Policy en
gpedit.msccomo primer paso, no como último. - Subestimar el almacenamiento: Sysmon genera un volumen enorme de eventos. Corrección: dimensioná el disco pensando en semanas de retención, no en días, y aplicá políticas de rotación.
- Credenciales débiles y sin cifrado: dejar el reenvío sin TLS o el dashboard con la contraseña por defecto es abrirle la puerta al atacante. Corrección: TLS en el transporte y credenciales fuertes desde el arranque.
¿Cómo validar que tu SIEM está colectando logs bien?
Para validar que tu SIEM colecta correctamente, generá actividad de prueba y verificá que aparezca en el dashboard con el timestamp y los detalles correctos. Primero confirmá que cada agente figura como “activo” o “reportando” en la consola. Después provocá eventos a propósito y buscalos. Sobre eso hablamos en integrar pipelines CI/CD en logs.
¿Cómo generás actividad de prueba? Fácil: hacé un logon fallido a propósito, ejecutá un proceso conocido desde PowerShell, abrí una conexión de red. Cada una de esas acciones debería aparecer en el dashboard en segundos. Si el logon fallido no salta, algo se rompió entre la auditoría de Windows y el colector.
Revisá tres cosas en cada evento de prueba: que el timestamp coincida con cuándo lo hiciste (verificás la sincronización horaria), que aparezca el detalle completo (usuario, proceso, línea de comandos) y que llegue desde el equipo correcto. Si las tres dan bien, el pipeline funciona de punta a punta.
Preguntas Frecuentes
¿Qué es Sysmon y para qué se usa?
Sysmon (System Monitor) es una herramienta gratuita de Microsoft que registra actividad detallada del sistema, como creación de procesos, conexiones de red y actividad de PowerShell, en el registro de eventos de Windows. Se usa junto con un SIEM para tener visibilidad profunda de lo que pasa en cada equipo. En el despliegue documentado se usó la versión 14 con configuración personalizada.
¿Cuál es la mejor herramienta SIEM para principiantes?
Wazuh es la opción más recomendada para principiantes por ser gratuita, de código abierto y venir preconfigurada con agentes, reglas y dashboard. Tiene una comunidad activa y guías en castellano. ELK Stack es una alternativa potente pero con una curva de aprendizaje más pronunciada.
¿Cómo envío logs de Windows a un SIEM?
Instalás un agente (por ejemplo, el de Wazuh) en el equipo Windows y lo apuntás al servidor SIEM, o usás Windows Event Forwarding con suscripciones de eventos. Antes de eso tenés que habilitar la Auditoría Avanzada por Group Policy y, si querés detalle profundo, instalar Sysmon. El agente lee el log local y lo reenvía al colector central.
¿Cuánto tarda desplegar un SIEM por primera vez?
Un despliegue de laboratorio básico se puede armar en una tarde, según relatan varias experiencias con Wazuh. El tiempo real se lo comen los detalles: sincronizar la hora, abrir los puertos correctos, habilitar la auditoría y depurar por qué un evento no llega. Contá con dedicarle un día completo a un primer entorno funcional.
¿Qué logs conviene monitorear con un SIEM?
Los logs prioritarios son los de autenticación (logon exitoso y fallido), creación de procesos con línea de comandos, conexiones de red salientes y actividad de PowerShell. Esos cuatro cubren los vectores de ataque más comunes: fuerza bruta, ejecución de código malicioso y comunicación con servidores de comando y control.
Conclusión
Desplegar SIEM por primera vez no es magia, es una secuencia de pasos en orden: habilitar la auditoría en Windows, instalar Sysmon para el detalle fino, elegir una herramienta manejable (Wazuh es el punto de entrada más amable) y centralizar los logs con la hora sincronizada. El orden importa tanto como las piezas.
La lección que deja la experiencia documentada esta semana es clara: los tropiezos no vienen del SIEM en sí, vienen de los detalles previos (puertos cerrados, auditoría apagada, relojes desincronizados). Si arrancás un laboratorio con tres máquinas, generás actividad de prueba y confirmás que llega al dashboard con timestamp correcto, ya tenés el flujo completo bajo control. A partir de ahí, sumar más fuentes es repetir la receta.
