Do plano diretor à preparação para auditoria: dominar os requisitos de segurança de aplicações para ISO 27001, DORA e NIS2

A ansiedade pré-auditoria era palpável. Para Maria, Diretora de Segurança da Informação de uma fintech de média dimensão, a próxima avaliação de conformidade com DORA parecia menos uma revisão e mais um acerto de contas. A sua equipa era competente, a infraestrutura estava reforçada, mas havia uma vulnerabilidade persistente que não a deixava dormir: o universo vasto e caótico das suas aplicações.

A preocupação mais recente era um novo portal de pagamentos orientado para clientes, lançado à pressa para cumprir objetivos trimestrais. A equipa de desenvolvimento, a trabalhar num modelo ágil agressivo, tinha cumprido todos os requisitos funcionais. Mas quando a equipa de Maria executou uma análise preliminar, os resultados confirmaram os seus receios.

O portal não tinha regras robustas de tempo limite de sessão, os campos de entrada eram suscetíveis a ataques básicos de injeção e as mensagens de erro expunham informação sensível do sistema. Não se tratava de explorações zero-day sofisticadas; eram falhas fundamentais de conceção. A causa raiz era dolorosamente clara. Os requisitos de segurança nunca tinham sido formalmente definidos, documentados nem integrados nos sprints de desenvolvimento. A equipa tinha um mandato vago para “tornar isto seguro”, mas, sem um plano diretor concreto, a segurança continuava a ser uma reflexão tardia, ambígua e frequentemente ignorada.

Este cenário não é único. Evidencia a lacuna crítica que muitos Diretores de Segurança da Informação e responsáveis de conformidade enfrentam: transformar a intenção de “fazemos segurança” em requisitos de segurança de aplicações explícitos e testáveis, alinhados com normas fundamentais como a ISO/IEC 27001:2022 e regulamentos relevantes como NIS2, DORA e RGPD da UE.

O elevado custo da ambiguidade: o que a conformidade realmente exige

O núcleo do problema de Maria reside numa falha organizacional comum: tratar a segurança como um atributo de qualidade, e não como um conjunto de requisitos inegociáveis. Um requisito de segurança eficaz é específico, mensurável e testável. “A aplicação deve ser segura” é um desejo. “A aplicação deve impor tempos limite de sessão de 15 minutos em caso de inatividade, validar todas as entradas fornecidas pelo utilizador contra um conjunto de caracteres predefinido e cifrar todos os dados em trânsito com TLS 1.3” é um requisito. Esta clareza é o que os auditores procuram e o que os programadores precisam para construir software seguro.

Sem isso, abre-se caminho a uma cascata de falhas:

• Implementação inconsistente: diferentes programadores interpretam “seguro” de formas diferentes, gerando um mosaico de controlos com lacunas imprevisíveis.
• Custos de remediação acrescidos: encontrar e corrigir uma falha de conceção em produção é exponencialmente mais caro do que tratá-la na fase de conceção.
• Não conformidades em auditoria: os auditores identificarão rapidamente a ausência de um processo estruturado para definir requisitos de segurança, originando constatações relevantes.
• Risco para o negócio: cada requisito não definido é um potencial vetor de ataque, expondo a organização a violações de dados, perdas financeiras e dano reputacional.

Nas normas modernas, a expectativa é consistente: a segurança deve ser definida como requisitos, desde cedo, e ligada ao risco e à legislação. A orientação da ISO/IEC 27002:2022 sobre o controlo 8.26, Requisitos de segurança de aplicações, espera que as organizações determinem, documentem e aprovem sistematicamente requisitos de segurança com base numa avaliação de riscos formal e em exigências regulamentares.

Este princípio único é a peça central de um vasto conjunto de mandatos de conformidade. O mapeamento transversal de conformidade da Clarysec no Zenith Controls: The Cross-Compliance Guide Zenith Controls mostra como este conceito surge em todo o lado:

