Evidência de TLPT DORA com controlos ISO 27001

São 07:40 de uma segunda-feira e o Diretor de Segurança da Informação de uma instituição de pagamentos de média dimensão está perante três versões da mesma pergunta desconfortável.

O órgão de administração quer saber se a organização consegue resistir a uma indisponibilidade do portal de pagamentos de clientes provocada por ransomware. O regulador quer evidência de que os testes de resiliência operacional digital não são um exercício de PowerPoint. A auditoria interna quer um trilho claro desde as obrigações DORA até ao risco das TIC, aos controlos ISO 27001, aos resultados dos testes, aos planos de remediação, à evidência de fornecedores e à aprovação formal da gestão.

O Diretor de Segurança da Informação tem um relatório de red team. O SOC tem capturas de ecrã de alertas. A infraestrutura tem um log de restauro de cópia de segurança. A área jurídica tem um rastreador de preparação para DORA. A área de compras tem atestados de prestadores de serviços em nuvem.

Nada disto está ligado.

É aqui que muitos programas de TLPT DORA e de testes de resiliência falham. Não porque os testes sejam fracos, mas porque a evidência está fragmentada. Quando um auditor pergunta: “Mostre-me como este teste comprova a resiliência de uma função crítica ou importante”, a resposta não pode ser uma pasta cheia de capturas de ecrã. Tem de ser uma cadeia de evidência defensável.

É nessa cadeia que um SGSI alinhado com a ISO/IEC 27001:2022 ISO/IEC 27001:2022 se torna poderoso. A ISO 27001 dá estrutura ao âmbito, à avaliação de riscos, à seleção de controlos, à Declaração de Aplicabilidade, ao controlo operacional, à auditoria interna, à revisão pela gestão e à melhoria contínua. O DORA introduz a pressão setorial específica. A metodologia da Clarysec e as suas ferramentas de conformidade cruzada ligam ambos num único modelo de evidência preparado para auditoria.

TLPT DORA é um teste de governação, não apenas uma simulação de ataque

Os testes de penetração baseados em ameaças, ou TLPT, são fáceis de interpretar mal. Tecnicamente, podem parecer um exercício sofisticado de red team: informações sobre ameaças, caminhos de ataque realistas, discrição, tentativas de exploração, cenários de movimentação lateral e validação da resposta da blue team.

Para o DORA, a questão mais profunda é a resiliência operacional digital. A entidade financeira consegue resistir, responder e recuperar de uma disrupção grave das TIC que afete processos de negócio? Consegue provar que as funções críticas ou importantes permanecem dentro das tolerâncias de impacto? A gestão consegue demonstrar que o risco das TIC é governado, financiado, testado, remediado e melhorado?

O Artigo 1 do DORA estabelece um quadro uniforme da UE para a segurança das redes e dos sistemas de informação que suportam os processos de negócio das entidades financeiras. Abrange a gestão do risco das TIC, a notificação de incidentes graves relacionados com as TIC, os testes de resiliência operacional digital, a gestão do risco associado a terceiros prestadores de serviços de TIC, requisitos contratuais obrigatórios para fornecedores de TIC, a supervisão de prestadores terceiros críticos de serviços de TIC e a cooperação entre autoridades de supervisão. O DORA é aplicável a partir de 17 de janeiro de 2025.

Para organizações também abrangidas pela NIS2, o DORA funciona como o ato jurídico setorial da União para requisitos de cibersegurança sobrepostos. Em termos práticos, as entidades financeiras devem priorizar o DORA para gestão do risco das TIC, notificação de incidentes, testes e risco de terceiros de TIC quando os regimes se sobrepõem, mantendo ainda assim a compreensão das expectativas da NIS2 para estruturas de grupo, fornecedores e serviços digitais não financeiros.

O DORA também coloca a responsabilização no topo. O Artigo 5 exige que o órgão de administração defina, aprove, supervisione e implemente os mecanismos de gestão do risco das TIC. Isto inclui a estratégia de resiliência operacional digital, a política de continuidade de negócio das TIC, os planos de resposta e recuperação, os planos de auditoria, os orçamentos, as políticas relativas a terceiros prestadores de serviços de TIC, os canais de reporte e conhecimento suficiente sobre risco das TIC através de formação regular.

