Microsoft Defender XDR

Vue d’ensemble

L’intégration Microsoft Defender XDR (INT-021) assure une synchronisation bidirectionnelle entre CaseBender et la plateforme de détection et de réponse étendues de Microsoft, y compris Microsoft Defender pour point de terminaison (MDE) et Microsoft Defender XDR.

Ingestion entrante

Les alertes et incidents Defender sont ingérés dans CaseBender, normalisés, enrichis d’observables et de techniques MITRE ATT&CK, puis transformés en alertes/dossiers.

Synchronisation sortante

Lorsqu’un dossier CaseBender est clôturé, l’alerte/incident Defender lié est mis à jour avec le statut, la classification et un commentaire d’audit via Microsoft Graph.

Cette intégration utilise l’API de sécurité Microsoft Graph (https://graph.microsoft.com/v1.0/security). Elle s’authentifie avec une application Azure AD (Entra ID) via le flux d’identifiants client OAuth2.

Fonctionnalités

Fonctionnalité	Direction	Description
Interrogation d’incidents (pull)	Entrant	CaseBender interroge l’API de sécurité Graph selon un calendrier et ingère automatiquement les nouveaux incidents, sans configuration côté Microsoft
Ingestion d’alertes (push)	Entrant	Les alertes Defender sont envoyées par webhook et normalisées en alertes CaseBender
Ingestion d’incidents	Entrant	Les incidents Defender (avec alertes enfants) sont ingérés
Extraction d’observables	Entrant	IP, URL, empreintes de fichiers, noms de fichiers, hostnames et comptes utilisateurs sont extraits des preuves
Extraction d’actifs	Entrant	Hostname, IP et plateforme OS de l’appareil sont capturés depuis `devices[]`
Corrélation MITRE ATT&CK	Entrant	Les identifiants de technique sont ajoutés comme étiquettes et TTP (p. ex. `mitre:T1078`)
Synchronisation d’alertes	Sortant	`status`, `classification`, `determination` et commentaires sont envoyés à la clôture du dossier
Synchronisation d’incidents	Sortant	`status`, `classification`, `determination` et commentaires sont envoyés à la clôture du dossier
Test de connexion	Bidirectionnel	Valide les identifiants OAuth2 et l’accès à l’API de sécurité Graph

Prérequis

Accès à Microsoft Defender / Entra ID

Un locataire Microsoft Entra ID (Azure AD) avec Microsoft Defender XDR ou Microsoft Defender pour point de terminaison sous licence et activé. Vous devez pouvoir enregistrer des applications et accorder le consentement administrateur.

Sortie réseau

Le déploiement CaseBender doit pouvoir atteindre :

https://login.microsoftonline.com (endpoint de jeton OAuth2)
https://graph.microsoft.com (API de sécurité Graph)

Rôle administrateur CaseBender

Vous devez pouvoir créer et gérer des intégrations dans Paramètres → Intégrations.

Partie A — Enregistrer une application Azure AD

Créer l'enregistrement d'application

Dans le centre d’administration Microsoft Entra, allez à Identité → Applications → Inscriptions d’applications → Nouvelle inscription. Donnez-lui un nom (p. ex. CaseBender Defender Integration) et enregistrez-la.

Noter les identifiants

Depuis la Vue d’ensemble de l’application, copiez l’ID d’application (client) et l’ID de répertoire (locataire). Vous les saisirez dans CaseBender.

Créer un secret client

Sous Certificats et secrets → Nouveau secret client, créez un secret et copiez sa Valeur immédiatement (elle n’est affichée qu’une fois).

Accorder les autorisations de l'API de sécurité Graph

Sous Autorisations d’API → Ajouter une autorisation → Microsoft Graph → Autorisations d’application, ajoutez les portées correspondant à la ou aux directions dont vous avez besoin, puis cliquez sur Accorder le consentement administrateur :

Autorisation	Requise pour	Objectif
`SecurityAlert.Read.All`	Entrée (interrogation / ingestion)	Lire les alertes Defender
`SecurityIncident.Read.All`	Entrée (interrogation / ingestion)	Lire les incidents Defender
`SecurityAlert.ReadWrite.All`	Sortie (clôture inverse)	Lire et mettre à jour les alertes Defender à la clôture du cas
`SecurityIncident.ReadWrite.All`	Sortie (clôture inverse)	Lire et mettre à jour les incidents Defender à la clôture du cas

L’accès en lecture seule suffit pour l’interrogation. Si vous ne faites qu’extraire des incidents/alertes vers CaseBender, accordez les deux portées Read.All. Les portées ReadWrite.All ne sont requises que pour la clôture inverse sortante optionnelle (syncCaseClose) — clôturer une alerte/incident Defender depuis CaseBender. Comme ReadWrite.All inclut également l’accès en lecture, accorder uniquement les deux portées ReadWrite.All couvre les deux directions.

Utilisez des autorisations d’Application (et non déléguées). L’intégration s’exécute sans interface avec le flux d’identifiants client et nécessite le consentement de l’administrateur du locataire.

Partie B — Configurer l’intégration dans CaseBender

Ouvrir le catalogue d'intégrations

Allez à Paramètres → Intégrations → Créer, puis choisissez Microsoft Defender XDR dans la catégorie EDR/XDR.

Saisir les identifiants Azure AD

Fournissez les valeurs obtenues dans la Partie A :

Champ	Description
`tenantId`	ID de répertoire (locataire)
`clientId`	ID d’application (client)
`clientSecret`	Valeur du secret client

Activer l'interrogation automatique (recommandé)

Dans la carte Interrogation automatique, activez Activer l’interrogation automatique et définissez :

Option	Effet
`pollingEnabled`	Activer l’extraction planifiée des incidents Defender
`pollingIntervalMinutes`	Fréquence d’interrogation (par défaut `5`, plage 1–1440)
`pollingInitialLookbackHours`	À la première exécution, importer les incidents mis à jour dans cette fenêtre (par défaut `24`, plage 1–168)

Voir Interrogation automatique pour le fonctionnement.

Configurer les options de synchronisation

Activez les comportements nécessaires :

Option	Effet
`syncCaseClose`	Commutateur principal de la synchronisation sortante. Lorsqu’il est activé (par défaut), la clôture d’un dossier lié envoie la classification + un commentaire d’audit à Defender
`closeAlertsOnCaseClose`	Définir en plus le statut de l’alerte Defender liée sur `resolved`
`closeIncidentsOnCaseClose`	Définir en plus le statut de l’incident Defender lié sur `resolved`
`autoCreateCases`	Promouvoir automatiquement chaque enregistrement Defender ingéré en dossier (dédupliqué par ID d’incident). Lorsqu’il est désactivé, les enregistrements restent dans la boîte de réception des Alertes pour une promotion manuelle

Avec syncCaseClose activé mais les deux commutateurs close…OnCaseClose désactivés, CaseBender écrit tout de même la classification et le commentaire d’audit dans Defender : il ne fait simplement pas passer l’entité Defender à resolved.

Tester la connexion

Utilisez Tester la connexion pour valider. CaseBender demande un jeton OAuth2 et appelle GET /security/alerts_v2?$top=1.

Une réponse 403 pendant le test est considérée comme un succès : elle confirme que l’authentification a fonctionné même lorsque l’application n’a pas encore obtenu la portée de lecture sur cet endpoint précis.

Entrant (interrogation automatique, recommandé)

Lorsque l’interrogation automatique est activée (dans la carte Interrogation automatique de l’intégration), CaseBender appelle périodiquement l’API de sécurité Graph et ingère lui-même les nouveaux incidents — sans Logic App, règle d’automatisation Sentinel ni transitaire de webhook du côté Microsoft. Seul l’enregistrement d’application Azure AD de la Partie A est nécessaire.

Extraction planifiée — à chaque pollingIntervalMinutes, CaseBender récupère les incidents avec lastUpdateDateTime gt <cursor> et $expand=alerts, du plus ancien au plus récent. Lors de la première exécution, il importe les incidents mis à jour dans la fenêtre pollingInitialLookbackHours.
Curseur et déduplication — un curseur par intégration avance jusqu’au dernier incident vu, et les incidents sont dédupliqués par ID d’incident Defender, de sorte que rien n’est ingéré deux fois.
Normalisation — chaque incident et ses alertes enfants deviennent une alerte CaseBender avec observables, actifs et TTP MITRE. L’ID d’incident Defender est inscrit sur l’alerte afin que la synchronisation de clôture sortante puisse le retrouver.

Nécessite SecurityIncident.Read.All (couvert par SecurityIncident.ReadWrite.All). Avec autoCreateCases activé, chaque incident interrogé devient automatiquement un dossier (dédupliqué par ID d’incident) ; s’il est désactivé, les incidents arrivent dans la boîte de réception des Alertes pour une promotion manuelle. Dans les deux cas, le lien Defender est conservé afin que la clôture du dossier puisse se synchroniser en retour.

Entrant (webhook / envoi)

Endpoint

Defender (ou un intermédiaire tel que Logic Apps, Sentinel ou un relais de webhooks) envoie les charges utiles d’alertes/incidents à l’endpoint d’ingestion CaseBender :

POST https://<votre-domaine-casebender>/api/v1/ingest/defender

Les requêtes sont authentifiées avec une clé d’API d’intégration dans l’en-tête x-api-key (l’en-tête authorization: Bearer <clé> est également accepté). Les clés d’API de webhook Defender ont le préfixe cbr_defender_.

Formats de charge utile

Le format par lots (tableau value[] de Graph) et l’objet d’alerte unique sont tous deux pris en charge.

curl -X POST "https://<votre-domaine-casebender>/api/v1/ingest/defender" \
  -H "x-api-key: cbr_defender_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" \
  -H "Content-Type: application/json" \
  -d '{
    "value": [
      {
        "id": "da637...",
        "incidentId": "12345",
        "title": "Exécution PowerShell suspecte",
        "severity": "high",
        "status": "new",
        "classification": "unknown",
        "createdDateTime": "2026-07-03T18:20:00Z",
        "mitreTechniques": ["T1059.001"],
        "evidence": [
          { "@odata.type": "#microsoft.graph.security.fileEvidence",
            "sha256": "9f2b...", "fileName": "payload.ps1" }
        ]
      }
    ]
  }'

