Segurança Digital

Incident response para times pequenos

Playbooks práticos que funcionam com 5 pessoas

4 de ago. de 2025·Ricardo Coelho

Às duas da manhã um alerta dispara no canal de engenharia: tráfego fora do usual saindo de uma instância que não deveria conversar com o mundo externo. O time tem cinco pessoas, nenhuma de plantão formal, e o fundador responde no WhatsApp perguntando o que fazer. Pra mim, essa cena define o problema real de resposta a incidentes em organizações pequenas: sem SOC, sem CISO e sem turno de madrugada, o relógio regulatório está rodando. A LGPD no artigo 48 exige comunicação à ANPD e aos titulares em prazo razoável, que a própria ANPD fixou em três dias úteis pelo Regulamento de Comunicação de Incidente de 2024. O GDPR fixa setenta e duas horas no artigo 33. O que separa quem cumpre esses prazos de quem explica à autoridade por que não cumpriu é o desenho do playbook, e não o tamanho da equipe.

O IBM Cost of a Data Breach 2024 relata média global de 194 dias pra identificar um incidente e mais 64 pra contê-lo, e esses números descrevem organizações com programa estruturado. Times pequenos que não desenharam resposta operam fora dessa distribuição, e costumam descobrir o incidente só quando um cliente reporta, a conta de cloud estoura ou alguém vê a chave de API num repositório público indexado pelo GitHub. Na minha avaliação, o atraso vem da ausência de convenção sobre quem decide o quê, e não da falta de ferramentas.

O playbook que funciona num time de cinco pessoas tem poucas páginas, nomes próprios em vez de cargos e uma única árvore de decisão visível. Cargos genéricos como "responsável de segurança" ou "coordenador de incidente" assumem uma estrutura que não existe. Nome e telefone da pessoa, com substituto definido e escalonamento pro fundador ou sócio, eliminam a ambiguidade que consome as primeiras horas. O A.5.24 da ISO 27001:2022 trata desse desenho (planejamento e preparação pra gestão de incidentes), e o A.5.25 trata da avaliação e decisão sobre eventos, que é onde os times pequenos mais falham por falta de critério explícito de severidade.

A classificação de severidade é o que separa resposta controlada de pânico, e três níveis bastam. O nível alto cobre incidente que afeta dados pessoais ou sistemas críticos, e exige ativação imediata e contagem do relógio regulatório. O nível médio cobre incidente que afeta a disponibilidade sem exposição de dados, e entra no horário comercial com janela de correção definida. O nível baixo é evento que pede investigação sem impacto confirmado, e entra no backlog. O erro comum é deixar o julgamento pra depois, o que empurra o caso pra categoria mais confortável em vez da correta. A decisão deve ser tomada pela primeira pessoa que vê o alerta, com critério escrito, e revisada em trinta minutos pela segunda pessoa na árvore.

A contenção antecede a investigação, e essa ordem precisa estar escrita. Num time pequeno a tentação é debugar enquanto o atacante ainda tem acesso, até porque a mesma pessoa que responde é a que conhece o sistema. O fluxo correto é outro: revogar credencial suspeita e isolar a instância comprometida, rotacionando chaves no perímetro afetado antes de começar a entender o que aconteceu. Investigação com acesso ainda ativo contamina evidência e estende exposição. A contenção agressiva derruba serviço legítimo por alguns minutos, enquanto investigar antes de conter é medido em registros exfiltrados por segundo.

A evidência precisa ser preservada antes de qualquer ação corretiva que a apague. Isso significa snapshot do volume antes de reiniciar a instância, exportação dos logs do CloudTrail pra bucket com retenção imutável e captura do estado das sessões ativas com hash dos artefatos suspeitos. Times pequenos costumam destruir evidência na primeira hora por instinto de restaurar o serviço, e depois descobrem que não conseguem reportar à ANPD o que foi acessado porque o log rotacionou. O A.5.28 da ISO 27001 trata da coleta de evidência, e a implementação mínima é automação que preserve estado antes de qualquer remediação tocar o recurso afetado.

A comunicação externa sob a LGPD é onde a engenharia encontra o jurídico, e num time pequeno essa fronteira costuma ser a mesma pessoa. O playbook precisa conter template de comunicação à ANPD com os campos obrigatórios do regulamento e decisão prévia sobre quem assina. Redigir o comunicado do zero sob a pressão do prazo consome o tempo que deveria estar sendo usado na contenção. Das organizações que auditei, as que cumpriram o prazo tinham o template pronto, e as que não cumpriram estavam escrevendo o primeiro parágrafo no segundo dia.

O exercício de mesa trimestral, de noventa minutos e cenário curto, é o que mantém o playbook vivo. Simular um vazamento de credencial em produção e cronometrar a árvore de decisão mostra quanto tempo o time leva pra isolar o recurso e quem assume a comunicação externa. Playbook não exercitado é ficção organizacional: existe no documento e não existe no comportamento do time sob estresse. O A.5.27 trata do aprendizado a partir de incidentes, e o exercício de mesa é a forma mais barata de gerá-lo sem depender de incidente real.

Na minha análise, resposta viável num time pequeno depende da compressão da decisão antes de qualquer sofisticação de ferramenta: menos opções no momento do alerta e mais automação na preservação da evidência, com papéis nominais em vez de cargos. A ausência da estrutura operacional das grandes organizações se compensa por redução deliberada de variáveis no momento da crise, nunca por heroísmo.