Skip to main content

​
Descripción general

La integración de Microsoft Defender XDR (INT-021) proporciona sincronización bidireccional entre CaseBender y la plataforma de detección y respuesta extendida de Microsoft, incluidos Microsoft Defender para Endpoint (MDE) y Microsoft Defender XDR.

Ingesta entrante

Las alertas e incidentes de Defender se ingieren en CaseBender, se normalizan, se enriquecen con observables y técnicas MITRE ATT&CK, y se convierten en alertas/casos.

Sincronización saliente

Cuando se cierra un caso en CaseBender, la alerta/incidente vinculado de Defender se actualiza con el estado, la clasificación y un comentario de auditoría mediante Microsoft Graph.
Esta integración utiliza la API de seguridad de Microsoft Graph (https://graph.microsoft.com/v1.0/security). Se autentica con una aplicación de Azure AD (Entra ID) mediante el flujo de credenciales de cliente OAuth2.

​
Capacidades

​
Requisitos previos

1

Acceso a Microsoft Defender / Entra ID

Un inquilino de Microsoft Entra ID (Azure AD) con Microsoft Defender XDR o Microsoft Defender para Endpoint con licencia y habilitado. Necesita permiso para registrar aplicaciones y conceder el consentimiento del administrador.
2

Salida de red

El despliegue de CaseBender debe poder alcanzar:
  • https://login.microsoftonline.com (endpoint de token OAuth2)
  • https://graph.microsoft.com (API de seguridad de Graph)
3

Rol de administrador de CaseBender

Debe poder crear y gestionar integraciones en Configuración → Integraciones.

​
Parte A — Registrar una aplicación de Azure AD

1

Crear el registro de la aplicación

En el centro de administración de Microsoft Entra, vaya a Identidad → Aplicaciones → Registros de aplicaciones → Nuevo registro. Asígnele un nombre (p. ej. CaseBender Defender Integration) y regístrela.
2

Registrar los identificadores

Desde Información general de la aplicación, copie el ID de aplicación (cliente) y el ID de directorio (inquilino). Los introducirá en CaseBender.
3

Crear un secreto de cliente

En Certificados y secretos → Nuevo secreto de cliente, cree un secreto y copie su Valor de inmediato (solo se muestra una vez).
4

Conceder permisos de la API de seguridad de Graph

En Permisos de API → Agregar un permiso → Microsoft Graph → Permisos de aplicación, agregue los ámbitos para la(s) dirección(es) que necesite y luego haga clic en Conceder consentimiento de administrador:
El acceso de solo lectura es suficiente para el sondeo. Si solo extrae incidentes/alertas hacia CaseBender, conceda los dos ámbitos Read.All. Los ámbitos ReadWrite.All son necesarios solo para el cierre inverso de salida opcional (syncCaseClose) — cerrar una alerta/incidente de Defender desde CaseBender. Dado que ReadWrite.All también incluye acceso de lectura, conceder únicamente los dos ámbitos ReadWrite.All cubre ambas direcciones.
Use permisos de Aplicación (no Delegados). La integración se ejecuta sin interacción con el flujo de credenciales de cliente y requiere el consentimiento del administrador del inquilino.

​
Parte B — Configurar la integración en CaseBender

1

Abrir el catálogo de integraciones

Vaya a Configuración → Integraciones → Crear y elija Microsoft Defender XDR en la categoría EDR/XDR.
2

Introducir las credenciales de Azure AD

Proporcione los valores obtenidos en la Parte A:
3

Habilitar el sondeo automático (recomendado)

En la tarjeta Sondeo automático, active Habilitar el sondeo automático y configure:Consulte Sondeo automático para saber cómo funciona.
4

Configurar las opciones de sincronización

Habilite los comportamientos que necesite:
Con syncCaseClose activado pero ambos conmutadores close…OnCaseClose desactivados, CaseBender igualmente escribe la clasificación y el comentario de auditoría en Defender: simplemente no cambia el estado de la entidad de Defender a resolved.
5

Probar la conexión

Use Probar conexión para validar. CaseBender solicita un token OAuth2 y llama a GET /security/alerts_v2?$top=1.
Una respuesta 403 durante la prueba se considera correcta: confirma que la autenticación funcionó incluso cuando la aplicación aún no tiene permiso de lectura en ese endpoint específico.

​
Entrante (sondeo automático, recomendado)

Con el sondeo automático activado (en la tarjeta Sondeo automático de la integración), CaseBender llama periódicamente a la API de seguridad de Graph e ingiere los nuevos incidentes por sí solo, sin necesidad de una Logic App, una regla de automatización de Sentinel ni un reenviador de webhooks del lado de Microsoft. Solo se requiere el registro de aplicación de Azure AD de la Parte A.
  • Extracción programada — cada pollingIntervalMinutes, CaseBender obtiene los incidentes con lastUpdateDateTime gt <cursor> y $expand=alerts, ordenados del más antiguo al más reciente. En la primera ejecución importa los incidentes actualizados dentro de pollingInitialLookbackHours.
  • Cursor y deduplicación — un cursor por integración avanza hasta el incidente más reciente visto, y los incidentes se deduplican por ID de incidente de Defender, por lo que nada se ingiere dos veces.
  • Normalización — cada incidente y sus alertas secundarias se convierten en una alerta de CaseBender con observables, activos y TTP de MITRE. El ID de incidente de Defender se registra en la alerta para que la sincronización de cierre saliente pueda localizarlo.
Requiere SecurityIncident.Read.All (incluido en SecurityIncident.ReadWrite.All). Con autoCreateCases activado, cada incidente sondeado se convierte automáticamente en un Caso (deduplicado por ID de incidente); si está desactivado, aparecen en la bandeja de Alertas para promoción manual. En ambos casos el vínculo con Defender se conserva para que al cerrar el caso se sincronice de vuelta.

​
Entrante (webhook / envío)

​
Endpoint

Defender (o un intermediario como Logic Apps, Sentinel o un reenviador de webhooks) envía las cargas de alertas/incidentes al endpoint de ingesta de CaseBender:
Las solicitudes se autentican con una clave de API de integración en el encabezado x-api-key (también se acepta el encabezado authorization: Bearer <clave>). Las claves de API de webhook de Defender llevan el prefijo cbr_defender_.

​
Formatos de carga

Se admiten tanto el formato por lotes (array value[] de Graph) como un objeto de alerta única.
Una solicitud correcta devuelve HTTP 202 Accepted:

​
Flujo de procesamiento

1

Proxy de ingesta

/api/v1/ingest/defender valida el origen y reenvía la solicitud al servicio de ingesta (POST /v1/sources/defender).
2

Publicación en cola

El servicio de ingesta autentica la clave de API, valida la carga y publica cada alerta en la cola de procesamiento.
3

Normalización

El procesador de Defender normaliza cada registro en una alerta de CaseBender: asigna la severidad, construye el título/descripción, extrae observables y activos de dispositivo y genera TTP de MITRE.

​
Referencia de mapeo de datos

Mapeo de severidad (Defender → CaseBender 1–4): Extracción de observables (desde evidence[]): Las etiquetas aplicadas en la ingesta incluyen defender, xdr, service:<serviceSource>, category:<category>, incident (para incidentes) y una etiqueta mitre:<technique> por cada técnica de MITRE. Los registros ingeridos usan por defecto TLP:2 y PAP:2.

​
Saliente: Sincronizar disposiciones de casos con Defender

Cuando se cierra un caso en CaseBender, el evento case_closed se despacha al controlador de Defender. Si el caso está vinculado a una alerta o incidente de Defender, CaseBender envía la resolución a través de la API de seguridad de Graph.

​
Cómo se resuelve la entidad vinculada de Defender

El controlador busca los identificadores de Defender en este orden:
  1. extraData.defenderAlertId / extraData.defenderIncidentId en el caso
  2. sourceRef cuando extraData.source === "defender"
  3. La(s) alerta(s) de Defender vinculada(s) al caso — el pipeline de ingesta registra el ID de incidente/alerta de Defender en los customFields de cada alerta, por lo que un caso promovido desde una alerta de Defender (sondeada o por webhook) se resuelve automáticamente, independientemente de cómo se creó.
Si no se encuentra ningún ID de alerta o incidente, se omite el cierre del caso para esta integración.

​
Mapeo de resolución → clasificación

Al cerrar, CaseBender aplica la classification mapeada y agrega un comentario como:
Además, establece el status de la entidad de Defender en resolved cuando el conmutador correspondiente (closeAlertsOnCaseClose para alertas, closeIncidentsOnCaseClose para incidentes) está habilitado. El resultado se escribe en la línea de tiempo del caso para que los analistas puedan confirmar la sincronización.
syncCaseClose es el interruptor principal de la sincronización saliente (activado por defecto). Cuando está desactivado, no se realizan llamadas salientes. Las actualizaciones de alertas usan el endpoint moderno /security/alerts_v2/{id}; las de incidentes usan /security/incidents/{id}.

​
Consideraciones de seguridad

  • Manejo de secretos — el secreto de cliente se almacena en la configuración de la integración; rótelo según lo requiera su organización y actualice la integración al hacerlo.
  • Privilegio mínimo — para implementaciones solo de entrada, conceda únicamente SecurityAlert.Read.All y SecurityIncident.Read.All; agregue los ámbitos ReadWrite.All correspondientes solo si habilita el cierre inverso de salida. No agregue otros permisos de Graph.
  • Almacenamiento en caché de tokens — los tokens de acceso se almacenan en memoria por integración y se actualizan un minuto antes de expirar; no se guardan en disco.
  • Claves de webhook — trate la clave de API cbr_defender_ como un secreto. Rótela si se expone y actualice la configuración del remitente.
  • Red — restrinja la salida a login.microsoftonline.com y graph.microsoft.com.

​
Solución de problemas

Verifique tenantId, clientId y clientSecret. Confirme que el secreto de cliente no ha expirado y que se concedió el consentimiento del administrador para los permisos de la aplicación de Graph.
Falta el encabezado x-api-key o no es válido. Confirme que envía la clave cbr_defender_ que coincide con la clave de API de webhook configurada de la integración.
La carga no tenía ni un array value[] ni un id de nivel superior. Envíe un objeto por lotes de Graph o un objeto de alerta única.
Confirme que Habilitar el sondeo automático esté activado y que la prueba de conexión sea correcta. Verifique que la aplicación tenga SecurityIncident.Read.All (o ReadWrite.All) con consentimiento del administrador, que el servicio de sondeo pueda alcanzar graph.microsoft.com (y su proxy, si lo hay), y que existan incidentes más recientes que el cursor. En la primera ejecución solo se importan los incidentes dentro de pollingInitialLookbackHours. Los incidentes sondeados aparecen en la bandeja de Alertas.Asegúrese de que todos los servicios de CaseBender estén en ejecución. Los incidentes los obtiene el procesador en segundo plano y el worker en segundo plano los convierte en alertas (y opcionalmente en casos). Si el worker no está en ejecución, los incidentes se obtienen pero nunca aparecen. Con Docker, ejecute docker compose ps y confirme que los servicios worker y misp-processor estén Up; si no, ejecute docker compose up -d. El instalador estándar y la guía de inicio rápido configuran todo automáticamente: no necesita configurar ningún ajuste de cola ni de Redis por su cuenta.
Asegúrese de que syncCaseClose esté activado (es el interruptor principal). Para además marcar la entidad de Defender como resolved, habilite closeAlertsOnCaseClose / closeIncidentsOnCaseClose. El caso debe estar vinculado a una alerta/incidente de Defender — al cerrar un caso promovido desde una alerta de Defender (sondeada o por webhook) el vínculo se resuelve automáticamente. Revise la línea de tiempo del caso para ver el resultado.
Un 403 significa que la aplicación de Azure AD carece de permiso de escritura: confirme que SecurityAlert.ReadWrite.All y SecurityIncident.ReadWrite.All estén concedidos con consentimiento del administrador. Un 404 en la actualización de una alerta suele indicar un endpoint heredado; CaseBender usa /security/alerts_v2/{id} para las alertas modernas de Defender XDR.

​
Documentación relacionada