Art. 23 NIS 2

Ataques DDoS ao abrigo da NIS 2

Sinais de deteção, camadas de mitigação e a decisão de notificação ao abrigo do artigo 23.o da NIS 2 e dos limiares do CIR 2024/2690.

Simon OrzelSimon Orzel·

Porque o DDoS se enquadra diretamente no artigo 23.o

Um ataque distribuído de negação de serviço satura um alvo com tráfego de muitas origens, de modo que os utilizadores legítimos deixam de conseguir aceder ao serviço. Ao abrigo da NIS 2, a categoria técnica é menos interessante do que o efeito. Assim que um DDoS degrada ou interrompe de forma mensurável um serviço que a entidade presta, o artigo 23.o da NIS 2 transforma-o num evento de notificação obrigatória com uma cascata fixa.

O Regulamento de Execução (UE) 2024/2690 da Comissão (o CIR) não designa a negação de serviço como categoria. Para os prestadores digitais que abrange, os artigos 5.º a 14.º fixam limiares de disponibilidade por tipo de serviço (para a nuvem: completamente indisponível durante mais de 30 minutos, artigo 7.º). Para as outras entidades essenciais e importantes, aplica-se o teste geral de significância do artigo 23.o, n.o 3, da NIS 2. O impacto na disponibilidade do serviço é o gatilho dominante em ambos os casos.

Uma entidade que opera um sítio web, uma API, um portal em linha, um gateway de pagamento, um resolvedor de DNS ou qualquer outro serviço exposto à internet atinge tipicamente o limiar de notificação mais depressa do que consegue escalar as defesas. A cascata legal começa, portanto, a correr em paralelo com a mitigação, não depois dela.

Ponto de ancoragem legal
Diretiva da UE, regulamento de execução da UE e o exemplo da transposição alemã. A camada da UE é vinculativa em todos os Estados-Membros.

Diretiva da UE (vinculativa em toda a União)

Os Estados-Membros asseguram que as entidades essenciais e importantes apresentam ao CSIRT ou, se aplicável, à autoridade competente: (a) sem demora injustificada e, em qualquer caso, no prazo de 24 horas após terem tido conhecimento do incidente significativo, um alerta precoce; (b) sem demora injustificada e, em qualquer caso, no prazo de 72 horas após terem tido conhecimento do incidente significativo, uma notificação de incidente; (c) um relatório intercalar sobre atualizações pertinentes do estado da situação, a pedido de um CSIRT ou, se aplicável, da autoridade competente; (d) um relatório final, o mais tardar um mês após a apresentação da notificação de incidente referida na alínea b); (e) em caso de incidente em curso no momento da apresentação do relatório final referido na alínea d), os Estados-Membros asseguram que as entidades em causa apresentem um relatório de progresso nesse momento e um relatório final no prazo de um mês após o tratamento do incidente.

Artigo 23.o, n.o 4, da NIS 2. O relógio de notificação começa no momento em que a entidade tem conhecimento do incidente significativo, não quando a mitigação começa ou termina. Um DDoS que ainda esteja em curso na marca de um mês aciona a variante de relatório de progresso na alínea e).

Regulamento de execução da UE (detalhe técnico vinculativo)

No que diz respeito aos prestadores de serviços de computação em nuvem, considera-se que um incidente é significativo nos termos do artigo 3.º, n.º 1, alínea g), se preencher um ou mais dos seguintes critérios: a) Um serviço de computação em nuvem prestado fica completamente indisponível durante mais de 30 minutos; b) A disponibilidade de um serviço de computação em nuvem de um prestador fica limitada, por um período superior a uma hora, para mais de 5 % dos utilizadores do serviço de computação em nuvem na União ou para mais de um milhão de utilizadores do serviço de computação em nuvem na União, consoante o que for menor; […]

Artigo 7.º do Regulamento de Execução (UE) 2024/2690 da Comissão, como exemplo. O CIR aplica-se diretamente aos prestadores de serviços de DNS, aos registos de nomes de TLD, aos prestadores de serviços de computação em nuvem, aos prestadores de serviços de centros de dados, aos prestadores de redes de distribuição de conteúdos, aos prestadores de serviços geridos, aos prestadores de serviços de segurança geridos, aos prestadores de mercados em linha, de motores de pesquisa em linha e de serviços de redes sociais. Para estes tipos de entidade, os artigos 5.º a 14.º fixam os limiares de disponibilidade; um DoS ou DDoS que ultrapasse um deles é significativo.

Exemplo nacional (Alemanha)

Wesentliche und wichtige Einrichtungen melden dem Bundesamt erhebliche Sicherheitsvorfälle. Die Meldung erfolgt unverzüglich, spätestens jedoch innerhalb von 24 Stunden nach Kenntnisnahme als Frühwarnung, innerhalb von 72 Stunden als Meldung mit erster Bewertung und innerhalb eines Monats als Abschlussbericht.

