Modulo 01. Mision y modelo operativo de un SOC

Objetivo del modulo

Comprender que hace realmente un SOC, que funciones necesita, como se estructura operativamente y como se relaciona con el resto de la organizacion para convertir senales en decisiones defensivas.

Resultados esperados

• Distinguir vigilancia, deteccion, respuesta y mejora continua dentro del SOC.
• Explicar diferencias funcionales entre SOC, CSIRT e ingenieria de seguridad.
• Identificar dependencias criticas del modelo operativo y sus puntos de fallo.
• Disenar un modelo basico de SOC con niveles, escalados y coordinacion.

Desarrollo teorico

Un SOC (Security Operations Center) existe para reducir el tiempo entre una actividad maliciosa y la decision defensiva adecuada. Esa decision puede ser investigar, descartar un falso positivo, escalar, contener un compromiso activo o endurecer un control preventivo. Por eso un SOC no es simplemente una pantalla con alertas ni un equipo que "mira logs". Es una capacidad operativa que combina personas con distintos niveles de experiencia, telemetria de multiples fuentes, procesos documentados, herramientas de deteccion y respuesta, y coordinacion estrecha con otros equipos de la organizacion.

La estructura mas comun de un SOC sigue un modelo de niveles (tiers). El Tier 1 o analista de triage recibe las alertas, realiza una primera evaluacion, descarta falsos positivos y escala las alertas que requieren investigacion mas profunda. El Tier 2 o analista de investigacion profundiza en las alertas escaladas, correlaciona eventos, busca indicadores adicionales y determina si existe un incidente real que requiera respuesta. El Tier 3 incluye analistas senior, threat hunters e ingenieros de deteccion que realizan investigaciones complejas, crean nuevas reglas de deteccion, realizan hunting proactivo y participan en la respuesta a incidentes graves. No todas las organizaciones necesitan los tres niveles de forma permanente, pero el concepto de escalado progresivo es fundamental.

En la practica, un SOC convive con otras funciones que deben estar claramente delimitadas. El CSIRT o IR team (Incident Response) lidera incidentes graves: coordinacion de contencion, erradicacion, recuperacion y analisis forense. Los administradores de sistemas, red o cloud aplican los cambios de contencion que el SOC o IR solicitan (aislar un endpoint, revocar credenciales, bloquear un IP en el firewall). La ingenieria de seguridad construye y mantiene la infraestructura de deteccion: conectores de logs, parsers, reglas de correlacion, dashboards y pipelines de datos. El equipo de gobierno de seguridad define prioridades, requisitos normativos y reporting ejecutivo. Cuando estas fronteras no estan claras, el SOC se atasca: investiga alertas sin capacidad para ejecutar contencion, recibe presion para resolver problemas que pertenecen a otra area o pierde tiempo en tareas de ingenieria que deberian hacerse fuera del flujo operativo.

Las herramientas centrales de un SOC incluyen el SIEM (Security Information and Event Management), que recolecta, normaliza y correlaciona logs de multiples fuentes; el SOAR (Security Orchestration, Automation and Response), que automatiza tareas repetitivas como enriquecimiento de alertas, consultas a threat intelligence y acciones de contencion basicas; y los EDR/XDR (Endpoint/Extended Detection and Response), que proporcionan visibilidad y capacidad de respuesta en endpoints, red, email y cloud. Estas herramientas no funcionan solas; necesitan afinamiento continuo, reglas actualizadas y analistas que interpreten lo que producen. Un SIEM con miles de reglas genéricas sin ajustar genera ruido que satura al equipo; un SOAR sin playbooks bien disenados automatiza sin criterio; un EDR sin politicas de deteccion afinadas pierde ataques reales entre falsos positivos.

