Microsoft User Group Perú

SOC Hands-On Workshop · Sesión 02
Detección & MITRE ATT&CK
MITRE ATT&CK aparece en casi todas las conversaciones de ciberseguridad. Poca gente lo usa operativamente. Esta sesión cambia eso.
── Lo que harás ──
Empezarás navegando la matriz MITRE directamente en Sentinel para ver qué tácticas cubre el Training Lab con sus 22 reglas activas — y cuáles quedan sin detección. Ese ejercicio tiene una respuesta incómoda: los gaps son más grandes de lo que parece. Identificarlos es el primer paso para priorizar qué construir después.
El segundo ejercicio es automation rules: una regla que clasifica, asigna y etiqueta incidentes de alta severidad automáticamente, sin intervención manual. Cuando detecta táctica de Credential Access con severidad Alta, asigna propietario, agrega el tag Priority-1 y cambia el estado — todo sin Logic Apps ni código.
El tercero es cross-platform: CrowdStrike detecta malware en un endpoint → Sentinel recibe la alerta y evalúa condiciones → Microsoft Defender for Endpoint aísla el dispositivo en segundos. Este ejercicio muestra en vivo lo que significa "orquestación" cuando el tiempo importa.

── Lo que te llevas ──
→ Mapa de cobertura MITRE real de tu workspace — con los gaps identificados
→ Automation rule activa que clasifica incidentes de Credential Access sin intervención manual
→ Pipeline cross-platform: detección en CrowdStrike → aislamiento en MDE
→ Perspectiva de campo de alguien que opera Sentinel en producción
── Prerequisitos ──
→ Haber completado S01 o tener el Training Lab desplegado
→ Para el Ejercicio 05: dispositivo ya onboarded en Microsoft Defender for Endpoint

SOC Hands-On Workshop · Sesión 03
Detection Engineering
Una regla que dispara 200 alertas al día no es una detección — es ruido. Esta sesión trata sobre la diferencia.
── Lo que harás ──
El primer ejercicio toma la regla de port scan del Training Lab — que con su umbral por defecto genera decenas de falsas alertas al día — y la afina: se excluyen IPs de confianza vía watchlist, se cambia el métrico de conteo total de eventos a puertos únicos escaneados, y se amplia la ventana de análisis para capturar al atacante que escanea despacio. Resultado: de docenas de alertas a 3–5 de alta fidelidad sobre el mismo tráfico.
El segundo ejercicio construye desde cero una regla para detectar MFA abuse en los logs de Okta del Training Lab. El patrón: múltiples fallos de autenticación MFA por el mismo usuario en una ventana corta — la señal de MFA fatigue attack o credential stuffing. Aprenderás a diseñar la hipótesis antes de escribir la query.
El tercer ejercicio introduce watchlists como mecanismo de enriquecimiento: creas una lista de usuarios de alto privilegio y modificas una regla para que las alertas sobre esos usuarios se generen con severidad Alta, sin importar el umbral original. La misma detección, con contexto de negocio integrado.
Un invitado con experiencia en detección compartirá cuántas reglas maneja en producción, cómo decide cuál afinar primero y cómo manejar identidades comprometidas con credenciales válidas — el escenario más difícil de detectar.
── Lo que te llevas ──
→ Regla de port scan afinada: de ruido a alta fidelidad
→ Regla de MFA abuse construida desde cero sobre comportamiento real
→ Watchlist de usuarios VIP activa como contexto de detección
→ El mindset de Detection Engineering: cuándo una alerta es un problema del atacante y cuándo es un problema de la regla