• RGPD da UE Articles 25 e 32 esperam “Proteção de Dados desde a Conceção” e “Segurança do tratamento”.
• NIS2 Article 21(2)(d)-(e) enfatiza o desenvolvimento seguro e a segurança da cadeia de fornecimento.
• DORA Articles 6(4), 8, 10 e 11 exigem gestão do risco das TIC e segurança desde a conceção para entidades financeiras.
• NIST SP 800-53 Rev.5, nos controlos SA-4 e SA-15, exige requisitos de segurança de sistemas definidos e práticas de desenvolvimento seguro.
• COBIT 2019, nos processos BAI03 e DSS05, exige que os requisitos relacionados com segurança estejam alinhados com o negócio e a conformidade antes de uma solução ser construída.

O objetivo é definir, nas palavras do Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, “o que a segurança significa para as suas aplicações, antes de ser escrita uma única linha de código.”

Porque falham as abordagens tradicionais: listas de verificação, testes tardios e teatro de segurança

A maioria das organizações já realiza alguma forma de segurança de aplicações. O problema é que raramente está estruturada de modo a resistir a uma certificação ISO/IEC 27001:2022 ou ao escrutínio regulamentar.

Padrões comuns de falha incluem:

1. Listas de verificação genéricas: as equipas reutilizam uma “lista de verificação de programação segura” de uma página para todos os projetos. Não está ligada aos riscos específicos da aplicação, à sensibilidade dos dados ou ao contexto regulamentar. Quando um auditor pergunta como a lista se mapeia para o Article 25 do RGPD da UE, não há uma resposta clara.
2. Segurança como ponto de controlo tardio: os requisitos de segurança não são incorporados na conceção nem nas histórias de utilizador. Surgem no fim sob a forma de um pedido de teste de intrusão. O Zenith Blueprint alerta que “confiar numa lista de verificação de segurança no fim do projeto não funciona; esses requisitos têm de moldar a arquitetura, influenciar a escolha de bibliotecas e orientar a priorização de funcionalidades desde o primeiro dia.”
3. Sem rastreabilidade do requisito ao teste: pode existir um requisito para “cifrar dados em trânsito”, mas não há um caso de teste associado que verifique a imposição da versão TLS, a validade do certificado e a robustez dos conjuntos de cifras. O Zenith Blueprint insiste que as expectativas devem ser mensuráveis e testáveis, com testes de segurança mapeados diretamente para os requisitos correspondentes.
4. Tratamento ad hoc de código de terceiros: as aplicações modernas são frequentemente “cosidas a partir de código interno, bibliotecas de terceiros, Interfaces de Programação de Aplicações e serviços nativos da nuvem”, como assinala o Zenith Blueprint. Sem requisitos explícitos para fornecedores e componentes de código aberto, o risco da cadeia de fornecimento continua a ser um ponto cego significativo e sem controlo.

O resultado é teatro de segurança: os documentos existem e os testes são executados, mas quando um auditor ou regulador sério procura uma narrativa coerente de requisitos, todo o processo colapsa.

Construir a base: da política à prática

Uma abordagem disciplinada à segurança de aplicações começa com uma governação clara. A política não é apenas burocracia; é a fonte oficial de verdade que capacita as equipas e fornece aos auditores uma declaração clara de intenção. Na Clarysec, concebemos políticas simultaneamente autoritativas e práticas.

A nossa Política de Requisitos de Segurança de Aplicações Política de Requisitos de Segurança de Aplicações estabelece regras de base inegociáveis. Por exemplo, a cláusula 5.2 em ‘Requisitos de governação’ determina:

Todas as aplicações devem ser sujeitas a validação de requisitos de segurança durante o planeamento ou a aquisição, com aprovação documentada da equipa de Segurança de Aplicações.

Esta diretiva simples previne a mentalidade de “construir primeiro, proteger depois”. A política também atribui responsabilidades claras. A cláusula 4.3.1 em ‘Papéis e responsabilidades’ declara que se espera que os programadores:

Implementem aplicações em conformidade com os requisitos e normas de segurança definidos.

Isto desloca o ónus da segurança de uma equipa de segurança separada, muitas vezes percecionada como adversarial, para os próprios criadores do software. Além disso, a política liga os pontos entre diferentes domínios de segurança. A cláusula 10.2 referencia a sua integração com outros controlos essenciais:

P4 – Política de controlo de acesso. Define as normas de gestão de identidades e sessões que devem ser impostas por todas as aplicações, incluindo autenticação forte, princípio do menor privilégio e requisitos de revisão de acessos.

Para organizações de menor dimensão, uma política adaptada como a nossa Política de Requisitos de Segurança de Aplicações - PME Política de Requisitos de Segurança de Aplicações - PME garante que estes princípios são escaláveis. Reconhece que, embora os riscos sejam semelhantes, a implementação deve ser pragmática. Ambas as versões visam, em última análise, o mesmo resultado: assegurar que a segurança de aplicações está plenamente integrada no SGSI e preparada para auditoria.

Um roteiro prático: criar requisitos de segurança de aplicações preparados para auditoria

A política define o “quê” e o “porquê”, mas os programadores e gestores de projeto precisam do “como”. Um guia de implementação estruturado é indispensável para traduzir controlos de alto nível em passos acionáveis. O passo 21 do Zenith Blueprint, focado no controlo 8.26 da ISO/IEC 27002:2022, apresenta uma metodologia clara em seis passos.

Percorramos este processo usando o portal de pagamentos de Maria como exemplo.

Passo 1: começar pelo risco e pelo contexto regulamentar

Usando os resultados da avaliação de riscos alinhados com a ISO/IEC 27005:2024 (tratamento de riscos), começa-se por identificar o contexto:

• Aplicação: portal de pagamentos de autosserviço para clientes.
• Dados: informações pessoais identificáveis (PII), credenciais, tokens de pagamento.
• Jurisdições: UE, serviços financeiros, alojado na nuvem.
• Regulamentos: RGPD da UE, DORA, PCI DSS.

Com base na orientação para o controlo 8.26 no Zenith Controls e nas normas ISO relacionadas (27034-1, 27017, 27701), as categorias iniciais de requisitos devem incluir identificação e autenticação, autorização, classificação de dados, validação de entradas, registo e proteção de dados em trânsito e em repouso.

Passo 2: criar ou adotar um modelo de requisitos de segurança

O Zenith Blueprint recomenda criar um modelo normalizado para garantir que todos os projetos respondem às mesmas questões fundamentais de segurança. Este documento deve passar a fazer parte do seu conjunto de ferramentas de arranque de projetos.

As secções mínimas devem incluir:

• Nome da aplicação, proprietário e criticidade.
• Categorias de dados e níveis de sensibilidade.
• Obrigações regulamentares e contratuais aplicáveis (RGPD da UE, DORA, etc.).
• Entradas do panorama de ameaças (derivadas do controlo 5.7 Informações sobre ameaças).
• Requisitos de segurança específicos por categoria (autenticação, registo, etc.).
• Ligações a histórias de utilizador e critérios de aceitação.
• Ligações a casos de teste (funcionais, de segurança, de intrusão).
• Requisitos para fornecedores e componentes de terceiros.

Passo 3: incorporar requisitos nos artefactos ágeis

Os requisitos de segurança devem ser incorporados diretamente nas histórias de utilizador e nos critérios de aceitação. Para a épica de “registo de cliente” no projeto do portal de Maria, isto significa transformar uma história funcional simples numa história consciente da segurança.

• História de utilizador original: “Como novo utilizador, posso criar uma conta.”
• História de utilizador segura: “Como novo cliente, quero criar uma conta segura para que a minha informação de pagamento esteja protegida.”
• Critérios de aceitação (com segurança incorporada):
  • O sistema deve impor uma política de palavras-passe fortes em linha com a P4 – Política de controlo de acesso.
  • O sistema deve exigir verificação por correio eletrónico através de uma ligação de utilização única antes de a conta ser ativada.
  • O formulário de criação de conta deve estar protegido por CAPTCHA para prevenir ataques de bots.
  • Todas as tentativas de registo devem ser registadas com IP de origem e impressão digital do dispositivo.
  • Todos os dados submetidos através do formulário devem ser sanitizados para prevenir cross-site scripting (XSS).

