Criação de manuais de procedimentos

Um fluxo de resposta é um fluxo de trabalho codificado: um conjunto ordenado e ramificado de etapas que a plataforma SOAR executa quando é acionado. Ele é a versão executável de um manual de procedimentos que antes ficava em um wiki.

Enquanto um manual de procedimentos diz consulte a reputação do IP, um fluxo de resposta chama de fato a API de reputação, analisa o resultado e ramifica o fluxo com base na pontuação. Projetar bem os fluxos de resposta é a habilidade central da engenharia de automação em um SOC.

Nunca projete um fluxo de resposta de forma abstrata. Comece documentando como os analistas realmente lidam com the alerta hoje, passo a passo, incluindo as decisões que tomam e os dados que verificam.

Mapeie cada etapa para uma destas três categorias:

• Ação determinística — a mesma entrada sempre produz a mesma saída (segura para automatizar).
• Enriquecimento — coleta dados, sem efeitos colaterais (seguro para automatizar).
• Julgamento — exige contexto ou responsabilização (mantenha a participação humana).

Todo fluxo de resposta precisa de um acionamento preciso. Se for amplo demais, será acionado por ruído; se for restrito demais, deixará de detectar casos reais.

Os acionamentos geralmente se vinculam a uma regra de correlação do SIEM, a uma categoria de detecção do EDR ou a um veredito de gateway de e-mail. Defina explicitamente a condição de entrada.

Um fluxo de resposta opera sobre artefatos: os indicadores extraídos do evento de acionamento, como IPs, hashes de arquivos, contas de usuário, URLs e nomes de máquinas.

Um bom projeto normaliza esses elementos em um objeto de contexto consistente logo no início, para que cada etapa posterior faça referência aos mesmos nomes de campos, independentemente de qual ferramenta produziu o evento.

• Extraia os artefatos uma vez, no início.
• Valide os tipos (isto é realmente um IPv4 válido?).
• Transporte um contexto compartilhado por todo the fluxo.

Os fluxos de trabalho reais se ramificam. Depois do enriquecimento, você decide um caminho com base em the evidências. Mantenha as ramificações explícitas e abrangentes para que nenhum evento fique sem tratamento.

Insira uma etapa de aprovação humana antes de qualquer ação destrutiva, irreversível ou de grande raio de impacto. O fluxo de resposta reúne the evidências, apresenta-as e bloqueia a execução até que uma decisão chegue.

Projete a etapa para que um tempo limite tenha um padrão seguro. Para contenção, um tempo limite sem resposta pode encaminhar o caso a um engenheiro de plantão, em vez de prosseguir silenciosamente ou descartar the caso sem aviso.

• Desativar contas: exige aprovação.
• Bloquear sub-redes grandes: exige aprovação.
• Enriquecer um indicador: não exige aprovação.

As integrações falham. As APIs impõem limites de requisições, excedem o tempo limite e retornam dados malformados. Um procedimento que presume que toda chamada seja bem-sucedida deixará os incidentes processados apenas pela metade.

Inclua:

• Novas tentativas com espera progressiva para erros transitórios (HTTP 429, 503).
• Padrões seguros em caso de falha — se o enriquecimento falhar, o padrão deve ser encaminhar o caso para uma pessoa, não fechá-lo automaticamente.
• Tratamento de eventos não processáveis — encaminhe eventos impossíveis de processar para uma fila que um analista possa revisar.

Um procedimento pode ser executado duas vezes para o mesmo evento devido a alertas duplicados ou novas tentativas. As ações devem ser idempotentes: executá-las duas vezes não deve causar dano adicional.

Isolar um host que já está isolado deve não fazer nada, e não gerar um erro. Ao abrir um chamado, verifique primeiro se já existe um chamado com a mesma chave de deduplicação.

Evite criar um único procedimento enorme para cada tipo de incidente. Divida-o em subprocedimentos reutilizáveis: um subprocedimento de enriquecimento, um de contenção e um de notificação.

Isso segue os princípios de um bom projeto de software. Um bloco reutilizável de enriquecimento de IP, chamado pelos procedimentos de phishing, força bruta e C2, oferece um único lugar para fazer correções quando a API de inteligência sobre ameaças mudar.

Execute novos procedimentos primeiro no modo de execução simulada: execute o enriquecimento e o registro, mas substitua as ações destrutivas por simulações. Compare a ação proposta pelo procedimento com o que os analistas teriam feito em casos históricos.

Somente depois que a lógica de decisão se mostrar correta em incidentes reais passados deverá habilitar as ações reais; mesmo assim, comece com uma etapa de aprovação para cada ação.

Os procedimentos são código e merecem a mesma disciplina. Mantenha-os sob controle de versões para que toda alteração seja revisada, rastreável e reversível.

• Um registro de alterações responde à pergunta por que este procedimento se comportou de forma diferente no mês passado?
• A revisão por pares identifica lógicas perigosas antes que elas cheguem à produção.
• Documentar o gatilho pretendido, as decisões e o responsável mantém o procedimento fácil de manter à medida que a equipe muda.

Um procedimento sem documentação que ninguém entende se torna um risco no momento em que falha.

Aplique os princípios de projeto de procedimentos a um cenário de falha.

Fundamentos do projeto de procedimentos:

• Um procedimento é um fluxo de resposta executável e ramificado; projete-o a partir do processo manual real.
• Classifique as etapas como ação determinística, enriquecimento ou julgamento; submeta o julgamento à aprovação humana.
• Defina gatilhos precisos, normalize os artefatos em um contexto compartilhado e torne as ramificações exaustivas.
• Trate os erros com novas tentativas e padrões seguros; um enriquecimento que falha deve encaminhar o caso para uma pessoa, e não fechá-lo automaticamente.
• Torne as ações idempotentes, mantenha os procedimentos modulares com subprocedimentos reutilizáveis e teste-os em modo de execução simulada com base em incidentes históricos antes de colocá-los em produção.