Incidente de phishing ao abrigo da NIS 2
Como o phishing ultrapassa o limiar de incidente significativo, o que a cascata de notificação exige, e o que um manual típico trata em paralelo.
O que esta página abrange
O phishing não é uma categoria regulamentar separada ao abrigo da NIS 2. A diretiva trata uma tentativa de phishing bem-sucedida como um possível incidente significativo entre outros. O teste qualitativo do Artigo 23(3) NIS 2 é o mesmo que qualquer outro tipo de incidente tem de passar. O Regulamento de Execução da Comissão (UE) 2024/2690 (CIR) nomeia, na Secção 11.6 do Anexo, categorias que, para as entidades de infraestrutura digital, contam como significativas por predefinição.
O fator desencadeador que a maioria dos operadores ignora é o comprometimento de credenciais. Um email de phishing que captura um conjunto funcional de credenciais de uma conta crítica não é um quase-acidente. É um evento bem-sucedido de acesso não autorizado. Se cumpre depois o limiar do Artigo 23(3) depende do que a conta consegue alcançar, do que foi extraído e de que serviços foram afetados.
Esta página estabelece a mecânica, não o aconselhamento jurídico. Descreve os relógios de alerta precoce, de notificação de incidente e de relatório final ao abrigo do Artigo 23(4) NIS 2, como um manual típico de SOC trata a contenção e a preservação de evidência, e onde o Artigo 33 do GDPR corre em paralelo quando estão envolvidos dados pessoais.
Diretiva NIS 2 (UE) 2022/2555, Art. 23(3)
Um incidente é considerado significativo se: (a) tiver causado ou for suscetível de causar uma perturbação operacional grave dos serviços ou perdas financeiras para a entidade em causa; (b) tiver afetado ou for suscetível de afetar outras pessoas singulares ou coletivas, causando danos materiais ou imateriais consideráveis.
Esta é a única definição geral de incidente significativo no direito da UE. Ambos os pontos usam «suscetível de causar», pelo que o dano potencial conta tanto como o dano efetivo. Um evento de phishing que comprometeu credenciais de uma conta privilegiada pode cumprir o ponto (a) mesmo antes de qualquer serviço ter efetivamente parado.
CIR (UE) 2024/2690, Anexo Secção 11.6
Um incidente é considerado significativo sempre que cause ou seja suscetível de causar uma perturbação operacional grave dos serviços ou perdas financeiras para a entidade em causa, ou sempre que tenha afetado ou seja suscetível de afetar outras pessoas singulares ou coletivas, causando danos materiais ou imateriais consideráveis.
A Secção 11.6 enumera categorias que se qualificam sempre como significativas para as entidades de infraestrutura digital abrangidas pelo CIR: ransomware, exfiltração de dados pessoais ou sensíveis, negação de serviço contra serviços essenciais, e perda de confidencialidade ou integridade de ativos críticos. Um caso de phishing que termine em qualquer uma destas ultrapassou o limiar por definição. Para os setores fora do CIR, o teste qualitativo do Artigo 23(3) prevalece sozinho.
§ 32 BSIG (Alemanha)
As entidades essenciais e importantes notificam o Bundesamt dos incidentes significativos sem demora injustificada, o mais tardar dentro dos prazos nomeados no Artigo 23(4) da Diretiva (UE) 2022/2555.
A Alemanha adota a cascata da diretiva tal como está e encaminha a notificação através do portal do BSI em meldung.bsi.bund.de. O § 32 BSIG é a âncora alemã. Os prazos substantivos continuam a ser os do Artigo 23(4) NIS 2: um alerta precoce no prazo de 24 horas, uma notificação de incidente no prazo de 72 horas e um relatório final no prazo de um mês.
Triagem e decisão sobre o limiar
O relógio começa quando a entidade toma conhecimento do incidente. O conhecimento é quando uma pessoa competente dentro da organização sabe o suficiente para suspeitar de um incidente significativo, não quando a investigação termina. A triagem responde a três perguntas: que contas foram comprometidas, o que essas contas conseguem alcançar e se alguma categoria da Secção 11.6 do Anexo do CIR se aplica. Se sim, a questão do limiar fica fechada e o alerta precoce é preparado.
Contenção e evidência
Um manual típico de SOC redefine as credenciais comprometidas, revoga as sessões ativas, bloqueia o domínio do remetente, isola os pontos finais afetados da rede e preserva a caixa de correio, a imagem do disco do ponto final e os registos de autenticação antes de qualquer reinstalação. Apagar uma máquina sujeita a phishing antes de fazer a sua imagem destrói o registo forense que mais tarde responde ao que o atacante realmente alcançou.
A cascata de 24h / 72h / 1 mês
O Artigo 23(4) NIS 2 define três prazos a partir do momento do conhecimento. No prazo de 24 horas, a entidade apresenta um alerta precoce indicando se há suspeita de o incidente ter sido causado por atos ilícitos ou maliciosos ou de ter impacto transfronteiriço. No prazo de 72 horas, uma notificação de incidente atualiza o alerta precoce com uma avaliação inicial, indicadores de comprometimento e gravidade. No prazo de um mês, um relatório final descreve a causa raiz, a mitigação e qualquer impacto transfronteiriço.
O alcance do dano é o que torna o phishing significativo
O Artigo 23(3) não se importa com a técnica. Importa-se com o efeito. Um email de phishing aberto por um único funcionário das finanças não é significativo. O mesmo email, se capturou credenciais funcionais que permitem o acesso ao sistema de faturação, à folha de pagamentos ou a uma base de dados de clientes, pode cumprir o ponto (a) sobre perturbação operacional potencial ou o ponto (b) sobre dano a pessoas singulares ou coletivas. A questão do alcance é: o que poderia a credencial comprometida alcançar antes de ser revogada, e o que foi alcançado durante a janela de acesso.
A rapidez vence a completude
A posição do BSI é «Schnelligkeit vor Vollständigkeit». O alerta precoce de 24 horas foi feito para o momento em que o quadro está incompleto. O formulário pede uma classificação inicial e os factos conhecidos, não uma análise final de causa raiz. Reter o alerta precoce até tudo ser conhecido falha o prazo; o prazo não pode ser recuperado mais tarde, mesmo que o incidente venha a revelar-se afinal não significativo.
BSI: notificação NIS 2 em meldung.bsi.bund.de
O BSI opera o canal único do § 32 BSIG para a notificação de incidentes NIS 2. O portal pré-estrutura as submissões de 24h, 72h e um mês e guarda o trilho de auditoria. A orientação pública do BSI repete a redação do Artigo 23(3) e confirma «Schnelligkeit vor Vollständigkeit». Os incidentes desencadeados por phishing que cumprem o teste qualitativo passam por este canal, independentemente de também tocarem em dados pessoais.
BfDI / DPA estadual: paralelo do Artigo 33 do GDPR
Se o evento de phishing expôs dados pessoais, o Artigo 33 do GDPR corre a par da NIS 2. A notificação de proteção de dados vai para a autoridade de controlo competente no prazo de 72 horas após o conhecimento, salvo se for improvável que a violação resulte num risco para pessoas singulares. O relatório NIS 2 e a notificação do GDPR são documentos separados para autoridades separadas; os factos subjacentes sobrepõem-se, os canais formais não.
ZAC LKA: queixa-crime como decisão separada
Um ataque de phishing bem-sucedido é normalmente um ato criminal ao abrigo do § 202a, § 202b ou § 263a StGB. A Zentrale Ansprechstelle Cybercrime (ZAC) do Landeskriminalamt responsável é o ponto de entrada para a queixa-crime. Apresentá-la é uma decisão de gestão separada da notificação regulamentar e não suspende nenhum dos relógios.
«Foi só um utilizador, não é significativo»
O teste do Artigo 23(3) pergunta se o incidente é suscetível de causar uma perturbação operacional grave ou um dano considerável a terceiros. Um conjunto de credenciais funcionais de uma conta privilegiada nas mãos de um atacante é suscetível de fazer ambos, independentemente de quantos utilizadores foram sujeitos a phishing. A significância é decidida pelo que a credencial consegue alcançar, não pelo tamanho da população que clicou.
«Reinstalar já o portátil para estar seguro»
Apagar o ponto final antes de ser tirada uma imagem forense destrói o único registo do que o atacante realmente fez durante a janela de acesso. A notificação de incidente de 72 horas e o relatório final de um mês pedem ambos indicadores de comprometimento e causa raiz. Sem a imagem, essas respostas são suposições. Um manual típico isola primeiro, faz a imagem do ponto final e da caixa de correio afetada, e só depois reinstala.
«O silêncio é mais seguro, não digas nada internamente»
O Artigo 23(1)(h) NIS 2 obriga a entidade, sempre que adequado, a comunicar aos destinatários dos seus serviços potencialmente afetados. O silêncio do lado interno atrasa a segunda vaga de deteção: outros colaboradores que receberam o mesmo email, outras contas que já podem estar comprometidas. Uma nota interna curta e factual nas primeiras horas faz parte da resposta, não é um comunicado de imprensa.
A coisa mais útil que uma pequena equipa pode ensaiar antes do evento real é a decisão sobre o limiar. Escreva, com antecedência, quais as contas «críticas» para a entidade (consolas de administração, sistemas de pagamento, fornecedor de identidade, base de dados de clientes, controlo OT). Um evento de phishing que capte qualquer uma destas é, pela sua própria definição, um candidato à Secção 11.6 e o relógio de 24 horas começa.
A segunda coisa mais útil é o modelo de relatório. O portal do BSI pede um conjunto estruturado de factos. Redigir o alerta precoce pela primeira vez durante um incidente real desperdiça as primeiras duas horas. Um modelo pré-preenchido com os identificadores da empresa, o setor, os canais de contacto e uma secção narrativa em branco pode ser submetido em trinta minutos, uma vez reunidos os factos.
O módulo de incidentes abre um caso a partir de um único carimbo temporal de «conhecimento» e ancora três relógios: 24 horas, 72 horas, um mês. Cada relógio tem o seu próprio modelo, pré-preenchido com os campos que o Artigo 23(4) e a Secção 11.6 do Anexo do CIR pedem. Introduz o que é conhecido, a plataforma mostra o que ainda falta. Um temporizador separado do Artigo 33 do GDPR ativa-se se forem assinalados dados pessoais no caso.
O registo do caso preserva a cadeia do momento de conhecimento, das ações de contenção, das comunicações e das submissões. Esse registo é a evidência de auditoria que o portal do BSI não consegue gerar por si e o documento que um auditor pedirá numa revisão do § 61 BSIG.
- Diretiva (UE) 2022/2555 (NIS 2), Artigo 23 (notificação de incidentes), Artigo 21(2)(g) (formação de sensibilização para a segurança), Considerando 101 (fatores de significância). EUR-Lex.
- Regulamento de Execução da Comissão (UE) 2024/2690, de 17 de outubro de 2024, Anexo Secção 11.6 (categorias de incidentes sempre considerados significativos para as entidades de infraestrutura digital). EUR-Lex.
- BSIG (Gesetz über das Bundesamt für Sicherheit in der Informationstechnik), § 32 (notificação de incidentes ao BSI). gesetze-im-internet.de.
- Regulamento (UE) 2016/679 (GDPR), Artigo 33 (notificação de violação de dados pessoais à autoridade de controlo no prazo de 72 horas). EUR-Lex.
- BSI, orientação pública sobre a cascata de notificação da NIS 2 e o princípio «Schnelligkeit vor Vollständigkeit». bsi.bund.de.
- Strafgesetzbuch (StGB) § 202a Ausspähen von Daten, § 202b Abfangen von Daten, § 263a Computerbetrug. gesetze-im-internet.de.