Um registro de risco de autenticação de e-mail deve explicar qual serviço comercial pode ser prejudicado e qual decisão reduz esse risco. “DMARC ausente" é uma descoberta técnica, não uma declaração de risco completa. Conecte a condição a uma ameaça confiável ou caminho de falha, processo afetado, salvaguardas existentes e proprietário responsável.
Descreva o serviço e o cenário
Para cada entrada, registre o serviço, domínio, proprietário do aplicativo, condição técnica, tempo de evidência e provável consequência. Mantenha a incerteza explícita. Um remetente não observado é uma lacuna de evidência, enquanto um remetente legítimo não alinhado e verificado é um defeito de autenticação. Nenhum dos dois prova automaticamente que um invasor explorou o serviço.
RFC 9989 especifica autenticação de domínio e alinhamento comportamento. Suas proteções não estabelecem que toda solicitação autenticada seja legítima. Um registro de risco deve distinguir a representação direta do seu domínio de uma conta autorizada comprometida ou de um domínio semelhante que passa a autenticação por si mesmo.
Separe o risco inerente e o restante
Descreva o cenário antes dos controles e depois explique o que cada salvaguarda existente altera. Para instruções de fatura, a verificação de retorno de chamada de pagamento pode resolver solicitações comerciais fraudulentas que a autenticação de domínio por si só não consegue resolver. Não sugira que a existência de uma política de retorno de chamada por escrito prova que as pessoas a seguem de forma consistente.
Use as definições de probabilidade e impacto acordadas pela organização. Evite apresentar precisão inventada, como uma probabilidade anual de fraude de 17,3% sem evidências. Quando os dados forem insuficientes, utilize uma classificação qualitativa com a sua fundamentação e gatilho de revisão. Registre quem tem autoridade para aceitar o risco restante, em vez de tratar a aprovação técnica do administrador de e-mail como aceitação comercial.
Use um exemplo vinculado
Suponha que a entrada hipotética R-1 diga respeito à folha de pagamento. A condição é ausência de evidência atual de passagem alinhada em um serviço crítico registrado. A consequência potencial é a perda de notificações de folha de pagamento se uma rota não testada falhar durante a aplicação. Este é um cenário condicional e não uma alegação de que os funcionários perderam mensagens. As finanças são proprietárias do serviço, a equipe de correio é responsável pela investigação e o fechamento exige um teste de rota atual mais a confirmação do proprietário do serviço.
R-2 cobre a representação de pagamento de fatura por meio de um domínio semelhante de propriedade do invasor. O controle proposto é a verificação independente por meio de uma rota de contato já confiável. A publicação de uma política mais forte no domínio da vítima não satisfaz o teste de encerramento do R-2. Para cada entrada, exija uma constatação, proprietário, decisão e evidência explícita de fechamento antes de considerar o registro proposto como completo. Esta é uma regra de revisão recomendada, não uma validação executada ou prova de que um controle funciona.
Mantenha o registro acionável
Escolha o tratamento explicitamente: remediar, evitar a atividade de risco, transferir uma exposição definida quando apropriado ou aceitar o risco remanescente através do processo de decisão autorizado. Defina uma data de vencimento e um gatilho de revisão. Um plano de tratamento não é evidência de conclusão; reter o teste real ou registro de decisão separadamente.
Essas entradas hipotéticas ilustram diferentes cenários, não ataques observados ou riscos de negócios aceitos. Uma análise completa pode identificar campos em falta, mas não pode validar uma classificação de risco ou estabelecer que salvaguardas reais funcionam. Mantenha a evidência real e a decisão de aceitação autorizada separadas do tratamento proposto.
Revise o cadastro após migrações, novos remetentes, incidentes e mudanças de negócios. Feche apenas o cenário específico cujas evidências atendem ao teste declarado e retenha histórico suficiente para explicar por que foi fechado.
As seções 2.3 e 3.2 NIST SP 800-30 Rev. 1 descrevem os fatores de risco, abordagens de avaliação e documentam os resultados da avaliação. Apoiam a explicitação da probabilidade, do impacto e da incerteza; os campos de registro específicos de e-mail e os exemplos acima são uma aplicação proposta, não uma lista de verificação de conformidade prescrita. Guia de avaliação de risco.