DORA: o que o seu RSSI não lhe contou.

A maioria das entidades financeiras não começou o DORA do zero. Tinham um ISMS, um plano de continuidade de negócio, uma política de subcontratação e um inventário de terceiros que era sobretudo contratos de aprovisionamento. O DORA não deita isso fora. Reenquadra-o, eleva a fasquia em dois pilares em particular, e desloca a conversa de "tem um controlo" para "consegue provar que o seu serviço continua a funcionar quando um prestador de TIC falha." Esta página é sobre essa lacuna: como os cinco pilares aterram realmente nas operações, o que é que um supervisor abre primeiro, e onde é que as equipas perdem tempo.

Os cinco pilares, e quem é auditado em cada um

O regulamento assenta em cinco pilares. Não têm o mesmo peso na prática. O Pilar 1 é fundamental mas familiar a quem opera um ISMS. Os Pilares 3 e 4 são onde se concentra a atenção da supervisão, porque produzem provas difíceis de falsificar e fáceis de testar. A tabela abaixo é a versão que usamos para informar um conselho de administração: o que cada pilar exige, e quem, dentro da entidade, acaba mais exposto quando o regulador pede provas.

O que fazer primeiro

O erro é começar pela atualização das políticas, porque esse é o trabalho confortável. Comece antes pelos dois artefactos que um supervisor pode pedir por escrito e que demoram mais tempo a construir corretamente: o registo de terceiros de TIC e o mapeamento das funções críticas ou importantes para os ativos e prestadores de TIC que as suportam. Tudo o resto depende desse mapeamento. Não consegue definir o âmbito dos testes de resiliência, não consegue classificar a gravidade dos incidentes, e não consegue raciocinar sobre o risco de concentração enquanto não souber quais as funções críticas e de que dependem.

Uma sequência viável para os primeiros 90 dias:

1. Defina as suas funções críticas ou importantes. Esta é uma decisão de negócio, não de segurança. Determina o âmbito de quase todas as outras obrigações.
2. Mapeie cada função crítica para os serviços de TIC, internos e subcontratados, dos quais depende. Este é o seu grafo de dependências.
3. Construa o registo de terceiros a partir desse grafo, e não a partir da folha de cálculo de aprovisionamento. O registo tem de descrever os acordos que suportam funções, incluindo os subcontratantes na cadeia.
4. Feche as lacunas contratuais que o DORA exige (direitos de auditoria, estratégias de saída, transparência da subcontratação, cooperação em incidentes) começando pelos acordos que suportam funções críticas.
5. Só então formalize o quadro de gestão do risco de TIC e o programa de testes, porque ambos têm agora um âmbito definido contra o qual trabalhar.

O registo de terceiros de TIC (Pilar 4) na prática

O registo não é uma lista de fornecedores. É um conjunto estruturado de registos de informação que a entidade mantém e que as autoridades competentes recolhem, num modelo definido, para ver a concentração de TIC em todo o setor financeiro. Isso muda a forma como o constrói. Um campo que é "suficientemente bom" para uso interno torna-se um problema de qualidade de dados quando é agregado ao nível nacional e da UE. Três coisas causam a maior parte das dificuldades.

Primeiro, a unidade é o acordo contratual, não o fornecedor. Um prestador pode estar por trás de vários acordos, e um acordo pode suportar várias funções. Está a descrever um grafo muitos-para-muitos, e achatá-lo numa linha por fornecedor não sobreviverá à revisão.

Segundo, tem de seguir a cadeia. O registo tem de captar os subcontratantes que efetivamente suportam uma função crítica ou importante, o que significa que a sua visibilidade sobre os prestadores tem de ir além da sua contraparte direta. Se o seu contrato não lhe dá o direito de saber quem é a quarta parte, isso é uma lacuna contratual a fechar, não um campo a deixar em branco.

Terceiro, o indicador de criticidade da função em cada acordo é o campo de que tudo o resto depende. Marque demasiado como crítico e afoga os seus próprios testes e a remediação contratual; marque de menos e subestima o risco de concentração e induz o supervisor em erro. Faça a avaliação de criticidade corretamente uma vez, ao nível da função, e deixe-a propagar-se.

Testes de penetração baseados em ameaças (Pilar 3): como é a sala na realidade

