Microsoft AZ-500: Microsoft Sentinel y operaciones de seguridad — Guía de estudio

By Laurynas Brazys · 11 August 2026 · #microsoft #az-500 #certification #exam-prep #study-guide

Forma parte de la Microsoft Azure Security Engineer Associate AZ-500 — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de Microsoft, o realiza tests cronometrados en ExamRoll.io.

Información general

Microsoft Sentinel es la plataforma SIEM y SOAR nativa de la nube de Azure, construida sobre Azure Monitor Log Analytics. Centraliza la telemetría de seguridad, aplica análisis para detectar amenazas, genera incidentes para el triaje de los analistas y orquesta respuestas automatizadas con Logic Apps. La eficacia de las operaciones depende de una arquitectura de áreas de trabajo bien diseñada, una incorporación de datos deliberada, una retención consciente de los costos, un análisis y mapeo de entidades precisos, y un régimen de automatización y ajuste que alinee las alertas con los flujos de trabajo del SOC y el riesgo empresarial.

Arquitectura y gestión de datos de Sentinel

• Áreas de trabajo y consideraciones multiinquilino

  • Sentinel se ejecuta por cada área de trabajo de Log Analytics. Elija los límites del área de trabajo en función de la soberanía de los datos, la latencia y el aislamiento administrativo. Un área de trabajo única de “SOC central” simplifica la correlación y la gestión de contenido; múltiples áreas de trabajo pueden ser apropiadas para modelos con requisitos estrictos de residencia, autonomía o MSSP/Lighthouse. Se admiten las consultas entre áreas de trabajo, pero añaden latencia y costo a la consulta; prefiera la consolidación cuando la correlación entre entidades sea crítica.
  • Use RBAC de contexto de recurso en el área de trabajo para separar funciones: Sentinel Reader para los paneles, Responder para la gestión de incidentes, Contributor para la gestión de contenido y Automation Contributor para los playbooks.

• Rutas de ingesta

  • Los datos ingresan a las tablas del área de trabajo a través de conectores nativos, agentes de Azure Monitor o API. Prefiera los conectores nativos para las fuentes de Microsoft (esquema optimizado, fiabilidad) y AMA+DCR para Windows/Syslog para obtener control sobre el filtrado y los planes por tabla. Para dispositivos de terceros, enrute CEF sobre Syslog a la tabla CommonSecurityLog para beneficiarse de los analizadores y el contenido de análisis integrados.

• Retención, archivo y búsqueda

  • Configure la retención por tabla para mantener los datos calientes (análisis interactivo) durante la ventana de detección operativa (comúnmente de 30 a 120 días). Archive los datos más antiguos en el nivel de archivo de Log Analytics (Archive tier) por hasta 7 años para cumplir con la normativa a un costo drásticamente menor; use Trabajos de búsqueda (Search Jobs) o Restauración (Restore) para las investigaciones. Razonamiento operativo: retenga solo aquello sobre lo que los analistas pivotan rutinariamente; archive el resto para cumplir con las necesidades de auditoría/regulatorias sin inflar el gasto en la ruta de acceso frecuente.

• Controles de costos

  • Los niveles de compromiso (reservas de capacidad) reducen el costo de ingesta de manera predecible para volúmenes estables; actívelos después de establecer una línea base de 30 a 60 días para evitar un compromiso excesivo.
  • Planes de facturación a nivel de tabla: use el modo Analytics para tablas críticas de seguridad (SecurityEvent, SignInLogs, CommonSecurityLog). Use Basic Logs para diagnósticos detallados y de bajo valor que consulta con poca frecuencia; nunca coloque tablas de seguridad de alta señal en Basic porque pierden las funciones de consulta completas y no son elegibles para alertas.
  • Las transformaciones en tiempo de ingesta con DCR eliminan o enmascaran campos y filas (minimización de PII, reducción de ruido) antes de la facturación. Operativamente, eliminar el ruido antes de la ingesta es el control de costo y fidelidad más potente.
  • Establezca límites diarios para el área de trabajo y alertas sobre picos anómalos para detectar configuraciones incorrectas o ataques que generen tormentas de registros (logs).

Conectores de datos e ingesta

• Azure Activity

  • Use el conector de Azure Activity para transmitir operaciones del plano de control a nivel de suscripción a la tabla AzureActivity a través de la configuración de diagnóstico (Diagnostic settings). Razonamiento: captura cambios de roles, actualizaciones de políticas y despliegues, indicadores principales de escalada de privilegios o manipulación por parte de un atacante.

