Trate la autoridad de pago como una cuestión separada
El correo electrónico de un proveedor puede autenticarse correctamente y aún contener una solicitud de cambio de pago no autorizada. Un buzón de correo o una aplicación comprometidos pueden utilizar la infraestructura de envío legítima del proveedor, mientras que un imitador puede utilizar un dominio diferente con un nombre para mostrar familiar. La pregunta empresarial inmediata es si el cambio solicitado está autorizado, no si el mensaje contiene la palabra pasar. Mantenga la decisión financiera separada de la investigación técnica para que ninguna sustituya a la otra.
RFC 9989 límites DMARC a las relaciones de autenticación de dominio y excluye explícitamente el análisis de contenido y la autenticación de entidades distintas de los dominios. No puede aprobar un cambio de cuenta bancaria ni establecer las intenciones de un empleado de un proveedor. Un resultado aprobado es una prueba útil sobre el uso del dominio, pero no es una instrucción de pago que la organización deba seguir. Este manuscrito propone un proceso defensivo; no se realizó ningún pago, actualización de cuenta o contacto externo.
Preservar la solicitud sin ejecutarla
Ponga el cambio solicitado en espera a través del proceso de compra o financiamiento existente. Registre lo que el mensaje solicita cambiar, a qué registro de proveedor afecta, cuándo se supone que el cambio entrará en vigor y quién lo recibió. Evite copiar detalles financieros completos en un ticket de incidente de fácil acceso. Un registro restringido aprobado puede preservar el original mientras que el resumen de trabajo describe el cambio utilizando un identificador de referencia y el contexto mínimo necesario.
Conservar el mensaje original y su procedencia. Una copia o una captura de pantalla reenviada puede ayudar a mostrar cómo apareció la solicitud, pero no es intercambiable con el mensaje original ni con los registros del receptor. Registre la hora de recogida y la zona horaria. Si alguien ya ha actuado, escale a través del procedimiento de incidentes financieros establecido por la organización en lugar de asumir que el cambio se puede revertir silenciosamente. Este artículo no autoriza transferencias, retiros o comunicaciones con un banco.
Establecer qué identidad se utilizó
Compare el dominio De origen real con el dominio del proveedor en el registro de proveedor de confianza. Mantenga el nombre para mostrar, la dirección de respuesta, la identidad del sobre y DKIM dominio de firma separado. Un mensaje de dominio diferente puede autenticarse para su propio dominio y al mismo tiempo engañar al lector sobre la afiliación. Un mensaje exacto del dominio del proveedor con autenticación alineada aún puede originarse a través de una cuenta o servicio abusado. No seleccione la hipótesis de compromiso únicamente porque la solicitud es inusual.
Utilice evidencia de receptor confiable al interpretar la autenticación. RFC 8601 explica por qué Authentication-Results Los campos requieren un límite de confianza. Es posible que una línea proporcionada por el remitente, una captura de pantalla o un extracto de encabezado reenviado no establezcan la evaluación del destinatario correspondiente. Registre qué receptor produjo el resultado y qué trayectoria alineada se observó. Cuando la evidencia esté incompleta, dígalo en lugar de forzar una conclusión de aprobación o no en la decisión financiera.
Verificar a través de una ruta independiente establecida
El Aviso BEC de correo electrónico en la nube IC3, publicado el 6 de abril de 2020, recomienda la verificación independiente de solicitudes comerciales sospechosas. Utilice una ruta de contacto con el proveedor que se haya establecido antes de la solicitud cuestionable, como el registro de proveedor verificado existente de la organización. Un nuevo número de teléfono, una dirección de correo electrónico alternativa o un enlace de verificación proporcionados únicamente en ese mensaje no constituyen una fuente independiente. El aviso citado respalda este principio general, no un reclamo de incidente actual.
Solicite al verificador comercial autorizado que confirme el cambio específico propuesto a través del proceso establecido. Confirmar que una persona reconoce el nombre del remitente es más débil que confirmar que el cambio en sí fue solicitado y aprobado. Cuando la política requiera aprobadores separados, conserve esa separación. No permita que la urgencia del mensaje reemplace los requisitos de aprobación de la organización. El analista técnico puede proporcionar pruebas de identidad, pero no debe convertirse silenciosamente en el aprobador financiero.
Coordinar cuidadosamente la investigación técnica.
Si la evidencia apunta a un abuso de la cuenta del proveedor, comuníquese a través de un contacto verificado aprobado y comparta solo la evidencia redactada relevante después de la autorización. El personal de respuesta autorizado del proveedor es responsable de la investigación de sus sistemas. La organización receptora no debe afirmar que ha probado la adquisición de un proveedor simplemente porque se autenticó un mensaje y el proveedor rechazó la solicitud de pago. Es posible que sea necesario investigar una integración, un remitente delegado u otro mecanismo.
Guía de cuentas comprometidas de Microsoft enumera reglas de bandeja de entrada sospechosas, reenvío y mensajes faltantes entre posibles indicadores y describe la respuesta de la cuenta para Microsoft 365 . Es una referencia para un proveedor autorizado de respuesta en ese entorno, no un permiso para inspeccionar las cuentas de otra organización. Ningún acceso a cuentas, revocación de sesión, eliminación de reglas o recopilación de credenciales forma parte del trabajo de este manuscrito.
Una hoja de trabajo de evidencia de cambio de pago
Cree una hoja de trabajo con cuatro secciones vinculadas. La sección de solicitud registra la referencia del proveedor, el tipo de cambio, la fecha solicitada y el propietario del negocio. La sección de identidad registra los dominios reales, las observaciones de autenticación confiable y la fuente de evidencia. La sección de verificación registra la ruta de contacto establecida independientemente, el verificador autorizado, la pregunta y respuesta precisas. La sección de decisiones registra la aprobación o el rechazo, los aprobadores requeridos, la ruta de implementación permitida y cualquier investigación no resuelta.
Mantenga los identificadores de cuentas financieras fuera de las copias de uso general. Utilice marcadores de posición consistentes cuando la comparación sea importante y almacene el original completo solo en una ubicación restringida aprobada. Agregue una columna que distinga los hechos observados de las hipótesis. “ DKIM alineado con el dominio del proveedor observado en nuestro receptor” es un hecho sólo si la evidencia lo respalda; "El empleado del proveedor aprobó el cambio" requiere una confirmación comercial por separado. La hoja de trabajo nunca debe promover automáticamente el primero al segundo.
Diagnóstico ficticio: un hilo familiar de proveedores
Un equipo de instalaciones ficticias recibe una solicitud en una conversación establecida con un proveedor solicitando cambiar los detalles de pago futuros. El mensaje utiliza el dominio real del proveedor e hipotéticamente pasa DMARC al receptor. El destinatario asume que el hilo existente y el resultado de la autenticación hacen que el cambio sea seguro. En cambio, un segundo revisor pausa la actualización y verifica el registro del proveedor aprobado para la ruta de verificación establecida.
En el ejercicio, el contacto del proveedor niega haber autorizado el cambio. Esa respuesta respalda el rechazo de la solicitud bajo el proceso de negocio, pero el mecanismo sigue sin resolverse hasta que se disponga de evidencia técnica autorizada. La investigación preservaría el mensaje y compartiría un resumen mínimo aprobado en lugar de enviar ampliamente los detalles completos del pago. Este es un escenario ficticio, no una negación real, un hallazgo de compromiso, una llamada de verificación o una pérdida evitada. Ilustra por qué la verificación empresarial y la autenticación de dominio responden a preguntas diferentes.
Cerrar las vías financiera y técnica por separado.
Registre la disposición del cambio solicitado incluso si la investigación técnica continúa. Por el contrario, no declare que el problema comercial se resolvió simplemente porque se aseguró una cuenta: es posible que alguien ya haya modificado el registro de un proveedor o haya actuado según la solicitud. Concilie el registro comercial real con la decisión autorizada y documente quién verificó el resultado. Cualquier acción de este tipo requiere la autoridad normal de la organización; aquí no se ha realizado ninguno.
El catálogo requiere un escenario de abuso redactado con evidencia de identidad, límites de control y verificación comercial independiente. Esa evidencia original permanece abierta. La hoja de trabajo propuesta y el ejercicio ficticio no lo satisfacen. La revisión de especialistas humanos, la aplicabilidad de las fuentes, las rutas de producción, la accesibilidad y la autorización del propietario también permanecen abiertas. Una versión publicable necesita un paquete de evidencia autorizado que demuestre el proceso de verificación sin exponer identificadores financieros ni hacer acusaciones sin fundamento sobre un proveedor.