§ 32 BSIG (NIS2UmsuCG). A transposição alemã espelha a cascata do artigo 23.o, n.o 4, literalmente. Os relatórios vão para o BSI através do Meldeportal. Outros Estados-Membros usam o seu próprio CSIRT nacional ou o encaminhamento para a autoridade competente. A substância é idêntica.

Três elementos operacionais
A deteção, a mitigação e a notificação correm em paralelo durante um evento de DDoS. Cada um tem os seus próprios critérios de decisão.
Detetar

Sinais de deteção ao nível do SOC

Os indicadores típicos captados pela monitorização de rede ou por um SOC incluem um pico súbito no volume de tráfego de entrada, uma queda na proporção de pedidos bem-sucedidos, contagens anómalas de ligações nos dispositivos de extremidade, uma onda de agentes de utilizador ou padrões de consulta idênticos, latência ou perda de pacotes acrescida nas ligações de perímetro e alertas de saturação dos fornecedores a montante. Combinados com uma queda mensurável na disponibilidade do serviço, estes indicadores transformam um evento num incidente na aceção do artigo 6.o, n.o 6, da NIS 2.

Mitigar

Camadas de mitigação de uso comum

Os padrões de mitigação comuns incluem a filtragem de tráfego a montante no fornecedor de serviços de internet, a depuração através de um serviço terceiro de proteção contra DDoS, a limitação de débito e a moderação de ligações na extremidade, a distribuição anycast e geográfica, o blackholing ou null-routing das origens de ataque ao nível do operador e proteções da camada aplicacional, como a gestão de bots. A defesa em camadas é aqui descrita, não recomendada; a combinação proporcionada depende da avaliação de risco da entidade ao abrigo do artigo 21.o da NIS 2.

Notificar

Decisão de notificação ao abrigo do artigo 23.o

Assim que a disponibilidade do serviço for afetada de uma forma que cumpre o artigo 23.o, n.o 3, da NIS 2 ou, para as entidades de infraestrutura digital, os limiares do CIR (artigos 5.º a 14.º), a cascata começa: alerta precoce no prazo de 24 horas, notificação de incidente no prazo de 72 horas, relatório intercalar a pedido, relatório final no prazo de um mês, relatório de progresso se o incidente ainda estiver em curso na marca de um mês.

Dois princípios estruturais
Ambos decorrem do texto da diretiva e moldam a forma como um DDoS é classificado.

O gatilho é o impacto no serviço, não o volume do ataque

O artigo 23.o, n.o 3, da NIS 2 define a significância pelo efeito no serviço: perturbação operacional grave, perdas financeiras ou danos materiais ou imateriais a outras pessoas singulares ou coletivas. Um ataque de 500 Gbps totalmente absorvido não é, por si só, um incidente significativo. Um ataque de 5 Gbps que deixa um portal offline durante uma hora costuma ser. Para os prestadores digitais abrangidos pelo CIR, os limiares são ainda mais diretos, por exemplo um serviço de nuvem completamente indisponível durante mais de 30 minutos (artigo 7.º do CIR).

O DDoS mascara muitas vezes um evento de segunda fase

Os ataques volumétricos são por vezes usados como cobertura para credential stuffing, exfiltração de dados ou implantação de ransomware. A análise pós-incidente exigida pelo artigo 23.o, n.o 4, alínea d), da NIS 2 no relatório final distingue tipicamente entre o evento visível de disponibilidade e qualquer evento secundário de acesso ou integridade detetado durante ou após a inundação.

Camada operacional nacional
A diretiva é direito da UE. As autoridades nacionais tratam da receção pelo CSIRT, da cooperação com os ISP e das orientações técnicas.
DE

BSI como CSIRT nacional e ponto de notificação

Na Alemanha, o BSI recebe os relatórios do artigo 23.o através do Meldeportal ao abrigo do § 32 BSIG. O BSI publica também orientações de tratamento de incidentes, como a BSI-Standard 200-4 (BCM) e notas técnicas operacionais; estas são orientações, não obrigações de notificação adicionais. Outros Estados-Membros têm estruturas paralelas (NCSC-NL, ANSSI, NCSC-IE e por aí adiante).

UE

Cooperação com os ISP e filtragem a montante

Os fornecedores de serviços de internet podem absorver ou filtrar o tráfego de ataque antes de este chegar à extremidade do cliente. Na Alemanha, os fornecedores de comunicações eletrónicas operam ao abrigo do TKG e cooperam com o BSI na resposta a ameaças; a BSI TR-03103 abrange interfaces técnicas para algumas categorias. O ponto para a entidade notificadora é que a mitigação do ISP não remove a obrigação de notificação do artigo 23.o se o serviço já tiver sido afetado.

