Modelação de ameaças para ISO 27001, NIS2 e DORA

Pediram a Anya, CISO de uma fintech em rápido crescimento, que aprovasse o plano de lançamento de uma nova plataforma B2B de risco de pagamentos. O conselho de administração queria entrar no mercado antes do fim do trimestre. A equipa comercial já tinha clientes bancários alinhados. A engenharia tinha esboçado uma arquitetura nativa da nuvem com atributos de identidade, sinais de dispositivos, metadados de transações, pontuações de risco comportamental, uma base de dados gerida e um fornecedor terceiro de análise de dados.

Em papel, a plataforma parecia uma oportunidade comercial decisiva. Para Anya, parecia cinco conversas de conformidade a chegar ao mesmo tempo.

Enquanto fornecedor de tecnologia financeira, a empresa sentia pressão da DORA. Enquanto prestador de serviços cloud e fornecedor de plataforma digital, precisava de compreender a sua exposição à NIS2. Como a plataforma tratava dados pessoais relativos a pessoas na UE, aplicava-se o GDPR. Os clientes empresariais esperavam certificação ISO/IEC 27001:2022. Se o serviço viesse a integrar um produto de software conectado, as expectativas do Cyber Resilience Act acrescentariam evidência de produto seguro desde a conceção.

A equipa de desenvolvimento propôs o plano de segurança habitual: analisar dependências, executar uma análise de vulnerabilidades, agendar um teste de intrusão e corrigir as constatações críticas antes da entrada em produção. Anya sabia que isso não era suficiente. Essas atividades testam o que já foi construído. Não demonstram que a arquitetura foi segura desde a conceção, que os limites de confiança foram compreendidos, que os fluxos de dados pessoais foram minimizados, que as premissas sobre fornecedores foram revistas ou que os cenários de interrupção de serviços foram considerados antes do lançamento.

Por isso, abrandou a reunião com quatro perguntas:

1. Onde estão os limites de confiança?
2. Que casos de abuso poderiam conduzir a fraude, exposição de dados ou interrupção de serviços?
3. Que decisões de conceção reduzem o risco antes de o código ser escrito?
4. Que evidência satisfará os revisores de ISO 27001, NIS2, DORA, CRA e GDPR daqui a seis meses?

É nessa quarta pergunta que muitas organizações falham. A modelação de ameaças é frequentemente tratada como um workshop útil de engenharia e depois enterrada numa página wiki. Em 2026, isso já não chega. Para fornecedores SaaS, fintechs, plataformas cloud, MSP, MSSP, operadores de infraestruturas digitais e fabricantes de software, a modelação de ameaças tornou-se um motor de evidência de conformidade.

Um processo maduro de modelação de ameaças transforma constatações STRIDE, casos de abuso e decisões arquiteturais em entradas do Registo de Riscos, requisitos de segurança, planos de tratamento, casos de teste, atividades de garantia de fornecedores, evidência de privacidade desde a conceção e rastreabilidade para a Declaração de Aplicabilidade.

Porque é que a evidência de segurança desde a conceção importa agora

A regulamentação moderna está a convergir em torno da mesma expectativa: as organizações devem identificar riscos de segurança e privacidade numa fase inicial, atribuir propriedade, implementar controlos proporcionais e reter evidência.

A ISO/IEC 27001:2022 exige um Sistema de Gestão da Segurança da Informação baseado no risco. As cláusulas 6.1.2 e 6.1.3 exigem avaliação e tratamento de riscos de segurança da informação. A cláusula 8.1 exige planeamento e controlo operacional. O Anexo A fornece controlos que devem ser selecionados através da Declaração de Aplicabilidade com base no risco, nos requisitos legais e nas necessidades do negócio.

A NIS2 aplica o mesmo princípio à governação da cibersegurança. O Article 20 exige que os órgãos de gestão aprovem medidas de gestão de riscos de cibersegurança e supervisionem a sua implementação. O Article 21 exige medidas técnicas, operacionais e organizacionais adequadas e proporcionais, incluindo análise de riscos, tratamento de incidentes, continuidade de negócio, segurança da cadeia de fornecimento, segurança na aquisição, desenvolvimento e manutenção, tratamento de vulnerabilidades, higiene de cibersegurança, cifragem, controlo de acesso, gestão de ativos e MFA quando adequado.

