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 a notificação das 72 horas: 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. A Diretiva não define esse momento, e o considerando 102 limita-se a repetir os prazos. Este playbook regista o conhecimento quando uma pessoa qualificada da entidade conclui, com certeza suficiente, que ocorreu um incidente significativo, e anota quem o concluiu e com que provas. 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.
Quando um incidente é significativo segundo o Regulamento de Execução 2024/2690
O artigo 23.º, n.º 3, da Diretiva dá o critério geral. Para alguns tipos de entidade, a Comissão concretizou-o. O Regulamento de Execução (UE) 2024/2690 aplica-se 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 centro de dados, aos fornecedores 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 serviços de mercados em linha, de motores de pesquisa em linha e de plataformas de serviços de redes sociais e aos prestadores de serviços de confiança (artigo 1.º). Uma agência WordPress que assegura aos clientes alojamento, manutenção e monitorização pode cair na categoria de prestador de serviços geridos. Se cai ou não depende da classificação segundo os anexos da Diretiva e o direito nacional, não deste playbook.
Para essas entidades, o artigo 3.º, n.º 1, do Regulamento considera significativo um incidente quando se verifica pelo menos um destes critérios:
- uma perda financeira direta superior a 500 000 EUR ou a 5 % do volume de negócios anual total da entidade no exercício anterior, consoante o valor que for mais baixo;
- a exfiltração de segredos comerciais na aceção da Diretiva (UE) 2016/943;
- a morte de uma pessoa singular ou danos consideráveis para a sua saúde;
- um acesso bem-sucedido, presumivelmente malicioso e não autorizado a redes e sistemas de informação, suscetível de causar uma perturbação operacional grave;
- os limiares próprios de cada tipo de entidade dos artigos 5.º a 14.º.
Para os prestadores de serviços geridos e de serviços de segurança geridos, o artigo 10.º fixa esses limiares: o serviço fica totalmente indisponível durante mais de 30 minutos; a disponibilidade fica limitada para mais de 5 % dos seus utilizadores na União, ou para mais de 1 milhão de utilizadores, consoante o número que for menor, durante mais de uma hora; ou a integridade, a confidencialidade ou a autenticidade dos dados relacionados com o serviço ficam comprometidas em resultado de uma ação presumivelmente maliciosa, ou com impacto em mais de 5 % dos utilizadores ou em mais de 1 milhão de utilizadores, consoante o número que for menor.
Duas regras mudam a triagem num parque WordPress. O artigo 3.º, n.º 2, exclui as interrupções programadas do serviço e as consequências previstas da manutenção programada, pelo que uma janela de manutenção anunciada não é um incidente significativo segundo este critério. O artigo 4.º acrescenta os incidentes recorrentes: incidentes que isoladamente não são significativos contam em conjunto como um único incidente significativo quando ocorreram pelo menos duas vezes em seis meses, têm a mesma causa aparente e, em conjunto, cumprem o critério da perda financeira. O ponto 3.4.2, alínea b), do anexo pede uma verificação trimestral desses incidentes. No WordPress, a reinfeção repetida pelo mesmo plugin sem correção é o padrão que essa verificação deve apanhar.
As entidades fora da lista do artigo 1.º continuam a aplicar o critério do artigo 23.º, n.º 3, tal como transposto para o direito nacional.
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. O artigo 23.º, n.º 4, alínea b), pede-os quando estejam disponíveis.
- 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.
O que mais exige o artigo 23.º da NIS2 além dos três relatórios
Os prazos de 24 horas, 72 horas e um mês são o que toda a gente retém. O mesmo artigo contém mais obrigações e uma proteção:
- Incidentes em curso. Segundo o artigo 23.º, n.º 4, alínea e), se o incidente ainda estiver em curso quando o relatório final for devido, a entidade apresenta nesse momento um relatório de progresso e o relatório final no prazo de um mês após concluir o tratamento do incidente.
- A resposta do CSIRT. O artigo 23.º, n.º 5, obriga o CSIRT ou a autoridade competente a responder sem demora injustificada e, se possível, no prazo de 24 horas após a receção do alerta precoce, com uma primeira reação e, a pedido da entidade, orientações sobre medidas de atenuação. Se houver suspeita de natureza criminosa, dá também orientações sobre a comunicação às autoridades policiais.
- Destinatários do serviço. Se for caso disso, a entidade informa sem demora injustificada os destinatários dos seus serviços dos incidentes significativos suscetíveis de afetar a prestação desses serviços (artigo 23.º, n.º 1). Segundo o artigo 23.º, n.º 2, os destinatários potencialmente afetados por uma ciberameaça significativa ficam a saber que medidas ou soluções podem aplicar. Numa loja ou num portal de clientes em WordPress, é a mensagem aos clientes preparada com antecedência.
- Prestadores de serviços de confiança. Em derrogação da alínea b), um prestador de serviços de confiança notifica os incidentes significativos que afetem os seus serviços de confiança no prazo de 24 horas após tomar conhecimento, não de 72.
- Responsabilidade. O artigo 23.º, n.º 1, estabelece que o mero ato de notificação não sujeita a entidade notificante a uma responsabilidade acrescida.
- Informação ao público. Segundo o artigo 23.º, n.º 7, o CSIRT ou a autoridade competente pode, depois de consultar a entidade, informar o público ou exigir que a entidade o faça, quando isso for necessário para prevenir ou gerir o incidente ou quando a divulgação for de interesse público por outra razão.
- Quase incidentes. O artigo 6.º, ponto 5, define-os como eventos que poderiam ter comprometido a disponibilidade, a autenticidade, a integridade ou a confidencialidade de dados ou serviços, mas que foram evitados ou não se concretizaram. O artigo 30.º permite às entidades essenciais e importantes notificar voluntariamente incidentes, ciberameaças e quase incidentes. Uma tentativa de exploração bloqueada contra um plugin de WordPress não é uma notificação obrigatória, mas pode seguir por esse canal.
Onde notificar um incidente NIS2 em Portugal 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:
- Portugal. O Decreto-Lei n.º 125/2025 está em vigor desde abril de 2026. A notificação vai para a autoridade de cibersegurança competente (artigo 40.º do regime), com o CNCS como autoridade nacional de cibersegurança; o CERT.PT coordena a divulgação de vulnerabilidades (artigo 38.º). O regime português prevê notificação inicial até 24 horas, atualização até 72 horas quando necessária, notificação do fim do impacto significativo em 24 horas e relatório final em 30 dias úteis (artigos 42.º a 44.º).
- Alemanha. Bundesamt für Sicherheit in der Informationstechnik (BSI) e CERT-Bund.
- Espanha. INCIBE-CERT para o setor privado e os cidadãos, CCN-CERT para a administração pública.
- Noruega. Não é Estado-Membro da UE. A Diretiva tem como destinatários os Estados-Membros (artigo 46.º), pelo que as obrigações de notificação norueguesas decorrem do direito norueguês; as regras em vigor confirmam-se junto do NSM.
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.
Atualização, . Quando um ataque vai além do seu próprio site, há mais um endereço a ter à mão. A Wordfence lançou a 26 de outubro de 2026 a Threat Response Team, a equipa responsável pelo período entre o primeiro sinal de uma nova ameaça e a estabilização, normalmente as primeiras 72 horas (anúncio da Wordfence). As participações vão para [email protected] em três casos: um plugin ou tema explorado ativamente, um ataque à cadeia de fornecimento, como uma atualização de plugin ou tema adulterada, ou uma campanha contra muitos sites WordPress ao mesmo tempo. A Wordfence pede o que está a observar e desde quando, o plugin ou tema afetado com a versão, indicadores (ficheiros suspeitos, contas de administrador desconhecidas, endereços IP, entradas de registo) e um contacto. São os mesmos dados que recolhe para o alerta precoce do modelo acima, por isso um único pacote de provas serve as duas participações. Endereços IP nos registos são dados pessoais nos termos do RGPD: envie os endereços dos atacantes, não os registos de visitas dos seus clientes. Esta participação não substitui o artigo 23.º: o CERT.PT recebe o alerta precoce em 24 horas, faça o fornecedor de segurança o que fizer.
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.
Requisitos de tratamento de incidentes do Regulamento de Execução 2024/2690
A secção 3 do anexo do Regulamento de Execução 2024/2690 fixa os requisitos de tratamento de incidentes do artigo 21.º, n.º 2, alínea b), da Diretiva para as entidades do seu artigo 1.º. Aplicados a um parque WordPress, estes pontos mudam o trabalho do dia a dia:
- Política de tratamento de incidentes (3.1). Funções, responsabilidades e procedimentos para detetar, analisar, conter, recuperar, documentar e comunicar incidentes, com um sistema de categorização, planos de comunicação para o escalamento e a notificação, e os documentos usados na resposta: manuais, diagramas de escalamento, listas de contactos e modelos (3.1.2). O modelo de alerta precoce acima é um desses documentos. A política é testada e revista a intervalos planeados e após incidentes significativos (3.1.3).
- Registo (3.2.3). Se for caso disso, os registos abrangem a criação, alteração ou eliminação de utilizadores e o alargamento de permissões, os eventos de autenticação, todo o acesso privilegiado e a atividade das contas de administração, e o acesso a ficheiros críticos de configuração e de cópia de segurança ou as suas alterações. Em WordPress: alterações de utilizadores e funções, inícios de sessão de administradores e alterações em
wp-config.php,.htaccesse arquivos de backup. - Registos protegidos (3.2.5). Os registos são conservados durante um período predefinido e protegidos contra acessos ou alterações não autorizados. Um registo que existe apenas no servidor WordPress comprometido pode ser alterado pelo atacante, por isso dificilmente conta como protegido.
- Hora sincronizada (3.2.6). Os sistemas usam fontes de hora sincronizadas para que os registos possam ser correlacionados. Sem isso, a hora do conhecimento no alerta precoce não pode ser confrontada com os registos do servidor web, da WAF e da base de dados.
- Comunicação de eventos (3.3). Um mecanismo simples permite a trabalhadores, fornecedores e clientes comunicar eventos suspeitos, e fornecedores e clientes são informados da sua existência quando for caso disso.
- Resposta (3.5). Contenção, erradicação e recuperação; planos de comunicação com o CSIRT ou a autoridade competente; registo das atividades de resposta com as provas; testes dos procedimentos a intervalos planeados.
- Análise pós-incidente (3.6). Se for caso disso, uma análise após a recuperação identifica a causa de raiz e termina em lições aprendidas documentadas. O relatório final do artigo 23.º, n.º 4, alínea d), e essa análise assentam nas mesmas provas.
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.