curl -X POST "https://<votre-domaine-casebender>/api/v1/ingest/defender" \
  -H "x-api-key: cbr_defender_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" \
  -H "Content-Type: application/json" \
  -d '{
    "id": "da637...",
    "title": "Logiciel malveillant détecté sur le point de terminaison",
    "severity": "medium",
    "status": "new",
    "createdDateTime": "2026-07-03T18:20:00Z"
  }'

Une requête réussie renvoie HTTP 202 Accepted :

{ "success": true, "processed": 1, "failed": 0 }

Pipeline de traitement

Proxy d'ingestion

/api/v1/ingest/defender valide la source et transmet la requête au service d’ingestion (POST /v1/sources/defender).

Publication en file d'attente

Le service d’ingestion authentifie la clé d’API, valide la charge utile et publie chaque alerte dans la file de traitement.

Normalisation

Le processeur Defender normalise chaque enregistrement en une alerte CaseBender : mappage de la gravité, construction du titre/description, extraction des observables et actifs d’appareil, et génération des TTP MITRE.

Référence de mappage des données

Mappage de la gravité (Defender → CaseBender 1–4) :

Gravité Defender	Gravité CaseBender
`high`	1
`medium`	2
`low`	3
`informational`	4
`unknown`	3

Extraction des observables (depuis evidence[]) :

