Compartilhar via


Considerações para integrar serviços de segurança não Microsoft no Microsoft 365

Embora a Microsoft forneça uma plataforma abrangente para segurança de e-mail, compreendemos que alguns clientes adotam uma estratégia de defesa em profundidade para a segurança de e-mail ao adicionar um serviço de segurança de terceiros (não Microsoft). Existem duas considerações para incorporar serviços de segurança não Microsoft com o Microsoft 365:

  • Se o serviço que não é da Microsoft aumenta a postura de segurança da sua organização e as desvantagens para o fazer. Por exemplo:

    • Mais custos.
    • Mais complexidade.
    • A taxa de falsos positivos (itens bons marcados como incorretos) aumenta à medida que são adicionados mais produtos.
    • Como o serviço de segurança não Microsoft integra ponto a ponto. Por exemplo:
      • O serviço que não seja da Microsoft deve proporcionar uma experiência de utilizador que não exija que os utilizadores pensem em que quarentena utilizar.
      • O serviço que não seja da Microsoft deve ser integrado com os processos e ferramentas de Operações de Segurança (SecOps) existentes. Por exemplo, gestão de informações e eventos de segurança (SIEM), orquestração de segurança, automatização e resposta (SOAR), etc.

    Observação

    Email segurança é um espaço adverso. Com o aumento dos kits de phishing e ataques, os ataques evoluem e modificam-se rapidamente. É por isso que Microsoft Defender para Office 365 faz parte da Microsoft Defender XDR, da nossa abordagem de várias camadas, pré-violação e pós-violação à cibersegurança empresarial.

    Independentemente do número de camadas de proteção de e-mail existentes, a proteção total nunca atinge os 100%.

  • Como o serviço que não é da Microsoft analisa e atua em mensagens de e-mail. Normalmente, os serviços de segurança não Microsoft sugerem as três opções de integração seguintes e nem todas estas opções são igualmente suportadas pela Microsoft neste momento.

Integração através do encaminhamento de correio DNS (o registo MX aponta para o serviço que não é da Microsoft)

Esta configuração é abordada detalhadamente na Filtragem Avançada para Conectores no Exchange Online e é totalmente suportada pela Microsoft. Email fornecedores de segurança que suportam a Cadeia De Receção Autenticada (ARC) funcionam melhor, mas existem limitações. Por exemplo, evite utilizar Ligações Seguras para marcar e encapsular ligações com um serviço que não seja da Microsoft que também reescreva ligações. A moldagem de ligações duplas pode impedir as Ligações Seguras de validar status de ligações, detonar ligações para ameaças e potencialmente acionar ligações de utilização única. Recomendamos que desative a funcionalidade de encapsulamento de ligações no serviço não Microsoft.

Para obter informações adicionais sobre esta configuração, consulte Gerir o fluxo de correio através de um serviço cloud de terceiros com Exchange Online.

Integração através do Microsoft API do Graph

Alguns serviços que não sejam da Microsoft autenticam e utilizam o Microsoft API do Graph para digitalizar mensagens depois de serem entregues nas caixas de correio dos utilizadores. Esta configuração também permite que o serviço que não seja da Microsoft remova mensagens que consideram maliciosas ou indesejadas. Normalmente, esta configuração requer acesso total às caixas de correio pelo serviço não Microsoft. Certifique-se de que compreende as práticas de segurança e suporte do serviço que não é da Microsoft antes de conceder esta permissão.

Integração através do encaminhamento de correio dentro e fora

Esta configuração permite que o registo MX aponte para o Microsoft 365. No entanto, o serviço não Microsoft funciona após a proteção e processamento de e-mail do Microsoft 365, conforme mostrado no diagrama seguinte:

 diagrama a mostrar o fluxo de correio com um serviço de segurança não Microsoft a ser utilizado após a entrega de correio no Microsoft 365.

Dica

A Filtragem Avançada para Conectores não funciona com esta configuração. A Filtragem Avançada de Conectores foi concebida para cenários em que o serviço que não seja da Microsoft é anterior ao Microsoft 365, conforme explicado anteriormente na secção Integração através do encaminhamento de correio DNS . O serviço que não é da Microsoft antes do Microsoft 365 permite que a pilha completa de proteção de e-mail funcione, ao mesmo tempo que impede o spoofing de falsos positivos relacionados com a infraestrutura de envio do serviço não Microsoft. Não pode utilizar a Filtragem Avançada para Conectores para confiar inerentemente em todas as mensagens de endereços IP do Microsoft 365.

