Governar a fadiga de MFA e os ataques de bombardeamento de notificações push

A notificação push das 2h13 que se tornou uma questão para o Conselho de Administração

Às 2h13, uma administradora sénior da área financeira recebe uma notificação no telemóvel: “Aprovar início de sessão?”. Está meio adormecida, assume que se trata de uma expiração de sessão de uma plataforma financeira na nuvem e toca em aprovar.

Às 2h19, o atacante já está dentro do fornecedor de identidade. Às 2h31, tenta aceder a uma exportação de salários, a uma consola privilegiada na nuvem e a uma caixa de correio partilhada utilizada para pagamentos a fornecedores. Às 3h05, o SOC observa pedidos de MFA repetidos, geografia invulgar, uma aprovação bem-sucedida e uma nova sessão a partir de um dispositivo não gerido.

A conversa da manhã é familiar:

• “Mas tínhamos MFA.”
• “Porque é que a utilizadora aprovou?”
• “Registámos os detalhes do desafio de MFA?”
• “Isto é uma violação de dados pessoais?”
• “Temos obrigações de reporte em 24 horas ou 72 horas?”
• “O nosso auditor ISO 27001:2022 vai tratar isto como uma falha de controlo?”
• “Isto afeta NIS2, DORA, RGPD da UE, contratos com clientes ou seguro cibernético?”

Esta é a lacuna de governação por trás da fadiga de MFA e do bombardeamento de notificações push. Os atacantes não estão a quebrar a criptografia. Estão a esgotar a capacidade humana de decisão, a explorar uma conceção fraca da autenticação e a procurar exceções não monitorizadas. A falha de controlo raramente é “MFA não ativada”. Normalmente é uma cadeia de garantia de identidade fraca, desenho arriscado de aprovação push, ausência de correspondência numérica, regras pouco claras para acesso privilegiado, registo insuficiente de eventos de autenticação, triagem deficiente de alertas, utilizadores insuficientemente formados e falta de evidência documentada de que a organização reviu e corrigiu a fraqueza.

Para CISO, gestores de conformidade, auditores e responsáveis de negócio, a fadiga de MFA deve ser tratada como um problema de evidência do SGSI, e não apenas como uma definição do fornecedor de identidade. A resposta combina tratamento de riscos ISO 27001:2022, controlos ISO/IEC 27002:2022, obrigações de política, sensibilização dos utilizadores, resposta a incidentes, governação de fornecedores e mapeamentos entre referenciais para NIS2, DORA, RGPD da UE, NIST CSF 2.0 e COBIT 2019.

A fadiga de MFA é uma falha de garantia, não um problema do utilizador

A fadiga de MFA, também designada bombardeamento de notificações push ou bombardeamento de pedidos de autenticação, ocorre quando um atacante com uma palavra-passe válida aciona repetidamente pedidos de aprovação MFA até que o utilizador aceite um deles. Por vezes, o atacante acrescenta engenharia social, como uma chamada falsa do apoio técnico, uma mensagem a afirmar “estamos a testar a sua conta” ou um pedido para aprovar um início de sessão para parar as notificações.

O risco operacional está no facto de as organizações tratarem frequentemente todas as formas de MFA como equivalentes. Não são.

Uma notificação push simples de “aprovar ou negar” é mais fraca do que a correspondência numérica, chaves de segurança FIDO2 resistentes a phishing, autenticação baseada em certificados ou acesso condicional que bloqueia deslocação impossível e dispositivos não geridos. A MFA também falha quando as exceções de bypass não estão documentadas, as contas de serviço são interativas, os protocolos legados permanecem abertos ou o acesso de alto risco não exige autenticação reforçada.

No Zenith Blueprint: roteiro de 30 passos para auditores, a Clarysec enquadra a autenticação segura na fase Controls in Action, Passo 19: Controlos tecnológicos I. A orientação é direta:

A autenticação é a primeira e mais crítica linha de defesa entre um agente de ameaça e os seus sistemas, dados e serviços. Se a autenticação for fraca, tudo o resto — cifragem, monitorização, segmentação — pode ser contornado.