Champ de preuve	Type d’observable
`ipAddress`	`ip`
`url`	`url`
`sha256`	`hash`
`fileName`	`filename`
`deviceDnsName`	`hostname`
`userAccount`	`user` (`DOMAINE\compte`)

Les étiquettes appliquées à l’ingestion incluent defender, xdr, service:<serviceSource>, category:<category>, incident (pour les incidents) et une étiquette mitre:<technique> par technique MITRE. Les enregistrements ingérés utilisent par défaut TLP:2 et PAP:2.

Sortant : Synchroniser les dispositions de dossiers vers Defender

Lorsqu’un dossier est clôturé dans CaseBender, l’événement case_closed est envoyé au gestionnaire Defender. Si le dossier est lié à une alerte ou un incident Defender, CaseBender renvoie la résolution via l’API de sécurité Graph.

Comment l’entité Defender liée est résolue

Le gestionnaire recherche les identifiants Defender dans cet ordre :

extraData.defenderAlertId / extraData.defenderIncidentId sur le dossier
sourceRef lorsque extraData.source === "defender"
La ou les alertes Defender liées au dossier — le pipeline d’ingestion inscrit l’ID d’incident/d’alerte Defender dans les customFields de chaque alerte ; un dossier promu depuis une alerte Defender (interrogée ou par webhook) est donc résolu automatiquement, quelle que soit la façon dont il a été créé.

