Traitez l’autorité de paiement comme une question distincte
L'e-mail d'un fournisseur peut être correctement authentifié tout en contenant une demande de modification de paiement non autorisée. Une boîte aux lettres ou une application compromise peut utiliser l'infrastructure d'envoi légitime du fournisseur, tandis qu'un usurpateur d'identité peut utiliser un domaine différent avec un nom d'affichage familier. La question commerciale immédiate est de savoir si la modification demandée est autorisée, et non si le message contient le mot de passe. Séparez la décision financière de l’enquête technique afin qu’aucune ne se substitue à l’autre.
RFC 9989 limites DMARC aux relations d'authentification de domaine et exclut explicitement l'analyse de contenu et l'authentification d'entités autres que les domaines. Il ne peut pas approuver un changement de compte bancaire ni établir les intentions d'un employé d'un fournisseur. Un résultat positif est une preuve utile de l’utilisation du domaine, mais il ne s’agit pas d’une instruction de paiement que l’organisation doit suivre. Ce manuscrit propose un processus défensif ; aucun paiement, mise à jour du compte ou contact externe n'a été effectué.
Conserver la requête sans l'exécuter
Mettez la modification demandée en attente via le processus d’achat ou de financement existant. Enregistrez ce que le message demande de modifier, quel enregistrement de fournisseur il affecte, quand le changement est censé prendre effet et qui l'a reçu. Évitez de copier tous les détails financiers dans un ticket d’incident largement accessible. Un enregistrement restreint approuvé peut conserver l'original tandis que le résumé de travail décrit le changement à l'aide d'un identifiant de référence et du contexte minimum nécessaire.
Conservez le message original et sa provenance. Une copie ou une capture d'écran transférée peut aider à montrer comment la demande est apparue, mais elle n'est pas interchangeable avec le message d'origine ou les journaux du destinataire. Enregistrez l’heure et le fuseau horaire de la collecte. Si quelqu'un a déjà agi, faites remonter la situation en suivant la procédure d'incident financier établie par l'organisation plutôt que de supposer que le changement peut être annulé en silence. Cet article n'autorise pas les virements, rappels ou communications avec une banque.
Déterminer quelle identité a été utilisée
Comparez le domaine De réel avec le domaine du fournisseur dans l'enregistrement du fournisseur approuvé. Conservez le nom d'affichage, l'adresse de réponse, l'identité de l'enveloppe et DKIM domaine de signature séparé. Un message appartenant à un domaine différent peut s'authentifier pour son propre domaine tout en induisant le lecteur en erreur sur l'affiliation. Un message exact du domaine du fournisseur avec une authentification alignée peut toujours provenir d'un compte ou d'un service abusé. Ne sélectionnez pas l’hypothèse de compromis uniquement parce que la demande est inhabituelle.
Utilisez la preuve d’un destinataire fiable lors de l’interprétation de l’authentification. RFC 8601 explique pourquoi Authentication-Results les champs nécessitent une limite de confiance. Une ligne fournie par l'expéditeur, une capture d'écran ou un extrait d'en-tête transmis peuvent ne pas établir l'évaluation du destinataire concerné. Enregistrez quel récepteur a produit le résultat et quel chemin aligné a été observé. Lorsque les preuves sont incomplètes, dites-le au lieu d’imposer une conclusion de réussite ou d’échec dans la décision financière.
Vérifier via un itinéraire indépendant établi
Le Avis BEC par courrier électronique cloud IC3, publié le 6 avril 2020, recommande une vérification indépendante des demandes commerciales suspectes. Utilisez un itinéraire de contact avec le fournisseur qui a été établi avant la demande douteuse, comme l'enregistrement du fournisseur vérifié existant de l'organisation. Un nouveau numéro de téléphone, une autre adresse e-mail ou un lien de vérification fourni uniquement dans ce message ne constitue pas une source indépendante. L'avis cité soutient ce principe général, et non une réclamation d'incident actuelle.
Demandez au vérificateur commercial agréé de confirmer le changement spécifique proposé via le processus établi. Confirmer qu'une personne reconnaît le nom de l'expéditeur est plus faible que confirmer que le changement lui-même a été demandé et approuvé. Lorsque la politique nécessite des approbateurs distincts, préservez cette séparation. Ne laissez pas l'urgence du message remplacer les exigences d'approbation de l'organisation. L'analyste technique peut fournir des preuves d'identité mais ne doit pas devenir silencieusement l'approbateur financier.
Coordonner soigneusement l’enquête technique
Si des preuves indiquent un abus du compte du fournisseur, communiquez via un contact vérifié approuvé et partagez uniquement les preuves expurgées pertinentes après autorisation. L'intervenant autorisé du fournisseur est responsable de l'enquête sur ses systèmes. L'organisation destinataire ne doit pas affirmer qu'elle a prouvé une prise de contrôle par un fournisseur simplement parce qu'un message authentifie et que le fournisseur a refusé la demande de paiement. Une intégration, un expéditeur délégué ou un autre mécanisme peut nécessiter une enquête.
Conseils de Microsoft sur les comptes compromis répertorie les règles de boîte de réception suspectes, les messages de transfert et manquants parmi les indicateurs possibles, et décrit la réponse du compte pour Microsoft 365 . Il s'agit d'une référence pour un fournisseur autorisé dans cet environnement, et non d'une autorisation d'inspecter les comptes d'une autre organisation. Aucun accès au compte, révocation de session, suppression de règles ou collecte d'informations d'identification ne fait partie du travail de ce manuscrit.
Une feuille de travail sur les preuves de changement de paiement
Créez une feuille de calcul avec quatre sections liées. La section demande enregistre la référence du fournisseur, le type de changement, la date demandée et le propriétaire de l'entreprise. La section d'identité enregistre les domaines réels, les observations d'authentification fiables et la source des preuves. La section de vérification enregistre l'itinéraire de contact établi de manière indépendante, le vérificateur autorisé, la question et la réponse précises. La section de décision enregistre l'approbation ou le rejet, les approbateurs requis, le chemin de mise en œuvre autorisé et toute enquête non résolue.
Gardez les identifiants de compte financier hors des copies à usage général. Utilisez des espaces réservés cohérents là où la comparaison est importante et stockez l'original complet uniquement dans un emplacement restreint approuvé. Ajoutez une colonne distinguant les faits observés des hypothèses. « DKIM aligné sur le domaine du fournisseur observé chez notre récepteur » n'est un fait que si les preuves le soutiennent ; « L'employé du fournisseur a approuvé le changement » nécessite une confirmation commerciale distincte. La feuille de calcul ne doit jamais promouvoir automatiquement le premier dans le second.
Diagnostic fictif : un fil conducteur familier pour les fournisseurs
Une équipe d'installations fictives reçoit une demande lors d'une conversation établie avec un fournisseur demandant de modifier les détails des futurs paiements. Le message utilise le domaine réel du fournisseur et transmet hypothétiquement DMARC au destinataire. Le destinataire suppose que le fil de discussion existant et le résultat de l'authentification sécurisent la modification. À la place, un deuxième réviseur suspend la mise à jour et vérifie l'enregistrement du fournisseur approuvé pour connaître l'itinéraire de vérification établi.
Dans l'exercice, le contact du fournisseur nie avoir autorisé le changement. Cette réponse soutient le rejet de la demande dans le cadre du processus commercial, mais le mécanisme reste en suspens jusqu'à ce que des preuves techniques autorisées soient disponibles. L’enquête préserverait le message et partagerait un résumé minimal approuvé plutôt que de transmettre largement les détails complets du paiement. Il s’agit d’un scénario fictif, et non d’un véritable déni, d’une découverte de compromission, d’un appel de vérification ou d’une perte évitée. Il illustre pourquoi la vérification commerciale et l'authentification de domaine répondent à des questions différentes.
Clôturer séparément les pistes financières et techniques
Enregistrez la décision relative à la modification demandée même si l'enquête technique se poursuit. À l’inverse, ne déclarez pas le problème commercial résolu simplement parce qu’un compte a été sécurisé : quelqu’un a peut-être déjà modifié la fiche d’un fournisseur ou donné suite à la demande. Rapprochez le dossier commercial réel avec la décision autorisée et le document qui a vérifié le résultat. Une telle action nécessite l'autorité normale de l'organisation ; aucun n'a été réalisé ici.
Le catalogue nécessite un scénario d'abus expurgé avec preuve d'identité, limite de contrôle et vérification commerciale indépendante. Cette preuve originale reste ouverte. La fiche de travail et l’exercice fictif proposés ne le satisfont pas. L'examen par un spécialiste humain, l'applicabilité des sources, les itinéraires de production, l'accessibilité et la libération par le propriétaire restent également ouverts. Une version publiable nécessite un ensemble de preuves autorisées qui démontrent le processus de vérification sans exposer les identifiants financiers ni faire d'allégations non étayées sur un fournisseur.