Un director financiero debería preguntarse cómo verifica una organización una solicitud para mover dinero, no sólo si su dominio de correo electrónico pasa la autenticación. La autenticación de dominio ayuda a los receptores a evaluar el uso de un dominio. No certifica una factura de proveedor, no confirma un cambio de cuenta bancaria ni prueba que el ser humano detrás de una cuenta legítima esté autorizado a realizar una solicitud.
Distinguir tres vías de fraude
La suplantación directa de dominio utiliza su dominio sin la autenticación alineada requerida. Un ataque similar utiliza un dominio diferente que se parece a uno de confianza. Un ataque a una cuenta comprometida puede originarse a través de un servicio legítimo y autenticado. Estas rutas requieren evidencia diferente y no todas pueden cerrarse publicando una política más estricta en su dominio.
RFC 9989 explica la autenticación alineación con el dominio del autor. Un resultado aprobado para billing-supplier.example controlado por un atacante no establece que pertenezca a un proveedor real. Los nombres para mostrar y los destinos de respuesta también pueden engañar a los lectores; registrarlos por separado del dominio evaluado por DMARC.
Inspeccionar el camino de decisión
Pregunte a operaciones financieras cómo se verifican los cambios de pago utilizando la información de contacto establecida antes de la solicitud sospechosa. Un número de teléfono o un enlace proporcionado en el mismo correo electrónico no es una ruta de verificación independiente. Utilice el flujo de trabajo aprobado por la organización y la separación de funciones, especialmente para cambios en los datos bancarios o excepciones de pagos urgentes.
El escenario ficticio escrito a continuación describe un mensaje que muestra "Cuentas de proveedores", mientras que el dominio visible De es un doble controlado por un atacante. El resultado de su receptor es un pase alineado sintético para ese dominio similar. La acción solicitada es un cambio de datos bancarios, omitiendo los números de cuenta. No se representa ningún incidente real del cliente ni instrucción de pago real.
Probar el límite de control
El dominio de proveedor legítimo del ejemplo es supplier.example .prueba; el remitente observado utiliza supplier-payments.example .prueba. Finanzas detiene el cambio y llama a un contacto previamente verificado desde el registro maestro de proveedores. El contacto ficticio rechaza la solicitud. Esta verificación comercial es parte del escenario, no una conversación real realizada para este punto de control.
Compare dos rutas de verificación estipuladas. El caso A utiliza el contacto del registro maestro de proveedores preexistente, que se supone verificado de forma independiente antes de la solicitud sospechosa; la negación ficticia mantiene el cambio en suspenso. El caso B utiliza únicamente un número proporcionado por el correo electrónico sospechoso; la verificación es inadecuada y el cambio permanece en suspenso. Ninguno de los casos fue calculado, llamado o verificado con un directorio real. Este es un ejemplo de control editorial, no un procedimiento financiero obligatorio.
Solicite evidencia de operación de rutina.
Solicite pruebas de muestra de que se producen devoluciones de llamadas y aprobaciones duales, que las excepciones se escalan y que las anomalías del dominio del remitente llegan al personal de finanzas en términos comprensibles. Pregunte quién es el propietario de la reparación de dominios desprotegidos y quién es el propietario de las fallas en el proceso de pago. Siga informando de forma proporcional: un recuento de mensajes DMARC fallidos no es un recuento de pagos fraudulentos evitados.
Si llega una solicitud de pago sospechosa, conserve el mensaje y los registros relevantes del destinatario, siga el proceso de incidentes de la organización y verifique la solicitud de forma independiente antes de actuar. La autenticación es una prueba valiosa, pero la decisión sobre el movimiento de dinero debe basarse en el proceso comercial autorizado. No permita que una tasa de aprobación impresionante reemplace ese proceso.
Solicite un cuadro de mando de control acotado
Solicite el recuento de cambios de pago de muestra, cuántos tenían verificación independiente documentada, excepciones no resueltas y sus propietarios. Mantenga esto separado del recuento de mensajes DMARC . La evidencia faltante es una brecha que investigar, no una prueba de que ocurrió un fraude o de que se evitó una pérdida financiera declarada.