A DORA aplica uma perspetiva de resiliência operacional ao setor financeiro desde 17 de janeiro de 2025. Exige que as entidades financeiras abrangidas mantenham um quadro de gestão do risco associado às TIC sólido, abrangente e documentado, identifiquem ativos de TIC e dependências, apliquem medidas de proteção e prevenção, detetem atividade anómala, testem a resiliência operacional digital, giram o risco associado a terceiros prestadores de serviços TIC e preparem capacidades de resposta e recuperação. Para as entidades financeiras abrangidas, a DORA é o ato jurídico setorial da União para obrigações NIS2 sobrepostas.

O GDPR acrescenta responsabilização e proteção de dados desde a conceção e por defeito. Qualquer sistema que trate dados pessoais deve conseguir demonstrar tratamento lícito, leal, transparente, limitado à finalidade, minimizado, limitado no prazo de conservação e seguro. Um modelo de ameaças que mapeie fluxos de dados pessoais, caminhos de acesso, registos de eventos, retenção, apagamento e transferências para terceiros é diretamente relevante para os Articles 5, 25, 32 e 35 do GDPR.

O Cyber Resilience Act acrescenta pressão para produtos com elementos digitais. As equipas de produto precisam de evidência ao longo do ciclo de vida que demonstre que riscos de cibersegurança, utilização indevida previsível, interfaces, mecanismos de atualização, fluxos de autenticação e premissas de tratamento de vulnerabilidades foram considerados numa fase inicial.

A lição é clara: se uma revisão da arquitetura não puder ser rastreada até riscos, controlos, proprietários, mitigações e testes, será difícil defendê-la numa auditoria ou revisão regulatória em 2026.

O modelo Clarysec: um modelo de ameaças, muitos resultados

A abordagem da Clarysec começa com um princípio prático: um modelo de ameaças não está completo enquanto não produzir decisões auditáveis.

Em Zenith Blueprint: roteiro de 30 etapas para auditores [ZB], a fase de Gestão de Riscos, etapa 9, dá às equipas um formato simples para converter observações técnicas em linguagem de risco:

“Agora combine Ativo + Ameaça + Vulnerabilidade numa descrição concisa de cenário de risco. Essencialmente, descreva o incidente potencial. Mais tarde, isto será uma linha no seu Registo de Riscos. Use um formato simples: ‘[Ameaça] explora [vulnerabilidade] em [ativo], resultando em [impacto].’”

Essa frase é a ponte entre engenharia e conformidade.

Uma nota num quadro branco como “risco de falsificação de identidade na API do parceiro” torna-se:

“Um atacante explora autenticação fraca da API do parceiro na API de risco de transações, resultando em acesso não autorizado a decisões de risco de pagamentos e exposição de dados pessoais.”

Agora a constatação tem ativo, ameaça, vulnerabilidade e impacto. Pode ser avaliada, atribuída, tratada, testada e aceite.

A camada de políticas torna isto repetível. A P24 Política de Desenvolvimento Seguro [P24] estabelece:

“Todas as novas aplicações e alterações de maior impacto devem ser sujeitas a revisão de arquitetura segura e modelação de ameaças antes do início do desenvolvimento.”
Da secção “Requisitos de implementação da política”, cláusula 6.1.1 da política.

Também exige:

“As revisões de conceção devem documentar diagramas de fluxo de dados, limites de confiança e medidas de mitigação para os riscos identificados.”
Da secção “Requisitos de implementação da política”, cláusula 6.1.2 da política.

Essas duas cláusulas são âncoras fortes para auditoria. Demonstram que a modelação de ameaças não é opcional e que a evidência de conceção deve incluir diagramas, limites e decisões de mitigação.

A P06 Política de Gestão de Riscos [P06] liga a modelação de ameaças à gestão de riscos empresarial:

“Todas as unidades de negócio devem identificar riscos de forma proativa utilizando técnicas estruturadas derivadas da ISO/IEC 27005:2024, incluindo modelação de ameaças, mapeamento de dependências de ativos e identificação baseada em cenários.”
Da secção “Requisitos de implementação da política”, cláusula 6.1.1 da política.

Também estabelece:

“Os riscos identificados devem ser documentados com referência ao proprietário do ativo, agente de ameaça, vulnerabilidade e impacto potencial na Confidencialidade, Integridade e Disponibilidade (CID).”
Da secção “Requisitos de implementação da política”, cláusula 6.1.4 da política.

Esta é a cadeia de evidência que os auditores querem ver: requisito da política, atividade de conceção, cenário de risco, seleção de controlos, implementação, testes e aprovação.

STRIDE torna a cobertura sistemática; os casos de abuso tornam-na real

STRIDE continua a ser um dos métodos mais úteis para modelação de ameaças na fase de conceção porque obriga as equipas a considerar seis modos de falha comuns:

• Falsificação de identidade
• Adulteração
• Repúdio
• Divulgação de informação
• Negação de serviço
• Elevação de privilégios

Na plataforma de risco de pagamentos de Anya, a equipa aplicou STRIDE a cada componente, fluxo de dados e limite de confiança.

A falsificação de identidade levantou a questão de saber se um cliente de API de um parceiro poderia personificar indevidamente um cliente bancário se a autenticação mútua fosse fraca. A adulteração expôs o risco de sinais de dispositivos ou montantes de transações serem manipulados antes da ingestão. O repúdio destacou a necessidade de registos de auditoria de administradores e transações. A divulgação de informação focou-se em fuga de dados através de registos de eventos, exportações de análise de dados, ferramentas de suporte e APIs de reporte. A negação de serviço obrigou a equipa a considerar janelas de pico de transações e inundações de pedidos malformados. A elevação de privilégios expôs riscos em funções de suporte, tokens de sessão e funções administrativas.

Os casos de abuso converteram essas categorias em histórias reais:

• Um fraudador carrega sinais de dispositivo manipulados para influenciar uma pontuação de risco.
• Uma credencial de parceiro comprometida inunda a API com pedidos fraudulentos.
• Um programador utiliza dados pessoais de produção num ambiente de teste.
• Um utilizador interno malicioso exporta identificadores de clientes e lógica de pontuação.
• Uma indisponibilidade do fornecedor cloud de análise de dados bloqueia decisões de risco durante uma janela de pagamentos.
• Uma configuração incorreta de armazenamento expõe documentos de identidade carregados.
• Um fluxo de apagamento remove o registo da aplicação, mas deixa cópias de segurança e cópias no fornecedor.

Cada caso de abuso tornou-se um registo de risco de conceção com o ativo afetado, agente de ameaça, vulnerabilidade, impacto, premissas existentes, mitigação necessária, proprietário do risco residual, evidência de teste e relevância regulamentar.

Essa estrutura evita constatações vagas como “risco de segurança da API”. Produz declarações de risco com qualidade de evidência, como:

“Um atacante utiliza credenciais de parceiro roubadas para submeter pedidos fraudulentos de pontuação através da API de risco de transações, resultando no comprometimento da integridade das decisões de risco, possível perda financeira para os clientes e tratamento não autorizado de dados pessoais.”

Mapeamento da modelação de ameaças para ISO/IEC 27001:2022 e ISO/IEC 27002:2022

A ISO/IEC 27001:2022 não exige modelação de ameaças pelo nome. Exige avaliação de riscos e tratamento de riscos consistentes e documentados. A modelação de ameaças é um dos métodos mais fortes para gerar essa evidência em ambientes de software, cloud e produto.

A chave é a rastreabilidade. Em ZB, a fase de Gestão de Riscos, etapa 13, recomenda mapear controlos para riscos e cláusulas, incluindo referências ao Anexo A nos planos de tratamento e assinalando onde os controlos apoiam GDPR, NIS2 ou DORA.

Zenith Controls: guia de conformidade transversal [ZC] ajuda a estruturar essa rastreabilidade ao mapear controlos ISO/IEC 27002:2022 para controlos relacionados, expectativas de auditoria e referenciais externos.

Para a modelação de ameaças, o controlo 5.8 da ISO/IEC 27002:2022, segurança da informação na gestão de projetos, é a âncora de governação do projeto. Mostra que a segurança está integrada na iniciação, planeamento, execução e aceitação do projeto.

O controlo 8.25, ciclo de vida de desenvolvimento seguro, é a âncora do SDLC. ZC liga o 8.25 a controlos de apoio como 8.26 requisitos de segurança das aplicações, 8.27 princípios de arquitetura e engenharia de sistemas seguros, 8.28 programação segura, 8.29 testes de segurança no desenvolvimento e na aceitação, 8.30 desenvolvimento externalizado e 8.31 separação de ambientes de desenvolvimento, teste e produção.

