Elegir un SIEM suele empezar con una planilla de funcionalidades y terminar con una factura de licencias que nadie anticipó. La pregunta correcta no es "qué SIEM tiene más recursos", sino qué amenazas necesito detectar, con qué datos y quién va a actuar cuando salte la alerta.
Qué hace un SIEM y qué no hace
Un SIEM (Security Information and Event Management) recopila eventos de múltiples fuentes, normaliza los datos, conserva el histórico y aplica reglas de correlación para generar alertas. El NIST aborda la base de este trabajo en la SP 800-92, Guide to Computer Security Log Management, y en su revisión en borrador, la Cybersecurity Log Management Planning Guide (SP 800-92 Rev. 1, de 2023), que define la gestión de logs como el proceso de generar, transmitir, almacenar, acceder y eliminar datos de log.
Lo que el SIEM no hace por sí solo: decidir qué logs importan, escribir y ajustar las reglas para tu entorno, investigar una alerta y contener un ataque. Esas partes dependen de personas y de procesos.
Antes de comparar productos: define qué quieres detectar
La guía Best Practices for Event Logging and Threat Detection, publicada en agosto de 2024 por la agencia australiana ASD's ACSC junto con CISA, FBI, NSA y socios de otros países, organiza el tema en cuatro puntos: una política de logging aprobada por la organización, recolección y correlación centralizadas, almacenamiento seguro con integridad de los logs y una estrategia de detección enfocada en las amenazas relevantes.
En la práctica, eso significa listar los activos críticos, los escenarios de ataque que más preocupan (ransomware, robo de credenciales, fraude, fuga de datos) y las fuentes que muestran cada uno. Esa lista se convierte en el criterio de evaluación.
Los criterios que realmente pesan
- Fuentes y parsers. Verifica que existan conectores y parsers mantenidos para lo que usas: firewall, EDR, Active Directory y proveedor de identidad, nube (IaaS y SaaS), correo, VPN, bases de datos y aplicaciones propias. Un log que llega sin interpretarse correctamente no sirve para correlacionar.
- Modelo de licenciamiento. Los modelos más comunes cobran por volumen ingerido (GB por día), por eventos por segundo (EPS), por activo o por usuario. Cada uno tiene efectos: el cobro por volumen desalienta enviar logs útiles pero verbosos; el cobro por EPS penaliza los picos. Simula el costo con el volumen real y el crecimiento esperado, no con la estimación del vendedor.
- Retención y costo de almacenamiento. Separa la retención "caliente", consultable al instante, de la retención a largo plazo, más barata y más lenta. Las investigaciones suelen necesitar mirar meses atrás, porque el atacante puede llevar bastante tiempo en el entorno antes de ser detectado.
- Contenido de detección mapeado a MITRE ATT&CK. Las reglas predefinidas ayudan, pero lo que importa es la cobertura documentada: qué técnicas de ATT&CK tienen detección, con qué fuentes y con qué facilidad puedes crear y probar reglas propias.
- UEBA. El análisis de comportamiento de usuarios y entidades ayuda a encontrar el uso indebido de credenciales válidas, que las reglas estáticas no detectan, pero requiere línea base y ajuste.
- Integración con SOAR. Evalúa si el SIEM activa playbooks de enriquecimiento y respuesta (aislar un host, bloquear una cuenta, abrir un ticket) de forma nativa o mediante integración, y con qué control de aprobación.
- Nube u on-premises. Un SIEM en la nube reduce el trabajo de infraestructura y escala con más facilidad; el on-premises puede ser exigido por requisitos de residencia de datos o por política interna, pero implica el costo de hardware, actualizaciones y alta disponibilidad.
- Cumplimiento y retención legal. Mapea las exigencias que te aplican. En Brasil, por ejemplo, el Marco Civil de Internet (Ley 12.965/2014) obliga a los proveedores de conexión a guardar los registros de conexión durante un año y a los proveedores de aplicaciones a guardar los registros de acceso durante seis meses. Los sectores regulados, como el financiero, tienen reglas propias. El SIEM debe garantizar integridad y control de acceso sobre esos registros.
Cómo llevar a cabo una prueba de concepto útil
Una prueba de concepto (PoC) solo vale si usa tu entorno. Un guion breve:
- Elige de tres a cinco escenarios de ataque vinculados a los riesgos que listaste, por ejemplo, fuerza bruta seguida de un inicio de sesión exitoso, creación de una cuenta administrativa fuera de lo normal y movimiento lateral.
- Conecta las fuentes reales que sustentan esos escenarios y mide el esfuerzo de integración y de parsing.
- Simula las técnicas de forma controlada y observa si la alerta aparece, con qué contexto y en cuánto tiempo.
- Mide el ruido. Cuántas alertas por día genera el entorno y cuántas merecen investigación.
- Proyecta el costo a tres años con volumen, retención y crecimiento reales, incluyendo almacenamiento y horas del equipo.
En mayo de 2025, CISA y ASD's ACSC publicaron, junto con socios, orientaciones específicas para quienes van a contratar SIEM y SOAR, con versiones para ejecutivos y para equipos técnicos, además de una guía de priorización de logs para la ingesta en el SIEM.
Errores comunes
- Ingerir todo "por si acaso". Aumenta el costo y el ruido sin mejorar la detección. Empieza por las fuentes prioritarias y amplía con criterio.
- Ingerir poco para ahorrar. Lo opuesto también falla: sin logs de identidad, endpoint y nube, el SIEM no ve las etapas más comunes de un ataque.
- Activar las reglas de fábrica y olvidarlas. Sin ajuste al entorno, los falsos positivos se acumulan y el equipo empieza a ignorar las alertas.
- No definir quién responde. Una alerta sin dueño, fuera del horario laboral, es una alerta perdida.
Por qué el SIEM solo no basta
La detección ocurre en tres capas: datos, análisis y acción. El SIEM resuelve bien la primera y parte de la segunda. El resto depende de:
- Personas. Analistas que hacen el triaje, investigan, buscan amenazas que aún no generaron alertas (threat hunting) y ajustan las reglas tras cada falso positivo.
- Procesos. Criterios de severidad, playbooks, escalamiento e integración con el plan de respuesta a incidentes, alineados con la NIST SP 800-61 Rev. 3.
- Cobertura continua. Los ataques no respetan horarios. Un evento crítico de madrugada un sábado necesita a alguien mirando en ese momento.
Cómo XDR, Open XDR y un SOC 24×7 completan el cuadro
El XDR (Extended Detection and Response) se enfoca en detección y respuesta accionables: correlaciona señales de endpoint, red, nube, identidad y correo, agrupa los eventos en incidentes con contexto y dispara acciones de contención. El Open XDR lo hace de forma abierta, integrando las herramientas que la empresa ya tiene, incluido el propio SIEM, sin atar la operación a un único fabricante.
En Network Secure, la plataforma Open-XDR es el núcleo que conecta los servicios: ingiere telemetría de múltiples fuentes, usa inteligencia artificial para correlacionar señales y reconstruir la línea de tiempo de un ataque y activa la respuesta mediante playbooks, con el SOC operando 24×7 y validación humana cuando es necesario. El SOC de Network Secure cuenta con la certificación ISO/IEC 27001:2022. Para entender qué esperar de esa operación, lee SOC tradicional vs. SOC moderno y el servicio de SOC y MDR.
Preguntas frecuentes
¿Cuál es la diferencia entre SIEM y XDR?
El SIEM centraliza logs y los correlaciona mediante reglas, con un papel fuerte en retención y cumplimiento. El XDR se enfoca en detección y respuesta, con correlación entre capas y acciones automatizadas. Ambos pueden convivir, y el XDR puede consumir datos del SIEM.
¿Cómo estimar el costo de un SIEM?
Mide el volumen real de eventos de las fuentes prioritarias durante algunas semanas, aplica el modelo de licenciamiento de cada proveedor, suma la retención exigida y el crecimiento esperado e incluye las horas del equipo para operar la plataforma.
¿Qué logs priorizar primero?
En general, identidad y autenticación, endpoint (EDR), firewall y VPN, servicios en la nube y correo, porque cubren las etapas más comunes de un ataque.
Fuentes consultadas: NIST SP 800-92, Guide to Computer Security Log Management (2006), y NIST SP 800-92 Rev. 1 (borrador), Cybersecurity Log Management Planning Guide (2023); ASD's ACSC, CISA, FBI, NSA y socios, Best Practices for Event Logging and Threat Detection (agosto de 2024); CISA, ASD's ACSC y socios, Implementing SIEM and SOAR Platforms y Priority Logs for SIEM Ingestion (mayo de 2025); MITRE ATT&CK; NIST SP 800-61 Rev. 3; Ley brasileña 12.965/2014 (Marco Civil de Internet), arts. 13 y 15. Este artículo es educativo; los criterios sugeridos no sustituyen una evaluación técnica de tu entorno ni asesoramiento jurídico sobre retención de datos.