Un registre des risques liés à l'authentification des e-mails doit expliquer quel service commercial pourrait être endommagé et quelle décision réduit ce risque. "DMARC "manquant" est une constatation technique, et non une déclaration de risque complète. Reliez la condition à une menace ou à un chemin de défaillance crédible, au processus affecté, aux garanties existantes et au propriétaire responsable.
Décrire le service et le scénario
Pour chaque entrée, enregistrez le service, le domaine, le propriétaire de l'application, l'état technique, le temps de preuve et les conséquences probables. Gardez l’incertitude explicite. Un expéditeur non observé est une lacune dans les preuves, tandis qu'un expéditeur légitime non aligné vérifié est un défaut d'authentification. Ni l’un ni l’autre ne prouve automatiquement qu’un attaquant a exploité le service.
RFC 9989 spécifie l'authentification du domaine et alignement comportement. Ses protections n'établissent pas que chaque demande authentifiée est légitime. Un registre des risques doit distinguer l'usurpation d'identité directe de votre domaine d'un compte autorisé compromis ou d'un domaine similaire qui réussit l'authentification pour lui-même.
Séparer le risque inhérent et résiduel
Décrivez le scénario avant les contrôles, puis expliquez ce que change chaque mesure de protection existante. Pour les instructions de facturation, la vérification des rappels de paiement peut répondre aux demandes commerciales frauduleuses que l'authentification de domaine ne peut à elle seule résoudre. N'insinuez pas que l'existence d'une politique de rappel écrite prouve que les gens la suivent systématiquement.
Utilisez les définitions de probabilité et d’impact convenues par l’organisation. Évitez de présenter des précisions inventées, comme une probabilité de fraude annuelle de 17,3 %, sans preuve. Lorsque les données sont insuffisantes, utilisez une notation qualitative avec sa justification et son déclencheur d'examen. Enregistrez qui a le pouvoir d'accepter le risque restant, plutôt que de considérer l'approbation technique d'un administrateur de messagerie comme une acceptation commerciale.
Utiliser un exemple lié
Supposons que l’entrée hypothétique R-1 concerne la paie. La condition est l’absence de preuve de réussite alignée actuelle sur un service critique enregistré. La conséquence potentielle est l'absence de notifications de paie si un itinéraire non testé échoue lors de l'application. Il s’agit d’un scénario conditionnel et non d’une affirmation selon laquelle les employés auraient manqué des messages. Les finances sont propriétaires du service, l'équipe de courrier est propriétaire de l'enquête et la clôture nécessite un test d'itinéraire en cours ainsi qu'une confirmation du propriétaire du service.
R-2 couvre l’usurpation d’identité lors du paiement d’une facture via un domaine similaire appartenant à un attaquant. Le contrôle proposé est une vérification indépendante via une route de contact déjà fiable. La publication d'une politique plus stricte sur le domaine de la victime ne satisfait pas au test de clôture de R-2. Pour chaque entrée, exigez une conclusion, un propriétaire, une décision et une preuve explicite de clôture avant de considérer le registre proposé comme complet. Il s'agit d'une règle de révision recommandée, et non d'une validation exécutée ou d'une preuve qu'un contrôle fonctionne.
Gardez le registre exploitable
Choisissez explicitement le traitement : corrigez, évitez l'activité à risque, transférez une exposition définie le cas échéant ou acceptez le risque restant via le processus de décision autorisé. Fixez une date d’échéance et un déclencheur de révision. Un plan de traitement ne constitue pas une preuve d’achèvement ; conserver séparément le dossier de test ou de décision réel.
Ces entrées hypothétiques illustrent différents scénarios, sans attaques observées ni risques commerciaux acceptés. Un examen de l'exhaustivité peut identifier les champs manquants, mais ne peut pas valider une évaluation du risque ni établir que de véritables mesures de protection fonctionnent. Conservez les preuves réelles et la décision d’acceptation autorisée séparément du traitement proposé.
Consultez le registre après les migrations, les nouveaux expéditeurs, les incidents et les changements commerciaux. Fermez uniquement le scénario spécifique dont les preuves répondent au test énoncé et conservez suffisamment d'historique pour expliquer pourquoi il a été fermé.
Les sections 2.3 et 3.2 NIST SP 800-30 Rév. 1 décrivent les facteurs de risque, les approches d'évaluation et la documentation des résultats de l'évaluation. Ils soutiennent que la probabilité, l’impact et l’incertitude sont explicites ; les champs de registre spécifiques aux e-mails et les exemples ci-dessus sont une proposition de candidature et non une liste de contrôle de conformité prescrite. Guide d'évaluation des risques.