Automação do SOC: checklist do CISO para SOAR e playbooks

Automatizar o SOC não é comprar uma plataforma SOAR e ligar todos os playbooks de uma vez. É decidir, com critério, quais decisões a máquina pode tomar sozinha, quais precisam de um humano e quem responde quando algo dá errado. Este checklist organiza essa decisão para o CISO: o que automatizar primeiro, como definir níveis de autonomia, como combinar a contenção com o negócio e como provar que a automação está funcionando.

Por que automatizar e por onde começar

O argumento central é tempo. A NIST SP 800-61 Rev. 3, publicada em abril de 2025, reorganizou as recomendações de resposta a incidentes em torno das funções do NIST CSF 2.0 e trata a resposta como parte da gestão de risco, não como um evento isolado. Detectar e conter mais rápido reduz o impacto, e a automação ajuda nisso. O ganho real, porém, vem de tirar do analista o trabalho repetitivo para que ele dedique tempo ao que exige julgamento, como explicamos em SOC tradicional x SOC moderno.

A regra prática para escolher o primeiro alvo: comece pelo que é frequente, padronizado e de baixo risco se der errado. Deixe para depois o que é raro, ambíguo ou capaz de parar a operação.

Enriquecimento de alertas. Consultar reputação de IP, domínio e hash, dono e criticidade do ativo, histórico do usuário e técnica do MITRE ATT&CK associada. É só leitura: não altera nada no ambiente.
Triagem. Agrupar alertas duplicados, descartar padrões já confirmados como falso positivo e ajustar a prioridade conforme a criticidade do ativo. Exige regras documentadas e revisão periódica.
Abertura e roteamento de casos. Criar o caso no sistema de chamados com as evidências já anexadas e encaminhar para a fila certa, com o prazo certo. Elimina a passagem informal entre quem detecta e quem age.
Contenção de baixo risco. Ações reversíveis e de alcance limitado: bloquear um indicador já confirmado como malicioso, colocar um e-mail de phishing em quarentena, forçar a troca de senha de uma conta comum, isolar uma estação de usuário pelo EDR.

Playbooks SOAR e níveis de autonomia

Playbook é a sequência documentada de passos para um tipo de caso: o que coletar, o que verificar, quando escalar e o que executar. Antes de virar automação, ele precisa existir no papel e funcionar na mão. A CISA publicou playbooks de resposta a incidentes e vulnerabilidades para órgãos federais americanos que servem de modelo de estrutura, e o padrão aberto CACAO, da OASIS, define um formato para descrever playbooks de segurança de forma que possam ser compartilhados e executados por diferentes ferramentas.

Cada ação de um playbook deve ter um nível de autonomia explícito. Uma escala simples, de quatro degraus:

Só notificar. A automação detecta, enriquece e avisa. Nenhuma ação no ambiente.
Sugerir. A automação propõe a ação, com a justificativa e as evidências. O analista decide e executa.
Executar com aprovação. A ação está pronta; um humano autorizado aprova com um clique e a plataforma executa e registra.
Executar. A plataforma age sozinha e avisa depois. Reservado a ações pré-aprovadas, reversíveis e já testadas.

Um playbook novo deve começar nos degraus mais baixos e subir só depois de um período de observação em que as sugestões se mostraram corretas. A mesma ação pode ter níveis diferentes conforme o alvo: isolar a estação de um colaborador pode ser automático; isolar um servidor de pagamentos, nunca sem aprovação.

Pré-aprovação da contenção com o negócio

A pior hora para discutir se o SOC pode derrubar a conta de um diretor é durante o incidente. Essa conversa precisa acontecer antes, com as áreas de negócio, e virar documento.

Matriz de ações por ativo. Para cada classe de ativo (estações, servidores, contas comuns, contas privilegiadas, sistemas críticos), quais ações estão pré-aprovadas e em qual nível de autonomia.
Lista de exceções. Ativos e contas que nunca sofrem ação automática, como sistemas de produção sensíveis e contas de serviço que sustentam processos críticos. Para contas privilegiadas, veja também gestão de acessos privilegiados.
Donos e aprovadores. Quem aprova cada tipo de ação, com substitutos e contatos para fora do horário comercial.
Critérios de comunicação. Quem é avisado depois de uma ação automática e por qual canal.

