Em resumo: um exercício tabletop de TI simula um incidente de segurança à mesa: uma moderação fornece, passo a passo, novas informações sobre a situação, os envolvidos decidem como numa emergência e, no fim, há uma lista de melhorias concretas. Para servidores web, um cenário no modelo do PHP2Shell é adequado, porque toca ao mesmo tempo na técnica, em decisões sob incerteza, na proteção de dados e na comunicação.
Porque é que um plano só funciona depois de treinado
Muitas empresas têm hoje um plano de emergência. Se funciona, só se vê quando alguém o usa sob pressão de tempo. O número de telefone certo consta dele? A gerência sabe que tem de decidir sobre um desligamento? O prestador de serviços conhece os acessos? Perguntas destas esclarece-as um exercício à mesa em poucas horas.
A semana de outubro de 2026 demonstrou com que rapidez uma situação pode escalar: aviso prévio do php.net a 20/10, patches a 21/10 às 16:00 (hora da Alemanha), nível de alerta laranja do BSI (Gabinete Federal Alemão para a Segurança da Informação), desligamento de sites públicos segundo notícias dos media. Quem tinha treinado esta sequência uma vez teve de improvisar menos. O decurso em pormenor descreve-o a Cronologia do PHP2Shell. Como montar o próprio plano, vê-se em Criar um plano de emergência de TI para servidores web; aqui trata-se de treinar.
Exercício tabletop de TI: papéis e preparação
Um bom exercício precisa de pouco material, mas de papéis claros. A moderação conduz o guião, introduz as informações e controla o tempo. Não discute, faz perguntas. Um registo anota decisões, perguntas em aberto e cada ponto em que alguém diz «isso agora não saberia». Opcionalmente, outra pessoa observa como decorre a comunicação.
Os participantes são as pessoas que, numa emergência, agem de facto: gerência, TI interna ou prestador de serviços externo, encarregados da proteção de dados, comunicação e, se necessário, compras ou departamento jurídico. É importante que haja substitutos presentes, pois os incidentes não respeitam os planos de férias.
Fazem parte da preparação: o plano de emergência atual em papel, a lista de contactos, uma visão geral dos sites e servidores e uma sala sem interrupções. Defina de antemão que se trata de aprender, não de classificações. Quem tem medo de fazer má figura não diz o que não sabe.
Um guião pronto: vulnerabilidade crítica do PHP numa sexta-feira à tarde
O cenário seguinte é fictício, mas inspira-se no modelo de uma situação real. Ajuste sistemas e nomes ao seu ambiente. Cada injeção tem dez a vinte minutos de discussão.
| Passo | Injeção da moderação | Pergunta orientadora à ronda |
|---|---|---|
| 1 | A imprensa especializada comunica uma vulnerabilidade crítica no PHP, os patches estão anunciados, mas ainda não chegaram. | Quem sabe primeiro e quem tem de ser informado? |
| 2 | Os patches aparecem à tarde. O BSI recomenda atualização imediata, caso contrário desligamento temporário. | Quais dos nossos sistemas são afetados e como o sabemos? |
| 3 | O fornecedor de alojamento não responde. Um servidor próprio corre uma versão do PHP sem atualização oficial. | Aplicar patch, desligar ou esperar, e quem decide? |
| 4 | A loja deve fazer uma campanha ao fim de semana. As vendas insistem em não desligar nada. | Como ponderamos faturação e risco e como documentamos a decisão? |
| 5 | Na segunda-feira, um administrador encontra um ficheiro PHP desconhecido na pasta de uploads. | O que fazemos primeiro, o que deixamos conscientemente por fazer? Quem preserva as provas? |
| 6 | Não é claro se houve fuga de dados de clientes. | Quem avalia uma possível obrigação de notificação e quando corre o prazo? |
| 7 | Uma jornalista pergunta por que o site está offline. | Quem fala para o exterior e o que dizemos enquanto sabemos pouco? |
O passo 6 toca no RGPD. No exercício basta esclarecer o procedimento: quem envolve os encarregados da proteção de dados e quando. A avaliação jurídica fica com especialistas; os traços gerais do prazo constam do Art. 33 do RGPD.
Conclusões típicas e como as registar
Certas lacunas surgem em quase todos os primeiros exercícios. Falta uma lista completa de quais sites correm em quais servidores com que versão do PHP. Os dados de contacto do fornecedor de alojamento estão desatualizados ou guardados apenas numa caixa de correio que numa emergência não é acessível. Ninguém sabe ao certo se a gerência pode ordenar ela própria um desligamento ou se alguém tem de dar o acordo.
Registe cada conclusão em três partes: o que constatámos, o que vamos alterar e quem o faz até quando. Uma conclusão sem responsável fica, segundo a experiência, por fazer. Ordene os pontos por impacto: um número de emergência em falta resolve-se depressa e ajuda de imediato, uma nova solução de monitorização precisa de planeamento.
Para a avaliação estruturada depois do exercício, serve o mesmo procedimento que após um incidente real. Está descrito no artigo Lições aprendidas: melhorar após o incidente. A lista de contactos, que no exercício costuma mostrar fragilidades, trata-a Contactos de emergência: quem deve ser informado e quando?.
Repita o exercício ao fim de seis a doze meses com um cenário diferente, por exemplo um site invadido com redirecionamento para páginas alheias. Assim verifica se as medidas da primeira ronda foram realmente aplicadas.
Como ajuda concretamente a PHP SOS?
- Ajustamos o guião aos seus sites, servidores e prestadores de serviços reais e preparamos as injeções.
- Moderamos o exercício à distância ou por videoconferência e contemos as avaliações até a ronda ter decidido.
- Entregamos depois um registo com conclusões, medidas, responsáveis e prazos.
- Se o desejar, treinamos a seguir a parte técnica, isto é, levantamento da situação, patch e busca de vestígios, tal como a nossa resposta a incidentes a executa numa emergência.
Conclusão
Um exercício de emergência à mesa é a forma mais económica de encontrar as fragilidades de um plano de emergência antes de um incidente real o fazer. Uma tarde, um guião realista e uma avaliação honesta chegam para começar. O decisivo é que cada conclusão se torne uma tarefa com nome e data.
Perguntas frequentes
O que é um exercício tabletop?
Um exercício em que os envolvidos discutem em conjunto um incidente à mesa, sem trabalhar em sistemas reais. Uma moderação introduz passo a passo novas informações, o grupo decide e fundamenta. Assim tornam-se visíveis lacunas no plano, nas responsabilidades e nas listas de contactos.
Quem deve participar num exercício de emergência?
Todos os que, numa emergência, decidem ou agem: gerência, TI ou prestador de serviços, proteção de dados, comunicação e, se existir, a pessoa responsável pelas questões de seguros. Mais de oito a dez pessoas tornam a ronda pesada.
Quanto tempo dura um exercício tabletop?
Para uma primeira ronda bastam duas a três horas, incluindo a avaliação. Mais importante do que a duração é que os resultados fiquem registados e que as medidas sejam atribuídas com prazo.
O cenário tem de ser realista?
Deve ajustar-se ao seu ambiente, mas não precisa de estar certo até ao pormenor. Um cenário no modelo de uma situação real como o PHP2Shell é credível e orienta a discussão para as decisões em vez de pormenores técnicos.