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 do artigo 11.o, n.o 6, do CIR 2024/2690.
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 artigo 11.o, n.o 6, do Regulamento de Execução (UE) 2024/2690 da Comissão (o CIR) designa explicitamente a negação de serviço como uma das categorias que, para os fornecedores de infraestrutura digital e de serviços de TIC, conta como incidente significativo. 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.
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)
Um ataque de negação de serviço ou um ataque distribuído de negação de serviço é considerado um incidente significativo para as entidades que prestam serviços de infraestrutura digital e as entidades que prestam gestão de serviços de TIC, sempre que o ataque cause uma indisponibilidade total do serviço ou uma degradação significativa do serviço.
Artigo 11.o, n.o 6, do Regulamento de Execução (UE) 2024/2690 da Comissão. 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, um DoS ou DDoS com indisponibilidade total ou degradação significativa é, por definição, 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.
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.
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.
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, o artigo 11.o, n.o 6, do CIR, 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.
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. O teste do §11(6) do CIR para entidades de infraestrutura digital é ainda mais direto: indisponibilidade total ou degradação significativa.
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.
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).
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.
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 ao abrigo do artigo 18.o da NIS 2. 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.
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 o artigo 11.o, n.o 6, do CIR está acionado. 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.
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.
O módulo de incidentes do nisd2.eu transporta a cascata do artigo 23.o, n.o 4, como um fluxo de trabalho estruturado: alerta precoce às 24h, notificação de incidente às 72h, relatório intercalar a pedido, relatório final ao fim de um mês, variante de progresso se o incidente ainda estiver em curso. A plataforma data cada passo face ao momento do conhecimento, e não face ao momento do ataque, que é o que a diretiva mede.
As referências de ativos no incidente ligam o serviço afetado às entradas no inventário de ativos construído ao abrigo do RSK 2.2, para que a análise pós-incidente possa rastrear que ativos, fornecedores e processos estiveram envolvidos sem reconstruir o contexto do zero.
- 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, artigo 11.o, n.o 6 (negação de serviço designada como incidente significativo para a infraestrutura digital e os fornecedores de serviços de TIC). 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