O mesmo Zenith Blueprint também aborda o controlo 5.17 da ISO/IEC 27002:2022 no Passo 22:

Se a identidade é a pergunta “Quem é?”, então a autenticação é a prova. O controlo 5.17 é onde a teoria se transforma em confiança. Exige que as informações de autenticação sejam geridas de forma segura ao longo de todo o seu ciclo de vida, garantindo que os métodos e as credenciais utilizados para verificar a identidade não se tornam eles próprios o elo mais fraco.

Estas duas afirmações explicam porque o bombardeamento de notificações push pertence ao Registo de Riscos. A cifragem não ajuda se o atacante se tornar um utilizador aprovado. A segmentação de rede ajuda menos se o acesso privilegiado na nuvem for aprovado através de um pedido num contexto de fadiga. A monitorização só funciona se os eventos de autenticação forem registados com detalhe suficiente e revistos rapidamente.

Uma declaração de risco madura deve ser explícita:

É aqui que a ISO 27001:2022 importa. A norma exige contexto, partes interessadas, liderança, avaliação de riscos, planeamento do tratamento, controlo operacional, monitorização, auditoria interna, revisão pela gestão e melhoria contínua. A fadiga de MFA toca em todos estes elementos.

O cluster de controlos ISO 27001:2022 que os auditores irão testar

A ISO 27001:2022 fornece a estrutura do sistema de gestão. A ISO/IEC 27002:2022 fornece orientação de implementação para os controlos. Para a fadiga de MFA e o bombardeamento de notificações push, os auditores irão normalmente concentrar-se num conjunto de controlos, e não num único controlo isolado.

O Zenith Controls: guia de conformidade cruzada da Clarysec mapeia o controlo 8.5 Autenticação segura da ISO/IEC 27002:2022 para controlos de suporte, como 5.17 Informações de autenticação, 8.2 Direitos de acesso privilegiado, 8.16 Atividades de monitorização, 5.24 Planeamento e preparação da gestão de incidentes de segurança da informação e 5.34 Privacidade e proteção de dados pessoais identificáveis (PII). Esta ligação cruzada é importante porque uma captura de ecrã que mostra “MFA ativada” não é suficiente. Os auditores querem evidência de que a autenticação é concebida, monitorizada, revista e melhorada com base no risco.

Um pacote de evidências defensável deve incluir:

1. Avaliação de riscos que identifique bombardeamento de notificações push e engenharia social de pedidos MFA.
2. Norma de autenticação que defina métodos MFA aceitáveis por criticidade do sistema.
3. Política de acesso privilegiado que exija autenticação reforçada para acesso administrativo e remoto.
4. Exportação da configuração do fornecedor de identidade que mostre correspondência numérica, limites de pedidos, acesso condicional e autenticação legada bloqueada.
5. Logs que mostrem eventos MFA bem-sucedidos e falhados, pedidos negados, deslocação impossível e contexto do dispositivo.
6. Regras de alerta para pedidos MFA repetidos, falhas repetidas e aprovação bem-sucedida invulgar.
7. Registos de resposta a incidentes para alertas relacionados com autenticação.
8. Conteúdo de formação de sensibilização que instrua os utilizadores a não aprovarem pedidos inesperados.
9. Registos de revisão de acessos para sistemas privilegiados e de alto impacto.
10. Registo de Exceções com datas de expiração, aprovações do Proprietário do risco e controlos compensatórios.

A política transforma “não aprovar pedidos inesperados” em evidência

Muitas organizações dizem aos utilizadores para não aprovarem pedidos suspeitos. Esse conselho é útil, mas não é suficiente para certificação ISO 27001:2022, supervisão NIS2, resiliência DORA, responsabilização ao abrigo do RGPD da UE, diligência prévia de clientes ou seguro cibernético.

O primeiro ponto de ancoragem na política é a P38 Política de Comunicações Seguras e Autenticação Multifator (MFA). Aborda diretamente o fator humano:

Sensibilização dos utilizadores: os utilizadores devem receber formação para distinguir canais de comunicação seguros de canais inseguros. A formação deve abranger a utilização correta da autenticação multifator (MFA) (por exemplo, não aprovar pedidos de início de sessão inesperados) e práticas de comunicação segura (por exemplo, verificar links de videoconferência e não discutir temas confidenciais através de linhas não seguras).

Isto transforma a fadiga de MFA numa obrigação de formação, não num exercício de atribuição de culpa. Permite ao CISO demonstrar que o bombardeamento de pedidos é abordado na integração, na formação de reciclagem, na formação baseada em funções e nos briefings de utilizadores privilegiados.

A mesma P38 Política de Comunicações Seguras e Autenticação Multifator (MFA) também cria uma obrigação de monitorização:

A Segurança da Informação deve monitorizar continuamente os logs de autenticação para detetar quaisquer tentativas de autenticação com fator único ou falhas anómalas de autenticação multifator (MFA). Os logs dos sistemas de comunicação segura, quando aplicável, devem ser monitorizados quanto a tentativas de acesso não autorizado ou alterações de configuração.

Para PME, a P11S Política de Gestão de Contas de Utilizador e Privilégios - PME estabelece uma linha de base prática:

A autenticação multifator (MFA) deve estar ativada, quando tecnicamente viável, para contas de administrador ou sistemas sensíveis.

A expressão “quando tecnicamente viável” nunca deve tornar-se uma lacuna. Se um sistema não suportar MFA forte, a exceção deve ser registada com proprietário, data de expiração, controlos compensatórios, monitorização e plano de migração. Organizações maiores podem alinhar a mesma expectativa com a P11 Política de Gestão de Contas de Utilizador e Privilégios e depois testar se a política e a realidade operacional coincidem.

A evidência de deteção vem da P22S Política de Registo de Eventos e Monitorização - PME, que exige o registo de eventos de autenticação:

Logs de autenticação: tentativas de início de sessão bem-sucedidas e falhadas, duração das sessões, utilização de MFA

Também exige revisão urgente de sinais de autenticação de alto risco:

Revisão imediata após deteção de alertas de alta severidade (por exemplo, malware, falha de autenticação multifator (MFA), falhas repetidas de início de sessão)

A sensibilização deve evoluir à medida que as ameaças evoluem. A Política de Sensibilização e Formação em Segurança da Informação - PME suporta esse ciclo:

Os temas devem incluir ameaças emergentes (por exemplo, phishing), alterações relevantes às políticas e tendências internas de incidentes.

Quando o SOC deteta tentativas de fadiga de MFA, essas informações sobre ameaças devem alimentar alertas aos utilizadores, guiões do apoio técnico, exercícios de tabletop e atualizações de formação.

Um pacote governado de controlos contra a fadiga de MFA

Assuma que a sua organização utiliza um fornecedor de identidade na nuvem, um CRM SaaS, uma plataforma financeira, uma VPN e um prestador de serviços de segurança geridos. O objetivo é governar a fadiga de MFA utilizando o Zenith Blueprint da Clarysec, a biblioteca de políticas e o guia de conformidade cruzada Zenith Controls.

Comece pelo Passo 19 do Zenith Blueprint, que instrui as equipas a definir requisitos de autenticação por sistema e alerta que a autenticação apenas por palavra-passe deve ser evitada para contas administrativas, consolas na nuvem, ferramentas de acesso remoto e sistemas expostos à Internet. Em seguida, aplique a atividade prática de revisão:

Reveja a sua implementação de MFA: identifique lacunas e planeie a sua correção. Valide que as contas de serviço são não interativas sempre que possível, têm credenciais robustas e estão documentadas. Confirme que não permanecem credenciais predefinidas em qualquer sistema ou aplicação.

Converta essa orientação num pacote de controlos operacionais.

Passo 1: classificar sistemas por risco de autenticação

Passo 2: remover comportamentos push de alto risco