Por isso, a pergunta de auditoria não é simplesmente: “Executou um TLPT?”

É:

• O TLPT estava ligado a funções críticas ou importantes?
• Foi autorizado, delimitado, seguro e sujeito a avaliação de risco?
• Foram incluídos fornecedores, dependências de nuvem e serviços de TIC externalizados quando relevante?
• O teste gerou evidência de deteção, resposta, recuperação e lições aprendidas?
• As constatações foram convertidas em tratamento de riscos, remediação acompanhada, reteste e reporte à gestão?
• A Declaração de Aplicabilidade explicou que controlos do Anexo A da ISO 27001 foram selecionados para gerir o risco?

É por isso que a Clarysec trata a evidência de TLPT DORA como um problema de evidência do SGSI, não apenas como um entregável de testes de penetração.

Construa a espinha dorsal de evidência ISO 27001 antes do início do teste

A ISO 27001 exige que a organização estabeleça, implemente, mantenha e melhore continuamente um SGSI que preserve a confidencialidade, a integridade e a disponibilidade através de um processo de gestão de riscos. As Cláusulas 4.1 a 4.4 exigem que a organização compreenda questões internas e externas, partes interessadas, obrigações legais e regulamentares, interfaces, dependências e, em seguida, documente o âmbito do SGSI.

Para uma entidade regulada pelo DORA, esta definição de âmbito deve capturar explicitamente funções críticas ou importantes, ativos de TIC, plataformas em nuvem, operações externalizadas, sistemas de pagamento, portais de clientes, serviços de identidade, plataformas de logging, ambientes de recuperação e terceiros prestadores de serviços de TIC. Se o âmbito do TLPT não mapear para o âmbito do SGSI, o trilho de auditoria já nasce frágil.

As Cláusulas 6.1.1, 6.1.2 e 6.1.3 da ISO 27001, em conjunto com as Cláusulas 8.2 e 8.3, exigem um processo de avaliação e tratamento de riscos. Os riscos devem ser identificados face à confidencialidade, integridade e disponibilidade. Devem ser designados proprietários do risco. A probabilidade e a consequência devem ser avaliadas. Os controlos devem ser selecionados e comparados com o Anexo A. O risco residual deve ser aceite pelos proprietários do risco.

Esta é a ponte entre o DORA e os testes preparados para auditoria.

O Zenith Blueprint: roteiro de 30 passos para auditores Zenith Blueprint, na fase de gestão de riscos, Passo 13, descreve claramente este papel de rastreabilidade:

A SoA é, na prática, um documento de ligação: liga a sua avaliação/tratamento de riscos aos controlos reais existentes. Ao preenchê-la, também verifica novamente se deixou algum controlo por considerar.

Para TLPT DORA, a Declaração de Aplicabilidade não deve ser um artefacto estático de certificação. Deve explicar por que razão controlos como segurança de fornecedores, gestão de incidentes, preparação das TIC para a continuidade de negócio, logging, monitorização, gestão técnica de vulnerabilidades, cópias de segurança, desenvolvimento seguro e testes de segurança são aplicáveis ao cenário de resiliência.

Um cenário de risco prático poderia ser:

“O comprometimento de credenciais privilegiadas do fornecedor de identidade permite que um atacante aceda a sistemas de administração do processamento de pagamentos, altere configurações de encaminhamento e interrompa uma função crítica de pagamentos, causando indisponibilidade de serviço, obrigações de reporte regulamentar, danos para clientes e dano reputacional.”

Esse único cenário pode orientar o âmbito do TLPT, os casos de uso de deteção, o envolvimento de fornecedores, o exercício de recuperação, o reporte ao órgão de administração e o conjunto de evidência.

O Zenith Blueprint também recomenda tornar explícita a rastreabilidade regulamentar:

Referencie regulamentos de forma cruzada: se determinados controlos forem implementados especificamente para cumprir o RGPD da UE, NIS2 ou DORA, pode assinalá-lo no Registo de Riscos (como parte da justificação do impacto do risco) ou nas notas da SoA.

