Microsoft Defender XDR

Visão geral

A integração do Microsoft Defender XDR (INT-021) fornece sincronização bidirecional entre o CaseBender e a plataforma de detecção e resposta estendidas da Microsoft, incluindo o Microsoft Defender para Endpoint (MDE) e o Microsoft Defender XDR.

Ingestão de entrada

Alertas e incidentes do Defender são ingeridos no CaseBender, normalizados, enriquecidos com observáveis e técnicas MITRE ATT&CK e transformados em alertas/casos.

Sincronização de saída

Quando um caso do CaseBender é fechado, o alerta/incidente vinculado do Defender é atualizado com o status, a classificação e um comentário de auditoria via Microsoft Graph.

Esta integração usa a API de Segurança do Microsoft Graph (https://graph.microsoft.com/v1.0/security). Ela se autentica com um aplicativo do Azure AD (Entra ID) usando o fluxo de credenciais de cliente OAuth2.

Recursos

Recurso	Direção	Descrição
Sondagem de incidentes (pull)	Entrada	O CaseBender consulta a API de Segurança do Graph de forma agendada e ingere novos incidentes automaticamente, sem configuração do lado da Microsoft
Ingestão de alertas (push)	Entrada	Alertas do Defender são enviados por webhook e normalizados em alertas do CaseBender
Ingestão de incidentes	Entrada	Incidentes do Defender (com alertas filhos) são ingeridos
Extração de observáveis	Entrada	IPs, URLs, hashes de arquivos, nomes de arquivos, hostnames e contas de usuário são extraídos das evidências
Extração de ativos	Entrada	Hostname, IP e plataforma de SO do dispositivo são capturados de `devices[]`
Correlação MITRE ATT&CK	Entrada	IDs de técnica são adicionados como tags e TTPs (ex.: `mitre:T1078`)
Sincronização de alertas	Saída	`status`, `classification`, `determination` e comentários são enviados ao fechar o caso
Sincronização de incidentes	Saída	`status`, `classification`, `determination` e comentários são enviados ao fechar o caso
Teste de conexão	Bidirecional	Valida as credenciais OAuth2 e o acesso à API de Segurança do Graph

Pré-requisitos

Acesso ao Microsoft Defender / Entra ID

Um locatário do Microsoft Entra ID (Azure AD) com o Microsoft Defender XDR ou o Microsoft Defender para Endpoint licenciado e habilitado. Você precisa de permissão para registrar aplicativos e conceder consentimento do administrador.

Saída de rede

A implantação do CaseBender deve conseguir alcançar:

https://login.microsoftonline.com (endpoint de token OAuth2)
https://graph.microsoft.com (API de Segurança do Graph)

Função de administrador do CaseBender

Você deve conseguir criar e gerenciar integrações em Configurações → Integrações.

Parte A — Registrar um aplicativo do Azure AD

Criar o registro do aplicativo

No centro de administração do Microsoft Entra, vá para Identidade → Aplicativos → Registros de aplicativo → Novo registro. Dê um nome (ex.: CaseBender Defender Integration) e registre-o.

Registrar os identificadores

Na Visão geral do aplicativo, copie o ID do aplicativo (cliente) e o ID do diretório (locatário). Você os inserirá no CaseBender.

Criar um segredo do cliente

Em Certificados e segredos → Novo segredo do cliente, crie um segredo e copie o seu Valor imediatamente (ele é exibido apenas uma vez).

Conceder permissões da API de Segurança do Graph

Em Permissões de API → Adicionar uma permissão → Microsoft Graph → Permissões de aplicativo, adicione os escopos para a(s) direção(ões) necessária(s) e clique em Conceder consentimento do administrador:

Permissão	Necessária para	Finalidade
`SecurityAlert.Read.All`	Entrada (sondagem / ingestão)	Ler alertas do Defender
`SecurityIncident.Read.All`	Entrada (sondagem / ingestão)	Ler incidentes do Defender
`SecurityAlert.ReadWrite.All`	Saída (fechamento reverso)	Ler e atualizar alertas do Defender ao fechar o caso
`SecurityIncident.ReadWrite.All`	Saída (fechamento reverso)	Ler e atualizar incidentes do Defender ao fechar o caso

Acesso somente leitura é suficiente para a sondagem. Se você apenas extrai incidentes/alertas para o CaseBender, conceda os dois escopos Read.All. Os escopos ReadWrite.All são necessários apenas para o fechamento reverso de saída opcional (syncCaseClose) — fechar um alerta/incidente do Defender a partir do CaseBender. Como ReadWrite.All também inclui acesso de leitura, conceder apenas os dois escopos ReadWrite.All cobre ambas as direções.

Use permissões de Aplicativo (não Delegadas). A integração é executada de forma headless com o fluxo de credenciais de cliente e requer o consentimento do administrador do locatário.

Parte B — Configurar a integração no CaseBender

Abrir o catálogo de integrações

Vá para Configurações → Integrações → Criar e escolha Microsoft Defender XDR na categoria EDR/XDR.

Inserir as credenciais do Azure AD

Forneça os valores capturados na Parte A:

Campo	Descrição
`tenantId`	ID do diretório (locatário)
`clientId`	ID do aplicativo (cliente)
`clientSecret`	Valor do segredo do cliente

Habilitar a sondagem automática (recomendado)

No cartão Sondagem automática, ative Habilitar a sondagem automática e defina:

Opção	Efeito
`pollingEnabled`	Ativar a extração agendada de incidentes do Defender
`pollingIntervalMinutes`	Com que frequência sondar (padrão `5`, intervalo 1–1440)
`pollingInitialLookbackHours`	Na primeira execução, importar os incidentes atualizados dentro desta janela (padrão `24`, intervalo 1–168)

Consulte Sondagem automática para saber como funciona.

Configurar as opções de sincronização

Habilite os comportamentos necessários:

Opção	Efeito
`syncCaseClose`	Interruptor principal da sincronização de saída. Quando ativado (padrão), fechar um caso vinculado envia a classificação + um comentário de auditoria ao Defender
`closeAlertsOnCaseClose`	Além disso, definir o status do alerta vinculado do Defender como `resolved`
`closeIncidentsOnCaseClose`	Além disso, definir o status do incidente vinculado do Defender como `resolved`
`autoCreateCases`	Promover automaticamente cada registro do Defender ingerido a um Caso (deduplicado por ID de incidente). Quando desativado, os registros permanecem na caixa de entrada de Alertas para promoção manual

Com syncCaseClose ativado, mas ambos os interruptores close…OnCaseClose desativados, o CaseBender ainda grava a classificação e o comentário de auditoria no Defender — apenas não altera a entidade do Defender para resolved.

Testar a conexão

Use Testar conexão para validar. O CaseBender solicita um token OAuth2 e chama GET /security/alerts_v2?$top=1.

Uma resposta 403 durante o teste é tratada como sucesso — ela confirma que a autenticação funcionou mesmo quando o aplicativo ainda não recebeu o escopo de leitura naquele endpoint específico.

Entrada (sondagem automática, recomendado)

Com a sondagem automática ativada (no cartão Sondagem automática da integração), o CaseBender chama periodicamente a API de segurança do Graph e ingere os novos incidentes por conta própria — sem necessidade de Logic App, regra de automação do Sentinel ou encaminhador de webhook no lado da Microsoft. Só é necessário o registro de aplicativo do Azure AD da Parte A.

Extração agendada — a cada pollingIntervalMinutes, o CaseBender busca os incidentes com lastUpdateDateTime gt <cursor> e $expand=alerts, do mais antigo ao mais recente. Na primeira execução, importa os incidentes atualizados dentro de pollingInitialLookbackHours.
Cursor e deduplicação — um cursor por integração avança até o incidente mais recente visto, e os incidentes são deduplicados pelo ID de incidente do Defender, de modo que nada é ingerido duas vezes.
Normalização — cada incidente e seus alertas filhos se tornam um alerta do CaseBender com observáveis, ativos e TTPs do MITRE. O ID de incidente do Defender é gravado no alerta para que a sincronização de fechamento de saída possa localizá-lo.

Requer SecurityIncident.Read.All (coberto por SecurityIncident.ReadWrite.All). Com autoCreateCases ativado, cada incidente obtido por sondagem se torna automaticamente um Caso (deduplicado por ID de incidente); se desativado, os incidentes aparecem na caixa de Alertas para promoção manual. Em ambos os casos, o vínculo com o Defender é preservado para que o fechamento do caso possa sincronizar de volta.

Entrada (webhook / push)

Endpoint

O Defender (ou um intermediário como Logic Apps, Sentinel ou um encaminhador de webhook) envia as cargas de alertas/incidentes para o endpoint de ingestão do CaseBender:

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

As solicitações são autenticadas com uma chave de API de integração no cabeçalho x-api-key (o cabeçalho authorization: Bearer <chave> também é aceito). As chaves de API de webhook do Defender têm o prefixo cbr_defender_.

Formatos de carga

Tanto o formato em lote (array value[] do Graph) quanto um objeto de alerta único são suportados.

curl -X POST "https://<seu-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": "Execução suspeita de 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://<seu-dominio-casebender>/api/v1/ingest/defender" \
  -H "x-api-key: cbr_defender_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" \
  -H "Content-Type: application/json" \
  -d '{
    "id": "da637...",
    "title": "Malware detectado no endpoint",
    "severity": "medium",
    "status": "new",
    "createdDateTime": "2026-07-03T18:20:00Z"
  }'

