Un service légitime peut répondre à une demande illégitime. Un utilisateur peut abuser des fonctionnalités normales de partage ou de notification d'une plateforme, un compte peut être compromis ou un expéditeur autorisé peut faire une demande commerciale non autorisée. L'authentification de domaine peut identifier correctement le service ou l'expéditeur configuré tout en laissant ces risques non résolus. L’enquête doit expliquer ces deux faits sans qualifier chaque message malveillant transmis d’échec d’authentification.
Distinguer le service de la demande
Enregistrez le domaine d'origine réel, le domaine de signature, l'identité de l'enveloppe et les liens dans le message. Déterminez quelles identités appartiennent au service et lesquelles appartiennent à un domaine contrôlé par le client. Ne présumez pas qu’un logo familier ou un nom d’affichage visible signifie que le message provient de l’organisation usurpée. DKIM associe un domaine de signature à un message ; il ne certifie pas la véracité des déclarations du message. RFC 6376.
Demandez ce que la plateforme a réellement authentifié. Il peut avoir authentifié une session de compte, un domaine configuré ou un workflow de notification. Aucun n’établit nécessairement que le propriétaire du compte avait l’intention de modifier le paiement ou qu’un document partagé est sûr. Gardez ces questions ouvertes jusqu'à ce qu'il y ait des preuves de la part du propriétaire du service et du destinataire de l'entreprise.
Construire une matrice d’exigences et de preuves
Utilisez des lignes distinctes pour l'authentification de domaine, le contrôle de compte, la révision du contenu et l'approbation commerciale. Chaque ligne nécessite une exigence, des preuves, une confiance, un propriétaire et l'action suivante. Une signature alignée peut satisfaire une ligne d'authentification de domaine étroite sans satisfaire les autres. RFC 9989 décrit DMARCla portée basée sur le domaine plutôt qu'une garantie générale sur le contenu. Spécification DMARC.
Pour une demande financière, une vérification indépendante est particulièrement importante. Utilisez un itinéraire de contact connu plutôt que le numéro de téléphone ou l'adresse de réponse nouvellement fourni dans le message. Le FBI recommande de vérifier de manière indépendante les demandes de paiement et les modifications apportées aux détails du compte. Conseils du FBI.
Lire l'exemple de charge de travail transparente
L'exemple écrit suppose un message de modification de paiement avec une authentification alignée, aucune approbation commerciale et un contact fournisseur connu refusant la modification. Sa matrice conserve donc le pass d'authentification tout en gardant en attente le changement de paiement. Cela ne permet pas de savoir si un compte a été compromis, si une fonctionnalité du service a été utilisée de manière abusive ou si l'expéditeur présumé a participé.
Le même modèle hypothétique utilise une charge de travail mensuelle illustrative de 10 000 messages, un taux de sélection de révision de 1 % et quatre minutes par message sélectionné. L’arithmétique donne 100 avis et environ 6,67 heures d’analyste. Il s’agit d’hypothèses de planification, et non de taux d’abus de plateforme mesurés, de références en matière de personnel ou de prix des fournisseurs. Ils excluent l'escalade des enquêtes, les week-ends, le traitement des faux positifs et la coordination des incidents. Ils ne constituent donc pas une estimation complète des coûts d'exploitation.
Enquêter sans surbloquer
Conservez les identifiants de message et les références d’objets spécifiques au fournisseur si disponibles, mais évitez de diffuser inutilement le contenu des documents sensibles. Demandez au propriétaire du service autorisé d'enquêter sur l'activité du compte, les paramètres de partage et les journaux d'audit. Toute mesure de confinement doit être limitée à la menace vérifiée et autorisée par le processus de réponse de l'organisation.
Le blocage d'un service populaire dans son intégralité peut interrompre des flux de travail légitimes sans résoudre la compromission du compte ailleurs. Déterminez si une action plus précise en matière d'expéditeur, d'objet, d'URL ou de compte est prise en charge et appropriée. Il s'agit de critères de décision, et non d'instructions pour effectuer un retrait ou modifier le compte d'une autre personne sans autorisation.
Terminez avec les faits d'identité prouvés, les explications causales non vérifiées, le résultat commercial et le propriétaire de la réponse. Si le service reste utilisable, conservez sa configuration d’authentification tout en traitant du chemin d’abus. Supprimer DKIM pour éviter toute apparence de confiance affaiblirait un signal utile sans sécuriser le contenu. L’objectif est d’interpréter correctement ce signal et d’ajouter les vérifications indépendantes requises par la demande.
Gardez quatre lignes de preuves distinctes
Pour ce cas inventé, l'authentification de domaine est stipulée pass ; l'administrateur de messagerie est propriétaire de la vérification des preuves de réception réelles. Le contrôle des comptes est inconnu ; le propriétaire du service autorisé doit examiner l'activité réelle du compte. La sécurité du contenu n'est pas résolue ; la sécurité est propriétaire de l'examen du contenu limité. L'approbation commerciale est absente et le fournisseur connu stipulé refuse la demande ; La finance conserve le blocage des paiements. Aucun véritable fournisseur n'a été contacté, aucun compte n'a fait l'objet d'une enquête et aucun paiement n'a été modifié. L’exemple fournit une structure décisionnelle, et non des preuves identifiant un auteur.
Limite source et exécution
RFC 9989 sections 4.4, 5.3.5 et 5.4 distinguer l'authentification, alignement et manipulation ; un laissez-passer n'approuve pas le contenu du message. Les décisions opérationnelles ici sont des recommandations ciblées et des exemples explicitement hypothétiques, et non de nouveaux tests d'un client, d'un fournisseur ou d'un élément historique. Tout changement réel nécessite sa propre portée autorisée, des preuves conservées et une décision responsable.