Un message authentifié peut toujours contenir une demande frauduleuse. Cette déclaration ne signifie pas SPF, DKIM ou DMARC sans importance. Il définit leur limite.
L'authentification par courrier électronique fournit des preuves sur les identités de domaine et la gestion des messages. L'autorisation commerciale répond à une question différente : cette personne ou ce système était-il autorisé à faire cette demande, et l'organisation doit-elle y donner suite ? Un processus sûr a besoin des deux.
Demandez ce que le laissez-passer prouve réellement
Sous RFC 9989 §5.3.5 et RFC 9989 §5.4, une réussite DMARC au niveau du message signifie que le récepteur a trouvé au moins un chemin SPF ou DKIM de passage dont le domaine authentifié était aligné avec le domaine dans From. Cela ne prouve pas :
- quelle personne contrôlait le compte ;
- que le compte n'a pas été compromis ;
- qu'une facture ou un changement bancaire est légitime ;
- qu'un lien ou une pièce jointe est inoffensif ;
- que le domaine est la marque que le destinataire avait en tête.
La déclaration précise est utile : le message présentait un domaine From et produisait une preuve d'authentification qualificative liée à ce domaine. Évitez de le convertir en une affirmation plus large selon laquelle l’expéditeur ou le message est en sécurité.
Classer l’abus d’identité avant de choisir une réponse
Différentes attaques peuvent se ressembler dans une boîte de réception mais se situer de différents côtés de la frontière d’authentification.
- Modèle : contrefaçon de domaine exact ; Ce que l'authentification peut montrer : Aucun chemin de passage aligné, soumis à la preuve et au traitement du destinataire ; Objectif de contrôle et de réponse : politique DMARC , couverture de l'expéditeur, contrôles et enquête du destinataire
- Modèle: Domaine similaire; Ce que l'authentification peut montrer : le sosie peut authentifier son propre domaine avec succès ; Objectif de contrôle et de réponse : surveillance de domaine, signaux d'utilisateur, filtrage, signalement et action proportionnée en cas d'abus
- Modèle : tromperie du nom d'affichage ; Ce que l'authentification peut montrer : un domaine non lié peut s'authentifier tout en présentant un nom familier ; Focus sur le contrôle et la réponse : analyse du nom d'affichage, contexte, rapports des utilisateurs et vérification indépendante
- Modèle : compte autorisé compromis ; Ce que l'authentification peut montrer : le domaine réel peut passer l'authentification ; Priorité au contrôle et à la réponse : sécurité des comptes, enquête sur les sessions et les connexions, confinement et vérification de l'activité.
- Modèle : Fournisseur compromis ; Ce que l'authentification peut montrer : le domaine réel du fournisseur peut être transmis ; Priorité au contrôle et à la réponse : coordination des incidents avec les fournisseurs, contrôles des transactions et confirmation par d'autres canaux
DMARC est le plus efficace contre l'utilisation non autorisée de l'identité de domaine qu'il couvre. Il ne crée pas la propriété de domaines visuellement similaires, ne vérifie pas la véracité d'un nom d'affichage ou ne décide pas si un compte réel a été utilisé avec l'autorité appropriée.
Suivez un incident fictif de changement de paiement
Le scénario suivant est synthétique. Il est conçu pour montrer la chaîne de preuves sans impliquer un incident client.
Un employé des finances reçoit une demande de accounts@supplier.example demander de modifier ses coordonnées bancaires. En supposant une politique applicable, les résultats du récepteur de confiance montrent un pass DKIM aligné pour supplier.example, donc le message passe DMARC . L’historique du fil de discussion et le style d’écriture semblent également familiers.
L'employé n'approuve pas le changement sur la base de ces signaux. Ils appellent un numéro de fournisseur préalablement vérifié et apprennent que la boîte aux lettres a été compromise. L'organisation fige la modification demandée, conserve le message d'origine et fournit au fournisseur les horodatages et les en-têtes pertinents.
L'authentification a fonctionné comme prévu : elle a montré que le message utilisait le domaine authentifié du fournisseur. Le contrôle de vérification indépendant a arrêté une transaction non autorisée que l'authentification de domaine ne pouvait pas juger.
Préserver les preuves protocolaires et les preuves commerciales
En cas d'incident consécutif, conservez un message original à accès contrôlé avant de produire une copie expurgée. RFC 8601 §7.1 définit les limites des résultats fiables ; les modifications apportées au matériel signé peuvent affecter la revérification sous RFC 6376 §3.7. Les preuves techniques utiles peuvent inclure les éléments fiables Authentication-Results, les champs Reçu pertinents, De, Répondre à, Return-Path, signatures DKIM , identifiants de message, horodatages et journaux de réception.
Les preuves commerciales utiles comprennent la demande, l'action envisagée, les règles d'approbation établies, la méthode de contact utilisée pour la vérification et le résultat. Séparez les faits des inférences. Une passe brute ne constitue pas une preuve de compromission, et un échec DMARC ne constitue pas une preuve qu'un préjudice s'est produit.
Sous RFC 9990 §3.1, les rapports DMARC agrégés peuvent aider les propriétaires de domaines à comprendre les modèles d'authentification et de disposition observés. Ils ne constituent pas un enregistrement complet des messages individuels et ne fournissent généralement pas le contenu nécessaire pour décider si une demande particulière a été autorisée. Sous RFC 9989 §5.3.9, rapports d'échec, lorsqu'ils sont générés, nécessitent une gestion minutieuse de la confidentialité et des accès et ne sont pas universellement disponibles.
Intégrez une vérification indépendante dans les flux de travail sensibles
Les actions à fort impact doivent utiliser des contrôles qui ne dépendent pas uniquement du message entrant. Les exemples incluent :
- vérifier les modifications des coordonnées bancaires via un canal préalablement approuvé ;
- exiger une double approbation pour les paiements dépassant des seuils définis ;
- empêcher un fil de discussion de courrier électronique de fournir à la fois la demande et le contact de vérification ;
- utiliser des portails authentifiés pour l'échange de données sensibles ;
- traiter le secret urgent, le timing inhabituel ou le contournement du contrôle comme des signaux de risque.
Il s’agit de contrôles commerciaux et non de substituts à l’authentification. L'authentification réduit l'ambiguïté concernant l'utilisation du domaine, tandis que les contrôles de transactions réduisent les conséquences d'une demande authentifiée mais non autorisée.
Communiquer la frontière sans affaiblir le programme
Dire que DMARC ne s'arrête pas tous hameçonnage la technique est précise. Dire qu’il est donc inefficace ne l’est pas. Une politique appliquée peut réduire l’utilisation non autorisée d’un domaine protégé, améliorer la preuve du destinataire et rendre explicite la propriété des chemins d’envoi légitimes.
Le bon message est multiple : protégez le domaine, sécurisez les comptes, détectez les sosies et les présentations trompeuses, et vérifiez de manière indépendante les actions sensibles. Utilisez le Guide d'identité DMARC pour le résultat au niveau du domaine et le inventaire des expéditeurs pour la propriété d'un service autorisé.
Conserver la conclusion dans les preuves
Le cas fictif de changement de paiement conserve deux résultats indépendants : l'authentification du domaine est réussie ; la transaction proposée n'a pas été approuvée après une vérification séparée. Ne signalez pas la compromission d’un seul laissez-passer. Conservez uniquement les divulgations d’incidents autorisées et conservez un contact de vérification de confiance en dehors de la demande entrante. Aucun fournisseur n’a été contacté et aucune transaction ou réponse à incident n’a été effectuée.