Mettre en place une PoV de sécurité qui a du sens

Lorsque vous évaluez des outils de sécurité pour la messagerie électronique, vous ne devriez pas avoir à choisir entre un test équitable et la sécurité de vos utilisateurs. Pourtant, d'une manière ou d'une autre, c'est devenu la demande.

Voici un modèle que nous avons observé. Les entreprises comparent les outils API uniquement aux solutions SEG. Quelqu'un suggère ensuite de désactiver les protections essentielles sur le SEG (réécriture d'URL, contrôle des pièces jointes, politiques de lutte contre les menaces avancées) afin d'uniformiser les règles du jeu à l'adresse "."

Ce n'est pas niveler quoi que ce soit, c'est simplement supprimer complètement le champ.

Voyons comment évaluer honnêtement ces architectures sans créer de risque, et pourquoi les bizarreries de la conception d'API uniquement rendent cette conversation nécessaire en premier lieu.

Deux architectures, des tâches différentes

Les principales différences d'architecture ne sont pas seulement techniques ; elles déterminent ce que chaque solution peut ou ne peut pas protéger.

Les SEG sont en ligne. Ils inspectent chaque message avant sa livraison, analysent les liens et les pièces jointes en temps réel et appliquent des contrôles au niveau du périmètre. (Si une information est dangereuse, elle n'est jamais transmise à la boîte de réception). Ils inspectent chaque URL ou pièce jointe au fur et à mesure que l'utilisateur clique dessus, offrant ainsi un niveau de sécurité supplémentaire contre les menaces dynamiques.

Les outils API uniquement se connectent après la livraison. Ils observent ce qui atterrit dans Microsoft 365 ou Google Workspace, analysent les modèles de comportement et tentent de remédier à la situation, parfois quelques minutes ou quelques heures plus tard, par le biais d'appels API.

Un seul empêche. L'un d'entre eux répond. Les deux peuvent être utiles. Mais elles ne sont pas interchangeables et pour les évaluer côte à côte, il faut comprendre ce que chaque architecture peut réellement faire.

Pourquoi quelqu'un pourrait-il vous demander d'affaiblir votre SEG ?

Lorsqu'un outil API fonctionne derrière un SEG entièrement configuré, un phénomène prévisible se produit : la plupart des menaces n'atteignent jamais le stade de l'analyse.

Le malware sur les matières premières est bloqué. Les campagnes de phishing connues s'arrêtent à la porte. Les tentatives évidentes d'usurpation d'identité ne passent pas. Ce qui reste à analyser par l'outil API est un ensemble de données nettement plus petit et plus propre.

C'est le résultat idéal en matière de sécurité : les couches travaillent ensemble et les éléments les plus dangereux sont stoppés au plus tôt. Il est donc plus difficile pour un fournisseur d'API de démontrer sa valeur lors d'une brève évaluation.

La solution consiste donc à désactiver les contrôles les plus efficaces du SEG, à en laisser passer davantage et à créer plus de détections "" à signaler.

Le problème ? Vous venez de rendre votre environnement manifestement moins sûr pour la durée du test.

Ce que vous perdez réellement lorsque vous réduisez vos activités

Il ne s'agit pas d'un risque hypothétique. L'affaiblissement de votre SEG supprime la protection à trois stades où les attaques réussissent ou échouent :

Avant la livraison : Arrêter les menaces à la porte

Avec un SEG pleinement activé, les courriels dangereux n'atteignent jamais les boîtes de réception. L'inspection approfondie permet de détecter les URL et les pièces jointes malveillantes. Les techniques d'usurpation d'identité sont identifiées. Les menaces sont bloquées avant d'être diffusées. En relâchant ces contrôles, vous inondez Microsoft 365 de contenus qui ne devraient pas s'y trouver. L'outil API ne peut répondre qu'après la livraison, une fois que le message est déjà visible, lisible et exploitable. Même un délai de 30 secondes représente 30 secondes d'exposition inutile.

Le temps du clic : Protéger les utilisateurs lorsqu'ils s'engagent

La réécriture d'URL fait partie de vos contrôles les plus précieux. Lorsque les utilisateurs cliquent sur des liens, un SEG correctement configuré :

• Routage des clics grâce à l'inspection en temps réel
• Suit les redirections vers les destinations finales
• Analyse les pages à l'engagement
• Bloque l'accès aux sites qui se sont révélés malveillants après l'envoi du courrier électronique.

Si vous désactivez cette fonction lors d'un PoV, les utilisateurs cliqueront directement sur la destination choisie par l'attaquant. Les outils basés uniquement sur l'API ne peuvent pas intercepter les clics. Ils ne peuvent essayer de récupérer l'e-mail qu'après coup, en supposant que la connexion API fonctionne, que le traitement de Microsoft n'est pas retardé et que l'utilisateur n'a pas déjà donné ses informations d'identification. C'est à l'envers.

Interne et externe : Quand les outils à base d'API seulement deviennent obscurs

Les outils API analysent généralement le courrier électronique entrant provenant d'expéditeurs externes. Ce qu'ils ne contrôlent pas, c'est ce qui se passe à l'intérieur de votre organisation, où les comptes compromis et le phishing latéral opèrent. Une SEG qui protège les prises de communication internes et sortantes :

• phishing latéral à partir de comptes compromis ciblant des collègues
• Exfiltration de données vers des adresses externes
• Activités malveillantes d'initiés utilisant des comptes légitimes
• Violations de la politique sur ce qui quitte votre environnement

Ces attaques utilisent des comptes autorisés et des domaines de confiance et ne touchent jamais le flux de courrier externe. Les outils API qui surveillent uniquement les messages entrants ne les verront pas du tout.

Comment gérer un PoV équitable sans casser les choses ?

Vous n'avez pas besoin de compromettre la sécurité pour évaluer les fournisseurs de manière pertinente. Vous avez besoin de meilleurs critères de réussite.

Maintenez votre SEG pleinement activé

Tout fournisseur qui vous demande d'affaiblir les défenses existantes ne démontre pas de la valeur, il la fabrique. La réécriture d'URL, le sandboxing des pièces jointes et les politiques de lutte contre les menaces doivent rester actifs tout au long de l'évaluation.

Mesurer l'exposition, et pas seulement le nombre de détections

Demandez à chaque vendeur :

• Pendant combien de temps la menace a-t-elle été visible pour les utilisateurs ?
• Que se passe-t-il si la connectivité de l'API se dégrade ?
• Pouvez-vous prévenir les clics ou seulement nettoyer après ?

Une détection qui se produit après que l'utilisateur a lu, cliqué et saisi des informations d'identification ne constitue pas une prévention. Il s'agit de la réponse aux incidents.

Évaluer les résultats complets en matière de sécurité

Comparez ce que chaque vendeur arrête réellement :

• Solutions SEG : Bloquer les menaces avant la livraison, protéger les clics en temps réel, remédier aux problèmes après la livraison, contrôler le courrier électronique sortant et interne.
• Outils réservés à l'API : Analyser les messages entrants post-délivrance lorsque l'API le permet

La première est une protection complète de la plateforme. L'autre est une couche supplémentaire.

A quoi ressemble une bonne évaluation

L'objectif n'est pas de donner une mauvaise image d'un vendeur ou de créer un scénario artificiel où tout réussit. Il s'agit de comprendre ce que chaque solution apporte à votre posture de sécurité, et où se situent les lacunes.

Si vous évaluez un outil API uniquement, testez-le dans une configuration réaliste. Faites-le fonctionner derrière votre SEG existant avec toutes les fonctions activées. Mesurez la façon dont il gère les menaces sophistiquées qui parviennent à franchir votre première ligne de défense. Comprendre ce qu'il ne peut pas faire, comme la protection contre les clics, les menaces internes et les contrôles sortants. Décidez ensuite si cette analyse supplémentaire justifie l'investissement et les frais généraux opérationnels liés à la gestion d'une autre relation avec le fournisseur.

Vous pouvez également conserver votre protection globale au niveau de la plateforme et la laisser faire ce qu'elle fait le mieux : arrêter les menaces avant, pendant et après la livraison dans l'ensemble de votre environnement de messagerie.

Exécutez vos PoV de manière plus intelligente

Les solutions ponctuelles permettent de résoudre des problèmes ponctuels. Les plates-formes résolvent l'ensemble du problème.

Si une évaluation nécessite d'affaiblir les protections que vous avez mises en place aujourd'hui, c'est un signal qui mérite d'être pris en compte. Les outils de sécurité doivent prouver leur valeur par leurs propres mérites, et non en handicapant la concurrence.

Exécutez vos PoV de manière plus intelligente. Assurez la sécurité de vos utilisateurs. Et si quelqu'un suggère de désactiver la réécriture d'URL pour rendre les choses "plus équitables,", c'est peut-être le bon moment pour demander ce qui se passe normalement lorsque des demandes inhabituelles sont formulées.