Partager via


Considérations relatives à l’intégration de services de sécurité non-Microsoft avec Microsoft 365

Bien que Microsoft fournisse une plateforme complète pour la sécurité de la messagerie, nous comprenons que certains clients adoptent une stratégie de défense en profondeur pour la sécurité de la messagerie en ajoutant un service de sécurité tiers (non-Microsoft). Il existe deux considérations relatives à l’incorporation de services de sécurité non-Microsoft avec Microsoft 365 :

  • Si le service non-Microsoft augmente la posture de sécurité de votre organization et les compromis pour le faire. Par exemple :

    • Plus de coûts.
    • Plus de complexité.
    • Le taux de faux positifs (bons éléments marqués comme mauvais) augmente à mesure que d’autres produits sont ajoutés.
    • Comment le service de sécurité non-Microsoft s’intègre de bout en bout. Par exemple :
      • Le service non-Microsoft doit fournir une expérience utilisateur qui n’oblige pas les utilisateurs à réfléchir à la mise en quarantaine à utiliser.
      • Le service non-Microsoft doit s’intégrer aux processus et outils d’opérations de sécurité (SecOps) existants. Par exemple, la gestion des informations et des événements de sécurité (SIEM), l’orchestration de la sécurité, l’automatisation et la réponse (SOAR), etc.

    Remarque

    Email sécurité est un espace contradictoire. Avec l’essor des kits d’hameçonnage et d’attaque de base, les attaques évoluent et se transforment rapidement. C’est pourquoi Microsoft Defender pour Office 365 fait partie de Microsoft Defender XDR, notre approche multicouche, pré-violation et post-violation de la cybersécurité d’entreprise.

    Quel que soit le nombre de couches de protection de la messagerie, la protection totale n’atteint jamais 100 %.

  • Comment le service non-Microsoft analyse et agit sur les messages électroniques. En règle générale, les services de sécurité non-Microsoft suggèrent les trois options d’intégration suivantes, et toutes ces options ne sont pas également prises en charge par Microsoft pour le moment.

Intégration via le routage de messagerie DNS (l’enregistrement MX pointe vers le service non-Microsoft)

Cette configuration est traitée en détail dans filtrage amélioré pour les connecteurs dans Exchange Online et est entièrement prise en charge par Microsoft. Email fournisseurs de sécurité qui prennent en charge la chaîne de réception authentifiée (ARC) fonctionnent mieux, mais il existe des limitations. Par exemple, évitez d’utiliser des liens fiables pour case activée et encapsuler des liens avec un service non-Microsoft qui réécrit également les liens. L’habillage de double liaison peut empêcher les liens fiables de valider les status de liens, de déclencher des liens pour les menaces et de déclencher potentiellement des liens à usage unique. Nous vous recommandons de désactiver la fonctionnalité d’habillage de liens dans le service non-Microsoft.

Pour plus d’informations sur cette configuration, consultez Gérer le flux de messagerie à l’aide d’un service cloud tiers avec Exchange Online.

Intégration via microsoft API Graph

Certains services non-Microsoft s’authentifient et utilisent les API Graph Microsoft pour analyser les messages une fois qu’ils ont été remis aux boîtes aux lettres des utilisateurs. Cette configuration permet également au service non-Microsoft de supprimer les messages qu’ils jugent malveillants ou indésirables. En règle générale, cette configuration nécessite un accès complet aux boîtes aux lettres par le service non-Microsoft. Veillez à comprendre les pratiques de sécurité et de support du service non-Microsoft avant d’accorder cette autorisation.

Intégration via le routage des messages entrants et sortants

Cette configuration permet à l’enregistrement MX de pointer vers Microsoft 365. Toutefois, le service non-Microsoft fonctionne après la protection et le traitement des e-mails Microsoft 365, comme illustré dans le diagramme suivant :

 diagramme montrant le flux de messagerie avec un service de sécurité non-Microsoft utilisé après la remise du courrier à Microsoft 365.

Conseil

Le filtrage amélioré pour les connecteurs ne fonctionne pas avec cette configuration. Le filtrage amélioré pour les connecteurs est conçu pour les scénarios où le service non-Microsoft est antérieur à Microsoft 365, comme expliqué précédemment dans la section Intégration via le routage de messagerie DNS . Le service non-Microsoft antérieur à Microsoft 365 autorise le fonctionnement de la pile complète de protection des e-mails, tout en empêchant intelligemment l’usurpation de faux positifs liés à l’infrastructure d’envoi du service non-Microsoft. Vous ne pouvez pas utiliser le filtrage amélioré pour les connecteurs pour approuver par nature tous les messages provenant d’adresses IP Microsoft 365.