La cobertura de logs y telemetria determina que puede ver y que no puede ver el SOC. Las fuentes criticas incluyen: logs de autenticacion (Active Directory, Entra ID, RADIUS), logs de endpoint (EDR, antivirus, Sysmon), logs de red (firewall, proxy, DNS, NetFlow), logs de correo (gateway, M365 Defender), logs de cloud (CloudTrail, Activity Log, Cloud Audit Logs) y logs de aplicaciones criticas. Si una fuente no esta integrada, las detecciones basadas en ella no funcionaran. El ejercicio de mapear fuentes de telemetria contra la matriz MITRE ATT&CK revela brechas de visibilidad: tacticas o tecnicas que no podrias detectar porque no recoges los datos necesarios.

Las metricas operativas del SOC sirven para medir eficacia, no solo volumen. Las mas relevantes incluyen: MTTD (Mean Time to Detect, tiempo medio desde que ocurre la actividad maliciosa hasta que se detecta), MTTR (Mean Time to Respond, tiempo medio desde la deteccion hasta la contencion o resolucion), tasa de falsos positivos (porcentaje de alertas que resultan no ser incidentes reales), cobertura de deteccion (porcentaje de tecnicas ATT&CK cubiertas por al menos una regla), y tasa de escalado (porcentaje de alertas que T1 escala a T2). Un SOC que cierra muchas alertas como "no aplica" puede estar sufriendo exceso de ruido. Un SOC con MTTD bajo pero MTTR alto puede tener problemas de coordinacion con los equipos que ejecutan contencion.

Los turnos y la cobertura horaria son otra dimension critica. Un SOC 24x7 requiere al menos tres turnos con analistas suficientes en cada uno, rotacion sostenible y procedimientos de handoff (traspaso entre turnos) que eviten que alertas se pierdan en las transiciones. Un SOC con cobertura 8x5 necesita saber que ocurre fuera de horario: puede depender de un MSSP (Managed Security Services Provider), de automatizaciones SOAR que contengan amenazas basicas sin intervencion humana, o de guardias de emergencia. La decision depende de la tolerancia al riesgo y el presupuesto de la organizacion.

El concepto de mejora continua es lo que diferencia un SOC reactivo de un SOC maduro. Cada incidente resuelto deberia generar lecciones aprendidas que alimenten nuevas detecciones, mejoras de procesos, recomendaciones de hardening o ajustes de telemetria. Los ejercicios de purple team (simulacion de ataques donde red team y blue team colaboran) permiten validar detecciones en un entorno controlado. Los informes post-incidente (PIR) documentan que funciono, que fallo y que se mejora. Sin este ciclo de retroalimentacion, el SOC repite los mismos errores indefinidamente.

Contenido ampliado

Puntos clave

• El SOC transforma senales en decisiones defensivas; su valor no es cerrar alertas sino reducir riesgo real.
• Necesita limites claros con IR, ingenieria de deteccion y operacion de TI para no atascarse.
• La cobertura de logs determina que puede y que no puede detectar el SOC.
• MTTD y MTTR son metricas mas utiles que el volumen bruto de alertas cerradas.
• La coordinacion entre equipos importa tanto como la calidad de las herramientas.
• La mejora continua (PIR, purple team, ajuste de detecciones) separa SOCs reactivos de SOCs maduros.

Checklist operativa

• Definir que casos escala el SOC y a quien (IR, administradores, gestion).
• Aclarar ownership de detecciones: quien crea, revisa y mantiene las reglas.
• Establecer canales de comunicacion para respuesta y guardias fuera de horario.
• Mapear fuentes de telemetria contra tacticas MITRE ATT&CK para identificar brechas.
• Definir metricas operativas: MTTD, MTTR, falsos positivos, cobertura de deteccion.
• Disenar procedimiento de handoff entre turnos.
• Programar revisiones post-incidente y ejercicios de purple team.

Errores frecuentes

• Medir al SOC solo por volumen de alertas cerradas en vez de por calidad de deteccion y respuesta.
• No tener criterios claros de severidad y escalado, dejando al analista de T1 decidir sin guia.
• Esperar que un analista T1 resuelva solo cambios de infraestructura que requieren acceso de administrador.
• Implementar SIEM sin afinar reglas, generando miles de alertas irrelevantes que saturan al equipo.
• No invertir en ingenieria de deteccion, esperando que las reglas out-of-the-box sean suficientes.
• Ignorar la fatiga de alertas como problema real que degrada rendimiento y retiene talento.

