Cybersecurity

SOC & Blue Team

Advanced 8 modules • 24 hours •69 € VAT included

Curso orientado a diseñar y operar capacidades defensivas reales de SOC y Blue Team. El foco está en telemetría, SIEM, casos de uso, triage, investigación, respuesta coordinada, threat hunting y mejora continua basada en métricas y cobertura.

Un SOC maduro no vive de acumular alertas, sino de convertir señales en decisiones: qué investigar, qué contener, qué endurecer y qué nuevas detecciones desplegar. El curso explica cómo se conectan fuentes de logs, lógica de detección, analistas, ingeniería y respuesta en una capacidad defensiva que aprende del adversario y del propio entorno.

The first module is free. Request information about full-course access.

Please note: the course material (modules, exam, glossary and labs) is written in Spanish. Only the site interface is available in English. A good reading level of Spanish is required.

On sale soon. The first module is free: sign up and start.

hola@itlabcert.com

Request received. We will reply to your email within 48 working hours. No need to send it again.

For myself For my company or team

I have read and accept the privacy policy. We will only use your data to reply to you.

hola@itlabcert.com

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

Funcion	Responsabilidad principal	Herramienta tipica
SOC Tier 1	Triage, descarte de falsos positivos, escalado	SIEM, consola EDR
SOC Tier 2	Investigacion profunda, correlacion, determinacion de incidente	SIEM, SOAR, sandbox
SOC Tier 3 / Hunting	Hunting proactivo, creacion de detecciones, investigaciones complejas	ATT&CK, logs raw, threat intel
IR/CSIRT	Coordinacion de incidentes graves, contencion, erradicacion	Forense, playbooks IR
Ingenieria de deteccion	Construir y mantener reglas, parsers, pipelines	SIEM, repositorio de detecciones
Equipos IT	Aplicar cambios en endpoints, red, identidad o cloud	Consolas de gestion, firewalls

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.

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

What you will learn

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.

Module contents

Desarrollo teorico
Contenido ampliado
Puntos clave
Checklist operativa
Errores frecuentes
Practica sugerida
Preguntas de autoevaluacion
Cierre