Un directeur financier doit se demander comment une organisation vérifie une demande de transfert d'argent, et pas seulement si son domaine de messagerie réussit l'authentification. L'authentification de domaine aide les destinataires à évaluer l'utilisation d'un domaine. Il ne certifie pas une facture fournisseur, ne confirme pas un changement de compte bancaire ou ne prouve pas que l'humain derrière un compte légitime est autorisé à faire une demande.
Distinguer trois chemins de fraude
L'usurpation d'identité de domaine directe utilise votre domaine sans l'authentification alignée requise. Une attaque similaire utilise un domaine différent qui ressemble à un domaine de confiance. Une attaque de compte compromis peut provenir d’un service légitime et authentifié. Ces chemins nécessitent des preuves différentes et ne peuvent pas tous être fermés en publiant une politique plus stricte sur votre domaine.
RFC 9989 explique l'authentification alignement avec le domaine de l'auteur. Un résultat réussi pour billing-supplier.example contrôlé par un attaquant n'établit pas qu'il appartient à un véritable fournisseur. Les noms d’affichage et les destinations de réponse peuvent également induire les lecteurs en erreur ; enregistrez-les séparément du domaine évalué par DMARC.
Inspecter le chemin de décision
Demandez aux opérations financières comment les modifications de paiement sont vérifiées à l'aide des informations de contact établies avant la demande suspecte. Un numéro de téléphone ou un lien fourni dans le même e-mail ne constitue pas une voie de vérification indépendante. Utilisez le flux de travail et la séparation des tâches approuvés par l'organisation, en particulier pour les modifications des coordonnées bancaires ou les exceptions de paiement urgentes.
Le scénario fictif écrit ci-dessous décrit un message affichant « Comptes fournisseurs » alors que le domaine visible De est un sosie contrôlé par l'attaquant. Son résultat de réception est une passe synthétique alignée pour cela domaine similaire. L'action demandée est une modification des coordonnées bancaires, les numéros de compte étant omis. Aucun incident client réel ni instruction de paiement réelle n’est représenté.
Tester la limite de contrôle
Le domaine de fournisseur légitime de l'exemple est supplier.example .test ; l'expéditeur observé utilise supplier-payments.example .test. Finance suspend la modification et appelle un contact préalablement vérifié à partir de la fiche fournisseur. Le contact fictif refuse la demande. Cette vérification commerciale fait partie du scénario et non d'une conversation réelle menée pour ce point de contrôle.
Comparez deux itinéraires de vérification stipulés. Le cas A utilise le contact de l'enregistrement principal du fournisseur préexistant, supposé vérifié de manière indépendante avant la demande suspecte ; le déni fictif maintient le changement en suspens. Le cas B utilise uniquement un numéro fourni par l'e-mail suspect ; la vérification est insuffisante et le changement reste en attente. Aucun des deux cas n’a été calculé, appelé ou vérifié par rapport à un répertoire réel. Il s’agit d’un exemple de contrôle éditorial et non d’une procédure financière obligatoire.
Demander des preuves de fonctionnement courant
Demandez des échantillons de preuves démontrant que des rappels et des doubles approbations se produisent, que les exceptions sont remontées et que les anomalies du domaine de l'expéditeur parviennent au personnel financier dans des termes compréhensibles. Demandez à qui appartient la correction des domaines non protégés et à qui appartiennent les échecs du processus de paiement. Gardez les rapports proportionnels : un nombre de messages DMARC ayant échoué n'est pas un nombre de paiements frauduleux évités.
Si une demande de paiement suspecte arrive, conservez le message et les enregistrements du destinataire correspondant, suivez le processus d'incident de l'organisation et vérifiez indépendamment la demande avant d'agir. L'authentification est une preuve précieuse, mais la décision de transférer de l'argent doit reposer sur le processus commercial autorisé. Ne laissez pas un taux de réussite impressionnant remplacer ce processus.
Demandez une carte de pointage de contrôle limitée
Demandez le nombre de modifications de paiement échantillonnées, combien ont fait l'objet d'une vérification indépendante documentée, les exceptions non résolues et leurs propriétaires. Gardez cela séparé du nombre de messages DMARC . Les preuves manquantes constituent une lacune sur laquelle enquêter, et non une preuve qu'une fraude a eu lieu ou qu'une perte financière déclarée a été évitée.