Estas não são tarefas de segurança separadas; são parte integrante da definição de “concluído” da funcionalidade.

Passo 4: ligar requisitos a testes de segurança

Usando o controlo 8.29 Testes de segurança do Zenith Controls, garante-se que cada requisito tem um caso de teste associado. Isto fecha o ciclo e fornece evidência auditável da eficácia dos controlos.

• Requisito: cifragem em trânsito com TLS 1.3. → Teste: análise automatizada para verificar imposição de TLS, validade do certificado e conjuntos de cifras aprovados.
• Requisito: validação de entradas para prevenir injeção SQL. → Teste: análise SAST/DAST automatizada e fuzzing manual durante a garantia da qualidade (QA).
• Requisito: tempo limite de sessão de 15 minutos em caso de inatividade. → Teste: testes automatizados e manuais para confirmar a invalidação da sessão no lado do servidor após 15 minutos de inatividade.

Passo 5: alargar os requisitos à cadeia de fornecimento

Como o controlo ISO 8.26 está ligado à segurança de fornecedores (5.19, 5.20) e ao desenvolvimento externalizado (8.30) no Zenith Controls, o seu processo deve abranger código de terceiros. Para PME fortemente dependentes de bibliotecas externas, a cláusula da Política de Requisitos de Segurança de Aplicações - PME é crítica:

Qualquer ferramenta de terceiros, plugin ou biblioteca de código externa utilizada numa aplicação deve ser registada e revista anualmente quanto ao impacto de segurança e ao estado de aplicação de patches.

Este requisito simples e pragmático impõe uma mentalidade de software bill of materials (SBOM), que é uma expectativa-chave em regulamentos como a NIS2. Para fornecedores relevantes, os mesmos requisitos de segurança de aplicações devem ser incluídos nos contratos, com referência à ISO/IEC 27036-1 (segurança da cadeia de fornecimento das TIC).

Passo 6: instituir reavaliação periódica

À medida que as aplicações evoluem, os seus riscos também evoluem. A orientação do Zenith Blueprint sobre reavaliação periódica é crucial. Quando integra uma nova API ou migra para outro serviço na nuvem, o contexto de risco muda. Isto deve desencadear uma revisão dos requisitos de segurança existentes para assegurar que continuam adequados. Esta abordagem alinha-se com a ISO/IEC 27005:2024 (tratamento de riscos contínuo) e transforma a segurança de aplicações numa prática contínua, não num projeto pontual.

Decompor o ecossistema de controlos

Um controlo ISO nunca existe isoladamente. A segurança eficaz assenta numa rede interligada de medidas. O verdadeiro poder do controlo 8.26 revela-se quando se compreende a sua relação com outros controlos, uma perspetiva detalhada no Zenith Controls.

O controlo 8.26 é classificado como um controlo preventivo, mas atua como o eixo central de todo o processo de desenvolvimento seguro, ligando-se a:

• 8.25 - Ciclo de vida de desenvolvimento seguro: este é o enquadramento global. O controlo 8.26 fornece o quê específico (os requisitos) que deve ser integrado no como (o processo SDLC).
• 8.27 - Arquitetura segura de sistemas e princípios de engenharia: os requisitos orientam decisões arquiteturais, garantindo que a segurança é basilar.
• 8.28 - Programação segura: uma vez definidos os requisitos (por exemplo, “prevenir injeção SQL”), as normas de programação segura fornecem aos programadores as técnicas para os cumprir.
• 8.29 - Testes de segurança em desenvolvimento e aceitação: este controlo valida que os requisitos definidos em 8.26 foram corretamente implementados.
• 5.34 - Privacidade e proteção de PII: quando uma aplicação trata dados pessoais, os requisitos de 8.26 devem incorporar os princípios de privacidade desde a conceção.
• 5.19 & 5.20 - Segurança da informação nas relações com fornecedores: para aplicações adquiridas ou externalizadas, o controlo 8.26 determina que os seus requisitos de segurança devem estender-se à cadeia de fornecimento.