Si aucun ID d’alerte ou d’incident n’est trouvé, la clôture du dossier est ignorée pour cette intégration.

Mappage résolution → classification

Résolution CaseBender	Classification Defender
`TruePositive`	`truePositive`
`FalsePositive`	`falsePositive`
`Duplicate`	`informationalExpectedActivity`
`NoImpact`	`informationalExpectedActivity`
(autre / aucune)	`truePositive` (par défaut)

À la clôture, CaseBender applique la classification mappée et ajoute un commentaire tel que :

Case closed in CaseBender with resolution: <résolution>

Il définit en plus le status de l’entité Defender sur resolved lorsque le commutateur correspondant (closeAlertsOnCaseClose pour les alertes, closeIncidentsOnCaseClose pour les incidents) est activé. Le résultat est écrit dans la chronologie du dossier afin que les analystes puissent confirmer la synchronisation.

syncCaseClose est le commutateur principal de la synchronisation sortante (activé par défaut). Lorsqu’il est désactivé, aucun appel sortant n’est effectué. Les mises à jour d’alertes utilisent l’endpoint moderne /security/alerts_v2/{id} ; celles d’incidents utilisent /security/incidents/{id}.

Considérations de sécurité

Gestion des secrets — le secret client est stocké dans les paramètres de l’intégration ; faites-le pivoter selon les exigences de votre organisation et mettez à jour l’intégration.
Moindre privilège — pour les déploiements en entrée uniquement, accordez seulement SecurityAlert.Read.All et SecurityIncident.Read.All ; ajoutez les portées ReadWrite.All correspondantes uniquement si vous activez la clôture inverse sortante. N’ajoutez pas d’autres portées Graph.
Mise en cache des jetons — les jetons d’accès sont mis en cache en mémoire par intégration et actualisés une minute avant expiration ; aucun jeton n’est persisté sur disque.
Clés de webhook — traitez la clé d’API cbr_defender_ comme un secret. Faites-la pivoter en cas d’exposition et mettez à jour la configuration de l’expéditeur.
Réseau — limitez la sortie à login.microsoftonline.com et graph.microsoft.com.

Dépannage

Le test de connexion échoue avec une erreur OAuth2

Vérifiez tenantId, clientId et clientSecret. Confirmez que le secret client n’a pas expiré et que le consentement administrateur a été accordé pour les autorisations d’application Graph.

L'ingestion renvoie 401 Unauthorized

L’en-tête x-api-key est manquant ou invalide. Confirmez que vous envoyez la clé cbr_defender_ qui correspond à la clé d’API de webhook configurée de l’intégration.

L'ingestion renvoie 400 'No alerts in payload'

La charge utile ne contenait ni tableau value[] ni id de premier niveau. Envoyez un objet par lots Graph ou un objet d’alerte unique.

L'interrogation est activée mais aucun incident n'apparaît