Esta configuração requer que a mensagem deixe o limite de serviço do Microsoft 365. Quando a mensagem é devolvida a partir do serviço que não é da Microsoft, é tratada como uma mensagem totalmente nova do Microsoft 365. Este comportamento resulta nos seguintes problemas e complexidades:

  • As mensagens são contadas duas vezes na maioria das ferramentas de relatórios, incluindo Explorer (Explorer de Ameaças), Investigação Avançada e investigação e resposta automatizada (AIR). Este comportamento dificulta a correlação adequada do veredicto e das ações da mensagem.

  • Uma vez que é provável que as mensagens que regressem ao Microsoft 365 falhem nas verificações de autenticação de e-mail, as mensagens podem ser identificadas como spoofing (falsos positivos). Alguns serviços que não sejam da Microsoft recomendam a utilização de regras de fluxo de correio (regras de transporte) ou de filtragem de ligação IP para ultrapassar este problema, mas podem levar à entrega de falsos negativos.

  • Talvez o mais importante, a aprendizagem automática no Defender para Office 365 não funcione da forma mais eficaz possível. Os algoritmos de machine learning dependem de dados precisos para tomar decisões sobre o conteúdo. Dados inconsistentes ou alterados podem afetar negativamente o processo de aprendizagem, o que leva a uma diminuição da eficácia geral dos Defender para Office 365. Os exemplos incluem:

    • Reputação: ao longo do tempo, os modelos de machine learning detetam os elementos associados a conteúdos bons e incorretos (endereços IP, domínios de envio, URLs, etc.). Quando as mensagens são devolvidas a partir do serviço não Microsoft, os endereços IP de envio iniciais não são preservados e podem reduzir a eficácia dos endereços IP ao compor um veredicto correto. Este comportamento também pode afetar as submissões, que são abordadas no ponto 3 posterior.
    • Modificações do conteúdo da mensagem: muitos serviços de segurança de e-mail adicionam cabeçalhos de mensagens, adicionam exclusões de responsabilidade, modificam o conteúdo do corpo da mensagem e/ou reescrevem URLs nas mensagens. Embora este comportamento não seja normalmente um problema, as mensagens entregues que contêm estas modificações que são posteriormente determinadas como maliciosas e removidas através da remoção automática de zero horas (ZAP) podem ensinar à aprendizagem automática que estas modificações indicam uma mensagem incorreta.

Por estas razões, recomendamos vivamente evitar esta configuração e trabalhar com o fornecedor de serviços não Microsoft para utilizar as outras opções de integração descritas neste artigo. No entanto, se tiver de adotar esta configuração, recomendamos vivamente as seguintes definições e operações para maximizar a postura de proteção:

  1. Configure Defender para Office 365 ações políticas para colocar em quarentena todos os veredictos negativos. Embora esta configuração possa ser menos fácil de utilizar do que utilizar a pasta Email de Lixo, a ação de lixo ocorre apenas após a entrega final na caixa de correio. Um e-mail que teria sido entregue na pasta Email de Lixo é enviado para o serviço que não é da Microsoft. Se/quando esta mensagem voltar à Microsoft, não há garantias de que o veredicto original (por exemplo, spam) seja preservado. Este comportamento leva a uma menor eficácia geral.

    Dica

    As regras de fluxo de correio (regras de transporte) que analisam os veredictos originais não são as ideais, pois podem introduzir outras questões e levar a desafios de eficácia.

  2. Minimize os falsos positivos ao substituir spoof para e-mails recebidos do serviço que não é da Microsoft. Por exemplo, se o serviço não Microsoft tiver um endereço IP 172.17.17.35, crie duas entradas de remetente falsificados permitidas na Lista de Permissões/Bloqueios de Inquilinos: uma Externa e outra Interna, conforme mostrado na seguinte captura de ecrã:

    Uma captura de ecrã das entradas de remetente falsificados permitidas na Lista de Permissões/Bloqueios do Inquilino.

    Certifique-se de que remove estas entradas de substituição se alguma vez sair do serviço de proteção não Microsoft ou alterar o funcionamento das mesmas.

  3. Os falsos negativos (correio incorreto permitido) e as submissões de e-mail falsos positivos para a Microsoft devem ser provenientes da versão inicial da mensagem e não da que é devolvida pelo serviço que não é da Microsoft. Os falsos positivos atribuídos ao serviço não Microsoft devem ser enviados para o serviço que não é da Microsoft. Este requisito pode ser complexo de gerir:

    • Microsoft false negative (perdido na receção inicial): precisa de uma cópia da mensagem antes de ser entregue na caixa de correio. Submeta a cópia em quarentena do serviço não Microsoft, se estiver disponível.
    • Microsoft + serviço não Microsoft falso negativo: se ambos os serviços falharem, recomendamos que comunique o item original à Microsoft e comunique o item na caixa de correio do destinatário ao serviço não Microsoft. O item devolvido ao Microsoft 365 a partir do serviço não Microsoft inclui detalhes do serviço que não é da Microsoft (por exemplo, os endereços IP enviados pelo serviço não Microsoft, cabeçalhos personalizados, etc.) que podem levar a uma diminuição da eficácia do machine learning.
    • Falso positivo da Microsoft: se a mensagem tiver sido inicialmente detetado pela Microsoft antes da avaliação pelo serviço que não é da Microsoft, a submissão desta cópia da quarentena é efetiva.
    • Falso positivo do serviço não Microsoft: se o serviço que não é da Microsoft tiver apanhado a mensagem, terá de enviar-lhes a mensagem, porque a Microsoft não consegue corrigir o problema.

Integrar ferramentas de relatórios de mensagens não Microsoft

Defender para Office 365 tem definições comunicadas pelo utilizador que funcionam com o botão Relatório incorporado em versões suportadas do Outlook ou os suplementos Microsoft Report Message ou Report Phishing.

Sabendo que os serviços de segurança não pertencentes à Microsoft podem incluir as suas próprias ferramentas e processos para comunicar falsos positivos e falsos negativos (incluindo os esforços de educação/sensibilização dos utilizadores), Defender para Office 365 suporta submissões de ferramentas de relatórios de terceiros. Este suporte ajuda a simplificar a comunicação de falsos positivos e falsos negativos à Microsoft e permite que a sua equipa do SecOps tire partido de Microsoft Defender XDR gestão de incidentes e investigações e resposta automatizadas (AIR).

Para obter mais informações, veja Opções para ferramentas de relatórios de terceiros.