Practica sugerida

Disena un modelo operativo completo para un SOC interno de una organizacion de 2000 empleados con los siguientes requisitos: (1) cobertura 24x7 con tres turnos, (2) equipo IR diurno de dos personas, (3) administradores de guardia para contencion fuera de horario. Define: estructura de tiers, fuentes de telemetria principales (al menos seis), herramientas (SIEM, EDR, SOAR), criterios de escalado (T1 a T2, T2 a IR), metricas operativas (al menos cuatro) y procedimiento de handoff entre turnos.

Preguntas de autoevaluacion

• ¿Que diferencia funcional hay entre SOC, CSIRT e ingenieria de deteccion?
• ¿Por que la cobertura de logs es tan importante como la calidad de las reglas de deteccion?
• ¿Que metricas usarias para evaluar si un SOC esta funcionando bien?
• ¿Que falla cuando no existe ownership claro de las reglas de deteccion?
• ¿Cual es el riesgo de medir el SOC unicamente por volumen de alertas cerradas?

Cierre

El SOC aporta valor cuando sabe que senales perseguir, con que prioridad, con que herramientas y con que apoyo operativo cuenta para transformar analisis en defensa real. Sin limites claros, metricas relevantes y mejora continua, un SOC es un equipo caro que consume alertas sin reducir riesgo.

Modulo 02. Fuentes de logs y telemetria

Objetivo del modulo

Seleccionar y priorizar fuentes de visibilidad que sostengan casos de uso útiles para el SOC.

Resultados esperados

• Identificar qué logs aportan más valor defensivo.
• Entender calidad, contexto y limitaciones de cada fuente.
• Relacionar telemetría con cobertura ATT&CK y con casos de uso.

Desarrollo teorico

No todas las fuentes de logs valen lo mismo. Un SOC puede ingestarlo todo y seguir ciego si no recibe los eventos adecuados o si llegan sin contexto, sin normalizacion o con demasiada latencia. Las fuentes basicas suelen agruparse en identidad, endpoint, red, correo, cloud, aplicaciones y controles defensivos. Lo importante no es la lista, sino la relacion entre fuente y pregunta defensiva. Si quieres detectar password spray (T1110.003 en MITRE ATT&CK), necesitas logs de autenticacion con errores de login, IPs de origen y correlacion temporal. Si quieres detectar persistencia en endpoint (T1053 Scheduled Task, T1547 Boot or Logon Autostart), necesitas telemetria de procesos, servicios, tareas programadas y cambios en el registro. Si quieres detectar exfiltracion desde SaaS, necesitas auditoria de archivos, sharing y actividad de usuario.

La telemetria de identidad es frecuentemente la fuente mas valiosa para un SOC. En entornos Microsoft, los logs de Entra ID (sign-in logs, audit logs, risky sign-ins) y Active Directory (Event IDs 4624, 4625, 4768, 4769, 4776) proporcionan visibilidad sobre autenticaciones exitosas y fallidas, cambios de privilegios, creacion de cuentas y modificaciones de grupos. Estos eventos son la base de detecciones criticas como password spray (multiples fallos de login desde la misma IP contra distintas cuentas en ventana corta), brute force (multiples fallos contra la misma cuenta), uso de cuentas comprometidas (login exitoso desde ubicacion anomala tras multiples fallos de MFA), y escalada de privilegios (adicion de un usuario a Domain Admins o Global Admin). En M365 Defender, los sign-in logs se integran con Identity Protection para generar señales de riesgo que el SOC puede consumir como alertas o como datos de enriquecimiento.

