Diferenças de esquema de alerta: conector autônomo versus Microsoft Defender XDR

Este artigo explica as diferenças entre alertas ingeridos por meio de conectores autônomos e alertas ingeridos por meio do conector Microsoft Defender XDR em Microsoft Sentinel.

Conectores autônomos ingerem alertas diretamente dos produtos de segurança originais, enquanto o conector Microsoft Defender XDR ingere alertas por meio do pipeline de Microsoft Defender XDR. Isso inclui conectores como Microsoft Defender para Office 365, Microsoft Defender para Ponto de Extremidade, Microsoft Defender para Identidade, IRM (Gerenciamento de Riscos de Informações), DLP (Prevenção contra Perda de Dados), Microsoft Defender para Nuvem (MDC) e Microsoft Defender para Aplicativos de Nuvem (MDA).

Essas diferenças podem afetar mapeamentos de campo, comportamento de campo derivado, estrutura de esquema, ingestão de alertas e comportamento do conector, o que pode afetar suas consultas, regras analíticas, pastas de trabalho e automação existentes. Examine essas diferenças antes de migrar para o conector XDR ou integrar Microsoft Sentinel ao portal Defender com Microsoft Defender XDR.

Para obter o esquema de alerta completo, veja Referência do esquema de alertas de segurança.

Comportamento do conector autônomo após a integração ao portal do Defender

Depois de integrar Microsoft Sentinel ao portal Defender com Microsoft Defender XDR, os alertas de Microsoft produtos de segurança são roteados pelo conector Microsoft Defender XDR em vez de Microsoft autônomos conectores de alerta do produto de segurança.

Em um ambiente de workspace único, os alertas de Microsoft produtos de segurança continuam disponíveis em Microsoft Sentinel, mas são ingeridos por meio do conector Microsoft Defender XDR. Essa alteração pode afetar campos relacionados à origem, mapeamentos de campo, comportamento de esquema, consultas, regras analíticas, pastas de trabalho e automação.

Em um ambiente de vários workspaces, o conector Microsoft Defender XDR é conectado apenas ao workspace primário. Para evitar alertas baseados em locatário duplicados em workspaces, conectores de dados autônomos para Microsoft Defender para Office 365, Microsoft Entra ID Protection, Microsoft Defender para Aplicativos de Nuvem, Microsoft Defender para Ponto de Extremidade e Microsoft Defender para Identidade são automaticamente desconectados em workspaces secundários durante a integração.

Como resultado, os alertas baseados em locatário desses produtos de segurança Microsoft estão disponíveis apenas no workspace primário. Todas as consultas, regras analíticas, pastas de trabalho, regras de automação ou integrações que dependem de alertas de conectores de produtos de segurança Microsoft autônomos em workspaces secundários não funcionam mais conforme o esperado após a integração.

Conectores de dados não Microsoft não são afetados por esse comportamento.

Para obter mais informações, veja Várias áreas de trabalho Microsoft Sentinel no portal do Defender.

Comportamento de CompromisedEntity

O campo CompromisedEntity é tratado de forma diferente em todos os produtos quando os alertas são ingeridos através do conector XDR.

Produto Valor equivalente de CompromisedEntity em alertas XDR
Microsoft Defender para Ponto de Extremidade (MDPE) O dispositivo em que "LeadingHost": true nas entidades de alerta JSON
Microsoft Entra ID (Proteção de Identidade) Sempre definido para o UPN do utilizador
Microsoft Defender para Identidade (MDI) Cadeia fixa "CompromisedEntity"

Observação

No MDPE alertas, o CompromisedEntity deriva do dispositivo em que "LeadingHost": true. Em alguns alertas, este campo pode não ser preenchido.

Nos alertas de MDI, o CompromisedEntity não representa um anfitrião ou utilizador e é sempre a cadeia "CompromisedEntity"literal .

Alterações ao mapeamento de campos

Alguns campos são renomeados ou utilizam conjuntos de valores diferentes em alertas do conector XDR.

Produto Campo/propriedade legado Comportamento XDR
MDPE ExtendedProperties.MicrosoftDefenderAtp.Category Mapeado para ExtendedProperties.Category
Microsoft Defender para o Office (MDO) ExtendedProperties.Status Utiliza um conjunto de valores diferente do legado
Microsoft Defender para o Office (MDO) ExtendedProperties.InvestigationName Não disponível

Transformações estruturais de esquemas (MDI)

Por vezes, o conector de Microsoft Defender para Identidade autónomo (MDI) utilizava entidades de marcador de posição para armazenar informações adicionais. No conector XDR, estas informações são dobradas em propriedades na resourceAccessEvents coleção.

Entidade/propriedade legada Representação XDR
ResourceAccessInfo.Time resourceAccessEvents[].AccessDateTime
ResourceAccessInfo.IpAddress resourceAccessEvents[].IpAddress
ResourceAccessInfo.ResourceIdentifier.AccountId resourceAccessEvents[].AccountId
ResourceAccessInfo.ResourceIdentifier.ResourceName resourceAccessEvents[].ResourceIdentifier
DomainResourceIdentifier resourceAccessEvents[].ResourceIdentifier

ResourceAccessInfo.ComputerId não é mais necessário porque é idêntico à entidade host na qual ResourceAccessInfo está definido.

Filtragem de ingestão de alertas

Alguns alertas disponíveis através de conectores autónomos não são ingeridos através do conector XDR.

Produto Comportamento de filtragem
Microsoft Defender para Cloud (MDC) Os alertas de gravidade informativa não são ingeridos
Microsoft Entra ID Por predefinição, os alertas abaixo de Gravidade elevada não são ingeridos; os clientes podem configurar a ingestão para incluir todas as gravidades

Comportamento de âmbito (Microsoft Defender para a Cloud)

Microsoft Defender para alertas da Cloud utilizam âmbitos diferentes quando ingeridos através do conector XDR.

Âmbito do conector autónomo Âmbito do conector XDR
Nível de subscrição Nível do locatário

Observação

Todos os alertas MDC estão disponíveis na área de trabalho primária do inquilino. Os alertas são confinados de acordo com os âmbitos de subscrição do MDC no Defender XDR.

Próximas etapas