Les organisations ont beaucoup investi dans l’authentification des courriels. Les domaines principaux sont de plus en plus protégés par SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail) et DMARC (Domain-based Message Authentication, Reporting and Conformance), alors que les équipes de sécurité surveillent les échecs d’authentification et travaillent à renforcer l’application des mesures. Pourtant, une autre partie du portefeuille de domaines reçoit souvent beaucoup moins d’attention : les domaines dont personne ne se souvient qu’ils les possèdent.

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

Parce qu’il n’envoie aucun courriel, il se peut que personne n’ait configuré DMARC pour ce domaine. Cela peut laisser le domaine sans les mêmes protections que le domaine principal de courriels de l’organisation, ce qui crée une occasion pour un attaquant d’envoyer des messages en prétendant représenter l’organisation.

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

Le secteur a fait des progrès importants en matière d’authentification des courriels. L’introduction d’exigences par de grands fournisseurs de boîtes de messagerie, tels que Google, Yahoo et Microsoft, a accéléré l’adoption de DMARC, surtout chez les organisations qui envoient des courriels à grande échelle. Cependant, l’adoption n’est pas synonyme d’application.

Un domaine publiant DMARC avec p=none surveille l’activité d’authentification; il n’indique pas aux systèmes de réception de mettre en quarantaine ou de rejeter les messages qui échouent DMARC. L’application commence avec des politiques telles que p=quarantine ou p=reject. Il y a une raison pour laquelle les organisations peuvent hésiter à faire cette transition. Passer à l’application sur un domaine utilisé activement peut révéler une compréhension incomplète de qui est autorisé à envoyer des courriels au nom de l’organisation. Il se peut qu’il existe une plateforme marketing non documentée, un système de facturation hérité lors d’une acquisition, une unité régionale utilisant un fournisseur tiers ou une application qui envoie discrètement des courriels depuis des années. Pour cette raison, p=none peut être une étape diagnostique précieuse. Le problème survient lorsque cette étape diagnostique devient l’état permanent du domaine.

Cela met en évidence un enjeu plus large des programmes DMARC d’entreprise : le principal obstacle n’est souvent pas la configuration DNS ou la technologie, mais bien la propriété. Le marketing peut posséder certains expéditeurs, les RH d’autres, les unités d’affaires régionales peuvent exploiter des systèmes inconnus du siège social et la sécurité peut contrôler la politique d’authentification sans détenir les expéditeurs sous-jacents.

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

Quand on demande à une organisation quelle est sa posture DMARC, la conversation commence généralement par son domaine principal de production. Demandez combien de domaines possède réellement l’organisation et la réponse peut être beaucoup moins certaine. Les grandes entreprises possèdent habituellement beaucoup plus de domaines qu’elles n’en utilisent pour le courriel. Il y a les enregistrements défensifs, les variantes par pays, les anciens domaines de campagnes, les marques héritées et les domaines acquis lors d’acquisitions. Certains existent principalement pour protéger les marques ou éviter les imitations évidentes. Un programme DMARC axé uniquement sur les domaines qui envoient des courriels peut donc laisser une partie du portefeuille exposée.

Un attaquant peut examiner les informations SPF, DKIM et DMARC via les DNS publics et identifier où l’authentification est appliquée ou absente. Un domaine principal avec une forte authentification peut simplement être évité. Un ancien domaine régional sans enregistrement DMARC peut représenter une opportunité plus facile. Cette approche n’a rien de particulièrement sophistiqué. Un attaquant n’a pas besoin de surpasser les défenses les plus solides de l’organisation si une autre partie de la même marque reste non protégée.

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

Chaque domaine ne pose pas le même défi. Passer un domaine très utilisé à l’application DMARC peut exiger une analyse approfondie des expéditeurs légitimes, des services tiers, du comportement de transfert et des dépendances d’affaires. Un domaine véritablement inutilisé, ou qui n’envoie aucun courriel, est différent.

