Les organisations ont beaucoup investi dans l’authentification des courriels. Les domaines principaux sont de plus en plus protégés par SPF, DKIM et DMARC, tandis que les équipes de sécurité surveillent les échecs d’authentification et œuvrent à un renforcement des politiques. Pourtant, une autre partie du portefeuille de domaines reçoit souvent beaucoup moins d’attention : les domaines dont plus personne ne se souvient qu’ils sont détenus.

Quelque part dans le portefeuille de domaines d’une organisation, il peut y avoir un domaine acheté pour une campagne de marketing il y a des années, hérité lors d’une acquisition ou enregistré par quelqu’un qui a depuis changé d’équipe. Il se peut qu’il n’ait aucun site web, n’envoie pas de courriel et n’apparaisse dans aucun registre d’actifs, mais qu’il continue à être renouvelé chaque année.

Puisqu’il n’envoie pas de courriel, personne n’a peut-être configuré DMARC dessus. Cela peut laisser le domaine sans les mêmes protections appliquées au domaine principal de courriel de l’organisation, créant ainsi une opportunité pour un attaquant d’envoyer des messages se faisant passer pour l’organisation.

Nous avons fait les devoirs. Nous n’avons peut-être pas retenu la leçon.

Le secteur a fait des progrès significatifs en matière d’authentification des courriels. Les exigences introduites par les principaux fournisseurs de boîtes aux lettres, dont Google, Yahoo et Microsoft, ont accéléré l’adoption de DMARC, particulièrement auprès des organisations qui envoient des courriels en masse. Toutefois, l’adoption n’est pas synonyme de mise en application.

Un domaine publiant DMARC avec p=none surveille l’activité d’authentification ; il n’ordonne pas aux systèmes destinataires de mettre en quarantaine ou de rejeter les messages qui échouent DMARC. L’application de la politique commence par des politiques telles que p=quarantine ou p=reject. Il y a une raison pour laquelle les organisations hésitent à effectuer cette transition. Passer un domaine d’envoi actif en mode enforcement peut révéler une compréhension incomplète de qui est autorisé à envoyer des courriels au nom de l’organisation. Il pourrait y avoir une plateforme de marketing non documentée, un système de facturation hérité lors d’une acquisition, une unité d’affaires régionale utilisant un fournisseur externe ou une application qui envoie des courriels discrètement depuis des années. Pour cette raison, p=none peut constituer une étape diagnostique utile. Le problème survient lorsque cette étape devient l’état permanent du domaine.

Cela met en lumière un enjeu plus large dans les programmes DMARC des entreprises : le plus grand obstacle n’est souvent pas la configuration DNS ou la technologie, mais plutôt la notion de propriété. Le marketing peut posséder certains expéditeurs, les RH d’autres, les unités commerciales régionales peuvent exploiter des systèmes méconnus du siège, et la sécurité gérer la politique d’authentification sans posséder les expéditeurs sous-jacents.

DMARC est un problème de propriété déguisé en enjeu DNS

Demandez à une organisation quelle est sa posture DMARC et la conversation commence généralement par son domaine principal de production. Demandez combien de domaines l’organisation possède réellement, et la réponse est souvent beaucoup moins certaine. Les grandes entreprises possèdent généralement beaucoup plus de domaines qu’elles n’en utilisent pour le courriel. On trouve des enregistrements défensifs, des variantes nationales, des anciens domaines de campagne, de vieux noms de marque et des domaines hérités d’acquisitions. Certains existent principalement pour protéger des marques ou prévenir les imitations évidentes. Un programme DMARC ciblant seulement les domaines qui envoient des courriels peut ainsi laisser une partie du portefeuille exposée.

Un attaquant peut consulter les informations SPF, DKIM et DMARC via le DNS public et identifier où l’authentification est appliquée et où elle est absente. Un domaine de production principal avec une forte authentification peut simplement être ignoré. Un ancien domaine régional sans enregistrement DMARC pourrait offrir une opportunité plus facile. Il n’y a rien de vraiment sophistiqué dans cette approche. Un attaquant n’a pas besoin de contourner les meilleures défenses d’une organisation si une autre partie du portefeuille de la marque reste sans protection.

Les domaines les plus faciles à corriger sont souvent ceux que personne ne surveille

Chaque domaine ne présente pas le même défi. Passer un domaine fortement utilisé à l’application DMARC peut exiger une enquête approfondie sur les expéditeurs légitimes, les services tiers, les pratiques de redirection et les dépendances d’affaires. Un domaine véritablement stationné ou inactif est différent.

