Introducción a operaciones SIEM: Una guía práctica para el Blue Team

Las plataformas Security Information and Event Management (SIEM) están en el corazón de la mayoría de Security Operations Centers (SOCs). Agregan logs, correlacionan eventos y generan alertas que los analistas deben clasificar e investigar. Esta guía recorre el flujo de trabajo operacional principal para que puedas comenzar a pensar como un analista SIEM, independientemente de qué plataforma (Splunk, Elastic, Microsoft Sentinel, QRadar, etc.) utilice tu organización.

Qué hace realmente un SIEM

En esencia, un SIEM realiza tres funciones: recopilar logs de endpoints, dispositivos de red, aplicaciones y servicios en la nube; normalizar esos datos en un esquema consistente; y correlacionar eventos utilizando reglas de detección para generar alertas. Los analistas luego procesan esas alertas a través de un ciclo de vida de clasificación e investigación. Entender este pipeline te ayuda a diagnosticar problemas cuando los datos se ven incorrectos o faltan alertas.

Configuración de fuentes de logs

Antes de que importe cualquier lógica de detección, necesitas datos confiables. Las fuentes comunes incluyen:

• Telemetría de endpoints (agentes EDR, Windows Event Logs a través de Sysmon)
• Datos de red (logs de firewall, consultas DNS, logs de proxy, NetFlow)
• Logs de autenticación (Active Directory, VPN, proveedores SSO)
• Logs de auditoría en la nube (AWS CloudTrail, Azure Activity Logs, GCP Audit Logs)

Al integrar una nueva fuente, verifica la precisión de las marcas de tiempo, confirma que el análisis de campos sea correcto y comprueba el volumen de ingesta contra las líneas base esperadas. Un analizador mal configurado rompe silenciosamente las detecciones sin lanzar errores, así que verifica regularmente eventos raw contra campos analizados.

Escritura y ajuste de reglas de detección

La mayoría de SIEMs utilizan alguna forma de búsqueda de correlación o sintaxis de regla de detección. Un ejemplo simple en SPL de Splunk podría verse así:

index=auth sourcetype=windows EventCode=4625
| stats count by user, src_ip
| where count > 10

Esto señala cuentas con más de 10 intentos de logon fallidos, un indicador clásico de fuerza bruta. Al construir reglas:

1. Comienza estrecho, luego amplía según la tasa de falsos positivos.
2. Asigna cada regla a una técnica MITRE ATT&CK para contexto y seguimiento de cobertura.
3. Documenta la intención de la regla, la fuente de datos esperada y escenarios conocidos de falsos positivos.
4. Establece umbrales realistas — demasiado sensible y los analistas se ahogan en ruido; demasiado flojo y las amenazas reales se cuelan.

Flujo de trabajo de clasificación de alertas

Una vez que se dispara una alerta, el trabajo del analista es responder: ¿es esto malicioso y requiere escalada? Una lista de verificación de clasificación práctica:

• Valida la alerta — confirma que el evento subyacente realmente ocurrió y no fue un artefacto de análisis.
• Enriquece con contexto — verifica la criticidad del activo, el rol del usuario, la geolocalización de la IP de origen y alertas recientes relacionadas en el mismo host.
• Busca un patrón — pivota sobre el usuario, IP o hash en una ventana de tiempo más amplia para ver si esto es aislado o parte de una campaña más amplia.
• Clasifica — verdadero positivo, falso positivo o verdadero positivo benigno (actividad real, pero no maliciosa, como un script legítimo de un administrador).
• Escalala o ciérrala — documenta tu razonamiento de cualquier forma; las alertas cerradas aún necesitan una justificación clara para propósitos de auditoría.

Construcción de dashboards efectivos

Los dashboards deben responder preguntas operacionales específicas, no solo verse impresionantes. Ejemplos útiles incluyen:

• Principales fuentes de autenticación fallida en las últimas 24 horas
• Volumen de alertas por severidad y asignación de analista
• Salud de la fuente de datos (lag de ingesta, caídas)
• Cobertura de detección asignada a tácticas ATT&CK

Evita la proliferación de dashboards — unos pocos puntos de vista de alta señal superan a veinte paneles raramente revisados.

Manejo de la fatiga de falsos positivos

La fatiga de alertas es uno de los mayores riesgos operacionales en un SOC. Combátela:

• Revisa regularmente alertas cerradas para identificar patrones recurrentes de falsos positivos.
• Suprime actividad conocida como benigna con excepciones documentadas (no deshabilitación de reglas indiscriminada).
• Rastrea el tiempo medio para clasificar y el tiempo medio para responder como métricas para detectar cuellos de botella.
• Rota ciclos de revisión de reglas de detección para que reglas antiguas y ruidosas se refinen o se retiren.

Documentación y entrega

Cada investigación debe dejar un rastro de papel: qué disparó la alerta, qué fue verificado, a qué conclusión se llegó y cualquier acción de seguimiento. Esto importa para entregas de turno, auditorías de cumplimiento y construcción del conocimiento institucional que sobrevive a la rotación de analistas. Una simple plantilla de runbook por tipo de alerta — pasos de investigación, contactos de escalada y evidencia esperada — ahorra tiempo significativo bajo presión.

Práctica práctica

La forma más rápida de construir fluidez en SIEM es la repetición: ingesta de logs de ejemplo, escritura de un puñado de reglas de detección contra técnicas de ataque conocidas y práctica del ciclo completo de clasificación de principio a fin. Conjuntos de datos libres y stacks SIEM de código abierto (como el Elastic Stack) son excelentes entornos de bajo costo para esto.

¿Listo para profundizar más en los fundamentos del blue team? Explora segmentos relacionados de Korra Studio sobre análisis de logs, flujos de trabajo de respuesta a incidentes e ingeniería de detección para continuar desarrollando tu conjunto de habilidades de SOC.