O TLPT é o pilar que surpreende as pessoas, porque é diferente de um teste de penetração de rotina. É orientado por informação, executado contra sistemas de produção ao vivo, com âmbito nas funções críticas ou importantes, e conduzido segundo a metodologia TIBER-EU com a autoridade nacional envolvida. As entidades significativas executam-no em ciclos de pelo menos três anos. Está mais próximo de um exercício de red team supervisionado do que de uma análise de vulnerabilidades, e o entregável que importa não é a lista de constatações; é a prova de que a deteção e a resposta funcionaram, ou o relato honesto das razões por que não funcionaram.

Três realidades que as equipas subestimam:

• O âmbito é determinado pelas funções críticas, e não pelo que é conveniente testar. Se uma função abrange um prestador subcontratado, esse prestador pode ter de estar no âmbito, o que significa que a cooperação do prestador tem de ser assegurada contratualmente com antecedência.
• A blue team geralmente não é avisada. O valor está em testar a deteção e a resposta reais, por isso um TLPT de que os defensores foram avisados perdeu a maior parte do seu propósito. Isso tem consequências organizacionais que se planeiam, não que se descobrem a meio do exercício.
• Os testadores e os prestadores de informação sobre ameaças têm de cumprir requisitos de competência e independência, e a autoridade revê o processo. Não pode simplesmente reetiquetar o teste de penetração anual do ano passado como TLPT.

Se a sua entidade está abaixo do limiar de significância, não executa TLPT, mas continua a dever um programa de testes baseado no risco: avaliações de vulnerabilidades, testes baseados em cenários, e testes de resiliência do percurso de recuperação. O curso Lead Operational Resilience Manager está construído precisamente em torno desta camada de testes e provas voltada para o regulador, e o curso DORA Lead Manager cobre como todo o programa é governado de ponta a ponta.

O DORA como lex specialis sobre a NIS 2 para os bancos

Os bancos, e a maioria das outras entidades financeiras, estão abrangidos tanto pela NIS 2 como pelo DORA. Os dois sobrepõem-se fortemente na gestão do risco de TIC, na comunicação de incidentes e na segurança da cadeia de abastecimento, o que levanta o receio óbvio de fazer tudo duas vezes. O DORA resolve isto: nas matérias de TIC que rege, o DORA é lex specialis. A regra específica afasta a geral. Onde o DORA estabelece a obrigação de gestão do risco de TIC e de comunicação de incidentes, uma entidade financeira segue o DORA, e as autoridades competentes não devem aplicar por cima o requisito equivalente da NIS 2 para o mesmo tema de TIC.

O que isto não significa: não desliga a NIS 2 por completo para uma entidade financeira, e não muda quem é a sua autoridade competente para as matérias não relacionadas com TIC. A decisão prática para um banco é mapear cada obrigação ao seu instrumento regulador: resiliência operacional de TIC, comunicação de incidentes e risco de terceiros de TIC correm ao abrigo do DORA; tudo o que está fora do DORA é âmbito que avalia separadamente. Documente esse mapeamento. É a resposta à pergunta "está a contar duas vezes ou a contar de menos" que tanto os examinadores como os auditores fazem.

Erros comuns e onde construir a competência

As falhas recorrentes não são exóticas. O registo é construído por fornecedor em vez de por acordo e quebra no momento em que a subcontratação importa. A criticidade das funções críticas é avaliada pela TI em vez de pelo negócio, pelo que o âmbito de tudo o que está a jusante fica errado. Os limiares de classificação de incidentes são escritos mas nunca testados contra um incidente real, pelo que o primeiro evento grave torna-se o primeiro ensaio do calendário de comunicação. E a continuidade de negócio é tratada como um projeto ISO 22301 separado em vez do músculo de recuperação que os testes do DORA se destinam a exercitar.

Este último ponto é importante: o DORA não substitui um sistema de gestão da continuidade de negócio, pressupõe-no. Os objetivos de recuperação e o percurso de recuperação testado que um BCMS lhe dá são o que os testes de resiliência validam. Construa o BCMS corretamente com o curso ISO 22301 Lead Implementer, e ele torna-se o substrato sobre o qual assentam as obrigações de resiliência operacional, em vez de um dossiê paralelo que ninguém abre.

Se está a partir do próprio regulamento, o curso DORA Foundation dá a toda a equipa uma leitura partilhada e rigorosa dos cinco pilares e do âmbito antes de alguém tocar no registo ou no programa de testes. A partir daí, o curso DORA Lead Manager é a camada de implementação e governação para as pessoas que vão ser donas do quadro, e o curso Lead Operational Resilience Manager é para a função que tem de se apresentar perante o supervisor e mostrar que a resiliência é real, e não apenas documentada.