Este mapeamento ajuda a transformar um workshop de conceção em evidência para a Declaração de Aplicabilidade. Também apoia as cláusulas 4 a 6 da ISO/IEC 27001:2022, porque os requisitos das partes interessadas, o âmbito do SGSI, os compromissos da liderança e as decisões de tratamento de riscos ficam visíveis.

Um mapa de conformidade transversal para NIS2, DORA, CRA, GDPR e NIST CSF

Um modelo de ameaças bem executado não deve produzir cinco linhas de trabalho de conformidade desconexas. Deve produzir um único pacote de evidência de risco de conceção reutilizável em vários referenciais.

O NIST CSF 2.0 é especialmente útil para comunicação executiva. A sua função GOVERN apoia obrigações legais, regulamentares, contratuais e de privacidade, enquanto os seus resultados relativos à cadeia de fornecimento ajudam a ligar criticidade de fornecedores, requisitos contratuais, diligência prévia, monitorização e planeamento de incidentes à mesma evidência de modelação de ameaças.

O GDPR exige atenção especial porque a modelação de ameaças e o trabalho de AIPD devem reforçar-se mutuamente. A P17 Política de Proteção de Dados e Privacidade [P17] estabelece:

“A modelação de ameaças e as Avaliações de Impacto sobre a Proteção de Dados (AIPD) são obrigatórias para sistemas de tratamento de alto risco.”
Da secção “Requisitos de implementação da política”, cláusula 6.3.4 da política.

Para equipas mais pequenas, a P17S Política de Proteção de Dados e Privacidade - PME [P17S] estabelece:

“A privacidade desde a conceção e por defeito deve ser aplicada em todos os novos sistemas e serviços”
Da secção “Requisitos de governação”, cláusula 5.3.1 da política.

O resultado é um modelo operacional prático: utilizar os mesmos diagramas de fluxo de dados, limites de confiança e casos de abuso para risco de segurança, risco de privacidade, revisão de fornecedores e evidência regulamentar.

Um sprint de risco de conceção de 90 minutos para funcionalidades de alto risco

A modelação de ameaças não precisa de começar como um programa pesado. Para uma nova API de pagamentos, fluxo de integração, funcionalidade com IA, serviço de identidade, migração para a nuvem ou integração externa, um sprint de risco de conceção de 90 minutos pode produzir evidência valiosa.

1. Abrir um ponto de controlo de segurança do projeto

Use a cláusula 6.1.1 da P24 como acionador. Para cada nova aplicação ou alteração de maior impacto, crie uma pasta de evidência com:

• Diagrama de arquitetura
• Diagrama de fluxo de dados
• Mapa de limites de confiança
• Lista de ativos
• Notas sobre dados pessoais
• Lista de dependências de fornecedores e de TIC
• Requisitos iniciais de segurança
• Folha de trabalho do modelo de ameaças
• Entradas do Registo de Riscos
• Rastreabilidade entre mitigação e teste
• Registo de aprovação

Para organizações mais pequenas, a P24S Política de Desenvolvimento Seguro - PME [P24S] apoia a mesma disciplina ao ligar processos de desenvolvimento seguro a controlo de acesso de programadores, testes, modelação de ameaças e documentação. Também exige retenção centralizada de listas de verificação, aprovações de revisão, relatórios de teste e inventários de componentes para fins de auditoria. A cláusula 11.3.1 referencia SA-3 a SA-15 para definir processos de desenvolvimento seguro, incluindo modelação de ameaças.

2. Desenhar o fluxo de dados mínimo viável

Não comece com um diagrama polido. Comece pelos fluxos que criam risco:

• O utilizador carrega documentos de identidade ou dados de transações.
• A aplicação web envia pedidos para a API.
• A API escreve para armazenamento gerido ou para uma base de dados.
• O fornecedor recebe dados de verificação ou análise.
• O portal interno de analistas apresenta resultados.
• O sistema do cliente consulta estados ou decisões.
• Registos de eventos, ferramentas de monitorização e cópias de segurança recebem cópias.

