Como Você Constrói um Plano de Resposta a Incidentes que Funciona?

A maioria das organizações não falha em resposta a incidentes porque faltam ferramentas. Falham porque ninguém acordou antecipadamente quem faz o quê, e o primeiro incidente real se torna uma reunião em vez de uma resposta.

Comece pelas fases, não pelo playbook

NIST SP 800-61 delineia quatro fases: preparação, detecção e análise, contenção/erradicação/recuperação, e atividade pós-incidente. Essa ordem importa. Times adoram pular direto para a contenção porque parece produtivo, mas se você não fez o trabalho de preparação, você não conhece sua própria rede bem o suficiente para conter qualquer coisa de forma limpa.

Preparação significa inventários de ativos que são realmente atuais, não a planilha de 2022. Significa conhecer sua janela de retenção de logs (se são 7 dias e o atacante teve 30 dias de permanência, você já perdeu a linha do tempo). Significa ferramentas forenses pré-preparadas — Velociraptor, KAPE, ou até um procedimento documentado tar/dd para imagens de disco — para que ninguém baixe ferramentas em um host comprometido durante um incidente ativo.

Defina níveis de severidade antes de precisar deles

Um SEV1 (exfiltração ativa de dados, detonação de ransomware, comprometimento de domain admin) precisa de uma resposta diferente de um SEV3 (malware isolado em uma estação de trabalho sem privilégios). Escreva isso como uma matriz: impacto vs. escopo vs. confiança. Atribua a cada severidade um tempo de resposta obrigatório e um caminho de escalação. Se seu comandante de incidente para um SEV1 é a mesma pessoa que tem que aprovar cada ordem de compra de $500, você construiu um gargalo no seu próprio processo de emergência.

O papel de comandante de incidente não é opcional

Uma pessoa gerencia o incidente. Não necessariamente o engenheiro mais sênior por padrão — a pessoa mais adequada para coordenar, delegar, e tomar decisões de contenção sob pressão. Essa pessoa não precisa tocar um teclado durante a resposta; ela rastreia a linha do tempo, gerencia comunicação com legal e liderança, e decide quando acionar o isolamento de um segmento ou tirar um sistema do ar.

Sem esse papel, você se vê com cinco pessoas SSH'd no mesmo box, nenhuma falando com a outra, e ninguém capturando memória volátil antes de alguém reiniciar a máquina para "ver se conserta".

Decisões de contenção que realmente importam

A chamada mais difícil na maioria dos incidentes é: isolar agora, ou observar um pouco mais para entender o escopo? Cortar acesso à rede muito cedo alerta um atacante ainda se movendo lateralmente e destrói sua chance de ver o próximo movimento. Esperar muito permite que ransomware termine de criptografar compartilhamentos.

Um meio termo razoável: use segmentação de rede e isolamento EDR (CrowdStrike, Defender for Endpoint, SentinelOne todos suportam isso) para cortar um host do movimento lateral mantendo-o ligado para captura de memória. Desligamento completo deve ser último recurso — mata evidência volátil e, para casos de ransomware, pode desencadear comportamento anti-forense incorporado em alguns payloads.

Lacunas de logging que você vai lamentar durante, não antes

Os padrões do Windows Event Log não são o suficiente. Se você não tem Sysmon implementado com uma configuração decente (as configs de baseline do SwiftOnSecurity ou de Olaf Hartong são um bom ponto de partida), você estará reconstruindo árvores de processo a partir de fragmentos. No lado da rede, logs de NetFlow ou Zeek importam mais do que a maioria das organizações percebe até que precisam responder