Em resumo: lições aprendidas após um incidente de TI significa: depois da conclusão técnica, todos os envolvidos reúnem-se, reconstroem o decurso, nomeiam sem atribuição de culpas o que correu bem e o que não correu, e daí derivam medidas com responsáveis e prazos. Isto vale também para quase-incidentes, como uma semana de PHP2Shell que acabou sem grandes danos. O decisivo não é a ata, mas o controlo posterior de saber se as medidas foram aplicadas.
Porque é que a semana depois do incidente é tão importante
Quando o servidor volta a funcionar e os patches estão instalados, a tentação de regressar depressa à rotina é grande. É precisamente então que se perde o conhecimento mais valioso: quem reparou em quê e quando? Onde faltou uma informação? Que decisão demorou demasiado? Dentro de algumas semanas, ninguém o sabe com exatidão.
A semana de outubro de 2026 é um bom exemplo. Muitas empresas aplicaram patches a servidores PHP, contactaram fornecedores de alojamento, desligaram sites por precaução ou guardaram registos. Mesmo que não tenha sido detetada nenhuma intrusão, há aqui muito para aprender. Quanto tempo demorou até estar claro que sistemas eram afetados? Quem tinha de aprovar o desligamento e essa pessoa estava contactável?
Os passos técnicos após um ataque propriamente dito trata-os a Lista de verificação após um ataque informático. Este artigo parte daí: o que aprendemos com isto?
Lições aprendidas num incidente de TI: regras básicas para o balanço
Um balanço não é um tribunal. Quem receia que os erros tenham consequências pessoais conta apenas metade da história. Por isso vale o princípio: procuramos causas em procedimentos, ferramentas e informação, não culpados. As pessoas agiram com o conhecimento que tinham naquele momento.
Convide todos os que estiveram envolvidos, incluindo externos como o fornecedor de alojamento, a agência ou prestadores de serviços, na medida do possível. Reserve duas horas. Peça material de antemão: tickets, históricos de conversas, e-mails, notas, extratos de registos. Deles nasce a cronologia, a espinha dorsal da reunião. Como a montar corretamente, descreve-o Criar a cronologia de um incidente.
A moderação não deve ser assumida pela pessoa que conduziu o incidente operacionalmente. De outro modo, avaliaria as suas próprias decisões. É neutra, por exemplo, alguém de outro departamento ou um parceiro externo.
O procedimento em seis passos
- Apresentar a cronologia: o que aconteceu e quando, do primeiro alerta à conclusão? Assinalar as lacunas na cronologia, não adivinhar.
- O que correu bem? Comece conscientemente pelo positivo. Isso mostra o que deve ser mantido e descontrai a ronda.
- Onde falhou? Cada atraso, cada informação em falta, cada incerteza é recolhida, por agora sem discutir soluções.
- Esclarecer as causas: para os pontos mais importantes, pergunte várias vezes porquê. «O patch chegou tarde» é uma constatação, «ninguém sabia que no servidor antigo ainda corre PHP» é uma causa.
- Definir medidas: para cada causa, uma medida concreta, uma pessoa responsável e um prazo.
- Combinar o controlo posterior: uma data dentro de quatro a oito semanas, em que se verifica o que está aplicado.
Perguntas e medidas típicas após uma situação com o PHP
A tabela seguinte mostra perguntas que muitas vezes se colocam após uma situação como o PHP2Shell e possíveis respostas sob a forma de medidas. Nem todas servem a todas as empresas; destina-se a afinar o olhar.
| Pergunta no balanço | Constatação típica | Medida possível |
|---|---|---|
| Como soubemos da vulnerabilidade? | Por acaso, pelas notícias | Subscrever de forma direcionada os alertas de segurança do php.net e do BSI |
| Sabíamos que sistemas eram afetados? | Lista incompleta, sistema antigo esquecido | Inventário de todos os sites e servidores com a versão do PHP |
| Quem podia decidir o desligamento? | Pouco claro, decisão atrasada | Fixar a competência de decisão no plano de emergência |
| O fornecedor de alojamento confirmou o patch? | Só oralmente ou de todo | Pedir confirmação escrita, completar o contrato |
| Todos os processos PHP foram reiniciados? | Não verificado | Incluir o reinício e a verificação como passo fixo |
| Havia registos disponíveis desde 20/10? | Em parte já sobrescritos | Prolongar o período de conservação, guardar registos de forma centralizada |
| Como correu a comunicação interna e externa? | Os colaboradores souberam pela imprensa | Preparar a informação interna inicial |
Registe também o que conscientemente não altera. Por vezes uma constatação é conhecida, mas a medida seria desproporcionada. Uma decisão documentada é melhor do que um esquecimento silencioso.
Separe na ata factos comprovados, suposições prováveis e perguntas em aberto. Precisamente após o PHP2Shell, para o qual não existem Indicators of Compromise publicados e confirmados, esta separação é importante.
Da ata à mudança
O fracasso mais frequente das lições aprendidas é banal: a ata é enviada e depois não acontece nada. Três hábitos ajudam. Primeiro, cada medida pertence ao sistema em que de qualquer modo se trabalha, isto é, o sistema de tickets ou a lista de tarefas, e não a um documento separado. Segundo, o controlo posterior tem uma data fixa na agenda da gerência. Terceiro, os resultados fluem para o plano de emergência, a lista de contactos e os exercícios.
Quem quiser verificar as conclusões sem esperar pelo próximo incidente real pode simulá-las num exercício de emergência à mesa. E onde o balanço mostrar que as atualizações dependeram demasiado do acaso, compensa a reconversão para uma gestão de patches como processo.
Para a proteção de dados, o seguro e, se for o caso, as autoridades, o relatório final é além disso um documento importante. A avaliação jurídica, por exemplo se era necessária uma notificação nos termos do Art. 33 do RGPD, pertence, porém, aos encarregados da proteção de dados ou ao advogado, e não ao balanço técnico.
Como ajuda concretamente a PHP SOS?
- Elaboramos, a partir de registos, tickets e notas, uma cronologia do incidente e assinalamos as lacunas.
- Moderamos o balanço como entidade neutra e cuidamos de que se procurem causas em vez de culpados.
- Traduzimos as constatações técnicas em medidas com estimativa de esforço e prioridade.
- Acompanhamos o controlo posterior e, se desejar, aplicamos nós próprios medidas técnicas, tal como previsto na nossa resposta a incidentes.
Conclusão
Um incidente já é suficientemente caro. Quem não o avalia paga de novo na próxima vez. Um balanço honesto, sem atribuição de culpas, uma cronologia limpa e medidas com nome e prazo fazem de uma semana difícil um ganho duradouro de segurança.
Perguntas frequentes
Quando deve realizar-se a reunião de lições aprendidas?
Quando o incidente está concluído do ponto de vista técnico, mas a memória ainda está fresca. Na prática, revela-se eficaz uma data cerca de uma a duas semanas após a conclusão. Antes, falta muitas vezes distância; mais tarde, os pormenores esbatem-se.
Também se deve fazer um balanço após um quase-incidente?
Compensa. Uma situação como o PHP2Shell, em que no fim nada aconteceu, mostra ainda assim onde os procedimentos falharam. Estas conclusões são especialmente valiosas porque surgiram sem dano.
Quem conduz o balanço?
O ideal é alguém que não tenha conduzido o incidente operacionalmente. Assim a moderação permanece neutra e ninguém tem de defender as suas próprias decisões. Pode ser também um prestador de serviços externo.
O que acontece com os resultados?
Cada conclusão torna-se uma medida com pessoa responsável e prazo. O plano de emergência, a lista de contactos e a documentação são ajustados. Passadas algumas semanas, alguém verifica o que foi efetivamente aplicado.