Gestão de vulnerabilidades NIS 2 ao abrigo do Artigo 21(2)(e)
A gestão de vulnerabilidades tem dois lados na NIS 2. Como trata as fraquezas nos seus próprios sistemas. E como trata as fraquezas que as pessoas lhe reportam. O Artigo 21(2)(e) é onde reside o dever, o §6.10 do CIR (UE) 2024/2690 detalha os pormenores, e o § 30(2)(5) BSIG transpõe-no para a lei alemã.
A versão curta
A gestão de vulnerabilidades é o ponto (e) na lista do Artigo 21(2). O CIR intitula a secção correspondente 'Tratamento e divulgação de vulnerabilidades'. Esse título é o que entrega o jogo. A NIS 2 preocupa-se com duas coisas ao mesmo tempo: as fraquezas que estão nos sistemas que opera, e as fraquezas que pessoas de fora encontram nos seus produtos e querem comunicar-lhe.
O §6.10 do CIR estabelece cinco ações. Recolher informação sobre vulnerabilidades junto de CSIRTs, autoridades, fabricantes e prestadores de serviços. Correr análises de vulnerabilidades com uma cadência documentada. Remediar as críticas sem demora. Ligar o tratamento de vulnerabilidades aos seus processos de gestão de alterações, de correções, de risco e de incidentes. E criar um procedimento de divulgação coordenada de vulnerabilidades (CVD) alinhado com a política nacional de CVD.
A Alemanha passa a mesma regra para a lei nacional através do § 30(2)(5) BSIG. O quadro nacional de CVD corre pelo programa de divulgação coordenada CERT-Bund no BSI. A própria NIS 2 cria também uma base de dados europeia de vulnerabilidades ao abrigo do Artigo 12, operada pela ENISA, onde as entidades podem divulgar voluntariamente.
Artigo 21(2)(e) da Diretiva NIS 2 (2022/2555)
Segurança na aquisição, desenvolvimento e manutenção de redes e sistemas de informação, incluindo o tratamento e a divulgação de vulnerabilidades.
Ponto (e) na lista das dez medidas. Note o enquadramento: o tratamento e a divulgação de vulnerabilidades estão dentro de um dever mais amplo de aquisição, desenvolvimento e manutenção. O CIR divide isto em secções separadas (§6.9 aquisição, §6.10 vulnerabilidades). A metade da divulgação é a que é subvalorizada.
CIR (UE) 2024/2690, Anexo §6.10
As entidades relevantes devem obter informação sobre vulnerabilidades técnicas nas suas redes e sistemas de informação, avaliar a sua exposição a tais vulnerabilidades e tomar as medidas adequadas para as gerir.
Lei da UE diretamente vinculativa para os setores nomeados no Anexo do CIR (DNS, TLDs, cloud, centros de dados, MSPs, serviços de confiança e outros). O §6.10.2 lista cinco ações concretas. O §6.10.3 diz que, quando dispensa a mitigação, regista porquê. O §6.10.4 diz que revê periodicamente os canais que usa para monitorizar a informação de vulnerabilidades.
§30(2)(5) BSIG (Alemanha)
Medidas de segurança para a aquisição, desenvolvimento e manutenção de sistemas, componentes e processos de tecnologias de informação, incluindo a gestão e a divulgação de vulnerabilidades.
A Alemanha copia o texto da UE. O quadro nacional de CVD corre pelo programa de divulgação coordenada CERT-Bund no BSI, que é o que 'alinhado com as políticas nacionais de CVD aplicáveis' no §6.10.2(e) aponta na Alemanha.
Faça entrar a informação
Acompanhe a informação de vulnerabilidades de CSIRTs, autoridades, fabricantes e prestadores de serviços. Corra análises de vulnerabilidades com uma cadência adequada ao seu ambiente. As ferramentas de análise (Tenable, Qualys, Nessus, OpenVAS) são o lado da engenharia. Os feeds (boletim CERT-Bund, avisos de fabricantes, NVD) são o lado da consciência. Precisa de ambos.
Corrija as críticas, documente as restantes
As vulnerabilidades críticas são remediadas sem demora. O tratamento de vulnerabilidades tem de ligar à sua gestão de alterações, gestão de correções, gestão de risco e gestão de incidentes. Quando decide não mitigar, o §6.10.3 diz que cria um plano de mitigação documentado ou regista por que razão nenhuma ação é necessária. Sem acumulação silenciosa.
Corra um processo de divulgação coordenada
Estabeleça um procedimento para receber comunicações de vulnerabilidades de pessoas de fora e coordenar a sua divulgação, alinhado com a política nacional de CVD aplicável. Mecânica mínima: um canal de contacto publicado (caixa security@ ou um ficheiro security.txt), um SLA de confirmação, um prazo de remediação, e uma divulgação pública coordenada. O CERT-Bund media se for preciso.
Periódica, não reativa
O §6.10.2(b) diz que as análises correm 'periodicamente conforme adequado'. O §6.10.4 diz que revê periodicamente os canais que usa para monitorizar a informação de vulnerabilidades. Ambas as expressões significam: cadência escrita. Documente com que frequência analisa, documente com que frequência revê a lista de feeds, e cumpra-a. Uma análise uma vez por ano porque alguém se lembrou não é periódica.
A divulgação coordenada é um dever, não opcional
O §6.10.2(e) diz que o procedimento tem de existir. Não 'se receber comunicações'. O procedimento existe para que, quando um investigador encontrar algo, tenha um canal e você tenha um processo. Mínimo viável: uma caixa security@seudominio.com que alguém lê, uma janela de confirmação (comummente 7 dias), e uma janela de divulgação (comummente 90 dias). Documente-o, publique-o, aponte um ficheiro security.txt para ele.
BSI / programa CVD do CERT-Bund
O BSI opera o CERT-Bund, o CSIRT federal, e mantém um programa de divulgação coordenada de vulnerabilidades. Os investigadores podem comunicar através do CERT-Bund e o BSI coordena com os fabricantes afetados. O § 30(2)(5) BSIG aponta para isto. Se está a montar um processo de CVD pela primeira vez, alinhar os seus prazos e canais de contacto com o modelo CERT-Bund é a opção segura.
Base de dados europeia de vulnerabilidades (Artigo 12 da NIS 2)
O Artigo 12 da NIS 2 cria uma base de dados europeia de vulnerabilidades operada pela ENISA. As entidades podem divulgar-lhe vulnerabilidades voluntariamente. Não é um canal de comunicação obrigatório ao abrigo do Artigo 23. É um recurso de referência à escala da UE que agrega informação de vulnerabilidades entre Estados-Membros.
CSIRTs nacionais como coordenadores de CVD
Cada Estado-Membro tem o seu CSIRT nacional a atuar como coordenador de CVD (NCSC-NL nos Países Baixos, CERT.at na Áustria, CCB na Bélgica). O dever é o mesmo em toda a UE. O que difere: com que CSIRT fala e a mecânica exata do seu processo de coordenação.
Aplicamos correções na Patch Tuesday, isso chega.
Não chega. O §6.10.2(c) diz que as vulnerabilidades críticas são remediadas sem demora. A Patch Tuesday é uma cadência de lançamento do fabricante. Um zero-day divulgado numa quinta-feira com exploração ativa não espera até à terça-feira seguinte. Precisa de uma cadência de correções para as rotineiras e de um processo extraordinário para as questões críticas.
Não temos processo de CVD porque nunca ninguém nos reporta vulnerabilidades.
O §6.10.2(e) não diz 'crie um processo quando começarem a chegar comunicações'. Diz que o procedimento tem de existir. O objetivo é garantir que, quando um investigador encontrar algo, tem um canal claro e a sua equipa sabe o que fazer. Uma caixa security@ e uma política de uma página chegam para cumprir o dever. Não ter uma é uma constatação de auditoria.
A análise de vulnerabilidades é tarefa da equipa de segurança.
É, até ler o §6.10.2(d): o tratamento de vulnerabilidades tem de ser consistente com a gestão de alterações, a gestão de correções, a gestão de risco e a gestão de incidentes. E o §6.10.4: rever os canais a nível organizacional. Isso faz da gestão de vulnerabilidades um processo entre equipas que toca as operações de TI, o desenvolvimento, o risco e o órgão de direção, não uma atividade de segurança isolada.
O lado da engenharia está normalmente em forma razoável. A maioria das equipas de TI do Mittelstand já corre um scanner (Tenable, Qualys, Nessus, OpenVAS) e tem algum tipo de cadência de correções, mesmo que seja só 'Patch Tuesday para clientes, trimestral para servidores'. Os deveres do §6.10.2(a)+(b)+(c) do CIR são sobretudo escrever o que já acontece e apertar o prazo de correção das críticas.
O lado da CVD é a metade subdocumentada. Mínimo realista: uma caixa security@seudominio.com encaminhada para duas pessoas, uma política de divulgação de uma página (confirmar em 7 dias, divulgar em 90 dias, dar crédito aos investigadores que o queiram), e um ficheiro security.txt em /.well-known/security.txt a apontar para a caixa. Meio dia de trabalho. A peça que as auditorias de facto assinalam.
O módulo PRO capta o seu inventário de vulnerabilidades, o calendário de análises, as tarefas de remediação e as decisões de aceitação num só lugar. Cada constatação de análise é encaminhada para uma tarefa com um responsável, um prazo e uma assinatura. O 'documentar por que razão nenhuma ação é necessária' do §6.10.3 é a mesma via de assinatura: justificação escrita, aprovador nomeado, registo de auditoria. Sem folha de cálculo separada.
Entregamos também um modelo de política de CVD (configuração da caixa security@, conteúdo do security.txt, SLAs de confirmação e divulgação alinhados com o CERT-Bund). Insere o seu domínio e os seus contactos e tem o dever do §6.10.2(e) coberto. As comunicações recebidas são encaminhadas para o mesmo fluxo de tarefas que as constatações de análise, pelo que o prazo de resposta é acompanhado da mesma forma.
- Diretiva (UE) 2022/2555 (NIS 2), Artigo 12 e Artigo 21(2)(e). eur-lex.europa.eu/eli/dir/2022/2555/oj
- Regulamento de Execução (UE) 2024/2690 da Comissão (CIR), Anexo §6.10. eur-lex.europa.eu/eli/reg_impl/2024/2690/oj
- Lei do BSI (BSIG), §30(2)(5) com a redação dada pela Lei de Implementação da NIS2 e de Reforço da Cibersegurança
- Programa de divulgação coordenada de vulnerabilidades BSI / CERT-Bund. bsi.bund.de
- Base de dados europeia de vulnerabilidades da ENISA (Artigo 12 da NIS 2)