La ejecución de Microsoft Defender XDR y Microsoft Sentinel en paralelo le brinda a su SOC dos herramientas poderosas. Ejecutarlos como dos colas separadas les da a los analistas dos lugares donde perderse algo.

El mejor modelo es una experiencia SecOps unificada: Defender XDR correlaciona alertas entre endpoints, identidades, correo electrónico, aplicaciones SaaS y cargas de trabajo en la nube, mientras que Microsoft Sentinel agrega cobertura SIEM, retención a largo plazo, datos multinube, detecciones personalizadas y SOAR. Microsoft documenta esta integración como una forma de incorporar incidentes, alertas, entidades y eventos de búsqueda avanzada de Defender XDR a Sentinel, con sincronización de incidentes entre portales cuando se usa el conector (Integración de Microsoft Defender XDR con Microsoft Sentinel).

En esta guía, configurará la integración de manera práctica: elija el portal de Defender como la experiencia de incidente principal, conecte los datos de Defender XDR a Sentinel, transmita eventos sin procesar de Microsoft Defender para Endpoint a tablas de Sentinel y cree detecciones y guías que funcionen en todos los productos.

Requisitos previos

Antes de comenzar a hacer clic en los botones, asegúrese de tener el acceso y las licencias correctos. Microsoft enumera los requisitos principales para configurar manualmente el conector Defender XDR en Azure Portal como una licencia válida de Microsoft Defender XDR, administrador de seguridad o permisos de inquilino equivalentes, permisos de lectura/escritura en el área de trabajo de Microsoft Sentinel y membresía en el mismo inquilino de Microsoft Entra que el espacio de trabajo (Transmitir datos desde Microsoft Defender XDR a Microsoft Sentinel).

También necesitarás:

• Un espacio de trabajo de Microsoft Sentinel.

• Microsoft Defender XDR activado para el inquilino.

• Microsoft Defender para Endpoint incorporado si planea transmitir eventos de búsqueda avanzada de endpoints.

• Permiso para instalar soluciones de Content Hub en Microsoft Sentinel.

• Permiso para crear reglas de análisis, reglas de automatización y guías.

Una nota de planificación importante: Microsoft dice que Microsoft Sentinel en el portal de Azure ya no será compatible después del 31 de marzo de 2027 y los clientes serán redirigidos a Microsoft Sentinel en el portal de Microsoft Defender (Microsoft Sentinel en el portal de Microsoft Defender). Si está diseñando un nuevo modelo operativo hoy, utilice el portal Defender como experiencia de analista predeterminada, a menos que tenga una razón difícil para no hacerlo.

Paso 1: elija su modelo de integración

Hay dos maneras de pensar en esta integración.

El primer modelo es el enfoque moderno de portal unificado. Usted incorpora Microsoft Sentinel al portal de Microsoft Defender y trabaja los incidentes, alertas, búsquedas y configuración de Sentinel desde https://security.microsoft.com. Microsoft dice que Sentinel generalmente está disponible en el portal Defender, incluso para clientes sin Defender XDR o una licencia E5, y que el portal Defender proporciona la experiencia SIEM y XDR unificada (Microsoft Sentinel en el portal de Microsoft Defender).

El segundo modelo es el antiguo enfoque del conector de Azure Portal. Instala la solución Microsoft Defender XDR desde Sentinel Content Hub, abre el conector de datos de Microsoft Defender XDR y habilita manualmente la recopilación de incidentes, alertas, entidades y eventos. Este modelo sigue siendo útil para espacios de trabajo existentes que no se han trasladado completamente al portal de Defender.

Aquí está la decisión más simple:

• ¿Nuevo flujo de trabajo SOC? Utilice el portal del Defensor.

• ¿El espacio de trabajo Sentinel existente todavía funciona desde Azure? Habilite el conector Defender XDR ahora y luego planifique la transición del portal.

• ¿Período de transición híbrido? Mantenga los runbooks explícitos sobre qué portal posee cada tarea hasta que los analistas estén completamente movidos.

Paso 2: utilizar el Portal de Defender como cola de incidentes principales

La mayor victoria operativa no es una tabla o una consulta. Les está dando a los analistas una cola de incidentes.

En el portal de Defender, vaya a Investigación y respuesta —> Incidentes y alertas —> Incidentes. Esta cola puede mostrar incidentes de Microsoft Sentinel junto con incidentes de Defender XDR cuando Sentinel se incorpora al portal de Defender. Microsoft describe esto como parte de la experiencia unificada del portal Defender, donde los datos de Microsoft Sentinel se incorporan junto con los datos de seguridad de la organización y los equipos de SecOps analizan y responden en un solo lugar (Integración de Microsoft Defender XDR con Microsoft Sentinel).