Este conselho é simples, mas altera a conversa de auditoria. Em vez de dizer a um auditor que o DORA foi considerado, a organização consegue mostrar onde o DORA aparece no registo de riscos, na SoA, no programa de testes, no conjunto de políticas e na revisão pela gestão.

Mapeie os testes DORA para controlos ISO 27001 reconhecidos pelos auditores

O Artigo 6 do DORA espera um quadro documentado de gestão do risco das TIC integrado na gestão global de riscos. O Anexo A da ISO 27001 fornece o catálogo de controlos que torna isto operacional.

Para TLPT DORA e testes de resiliência, estes controlos do Anexo A da ISO/IEC 27001:2022 são particularmente importantes:

O Zenith Controls: guia de conformidade cruzada Zenith Controls ajuda as organizações a evitar tratar estes controlos como itens isolados de uma lista de verificação. Mapeia os controlos ISO/IEC 27002:2022 para atributos, domínios, capacidades operacionais, expectativas de auditoria e padrões de correspondência entre referenciais.

Por exemplo, o Zenith Controls classifica o controlo 5.30 da ISO/IEC 27002:2022, preparação das TIC para a continuidade de negócio, como “Corretivo”, alinhado com “Disponibilidade”, associado ao conceito de cibersegurança “Responder” e colocado no domínio “Resiliência”. Essa classificação é útil para explicar aos auditores por que razão um exercício de recuperação não é apenas uma operação de TI, mas um controlo de resiliência com um papel definido no ambiente de controlo.

O Zenith Controls também classifica o controlo 8.29, testes de segurança em desenvolvimento e aceitação, como um controlo preventivo que suporta confidencialidade, integridade e disponibilidade, com capacidades operacionais em segurança das aplicações, garantia da segurança da informação e segurança de sistemas e redes. Para constatações de TLPT que remontem a fragilidades de conceção aplicacional, comportamento inseguro de APIs, fluxos de autenticação deficientes ou validação inadequada, este é o caminho de controlo para a governação do desenvolvimento seguro.

O controlo 5.35, revisão independente da segurança da informação, também é importante. Suporta desafio independente, garantia de governação e melhoria corretiva. As equipas internas podem coordenar os testes, mas evidência preparada para auditoria exige revisão, escalonamento e supervisão para além das pessoas que construíram ou operaram os sistemas testados.

Proteja o sistema enquanto o testa

Uma premissa perigosa nos testes de resiliência é assumir que testar é automaticamente positivo. Na prática, testes intrusivos podem criar indisponibilidades, expor dados sensíveis, poluir logs, acionar defesas automatizadas, interromper sessões de clientes ou levar fornecedores a invocar procedimentos de emergência.

A Política de Testes de Segurança e Red Teaming da Clarysec Política de Testes de Segurança e Red Teaming fornece às organizações um padrão de governação para execução segura. A Cláusula 6.1 estabelece:

Tipos de testes: o programa de testes de segurança deve incluir, no mínimo: (a) varredura de vulnerabilidades, consistindo em varreduras automatizadas semanais ou mensais de redes e aplicações para identificar vulnerabilidades conhecidas; (b) testes de intrusão, consistindo em testes manuais aprofundados de sistemas ou aplicações específicos por testadores qualificados para identificar fraquezas complexas; e (c) exercícios de red team, consistindo em simulações baseadas em cenários de ataques reais, incluindo engenharia social e outras táticas, para testar as capacidades globais de deteção e resposta da organização.

Para TLPT, o elemento de red team é óbvio, mas o valor de auditoria vem da conceção do programa. Varredura de vulnerabilidades, testes de penetração, exercícios de red team, exercícios de resiliência e retestes devem formar um ciclo, não uma coleção de testes desconectados.

A Cláusula 6.2 da mesma política aborda a execução segura:

Âmbito e regras de atuação: para cada teste ou exercício, o STC deve definir o âmbito, incluindo sistemas e intervalos de IP abrangidos, métodos de teste permitidos, objetivos, janela temporal e duração. As regras de atuação devem ser documentadas. Por exemplo, sistemas operacionalmente sensíveis podem ser designados apenas para monitorização para evitar disrupção, e qualquer teste em produção deve incluir procedimentos de reversão e paragem. Devem ser estabelecidas medidas de segurança, como janelas temporais e canais de comunicação definidos, para prevenir indisponibilidades de serviço não intencionais.

