Microsoft Defender XDR

Panoramica

L’integrazione Microsoft Defender XDR (INT-021) fornisce sincronizzazione bidirezionale tra CaseBender e la piattaforma di rilevamento e risposta estesi di Microsoft, inclusi Microsoft Defender per endpoint (MDE) e Microsoft Defender XDR.

Acquisizione in entrata

Gli avvisi e gli incidenti di Defender vengono acquisiti in CaseBender, normalizzati, arricchiti con osservabili e tecniche MITRE ATT&CK e trasformati in avvisi/casi.

Sincronizzazione in uscita

Quando un caso di CaseBender viene chiuso, l’avviso/incidente Defender collegato viene aggiornato con stato, classificazione e un commento di audit tramite Microsoft Graph.

Questa integrazione utilizza l’API di sicurezza di Microsoft Graph (https://graph.microsoft.com/v1.0/security). Si autentica con un’applicazione Azure AD (Entra ID) tramite il flusso di credenziali client OAuth2.

Funzionalità

Funzionalità	Direzione	Descrizione
Polling degli incidenti (pull)	In entrata	CaseBender interroga l’API di sicurezza di Graph a intervalli regolari e acquisisce automaticamente i nuovi incidenti, senza configurazione lato Microsoft
Acquisizione avvisi (push)	In entrata	Gli avvisi Defender vengono inviati via webhook e normalizzati in avvisi CaseBender
Acquisizione incidenti	In entrata	Vengono acquisiti gli incidenti Defender (con avvisi figli)
Estrazione osservabili	In entrata	IP, URL, hash di file, nomi file, hostname e account utente vengono estratti dalle prove
Estrazione asset	In entrata	Hostname, IP e piattaforma OS del dispositivo vengono acquisiti da `devices[]`
Correlazione MITRE ATT&CK	In entrata	Gli ID tecnica vengono aggiunti come tag e TTP (es. `mitre:T1078`)
Sincronizzazione avvisi	In uscita	`status`, `classification`, `determination` e commenti vengono inviati alla chiusura del caso
Sincronizzazione incidenti	In uscita	`status`, `classification`, `determination` e commenti vengono inviati alla chiusura del caso
Test di connessione	Bidirezionale	Convalida le credenziali OAuth2 e l’accesso all’API di sicurezza di Graph

Prerequisiti

Accesso a Microsoft Defender / Entra ID

Un tenant Microsoft Entra ID (Azure AD) con Microsoft Defender XDR o Microsoft Defender per endpoint concesso in licenza e abilitato. È necessario il permesso per registrare applicazioni e concedere il consenso dell’amministratore.

Uscita di rete

Il deployment di CaseBender deve poter raggiungere:

https://login.microsoftonline.com (endpoint token OAuth2)
https://graph.microsoft.com (API di sicurezza di Graph)

Ruolo di amministratore CaseBender

Devi poter creare e gestire integrazioni in Impostazioni → Integrazioni.

Parte A — Registrare un’applicazione Azure AD

Creare la registrazione dell'app

Nel centro di amministrazione Microsoft Entra, vai a Identità → Applicazioni → Registrazioni app → Nuova registrazione. Assegnale un nome (es. CaseBender Defender Integration) e registrala.

Annotare gli identificatori

Dalla Panoramica dell’applicazione, copia l’ID applicazione (client) e l’ID directory (tenant). Li inserirai in CaseBender.

Creare un secret client

In Certificati e segreti → Nuovo secret client, crea un secret e copia subito il suo Valore (viene mostrato una sola volta).

Concedere le autorizzazioni dell'API di sicurezza di Graph

In Autorizzazioni API → Aggiungi autorizzazione → Microsoft Graph → Autorizzazioni applicazione, aggiungi gli ambiti per la direzione o le direzioni necessarie e poi fai clic su Concedi consenso amministratore:

Autorizzazione	Necessaria per	Scopo
`SecurityAlert.Read.All`	In entrata (polling / ingestione)	Leggere gli avvisi Defender
`SecurityIncident.Read.All`	In entrata (polling / ingestione)	Leggere gli incidenti Defender
`SecurityAlert.ReadWrite.All`	In uscita (chiusura inversa)	Leggere e aggiornare gli avvisi Defender alla chiusura del caso
`SecurityIncident.ReadWrite.All`	In uscita (chiusura inversa)	Leggere e aggiornare gli incidenti Defender alla chiusura del caso

L’accesso in sola lettura è sufficiente per il polling. Se estrai solo incidenti/avvisi in CaseBender, concedi i due ambiti Read.All. Gli ambiti ReadWrite.All sono necessari solo per la chiusura inversa in uscita facoltativa (syncCaseClose) — chiudere un avviso/incidente Defender da CaseBender. Poiché ReadWrite.All include anche l’accesso in lettura, concedere solo i due ambiti ReadWrite.All copre entrambe le direzioni.

Usa autorizzazioni di Applicazione (non delegate). L’integrazione viene eseguita senza interazione con il flusso di credenziali client e richiede il consenso dell’amministratore del tenant.

Parte B — Configurare l’integrazione in CaseBender

Aprire il catalogo delle integrazioni

Vai a Impostazioni → Integrazioni → Crea, quindi scegli Microsoft Defender XDR dalla categoria EDR/XDR.

Inserire le credenziali Azure AD

Fornisci i valori acquisiti nella Parte A:

Campo	Descrizione
`tenantId`	ID directory (tenant)
`clientId`	ID applicazione (client)
`clientSecret`	Valore del secret client

Abilitare il polling automatico (consigliato)

Nella scheda Polling automatico, attiva Abilita il polling automatico e imposta:

Opzione	Effetto
`pollingEnabled`	Attivare l’estrazione pianificata degli incidenti Defender
`pollingIntervalMinutes`	Frequenza di polling (predefinito `5`, intervallo 1–1440)
`pollingInitialLookbackHours`	Alla prima esecuzione, importare gli incidenti aggiornati entro questa finestra (predefinito `24`, intervallo 1–168)

Consulta Polling automatico per il funzionamento.

Configurare le opzioni di sincronizzazione

Abilita i comportamenti necessari:

Opzione	Effetto
`syncCaseClose`	Interruttore principale della sincronizzazione in uscita. Quando è attivo (predefinito), la chiusura di un caso collegato invia la classificazione + un commento di audit a Defender
`closeAlertsOnCaseClose`	Impostare inoltre lo stato dell’avviso Defender collegato su `resolved`
`closeIncidentsOnCaseClose`	Impostare inoltre lo stato dell’incidente Defender collegato su `resolved`
`autoCreateCases`	Promuovere automaticamente ogni record Defender acquisito a un Caso (deduplicato per ID incidente). Quando è disattivato, i record restano nella casella Avvisi per la promozione manuale

Con syncCaseClose attivo ma entrambi gli interruttori close…OnCaseClose disattivati, CaseBender scrive comunque la classificazione e il commento di audit in Defender: semplicemente non porta l’entità Defender a resolved.

Testare la connessione

Usa Testa connessione per convalidare. CaseBender richiede un token OAuth2 e chiama GET /security/alerts_v2?$top=1.

Una risposta 403 durante il test è considerata un successo: conferma che l’autenticazione ha funzionato anche quando l’app non dispone ancora dell’ambito di lettura su quello specifico endpoint.

In entrata (polling automatico, consigliato)

Con il polling automatico attivato (nella scheda Polling automatico dell’integrazione), CaseBender chiama periodicamente l’API di sicurezza Graph e acquisisce da solo i nuovi incidenti — senza alcuna Logic App, regola di automazione di Sentinel o inoltro webhook sul lato Microsoft. È necessaria solo la registrazione dell’applicazione Azure AD della Parte A.

Estrazione pianificata — a ogni pollingIntervalMinutes, CaseBender recupera gli incidenti con lastUpdateDateTime gt <cursor> e $expand=alerts, dal più vecchio al più recente. Alla prima esecuzione importa gli incidenti aggiornati entro pollingInitialLookbackHours.
Cursore e deduplica — un cursore per integrazione avanza fino all’incidente più recente visto e gli incidenti vengono deduplicati per ID incidente di Defender, quindi nulla viene acquisito due volte.
Normalizzazione — ogni incidente e i relativi avvisi figli diventano un avviso di CaseBender con osservabili, asset e TTP MITRE. L’ID incidente di Defender viene registrato sull’avviso in modo che la sincronizzazione di chiusura in uscita possa individuarlo.

Richiede SecurityIncident.Read.All (incluso in SecurityIncident.ReadWrite.All). Con autoCreateCases attivato, ogni incidente acquisito tramite polling diventa automaticamente un Caso (deduplicato per ID incidente); se disattivato, gli incidenti compaiono nella casella Avvisi per la promozione manuale. In entrambi i casi il collegamento con Defender viene conservato affinché la chiusura del caso possa sincronizzarsi a ritroso.

In entrata (webhook / push)

Endpoint

Defender (o un intermediario come Logic Apps, Sentinel o un forwarder di webhook) invia i payload di avvisi/incidenti all’endpoint di acquisizione di CaseBender:

POST https://<il-tuo-dominio-casebender>/api/v1/ingest/defender

Le richieste vengono autenticate con una chiave API di integrazione nell’header x-api-key (è accettato anche l’header authorization: Bearer <chiave>). Le chiavi API dei webhook Defender hanno il prefisso cbr_defender_.

Formati del payload

Sono supportati sia il formato batch (array value[] di Graph) sia un oggetto di avviso singolo.

curl -X POST "https://<il-tuo-dominio-casebender>/api/v1/ingest/defender" \
  -H "x-api-key: cbr_defender_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" \
  -H "Content-Type: application/json" \
  -d '{
    "value": [
      {
        "id": "da637...",
        "incidentId": "12345",
        "title": "Esecuzione sospetta di PowerShell",
        "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://<il-tuo-dominio-casebender>/api/v1/ingest/defender" \
  -H "x-api-key: cbr_defender_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" \
  -H "Content-Type: application/json" \
  -d '{
    "id": "da637...",
    "title": "Malware rilevato su endpoint",
    "severity": "medium",
    "status": "new",
    "createdDateTime": "2026-07-03T18:20:00Z"
  }'

Una richiesta riuscita restituisce HTTP 202 Accepted:

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

Pipeline di elaborazione

Proxy di acquisizione

/api/v1/ingest/defender convalida la sorgente e inoltra la richiesta al servizio di acquisizione (POST /v1/sources/defender).

Pubblicazione in coda

Il servizio di acquisizione autentica la chiave API, convalida il payload e pubblica ogni avviso nella coda di elaborazione.

Normalizzazione

Il processore Defender normalizza ogni record in un avviso CaseBender: mappa la gravità, costruisce titolo/descrizione, estrae osservabili e asset del dispositivo e genera i TTP MITRE.

Riferimento di mappatura dei dati

Mappatura della gravità (Defender → CaseBender 1–4):

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

Estrazione degli osservabili (da evidence[]):

Campo prova	Tipo di osservabile
`ipAddress`	`ip`
`url`	`url`
`sha256`	`hash`
`fileName`	`filename`
`deviceDnsName`	`hostname`
`userAccount`	`user` (`DOMINIO\account`)

I tag applicati all’acquisizione includono defender, xdr, service:<serviceSource>, category:<category>, incident (per gli incidenti) e un tag mitre:<technique> per ogni tecnica MITRE. I record acquisiti usano per impostazione predefinita TLP:2 e PAP:2.

In uscita: Sincronizzare le disposizioni dei casi con Defender

Quando un caso viene chiuso in CaseBender, l’evento case_closed viene inviato al gestore Defender. Se il caso è collegato a un avviso o incidente Defender, CaseBender invia la risoluzione tramite l’API di sicurezza di Graph.

Come viene risolta l’entità Defender collegata

Il gestore cerca gli identificatori Defender in questo ordine:

extraData.defenderAlertId / extraData.defenderIncidentId sul caso
sourceRef quando extraData.source === "defender"
Gli avvisi Defender collegati al caso — il pipeline di acquisizione registra l’ID incidente/avviso Defender nei customFields di ogni avviso, quindi un caso promosso da un avviso Defender (acquisito tramite polling o webhook) si risolve automaticamente, indipendentemente da come è stato creato.

Se non viene trovato alcun ID di avviso o incidente, la chiusura del caso viene ignorata per questa integrazione.

Mappatura risoluzione → classificazione

Risoluzione CaseBender	Classificazione Defender
`TruePositive`	`truePositive`
`FalsePositive`	`falsePositive`
`Duplicate`	`informationalExpectedActivity`
`NoImpact`	`informationalExpectedActivity`
(altra / nessuna)	`truePositive` (predefinito)

Alla chiusura, CaseBender applica la classification mappata e aggiunge un commento come:

Case closed in CaseBender with resolution: <risoluzione>

Imposta inoltre lo status dell’entità Defender su resolved quando è abilitato il relativo interruttore (closeAlertsOnCaseClose per gli avvisi, closeIncidentsOnCaseClose per gli incidenti). L’esito viene scritto nella cronologia del caso affinché gli analisti possano confermare la sincronizzazione.

syncCaseClose è l’interruttore principale della sincronizzazione in uscita (attivo per impostazione predefinita). Quando è disattivato, non viene effettuata alcuna chiamata in uscita. Gli aggiornamenti degli avvisi usano l’endpoint moderno /security/alerts_v2/{id}; quelli degli incidenti usano /security/incidents/{id}.

Considerazioni sulla sicurezza

Gestione dei segreti — il secret client è memorizzato nelle impostazioni dell’integrazione; ruotalo secondo le esigenze della tua organizzazione e aggiorna l’integrazione.
Privilegio minimo — per le distribuzioni solo in entrata concedi solo SecurityAlert.Read.All e SecurityIncident.Read.All; aggiungi i corrispondenti ambiti ReadWrite.All solo se abiliti la chiusura inversa in uscita. Non aggiungere ambiti Graph più ampi.
Caching dei token — i token di accesso sono memorizzati in cache in memoria per integrazione e aggiornati un minuto prima della scadenza; nessun token viene persistito su disco.
Chiavi webhook — tratta la chiave API cbr_defender_ come un segreto. Ruotala se esposta e aggiorna la configurazione del mittente.
Rete — limita l’uscita a login.microsoftonline.com e graph.microsoft.com.

Risoluzione dei problemi

Il test di connessione fallisce con un errore OAuth2

Verifica tenantId, clientId e clientSecret. Conferma che il secret client non sia scaduto e che sia stato concesso il consenso dell’amministratore per le autorizzazioni dell’applicazione Graph.

L'acquisizione restituisce 401 Unauthorized

L’header x-api-key è mancante o non valido. Conferma di inviare la chiave cbr_defender_ che corrisponde alla chiave API webhook configurata dell’integrazione.

L'acquisizione restituisce 400 'No alerts in payload'

Il payload non conteneva né un array value[] né un id di primo livello. Invia un oggetto batch di Graph o un oggetto di avviso singolo.

Il polling è abilitato ma non compaiono incidenti

Conferma che Abilita il polling automatico sia attivo e che il test di connessione abbia successo. Verifica che l’app abbia SecurityIncident.Read.All (o ReadWrite.All) con consenso dell’amministratore, che il servizio di polling possa raggiungere graph.microsoft.com (e il tuo proxy, se presente) e che esistano incidenti più recenti del cursore. Alla prima esecuzione vengono importati solo gli incidenti entro pollingInitialLookbackHours. Gli incidenti acquisiti tramite polling compaiono nella casella Avvisi.Assicurati che tutti i servizi di CaseBender siano in esecuzione. Gli incidenti vengono recuperati dal processore in background e trasformati in avvisi (e facoltativamente in casi) dal worker in background. Se il worker non è in esecuzione, gli incidenti vengono recuperati ma non compaiono mai. Con Docker, esegui docker compose ps e verifica che i servizi worker e misp-processor siano Up; in caso contrario esegui docker compose up -d. L’installer standard e la guida rapida configurano tutto automaticamente: non devi configurare alcuna impostazione di coda o Redis.

La chiusura del caso non aggiorna Defender

Assicurati che syncCaseClose sia attivo (è l’interruttore principale). Per contrassegnare anche l’entità Defender come resolved, abilita closeAlertsOnCaseClose / closeIncidentsOnCaseClose. Il caso deve essere collegato a un avviso/incidente Defender — la chiusura di un caso promosso da un avviso Defender (acquisito tramite polling o webhook) risolve automaticamente il collegamento. Controlla la cronologia del caso per l’esito.

L'aggiornamento in uscita restituisce 403 o 404

Un 403 significa che all’app Azure AD manca l’autorizzazione di scrittura: conferma che SecurityAlert.ReadWrite.All e SecurityIncident.ReadWrite.All siano concessi con il consenso dell’amministratore. Un 404 sull’aggiornamento di un avviso indica di solito un endpoint legacy; CaseBender usa /security/alerts_v2/{id} per gli avvisi moderni di Defender XDR.

Iniziare

Distribuzione

Gestione degli Avvisi

Gestione dei Casi

Gestione delle Attività

Analisi

Verifiche

Impostazioni

Microsoft Defender XDR

Panoramica

Acquisizione in entrata

Sincronizzazione in uscita

Funzionalità

Prerequisiti

Parte A — Registrare un’applicazione Azure AD

Parte B — Configurare l’integrazione in CaseBender

In entrata (polling automatico, consigliato)

In entrata (webhook / push)

Endpoint

Formati del payload

Pipeline di elaborazione

Riferimento di mappatura dei dati

In uscita: Sincronizzare le disposizioni dei casi con Defender

Come viene risolta l’entità Defender collegata

Mappatura risoluzione → classificazione

Considerazioni sulla sicurezza

Risoluzione dei problemi

Documentazione correlata

​Panoramica

Acquisizione in entrata

Sincronizzazione in uscita

​Funzionalità

​Prerequisiti

​Parte A — Registrare un’applicazione Azure AD

​Parte B — Configurare l’integrazione in CaseBender

​In entrata (polling automatico, consigliato)

​In entrata (webhook / push)

​Endpoint

​Formati del payload

​Pipeline di elaborazione

​Riferimento di mappatura dei dati

​In uscita: Sincronizzare le disposizioni dei casi con Defender

​Come viene risolta l’entità Defender collegata

​Mappatura risoluzione → classificazione

​Considerazioni sulla sicurezza

​Risoluzione dei problemi

​Documentazione correlata

Panoramica

Funzionalità

Prerequisiti

Parte A — Registrare un’applicazione Azure AD

Parte B — Configurare l’integrazione in CaseBender

In entrata (polling automatico, consigliato)

In entrata (webhook / push)

Endpoint

Formati del payload

Pipeline di elaborazione

Riferimento di mappatura dei dati

In uscita: Sincronizzare le disposizioni dei casi con Defender

Come viene risolta l’entità Defender collegata

Mappatura risoluzione → classificazione

Considerazioni sulla sicurezza

Risoluzione dei problemi

Documentazione correlata