Si su espacio de trabajo ya está integrado en el portal de Defender, Microsoft dice que el conector Defender XDR se configura automáticamente para usted. Los pasos del conector manual no son necesarios en ese caso (Transmitir datos desde Microsoft Defender XDR a Microsoft Sentinel).

Si su equipo todavía usa Sentinel en Azure Portal, configure el conector manualmente:

1. Abierto Centinela de Microsoft en el portal de Azure.

2. Selecciona tu espacio de trabajo.

3. Ir a Gestión de contenidos —> Centro de contenidos.

4. Instale el Microsoft Defender XDR solución.

5. Ir a Configuración —> Conectores de datos.

6. Abre el Microsoft Defender XDR página del conector.

7. Permitir Conecta incidencias y alertas.

8. Seleccione la opción recomendada para desactivar las reglas de creación de incidentes de Microsoft para los productos Defender integrados para evitar incidentes duplicados.

9. Guarde la configuración del conector.

La documentación del conector de Microsoft incluye esta consulta de validación para incidentes de Defender XDR en Sentinel:

“`texto sin formato
Incidente de seguridad
| donde Nombre del proveedor == “Microsoft XDR”

Under normal operating conditions, Microsoft says Defender XDR incidents typically appear in the Sentinel UI and API within five minutes after they’re generated in Defender XDR. Ingestion into the `SecurityIncident` table can take a few more minutes ([Microsoft Defender XDR integration with Microsoft Sentinel](https://learn.microsoft.com/en-us/azure/sentinel/microsoft-365-defender-sentinel-integration)).

## Step 3: Understand What Syncs Between Defender XDR and Sentinel

Once incidents are connected, don’t treat the integration as a one-way log feed. Microsoft documents bidirectional synchronization between the Defender portal and Sentinel for Defender XDR incidents. Changes to certain incident fields are synchronized after the change is applied, though you might need to refresh the portal to see the latest values ([Microsoft Defender XDR integration with Microsoft Sentinel](https://learn.microsoft.com/en-us/azure/sentinel/microsoft-365-defender-sentinel-integration)).

For analysts, that means:

- An incident can be triaged in Defender XDR and reflected in Sentinel.

- An incident can be managed in Sentinel and reflected in Defender XDR.

- Defender XDR correlation can merge or update incidents as the attack story changes.

- A Sentinel incident can link back to its parallel Defender XDR incident.

For engineers, it means you should stop building automation that assumes Sentinel alone owns the incident lifecycle. Use stable conditions such as severity, provider, product name, entities, tags, tactics, or custom details. Avoid brittle conditions based only on incident title. Microsoft specifically warns that Defender XDR’s correlation engine automatically names incidents and recommends using criteria other than incident name for automation rule conditions, such as tags ([Microsoft Defender XDR integration with Microsoft Sentinel](https://learn.microsoft.com/en-us/azure/sentinel/microsoft-365-defender-sentinel-integration)).

Also remember the 150-alert behavior. Microsoft says Sentinel incidents can contain a maximum of 150 alerts. Defender XDR incidents can have more; if an incident with more than 150 alerts is synchronized, Sentinel shows `150+` and links to the Defender XDR incident for the full set ([Microsoft Defender XDR integration with Microsoft Sentinel](https://learn.microsoft.com/en-us/azure/sentinel/microsoft-365-defender-sentinel-integration)).

## Step 4: Stream Defender for Endpoint Raw Events into Sentinel

Incidents give you the story. Raw events give you the evidence.

The Defender XDR connector can stream advanced hunting events from Defender XDR components into purpose-built tables in your Sentinel workspace. Microsoft calls these a type of raw event data and says the tables use the same schema as the Defender portal advanced hunting schema, making it easier to copy existing Defender hunting queries into Sentinel ([Microsoft Defender XDR integration with Microsoft Sentinel](https://learn.microsoft.com/en-us/azure/sentinel/microsoft-365-defender-sentinel-integration)).

In the connector page, enable **Connect events**, then choose the tables you want to collect. For Microsoft Defender for Endpoint, common tables include:

- `DeviceInfo` for device inventory and OS information.

- `DeviceNetworkInfo` for network adapters, IP addresses, MAC addresses, networks, and domains.

- `DeviceProcessEvents` for process creation events.

- `DeviceNetworkEvents` for network connections.

- `DeviceFileEvents` for file creation, modification, and other file system activity.

- `DeviceRegistryEvents` for registry changes.

- `DeviceLogonEvents` for sign-ins and device authentication events.

- `DeviceImageLoadEvents` for DLL loading events.

- `DeviceEvents` for multiple endpoint event types, including security-control events.

A practical starting point is to enable the endpoint tables your SOC actually hunts with every week. If you turn on everything without a use case, you’ll pay to ingest data nobody uses. Microsoft notes that Defender XDR alerts and incidents that populate `SecurityAlert` and `SecurityIncident` are ingested and synchronized at no charge, but other data types, including advanced hunting tables such as `DeviceInfo`, `DeviceFileEvents`, and `EmailEvents`, are charged ([Microsoft Defender XDR integration with Microsoft Sentinel](https://learn.microsoft.com/en-us/azure/sentinel/microsoft-365-defender-sentinel-integration)).

Also watch for unsupported data. Microsoft specifically calls out Defender Vulnerability Management tables such as `DeviceTvmSoftwareInventory` and `DeviceTvmSoftwareVulnerabilities`: they can appear in the schema for autocomplete and discoverability, but TVM data isn’t ingested into Sentinel workspaces. Query TVM data in Defender XDR Advanced Hunting or build a custom ingestion path if Sentinel must use it ([Stream data from Microsoft Defender XDR to Microsoft Sentinel](https://learn.microsoft.com/en-us/azure/sentinel/connect-microsoft-365-defender)).

Validate event flow with a small query:

```plain text
DeviceProcessEvents
| take 10