Isto mapeia diretamente para o Zenith Blueprint, fase Controls in Action, Passo 21, que se concentra no controlo 8.34 do Anexo A da ISO 27001, proteção de sistemas de informação durante testes de auditoria. O Zenith Blueprint alerta que auditorias, testes de penetração, revisões forenses e avaliações operacionais podem envolver acesso elevado, ferramentas intrusivas ou alterações temporárias ao comportamento dos sistemas. Salienta autorização, âmbito, janelas temporais, aprovação pelo proprietário do sistema, reversão, monitorização e tratamento seguro de dados de teste.

O pacote de evidência preparado para auditoria deve incluir:

• Termos de referência e objetivos do TLPT
• Resumo de informações sobre ameaças e racional do cenário
• Funções críticas ou importantes no âmbito
• Sistemas, intervalos de IP, identidades, fornecedores e ambientes no âmbito
• Exclusões e sistemas apenas para monitorização
• Regras de atuação
• Avaliação de risco dos testes em produção
• Procedimentos de reversão e paragem
• Modelo de notificação ao SOC, incluindo o que é divulgado e o que é retido
• Aprovações jurídicas, de privacidade e de fornecedores
• Evidência de criação e revogação de contas de teste
• Localização de armazenamento seguro para artefactos de teste e logs

Um TLPT DORA que não consiga demonstrar autorização segura e controlo da atividade de teste pode revelar lacunas de resiliência, mas também cria lacunas de governação.

Transforme os resultados do TLPT em tratamento de riscos

A falha pós-teste mais comum é o problema do relatório de red team que fica na prateleira. Um relatório de elevada qualidade é entregue, circula, é discutido e depois perde gradualmente impulso. As constatações permanecem em aberto. Os controlos compensatórios não são documentados. Os riscos aceites ficam informais. O reteste nunca acontece.

A Política de Testes de Segurança e Red Teaming torna isto inaceitável. A Cláusula 6.6 estabelece:

Remediação de constatações: todas as vulnerabilidades ou fraquezas identificadas devem ser documentadas num relatório de constatações com classificações de severidade. Após receção do relatório, os proprietários dos sistemas são responsáveis por criar um plano de remediação com datas limite; por exemplo, as constatações críticas devem ser remediadas no prazo de 30 dias e as constatações de severidade elevada no prazo de 60 dias, de acordo com a Política de Gestão de Vulnerabilidades e Patches da organização. O STC deve acompanhar o progresso da remediação. Deve ser realizado reteste para confirmar que os problemas críticos foram resolvidos ou adequadamente mitigados.

A Cláusula 6.7 acrescenta a camada de governação:

Reporte: deve ser emitido um relatório formal no fim de cada teste. Para testes de intrusão, o relatório deve incluir um resumo executivo, metodologia e constatações detalhadas com evidência de suporte e recomendações. Para exercícios de red team, o relatório deve detalhar os cenários, que caminhos de ataque tiveram sucesso, o que foi detetado pela Blue Team e as lições aprendidas sobre lacunas de deteção e resposta. O Diretor de Segurança da Informação deve apresentar resultados resumidos e o estado da remediação à alta direção e, quando relevante, incluí-los no relatório anual de segurança ao Conselho de Administração.

Isto alinha-se com a orientação de tratamento de riscos da ISO/IEC 27005:2022: selecionar opções de tratamento, determinar controlos a partir do Anexo A da ISO 27001 e requisitos setoriais específicos, criar um plano de tratamento de riscos, designar responsáveis, definir prazos, acompanhar o estado, obter aprovação do proprietário do risco e documentar a aceitação do risco residual.

Cada constatação significativa de TLPT deve tornar-se uma de quatro coisas: uma ação de remediação, uma melhoria de controlo, uma aceitação formal do risco ou um requisito de reteste.

O objetivo não é produzir mais documentos. O objetivo é fazer com que cada documento explique a decisão seguinte.