Ver estes controlos como um ecossistema, e não como uma lista de verificação, permite construir uma postura de segurança multicamada e defensável.

A perspetiva do auditor: preparar-se para o escrutínio

Os auditores pensam em termos de evidência. Para se preparar, deve compreender as diferentes perspetivas que um auditor pode trazer. A secção de metodologia de auditoria no Zenith Controls antecipa estas abordagens variadas.

Compreender estas perspetivas permite preparar um portefólio abrangente de evidência que demonstra um processo vivo e efetivo, incorporado na organização.

A bússola de conformidade transversal: um processo, muitos referenciais

Para uma empresa como a de Maria, satisfazer DORA, RGPD da UE e NIS2 é obrigatório. Mapear controlos manualmente é uma receita para esforço duplicado e lacunas de conformidade. Uma abordagem centralizada e transversal de conformidade proporciona enorme valor. Definir requisitos de segurança de aplicações é a implementação prática do princípio de segurança desde a conceção que sustenta todos estes regulamentos modernos.

Ao implementar um processo robusto para requisitos de segurança de aplicações com base na ISO/IEC 27002:2022, está simultaneamente a criar evidência para satisfazer uma parte significativa destes outros regulamentos. Não está apenas a “fazer ISO”; está a construir um programa de segurança universalmente conforme.

Do caos ao controlo: o seu caminho a seguir

A história de Maria teve um desfecho positivo. Ela usou o incidente com o portal de pagamentos como catalisador de mudança. Munida de um quadro de políticas claro da Clarysec e de um guia prático de implementação, reuniu as equipas de desenvolvimento, segurança e produto. Usaram a metodologia do Zenith Blueprint para definir retrospetivamente requisitos para o portal, priorizando a remediação com base no risco.

Mais importante ainda, estabeleceram uma nova forma de trabalhar. A “lista de verificação de segurança” foi substituída por sessões colaborativas de conceção. Quando os auditores DORA chegaram, Maria conseguiu não só mostrar-lhes uma aplicação segura, mas também demonstrar um processo maduro e repetível para garantir que todas as aplicações futuras seriam construídas sobre uma base de segurança.

Transformar a postura de segurança das suas aplicações começa com um único passo estruturado. O caminho a seguir é claro:

1. Estabelecer governação: implemente uma política formal para definir requisitos de segurança de aplicações. Os nossos modelos, como a Política de Requisitos de Segurança de Aplicações, fornecem um ponto de partida preparado para auditoria.
2. Adotar um referencial prático: use o Zenith Blueprint para integrar requisitos de segurança diretamente no seu ciclo de vida de desenvolvimento, tornando-os acionáveis, testáveis e rastreáveis.
3. Compreender o contexto completo: utilize o Zenith Controls para ver como este controlo crítico se liga ao ecossistema de segurança mais amplo e se mapeia para DORA, NIS2, RGPD da UE e outros referenciais.
4. Escalar para o seu portefólio: quando a abordagem funcionar para uma aplicação, escale-a por todo o portefólio integrando o Modelo de Requisitos de Segurança nas listas de verificação normalizadas de arranque de projetos, modelos ágeis e processos de aquisição.

Se pretende acelerar esta transformação, a Clarysec fornece políticas pré-construídas, roteiros de implementação e mapeamentos transversais de conformidade para passar de esforços fragmentados para um programa demonstravelmente maduro e preparado para auditoria. Deixe de tratar a segurança de aplicações como uma inspeção final. Comece a incorporá-la no plano diretor de tudo o que cria.