Commencez par l'identité, pas par l'étiquette de l'incident
Compromission de la messagerie professionnelle décrit un scénario commercial nuisible, et non un résultat unique d'authentification de courrier électronique. Une demande trompeuse peut provenir d'un domaine usurpant l'identité, d'une boîte aux lettres d'un fournisseur compromise, d'un compte interne abusé ou d'une application non autorisée utilisant une infrastructure d'envoi légitime. L'enquête doit établir quelle identité a été présentée, quel système l'a authentifiée et quelle autorité commerciale le destinataire pensait qu'elle représentait. Sans cette séparation, une équipe peut réparer un mauvais contrôle alors que le risque sous-jacent demeure.
Le Avis par courrier électronique basé sur le cloud IC3, daté du 6 avril 2020, décrit comment les comptes de messagerie cloud compromis peuvent prendre en charge BEC et recommande une vérification indépendante et des protections de compte. Il s’agit d’informations contextuelles et non d’une preuve d’un incident en cours. Conseils de Microsoft sur les comptes compromis décrit également les abus de boîtes aux lettres et les enquêtes dans Microsoft 365 . Aucune des deux sources n’établit qu’un compte discuté dans un exercice hypothétique ait réellement été compromis.
Conserver la demande et suspendre l'action commerciale
La première question opérationnelle est ce que le message demande à quelqu'un de faire : modifier les détails du paiement, divulguer des informations, approuver l'accès, modifier un enregistrement de fournisseur ou prendre une autre action consécutive. Enregistrez l'action dans un langage neutre. Suspendez l'exécution via le processus établi par l'organisation lorsque la demande est suspecte. Évitez de transformer l’enquête elle-même en un paiement, un changement de compte ou une divulgation non autorisé. Un analyste peut documenter la demande sans y donner suite.
Conservez le message original et le dossier commercial pertinent dans un emplacement restreint approuvé. Une capture d'écran peut montrer une présentation mais ne peut pas remplacer une preuve complète du message. Une copie transférée peut modifier le contexte et ajouter des en-têtes ; étiquetez-le en conséquence. Gardez une chronologie avec les fuseaux horaires et identifiez qui a collecté chaque élément. Pour une synthèse partagée, supprimez les données personnelles inutiles tout en conservant les distinctions nécessaires à la comparaison des identités. Ne diffusez pas d’informations d’identification, de jetons d’accès et ne complétez pas de correspondance sensible comme matériel de dépannage de routine.
Construire une pile d'identité
Répertoriez le nom d'affichage visible, l'adresse de départ analysée, l'adresse de réponse, expéditeur d'enveloppe, DKIM domaine de signature, résultat de l'authentification du destinataire et rôle commercial présumé. Ajoutez la boîte aux lettres ou le compte d'application uniquement si des preuves d'enquête autorisées l'identifient. Il s'agit de lignes distinctes et non d'étiquettes interchangeables pour « l'expéditeur ». Le domaine qui a authentifié un message peut différer de la personne dont le destinataire a déduit l'autorité.
RFC 9989 rend la frontière explicite : DMARC utilise alignement de domaine et n'authentifie pas les entités autres que les domaines et n'analyse pas le contenu. Un résultat aligné réussi ne peut donc pas certifier une facture, une nouvelle coordonnée bancaire ou l'approbation d'un dirigeant. A l’inverse, un résultat raté n’établit pas rachat de compte. Une enquête doit éviter de passer du résultat d'un protocole à une conclusion sur qui contrôlait le compte d'une personne.
Établir la limite de confiance pour chaque observation
Déterminez quel récepteur a produit le résultat d'authentification et si l'enregistrement a été obtenu via l'interface ou les journaux approuvés de ce récepteur. RFC 8601 aborde la confiance dans Authentication-Results affirmations. Un expéditeur peut inclure un texte d’apparence trompeuse, la présence d’un champ n’est donc pas suffisante. Documentez la base pour traiter une assertion comme locale et fiable. Si cette base est absente, marquez le résultat comme non vérifié plutôt que de le répéter comme un fait.
Les journaux d'application et les enregistrements d'audit de compte répondent à différentes questions. Un journal d'envoi peut montrer une soumission réussie sans prouver que l'humain l'avait prévu. Un audit de boîte aux lettres peut montrer un changement de règle sans prouver que la règle était malveillante. Combinez les observations par heure, identifiants de compte et de message lorsque cela est autorisé, en préservant l'incertitude lorsque le lien est faible. Évitez de traiter un seul emplacement inhabituel ou une erreur isolée comme une preuve concluante de compromission.
Comparez les mécanismes avant de sélectionner les contrôles
Utilisez une matrice d’identité et de contrôle. Pour l’usurpation d’identité de domaine exact sans authentification alignée, examinez la stratégie de domaine et le chemin d’envoi. En cas d'abus de nom d'affichage ou de domaine similaire, examinez la présentation, la reconnaissance et la vérification commerciale indépendante. En cas de suspicion de compromission de compte, examinez l’accès au compte et les actions non autorisées. Pour une application abusée, inspectez ses limites d’autorisation et de construction de messages. Plusieurs mécanismes peuvent se produire dans le même cas.
Les conseils de Microsoft répertorient les symptômes potentiels tels que les règles de boîte de réception suspectes, le transfert et les messages manquants ou supprimés. Il s’agit de pistes d’enquête et non de verdicts automatiques. Sa séquence de remédiation comprend la désactivation d'un compte concerné, la révocation de l'accès et l'examen des dispositifs d'authentification, des applications autorisées, des rôles et des redirecteurs. Il s’agit d’actions administratives consécutives pour un intervenant autorisé. Cet article ne demande pas à un assistant de les exécuter, d'accorder des autorisations ou de collecter des informations d'identification ; il identifie le domaine de réponse approprié une fois que les preuves soutiennent l'hypothèse.
La feuille de comparaison opérationnelle
Créez une ligne par hypothèse. Incluez l'identité affirmée, l'observation à l'appui, la source de cette observation, les preuves contradictoires, le contrôle concerné, le prochain contrôle autorisé proposé et la personne responsable. Ajoutez une étiquette de confiance avec une explication en langage simple. « Rapports de récepteurs de confiance alignés DKIM pour le domaine du fournisseur » est plus restreint et plus utile que « sûr confirmé par le fournisseur ». « Le destinataire se souvient du nom d'affichage » n'équivaut pas à une adresse de fournisseur authentifiée.
Ajoutez une ligne de vérification d'entreprise distincte. Identifiez un canal de contact établi avant la demande suspecte, le changement exact qui doit être confirmé, le vérificateur autorisé et le résultat enregistré. La réponse doit confirmer ou rejeter l'action commerciale demandée, et pas seulement que le contact reconnaît le nom de l'expéditeur. N'utilisez pas les numéros de téléphone, les liens ou les adresses alternatives fournis uniquement dans le message douteux comme vérification indépendante. Cette feuille de travail proposée n'est pas un enregistrement de réponse à un incident exécuté.
Diagnostic fictif : une demande de modification de facture
Un fabricant fictif reçoit une demande de modification de la destination de paiement d'un fournisseur. Le nom d'affichage correspond au responsable de compte et la preuve du destinataire de confiance montre une authentification alignée pour le domaine réel du fournisseur. Le destinataire suppose que cela exclut BEC. L’équipe de sécurité tire plutôt une conclusion plus étroite : le message utilisait un chemin de domaine fournisseur authentifié. On ne sait pas si le compte fournisseur, une intégration ou une personne autorisée a initié le changement.
À l’aide d’un contact fournisseur préalablement enregistré, le propriétaire de l’entreprise vérifierait le changement spécifique proposé. Un fournisseur agréé enquêterait sur son propre compte et les preuves de sa demande. Si le fournisseur refuse la demande, ce refus justifie l'arrêt du changement mais n'identifie pas en soi la manière dont l'e-mail a été envoyé. Le dossier reste ouvert jusqu'à ce que les preuves de compte ou de service résolvent le mécanisme. Cet exemple entier est fictif ; aucun détail de paiement, aucun compte fournisseur ou aucune correspondance réelle n'ont été obtenus.
Clôturez chaque incertitude avec les bonnes preuves
Une conclusion solide indique ce qui a été observé, quel mécanisme est soutenu, ce qui reste incertain et quel contrôle a été modifié par autorisation. Ne qualifiez pas de malveillant chaque message du domaine concerné, ne prétendez pas qu'une modification DNS contient un piratage de compte ou ne déclarez pas la correction terminée simplement parce que le courrier ultérieur s'authentifie. La vérification des processus métier, le confinement des comptes et l’authentification du courrier répondent chacun à des questions différentes.
Le catalogue nécessite une comparaison d'identité et de contrôle rédigée à partir de preuves de messages fiables. Cette preuve reste ouverte. Ce brouillon fournit une méthode et un cas fictif, et non un message original fiable. L'examen spécialisé indépendant, l'applicabilité actuelle des sources, les vérifications des itinéraires de production, l'accessibilité visuelle et la libération du propriétaire sont également ouverts. La publication doit attendre un ensemble de preuves autorisées démontrant la comparaison sans exposer les données de compte sensibles ni impliquer que des actions de réponse non effectuées ont eu lieu.