Os testes de resiliência devem comprovar recuperação, não apenas deteção

Um TLPT bem-sucedido pode demonstrar que o SOC detetou tráfego de comando e controlo, bloqueou movimentação lateral e escalou corretamente. Isso é valioso, mas os testes de resiliência DORA vão mais longe. Perguntam se a organização consegue continuar ou recuperar serviços de negócio.

O Zenith Blueprint, fase Controls in Action, Passo 23, explica o controlo 5.30, preparação das TIC para a continuidade de negócio, numa linguagem que qualquer Diretor de Segurança da Informação deve usar com o órgão de administração:

Do ponto de vista da auditoria, este controlo é frequentemente testado com uma frase simples: Mostre-me. Mostre-me o último resultado de teste. Mostre-me a documentação de recuperação. Mostre-me quanto tempo demorou a comutar para contingência e a regressar. Mostre-me a evidência de que o que foi prometido pode ser entregue.

Esse padrão “Mostre-me” é a diferença entre maturidade documental e resiliência operacional.

A Política de Continuidade de Negócio e Recuperação de Desastre - SME da Clarysec Política de Continuidade de Negócio e Recuperação de Desastre - SME, da secção “Requisitos de implementação da política”, Cláusula 6.4.1, estabelece:

A organização deve testar as suas capacidades de BCP e DR pelo menos anualmente. Os testes devem incluir:

A secção de aplicação da mesma política, Cláusula 8.5.1, torna explícita a responsabilização pela evidência:

O Diretor-Geral deve assegurar que os seguintes elementos são mantidos e preparados para auditoria:

Para uma entidade financeira regulada pelo DORA, os testes anuais podem ser o mínimo, não a ambição. Funções críticas ou importantes de maior risco devem ser testadas com maior frequência, especialmente após alterações arquiteturais, migrações para a nuvem, incidentes relevantes, novos fornecedores de TIC, lançamentos aplicacionais materiais ou alterações na exposição a ameaças.

Um pacote forte de evidência de teste de resiliência deve incluir:

• Análise de impacto no negócio que mapeia a função crítica ou importante
• RTO e RPO aprovados pelos responsáveis de negócio
• Mapa de dependências do sistema, incluindo identidade, DNS, rede, nuvem, base de dados, monitorização, cópias de segurança e serviços terceiros
• Resultados de testes de cópia de segurança e restauro
• Carimbos temporais de failover e failback
• Evidência de controlos de segurança em operação durante a disrupção
• Modelos de comunicação para clientes, regulador e comunicações internas
• Logs de participação do comandante do incidente e da equipa de crise
• Lições aprendidas e ações de melhoria
• Evidência de reteste para lacunas de recuperação anteriores

É também aqui que o GDPR da UE entra na história. Os Artigos 2 e 3 do GDPR colocam a maioria dos tratamentos SaaS e fintech de dados pessoais da UE dentro do âmbito. O Artigo 4 define dados pessoais, tratamento, responsável pelo tratamento, subcontratante e violação de dados pessoais. O Artigo 5 exige integridade, confidencialidade e responsabilização, o que significa que a organização deve conseguir demonstrar conformidade. Se o TLPT ou os testes de recuperação utilizarem dados pessoais de produção, copiarem logs que contenham identificadores ou validarem a resposta a violações, as salvaguardas de privacidade devem ser documentadas.

A evidência de fornecedores é o ponto cego DORA que os auditores não vão ignorar

Os serviços financeiros modernos são construídos a partir de plataformas em nuvem, aplicações SaaS, prestadores de segurança gerida, processadores de pagamentos, plataformas de dados, fornecedores de identidade, ferramentas de observabilidade, equipas de desenvolvimento externalizado e fornecedores de cópias de segurança.

O Artigo 28 do DORA exige que as entidades financeiras giram o risco associado a terceiros prestadores de serviços de TIC como parte do quadro de gestão do risco das TIC e permaneçam plenamente responsáveis mesmo quando os serviços de TIC são externalizados. O Artigo 30 exige contratos escritos de serviços de TIC com descrições dos serviços, condições de subcontratação, localizações de tratamento, proteção de dados, acesso e recuperação, níveis de serviço, assistência em incidentes, cooperação com autoridades, direitos de cessação, termos mais robustos para funções críticas ou importantes, direitos de auditoria, medidas de segurança, participação em TLPT quando relevante e disposições de saída.

