Un incident d’usurpation d’identité traverse souvent les équipes avant que quiconque sache quel contrôle a échoué. DNS peut être intact, l'authentification du courrier peut passer pour un domaine similaire et la demande commerciale peut toujours être frauduleuse. Attribuez un responsable d'incident, protégez immédiatement les actions qui en résultent et laissez les équipes concernées enquêter en parallèle. Attendre une réponse DNS avant de retenir un paiement suspect peut laisser le risque le plus important non traité.
S'ouvrir aux faits et à l'incertitude
Créez un enregistrement de cas contenant l'heure du rapport, le flux de travail concerné, la référence du message d'origine, les identités visibles exactes et l'exposition commerciale connue. Marquez chaque observation par sa source et sa confiance. Distinguer une allégation d’un événement confirmé et une recommandation de réponse d’une action déjà entreprise. Les lignes directrices actuelles du NIST en matière de réponse aux incidents placent la réponse dans le cadre d'une gestion plus large des risques de cybersécurité ; le flux de travail ci-dessous est une implémentation opérationnelle locale, et non un modèle NIST obligatoire. SP 800-61 révision 3.
Définissez un responsable d’incident nommé et un endroit sécurisé pour les preuves. Conservez l’original à accès contrôlé séparé des copies de partage réduites. Identifiez qui peut autoriser le confinement, les rapports des fournisseurs et les décisions commerciales. Cela empêche un analyste technique de prendre involontairement un engagement financier ou de réputation en essayant de résoudre une alerte par courrier électronique.
Donnez à chaque équipe une question distincte
DNS doit établir la propriété et les changements récents pour le domaine réel de l'organisation et les délégations pertinentes. Il ne doit pas prendre le contrôle d’un domaine similaire car le nom de la marque y apparaît. Les opérations de messagerie doivent établir les identités reçues, les résultats d'authentification fiables, l'itinéraire et toutes les transformations. Les assertions d'authentification nécessitent une limite de confiance connue. RFC 8601.
Le propriétaire de l'entreprise doit déterminer si l'action demandée est autorisée, en utilisant des contacts préalablement établis. Le FBI recommande spécifiquement une vérification indépendante des demandes de paiement et des modifications des procédures de paiement. Conseils du FBI. La sécurité doit combiner ces résultats, évaluer l’exposition et coordonner la réponse autorisée sans imposer à chaque cas une explication d’usurpation d’identité DNS.
Suivez le triage parallèle synthétique
Le scénario écrit suppose une demande de paiement provenant d'un domaine similaire. Son équipe DNS ne trouve aucune modification non autorisée dans l'inventaire inventé. Les opérations de messagerie identifient l'identité similaire distincte, de sorte que la politique de domaine propre de l'organisation ne peut pas la contrôler directement. Le contact fournisseur connu de l’équipe commerciale refuse la demande. La sécurité préserve le dossier et laisse ouvertes l’attribution et la réponse du fournisseur.
Le chemin critique qui en résulte est désormais une affaire commerciale, avec en parallèle la collecte de preuves techniques. Le grand livre proposé maintient le dossier ouvert et répertorie les portes de clôture plutôt que d'assimiler une tâche d'équipe terminée à une résolution. Toutes les confirmations et conclusions sont hypothétiques et ne constituent pas un modèle de coordination exécuté. Aucun véritable DNS , boîte aux lettres, fournisseur ou système de gestion des incidents n'a été consulté, et aucune communication externe ou action de confinement n'a été exécutée.
Rejoignez les conclusions sans effacer les désaccords
Utilisez un identifiant de cas et un fuseau horaire communs, mais conservez les références originales des preuves de chaque équipe. Si DNS indique inchangé alors qu'un message montre une signature passante, ces observations peuvent être compatibles avec un service autorisé ou un domaine différent. Comparez la portée et le temps avant de déclarer qu’une des équipes a tort. DMARCLa portée basée sur le domaine aide à expliquer pourquoi une politique inchangée peut coexister avec une usurpation d'identité en dehors de ce domaine. RFC 9989.
Enregistrez la prochaine action responsable pour chaque problème non résolu, y compris l'enquête du fournisseur, l'examen du compte ou la récupération des journaux manquants. Évitez les tickets en double qui divisent le même incident en historiques déconnectés. Gardez les modifications urgentes réversibles dans la mesure du possible et documentez l’autorité et la vérification pour chaque action effectuée.
Clôture lorsque l'exposition de l'entreprise a été évaluée, la condition d'identité du courrier est classifiée, les résultats DNS sont enregistrés et les obligations de réponse restantes incombent aux propriétaires. La clôture ne nécessite pas d’inventer des certitudes sur l’attaquant. Cela nécessite un récit défendable de ce qui s’est passé, de ce qui a été protégé, de ce qui a changé et de ce qui n’a pas été résolu pour un suivi.
Rendre le transfert explicite
Pour le cas illustratif DEMO-TRIAGE-01, le propriétaire DNS proposé fournit des preuves de l'historique des modifications ; les opérations de courrier fournissent des preuves d'identité fiables ; la finance fournit la décision commerciale indépendante ; la sécurité est responsable de l'exposition non résolue et du suivi de la réponse du fournisseur. Une vérification DNS terminée ne clôture que cette question. Si les journaux de compte restent manquants, nommez le propriétaire du suivi responsable et préservez cette incertitude lors de l'enregistrement de toute clôture ciblée. Personne n’a accepté ces missions illustratives.
Conserver les résultats dans les preuves
Les exemples sont des aides à la décision défensives, et non des allégations observées contre de vraies personnes ou des prestataires actuels. Conservez séparément les preuves d’authentification, la vérification commerciale et l’attribution. Les sources de protocole actuelles décrivent la validation du domaine et les limites des résultats fiables ; ils ne fournissent pas les preuves manquantes et n'autorisent pas la publication d'une accusation.