Uma solicitação bem-sucedida retorna HTTP 202 Accepted:

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

Pipeline de processamento

Proxy de ingestão

/api/v1/ingest/defender valida a origem e encaminha a solicitação ao serviço de ingestão (POST /v1/sources/defender).

Publicação na fila

O serviço de ingestão autentica a chave de API, valida a carga e publica cada alerta na fila de processamento.

Normalização

O processador do Defender normaliza cada registro em um alerta do CaseBender: mapeia a gravidade, constrói o título/descrição, extrai observáveis e ativos de dispositivo e gera os TTPs do MITRE.

Referência de mapeamento de dados

Mapeamento de gravidade (Defender → CaseBender 1–4):

Gravidade do Defender	Gravidade do CaseBender
`high`	1
`medium`	2
`low`	3
`informational`	4
`unknown`	3

Extração de observáveis (de evidence[]):

Campo de evidência	Tipo de observável
`ipAddress`	`ip`
`url`	`url`
`sha256`	`hash`
`fileName`	`filename`
`deviceDnsName`	`hostname`
`userAccount`	`user` (`DOMÍNIO\conta`)

As tags aplicadas na ingestão incluem defender, xdr, service:<serviceSource>, category:<category>, incident (para incidentes) e uma tag mitre:<technique> por técnica do MITRE. Os registros ingeridos usam por padrão TLP:2 e PAP:2.

