Trate a autoridade de pagamento como uma questão separada
O e-mail de um fornecedor pode ser autenticado corretamente e ainda conter uma solicitação de alteração de pagamento não autorizada. Uma caixa de correio ou aplicativo comprometido pode usar a infraestrutura de envio legítima do fornecedor, enquanto um imitador pode usar um domínio diferente com um nome de exibição familiar. A questão comercial imediata é se a alteração solicitada é autorizada e não se a mensagem contém a palavra passar. Mantenha a decisão financeira separada da investigação técnica para que nenhuma substitua a outra.
RFC 9989 limites DMARC às relações de autenticação de domínio e exclui explicitamente a análise de conteúdo e a autenticação de entidades que não sejam domínios. Não pode aprovar uma alteração de conta bancária nem estabelecer as intenções de um funcionário de um fornecedor. Um resultado aprovado é uma evidência útil sobre o uso do domínio, mas não é uma instrução de pagamento que a organização deva seguir. Este manuscrito propõe um processo defensivo; nenhum pagamento, atualização de conta ou contato externo foi realizado.
Preservar a solicitação sem executá-la
Coloque a alteração solicitada em espera por meio do processo de compra ou financeiro existente. Registre o que a mensagem pede para alterar, qual registro do fornecedor ela afeta, quando a alteração deverá entrar em vigor e quem a recebeu. Evite copiar detalhes financeiros completos em um ticket de incidente amplamente acessível. Um registro restrito aprovado pode preservar o original enquanto o resumo de trabalho descreve a mudança usando um identificador de referência e o contexto mínimo necessário.
Retenha a mensagem original e sua proveniência. Uma cópia encaminhada ou captura de tela pode ajudar a mostrar como a solicitação apareceu, mas não é intercambiável com a mensagem original ou com os registros do receptor. Registre a hora e o fuso horário da coleta. Se alguém já tiver agido, avance através do procedimento de incidente financeiro estabelecido pela organização, em vez de presumir que a mudança pode ser revertida silenciosamente. Este artigo não autoriza transferências, recalls ou comunicações com bancos.
Estabeleça qual identidade foi usada
Compare o domínio De real com o domínio do fornecedor no registro do fornecedor confiável. Mantenha o nome de exibição, endereço de resposta, identidade do envelope e DKIM assinando domínio separado. Uma mensagem de domínio diferente pode autenticar seu próprio domínio enquanto engana o leitor sobre a afiliação. Uma mensagem exata do domínio do fornecedor com autenticação alinhada ainda pode ser originada por meio de uma conta ou serviço abusado. Não selecione a hipótese de compromisso apenas porque a solicitação é incomum.
Use evidências de receptor confiável ao interpretar a autenticação. RFC 8601 explica por que Authentication-Results campos exigem um limite de confiança. Uma linha fornecida pelo remetente, uma captura de tela ou um trecho do cabeçalho encaminhado podem não estabelecer a avaliação do destinatário relevante. Registre qual receptor produziu o resultado e qual caminho alinhado foi observado. Quando as evidências estiverem incompletas, diga-o em vez de forçar uma conclusão de aprovação ou reprovação na decisão financeira.
Verifique através de uma rota independente estabelecida
O Aviso BEC de e-mail na nuvem IC3, publicado em 6 de abril de 2020, recomenda a verificação independente de solicitações comerciais suspeitas. Use uma rota de contato com o fornecedor que tenha sido estabelecida antes da solicitação questionável, como o registro de fornecedor verificado existente da organização. Um novo número de telefone, endereço de e-mail alternativo ou link de verificação fornecido apenas nessa mensagem não é uma fonte independente. O comunicado citado apoia este princípio geral, não uma reclamação de incidente atual.
Peça ao verificador comercial autorizado para confirmar a alteração específica proposta por meio do processo estabelecido. Confirmar que uma pessoa reconhece o nome do remetente é mais fraco do que confirmar que a alteração em si foi solicitada e aprovada. Quando a política exigir aprovadores separados, preserve essa separação. Não deixe que a urgência na mensagem substitua os requisitos de aprovação da organização. O analista técnico pode fornecer provas de identidade, mas não deve tornar-se silenciosamente o aprovador financeiro.
Coordene a investigação técnica cuidadosamente
Se as evidências apontarem para abuso na conta do fornecedor, comunique-se por meio de um contato verificado e aprovado e compartilhe apenas as evidências redigidas relevantes após a autorização. O atendente autorizado do fornecedor possui investigação de seus sistemas. A organização receptora não deve afirmar que provou a aquisição de um fornecedor apenas porque uma mensagem foi autenticada e o fornecedor negou a solicitação de pagamento. Uma integração, remetente delegado ou outro mecanismo pode exigir investigação.
Orientação sobre contas comprometidas da Microsoft lista regras de caixa de entrada suspeitas, encaminhamento e mensagens perdidas entre os possíveis indicadores e descreve a resposta da conta para Microsoft 365 . É uma referência para um fornecedor autorizado naquele ambiente, e não uma permissão para inspecionar as contas de outra organização. Nenhum acesso à conta, revogação de sessão, exclusão de regras ou coleta de credenciais faz parte do trabalho deste manuscrito.
Uma planilha de comprovação de alteração de pagamento
Crie uma planilha com quatro seções vinculadas. A seção de solicitação registra a referência do fornecedor, tipo de alteração, data solicitada e proprietário da empresa. A seção de identidade registra domínios reais, observações de autenticação confiável e a fonte de evidências. A seção de verificação registra a rota de contato estabelecida de forma independente, verificador autorizado, pergunta e resposta precisas. A seção de decisão registra aprovação ou rejeição, aprovadores necessários, caminho de implementação permitido e qualquer investigação não resolvida.
Mantenha os identificadores de contas financeiras fora de cópias de uso geral. Use espaços reservados consistentes onde a comparação for importante e armazene o original completo somente em um local restrito e aprovado. Adicione uma coluna distinguindo fatos observados de hipóteses. “ DKIM alinhado ao domínio do fornecedor observado em nosso receptor” só é um fato se a evidência o apoiar; “funcionário do fornecedor aprovou a mudança” requer confirmação comercial separada. A planilha nunca deve promover automaticamente o primeiro para o segundo.
Diagnóstico fictício: um tópico familiar de fornecedor
Uma equipe fictícia de instalações recebe uma solicitação em uma conversa estabelecida com um fornecedor solicitando a alteração de detalhes de pagamentos futuros. A mensagem usa o domínio real do fornecedor e hipoteticamente passa DMARC no destinatário. O destinatário assume que o thread existente e o resultado da autenticação tornam a alteração segura. Em vez disso, um segundo revisor pausa a atualização e verifica o registro do fornecedor aprovado para a rota de verificação estabelecida.
No exercício, o contato do fornecedor nega ter autorizado a alteração. Essa resposta apoia a rejeição do pedido no âmbito do processo empresarial, mas o mecanismo permanece sem solução até que esteja disponível evidência técnica autorizada. A investigação preservaria a mensagem e compartilharia um resumo mínimo aprovado, em vez de encaminhar amplamente os detalhes completos do pagamento. Este é um cenário fictício, não uma negação real, uma descoberta de compromisso, uma chamada de verificação ou uma perda evitada. Ele ilustra por que a verificação comercial e a autenticação de domínio respondem a perguntas diferentes.
Feche as trilhas financeiras e técnicas separadamente
Registre a disposição da alteração solicitada mesmo que a investigação técnica continue. Por outro lado, não declare o problema comercial resolvido apenas porque uma conta foi garantida: alguém pode já ter modificado um registro de fornecedor ou agido de acordo com a solicitação. Reconcilie o registro comercial real com a decisão autorizada e documente quem verificou o resultado. Qualquer ação desse tipo requer a autoridade normal da organização; nada foi realizado aqui.
O catálogo exige um cenário de abuso redigido com evidências de identidade, limite de controle e verificação comercial independente. Essa evidência original permanece aberta. A ficha de trabalho proposta e o exercício ficcional não o satisfazem. A revisão de especialistas humanos, a aplicabilidade da fonte, as rotas de produção, a acessibilidade e a liberação do proprietário também permanecem em aberto. Uma versão publicável precisa de um pacote de evidências autorizado que demonstre o processo de verificação sem expor identificadores financeiros ou fazer alegações não comprovadas sobre um fornecedor.