Luego pruebe una consulta un poco más útil:

“`texto sin formato
Eventos de proceso de dispositivo
| donde Marca de tiempo > hace (24h)
| resumir ProcessEvents=count() por DeviceName
| top 20 por ProcessEvents descripción

If you get no data, check three things before blaming KQL: the connector table selection, Defender for Endpoint onboarding health, and whether enough time has passed for new events to arrive.

## Step 5: Build Cross-Product Detections

Once Defender endpoint events and Sentinel data live in the same workspace experience, you can start writing cross-product detections. For scheduled Sentinel analytics rules, Microsoft recommends designing and testing the KQL query first, making sure the query returns `TimeGenerated`, then creating a scheduled query rule from **Microsoft Sentinel —> Configuration —> Analytics** in the Defender portal or **Configuration —> Analytics** in the Azure portal ([Create scheduled analytics rules in Microsoft Sentinel](https://learn.microsoft.com/en-us/azure/sentinel/create-analytics-rules)).

Here’s a starter detection pattern that correlates suspicious endpoint process execution with sign-in activity. Adjust table names and fields to match the connectors you have enabled:

```plain text
let Lookback = 1h;
let SuspiciousProcesses = DeviceProcessEvents
| where TimeGenerated > ago(Lookback)
| where FileName in~ ("powershell.exe", "pwsh.exe", "cmd.exe", "wscript.exe", "cscript.exe")
| where ProcessCommandLine has_any ("-enc", "DownloadString", "FromBase64String", "Invoke-WebRequest")
| project TimeGenerated, DeviceName, AccountUpn, FileName, ProcessCommandLine, DeviceId;
let RecentSignins = SigninLogs
| where TimeGenerated > ago(Lookback)
| project SigninTime=TimeGenerated, UserPrincipalName, IPAddress, AppDisplayName, ResultType;
SuspiciousProcesses
| join kind=leftouter RecentSignins on $left.AccountUpn == $right.UserPrincipalName
| project TimeGenerated, DeviceName, AccountUpn, FileName, ProcessCommandLine, IPAddress, AppDisplayName, ResultType

Esa regla es intencionalmente simple. El punto es mostrar el flujo de trabajo:

1. Comience desde una tabla de comportamiento de puntos finales.

2. Únase con registros de identidad, nube, firewall o SaaS que ya estén en Sentinel.

3. Asigne entidades como cuenta, host y dirección IP en el asistente de reglas de análisis.

4. Pruebe con los datos actuales antes de guardar la regla.

5. Cree incidentes a partir de alertas a menos que tenga un motivo específico para no hacerlo.

Si su espacio de trabajo está incorporado al portal de Defender, Microsoft dice que el motor de correlación del portal de Defender es responsable de la correlación de alertas. La configuración de agrupación de alertas se acepta como instrucciones iniciales, pero la agrupación final puede diferir de lo que configuró en la regla (Cree reglas de análisis programadas en Microsoft Sentinel). Construya su proceso de análisis en torno a la calidad de los incidentes, no en un mapeo perfecto de una regla a un incidente.

Evalúe también las detecciones personalizadas de Defender. Microsoft ahora describe las detecciones personalizadas en Microsoft Defender como la mejor manera de crear nuevas reglas en Microsoft Sentinel SIEM y Defender XDR para una experiencia SOC unificada, mientras las reglas de análisis de Sentinel permanecen disponibles (Integración de Microsoft Defender XDR con Microsoft Sentinel). Una buena regla general es:

• Usar Detecciones personalizadas del defensor para detecciones y acciones de respuesta nativas de Defender, casi en tiempo real.

• Usar Reglas de análisis centinela cuando necesite fuentes de datos exclusivas de Sentinel, uniones complejas, plantillas de contenido SIEM o lógica de incidentes específica del espacio de trabajo.

Paso 6: Automatizar con reglas y guías

La detección sin respuesta simplemente crea una cola más bonita.

La automatización de Microsoft Sentinel tiene dos partes principales: reglas de automatización y guías. Las reglas de automatización gestionan el manejo de incidentes desde un lugar central. Pueden etiquetar, asignar o cerrar incidentes; desencadenar manuales de estrategias; automatizar respuestas a través de múltiples reglas de análisis; y crear listas de tareas para analistas. Los playbooks se basan en Azure Logic Apps y pueden ejecutar flujos de trabajo de respuesta o corrección automáticamente o bajo demanda (Automatización en Microsoft Sentinel).

Una primera regla práctica de automatización para el SOC unificado es una regla de etiquetado:

1. Ir a Microsoft Sentinel —> Configuración —> Automatización.

2. Cree una regla de automatización que se ejecute cuando se crea un incidente.

3. Alcancelo para incidentes en los que el proveedor o producto identifica Microsoft Defender XDR.

4. Añade una etiqueta como defender-xdr o unified-soc.

5. Asigne el incidente a su cola de Nivel 1 o grupo SOC.

6. Agregue tareas de analista como “Revisar el gráfico de incidentes de Defender”, “Verificar el cronograma del punto final” y “Confirmar el riesgo del usuario”.

Luego agregue un manual para el enriquecimiento, no para la remediación destructiva. Por ejemplo, un manual de Logic Apps puede publicar en Teams, abrir un ticket, enriquecer las IP con inteligencia sobre amenazas o recopilar información del propietario de los activos. Mantenga el aislamiento del dispositivo, la desactivación de cuentas y las acciones del buzón de correo detrás de un paso de aprobación manual hasta que tenga controles estrictos de falsos positivos.

Si está realizando la transición al portal de Defender, lea atentamente las diferencias de automatización. Microsoft señala que, después de la incorporación, el Updated by El campo tiene diferentes valores admitidos y, si se realizan varios cambios en el mismo incidente en un período de 5 a 10 minutos, se envía una única actualización a Sentinel con solo el cambio más reciente (Automatización en Microsoft Sentinel). Eso importa si su automatización depende de cada actualización de incidente intermedia.

Paso 7: Verificar el flujo de trabajo SOC de principio a fin

No dé por finalizada la integración solo porque el conector dice conectado. Ejecute una validación completa de la ruta del analista.

Utilice esta lista de verificación:

• Cree o identifique una alerta de prueba de bajo riesgo en Defender XDR.

• Confirme que el incidente aparezca en la cola de incidentes del portal Defender.

• Confirme que el incidente sincronizado aparezca en Sentinel si aún está validando el comportamiento de Azure Portal.

• Ejecute el SecurityIncident consulta para ProviderName == "Microsoft XDR".

• Ejecute una muestra DeviceProcessEvents o DeviceNetworkEvents consulta.

• Confirmar la asignación de entidades muestra usuarios, hosts y direcciones IP útiles.

• Active una regla de automatización de pruebas y confirme la etiqueta, el propietario, la tarea, el ticket o la notificación esperados.

• Cierre el incidente de prueba y confirme la sincronización del estado en el otro portal si ambos portales están en uso.

Documente lo que los analistas deben hacer en una página: por dónde empezar, en qué enlaces de portal confiar, cómo pasar a la búsqueda avanzada y cuándo ejecutar un manual de estrategias manualmente.

Pensamientos finales

La integración de Defender XDR y Microsoft Sentinel no es solo un conector. Es un modelo operativo.

Utilice el portal Defender como cola de incidentes unificada. Deje que Defender XDR correlacione las alertas de seguridad de Microsoft con incidentes más completos. Transmita a Sentinel las tablas de eventos sin procesar de Defender for Endpoint con las que realmente busca. Utilice reglas de análisis de Sentinel cuando necesite datos SIEM y uniones entre fuentes. Utilice detecciones personalizadas de Defender donde la detección y respuesta nativas de Defender se adapten mejor. Vincúlelo con reglas de automatización y guías de Logic Apps que enriquecen y dirigen los incidentes sin sorprender a los analistas.

Haga eso y su SOC obtendrá menos investigaciones dinámicas, un mejor contexto y un camino más limpio desde la señal hasta la respuesta.