Para contas de administrador e de alto impacto, desative a aprovação push básica. Utilize autenticadores resistentes a phishing sempre que possível. Quando o push permanecer, imponha correspondência numérica, contexto da aplicação, contexto geográfico, vinculação ao dispositivo e limitação da taxa de pedidos. Bloqueie a autenticação legada e exija reautenticação para sessões de risco.

Passo 3: definir regras de alerta para fadiga de MFA

Uma regra SIEM prática deve disparar quando um ou mais destes padrões ocorrerem numa janela curta:

• Três ou mais pedidos push MFA para um utilizador.
• Dois pedidos negados seguidos de um pedido aprovado.
• Aprovação MFA a partir de uma nova geografia ou de um dispositivo não gerido.
• Pedido MFA após um sinal de password spraying ou credential stuffing.
• Aprovação MFA para acesso privilegiado fora do horário normal de trabalho.
• Registo de novo autenticador pouco depois de tentativas falhadas de início de sessão.

O alerta deve criar um ticket de incidente, notificar o SOC ou o Responsável de Segurança e exigir passos de contenção: suspender a sessão, revogar tokens de atualização, exigir reposição de palavra-passe, verificar o dispositivo, entrevistar o utilizador, rever o acesso durante a sessão e classificar se ocorreu impacto em dados pessoais ou em serviço crítico.

Passo 4: ligar registos de privacidade e de incidentes

Se a conta puder aceder a dados pessoais, aplique a Política de Segurança e Controlo de Acesso a Dados Pessoais. Esta exige autenticação forte antes de acesso a dados pessoais de alto impacto:

[Ambos] O Responsável de Segurança da Informação DEVE exigir autenticação forte para acesso privilegiado, remoto, administrativo ou a dados pessoais de alto impacto antes de esse acesso ser ativado e registar o requisito em REG12.

Também exige que o âmbito de registo de eventos relativo a dados pessoais seja definido:

[Ambos] O Proprietário do sistema / Proprietário da aplicação DEVE definir o âmbito de registo de eventos relativo a dados pessoais para eventos de autenticação, eventos de acesso, ações privilegiadas, atividade de exportação de dados pessoais e alterações materiais de configuração em REG12 antes da utilização em produção ou de alteração material.

Quando a monitorização sugere acesso não autorizado a dados pessoais, cria uma obrigação de registo de incidente:

[Condicional] O Coordenador de Resposta a Incidentes DEVE abrir ou associar um registo REG10 no prazo de um dia útil quando a monitorização indicar suspeita de acesso não autorizado a dados pessoais, suspeita de divulgação de dados pessoais, suspeita de alteração de dados pessoais ou suspeita de perda de disponibilidade de dados pessoais.

O escalonamento de privacidade é completado pela Política de Gestão de Incidentes e Violações de Dados Pessoais:

[Condicional] O Responsável de Privacidade / Gestor do PIMS DEVE avaliar os desencadeadores de reporte legais, setoriais, do setor financeiro, de cibersegurança, contratuais, de clientes e de destinatários dos serviços aplicáveis a cada incidente de alto impacto relativo a dados pessoais e registar o resultado da aplicabilidade em REG01, REG08 e REG10.

É isto que transforma um alerta MFA em evidência pronta para auditoria em segurança, privacidade e conformidade.

NIS2, DORA e RGPD da UE: um incidente, perguntas diferentes

A fadiga de MFA é um teste de esforço útil de conformidade cruzada porque toca em governação, higiene de cibersegurança, controlo de acesso, deteção de incidentes, acesso de fornecedores e reporte de violações.

NIS2: responsabilização da gestão e higiene de cibersegurança

A NIS2 aplica-se a muitas entidades essenciais e importantes, dependendo do setor, da dimensão e da designação pelo Estado-Membro. O Article 20 atribui responsabilidade aos órgãos de administração pela aprovação das medidas de gestão de riscos de cibersegurança, pela supervisão da implementação e pela receção de formação. O Article 21 exige medidas técnicas, operacionais e organizativas adequadas, incluindo tratamento de incidentes, higiene de cibersegurança, segurança da cadeia de fornecimento, controlo de acesso, gestão de ativos, formação e autenticação multifator ou autenticação contínua quando adequado. O Article 23 introduz obrigações faseadas de reporte de incidentes para incidentes significativos, incluindo alerta precoce no prazo de 24 horas após a tomada de conhecimento e notificação de incidente no prazo de 72 horas.