• Microsoft Entra ID (Azure AD)

  • Habilite los conectores AuditLogs y SignInLogs. Opcionalmente, ingiera los registros enriquecidos de Azure AD (Enriched Azure AD logs) si tiene la licencia. Razonamiento: la identidad es la principal superficie de ataque; las anomalías en los inicios de sesión y los cambios en el directorio son la base de la mayoría de las detecciones y de UEBA.

• Productos de Microsoft Defender

  • Los conectores de Defender for Endpoint, Defender for Office 365, Defender for Identity, Defender for Cloud Apps y Defender for Cloud aportan alertas y telemetría de alta fidelidad. Razonamiento: las alertas de seguridad de Microsoft están profundamente correlacionadas y elevan la calidad de los incidentes; ingiéralas para potenciar Fusion y las reglas de seguridad de Microsoft con un ajuste mínimo.

• Eventos de Windows

  • Use Azure Monitor Agent (AMA) con DCR: eventos de seguridad de Windows (Windows Security Events) a la tabla SecurityEvent (Común, Mínimo o Todo) para controladores de dominio (DC) y servidores críticos; canales generales de eventos de Windows (Windows Event) a la tabla WindowsEvent según sea necesario. Razonamiento: la tabla SecurityEvent es la columna vertebral para la auditoría de autenticación y procesos; el filtrado con DCR recorta el ruido (p. ej., excluir el evento 4688 sin CommandLine).

• Syslog y CEF

  • Para Linux, la DCR de Syslog de AMA selecciona facilities y niveles de gravedad para la tabla Syslog. Para firewalls/IDS/EDR de terceros, reenvíe CEF al reenviador basado en el agente de Log Analytics o a la ingesta basada en AMA que deposita los datos en CommonSecurityLog; use el contenido del analizador del proveedor. Razonamiento: CEF mantiene campos normalizados y reduce la carga de análisis; CommonSecurityLog desbloquea detecciones preconstruidas.

• Higiene operativa

  • Sincronización de tiempo (NTP) y zonas horarias consistentes en los dispositivos para una correlación precisa.
  • Deduplique las fuentes que se superponen (p. ej., no ingiera duplicados brutos y normalizados a la vez).
  • Valide el esquema con Watchlists o consultas de muestra antes de habilitar los análisis para evitar falsos positivos.

Analítica, Detección e Investigación

• Tipos de reglas de analítica

  • Reglas programadas (Scheduled): KQL sobre datos históricos con una cadencia (p. ej., cada 5 minutos, con una retrospectiva de 1 hora). Úsalas para la mayoría de las detecciones; ajusta la retrospectiva para que exceda la latencia de datos típica y evitar omisiones.
  • Casi en tiempo real (NRT): detección en menos de un minuto con KQL restringido y una retrospectiva corta y fija. Úsalas con moderación para patrones de alta urgencia donde los segundos importan (p. ej., asignación masiva de roles). Opera con uniones (joins) mínimas y filtros simples para un buen rendimiento.
  • Fusion: correlación multifase impulsada por ML a través de señales de Microsoft (Defender, Entra, Cloud Apps). Razonamiento: reduce drásticamente la fatiga por alertas al producir un único incidente para una cadena de ataque (attack kill chain).
  • Reglas de anomalías: líneas base de usuario/entidad con umbrales dinámicos. Proporcionan victorias rápidas (quick wins) para patrones inusuales de geolocalización, volumen o procesos; mantén listas de exclusión para anomalías autorizadas (p. ej., ventanas de mantenimiento).
  • Reglas de seguridad de Microsoft: crean incidentes automáticamente a partir de alertas de Defender. Mantenlas habilitadas y ajusta las reglas de automatización para el enrutamiento/severidad; proporcionan señales de alta confianza con un bajo costo de ajuste.

• Mapeo de entidades e incidentes

  • Mapea las columnas de salida de KQL a entidades (Cuenta, Host, IP, URL, Archivo) en la configuración de la regla para potenciar los grafos de incidentes y UEBA. Un mapeo deficiente degrada la fidelidad de la investigación.
  • La política de agrupación de alertas influye en el volumen y el contexto de los incidentes. Agrupa por entidades/ventana de tiempo para combinar alertas relacionadas, reduciendo el ruido mientras se preserva la narrativa (storyline).

• Investigación y UEBA

  • Los incidentes presentan una cronología (timeline), evidencia y entidades relacionadas; el grafo de investigación construye relaciones automáticamente a partir del mapeo de entidades y las búsquedas de datos.
  • Habilita UEBA para enriquecer las entidades con líneas base de pares, roles de dispositivo y señales de riesgo. Razonamiento: el contexto acorta el tiempo de triaje e informa el alcance de la respuesta.