Confirmez que Activer l’interrogation automatique est activé et que le test de connexion réussit. Vérifiez que l’application dispose de SecurityIncident.Read.All (ou ReadWrite.All) avec consentement administrateur, que le service d’interrogation peut atteindre graph.microsoft.com (et votre proxy le cas échéant), et qu’il existe des incidents plus récents que le curseur. À la première exécution, seuls les incidents dans pollingInitialLookbackHours sont importés. Les incidents interrogés arrivent dans la boîte de réception des Alertes.Assurez-vous que tous les services CaseBender sont en cours d’exécution. Les incidents sont récupérés par le processeur en arrière-plan puis transformés en alertes (et éventuellement en dossiers) par le worker en arrière-plan. Si le worker n’est pas en cours d’exécution, les incidents sont récupérés mais n’apparaissent jamais. Avec Docker, exécutez docker compose ps et vérifiez que les services worker et misp-processor sont Up ; sinon, exécutez docker compose up -d. L’installateur standard et le guide de démarrage rapide configurent tout automatiquement : vous n’avez aucun paramètre de file d’attente ou Redis à configurer vous-même.

La clôture du dossier ne met pas à jour Defender

Assurez-vous que syncCaseClose est activé (c’est le commutateur principal). Pour marquer aussi l’entité Defender comme resolved, activez closeAlertsOnCaseClose / closeIncidentsOnCaseClose. Le dossier doit être lié à une alerte/incident Defender — la clôture d’un dossier promu depuis une alerte Defender (interrogée ou par webhook) résout le lien automatiquement. Consultez la chronologie du dossier pour le résultat.

La mise à jour sortante renvoie 403 ou 404

Un 403 signifie que l’application Azure AD n’a pas d’autorisation d’écriture — confirmez que SecurityAlert.ReadWrite.All et SecurityIncident.ReadWrite.All sont accordés avec le consentement administrateur. Un 404 sur la mise à jour d’une alerte indique généralement un endpoint hérité ; CaseBender utilise /security/alerts_v2/{id} pour les alertes modernes de Defender XDR.

Mise en Route

Déploiement

Gestion des Alertes

Gestion des Dossiers

Gestion des Tâches

Analytique

Audits

Paramètres

Microsoft Defender XDR

Vue d’ensemble

Ingestion entrante

Synchronisation sortante

Fonctionnalités

Prérequis

Partie A — Enregistrer une application Azure AD

Partie B — Configurer l’intégration dans CaseBender

Entrant (interrogation automatique, recommandé)

Entrant (webhook / envoi)

Endpoint

Formats de charge utile

Pipeline de traitement

Référence de mappage des données

Sortant : Synchroniser les dispositions de dossiers vers Defender

Comment l’entité Defender liée est résolue

Mappage résolution → classification

Considérations de sécurité

Dépannage

Documentation associée

​Vue d’ensemble

Ingestion entrante

Synchronisation sortante

​Fonctionnalités

​Prérequis

​Partie A — Enregistrer une application Azure AD

​Partie B — Configurer l’intégration dans CaseBender

​Entrant (interrogation automatique, recommandé)

​Entrant (webhook / envoi)

​Endpoint

​Formats de charge utile

​Pipeline de traitement

​Référence de mappage des données

​Sortant : Synchroniser les dispositions de dossiers vers Defender

​Comment l’entité Defender liée est résolue

​Mappage résolution → classification

​Considérations de sécurité

​Dépannage

​Documentation associée

Vue d’ensemble

Fonctionnalités

Prérequis

Partie A — Enregistrer une application Azure AD

Partie B — Configurer l’intégration dans CaseBender

Entrant (interrogation automatique, recommandé)

Entrant (webhook / envoi)

Endpoint

Formats de charge utile

Pipeline de traitement

Référence de mappage des données

Sortant : Synchroniser les dispositions de dossiers vers Defender

Comment l’entité Defender liée est résolue

Mappage résolution → classification

Considérations de sécurité

Dépannage

Documentation associée