Resposta a incidentes em WordPress ao abrigo da NIS2: playbook de alerta precoce em 24 horas
O artigo 23.º da Diretiva 2022/2555 comprime a fase inicial da resposta a incidentes em três prazos: 24 horas, 72 horas e um mês. O prazo de 24 horas apanha de surpresa quem gere WordPress, porque começa a contar quando se toma conhecimento do incidente, não quando este fica resolvido. E num site WordPress típico esse conhecimento chega mais depressa por uma mensagem no Slack do que por um painel de SOC.
Este é um artigo de apoio ao pilar sobre NIS2 e DORA em WordPress.
TL;DR
- 24 horas após o conhecimento: alerta precoce ao CSIRT.
- 72 horas após o conhecimento: notificação com avaliação inicial.
- 1 mês após o conhecimento: relatório final com causa e correção.
- O “conhecimento” é o gatilho, não um alerta do SIEM.
- Seis sinais de WordPress que, para mim, significam “o relógio está a contar”.
- Modelos nas línguas nacionais neste playbook.
O que diz exatamente o artigo 23.º
O artigo 23.º, n.º 1, estabelece a obrigação: notificar o CSIRT ou a autoridade competente de qualquer incidente com impacto significativo na prestação de serviços. O artigo 23.º, n.º 3, define “significativo”: suscetível de causar perturbação operacional grave dos serviços ou perda financeira para a entidade, ou danos materiais ou imateriais a outras pessoas singulares ou coletivas.
O artigo 23.º, n.º 4, divide a linha temporal:
- (a) Sem demora injustificada e, em qualquer caso, no prazo de 24 horas após ter tomado conhecimento do incidente significativo: um alerta precoce que indique se há suspeita de que o incidente tenha causa ilícita ou maliciosa e se pode ter impacto transfronteiriço.
- (b) Sem demora injustificada e, em qualquer caso, no prazo de 72 horas: uma notificação que atualize o alerta precoce e inclua uma avaliação inicial da gravidade, do impacto e dos indicadores de comprometimento.
- (c) A pedido do CSIRT ou da autoridade competente: um relatório intercalar sobre a situação.
- (d) No prazo máximo de um mês após a notificação da alínea b): um relatório final com descrição pormenorizada, tipo de ameaça ou causa de raiz, medidas de correção aplicadas e eventual impacto transfronteiriço.
O relógio começa quando se toma conhecimento de um incidente significativo. As orientações da ENISA leem o “conhecimento” como o momento em que uma pessoa qualificada da entidade conclui, com certeza suficiente, que ocorreu um incidente significativo. Isto pesa muito no WordPress, porque o conhecimento costuma chegar por um e-mail de um cliente, por um serviço externo de monitorização ou por um scanner de vulnerabilidades, não por um SOC interno.
Como reconhecer uma intrusão num site WordPress
Estas constatações exigem abrir um registo e avaliar de imediato se o incidente é significativo. Não põem automaticamente a correr o prazo da NIS2. O artigo 23.º aplica-se quando uma entidade abrangida toma conhecimento de que o incidente é significativo segundo as regras aplicáveis.
1. Defacement numa página visível aos clientes. Defacements indexados, página inicial substituída, páginas de produto substituídas. A visibilidade facilita a avaliação da gravidade: o dano à confiança dos clientes é um dado adquirido.
2. Conta de administrador comprometida com início de sessão confirmado. Uma nova conta de administrador, uma conta de administrador existente com inícios de sessão a partir de um intervalo de IP ou de um país invulgar, uma conta de administrador a alterar outras contas. Detetado por plugins de audit log (WP Activity Log, Stream, Wordfence audit log).
3. Instalação de plugin malicioso ou carregamento de tema. Um ficheiro de plugin em wp-content/plugins/ fora do canal normal de atualizações, ou com PHP que chama eval, base64_decode, gzinflate ou assert sobre dados do utilizador. Detetado pela monitorização da integridade de ficheiros ou por uma análise do Wordfence.
4. Injeção na base de dados com escrita confirmada. Uma SQL injection que conseguiu inserir ou alterar linhas. Confirmada por um diff do audit log ou por manipulação em wp_users ou wp_options. Sinal clássico: a opção siteurl passa de repente a apontar para um domínio alheio.
5. Exportação não autorizada de dados pessoais. Uma exportação do WordPress, uma chamada à REST API que devolve a lista de utilizadores, uma resposta grande de wp-json/wp/v2/users a partir de um IP inesperado. O artigo 33.º do RGPD pode aplicar-se em paralelo com o artigo 23.º da NIS2.
6. Ransomware ou cifragem do sistema de ficheiros em produção ou nas cópias de segurança. Ficheiros com extensões novas, .html com nota de resgate nas pastas de uploads, arquivos de backup cifrados. É um sinal de gravidade elevada, mas o âmbito e o caráter significativo continuam a exigir uma decisão documentada.
Para cada uma destas constatações, o runbook da agência diz: registar a hora do conhecimento no ticket de IR, nomear o responsável, pôr a correr o prazo de 24 horas, avisar o CISO da entidade ou equivalente na primeira hora. A agência não notifica o CSIRT; quem notifica é a entidade. A agência fornece o conteúdo técnico.
Modelo de alerta precoce NIS2 em 24 horas
O alerta precoce é curto de propósito. O modelo que entrego à equipa de compliance da entidade:
Entidade: [denominação legal]
Setor: [classificação do Anexo I ou II]
Identificador nacional: [NIPC ou número de registo]
Resumo do incidente
Data e hora do conhecimento: [ISO-8601 com fuso horário]
Origem da deteção: [audit log / comunicação de cliente / scanner externo / aviso do fornecedor de alojamento]
Serviço afetado: [site público WordPress em https://example.com, portal de clientes, etc.]
Classificação inicial
Causa presumida: [maliciosa / acidental / em apuramento]
Impacto transfronteiriço: [sim / não / em apuramento]
Indícios de impacto transfronteiriço: [se sim, o que aponta nesse sentido]
Avaliação inicial do impacto
Disponibilidade do serviço: [operacional / degradada / indisponível]
Acesso confirmado a dados: [nenhum / suspeita / confirmado]
Número de pessoas potencialmente afetadas: [número, se conhecido, caso contrário "em apuramento"]
Primeira resposta
Medidas de contenção: [rotação de credenciais, remoção de plugin, bloqueio de IP, etc.]
Análise forense em curso: [sim / não, com o nome do fornecedor se externo]
Próxima atualização: [hora da notificação de 72 horas ou de um relatório intercalar anterior]
Contacto
Nome e função: [CISO, diretor de TI, etc.]
E-mail e telefone: [linha direta]Isto é o alerta precoce, não a notificação. A notificação de 72 horas acrescenta-lhe a avaliação da gravidade, os indicadores de comprometimento e uma avaliação mais clara do impacto transfronteiriço.
O que contém a notificação de incidente NIS2 às 72 horas
No prazo de 72 horas após o conhecimento, a notificação acrescenta:
- Avaliação da gravidade. Número de utilizadores afetados, distribuição geográfica, estimativa da perda financeira, tempo estimado de recuperação.
- Indicadores de comprometimento. Endereços IP, hashes de ficheiros, URLs, cadeias User-Agent maliciosas, assinaturas de ataque. A ENISA recomenda um esquema; os CSIRT aceitam STIX 2.1 ou uma lista livre.
- Avaliação do impacto transfronteiriço. Confirmado ou excluído, com fundamentação.
- Estado da contenção. O que está controlado e o que continua em aberto.
- Necessidades de cooperação. Se a entidade precisa de apoio do CSIRT ou de outras autoridades.
Em WordPress, o bloco de indicadores contém normalmente: IPs dos atacantes retirados dos access logs, caminhos dos ficheiros maliciosos em wp-content/, hashes desses ficheiros, cadeias User-Agent observadas durante a exploração e o HTTP request body guardado pela WAF.
Que elementos tem de conter o relatório final NIS2 após um incidente?
Artigo 23.º, n.º 4, alínea d): relatório final no prazo máximo de um mês após a notificação. Conteúdo:
- Descrição pormenorizada do incidente.
- Tipo de ameaça ou causa de raiz.
- Medidas de correção aplicadas e em curso.
- Impacto transfronteiriço, quando aplicável.
Nos incidentes em WordPress, a secção da causa costuma ir parar a uma destas: um plugin desatualizado com CVE conhecido, credenciais de administrador fracas sem MFA, um wp-config.php exposto a partir de um ficheiro de backup, RCE através de uma função do tema, comprometimento da cadeia de fornecimento no canal de atualizações, má configuração no servidor. A secção das medidas de correção liga a causa à medida do artigo 21.º, n.º 2 que a deveria ter evitado e atualiza o registo de riscos da entidade.
Onde notificar um incidente NIS2 na Polónia e na UE
Cada Estado-Membro designa pelo menos um CSIRT e uma autoridade competente. A lista atualizada é mantida no portal da ENISA. Os destinos mais frequentes para as entidades com que trabalho:
- Polónia. CSIRT NASK para os setores civis, CSIRT GOV para a administração pública, CSIRT MON para a área da defesa. A autoridade nacional competente depende do setor.
- Alemanha. Bundesamt für Sicherheit in der Informationstechnik (BSI) e CERT-Bund. CSIRT setoriais para finanças (CSIRT BaFin), energia e telecomunicações.
- Espanha. INCIBE-CERT para o setor privado e os cidadãos, CCN-CERT para a administração pública.
- Noruega. Não é membro da UE, mas está alinhada através do EEE; o NSM NCSC recebe notificações dos setores que se harmonizaram voluntariamente.
- Portugal. CERT.PT, sob a alçada do CNCS (Centro Nacional de Cibersegurança).
Para entidades que operam em várias jurisdições, a ENISA mantém uma lista de pontos de contacto únicos (SPOC) para a coordenação transfronteiriça.
Como preparar um plano de resposta a incidentes em WordPress
O prazo de 24 horas é implacável para as entidades que só se preparam depois de tomarem conhecimento do incidente. Antes de qualquer incidente:
- Escala de prevenção com nomes. Duas pessoas, principal e substituta, com os números no runbook de IR.
- Árvore de escalamento até ao CISO da entidade. A agência não envia o alerta precoce; quem o faz é a entidade. Por isso, o caminho entre “a agência vê” e “a entidade decide” tem de demorar menos de uma hora.
- Modelos de comunicação preparados com antecedência. Notificação aos clientes, notificação interna, notificação ao regulador. Os três nas línguas adequadas.
- Capacidade de fazer snapshot da instância WordPress de produção. Antes de qualquer alteração de contenção, preserve o sistema de ficheiros e a base de dados para a análise forense.
- Relação com um fornecedor de análise forense, contratada antecipadamente. A análise forense ao abrigo do artigo 23.º em 72 horas exige um fornecedor que atenda o telefone, não um pedido de orçamento.
- Backup externo em modo imutável. Sem ele, o ransomware pode impossibilitar o relatório final ao destruir as provas.
O preço desta preparação é individual e depende da dimensão do parque WordPress; não é uma linha na fatura do alojamento.
Como fazer a triagem de um incidente WordPress e preservar provas
Perante um sinal credível, a equipa abre um único registo principal do incidente. Anota a observação original, a hora com fuso horário, a origem, o ambiente e a pessoa que conduz o processo. Avalia a autenticidade e o impacto na confidencialidade, integridade e disponibilidade, e só depois se os critérios de incidente significativo podem estar cumpridos. Níveis operacionais como evento, incidente grave e crise organizam os recursos, mas não substituem o artigo 23.º nem a lei nacional. O acesso confirmado, as contas, os componentes, os percursos dos clientes, o tempo, o alcance, os fornecedores e o grau de certeza vão sendo atualizados. O que se desconhece continua assinalado como desconhecido.
A contenção e a preservação de provas correm em paralelo. Antes de reconstruir ou remover código suspeito, e se for seguro fazê-lo, guarda-se um snapshot ou uma cópia dos ficheiros, o estado da base de dados, o identificador do deploy, as sessões, os administradores e os logs. Os originais são preservados, os ficheiros recebem somas de verificação e as cópias de trabalho ficam separadas. Cada alteração, incluindo a rotação de credenciais, regras de WAF, remoção de plugins, restauro e DNS, entra na linha temporal. A segurança tem prioridade quando preservar uma prova prolonga o dano; a falta da prova tem de ser fundamentada.
Ao lado da linha temporal técnica corre um registo cronológico de decisões com factos, pressupostos, alternativas, responsável e data de revisão. A parte técnica, a administração, o jurídico e a privacidade, e a comunicação com os clientes têm fluxos separados, articulados pelo coordenador. A agência entrega os componentes, a hora da deteção, as referências às provas, o estado da contenção, o acesso suspeito e a estimativa de recuperação. A entidade decide e notifica, salvo autorização expressa em contrário.
Como testar o plano de resposta a incidentes
O exercício deve juntar o fornecedor de alojamento, a agência, o líder do incidente, a privacidade e a comunicação. Vai do alerta às provas e à avaliação do caráter significativo, até à passagem ao regulador, à aprovação do restauro e às mensagens aos clientes. Para ser aceite, exige resposta da prevenção, um registo correto, recolha de provas sem acessos improvisados, passagem a quem decide, modelos atualizados, um ponto de restauro limpo e um responsável e um prazo para cada melhoria.
Depois do restauro ficam a linha temporal, o registo de decisões, o índice de provas, as cópias das notificações, a lista de ativos, a análise de causa, a prova do restauro, a comunicação e a verificação das correções. Uma proteção temporária é substituída por um controlo permanente ou por uma decisão formal sobre o risco residual.
Para preparar o plano ou ensaiá-lo, envie uma descrição escrita através da auditoria de conformidade UE para WordPress. Indique a entidade, as jurisdições, os ambientes WordPress, o alojamento, os percursos críticos, o registo de logs, os backups, os contactos, exercícios anteriores e lacunas. Não envie numa primeira fase credenciais, dados pessoais nem provas em bruto do comprometimento. O trabalho melhora a preparação e as provas, mas não é um parecer jurídico, uma garantia nem uma conclusão automática sobre a obrigação de notificar.
