Todos os artigos

Blog

Regulamento DORA, NIS2, PCI DSS: o registo não prova a eficácia

Regulamento DORA, NIS2, PCI DSS, ISO 27001: o que os textos exigem na formação de programadores, o que o auditor verifica e a prova que falta.

  • Por Azziz ERRIME
  • 12 min de leitura
Sala de audiências parlamentar vazia, sem bandeira nem emblema, com um dossiê fechado diante da cadeira da testemunha

TL;DR

  • Formação exigida pelo regulamento DORA, pela NIS2 ou pelo PCI DSS: os textos obrigam a formar os programadores e a documentá-lo, raramente a provar que as suas práticas mudaram.
  • O PCI DSS exige formação a cada 12 meses, e o avaliador verifica-a através de registos e de entrevistas ao pessoal.
  • Eu prepararia a auditoria em duas colunas: o que foi feito e o que mudou nas revisões de código.

A 3 de outubro de 2017, o antigo CEO da Equifax explica ao Congresso dos Estados Unidos que o alerta de segurança tinha seguido para as equipas certas e que o protocolo fora cumprido. A fuga de dados atingiu cerca de 147 milhões de pessoas. As obrigações de formação do DORA, da NIS2 e do PCI DSS repetem esta cena à sua escala: pedem que se mostre que o dispositivo existe, muito menos que funciona.

Nesse 3 de outubro, em Washington, Richard Smith está perante a comissão de Energia e Comércio da Câmara dos Representantes. Avisada em março, a Equifax só descobre a intrusão em julho. Diante dos congressistas, Smith descreve a cadeia prevista: no dia seguinte ao alerta do CERT, a equipa de segurança avisa um grupo alargado da equipa técnica. Cabe a essas pessoas encontrar a vulnerabilidade e aplicar a correção e, alguns dias mais tarde, lançar um scanner de verificação.

Segundo a transcrição da audição, a cadeia partiu-se num elo. Smith di-lo assim: «The human error was the individual who is responsible for communicating in the organization to apply the patch did not.» Depois resume em dois tempos: «Both human deployment of the patch and the scanning deployment did not work» e «The protocol was followed».

A FTC relata em 2019 que a regra interna mandava corrigir no prazo de 48 horas. O acordo celebrado prevê pelo menos 575 milhões de dólares. O protocolo tinha sido cumprido e previa a sua própria verificação. Também ela não detetou nada.

Cumprir um protocolo não prova que um controlo funciona

A cena mostra a distância entre duas provas que facilmente se confundem. A primeira diz que uma ação aconteceu: um alerta enviado, um scanner agendado, um procedimento assinado. A segunda diz que essa ação mudou alguma coisa: a correção está aplicada, o servidor já não responde ao ataque. A primeira arruma-se sem esforço num dossiê de auditoria, a segunda muito menos.

O atacante não lê os seus procedimentos. Procura o servidor que não recebeu a correção, o formulário que ninguém filtrou, o pull request revisto à pressa. Na prática, testa a aplicação em produção, e o que lá encontra mede a eficácia real dos seus controlos, formação incluída.

A formação dos programadores vive exatamente nesta distância. Um registo diz que um programador fez em março um módulo sobre injeção de SQL. Não diz se, em setembro, detetou a injeção escondida no código de um colega. Os textos que enquadram a formação no regulamento DORA, na NIS2 ou no PCI DSS ficam-se pela primeira prova?

No regulamento DORA, na NIS2 ou no PCI DSS, a formação verifica-se sobretudo no registo

O quadro assenta nos próprios textos, lidos no Jornal Oficial da União Europeia, e na norma PCI DSS 4.0.1. Resume o que exigem às equipas que escrevem código.