La telemetria de endpoint proviene principalmente de soluciones EDR (Endpoint Detection and Response) como Microsoft Defender for Endpoint, CrowdStrike Falcon, SentinelOne o Carbon Black, y de agentes de telemetria adicional como Sysmon en Windows. Un EDR bien configurado proporciona arboles de procesos (que proceso padre lanzo que proceso hijo), conexiones de red por proceso, carga de DLLs, modificaciones de ficheros, escritura en registro y ejecucion de scripts. Sysmon (Event IDs 1, 3, 7, 8, 10, 11, 13, 22) complementa la visibilidad con eventos granulares de creacion de procesos, conexiones de red, carga de imagenes y acceso a procesos (critico para detectar volcado de credenciales como Mimikatz accediendo a lsass.exe). Sin esta telemetria, la deteccion de tecnicas como T1003 OS Credential Dumping, T1059 Command and Scripting Interpreter o T1055 Process Injection queda fuera del alcance del SOC.

La telemetria de red incluye logs de firewall (trafico permitido y denegado, puertos, IPs), proxy web (URLs visitadas, categorias, user agents, dominios bloqueados), DNS (resoluciones, dominios consultados, deteccion de DGA o tunneling DNS) y NetFlow o trafico de red para analisis volumetrico. Los logs de correo (gateway de correo, M365 Defender for Office 365) proporcionan visibilidad sobre phishing entrante, adjuntos maliciosos, URLs en correos y reglas de forwarding sospechosas. Los logs de cloud (CloudTrail en AWS, Activity Log en Azure, Cloud Audit Logs en GCP) cubren operaciones de control plane: creacion y eliminacion de recursos, cambios de IAM, modificaciones de configuracion de seguridad y accesos a datos sensibles.

El ejercicio mas valioso que puede hacer un SOC es mapear sus fuentes de telemetria contra la matriz MITRE ATT&CK para identificar brechas de visibilidad. Para cada tactica (Reconnaissance, Initial Access, Execution, Persistence, Privilege Escalation, Defense Evasion, Credential Access, Discovery, Lateral Movement, Collection, Exfiltration, Command and Control, Impact), el equipo debe preguntarse: ¿tenemos los logs necesarios para detectar al menos las tecnicas mas comunes de esta tactica? ¿Los logs llegan con la latencia adecuada? ¿Los parsers extraen los campos relevantes? Las brechas descubiertas alimentan el backlog de ingenieria de deteccion y ayudan a priorizar inversiones en nuevas fuentes o mejoras de las existentes.

La calidad de la telemetria depende de factores que muchas veces se descuidan: latencia (un log que llega con 30 minutos de retraso puede hacer inutil una deteccion en tiempo real), retencion (si los logs se borran a los 7 dias, las investigaciones de incidentes historicos quedan imposibilitadas), normalizacion (campos como usuario, IP de origen o timestamp deben mapearse a un esquema comun para que las reglas SIEM funcionen entre fuentes distintas), y completitud (un log de autenticacion que no incluye IP de origen o user agent pierde gran parte de su valor analitico). Los analistas de SOC Tier 1 deben conocer las fuentes principales y sus limitaciones para interpretar correctamente las alertas que reciben.

Contenido ampliado

Puntos clave

• Más logs no equivalen a mejor detección.
• La calidad y el contexto pesan más que el volumen bruto.
• Cada caso de uso debería apoyarse en fuentes concretas y conocidas.

Checklist operativa

• Inventariar fuentes disponibles y su retención.
• Mapear cada una a casos de uso existentes.
• Revisar lag, parsers y campos críticos.
• Detectar puntos ciegos de identidad, endpoint o cloud.

Errores frecuentes

• Ingestar por inercia sin saber para qué sirve una fuente.
• No validar si un parser rompe campos relevantes.
• Confiar en que el SIEM “ya correlacionará” sin diseño previo.

Practica sugerida

Construye una tabla de telemetría mínima para detectar phishing con robo de credenciales y malware en endpoint.

Preguntas de autoevaluacion

• ¿Qué log echarías más de menos para detectar password spray?
• ¿Qué diferencia hay entre cantidad y calidad de telemetría?
• ¿Qué harías si una fuente crítica llega con retraso constante?

Cierre

La telemetría es el sistema nervioso del SOC. Si falta o llega mal, la detección se convierte en intuición y ruido.