As 9 medidas do Art. 27.º (parte 1)
Tratamento de incidentes, continuidade, cadeia de abastecimento e desenvolvimento
Cenário de abertura
Imagine que o vosso sistema ERP está encriptado. Um ransomware infiltrou-se através de um software de contabilidade de um fornecedor. Os dados de produção estão inacessíveis. O CEO pergunta: «O que fizemos mal? Quais as medidas NIS2 que deveriamos ter implementado?» A resposta envolve pelo menos quatro das nove medidas do Art. 27.º.
a) Tratamento de incidentes
A primeira medida obrigatória (Art. 27.º, al. a) é a implementação de capacidades de tratamento de incidentes. O modelo SANS de resposta a incidentes, alinhado com o NIST SP 800-61, organiza-se em seis fases: Preparar (definir políticas, equipa CSIRT interno ou externo, runbooks); Detetar (SIEM, EDR, alertas de anomalias); Conter (isolamento de sistemas comprometidos); Erradicar (remoção de malware, patch de vulnerabilidades); Recuperar (restauro a partir de backups verificados); e Lições aprendidas (post-incident review documentado). Cada fase deve ter procedimentos escritos e testados.
b) Continuidade de negócio e backups
A segunda medida (Art. 27.º, al. b) exige planos de continuidade de negócio e capacidades de recuperação. A regra de backup 3-2-1-1-0 é a referência da indústria: 3 cópias dos dados, em 2 suportes diferentes, 1 cópia offsite, 1 cópia offline ou imutável (air-gapped), 0 erros verificados nos testes de restauro. O plano de continuidade (BCP) e o plano de recuperação de desastres (DRP) devem ser documentados e aprovados pela gestão. É boa prática testá-los pelo menos uma vez por ano; a periodicidade não está fixada na lei. A gestão de crises inclui linhas de comunicação alternativas para o caso de os sistemas principais estarem comprometidos.
c) Segurança da cadeia de abastecimento
O Art. 27.º, al. c) e o Art. 28.º exigem que as entidades avaliem e gerem o risco introduzido pelos fornecedores de tecnologia e serviços. O caso SolarWinds de 2020 é o exemplo paradigmático: um update malicioso do software de monitorização Orion infetou cerca de 18 000 organizações a nível mundial, incluindo agências do governo dos EUA. A resposta regulatória passou por exigir inventários de fornecedores críticos, cláusulas contratuais de segurança, auditorias de fornecedores e avaliação de risco antes de onboarding de novos fornecedores de software ou serviços.
d) Segurança no desenvolvimento e aquisição de sistemas
A quarta medida (Art. 27.º, al. d) abrange a segurança no ciclo de desenvolvimento de software e na aquisição de produtos e serviços digitais. As boas práticas incluem a adoção de um SBOM (Software Bill of Materials) nos formatos SPDX ou CycloneDX para rastrear componentes de terceiros, bem como a integração de testes de segurança no pipeline de CI/CD (SAST, DAST, SCA). O caso XZ Utils (CVE-2024-3094) de 2024 ilustrou os riscos da cadeia de abastecimento de software open-source: um backdoor inserido gradualmente por um ator malicioso num componente de compressão amplamente utilizado, descoberto apenas por acidente.
Ciclo de resposta a incidentes NIS2
Caso real
SolarWinds 2020: 18 000 vítimas por um update maliciosoEm dezembro de 2020, revelou-se que o grupo APT29 (ligado ao serviço de inteligência russo SVR) tinha inserido um backdoor no software de monitorização de rede Orion da SolarWinds. Cerca de 18 000 organizações, incluindo o Departamento do Tesouro dos EUA e a Microsoft, tinham instalado o update malicioso. O ataque permaneceu ativo durante meses sem deteção. A NIS2 responde a este vetor com os requisitos das alíneas c) e d) do Art. 27.º.
Quiz do módulo 4
Responda a 5 perguntas sobre o conteúdo deste módulo. É necessário obter 70% ou mais para avançar.