Texto O que exige O que se mostra na auditoria Exige eficácia?
DORA, art. 13, § 6 Programas de sensibilização e formações integrados como «módulos obrigatórios», para todos os trabalhadores e para a direção, e para os prestadores de serviços de TIC, se for o caso O programa e a sua execução Não
DORA, art. 5, § 4 Formação regular do órgão de administração, proporcional ao risco associado às TIC O acompanhamento das formações Não
RTS DORA 2024/1774, art. 16 Análises do código-fonte com testes estáticos e dinâmicos; código de terceiros e open source analisado, na medida do possível, antes da produção As análises, o plano de ação e o seu acompanhamento Indiretamente, pelos resultados
PCI DSS 4.0.1, 6.2.2 Formação dos programadores de software à medida pelo menos uma vez a cada 12 meses Registos de formação e entrevistas (6.2.2.b) Não
PCI DSS 4.0.1, 6.2.3 e 6.2.3.1 Revisão de código antes da produção; em revisão manual, um revisor que não seja o autor Registos das revisões (6.2.3.b) Indiretamente
NIS2, art. 20, § 2 Os Estados impõem a formação dos órgãos de gestão; formação do pessoal incentivada Conforme a lei nacional Não
NIS2, art. 21, § 2, e a g Segurança no desenvolvimento; avaliação da eficácia das medidas; formação em cibersegurança Conforme a lei nacional Sim, para o conjunto das medidas
ISO/IEC 27001:2022, 7.2 Competência do pessoal e avaliação da eficácia das ações realizadas Informação documentada Sim
AI Act, art. 4, alterado em 2026 Medidas para apoiar a literacia no domínio da IA, sem nível garantido As medidas tomadas Não

O DORA, regulamento europeu sobre a resiliência operacional digital do setor financeiro, não diz como formar nem com que periodicidade. O seu artigo 13 impõe programas e formações «aplicáveis a todos os trabalhadores e aos membros da direção de topo», que tenham «um nível de complexidade proporcional às suas funções». A formação exigida pelo regulamento DORA é uma obrigação de organizar módulos, sem resultado a medir.

O PCI DSS, a norma dos cartões de pagamento, desce mais ao pormenor. O requisito 6.2.2 do PCI DSS fixa a periodicidade: pelo menos uma vez a cada 12 meses. Fixa também o conteúdo, ou seja, a segurança de software própria da função e das linguagens, a conceção e as técnicas de código seguro. O procedimento de teste diz o que o avaliador verifica: «Examine training records and interview personnel». Registos e entrevistas.

Estes dois textos descrevem, portanto, uma formação realizada. O que se passa entre o registo e o código?

Carimbo sem desenho sobre uma pilha de folhas de presença de uma formação sobre o regulamento DORA, ao lado de um ecrã apagado

O carimbo certifica a presença. Já o ecrã ainda não mostrou nada.

Nenhum texto pede para cruzar o registo com as revisões de código

Até o objetivo que o PCI DSS atribui ao seu requisito de formação fica do lado do saber. Na abordagem personalizada, a norma visa programadores que «remain knowledgeable about secure development practices». Um programador pode manter-se informado e deixar passar uma vulnerabilidade numa revisão, porque nesse dia estava a rever a lógica de negócio.

O artigo 16 do regulamento delegado DORA 2024/1774 olha, por seu lado, para o código. Impõe «o desempenho das análises do código-fonte que abranjam testes estáticos e dinâmicos». As entidades têm depois de identificar as vulnerabilidades, adotar um plano de ação e acompanhar a sua execução. Estas análises produzem exatamente os dados que faltam ao registo de formação, mas nada no texto pede que sejam postas lado a lado.

Poder-se-ia concluir que o auditor se contenta com o registo e que seria inútil fazer mais. Dois textos do quadro dizem, no entanto, o contrário.

Dois textos já pedem que se avalie a eficácia

A norma ISO/IEC 27001, na versão de 2022, trata a competência na cláusula 7.2. Segundo as reproduções fiáveis deste texto pago, pede que se tomem as ações necessárias para adquirir a competência e que depois se avalie a sua eficácia. Pede também que se conserve informação documentada como prova. Uma formação concluída é uma ação, e a sua eficácia é outra questão, que a norma coloca de forma explícita.

A diretiva NIS2 fá-lo também, à escala de todas as medidas de segurança. O artigo 21 enumera, na alínea e), a segurança na aquisição, no desenvolvimento e na manutenção dos sistemas. Na alínea g) figuram as «práticas básicas de ciber-higiene e formação em cibersegurança». Entre as duas, a alínea f) exige «políticas e procedimentos para avaliar a eficácia das medidas de gestão dos riscos de cibersegurança». Eu leio a alínea f) como aplicável também à alínea g), a formação. Nenhum dos dois textos se aplica ainda a todos. A ISO 27001 vale para quem procura a certificação, e a NIS2 aguarda a lei francesa.

O guia NIST SP 800-50, na revisão 1 publicada a 12 de setembro de 2024, não obriga ninguém. Propõe, ainda assim, «suggested metrics and evaluation methods» para fazer evoluir um programa de formação.

Em França, a conformidade com a NIS2 continua suspensa do texto nacional. O prazo de transposição expirou a 17 de outubro de 2024, segundo a InCyber. A proposta de lei de transposição da NIS2 começa a ser apreciada na Assembleia Nacional a partir de 7 de outubro de 2026, segundo a Kohen Avocats.

