Durante um incidente, velocidade importa e incerteza é alta. IA pode comprimir evidência e preparar ações, mas a autoridade de recuperação deve permanecer com pessoas que entendem impacto, telemetria incompleta e as consequências de errar.
A NIST SP 800-61 Revisão 3 posiciona incident response dentro das funções do CSF 2.0 e enfatiza preparação, detecção, resposta, recuperação e melhoria contínua. IA pode acelerar esse ciclo: correlacionar alertas, resumir logs, montar timelines, sugerir queries, mapear comportamento ao MITRE ATT&CK, preparar comunicação e abrir PRs de remediação.
Ela não deve inventar fatos, alterar evidência silenciosamente ou receber autoridade ampla porque há urgência. O incident commander controla severidade, prioridades, tradeoffs de contenção, comunicação, critérios de recuperação e encerramento. Todo output da IA é hipótese ou proposta até ser sustentado por evidência citada e aceito pela política.
Uma transcrição de chat não é runbook. Modele estados, transições, evidência exigida, papéis, timeouts, aprovações, comandos, rollback e critérios como dados estruturados. O OASIS CACAO oferece schema e taxonomia para playbooks automatizados; OpenC2 oferece linguagem independente de fornecedor para comandos de defesa. Ambos informam a implementação sem remover responsabilidade humana.
O atacante pode controlar command lines, filenames, HTTP, emails, chats, texto de repositório e documentos coletados. Trate tudo como evidência, não instrução ao modelo. Delimite conteúdo, remova markup ativo, bloqueie tool calls derivados diretamente da evidência e exija IDs imutáveis para cada afirmação factual.
Mantenha o modelo de investigação separado das credenciais de execução. Uma linha maliciosa no log não pode pedir revogação de tokens, firewall ou exportação. A execução recebe apenas comandos tipados produzidos por uma transição aprovada.
| Classe | Exemplos | Papel da IA | Aprovação e verificação |
|---|---|---|---|
| Enriquecimento read-only | Consultar SIEM, EDR, audit logs, inventário, grafo de identidade e threat intelligence. | Pode executar automaticamente dentro dos limites do caso, tenant, tempo e dados. | Registre query, escopo, fontes, hash do resultado, custo e acesso. |
| Preservação de evidência | Estender retenção, snapshot, exportar dados voláteis, preservar mailbox ou versões. | Propõe e executa perfis de baixo risco pré-aprovados. | Verifique chain of custody, destino, criptografia, completude e política legal. |
| Contenção estreita e reversível | Revogar uma sessão, isolar endpoint, desativar key, bloquear indicador temporariamente. | Gera comando exato e preview; executa somente dentro de política explícita. | Aprovação do analista ou regra emergencial; verifique estado e rollback token. |
| Contenção ampla | Desativar IdP, bloquear região, rotacionar segredos compartilhados ou isolar rede. | Apresenta alternativas, dependências, serviços afetados e resposta provável do atacante. | Incident commander e service owner; execução gradual e pós-condições contínuas. |
| Mudança de remediação | Patch, IAM, detecção, infraestrutura ou remoção de persistência. | Abre branch ou PR assinado com evidência, testes e rollback. | Revisão normal, checks, política de deploy e canário. |
| Recuperação | Restaurar serviço, reativar usuários, reconectar sistemas ou remover bloqueios. | Prepara checklist e monitora estado limpo; nunca declara sucesso sozinha. | Owner de recuperação aprova critérios; automação restaura gradualmente. |
O modelo pode ter alta confiança em explicação de baixa severidade ou baixa confiança em evento catastrófico. Não converta confiança diretamente em ação. Rastreie força da evidência, confiança da hipótese, severidade, impacto, urgência, reversibilidade e autoridade separadamente.
Mantenha hipóteses concorrentes visíveis. Pergunte qual evidência falsificaria cada uma e qual telemetria falta. Isso reduz confirmation bias e impede que uma narrativa bem escrita encerre cedo a investigação.
Quando a IA rascunhar código, infraestrutura, IAM ou detecções, deve abrir PR em vez de ignorar deployment controls. Inclua incident ID, evidência, assets, testes, efeito esperado, rollback e proveniência. Protected branches e reviews continuam ativos, salvo break-glass separado e governado.
Regras Sigma expressam detecções portáveis; data sources e técnicas ATT&CK documentam cobertura. Regras geradas ainda precisam de validação em dados benignos e maliciosos. Sintaxe válida não garante baixo ruído nem cobertura.
Defina hipótese de estado limpo e pós-condições: sem sessões do atacante, raízes de identidade confiáveis, entrada corrigida, observabilidade restaurada, dependências saudáveis, erro e latência aceitáveis e ausência de recorrência. Restaure em etapas pequenas e mantenha contenção pronta.
O assistente monitora sinais e compara thresholds, mas a pessoa responsável pelo serviço autoriza restauração. “Nenhum alerta” não prova recuperação quando a coleta pode estar quebrada.
Eu construiria um orquestrador de incidentes event-sourced. Ele armazenaria referências de evidência, fatos normalizados, hipóteses, estado do runbook, papéis, aprovações, comandos tipados, receipts, pós-condições, comunicação e PRs sob um incident ID.
A interface separaria fatos de inferências, mostraria evidência ausente, exibiria a autoridade exata antes de ações e permitiria replay completo de decisões de contenção e recuperação.
IA deve reduzir o tempo entre evidência e decisão bem formada, não remover o dono da decisão. Preserve evidência, estruture incerteza, vincule comandos a transições aprovadas, mantenha controles de engenharia e trate recuperação como julgamento humano verificado.
Artigo sobre runbooks assistidos por IA com triagem baseada em evidência, contenção e recuperação aprovadas, PRs de remediação e execução reproduzível.