Si le domaine a été vérifié comme étant inactif, il se peut qu’aucun inventaire d’expéditeurs légitimes n’ait à être réconcilié et qu’aucune application d’affaires ne risque d’être perturbée. Ainsi, de solides contrôles de courriel peuvent souvent être introduits avec un impact commercial minimal. Selon l’objectif et l’architecture du domaine, les contrôles peuvent inclure :

• SPF : Publier une politique n’autorisant aucun expéditeur, le cas échéant.
• DMARC : Appliquer une politique d’enforcement telle que p=reject, incluant les contrôles appropriés pour les sous-domaines.
• DKIM : S’assurer qu’il n’y a pas de configuration de signature active pouvant être utilisée à mauvais escient.
• MX : Utiliser une configuration MX nulle si le domaine ne doit pas recevoir de courriel.

La configuration exacte devrait toujours être validée en fonction de l’utilisation visée du domaine. La leçon plus large est plus importante que la configuration DNS elle-même : les organisations ne peuvent pas protéger ce qu’elles ignorent posséder. Cela fait du registraire de domaines un point de départ important pour un programme DMARC d’entreprise. Il peut révéler des domaines disparus des registres d’actifs, des inventaires de sécurité et des processus d’affaires mais qui n’ont jamais disparu d’Internet.

La limite supérieure : DMARC ne peut pas tout protéger pour votre marque

Une organisation peut sécuriser tous les domaines qu’elle détient et pourtant se faire usurper. DMARC aide à établir si un courriel prétendant venir d’un domaine est authentifié selon les politiques publiées de ce domaine. Il n’établit pas si le domaine lui-même est légitime. Un attaquant peut enregistrer un domaine semblable en utilisant une substitution subtile de caractères, un autre domaine de premier niveau ou un nom visuellement proche conçu pour tromper un destinataire. L’attaquant peut ensuite configurer correctement SPF, DKIM et DMARC. Le message qui en résulte peut passer l’authentification puisque, techniquement, il s’agit d’un courriel authentique provenant de ce domaine. Le problème est que le domaine lui-même est frauduleux.

DMARC n’établit pas non plus l’intention de la personne qui utilise un compte légitime. Pensez à une boîte courriel de fournisseur compromise : un attaquant peut répondre dans une conversation de facture existante en utilisant l’historique, la signature et le ton appropriés. SPF, DKIM et DMARC peuvent tous réussir, car le domaine expéditeur est légitime. Le courriel est authentique, mais la transaction ne l’est pas. GenAI ajoute une autre dimension. Les fautes de grammaire et formulations maladroites qui aidaient autrefois les employés à repérer les messages suspects deviennent des indicateurs moins fiables. L’authentification demeure essentielle, mais elle ne peut être traitée comme une preuve absolue de sécurité du courriel.

Commencez par votre propre liste

Un programme de sécurité du courriel mature devrait commencer par une question en apparence simple : quels domaines l’organisation possède-t-elle réellement ?

À partir de là, les responsables de la sécurité peuvent se concentrer sur cinq priorités :

1. Mesurer l’application, pas seulement l’adoption. Une politique p=none apporte de la visibilité sans réellement protéger contre les courriels non authentifiés.
2. Compter tous les domaines, pas seulement ceux qui envoient des courriels. La couverture doit être mesurée pour l’ensemble du portefeuille de domaines.
3. Sécuriser les domaines réellement stationnés. Les domaines vérifiés comme non-expéditeurs peuvent souvent être protégés avec peu d’impact commercial.
4. Trouver le propriétaire avant l’outil. Déterminez qui possède chaque domaine, l’inventaire des expéditeurs et qui a l’autorité sur l’authentification du courriel.
5. Considérer l’authentification comme un plancher, non un plafond. Les domaines ressemblants, les comptes compromis, la prise de contrôle de conversation, les compromissions de fournisseurs et les attaques propulsées par l’AI exigent des contrôles additionnels.

La technologie peut identifier le problème, mais seule une responsabilité claire permet à l’organisation de le résoudre.

La liste, c’est la surface d’attaque

Le domaine qu’une organisation a oublié posséder porte encore son nom. Un attaquant se moque qu’il soit oublié en interne ; ce qui compte, c’est si les clients, employés et partenaires pourraient le reconnaître et faire confiance à un message reçu de ce domaine. Le domaine de production est protégé parce que tout le monde sait qu’il est important. Le domaine oublié peut rester exposé parce que personne ne se souvient de son existence. Pourtant, les deux appartiennent à la même organisation et peuvent être découverts via la même infrastructure publique. L’organisation et l’attaquant travaillent donc à partir de la même liste. La différence, c’est que l’attaquant a peut-être déjà lu la liste jusqu’au bout. Une stratégie de sécurité du courriel résiliente ne s’arrête pas au domaine connu de tous. Elle commence par retrouver les domaines dont personne ne se souvient.