Concevoir la réponse avant de collecter les candidats
La surveillance des domaines similaires n’est utile que lorsqu’une découverte peut conduire à une décision proportionnée et fondée sur des preuves. Un domaine qui ressemble à une marque est un candidat à un examen et non une preuve d'abus. Un processus de surveillance doit définir ce qu'il observe, comment il distingue une correspondance lexicale des preuves opérationnelles, à qui appartient l'enquête et quelles réponses doivent être approuvées. Dans le cas contraire, une file d'attente d'alertes importante peut attirer l'attention sans améliorer la capacité de l'organisation à gérer une véritable usurpation d'identité.
RFC 9989, section 2.2, explique que DMARC ne traite pas des noms de domaine visuellement similaires ni des abus de noms d'affichage. Un domaine différent peut authentifier correctement son propre courrier. La surveillance complète donc l’authentification du domaine plutôt que de la remplacer. Cet article propose un workflow ; il n'enregistre pas de domaines, n'interroge pas une véritable liste de surveillance, n'envoie pas de messages de test, ne visite pas de sites suspects et ne contacte pas les bureaux d'enregistrement ou les opérateurs présumés.
Définir un périmètre défendable
Commencez par les domaines vérifiés, les marques publiques et les relations commerciales de l'organisation qui sont importantes pour l'objectif de surveillance. Enregistrez qui a approuvé cette portée et pourquoi chaque élément est inclus. Évitez de collecter des noms personnels ou des données relationnelles sensibles simplement parce qu’un outil le permet. Précisez quelles sources d’observation sont disponibles et autorisées, leurs limites de couverture et la cadence d’examen attendue. L'alerte d'un fournisseur constitue une preuve provenant de cette source à ce moment-là, et non une preuve d'une visibilité complète sur Internet.
Séparez les règles de génération de candidats des règles d’escalade. Les règles des candidats peuvent comparer l’orthographe ou la similarité des caractères ; l'escalade nécessite un contexte supplémentaire, tel qu'un message trompeur signalé ou une affirmation commerciale trompeuse observée. L'âge d'inscription, un certificat ou un Enregistrement MX peut être un contexte pertinent, mais aucun ne démontre à lui seul une intention malveillante. De même, l'absence d'enregistrement MX ne constitue pas une garantie complète qu'un domaine ne peut pas participer à une tromperie. Ne transformez pas un indicateur pratique en un verdict universel.
Traitez la confusion comme un signal technique
Norme technique Unicode 39 décrit les mécanismes de détection des identifiants pouvant prêter à confusion et prévient que les comparaisons peuvent être trop inclusives. Un squelette ou un résultat de comparaison associé est une relation technique entre des chaînes, et non une conclusion juridique, une preuve de propriété commune ou une preuve qu'un destinataire a été trompé. Enregistrez l'outil, la version des données Unicode et la méthode de comparaison afin que les futurs évaluateurs puissent comprendre pourquoi un candidat est apparu.
Conservez la chaîne d'origine observée et sa représentation orientée DNS séparées de l'artefact de comparaison. Un squelette confus n'est pas une adresse à visiter ou à publier dans DNS . Si un outil normalise ou affiche les noms différemment, conservez cette transformation en tant que métadonnées. L'examen humain doit tenir compte du public visé et du contexte sans supposer que les noms internationalisés sont intrinsèquement suspects. Les organisations légitimes utilisent de nombreux scripts ; le processus de contrôle doit éviter de considérer le choix linguistique comme une preuve d’inconduite.
Construisez une échelle de tri plutôt qu’une accusation automatique
Utilisez des statuts tels que candidat, examinés sans aucune preuve d'abus actuelle, une enquête supplémentaire nécessaire, des preuves d'usurpation d'identité vérifiées et résolues avec un résultat documenté. Définissez les preuves nécessaires pour se déplacer entre eux. Une alerte peut être fermée avec une faible priorité sans déclarer le domaine définitivement sûr. Un incident vérifié peut rester ouvert pendant que la propriété de la réponse est établie. Il s'agit d'étiquettes de flux de travail internes proposées, et non de classifications standard de l'industrie ou de capacités des fournisseurs.
Pour chaque candidat, enregistrez la similarité observée, la source et l'heure, l'affiliation revendiquée le cas échéant, le processus métier concerné, les preuves de message disponibles et les questions non résolues. Ne sondez pas les comptes, n'enregistrez pas de ressources et n'envoyez pas de messages pour tester si un abus est possible. Si une analyse plus approfondie est nécessaire, acheminez-la vers un processus de sécurité autorisé. Toute plainte externe, demande de retrait ou communication nécessite l'approbation appropriée et des preuves à l'appui ; une correspondance lexicale automatisée à elle seule ne devrait pas générer une allégation.
Connectez les rapports de messages à des identités de confiance
Lorsqu'un message signalé est disponible via un canal autorisé, comparez son domaine d'expéditeur réel, son nom d'affichage et l'action demandée avec l'identité commerciale attendue. Conservez le résultat d’authentification du destinataire concerné avec sa provenance. RFC 8601 explique pourquoi un Authentication-Results l’assertion a besoin d’une limite de confiance. Ne considérez pas une ligne de passe copiée comme une preuve suffisante que le domaine inconnu s'est authentifié auprès du destinataire du destinataire.
Un message correctement authentifié provenant d'un autre domaine peut toujours être trompeur, tandis qu'un message légitime provenant d'un nouveau partenaire commercial peut être inconnu sans être malveillant. La réponse dépend de l'affiliation et de la demande spécifique. Une vérification indépendante via un contact professionnel établi peut résoudre cette question plus directement que la collecte de variantes orthographiques supplémentaires. Le Avis IC3 BEC, daté de 2020, soutient ce contrôle de vérification général, et non une affirmation concernant un service de surveillance actuel.
Une feuille de travail sur le processus de réponse
Créez une feuille de travail avec l'identifiant du candidat, l'orthographe d'origine, la représentation DNS normalisée si validée, la méthode de comparaison, la source d'observation, l'horodatage, le propriétaire de la portée et l'état actuel. Ajoutez des preuves de l'utilisation réelle, des utilisateurs ou du flux de travail concernés, des justifications de confiance, de la réponse proposée, de l'autorisation requise et de la date de suivi. Gardez un champ séparé pour ce que la source ne peut pas établir. Cela évite que l’apparence de précision d’un score d’outil ne masque une conclusion incertaine.
Définissez les preuves de clôture pour chaque réponse. Un avertissement interne doit identifier son public et son fondement sans répéter de contenu sensible. Un bloc doit avoir un propriétaire autorisé et un plan de révision pour les faux positifs. Un rapport externe doit être étayé et approuvé par des faits. Il s'agit uniquement de considérations de conception de processus ; aucun blocage, avertissement ou rapport n'a été créé ici. Examinez la charge de travail et les cas non résolus à fort impact ainsi que le nombre d'alertes brutes pour évaluer si le processus est utile.
Diagnostic fictif : un candidat performant
Un outil fictif de surveillance de marque signale un domaine ressemblant au nom d'un fournisseur. Le score de similarité est élevé, mais l’alerte ne contient aucun message, contenu de site Web ou revendication d’affiliation. L'analyste l'enregistre comme candidat plutôt que de qualifier son opérateur de malveillant. Ultérieurement, un utilisateur professionnel fournit un rapport de messages autorisés qui utilise le domaine candidat et demande une modification inhabituelle de l'enregistrement du fournisseur. La preuve du message modifie la priorité de l'enquête, pas le score lexical.
L'équipe comparerait les résultats des récepteurs de confiance et vérifierait le changement demandé avec le fournisseur en utilisant une voie de contact existante. Si le fournisseur refuse la demande, le dossier peut documenter ce fait vérifié et demander l'approbation de la réponse appropriée. L'équipe hypothétique n'enregistre pas le domaine, ne teste pas de connexion et n'envoie pas de message. hameçonnage message pour prouver un point. Il s’agit d’un exercice de processus inventé, et non d’un domaine observé, d’une véritable plainte ou d’une mesure coercitive achevée.
Maintenir le processus responsable et fondé sur des preuves
Examinez les faux positifs, les candidats périmés non résolus, les délais de réponse et l'impact commercial des cas confirmés. Ne prétendez pas qu’un nombre croissant d’alertes signifie une augmentation des attaques sans vérifier la couverture des sources et les modifications des règles. Ne prétendez pas qu’une file d’attente silencieuse prouve l’absence d’usurpation d’identité. Conservez suffisamment d'informations de version pour expliquer pourquoi le même domaine peut recevoir un score différent après une mise à jour d'un outil ou de données Unicode.
Le scénario d'abus expurgé requis avec preuve d'identité, limite de contrôle et vérification commerciale indépendante reste manquant. L’exercice fictionnel ne peut satisfaire à cette exigence. Toutes les portes de libération restent ouvertes et aucune observation de surveillance originale n'est représentée comme un travail terminé. Avant la publication, obtenez des preuves autorisées, demandez à un spécialiste d'examiner les critères de réponse, vérifiez l'applicabilité de la source et les itinéraires de production, effectuez les contrôles d'accessibilité et obtenez la libération du propriétaire. L'objectif est un processus de décision pratique, et non une promesse de découvrir ou d'éliminer chaque domaine similaire.