Saída: Sincronizar disposições de casos com o Defender

Quando um caso é fechado no CaseBender, o evento case_closed é despachado para o manipulador do Defender. Se o caso estiver vinculado a um alerta ou incidente do Defender, o CaseBender envia a resolução por meio da API de Segurança do Graph.

Como a entidade vinculada do Defender é resolvida

O manipulador procura os identificadores do Defender nesta ordem:

extraData.defenderAlertId / extraData.defenderIncidentId no caso
sourceRef quando extraData.source === "defender"
O(s) alerta(s) do Defender vinculado(s) ao caso — o pipeline de ingestão registra o ID de incidente/alerta do Defender nos customFields de cada alerta, portanto um caso promovido a partir de um alerta do Defender (sondado ou por webhook) é resolvido automaticamente, independentemente de como foi criado.

Se nenhum ID de alerta ou incidente for encontrado, o fechamento do caso é ignorado para esta integração.

Mapeamento de resolução → classificação

Resolução do CaseBender	Classificação do Defender
`TruePositive`	`truePositive`
`FalsePositive`	`falsePositive`
`Duplicate`	`informationalExpectedActivity`
`NoImpact`	`informationalExpectedActivity`
(outra / nenhuma)	`truePositive` (padrão)

Ao fechar, o CaseBender aplica a classification mapeada e adiciona um comentário como:

Case closed in CaseBender with resolution: <resolução>

Além disso, define o status da entidade do Defender como resolved quando o interruptor correspondente (closeAlertsOnCaseClose para alertas, closeIncidentsOnCaseClose para incidentes) está habilitado. O resultado é gravado na linha do tempo do caso para que os analistas possam confirmar a sincronização.

syncCaseClose é o interruptor principal da sincronização de saída (ativado por padrão). Quando está desativado, nenhuma chamada de saída é feita. As atualizações de alertas usam o endpoint moderno /security/alerts_v2/{id}; as de incidentes usam /security/incidents/{id}.

Considerações de segurança

Tratamento de segredos — o segredo do cliente é armazenado nas configurações da integração; alterne-o conforme o cronograma exigido pela sua organização e atualize a integração.
Privilégio mínimo — para implantações somente de entrada, conceda apenas SecurityAlert.Read.All e SecurityIncident.Read.All; adicione os escopos ReadWrite.All correspondentes somente se você habilitar o fechamento reverso de saída. Não adicione escopos mais amplos do Graph.
Cache de tokens — os tokens de acesso são armazenados em cache na memória por integração e atualizados um minuto antes da expiração; nenhum token é persistido em disco.
Chaves de webhook — trate a chave de API cbr_defender_ como um segredo. Alterne-a se exposta e atualize a configuração do remetente.
Rede — restrinja a saída a login.microsoftonline.com e graph.microsoft.com.