Isto significa que um cenário de TLPT não pode parar na firewall da organização se a função crítica depender de um fornecedor.

A Política de Segurança de Terceiros e Fornecedores - SME da Clarysec Política de Segurança de Terceiros e Fornecedores - SME, da secção “Requisitos de implementação da política”, Cláusula 6.3.1, estabelece:

Fornecedores críticos ou de alto risco devem ser revistos pelo menos anualmente. A revisão deve verificar:

A Política de Testes de Segurança e Red Teaming acrescenta um requisito específico para fornecedores em testes na Cláusula 6.9:

Coordenação de testes com terceiros: quando qualquer fornecedor crítico ou prestador de serviços estiver abrangido pelo âmbito da segurança global da organização, de acordo com a Política de segurança de terceiros e fornecedores, a organização deve, quando viável, obter garantia sobre as suas práticas de testes de segurança ou coordenar testes conjuntos. Por exemplo, quando é utilizado um Cloud Service Provider (CSP), a organização pode apoiar-se nos seus relatórios de testes de intrusão ou incluí-lo em cenários colaborativos de red team, sujeito a disposições contratuais.

Para evidência DORA preparada para auditoria, a garantia de fornecedores deve estar ligada ao mesmo cenário de risco do TLPT. Se o fornecedor de identidade for essencial à recuperação de pagamentos, o pacote de evidência deve incluir diligência prévia do fornecedor, requisitos contratuais de segurança, termos de suporte a incidentes, coordenação de testes, relatórios de garantia, evidência de níveis de serviço, estratégia de saída e restrições aos testes.

O Artigo 21 da NIS2 também é relevante para prestadores de SaaS, nuvem, serviços geridos, segurança gerida, centros de dados, CDN, serviços de confiança, DNS, TLD, marketplaces online, motores de pesquisa e redes sociais. Exige uma abordagem de todos os perigos que abrange análise de riscos, tratamento de incidentes, continuidade de negócio, segurança da cadeia de fornecimento, desenvolvimento seguro, avaliação da eficácia, formação, criptografia, controlo de acesso, gestão de ativos, MFA e comunicações seguras.

O resultado prático é simples: as entidades financeiras devem construir um único modelo de evidência que satisfaça primeiro o DORA e, depois, referencie de forma cruzada as expectativas NIS2 quando estejam envolvidos fornecedores, entidades de grupo ou serviços digitais não financeiros.

Um registo prático de evidência de TLPT da Clarysec

Assuma que o cenário é:

“Um agente de ameaça compromete uma conta de administrador numa plataforma de suporte SaaS, faz pivot para o ambiente de operações de pagamento, modifica a configuração e interrompe o processamento de transações.”

Crie um registo de evidência com uma linha por objeto de evidência. Não espere pelo fim do teste. Preencha-o durante o planeamento, a execução, a remediação e o encerramento.

Depois, use o Zenith Blueprint Passo 13 para acrescentar rastreabilidade ao registo de riscos e à Declaração de Aplicabilidade. Cada item de evidência deve ligar-se a um cenário de risco, proprietário do risco, controlo selecionado, plano de tratamento e decisão sobre risco residual.

Se uma constatação estiver relacionada com uma fragilidade de software, cite os controlos de desenvolvimento seguro e de testes. A Política de Desenvolvimento Seguro - SME da Clarysec Política de Desenvolvimento Seguro - SME, da secção “Requisitos de implementação da política”, Cláusula 6.5.2, exige:

Os testes devem ser documentados com:

Se uma constatação produzir material forense, preserve a cadeia de custódia. A Política de Recolha de Evidência e Análise Forense - SME da Clarysec Política de Recolha de Evidência e Análise Forense - SME, da secção “Requisitos de governação”, Cláusula 5.2.1, estabelece:

Cada item de evidência digital deve ser registado com:

Este é o ponto que muitas equipas falham. Evidência não são apenas relatórios finais. É o registo controlado de quem aprovou, quem executou, o que aconteceu, o que foi detetado, o que foi recuperado, o que foi alterado, o que permanece exposto e quem aceitou essa exposição.

Como os auditores inspecionam a mesma evidência de TLPT

A evidência de TLPT DORA será lida de forma diferente consoante o enquadramento do auditor. A Clarysec concebe pacotes de evidência para que cada perspetiva encontre o que precisa sem obrigar as equipas a duplicar trabalho.

O COBIT 2019 aparece na referência de conformidade cruzada do Zenith Blueprint para execução segura de auditorias e testes, incluindo DSS05.03 e MEA03.04. A relevância não é que o COBIT substitua o DORA ou a ISO 27001, mas que profissionais de garantia ao estilo ISACA procurarão execução controlada, monitorização, avaliação e evidência de conformidade.

A narrativa para o órgão de administração: o que a gestão deve aprovar

O reporte ao órgão de administração deve evitar teatro técnico. O órgão de administração não precisa de payloads de exploração. Precisa de evidência adequada à tomada de decisão:

• Que função crítica ou importante foi testada?
• Que cenário de ameaça foi simulado e porquê?
• A deteção funcionou?
• O escalonamento da resposta funcionou?
• A recuperação cumpriu RTO e RPO?
• Que fornecedores estiveram envolvidos ou condicionaram o teste?
• Que fraquezas materiais permanecem?
• Qual é o custo, proprietário e prazo da remediação?
• Que riscos residuais exigem aceitação formal?
• O que será retestado?

É aqui que a Cláusula 5 da ISO 27001 se torna importante. A alta direção deve assegurar que a política de segurança da informação e os objetivos são estabelecidos, alinhados com a orientação estratégica, integrados nos processos de negócio, dotados de recursos, comunicados e continuamente melhorados. Papéis e responsabilidades devem ser atribuídos. Os objetivos devem ser mensuráveis sempre que praticável e considerar requisitos aplicáveis e resultados do tratamento de riscos.

Se o TLPT identificar que o tempo de recuperação é de seis horas face a uma tolerância de negócio de quatro horas, isto não é apenas um item de backlog de infraestrutura. É uma decisão de gestão que envolve apetite ao risco, orçamento, compromissos com clientes, exposição regulamentar, contratos, arquitetura e capacidade operacional.

Falhas comuns de evidência nos testes de resiliência DORA

As revisões da Clarysec encontram frequentemente as mesmas lacunas de evidência em entidades financeiras e prestadores de serviços de TIC que se preparam para o DORA.

Primeiro, o âmbito do TLPT não mapeia para funções críticas ou importantes. O teste pode ser tecnicamente impressionante, mas não comprova a resiliência do processo de negócio que interessa aos reguladores.

Segundo, as dependências de fornecedores são reconhecidas, mas não evidenciadas. As equipas dizem que o prestador de serviços em nuvem, o SOC gerido ou a plataforma SaaS estão no âmbito, mas faltam contratos, direitos de auditoria, permissões de teste, termos de suporte a incidentes e planos de saída.

Terceiro, os testes criam evidência, mas não tratamento. As constatações permanecem num relatório de red team em vez de serem convertidas em atualizações do registo de riscos, alterações de controlos, proprietários, datas, reteste e decisões sobre risco residual.

Quarto, a recuperação é presumida em vez de demonstrada. Existem políticas de cópia de segurança, mas ninguém consegue mostrar carimbos temporais de failover, verificações de integridade do restauro, validação de acesso ou confirmação do responsável de negócio.

Quinto, a privacidade e a evidência forense não são controladas. Logs e capturas de ecrã contêm dados pessoais, artefactos de teste são armazenados em unidades partilhadas, contas temporárias permanecem ativas e a cadeia de custódia da evidência está incompleta.

Sexto, o reporte à gestão é demasiado técnico. A liderança sénior não consegue ver se a resiliência melhorou, se o risco está dentro do apetite ou que decisões de investimento são necessárias.

Cada uma destas lacunas pode ser resolvida tratando o TLPT DORA como um fluxo de trabalho estruturado de evidência ISO 27001.

