Última revisión: mayo de 2026
Una referencia escaneable de patrones arquitectónicos que evalúa el examen SC-200. Lee de arriba a abajo o salta a una sección.
Requisitos estrictos de residencia de datos en múltiples regiones geográficas.
Implementar múltiples espacios de trabajo de Microsoft Sentinel, uno por región. Usar Azure Lighthouse para la administración centralizada.
Por qué: Mantiene los datos de registro dentro de los límites geográficos para el cumplimiento, permitiendo que un SOC central opere en todos los espacios de trabajo.
Espacio de trabajo de Sentinel ingiriendo más de 100 GB de datos por día.
Cambiar el nivel de precios del espacio de trabajo de Log Analytics de Pago por uso a Niveles de compromiso.
Por qué: Los Niveles de compromiso ofrecen importantes ahorros de costos para la ingesta de datos de gran volumen y predecible en comparación con los precios estándar.
Los registros de gran volumen (por ejemplo, eventos de seguridad de Windows) están aumentando los costos de SIEM.
1. Usar una Regla de recopilación de datos (DCR) para filtrar eventos en el origen. 2. Configurar la tabla de destino para Registros básicos.
Por qué: Las DCRs reducen los costos de ingesta al recopilar solo los eventos necesarios. Los Registros básicos reducen los costos de almacenamiento para datos detallados que no requieren análisis completos.
El cumplimiento requiere retención de datos por más de 2 años (por ejemplo, 7 años).
Configurar el espacio de trabajo con retención interactiva de 90 días y retención total de 7 años (nivel de archivo).
Por qué: Equilibra la capacidad de búsqueda inmediata (interactiva) con el almacenamiento de bajo costo y a largo plazo (archivo). Acceder a los datos archivados mediante Trabajos de búsqueda.
Recopilar eventos de seguridad de servidores Windows y Linux locales.
Instalar el agente de Azure Arc para la administración, luego implementar el Agente de Azure Monitor (AMA) a través de Arc.
Por qué: Arc extiende el plano de control de Azure a entornos locales, habilitando la administración nativa y la recopilación de datos con el agente AMA moderno.
Ingerir registros de dispositivos de terceros (por ejemplo, firewalls) que soportan Syslog.
Implementar una máquina virtual Linux dedicada como Reenviador de registros con el AMA. Usar el formato CEF para datos de seguridad estructurados.
Por qué: Centraliza la recopilación para dispositivos que no pueden alojar un agente. CEF proporciona un esquema normalizado y consultable para eventos de seguridad.
Ingerir incidentes y alertas de Microsoft Defender XDR en Sentinel.
Habilitar el conector de datos de Microsoft Defender XDR y su opción de creación de incidentes/sincronización bidireccional.
Por qué: Crea una cola de incidentes unificada y asegura que los cambios de estado se sincronicen entre Sentinel y el portal de Defender.
Filtrar IDs de eventos de Windows específicos en el origen para reducir el volumen de ingesta.
Configurar una Regla de recopilación de datos (DCR) con una consulta XPath para especificar qué IDs de eventos recopilar.
Por qué: Reduce el volumen y el costo de ingesta al filtrar datos en el agente de origen, antes de enviarlos al espacio de trabajo.
Requerir el tiempo de detección más rápido posible para eventos críticos.
Usar una regla de análisis casi en tiempo real (NRT).
Por qué: Las reglas NRT se ejecutan cada minuto, ofreciendo una latencia de detección de ~1-2 minutos, mucho más rápido que el mínimo de 5 minutos para las reglas programadas.
Detectar un umbral de eventos dentro de una ventana de tiempo específica (por ejemplo, ataques de fuerza bruta).
Crear una regla de análisis programada usando KQL `summarize ... by bin(TimeGenerated, 5m), ...`.
Por qué: La función `bin()` es fundamental para agrupar eventos en ventanas de tiempo discretas y no superpuestas para una detección de umbral precisa.
Detectar ataques complejos de múltiples etapas que las alertas individuales podrían pasar por alto.
Habilitar reglas de análisis de Fusion para la detección avanzada de ataques de múltiples etapas.
Por qué: Fusion usa ML para correlacionar señales de baja fidelidad en múltiples fuentes de datos en incidentes de alta confianza, reduciendo la fatiga de alertas.
Detectar amenazas internas o cuentas comprometidas basadas en comportamientos anómalos.
Habilitar el Análisis del Comportamiento de Usuarios y Entidades (UEBA).
Por qué: UEBA establece líneas de base de comportamiento para usuarios y entidades, luego marca desviaciones significativas que no coinciden con la lógica de reglas específica.
Escribir una única regla de análisis agnóstica a la fuente para múltiples fuentes de datos (por ejemplo, DNS de varios proveedores).
Usar analizadores del Modelo de Información de Seguridad Avanzada (ASIM) en la consulta KQL.
Por qué: ASIM proporciona un esquema normalizado, permitiendo que las consultas se ejecuten contra una vista unificada (por ejemplo, `imDns`) en lugar de múltiples tablas específicas del proveedor.
Administrar contenido de Sentinel (reglas de análisis, libros) como código e implementarlo en diferentes entornos.
Usar los Repositorios de Microsoft Sentinel para conectar un repositorio de GitHub o Azure DevOps.
Por qué: Habilita flujos de trabajo de CI/CD, control de versiones y el despliegue automatizado y consistente de contenido de seguridad (Sentinel-as-Code).
Automatizar tareas básicas de triaje de incidentes como asignar propietarios, cambiar el estado o agregar etiquetas.
Usar una Regla de automatización activada por la creación de incidentes.
Por qué: Las reglas de automatización son ligeras y síncronas, ideales para acciones de triaje simples sin la sobrecarga de una Logic App.
Automatizar respuestas a incidentes complejas que involucren sistemas externos (por ejemplo, bloquear usuario en Entra ID, enviar mensaje de Teams).
Crear un Playbook (Azure Logic App) y activarlo desde una Regla de automatización.
Por qué: Las Logic Apps proporcionan el motor de orquestación y los conectores necesarios para respuestas e integraciones complejas de múltiples pasos.
Comprender el alcance de un ataque visualizando las relaciones entre entidades (usuarios, IPs, hosts).
Usar el Gráfico de investigación en la página de detalles del incidente.
Por qué: Proporciona un mapa interactivo del ataque, facilitando ver conexiones y pivotar entre entidades y alertas relacionadas.
Estandarizar y acelerar los flujos de trabajo de investigación comunes para el equipo SOC.
Crear y compartir un Promptbook en Microsoft Security Copilot.
Por qué: Los Promptbooks encadenan una serie de indicaciones en lenguaje natural para crear un proceso de investigación guiado y repetible para escenarios comunes.
Administrar permisos de seguridad de forma centralizada para todos los productos de Microsoft Defender.
Activar el modelo RBAC unificado de Microsoft Defender XDR.
Por qué: Reemplaza roles individuales específicos de productos con un modelo de permisos único y granular, simplificando la administración.
Isolar dispositivos o remediar archivos automáticamente según la gravedad de la alerta.
Configurar los ajustes de investigación automatizada para grupos de dispositivos, estableciendo el Nivel de automatización en 'Completo' o 'Semi'.
Por qué: Permite la remediación sin intervención para amenazas comunes. Los grupos de dispositivos permiten diferentes niveles de automatización para estaciones de trabajo versus servidores críticos.
Bloquear inmediatamente un hash de archivo malicioso conocido, una dirección IP o una URL en todos los puntos finales.
Crear un Indicador de Compromiso (IoC) con una acción de "Bloquear y Remediación".
Por qué: Proporciona un mecanismo de contención rápido y a nivel de toda la organización que es más rápido que esperar las actualizaciones de firmas de AV.
Fortalecer los puntos finales bloqueando técnicas de ataque comunes (por ejemplo, Office creando procesos secundarios).
Implementar reglas de Reducción de la Superficie de Ataque (ASR), comenzando en modo 'Auditoría' para evaluar el impacto antes de cambiar a 'Bloquear'.
Por qué: Las reglas ASR son un control preventivo clave. El modo Auditoría es crítico para prevenir la interrupción de las aplicaciones comerciales durante el despliegue.
Realizar una investigación forense profunda o remediación manual en un punto final en vivo.
Usar la función de Respuesta en Vivo para establecer un shell remoto y recopilar paquetes forenses.
Por qué: Proporciona acceso directo y en tiempo real al dispositivo para ejecutar comandos, recopilar archivos y ejecutar scripts forenses.
Reconstruir las acciones de un atacante en un dispositivo comprometido específico.
Analizar la Línea de Tiempo del Dispositivo.
Por qué: Proporciona un registro de eventos detallado y cronológico de toda la actividad de procesos, red, archivos y registro en el punto final.
Detectar robo de credenciales y técnicas de movimiento lateral como Pass-the-Hash/Ticket.
Implementar sensores de Microsoft Defender for Identity en todos los Controladores de Dominio.
Por qué: Defender for Identity monitorea directamente el tráfico de autenticación de AD local, proporcionando alertas de alta fidelidad para ataques basados en identidad.
Proteger a los usuarios de malware de día cero incrustado en archivos adjuntos de correo electrónico.
Configurar una política de Datos Adjuntos Seguros con la opción de Entrega Dinámica.
Por qué: Detona los archivos adjuntos en un sandbox para verificar comportamientos maliciosos mientras entrega el cuerpo del correo electrónico inmediatamente, equilibrando seguridad y productividad.
Encontrar y eliminar todas las instancias de un correo electrónico de phishing de los buzones de los usuarios.
Usar el Explorador de amenazas (o la Búsqueda avanzada) para buscar el correo electrónico y ejecutar una acción de eliminación suave o dura.
Por qué: El Explorador de amenazas es una potente herramienta de búsqueda y remediación para purgar amenazas activas del sistema de correo en toda la organización.
Prevenir la exfiltración de datos bloqueando las descargas de archivos sensibles a dispositivos no administrados (no conformes).
Configurar una política de sesión de Defender for Cloud Apps usando el Control de aplicaciones de acceso condicional.
Por qué: Actúa como un proxy inverso para inspeccionar y controlar la actividad del usuario en tiempo real dentro de una sesión de aplicación en la nube, aplicando políticas de acceso a datos.
Contener automáticamente un ataque activo y generalizado como el ransomware operado por humanos.
Habilitar la Interrupción automática de ataques en Microsoft Defender XDR.
Por qué: Utiliza señales de varios dominios (XDR) para tomar acciones decisivas a velocidad de máquina, como deshabilitar cuentas de usuario comprometidas e aislar dispositivos.
Buscar proactivamente amenazas en todos los datos XDR (punto final, correo electrónico, identidad, aplicaciones en la nube).
Usar Búsqueda avanzada con Kusto Query Language (KQL).
Por qué: Proporciona una interfaz potente basada en consultas para buscar en 30 días de telemetría sin procesar, permitiendo el descubrimiento de amenazas que eluden las detecciones estándar.
Comprender rápidamente el alcance completo de un incidente complejo que involucra múltiples alertas y entidades.
Analizar la Historia de ataque o el Gráfico de investigación del incidente.
Por qué: Consolida y visualiza toda la cadena de ataque, mostrando cómo un atacante se movió desde un punto de entrada inicial a través de diferentes activos.
Extender las protecciones de carga de trabajo de Defender for Cloud a servidores locales y multi-nube.
Incorporar los servidores usando Azure Arc, luego habilitar el plan de Defender para Servidores.
Por qué: Azure Arc actúa como un puente del plano de control, proyectando recursos no-Azure en Azure para que puedan ser administrados y asegurados por Defender for Cloud.
Comprender rápidamente el propósito y la posible maliciosidad de un script complejo (por ejemplo, PowerShell).
Pegar el script en Security Copilot y solicitar un análisis de su función y riesgo.
Por qué: Aprovecha la IA generativa para desofuscar y explicar código, acelerando significativamente el análisis de artefactos sin ejecutar el script.
Contener inmediatamente una cuenta de usuario comprometida que se sincroniza desde el AD local.
Deshabilitar la cuenta en Active Directory local, luego activar una sincronización inmediata de AD Connect.
Por qué: Para identidades sincronizadas, el AD local es la fuente de autoridad. Deshabilitar la cuenta allí es la acción de contención más efectiva.
Ingerir inteligencia de amenazas externa de un TIP usando un protocolo estándar de la industria.
Usar el conector de datos 'Threat Intelligence - TAXII' en Sentinel.
Por qué: Se conecta a servidores TAXII 2.x para importar automáticamente indicadores en formato STIX, operacionalizando la inteligencia de amenazas.
Correlacionar indicadores de amenazas conocidos (IPs, dominios, hashes) con todas las fuentes de registro ingeridas.
Ingerir indicadores en la tabla ThreatIntelligenceIndicator y habilitar las reglas de análisis integradas "TI map...".
Por qué: Estas reglas comparan eficientemente la inteligencia de amenazas con campos de entidad normalizados en los registros para generar alertas sobre actividad maliciosa conocida.
Usar una lista personalizada de indicadores (por ejemplo, IPs de socios comerciales, cuentas de empleados terminados) para alertar o enriquecer.
Crear una Watchlist y unirse a ella con datos en consultas KQL.
Por qué: Las Watchlists actúan como un almacén simple de clave-valor para datos personalizados, fácilmente utilizables en consultas para lógica de detección o para reducir falsos positivos.
Una consulta de caza KQL exitosa debe ser guardada y operacionalizada para la detección automática.
1. Guardar la consulta en la sección de Caza. 2. Promover la consulta de caza a una Regla de análisis programada.
Por qué: Formaliza la transición del descubrimiento ad-hoc (caza) a la detección automatizada y repetible (regla de análisis).
Evaluar la cobertura de detección e identificar brechas basándose en el framework MITRE ATT&CK.
Usar la sección MITRE ATT&CK en Sentinel. Etiquetar las reglas de análisis con tácticas/técnicas relevantes.
Por qué: Proporciona un mapa de calor visual de las capacidades de detección mapeadas contra el framework estándar de la industria, guiando la ingeniería de detección.
Preservar resultados o evidencias interesantes encontrados durante una caza para un seguimiento posterior.
Crear un Marcador de Caza a partir de los resultados de la consulta KQL.
Por qué: Captura la consulta, los resultados y el contexto de la entidad, permitiendo a un analista guardar hallazgos sin crear inmediatamente un incidente completo.