SOAR Security Orchestration, Automation and Response.

O que o SOAR acrescenta acima do SIEM

Security Orchestration, Automation and Response é a camada de ação que fica por trás da deteção. Um SIEM é bom a recolher registos, correlacioná-los e gerar alertas, mas para no alerta. O SOAR continua a partir daí e faz o trabalho que de outra forma um analista faria à mão: enriquece o alerta com pesquisas de reputação e contexto dos ativos, decide o seu grau de urgência, abre ou atualiza um ticket e, onde a política permite, toma medidas de contenção como isolar um host, desativar uma conta ou bloquear um indicador na firewall. A unidade de trabalho num SOAR é o playbook, uma sequência de passos codificada que transforma um procedimento repetível de tratamento de incidentes em algo que a plataforma pode executar sozinha.

A orquestração e a automação são duas ideias distintas que o acrónimo agrupa. A orquestração é a cablagem: ligar o SIEM, o EDR, o sistema de ticketing, o fornecedor de identidade, os feeds de threat intelligence e a firewall para que possam trocar dados e comandos entre si através de uma única consola. A automação é o que corre através dessa cablagem sem intervenção humana. A maioria das equipas maduras mantém um ponto de aprovação humana nos passos destrutivos, de modo que a plataforma enriquece e triagem automaticamente, mas espera que um analista confirme antes de pôr em quarentena um servidor de produção. Essa mistura, o trabalho fastidioso automatizado com o juízo humano nas ações de maior consequência, é o que os profissionais realmente implementam.

SIEM, SOAR e o SOC

Estes três termos andam juntos e são fáceis de confundir. Não são produtos concorrentes. Descrevem funções diferentes dentro da mesma operação de deteção e resposta.

Leia-o como um pipeline. O SIEM encontra o sinal, o SOAR faz o trabalho de resposta repetível em torno desse sinal, e o SOC são as pessoas que são donas de todo o ciclo e tratam de tudo o que os playbooks não conseguem. O valor mais claro do SOAR está no volume: relatórios de phishing, alertas de malware comum, inícios de sessão suspeitos. Tudo o que chega em massa e segue um padrão de tratamento previsível é candidato a um playbook, que é de onde vem a redução do tempo médio de resposta e a razão pela qual os analistas deixam de passar o turno a fazer enriquecimento por copiar e colar.

Por que os projetos SOAR têm êxito ou falham

A shortDefinition é direta sobre a armadilha, e corresponde ao que se vê no terreno: um SOAR só vale o que valem os playbooks que escreve e mantém, e a maioria dos projetos SOAR falhados ficou sem autores de playbooks. A plataforma vem com conectores e um motor de fluxos de trabalho, mas vem sem qualquer conhecimento do seu ambiente. Cada playbook tem de ser concebido, construído, testado contra alertas reais e depois mantido à medida que as suas ferramentas, a sua rede e os seus atacantes mudam. Um playbook que chama uma API descontinuada no trimestre passado é pior do que nenhum playbook, porque falha silenciosamente a meio de um incidente.

Do ponto de vista da governança, o SOAR é a forma como vários objetivos de controlo deixam de ser aspiracionais. No âmbito de um sistema de gestão da segurança da informação ISO/IEC 27001, apoia o lado técnico da gestão de incidentes, do registo e da monitorização, e produz um registo coerente e com marca temporal de como cada incidente foi tratado, que é exatamente a evidência que um auditor quer. Também sustenta a capacidade de resposta que o NIST Cybersecurity Framework pressupõe e que regulamentos como NIS2 e DORA esperam que as organizações mantenham, em particular em torno do tratamento e da notificação atempados de incidentes significativos. Trate o SOAR como um multiplicador de força para um processo que funciona, não como um substituto de ter um.