Registo e monitorização na NIS 2 ao abrigo do Artigo 21(2)(b)
O registo é a camada de visibilidade do tratamento de incidentes. O Artigo 21(2)(b) é onde reside o dever, o CIR §3.2 nomeia os doze tipos de eventos e as regras operacionais, e a Alemanha transpõe a mesma regra para o §30(2)(2) BSIG.
A versão curta
O registo e a monitorização não são um dever separado na NIS 2. Inserem-se na medida de tratamento de incidentes do Artigo 21(2)(b). A lógica é simples: se não consegue ver o que se passa na sua rede, não consegue detetar um incidente de segurança, nem consegue contê-lo.
O CIR (UE) 2024/2690 §3.2 acrescenta o detalhe. Nomeia doze tipos de eventos que tem de registar, define as regras para alertas e resposta qualificada, fixa um período de retenção definido, e exige sistemas com sincronização horária mais monitorização redundante. Esse é o piso mínimo para os setores nomeados no Anexo do CIR.
A Alemanha transpõe a mesma regra para o §30(2)(2) BSIG. A base prática é o IT-Grundschutz OPS.1.1.5 'Protokollierung' e DER.1 'Detektion'. Esta página percorre a diretiva, o regulamento de execução da UE e a transposição alemã por essa ordem.
Artigo 21(2)(b) da Diretiva NIS 2 (2022/2555)
Tratamento de incidentes.
Este é o ponto (b) na lista de dez medidas de cibersegurança que cada entidade essencial e importante tem de implementar. O CIR §3 operacionaliza-o em seguida. O registo e a monitorização inserem-se no §3.2.
CIR (UE) 2024/2690, Anexo §3.2.1
As entidades relevantes estabelecem procedimentos e utilizam instrumentos para monitorizar e registar atividades nas suas redes e sistemas de informação, de modo a que os eventos que possam ser considerados incidentes de segurança possam ser detetados e tratados para conter o seu impacto.
Como se trata de um regulamento (e não de uma diretiva), é legislação da UE diretamente vinculativa. O §3.2 desdobra-se depois em sete subpontos que cobrem os tipos de eventos a registar, os alertas, a retenção, a sincronização horária e a redundância. Não é necessária transposição nacional.
§30(2)(2) BSIG (Alemanha)
Tratamento de incidentes.
A Alemanha copia o texto da UE palavra por palavra. O 'como' prático vem através do IT-Grundschutz: OPS.1.1.5 'Protokollierung' para a conceção do registo, e DER.1 'Detektion' para o lado dos alertas e da resposta.
Registar os doze tipos de eventos
Construa a lista a partir do seu inventário de ativos. Quando apropriado, capture: tráfego de rede de entrada e de saída, alterações de utilizadores e de privilégios, acesso a sistemas e aplicações, eventos de autenticação, toda a atividade privilegiada e de administração, acesso a ficheiros críticos de configuração ou de cópias de segurança, registos de ferramentas de segurança (antivírus, IDS, firewall), uso de recursos do sistema, acesso físico, uso de equipamento de rede, ativação ou pausa dos próprios registos, e eventos ambientais.
Revisão, alarme, resposta qualificada
Recolher registos não basta. Verifique-os com uma cadência regular em busca de tendências invulgares ou indesejadas. Quando apropriado, defina limiares. Quando um limiar é ultrapassado, dispare um alarme automático. E garanta que alguém qualificado responde realmente a tempo. Armazenamento sem revisão não é registo nos termos do §3.2.
Proteger, reter, sincronizar a hora, redundância
Os próprios registos são prova. Guarde-os durante um período de retenção definido, proteja-os de acesso e alterações não autorizados, sincronize a hora de todos os sistemas para que os eventos possam ser correlacionados, e opere o sistema de monitorização de forma redundante. A monitorização do sistema de monitorização é, ela própria, independente dos sistemas que monitoriza.
Os registos são um ativo, não um subproduto
O §3.2.5 trata os registos como dados críticos. Período de retenção definido, proteção contra adulteração, proteção contra acesso não autorizado. Se um atacante puder apagar os registos que mostram o que fez, o dever de registo não está cumprido. É também por isso que o §3.2.3(k) lista explicitamente a 'ativação, desativação ou pausa' dos registos como um evento que tem de registar.
Rever os registos é um dever, não um luxo
O §3.2.4 exige verificações regulares de tendências invulgares, limiares quando apropriado, alarmes automáticos em caso de ultrapassagem de limiar, e uma resposta qualificada atempada. Um SIEM que ninguém consulta não cumpre isto. Um auditor vai perguntar quem reviu quais alertas, quando, e o que fez a respeito deles.
BSI / IT-Grundschutz OPS.1.1.5 + DER.1
O BSI aponta para o IT-Grundschutz como o caminho prático. O OPS.1.1.5 'Protokollierung' é onde reside a conceção do registo (o que registar, retenção, proteção). O DER.1 'Detektion' cobre o lado dos alertas e da resposta (cadência de revisão, regras de SIEM, tratamento qualificado). Em conjunto, os dois correspondem ao CIR §3.2.
Orientação Técnica de Implementação da ENISA
A TIG da ENISA dá exemplos concretos de prova para o §3.2: modelos de política de registo, exemplos de limiares de alerta, valores predefinidos de retenção, e um mapeamento para o Anexo A da ISO/IEC 27001:2022 (A.8.15 Registo, A.8.16 Atividades de monitorização). Se já opera segundo a ISO 27001, reutiliza a maior parte dos controlos.
Leis de transposição nacionais
Cada Estado-Membro tem a sua própria transposição (Países Baixos: Cyberbeveiligingswet, Áustria: NISG, Bélgica: NIS2-Wet). O dever do §3.2 é o mesmo porque o CIR é diretamente aplicável. O que difere: com que autoridade nacional fala, e como são geridos localmente os canais de notificação e as cadências de auditoria.
Guardamos todos os registos para sempre, por isso estamos cobertos.
O §3.2.5 exige um período de retenção definido, não infinito. Guardar tudo para sempre é um problema de proteção de dados (Art. 5(1)(e) GDPR, limitação da conservação) e um problema de custos. Decida uma janela de retenção por tipo de registo, escreva-a, justifique-a face ao seu quadro de risco, e cumpra-a.
O SIEM trata disso, por isso estamos bem.
Quase, mas não totalmente. O §3.2.4 não exige apenas armazenamento. Exige revisão regular, limiares quando apropriado, alarmes automáticos em caso de ultrapassagem, e uma pessoa qualificada que responda de facto. Um SIEM que corre sem regras, ou com regras que ninguém afina, falha o §3.2.4.
Registamos a atividade dos utilizadores, mas não a atividade de administração.
O §3.2.3(e) é explícito: todo o acesso privilegiado a sistemas e aplicações, mais as atividades das contas de administração. Os administradores são os utilizadores de maior impacto na sua rede. Não os registar é a lacuna que um auditor encontra primeiro.
O que vemos na prática: a maioria das empresas do Mittelstand tem registos de firewall e registos de Active Directory. Raramente têm os doze tipos de eventos do §3.2.3 cobertos de forma sistemática. O acesso privilegiado, as alterações a ficheiros de configuração e o acesso físico são as três lacunas habituais.
A correção mais barata: construa a lista do §3.2.3 a partir do seu inventário de ativos (RSK 2.2), encaminhe tudo para um único sítio (um repositório central de registos ou um pequeno SIEM), defina limiares nos eventos de elevado valor, e reveja semanalmente. Não precisa de um SOC gerido logo no primeiro dia. Precisa de alguém que olhe para os alertas e saiba o que fazer.
O módulo INC cobre a estratégia de registo do §3.2: que tipos de eventos regista, face a que ativos, com que janela de retenção. Escreve-a uma vez, aprova-a, e ela torna-se a sua política de registo pronta para auditoria.
O módulo EFF cobre o lado da revisão do §3.2.4: limiares de alarme, cadência de revisão, prova de resposta qualificada. As aprovações e o registo de auditoria mostram a um auditor que alguém olhou para os alertas e agiu sobre eles. Sem pilhas de folhas de cálculo. Sem uma segunda ferramenta.
- Diretiva (UE) 2022/2555 (NIS 2), Artigo 21(2)(b). eur-lex.europa.eu/eli/dir/2022/2555/oj
- Regulamento de Execução (UE) 2024/2690 da Comissão (CIR), Anexo §3.2. eur-lex.europa.eu/eli/reg_impl/2024/2690/oj
- Lei do BSI (BSIG), §30(2)(2), conforme alterada pela Lei de Implementação da NIS2 e de Reforço da Cibersegurança
- Compêndio IT-Grundschutz, OPS.1.1.5 'Protokollierung' e DER.1 'Detektion'. bsi.bund.de/grundschutz
- Orientação Técnica de Implementação da ENISA para o CIR (UE) 2024/2690 (situação em maio de 2026)