A prova de eficácia da formação exigida pelo regulamento DORA já está nas suas revisões de código

Concluo que a matéria desta prova já existe nas empresas sujeitas ao DORA ou ao PCI DSS. Está adormecida nas análises de código que esses textos impõem. O PCI DSS exige registos das revisões antes de cada passagem à produção, e o RTS DORA análises do código-fonte com um plano de ação. Falta pô-los lado a lado com o registo de formação.

No dossiê de auditoria, ao lado do registo, eu poria:

  • o registo de formação DORA ou PCI DSS tal como o avaliador o espera, com os módulos concluídos por cada programador;
  • as constatações das revisões de código e dos testes do código-fonte no mesmo período, classificadas por tipo de vulnerabilidade;
  • o cruzamento dos dois: as vulnerabilidades que a formação cobria e as que continuam a passar na revisão;
  • o plano de ação que daí resulta e o seu acompanhamento, como pede o artigo 16 do RTS DORA;
  • a mesma medição repetida após cada ciclo de formação, para ver se a curva se mexe.

Este cruzamento alimenta a avaliação pedida pela cláusula 7.2 da ISO 27001 e pela alínea f) do artigo 21 da NIS2. Sobretudo, dá à comissão executiva outra coisa que não uma taxa de conclusão. É também o que estou a medir neste momento: o que os programadores detetam, ou deixam passar, quando reveem código escrito por uma IA. Falei disso num artigo anterior sobre code review.

Balança de dois pratos, com certificados enrolados de um lado e uma peça mecânica maquinada do outro

De um lado, certificados. Do outro, uma peça que mudou.

Depois de um incidente, lê-se a segunda coluna

Diante dos congressistas, Richard Smith descreve um protocolo que existia e um alerta que seguiu no dia seguinte. O protocolo previa até um controlo do efeito, o scanner, e também esse controlo falhou.

Uma formação DORA, NIS2 ou PCI DSS bem gerida parece-se muitas vezes com este protocolo. O registo está completo, os módulos estão em dia, o avaliador sai satisfeito. Ainda assim, eu prepararia a auditoria em duas colunas: o que foi feito e o que mudou nas revisões. Depois de um incidente, vão pedir-lhe a segunda.

Fica-me uma dúvida. Não sei se os reguladores chegarão a exigir esta prova de forma explícita, nem se a lei francesa sobre a NIS2 o vai especificar. Para mim, os dois textos que já a pedem bastam para começar.

Perguntas frequentes sobre a formação no regulamento DORA e nos textos vizinhos

Que obrigações de formação decorrem do regulamento DORA?

As obrigações do regulamento DORA em matéria de formação cabem em dois artigos. A formação DORA assenta, em primeiro lugar, no artigo 13, n.º 6, do regulamento: programas de sensibilização para a segurança das TIC e formação em resiliência operacional digital. Integram a formação do pessoal como «módulos obrigatórios», para todos os trabalhadores e para a direção. O artigo 5 acrescenta uma formação regular para o órgão de administração. O texto não fixa frequência nem duração.

O que diz o requisito PCI DSS 6.2.2?

O PCI DSS 4.0.1 impõe que os programadores de software à medida recebam formação «at least once every 12 months». A formação incide sobre a segurança de software própria da sua função e das suas linguagens, incluindo a conceção e as técnicas de código seguro. Para o verificar, o avaliador examina os registos de formação e entrevista o pessoal, segundo o procedimento 6.2.2.b.

Quando entra em vigor a NIS2 em França?

A diretiva NIS2 devia ser transposta antes de 17 de outubro de 2024. Em França, a proposta de lei de transposição começa a ser apreciada na Assembleia Nacional a partir de 7 de outubro de 2026, segundo a Kohen Avocats. As obrigações nacionais, formação incluída, vão depender do texto aprovado. A diretiva obriga cada Estado a impor esta formação aos órgãos de gestão. Em França, a obrigação aguarda, portanto, a lei.

O que diz o artigo 4 do AI Act?

Na versão de 2024, o artigo 4 do AI Act visava os fornecedores e os responsáveis pela implantação de sistemas de IA. Deviam garantir ao seu pessoal, «na medida do possível, […] um nível suficiente de literacia no domínio da IA». Desde o regulamento Omnibus, que entrou em vigor a 27 de julho de 2026, pede-lhes que apoiem essa literacia, sem garantir um nível, segundo a Law & Technology.

Fontes