Solução de problemas

O teste de conexão falha com um erro OAuth2

Verifique tenantId, clientId e clientSecret. Confirme que o segredo do cliente não expirou e que o consentimento do administrador foi concedido para as permissões do aplicativo do Graph.

A ingestão retorna 401 Unauthorized

O cabeçalho x-api-key está ausente ou inválido. Confirme que você está enviando a chave cbr_defender_ que corresponde à chave de API de webhook configurada da integração.

A ingestão retorna 400 'No alerts in payload'

A carga não tinha nem um array value[] nem um id de nível superior. Envie um objeto em lote do Graph ou um objeto de alerta único.

A sondagem está habilitada, mas nenhum incidente aparece

Confirme que Habilitar a sondagem automática está ativado e que o teste de conexão passa. Verifique se o aplicativo tem SecurityIncident.Read.All (ou ReadWrite.All) com consentimento do administrador, se o serviço de sondagem consegue alcançar graph.microsoft.com (e seu proxy, se houver) e se existem incidentes mais recentes que o cursor. Na primeira execução, apenas os incidentes dentro de pollingInitialLookbackHours são importados. Os incidentes sondados aparecem na caixa de entrada de Alertas.Certifique-se de que todos os serviços do CaseBender estejam em execução. Os incidentes são obtidos pelo processador em segundo plano e transformados em alertas (e, opcionalmente, em casos) pelo worker em segundo plano. Se o worker não estiver em execução, os incidentes são obtidos, mas nunca aparecem. Com o Docker, execute docker compose ps e confirme que os serviços worker e misp-processor estão Up; caso contrário, execute docker compose up -d. O instalador padrão e o guia de início rápido configuram tudo automaticamente — você não precisa configurar nenhuma opção de fila ou Redis.

O fechamento do caso não atualiza o Defender

Certifique-se de que syncCaseClose esteja ativado (é o interruptor principal). Para também marcar a entidade do Defender como resolved, habilite closeAlertsOnCaseClose / closeIncidentsOnCaseClose. O caso deve estar vinculado a um alerta/incidente do Defender — fechar um caso promovido a partir de um alerta do Defender (sondado ou por webhook) resolve o vínculo automaticamente. Verifique a linha do tempo do caso para ver o resultado.

A atualização de saída retorna 403 ou 404

Um 403 significa que o aplicativo do Azure AD não tem permissão de gravação — confirme que SecurityAlert.ReadWrite.All e SecurityIncident.ReadWrite.All foram concedidos com consentimento do administrador. Um 404 na atualização de um alerta geralmente indica um endpoint legado; o CaseBender usa /security/alerts_v2/{id} para alertas modernos do Defender XDR.

Primeiros Passos

Implantação

Gerenciamento de Alertas

Gerenciamento de Casos

Gerenciamento de Tarefas

Análises

Auditorias

Configurações

Microsoft Defender XDR

Visão geral

Ingestão de entrada

Sincronização de saída

Recursos

Pré-requisitos

Parte A — Registrar um aplicativo do Azure AD

Parte B — Configurar a integração no CaseBender

Entrada (sondagem automática, recomendado)

Entrada (webhook / push)

Endpoint

Formatos de carga

Pipeline de processamento

Referência de mapeamento de dados

Saída: Sincronizar disposições de casos com o Defender

Como a entidade vinculada do Defender é resolvida

Mapeamento de resolução → classificação

Considerações de segurança

Solução de problemas

Documentação relacionada

​Visão geral

Ingestão de entrada

Sincronização de saída

​Recursos

​Pré-requisitos

​Parte A — Registrar um aplicativo do Azure AD

​Parte B — Configurar a integração no CaseBender

​Entrada (sondagem automática, recomendado)

​Entrada (webhook / push)

​Endpoint

​Formatos de carga

​Pipeline de processamento

​Referência de mapeamento de dados

​Saída: Sincronizar disposições de casos com o Defender

​Como a entidade vinculada do Defender é resolvida

​Mapeamento de resolução → classificação

​Considerações de segurança

​Solução de problemas

​Documentação relacionada

Visão geral

Recursos

Pré-requisitos

Parte A — Registrar um aplicativo do Azure AD

Parte B — Configurar a integração no CaseBender

Entrada (sondagem automática, recomendado)

Entrada (webhook / push)

Endpoint

Formatos de carga

Pipeline de processamento

Referência de mapeamento de dados

Saída: Sincronizar disposições de casos com o Defender

Como a entidade vinculada do Defender é resolvida

Mapeamento de resolução → classificação

Considerações de segurança

Solução de problemas

Documentação relacionada