• Fundamentos de KQL para la ingeniería de detección

  • Filtrado y proyección

    SignInLogs
    | where TimeGenerated > ago(24h) and ResultType != 0
    | project TimeGenerated, UserPrincipalName, IPAddress, AppDisplayName, ResultType
    ```

  - Análisis sintáctico (parsing) y normalización

CommonSecurityLog
| extend Url = extract(@"request=([^;\s]+)", 1, AdditionalExtensions)
| parse DeviceCustomString1 with * "cmd=" CommandLine
```

• Uniones (Joining)

    SecurityEvent
    | where EventID == 4624 and AccountType == "User"
    | summarize logons = count() by Account, bin(TimeGenerated, 1h)
    | join kind=inner (
        SignInLogs
        | summarize aad_logons = count() by UserPrincipalName, bin(TimeGenerated, 1h)
    ) on $left.Account == $right.UserPrincipalName, TimeGenerated
    ```

  - Resumen y análisis de ventanas de tiempo

SignInLogs
| where TimeGenerated between (ago(1d) .. now())
| summarize attempts = count(), byIP = dcount(IPAddress) by UserPrincipalName
| where attempts > 50 or byIP > 10
```

Búsqueda, Automatización, Inteligencia de Amenazas, Informes y Ajuste del SOC

• Flujo de trabajo de búsqueda de amenazas

  • Consultas de búsqueda: empezar desde plantillas de Sentinel; evolucionar con listas de permitidos específicas del entorno. Guardar las pistas prometedoras como consultas personalizadas para su reutilización.
  • Marcadores: capturar evidencias y puntos de pivote durante las búsquedas; adjuntarlos más tarde a los incidentes para preservar el contexto del analista.
  • Livestream: ejecutar un filtro KQL continuamente para detectar eventos a medida que llegan; ideal durante incidentes activos para confirmar la contención.
  • Watchlists: cargar conjuntos de permitidos/denegados/prioritarios basados en CSV (usuarios VIP, IP sancionadas, niveles de activos). Referenciarlos con la función _GetWatchlist para enriquecimiento y supresión.

• Reglas de automatización y playbooks

  • Las reglas de automatización realizan el triaje en la creación de incidentes/alertas: establecen la severidad, asignan un propietario, añaden etiquetas, cierran con una clasificación o activan playbooks basados en condiciones (nombre de la regla, tácticas, entidades).
  • Los Playbooks (Logic Apps) implementan SOAR: enriquecen con VirusTotal/MDTI, notifican en Teams, abren tickets (ServiceNow/Jira), aíslan endpoints (MDE) o deshabilitan cuentas (Entra). Usar identidades administradas y RBAC de privilegios mínimos (Sentinel Responder en el workspace; roles de alcance limitado para los sistemas de destino). Justificación: acciones codificadas y repetibles reducen el MTTR y el error manual.

• Inteligencia de amenazas (TI)

  • Ingerir indicadores de TI usando proveedores integrados, carga manual, automatización de GitHub o colectores TAXII (STIX 2.0/2.1). Normalizar campos (tipo de indicador, patrón, confianza, TLP) y establecer una expiración para evitar coincidencias obsoletas.
  • Coincidencia de indicadores: habilitar reglas analíticas basadas en TI para hacer coincidir IP/dominio/URL/hash con la telemetría (CommonSecurityLog, DNS, Proxy, SignInLogs). Usar umbrales de confianza y excepciones de watchlist para reducir el ruido. Justificación: la TI acota el espacio de búsqueda a elementos maliciosos conocidos, pero debe ser curada para evitar falsos positivos.

• Workbooks e informes

  • Construir dashboards operativos con Azure Monitor Workbooks. Parametrizar por suscripción, workspace o rango de tiempo; resumir los datos tempranamente (summarize, make-series) para mantener las consultas eficientes.
  • Proporcionar vistas por niveles: postura ejecutiva (incidentes por severidad/SLA), operaciones del SOC (abiertos vs. cerrados, antigüedad de la cola, carga de analistas), salud de las detecciones (estado del conector, latencia de datos) y cobertura de controles (mapeo de MITRE). Justificación: las vistas específicas para cada rol apoyan la toma de decisiones sin abrumar a los usuarios con eventos en bruto.