Assinale cada limite de confiança: Internet para aplicação, aplicação para API, serviço interno para fornecedor, sistema de produção para análise de dados, administrador para função privilegiada e produção para ambiente de não produção.

3. Executar STRIDE e casos de abuso em conjunto

Para cada limite, faça as perguntas STRIDE e escreva casos de abuso em linguagem simples de negócio. O objetivo não é listar todos os ataques imagináveis. O objetivo é identificar cenários plausíveis e materiais que afetem confidencialidade, integridade, disponibilidade, privacidade, resiliência ou segurança física/operacional.

4. Converter constatações em cenários de risco

Use a fórmula da etapa 9 de ZB:

“[Ameaça] explora [vulnerabilidade] em [ativo], resultando em [impacto].”

Por exemplo:

“Um atacante explora controlos fracos de acesso ao armazenamento de objetos no repositório de documentos de identidade, resultando em divulgação não autorizada de dados pessoais e exposição a obrigações de notificação regulamentar.”

Depois acrescente proprietário, probabilidade, impacto, risco inerente, opção de tratamento, controlo-alvo, risco residual e evidência.

5. Derivar requisitos e testes

Um modelo de ameaças não está concluído quando os riscos são listados. Está concluído quando as mitigações são implementadas, testadas ou formalmente aceites.

A Política de Gestão de Alterações - PME fornece um acionador prático:

“Se uma alteração envolver dados sensíveis, direitos de acesso ao sistema ou integrações externas, é necessária uma revisão do impacto na segurança. O ponto de contacto designado para segurança ou conformidade deve avaliar se a alteração introduz riscos adicionais e recomendar salvaguardas adicionais.”
Da secção “Tratamento do risco e exceções”, cláusula 7.5.1 da política.

Dados sensíveis, direitos de acesso e integrações externas são exatamente as alterações que exigem revisão de risco de conceção.

O que os diferentes auditores irão perguntar

Um auditor ISO/IEC 27001:2022 irá perguntar se a modelação de ameaças faz parte de um processo definido de avaliação de riscos, se os critérios são consistentes, se os proprietários do risco aprovaram os riscos residuais, se os planos de tratamento estão ligados à SoA e se a evidência é retida. Procurará repetibilidade, histórico de versões, visibilidade em revisão pela gestão e cobertura por auditoria interna.

Para o Anexo A, ligará a sua evidência a 5.8, 8.25, 8.26, 8.27 e 8.29. A etapa 21 de ZB, Controlos em Ação, destaca os princípios de arquitetura e engenharia de sistemas seguros ao perguntar que princípios orientam a arquitetura segura. Os auditores podem perguntar se a modelação de ameaças é realizada durante a conceção, usando métodos como STRIDE ou árvores de ataque, e se as decisões arquiteturais são revistas antes da implementação.

Um revisor NIS2 focar-se-á na governação e na proporcionalidade. Poderá perguntar se a gestão aprovou a abordagem de gestão de riscos de cibersegurança, se a aquisição, desenvolvimento e manutenção seguros estão cobertos, se as vulnerabilidades de fornecedores são consideradas, se os cenários de incidente estão ligados a fluxos de notificação e se os cenários de continuidade são analisados. O reporte faseado previsto no Article 23 da NIS2 para incidentes significativos, incluindo alerta precoce no prazo de 24 horas, notificação no prazo de 72 horas e relatório final no prazo de um mês, torna a clareza dos cenários especialmente valiosa.

Um examinador DORA focar-se-á na governação do risco associado às TIC, funções críticas, ativos de TIC, dependências externas, testes de resiliência e serviços TIC prestados por terceiros. Se o sistema suportar uma função crítica ou importante, esperará evidência mais robusta que ligue cenários de ameaça a inventários de ativos, mapas de dependências, planos de teste, contratos com terceiros e medidas de recuperação.

Um revisor de privacidade inspecionará os fluxos de dados e perguntará se o tratamento de dados pessoais é necessário, lícito, minimizado e protegido. Perguntará se estão envolvidas categorias especiais de dados, se é utilizada pseudonimização ou cifragem, se a retenção é justificada e se é necessária uma AIPD. A modelação de ameaças e a AIPD são atividades diferentes, mas devem partilhar diagramas, cenários e mitigações.