Um incidente de bombardeamento de notificações push torna-se, portanto, uma questão para o Conselho de Administração: a MFA foi concebida de forma segura ou apenas ativada?

DORA: autenticação como resiliência operacional digital

Para as entidades financeiras abrangidas, o DORA é aplicável desde 17 de janeiro de 2025. Exige gestão do risco das TIC, deteção, resposta, recuperação, reporte de incidentes, testes de resiliência operacional digital e gestão do risco de terceiros de TIC.

O Article 9 do DORA aborda proteção e prevenção, incluindo controlo de acesso e medidas de autenticação. O Article 10 aborda a deteção de atividade anómala. O Article 17 exige um processo de gestão de incidentes relacionados com TIC. Num contexto DORA, a evidência de fadiga de MFA deve demonstrar que os ativos de TIC afetados foram identificados, que a monitorização detetou comportamento anómalo, que o incidente foi classificado segundo critérios de impacto, que houve escalonamento para a alta direção quando exigido e que as lições aprendidas foram reintegradas no quadro de risco das TIC.

RGPD da UE: segurança do tratamento e responsabilização

O Article 5(1)(f) do RGPD da UE exige integridade e confidencialidade. O Article 5(2) exige responsabilização. O Article 32 exige segurança adequada ao risco. O Article 4 define uma violação de dados pessoais como uma violação da segurança que conduza, de modo acidental ou ilícito, à destruição, perda, alteração, divulgação não autorizada ou acesso a dados pessoais.

Se um incidente de fadiga de MFA envolver dados pessoais, a pergunta de evidência é simples: a organização consegue demonstrar controlos de autenticação adequados, monitorização, resposta a incidentes e avaliação da violação de dados pessoais?

Mapeamento para ISO, NIST CSF 2.0, COBIT 2019 e evidência de auditoria

O NIST CSF 2.0 é útil porque traduz a governação de MFA em resultados GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND e RECOVER.

O COBIT 2019 acrescenta clareza de governação. Um auditor orientado pelo COBIT pode consultar DSS05.04 Gerir identidade e acesso lógico, DSS05 Gerir serviços de segurança, APO13 Gerir segurança e MEA03 Gerir conformidade com requisitos externos. O foco não é o fornecedor de MFA. É saber se a autenticação suporta objetivos de negócio, se os direitos de acesso são governados, se a monitorização é eficaz e se a gestão recebe garantia significativa.

Um mapeamento consolidado ajuda as equipas de conformidade a evitar pedidos fragmentados de evidência:

O que auditores e reguladores vão solicitar

Um programa robusto contra a fadiga de MFA deve resistir a vários estilos de auditoria. O guia de conformidade cruzada Zenith Controls da Clarysec mostra como os controlos ISO/IEC 27002:2022 são testados através de metodologias ISO, NIST, COBIT e ISACA.

Um programa fraco diz: “Perguntámos ao utilizador e repusemos a palavra-passe.” Um programa governado produz um alerta SIEM, ticket de incidente, registo de revogação de sessão, evidência de reposição de palavra-passe, revisão do fator MFA, análise dos logs de acesso, avaliação de dados pessoais, avaliação dos desencadeadores de reporte, declaração de causa raiz, ações corretivas e contributo para a revisão pela gestão.

Plano de ação de 30 dias para a governação da fadiga de MFA

O objetivo não é a perfeição em 30 dias. O objetivo é visibilidade, propriedade e evidência.

Semana 1: identificar e definir o âmbito

• Listar todos os fornecedores de identidade, VPN, consolas na nuvem, plataformas SaaS e ferramentas de acesso privilegiado.
• Identificar sistemas com dados pessoais, dados financeiros, acesso à produção ou funções com impacto no serviço.
• Exportar os métodos MFA e as exceções atuais.
• Identificar contas externas e de fornecedores.
• Adicionar a fadiga de MFA e o bombardeamento de notificações push ao Registo de Riscos.
• Atribuir um Proprietário do risco e um responsável pelo tratamento.