UE

Orientações técnicas e panorama de ameaças da ENISA

A ENISA publica o relatório anual Threat Landscape e orientações de resposta a incidentes. O Threat Landscape 2024 confirma o DDoS como uma das principais categorias de ameaça observadas nos setores da UE. Os documentos da ENISA são material de referência; não alteram a cascata do artigo 23.o.

Armadilhas comuns
Padrões vistos repetidamente em análises pós-incidente de DDoS em entidades NIS 2.
  • O ISP trata disso, por isso nada precisa de ser notificado

    A filtragem do lado do ISP reduz o impacto, mas não altera o gatilho legal. Se o serviço esteve indisponível ou significativamente degradado entre o início do ataque e a mitigação do ISP, o artigo 23.o, n.o 3, da NIS 2 ou os limiares do CIR (artigos 5.º a 14.º) estão acionados. A cascata de notificação corre em paralelo com a resposta ao nível do operador.

  • Tratar apenas o sintoma é suficiente

    A limitação de débito e a depuração param a inundação, mas raramente identificam se o DDoS foi uma distração. Uma análise pós-incidente que não verifica os registos de autenticação, as anomalias de tráfego de saída e as alterações de configuração durante a janela do ataque deixa o evento secundário por detetar. O relatório final do artigo 23.o, n.o 4, alínea d), é o ponto de controlo documentado para isto.

  • Assim que o tráfego normaliza, o incidente está encerrado

    O artigo 23.o, n.o 4, alínea d), da NIS 2 exige um relatório final no prazo de um mês após a notificação de incidente. Esse relatório cobre a causa raiz, a mitigação tomada e os ensinamentos retirados. Uma entidade que encerra o ticket no momento em que o tráfego cai tipicamente não tem nada para submeter, o que é, em si mesmo, uma não conformidade documentada.

Notas do profissional

Dois hábitos operacionais separam as entidades que lidam com o DDoS de forma limpa das que se atrapalham. Primeiro, o relógio de notificação e o relógio de mitigação são acompanhados separadamente. A mitigação pode levar horas; o alerta precoce de 24 horas tem o seu próprio responsável e modelo prontos antes do evento. Segundo, a análise pós-incidente é agendada no momento da deteção, não no fim da inundação. Uma marcação na agenda 25 dias após a deteção obriga a que o relatório final seja escrito, mesmo num incidente calmo.

A configuração do DNS e da extremidade importa mais do que as decisões em tempo de ataque. O encaminhamento anycast, prestadores de DNS autoritativo separados, um acordo testado de filtragem a montante com o ISP e um caminho de contacto documentado com o NOC do operador estão tipicamente em vigor muito antes de chegar o primeiro pacote de um ataque. O mesmo se aplica aos modelos de relatório: os campos de alerta precoce e de notificação exigidos pelo § 32 BSIG e pelos portais nacionais equivalentes são suficientemente estáticos para serem pré-preenchidos.

Fontes
  • Diretiva (UE) 2022/2555 (NIS 2), artigo 6.o, n.o 6 (definição de incidente), artigo 21.o (medidas de gestão de risco), artigo 23.o (notificação). EUR-Lex: eur-lex.europa.eu/eli/dir/2022/2555/oj
  • Regulamento de Execução (UE) 2024/2690 da Comissão, artigos 3.º e 5.º a 14.º (limiares de significância para os prestadores digitais que abrange). EUR-Lex: eur-lex.europa.eu/eli/reg_impl/2024/2690/oj
  • BSIG (NIS2UmsuCG), § 32 (obrigações de notificação ao BSI). gesetze-im-internet.de
  • BSI Meldeportal e orientações operacionais sobre notificação de incidentes. bsi.bund.de
  • ENISA Threat Landscape 2024, capítulo sobre DDoS. enisa.europa.eu
  • BSI-Standard 200-4 (Gestão da Continuidade do Negócio). bsi.bund.de
  • BSI TR-03103 (série de orientações técnicas). bsi.bund.de

Na prática

Onde isto aparece no percurso guiado

O percurso guiado transforma isto em passos que preenche, com a lei explicada ao lado de cada um. Abra um passo para ver o seu ecrã, preenchido para uma empresa fictícia.

O percurso em si está em alemão e em inglês.

  1. Incident Handling

    Know how to report an incident

    Three reports to your authority, with fixed deadlines.

Tem de tratar da NIS2?

Acompanhamos passo a passo. Preenche, nós explicamos cada ponto em palavras simples e, no fim, a direção assina.

O percurso NIS2: o seu caminho passo a passo, com os primeiros pontos feitos