A abordagem integrada da Clarysec para resiliência preparada para auditoria

A abordagem da Clarysec combina três camadas.

A primeira camada é o roteiro de implementação de 30 passos Zenith Blueprint. Para este tema, o Passo 13 constrói rastreabilidade entre tratamento de riscos e SoA, o Passo 21 protege os sistemas durante testes de auditoria, e o Passo 23 valida a preparação das TIC para a continuidade de negócio. Estes passos transformam o TLPT de um evento técnico num ciclo de governação documentado.

A segunda camada é a biblioteca de políticas da Clarysec. A Política de Testes de Segurança e Red Teaming define tipos de testes, âmbito, regras de atuação, remediação, reporte e coordenação com fornecedores. A Política de Continuidade de Negócio e Recuperação de Desastre - SME estabelece expectativas para testes anuais de BCP e DR e evidência de continuidade preparada para auditoria. A Política de Segurança de Terceiros e Fornecedores - SME suporta a garantia de fornecedores. A Política de Desenvolvimento Seguro - SME assegura que os testes de segurança são documentados. A Política de Recolha de Evidência e Análise Forense - SME suporta o registo de evidência e a disciplina da cadeia de custódia.

A terceira camada é o Zenith Controls, o guia de conformidade cruzada da Clarysec. Ajuda a mapear os controlos ISO/IEC 27002:2022 para atributos, domínios, capacidades operacionais e expectativas de múltiplos referenciais. Para TLPT DORA, o padrão mais importante não é um único controlo. É a relação entre testes, continuidade, gestão de incidentes, gestão de fornecedores, logging, monitorização, desenvolvimento seguro, revisão independente e governação.

Quando estas camadas trabalham em conjunto, o problema de segunda-feira de manhã do Diretor de Segurança da Informação muda. Em vez de três perguntas desconectadas do órgão de administração, do regulador e da auditoria interna, a organização passa a ter uma única narrativa de evidência:

“Identificámos a função crítica. Avaliámos o risco das TIC. Selecionámos e justificámos controlos. Autorizámos e executámos TLPT de forma segura. Detetámos, respondemos e recuperámos. Envolvemos fornecedores quando necessário. Documentámos a evidência. Remediámos constatações. Retestámos. A gestão reviu e aceitou o risco remanescente.”

Isto é resiliência preparada para auditoria.

Próximos passos

Se o seu programa de TLPT DORA ainda estiver organizado em torno de relatórios em vez de cadeias de evidência, comece com uma análise passo a passo da evidência da Clarysec.

Use o Zenith Blueprint Zenith Blueprint Passo 13 para ligar cenários de TLPT a riscos, controlos e à Declaração de Aplicabilidade. Use o Passo 21 para verificar autorização segura, regras de atuação, reversão, monitorização e limpeza. Use o Passo 23 para comprovar a preparação das TIC para a continuidade de negócio com evidência de recuperação.

Depois, alinhe os seus documentos operacionais com a Política de Testes de Segurança e Red Teaming da Clarysec Política de Testes de Segurança e Red Teaming, Política de Continuidade de Negócio e Recuperação de Desastre - SME Política de Continuidade de Negócio e Recuperação de Desastre - SME, Política de Segurança de Terceiros e Fornecedores - SME Política de Segurança de Terceiros e Fornecedores - SME, Política de Desenvolvimento Seguro - SME Política de Desenvolvimento Seguro - SME e Política de Recolha de Evidência e Análise Forense - SME Política de Recolha de Evidência e Análise Forense - SME.

Por fim, use o Zenith Controls Zenith Controls para mapear de forma cruzada a sua evidência de TLPT DORA para controlos ISO 27001, NIS2, GDPR da UE, COBIT 2019 e expectativas dos auditores.

Se quiser que o seu próximo teste de resiliência produza mais do que constatações, use a Clarysec para o transformar numa cadeia de evidência defensável. Descarregue os kits de ferramentas, agende uma avaliação de preparação da evidência ou solicite uma análise passo a passo de como a Clarysec mapeia TLPT DORA para controlos ISO 27001:2022 desde o planeamento até à aprovação pelo órgão de administração.