SOC Hands-On Workshop · Sesión 04
Operations + Data Lake
Hay algo que nadie te dice cuando empiezas con Sentinel: la factura puede subir sin que nadie lo decida conscientemente. Esta sesión es sobre entender por qué y cómo controlarlo sin perder visibilidad.
── Lo que harás ──
El primer ejercicio usa KQL sobre la tabla Usage del workspace para ver qué tablas consumen más GB de ingesta, cuánto representan en costo estimado y cuáles deberían estar en un tier más barato. Es la consulta que deberías ejecutar en cualquier workspace de producción antes de que llegue la primera factura sorpresa.
El segundo ejercicio mueve los logs de firewall de Palo Alto de Analytics tier (el más caro) a Basic tier: menos costo de ingesta, retención configurada, y los datos siguen accesibles vía search job. El ahorro estimado en ese ejercicio solo es del 80% para esa tabla.
El tercer ejercicio es el más revelador: lanzar un search job sobre 90 días de logs históricos en el Data Lake para encontrar el patrón de movimiento lateral del atacante — conexiones desde la IP comprometida hacia múltiples destinos internos que ocurrieron semanas antes del incidente visible. El atacante que ninguna regla de ventana de 10 minutos puede detectar.
El cuarto ejercicio configura una summary rule que agrega el tráfico de Palo Alto por hora antes de que llegue a la tabla de destino. Misma señal de detección. El costo de ingesta del firewall baja un 99% sin tocar ninguna regla existente.
Un invitado que opera Sentinel en producción hablará de la primera factura que no esperaba, qué tabla fue la más cara y cómo convenció al CFO de que Sentinel vale lo que cuesta.
── Lo que te llevas ──
→ Diagnóstico de costos del workspace con KQL
→ Table tier configurado y ahorro validado
→ Primer search job sobre datos históricos ejecutado
→ Summary rule activa que reduce ingesta sin perder detección
── Prerequisitos ──
→ Haber completado S01, S02 y S03
→ KQL intermedio (summarize, join, where con condiciones múltiples)

SOC Hands-On Workshop · Sesión 05 · SESIÓN FINAL
Advanced: AI + MCP + Federation
El analista que sepa instruir a un agente IA para investigar incidentes en Sentinel tendrá una ventaja operativa que los manuales de 2024 todavía no contemplan. Esta sesión es sobre construir esa ventaja.
── Lo que harás ──
El primer ejercicio abre un Jupyter Notebook en Azure Machine Learning conectado al workspace de Sentinel y ejecuta un análisis de comportamiento de usuarios sobre los logs de Okta del Training Lab usando Python y MSTICPy — la librería oficial de Microsoft para análisis de seguridad en notebooks.
El segundo ejercicio conecta VS Code con el Sentinel MCP Server — disponible desde noviembre de 2025 — y ejecuta las primeras investigaciones en lenguaje natural: “encuéntra los 3 usuarios con mayor riesgo y explica por qué”, “identifica dispositivos con un número anormal de conexiones salientes”, “ïrealiza una investigación completa del usuario victim@contoso.com y dame un veredicto”. El agente consulta el Data Lake, razona sobre los datos y entrega un veredicto estructurado — sin escribir una sola línea de KQL.
El tercer ejercicio configura federación con ADLS Gen2: una tabla externa que apunta a un storage account y que puedes consultar con KQL exactamente igual que cualquier tabla propia de Sentinel, sin ingestar ni un byte. La respuesta correcta para logs legacy, SIEMs anteriores o fuentes de datos demasiado costosas de mover.
El cuarto ejercicio configura una split transformation que en tiempo de ingesta enruta los logs de CrowdStrike automáticamente: eventos de alta severidad a Analytics tier para detección en tiempo real, el resto a Basic tier para reducir costos.
Un invitado con experiencia directa en IA aplicada a operaciones de seguridad cerrará la sesión con una conversación sobre lo que ya está pasando en el campo, los límites reales de la automatización y qué skill recomienda para el analista de 2026.
La sesión termina con una reflexión sobre el recorrido completo: de desplegar el lab en S01 hasta orquestar agentes IA sobre él en S05 — 10 horas, 16 ejercicios, un stack completo de operaciones SOC.
── Lo que te llevas ──
→ Jupyter Notebook conectado a Sentinel y primera consulta Python sobre datos reales
→ Sentinel MCP Server configurado y primeras investigaciones en lenguaje natural
→ Tabla federada ADLS Gen2 operativa en tu workspace
→ Split transformation activa que enruta datos por severidad en tiempo de ingesta
→ El recorrido completo del workshop: 16 ejercicios, stack completo
── Prerequisito ──
→ Haber completado S01–S04
→ Setup de VS Code + GitHub Copilot antes de la sesión (guía enviada 24h antes)