Um serviço legítimo pode entregar uma solicitação ilegítima. Um usuário pode abusar dos recursos normais de compartilhamento ou notificação de uma plataforma, uma conta pode ser comprometida ou um remetente autorizado pode fazer uma solicitação comercial não autorizada. A autenticação de domínio pode identificar corretamente o serviço ou o remetente configurado, deixando esses riscos sem solução. A investigação deve explicar ambos os fatos sem chamar cada mensagem maliciosa que passa de falha de autenticação.
Distinguir o serviço da solicitação
Registre o domínio De real, o domínio de assinatura, a identidade do envelope e os links na mensagem. Determine quais identidades pertencem ao serviço e quais pertencem a um domínio controlado pelo cliente. Não presuma que um logotipo familiar ou um nome de exibição visível significa que a mensagem originada da organização está sendo personificada. DKIM associa um domínio de assinatura a uma mensagem; não certifica a veracidade das declarações da mensagem. RFC 6376.
Pergunte o que a plataforma realmente autenticou. Pode ter autenticado uma sessão de conta, um domínio configurado ou um fluxo de trabalho de notificação. Nenhum estabelece necessariamente que o proprietário da conta pretendia uma alteração no pagamento ou que um documento compartilhado é seguro. Mantenha essas questões em aberto até que haja evidências do proprietário do serviço e do destinatário da empresa.
Crie uma matriz de requisitos e evidências
Use linhas separadas para autenticação de domínio, controle de conta, revisão de conteúdo e aprovação comercial. Cada linha precisa de um requisito, evidência, confiança, proprietário e próxima ação. Uma assinatura alinhada de passagem pode satisfazer uma linha estreita de autenticação de domínio sem satisfazer as outras. RFC 9989 descreve DMARCdo escopo baseado em domínio, em vez de uma garantia geral sobre o conteúdo. Especificação DMARC.
Para um pedido financeiro, a verificação independente é particularmente importante. Use uma rota de contato conhecida em vez do número de telefone ou endereço de resposta fornecido recentemente na mensagem. O FBI recomenda verificar de forma independente as solicitações de pagamento e alterações nos detalhes da conta. Orientação do FBI.
Leia o exemplo de carga de trabalho transparente
O exemplo escrito pressupõe uma mensagem de alteração de pagamento com autenticação alinhada, sem aprovação comercial e um contato de fornecedor conhecido negando a alteração. Sua matriz, portanto, retém o passe de autenticação enquanto mantém a alteração do pagamento em espera. Ele não infere se uma conta foi comprometida, se um recurso do serviço foi abusado ou se o suposto remetente participou.
O mesmo modelo hipotético utiliza uma carga de trabalho mensal ilustrativa de 10.000 mensagens, uma taxa de seleção de revisão de 1% e quatro minutos por mensagem selecionada. A aritmética rende 100 avaliações e cerca de 6,67 horas de analista. Essas são suposições de planejamento, e não taxas medidas de abuso de plataforma, benchmarks de pessoal ou preços de fornecedores. Eles excluem o escalonamento da investigação, fins de semana, tratamento de falsos positivos e coordenação de incidentes, portanto não constituem uma estimativa completa dos custos operacionais.
Investigue sem bloquear demais
Preserve identificadores de mensagens e referências de objetos específicos do provedor, se disponíveis, mas evite espalhar conteúdo confidencial de documentos desnecessariamente. Peça ao proprietário do serviço autorizado para investigar a atividade da conta, compartilhando configurações e registros de auditoria. Qualquer ação de contenção deve ter como escopo a ameaça verificada e ser permitida pelo processo de resposta da organização.
O bloqueio de todo um serviço popular pode interromper fluxos de trabalho legítimos sem resolver o comprometimento da conta em outro lugar. Considere se um remetente, objeto, URL ou ação de conta mais restrito é suportado e apropriado. Estes são critérios de decisão, não instruções para realizar uma remoção ou alterar a conta de outra pessoa sem autoridade.
Encerre com os fatos de identidade comprovados, as explicações causais não verificadas, o resultado do negócio e o proprietário da resposta. Se o serviço permanecer utilizável, preserve sua configuração de autenticação ao abordar o caminho do abuso. A remoção DKIM para evitar a aparência de confiança enfraqueceria um sinal útil sem tornar o conteúdo seguro. O objetivo é interpretar esse sinal corretamente e adicionar as verificações independentes exigidas pela solicitação.
Mantenha quatro linhas de evidências distintas
Para este caso inventado, a autenticação do domínio é estipulada; o administrador de e-mail possui verificação de evidências reais de recebimento. O controle da conta é desconhecido; o proprietário do serviço autorizado deve examinar a atividade real da conta. A segurança do conteúdo não está resolvida; a segurança é proprietária da revisão do conteúdo com escopo definido. A aprovação comercial está ausente e o fornecedor conhecido estipulado nega a solicitação; finanças retém a retenção de pagamento. Nenhum fornecedor real foi contatado, nenhuma conta foi investigada e nenhum pagamento foi alterado. O exemplo fornece uma estrutura de decisão e não provas que identificam um perpetrador.
Limite de origem e execução
RFC 9989 Seções 4.4, 5.3.5 e 5.4 distinguir autenticação, alinhamento e manuseio; um passe não endossa o conteúdo da mensagem. As decisões operacionais aqui são recomendações com escopo definido e exemplos explicitamente hipotéticos, e não novos testes de um cliente, fornecedor ou cenário histórico. Qualquer mudança real requer o seu próprio âmbito autorizado, provas retidas e decisão responsável.