Um revisor orientado para NIST CSF ou COBIT 2019 procurará governação, propriedade de processos, desempenho, responsabilização e melhoria contínua. Poderá importar-se menos com a folha de trabalho STRIDE em si e mais com o facto de o processo ser fiável, medido, aprovado e melhorado.

Falhas comuns na evidência de modelação de ameaças

As falhas mais comuns não são técnicas. São falhas de evidência.

As equipas realizam modelação de ameaças demasiado tarde, depois de o sistema já estar construído. Nessa altura, o workshop torna-se uma sessão preparatória para um teste de intrusão, em vez de um controlo de conceção.

As constatações não são convertidas em linguagem de risco. “Adicionar autenticação” ou “problema de registo de eventos” pode ajudar os engenheiros, mas os auditores precisam de ativo, ameaça, vulnerabilidade, impacto, proprietário, tratamento e risco residual.

Privacidade e segurança são separadas. Uma equipa documenta risco de falsificação de identidade e de injeção, enquanto outra documenta retenção e fundamento de licitude. A responsabilização no GDPR funciona melhor quando fluxos de dados, casos de abuso e acionadores de AIPD estão ligados.

As premissas sobre fornecedores permanecem não documentadas. NIS2, DORA e NIST CSF elevam as expectativas relativas ao risco da cadeia de fornecimento de TIC. Se uma mitigação depender da cifragem, registo de eventos, apagamento, resiliência ou resposta a incidentes de um fornecedor, recolha a evidência.

Os testes não são mapeados de volta para as ameaças. Um relatório de teste de intrusão pode ser útil, mas pode não demonstrar que os riscos de conceção específicos foram mitigados. Cada constatação de ameaça relevante deve ter evidência de validação.

A aceitação do risco residual é informal. “Aceitamos isto para o MVP” não chega. A ISO/IEC 27001:2022 espera aceitação do risco residual pelos proprietários do risco adequados, como informação documentada.

O seu pacote de evidência de modelação de ameaças para 2026

Para cada sistema relevante ou alteração significativa, mantenha um pacote de evidência normalizado que possa apoiar ISO 27001, NIS2, DORA, CRA, GDPR e garantia perante clientes.

A Política de Gestão de Riscos - PME descreve bem o modelo operacional:

“Assegura que a gestão de riscos é uma componente ativa do planeamento, da execução de projetos, da seleção de fornecedores e da resposta a incidentes, em alinhamento com ISO 27001, ISO 31000 e os requisitos regulamentares aplicáveis.”
Da secção “Finalidade”, cláusula 1.2 da política.

Esse é o objetivo certo. A modelação de ameaças deve influenciar planeamento, engenharia, seleção de fornecedores, resposta a incidentes e preparação para auditoria.

Prepare a modelação de ameaças para auditoria antes do seu próximo lançamento

As organizações que melhor irão gerir a pressão de conformidade em 2026 não são as que têm mais diagramas. São as que conseguem demonstrar uma cadeia simples:

O risco de conceção foi identificado. O risco foi avaliado. Os controlos foram selecionados. As mitigações foram implementadas. Os testes validaram as mitigações. O risco residual foi aprovado. A evidência mapeia para os referenciais relevantes.

Comece com uma alteração de alto risco: uma integração de pagamentos, nova API, fluxo de trabalho com IA, funcionalidade de identidade, migração para a nuvem, lançamento de produto orientado para o cliente ou serviço conectado a fornecedor. Execute um sprint de risco de conceção de 90 minutos. Use ZB para converter constatações em cenários de risco, planos de tratamento e rastreabilidade SoA. Use ZC para mapear controlos ISO/IEC 27002:2022, como 5.8, 8.25, 8.26, 8.27 e 8.29, para controlos de apoio, risco de fornecedores, privacidade, testes e evidência de auditoria. Alinhe P24, P06, P17, P24S e o seu procedimento de gestão de alterações para que a modelação de ameaças passe a ser obrigatória, repetível e sujeita a revisão.

Se quiser apoio da Clarysec, comece por uma revisão de evidência de modelação de ameaças. Avaliaremos um projeto real, identificaremos lacunas face às expectativas de ISO/IEC 27001:2022, NIS2, DORA, CRA e GDPR, e entregar-lhe-emos um roteiro prático de remediação que os seus engenheiros, auditores e conselho de administração consigam compreender.