Si le domaine a été vérifié comme inactif, il se peut qu’il n’y ait aucun expéditeur légitime à recenser et aucune application d’affaires à interrompre. De forts contrôles sur les courriels peuvent alors souvent être introduits sans grand impact opérationnel. Selon la finalité et l’architecture du domaine, les contrôles peuvent inclure :

• SPF : Publier une politique qui n’autorise aucun expéditeur, le cas échéant.
• DMARC : Appliquer une politique d’application telle que p=reject, y compris les contrôles appropriés pour les sous-domaines.
• DKIM : S’assurer qu’aucune configuration de signature active ne pourrait être mal utilisée.
• MX : Utiliser une configuration MX nulle lorsque le domaine ne doit pas recevoir de courriels.

La configuration exacte doit toujours être validée selon l’utilisation prévue du domaine. La plus grande leçon est plus importante que la configuration DNS elle-même : les organisations ne peuvent pas protéger ce qu’elles ne savent pas 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, inventaires de sécurité et processus d’affaires, mais jamais disparus d’internet.

Le plafond : DMARC ne peut pas tout protéger pour votre marque

Une organisation peut sécuriser tous ses domaines et être tout de même usurpée. DMARC aide à déterminer si un courriel prétendument émis 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 ressemblant, utilisant une substitution subtile de caractère, une autre extension ou un domaine visuellement similaire conçu pour tromper le destinataire. L’attaquant peut ensuite configurer correctement SPF, DKIM et DMARC. Le message résultant peut passer l’authentification parce qu’il s’agit, techniquement, d’un courriel authentique de ce domaine. Le problème, c’est que le domaine lui-même est frauduleux.

DMARC n’établit pas non plus l’intention de la personne qui opère un compte légitime. Pensez à une boîte courriel de fournisseur compromise : un attaquant peut répondre dans une discussion existante de facturation en utilisant l’historique, la signature et le ton corrects. SPF, DKIM et DMARC peuvent tous réussir parce que le domaine d’envoi est légitime. Le courriel est authentique, mais la transaction ne l’est pas. GenAI ajoute une autre dimension. Les fautes grammaticales et tournures maladroites qui aidaient autrefois à repérer les messages suspects deviennent moins fiables. L’authentification demeure essentielle, mais elle ne doit pas être considérée comme une preuve que le courriel est sûr.

Lisez d’abord votre propre liste

Un programme mature de sécurité du courriel 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. Mesurez l’application, pas seulement l’adoption. Une politique p=none donne de la visibilité mais ne protège pas activement contre les courriels non authentifiés.
2. Comptez tous les domaines, pas seulement ceux qui envoient des courriels. La couverture doit être mesurée à l’échelle de tout le portefeuille de domaines.
3. Verrouillez les domaines réellement stationnés. Les domaines vérifiés comme n’envoyant pas de courriels peuvent souvent être sécurisés avec un impact minimal sur les affaires.
4. Trouvez le propriétaire avant de trouver l’outil. Établissez qui possède chaque domaine et l’inventaire des expéditeurs et qui détient l’autorité sur l’authentification des courriels.
5. Considérez l’authentification comme la base, non le sommet. Les domaines ressemblants, comptes compromis, détournement de conversation, compromission de fournisseur et attaques activé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 est la surface d’attaque

Le domaine qu’une organisation a oublié de posséder porte encore son nom. Un attaquant se soucie peu que personne à l’interne ne s’en souvienne; ce qui importe, c’est que des clients, employés ou partenaires pourraient le reconnaître et faire confiance à un message envoyé à partir de celui-ci. Le domaine de production est protégé parce que tout le monde sait qu’il compte. Le domaine oublié peut demeurer exposé parce que personne ne se souvient de son existence. Pourtant, les deux appartiennent à la même organisation et peuvent être trouvés 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 l’a peut-être déjà lue jusqu’au bout. Une stratégie de sécurité du courriel résiliente ne s’arrête pas au domaine que tout le monde connaît. Elle commence par trouver les domaines que personne ne se rappelle.