Semana 2: reforçar a autenticação

• Desativar a autenticação legada.
• Exigir MFA resistente a phishing para administradores, sempre que viável.
• Ativar correspondência numérica e contexto da aplicação para MFA push.
• Aplicar acesso condicional para localização, conformidade do dispositivo e deslocação impossível.
• Limitar pedidos push repetidos.
• Exigir reautenticação para ações de alto risco.
• Tornar as contas de serviço não interativas sempre que possível.
• Documentar exceções com expiração e controlos compensatórios.

Semana 3: monitorizar e ensaiar

• Assegurar que os logs de autenticação capturam sucesso, falha, duração da sessão e utilização de MFA.
• Criar regras de alerta para pedidos repetidos, pedidos negados seguidos de aprovação, registo de novo dispositivo e localização invulgar.
• Testar alertas com uma simulação controlada.
• Validar a criação e o escalonamento de tickets de incidente.
• Formar os utilizadores com um exercício curto sobre “pedido MFA inesperado”.
• Atualizar guiões do apoio técnico para prevenir engenharia social durante reposições de palavra-passe e reinscrição MFA.

Semana 4: evidência e revisão pela gestão

• Armazenar exportações de configuração e capturas de ecrã.
• Registar resultados da revisão de acessos.
• Ligar a conclusão da formação aos utilizadores privilegiados.
• Rever incidentes e quase-incidentes.
• Atualizar a Declaração de Aplicabilidade e o plano de tratamento.
• Apresentar o risco residual e as métricas à gestão.
• Agendar amostragem de auditoria interna.

Tornar a fadiga de MFA auditável antes de se tornar reportável

A fadiga de MFA é um lembrete de que os controlos de segurança falham nas interfaces: entre identidade e monitorização, entre política e formação, entre fornecedores e acesso interno, entre resposta a incidentes e reporte de privacidade.

As organizações que a gerem bem não se limitam a “ativar MFA”. Governam a autenticação como um ciclo de vida, monitorizam-na como sinal de ameaça, formam os utilizadores como parte do controlo e preservam evidência como parte do SGSI.

A Clarysec reúne três ativos:

• O Zenith Blueprint: roteiro de 30 passos para auditores, especialmente o Passo 19 para autenticação segura, o Passo 22 para informações de autenticação e o Passo 16 para comunicação de incidentes impulsionada pelo pessoal.
• Modelos de políticas da Clarysec, incluindo a P38 Política de Comunicações Seguras e Autenticação Multifator (MFA), a P22S Política de Registo de Eventos e Monitorização - PME, a P11S Política de Gestão de Contas de Utilizador e Privilégios - PME, a Política de Sensibilização e Formação em Segurança da Informação - PME, a Política de Segurança e Controlo de Acesso a Dados Pessoais e a Política de Gestão de Incidentes e Violações de Dados Pessoais.
• O Zenith Controls: guia de conformidade cruzada, que mapeia os controlos ISO/IEC 27002:2022 5.17, 8.5, 8.15 e 8.16 para controlos de suporte, expectativas de auditoria ISO, RGPD da UE, NIS2, DORA, NIST e COBIT.

Se é CISO, gestor de conformidade, auditor ou responsável de negócio, execute uma revisão de evidência da fadiga de MFA numa semana. Recolha a sua configuração MFA, logs de autenticação, lista de acessos privilegiados, lista de acessos de fornecedores, playbook de incidentes, material de formação e Registo de Exceções. Se esses artefactos não contarem uma história coerente, a Clarysec pode ajudá-lo a construir o pacote de controlos antes que um atacante, auditor ou regulador o solicite.

Explore o Zenith Blueprint, reveja o Zenith Controls ou agende uma chamada de descoberta com a Clarysec para transformar a fadiga de MFA de uma surpresa ao nível do Conselho de Administração num programa de autenticação defensável e auditável.