Cette configuration nécessite que le message quitte la limite du service Microsoft 365. Lorsque le message est retourné à partir du service non-Microsoft, il est traité comme un message entièrement nouveau par Microsoft 365. Ce comportement entraîne les problèmes et les complexités suivants :

  • Les messages sont comptés deux fois dans la plupart des outils de création de rapports, y compris Explorer (Explorer de menaces), la chasse avancée et l’investigation et la réponse automatisées (AIR). Ce comportement rend difficile la corrélation correcte du verdict et des actions du message.

  • Étant donné que les messages qui reviennent dans Microsoft 365 sont susceptibles d’échouer aux vérifications d’authentification par e-mail, les messages peuvent être identifiés comme usurpant l’identité (faux positifs). Certains services non-Microsoft recommandent d’utiliser des règles de flux de messagerie (règles de transport) ou un filtrage de connexion IP pour résoudre ce problème, mais cela peut entraîner la remise de faux négatifs.

  • Plus important encore, le machine learning dans Defender for Office 365 ne fonctionne pas aussi efficacement que possible. Les algorithmes de Machine Learning s’appuient sur des données précises pour prendre des décisions sur le contenu. Les données incohérentes ou modifiées peuvent affecter négativement le processus d’apprentissage, ce qui entraîne une diminution de l’efficacité globale des Defender for Office 365. Les exemples incluent :

    • Réputation : Au fil du temps, les modèles Machine Learning découvrent les éléments associés au contenu correct et incorrect (adresses IP, domaines d’envoi, URL, etc.). Lorsque des messages sont retournés par le service non-Microsoft, les adresses IP d’envoi initiales ne sont pas conservées et peuvent réduire l’efficacité des adresses IP pour rendre un verdict correct. Ce comportement peut également affecter les soumissions, qui sont abordées plus loin au point 3.
    • Modifications du contenu du message : de nombreux services de sécurité de messagerie ajoutent des en-têtes de message, ajoutent des clauses d’exclusion de responsabilité, modifient le contenu du corps du message et/ou réécrient les URL dans les messages. Bien que ce comportement ne soit généralement pas un problème, les messages remis contenant ces modifications qui sont par la suite déterminés comme malveillants et supprimés via le vidage automatique zéro heure (ZAP) peuvent enseigner au Machine Learning que ces modifications indiquent un message incorrect.

Pour ces raisons, nous vous recommandons vivement d’éviter cette configuration et de travailler avec le fournisseur de services non-Microsoft pour utiliser les autres options d’intégration décrites dans cet article. Toutefois, si vous devez adopter cette configuration, nous vous recommandons vivement les paramètres et opérations suivants pour optimiser votre posture de protection :

  1. Configurez Defender for Office 365 actions de stratégie pour mettre en quarantaine tous les verdicts négatifs. Bien que cette configuration puisse être moins conviviale que l’utilisation du dossier Email indésirable, l’action de courrier indésirable se produit uniquement lors de la remise finale à la boîte aux lettres. Un e-mail qui aurait été remis au dossier Email indésirable est envoyé au service non-Microsoft à la place. Si/lorsque ce message revient à Microsoft, il n’existe aucune garantie que le verdict d’origine (par exemple, le courrier indésirable) est conservé. Ce comportement entraîne une diminution de l’efficacité globale.

    Conseil

    Les règles de flux de courrier (règles de transport) qui examinent les verdicts d’origine ne sont pas idéales, car elles peuvent introduire d’autres problèmes et entraîner des problèmes d’efficacité.

  2. Réduisez les faux positifs en remplaçant l’usurpation pour les e-mails provenant du service non-Microsoft. Par exemple, si le service non-Microsoft a une adresse IP 172.17.17.35, créez deux entrées d’expéditeur usurpées autorisées dans la liste verte/bloquée du locataire : une entrée externe et une entrée interne, comme illustré dans la capture d’écran suivante :

    Capture d’écran des entrées autorisées de l’expéditeur usurpé dans la liste verte/bloquée du locataire.

    Veillez à supprimer ces entrées de remplacement si vous quittez le service de protection non-Microsoft ou si vous modifiez son fonctionnement.

  3. Les faux négatifs (messages incorrects autorisés) et les envois de messages électroniques faux positifs à Microsoft doivent provenir de la version initiale du message, et non de celle renvoyée par le service non-Microsoft. Les faux positifs attribués au service non-Microsoft doivent être envoyés au service non-Microsoft. Cette exigence peut être complexe à gérer :

    • Faux négatif Microsoft (manqué lors de la réception initiale) : vous avez besoin d’une copie du message avant de le livrer à la boîte aux lettres. Envoyez la copie en quarantaine à partir du service non-Microsoft, si elle est disponible.
    • Faux négatif du service Microsoft + non-Microsoft : si les deux services le ratent, nous vous recommandons de signaler l’élément d’origine à Microsoft et de signaler l’élément dans la boîte aux lettres du destinataire au service non-Microsoft. L’élément retourné à Microsoft 365 à partir du service non-Microsoft inclut les détails du service non-Microsoft (par exemple, les adresses IP d’envoi du service non-Microsoft, les en-têtes personnalisés, etc.), ce qui peut entraîner une diminution de l’efficacité du machine learning.
    • Faux positif Microsoft : si le message a été initialement intercepté par Microsoft avant l’évaluation par le service non-Microsoft, l’envoi de cette copie à partir de la mise en quarantaine est efficace.
    • Faux positif du service non-Microsoft : si le service non-Microsoft a intercepté le message, vous devez leur envoyer le message, car Microsoft ne peut pas corriger le problème.

Intégration d’outils de création de rapports de messages non-Microsoft

Defender for Office 365'utilisateur a signalé des paramètres qui fonctionnent avec le bouton Rapport intégré dans les versions prises en charge d’Outlook.

Sachant que les services de sécurité non-Microsoft peuvent inclure leurs propres outils et processus pour signaler les faux positifs et les faux négatifs (y compris les efforts d’éducation et de sensibilisation des utilisateurs), Defender for Office 365 prend en charge les soumissions provenant d’outils de création de rapports tiers. Cette prise en charge permet de simplifier le signalement de faux positifs et de faux négatifs à Microsoft, et permet à votre équipe SecOps de tirer parti de Microsoft Defender XDR gestion des incidents et des enquêtes et réponses automatisées (AIR).

Pour plus d’informations, consultez Options pour les outils de création de rapports tiers.