Un registro de riesgos de autenticación de correo electrónico debería explicar qué servicio empresarial podría verse perjudicado y qué decisión reduce ese riesgo. “DMARC "falta" es un hallazgo técnico, no una declaración de riesgo completa. Conecte la condición con una amenaza creíble o ruta de falla, proceso afectado, salvaguardas existentes y propietario responsable.
Describir el servicio y el escenario.
Para cada entrada, registre el servicio, el dominio, el propietario de la aplicación, la condición técnica, el tiempo de evidencia y las posibles consecuencias. Mantenga la incertidumbre explícita. Un remitente no observado es una brecha de evidencia, mientras que un remitente legítimo no alineado verificado es un defecto de autenticación. Ninguno de los dos prueba automáticamente que un atacante haya explotado el servicio.
RFC 9989 especifica la autenticación de dominio y alineación comportamiento. Sus protecciones no establecen que cada solicitud autenticada sea legítima. Un registro de riesgos debe distinguir la suplantación directa de su dominio de una cuenta autorizada comprometida o una dominio similar que pasa la autenticación por sí mismo.
Separar el riesgo inherente y restante
Describa el escenario antes de los controles, luego explique qué cambia cada salvaguarda existente. Para instrucciones de facturación, la verificación de devolución de llamada de pago puede abordar solicitudes comerciales fraudulentas que la autenticación de dominio por sí sola no puede resolver. No dé a entender que la existencia de una política de devolución de llamadas escrita demuestra que la gente la sigue consistentemente.
Utilice las definiciones de probabilidad e impacto acordadas por la organización. Evite presentar sin pruebas precisiones inventadas como una probabilidad de fraude anual del 17,3%. Cuando los datos sean insuficientes, utilice una calificación cualitativa con su justificación y el desencadenante de la revisión. Registre quién tiene autoridad para aceptar el riesgo restante, en lugar de tratar la aprobación técnica de un administrador de correo como una aceptación comercial.
Utilice un ejemplo vinculado
Supongamos que la entrada hipotética R-1 se refiere a la nómina. La condición es la ausencia de evidencia de aprobación alineada actual en un servicio crítico registrado. La posible consecuencia es la pérdida de notificaciones de nómina si una ruta no probada falla durante la aplicación de la ley. Este es un escenario condicional, no una afirmación de que los empleados hayan perdido mensajes. Finanzas es dueña del servicio, el equipo de correo es dueño de la investigación y el cierre requiere una prueba de ruta actual más la confirmación del propietario del servicio.
R-2 cubre la suplantación de pagos de facturas a través de un dominio similar propiedad del atacante. Su control propuesto es la verificación independiente a través de una ruta de contacto ya confiable. Publicar una política más estricta en el dominio de la víctima no satisface la prueba de cierre de R-2. Para cada entrada, exigir un hallazgo, propietario, decisión y evidencia de cierre explícito antes de considerar completo el registro propuesto. Esta es una regla de revisión recomendada, no una validación ejecutada o una prueba de que un control funciona.
Mantenga el registro procesable
Elegir el tratamiento explícitamente: remediar, evitar la actividad riesgosa, transferir una exposición definida cuando corresponda, o aceptar el riesgo restante a través del proceso de decisión autorizado. Establezca una fecha de vencimiento y un activador de revisión. Un plan de tratamiento no es evidencia de su finalización; conservar la prueba real o el registro de decisión por separado.
Estas entradas hipotéticas ilustran diferentes escenarios, ataques no observados o riesgos comerciales aceptados. Una revisión de la integridad puede identificar campos faltantes, pero no puede validar una calificación de riesgo ni establecer que operan salvaguardas reales. Mantenga la evidencia real y la decisión de aceptación autorizada separadas del tratamiento propuesto.
Revisar el registro tras migraciones, nuevos remitentes, incidencias y cambios de negocio. Cierre solo el escenario específico cuya evidencia cumpla con la prueba establecida y conserve suficiente historial para explicar por qué se cerró.
NIST SP 800-30 Rev. 1, secciones 2.3 y 3.2, describen los factores de riesgo, los enfoques de evaluación y la documentación de los resultados de la evaluación. Apoyan hacer explícitos la probabilidad, el impacto y la incertidumbre; Los campos de registro específicos de correo electrónico y los ejemplos anteriores son una aplicación propuesta, no una lista de verificación de cumplimiento prescrita. guía de evaluación de riesgos.