• Ajuste y procedimientos del SOC

  • Reducción de falsos positivos: refinar los predicados KQL, añadir líneas base (umbrales dinámicos), aprovechar las listas de permitidos de entidades (watchlists) y excluir fuentes benignas. Validar cada supresión con un control compensatorio.
  • Normalización de la severidad: mapear la severidad de la regla al impacto y la confianza, no a la frecuencia. Alta debe implicar una llamada de guardia; Media para un triaje rápido; Baja para la búsqueda en el backlog.
  • Escalamiento y traspaso: definir estados de incidentes, propietarios y SLAs; enriquecer y enrutar automáticamente a la cola correcta; abrir tickets de ITSM a través de playbooks con actualizaciones bidireccionales. Documentar los pasos de contención para cada táctica (deshabilitar usuario, aislar endpoint, revocar tokens, bloquear indicadores).

Escenario de Problema Práctico

Contoso Ltd. experimenta fatiga de alertas y una respuesta lenta después de incorporar múltiples fuentes de datos en Microsoft Sentinel. Los incidentes son numerosos, están mal agrupados y carecen de automatización. El CISO exige una reducción del 50% en el tiempo medio de respuesta (MTTR) sin perder fidelidad en la detección.

1. Rearquitectar la ingesta de datos con filtrado DCR y planes de tabla

• Acción: Mover los Windows Security Events a AMA+DCR con el preajuste “Common” en los DCs; cambiar las tablas de diagnóstico detalladas a Basic Logs; habilitar 90 días de retención hot y 1 año de archivo.
• Justificación: Reduce el ruido y el costo de la ruta hot mientras preserva los datos de seguridad accionables, liberando ciclos de análisis y presupuesto para detecciones de mayor fidelidad.

2. Habilitar los conectores de Microsoft Defender y Fusion

• Acción: Conectar MDE, MDI, MDO, MDC y Cloud Apps; asegurar que el análisis de seguridad de Microsoft y Fusion estén activados.
• Justificación: Las alertas de alta confianza y la correlación de ML colapsan las alertas duplicadas en un único incidente enriquecido, reduciendo la carga de triaje.

3. Estandarizar el mapeo de entidades y la agrupación de alertas

• Acción: Actualizar las reglas programadas para mapear Account, Host, IP y URL; configurar la agrupación por Account y una ventana de 4 horas para alertas relacionadas.
• Justificación: Un mapeo adecuado alimenta los gráficos de investigación y UEBA; la agrupación reduce el volumen de incidentes mientras preserva el contexto para las cadenas de ataque.

4. Implementar reglas de automatización para el triaje y playbooks dirigidos

• Acción: Crear reglas de automatización para etiquetar automáticamente por táctica, establecer la severidad según la confianza, asignar a colas y activar playbooks: enriquecer indicadores (MDTI), abrir tickets en ServiceNow, aislar dispositivos (MDE) y suspender usuarios de riesgo (Entra) con aprobación.
• Justificación: El triaje determinista más las acciones SOAR acortan el MTTR y estandarizan las respuestas; las aprobaciones imponen barreras de seguridad para los pasos de alto impacto.

5. Introducir watchlists y coincidencia de TI con curación

• Acción: Construir watchlists de usuarios VIP y servicios sancionados; añadir un feed TAXII curado con una confianza >= 70 y una expiración de 7 días; habilitar reglas de coincidencia de TI contra proxy/DNS.
• Justificación: Prioriza los objetivos de alto valor y utiliza TI fresca y confiable para enfocar las investigaciones y reducir los falsos positivos.

6. Publicar workbooks y SLAs basados en roles

• Acción: Crear workbooks para ejecutivos, operaciones del SOC y salud de las detecciones; establecer SLAs para incidentes (Alta 4h, Media 24h, Baja 3d) e informar sobre incumplimientos.
• Justificación: La visibilidad y la rendición de cuentas impulsan la disciplina operativa; los dashboards específicos evitan el cambio de contexto y el esfuerzo desperdiciado.

7. Establecer una cadencia de ajuste continuo

• Acción: Revisión semanal de los incidentes cerrados como falsos positivos; ajustar reglas, supresiones y exclusiones con justificaciones documentadas; monitorear anomalías en la ingesta y el rendimiento de las consultas.
• Justificación: Las operaciones de seguridad se desvían sin bucles de retroalimentación; el refinamiento continuo mantiene la calidad de la señal a medida que el entorno evoluciona.

Al ejecutar estos pasos, Contoso alinea las detecciones con el riesgo del negocio, reduce el ruido en el origen y automatiza tareas repetitivas, logrando una respuesta a incidentes más rápida y consistente sin sacrificar la cobertura.

← Gestión de la postura de seguridad y gobernanza · Todos los dominios · Seguridad de aplicaciones y DevSecOps →

Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →

Explorar Microsoft →