Contenção também tem custo. Isolar um servidor por engano para a operação. A pré-aprovação existe para equilibrar o risco do ataque com o risco da própria resposta, e essa decisão é do negócio, não só da segurança.

Testes e rollback

Automação errada erra em escala. Antes de subir um playbook de nível, confirme:

Teste em ambiente controlado. Rodar o playbook contra casos reais anteriores ou em laboratório antes de produção.
Rollback documentado e testado. Toda ação de contenção precisa de um caminho de volta conhecido: desbloquear, reativar, retirar do isolamento.
Limites de segurança. Teto de ações por janela de tempo (por exemplo, nunca isolar mais de um número definido de máquinas sem aprovação humana) para evitar que um erro de regra vire incidente.
Revisão a cada mudança. Atualizações de ferramentas, APIs e regras de detecção podem quebrar um playbook silenciosamente. Inclua os playbooks na gestão de mudanças.

Métricas que mostram se a automação funciona

MTTR. Tempo da detecção até a contenção. Compare os casos tratados com e sem automação, por tipo de incidente.
Percentual de casos automatizados. Quantos casos foram resolvidos total ou parcialmente por playbook. Não é meta em si: automatizar o caso errado só acelera o erro.
Falsos positivos. Taxa de falsos positivos que chegam ao analista e, principalmente, ações automáticas executadas sobre algo legítimo. Este segundo número deve ser acompanhado caso a caso.
Reversões. Quantas ações automáticas precisaram de rollback e por quê.

Governança e trilha de auditoria

Cada ação automática precisa responder às mesmas perguntas que uma ação humana: o que foi feito, quando, em qual ativo, com base em qual evidência, por qual playbook e versão, e quem aprovou. Na prática:

Registro imutável. Logs das execuções guardados fora do alcance de quem opera a plataforma.
Versionamento de playbooks. Histórico de alterações, com autor, revisor e data.
Contas de serviço com privilégio mínimo. A plataforma SOAR tem acesso a firewall, EDR e diretório; ela própria é um alvo e precisa de credenciais protegidas e monitoradas.
Revisão periódica. Comitê ou dono formal que revisa níveis de autonomia, exceções e métricas, alinhado à função Govern do CSF 2.0.

Erros comuns

Automatizar processo que não existe. Se o playbook manual não está claro, a automação só cristaliza a confusão.
Começar pela contenção. Pular enriquecimento e triagem e ir direto para bloqueios automáticos é o caminho mais rápido para perder a confiança do negócio.
Pré-aprovação informal. "Combinamos por e-mail" não protege ninguém no dia da crise.
Sem dono do playbook. Playbook sem responsável fica desatualizado e falha justamente quando é necessário.

Na prática: automação com validação humana

No SOC da Network Secure, a plataforma Open-XDR faz triagem, enriquecimento com Threat Intelligence e contenção automática, e o analista valida, investiga o que é crítico e ajusta as regras. Saiba mais sobre o serviço de SOC e MDR e como ele se conecta ao seu plano de resposta a incidentes.

Perguntas frequentes

O que é SOAR?

SOAR (Security Orchestration, Automation and Response) é a categoria de ferramenta que integra as soluções de segurança e executa playbooks. O valor depende dos playbooks e da governança, não só da ferramenta.

A automação substitui os analistas do SOC?

Não. Ela absorve tarefas repetitivas e padronizadas. Investigação de casos ambíguos, decisões com impacto no negócio e melhoria das detecções continuam exigindo pessoas.

Quais ações de contenção podem ser totalmente automáticas?

As que são reversíveis, de alcance limitado, foram pré-aprovadas pelo negócio e testadas, como quarentena de e-mail malicioso ou isolamento de estação de usuário. Ações sobre sistemas críticos e contas privilegiadas devem exigir aprovação humana.

Como saber se a automação está funcionando?

Acompanhe o MTTR por tipo de caso, os falsos positivos e as ações automáticas que precisaram de rollback.

Fontes consultadas: NIST SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile (abril de 2025); NIST Cybersecurity Framework 2.0 (CSWP 29), função Govern; CISA, Federal Government Cybersecurity Incident and Vulnerability Response Playbooks; OASIS, CACAO Security Playbooks Version 2.0; MITRE ATT&CK e MITRE D3FEND. A escala de níveis de autonomia é uma proposta prática deste artigo, não uma classificação de norma. Este artigo é educacional e não substitui a avaliação do seu ambiente e dos seus processos de resposta.