Preparação e Definição de Escopo

Nota 01 do capítulo 07 (Processo e Metodologias de Hunting), abrindo o ciclo operacional da caça antes da primeira consulta ser escrita.
Define o que prepara uma caça: inventário de dados, janela temporal, sistemas em escopo, autorização formal, escopo realista, critérios de sucesso e de parada e riscos operacionais.
Consome os controles de preparação do capítulo 15 e alimenta as notas 02 a 06, que executam hipóteses, coleta, análise, relato e automação.

1. Contexto e Posicionamento na Biblioteca

A diferença entre uma caça que produz achados e uma caça que produz apenas horas de consulta improdutiva quase sempre se decide antes da primeira linha de KQL ser escrita. A preparação determina quais dados estão realmente disponíveis, qual janela temporal pode ser investigada com qualidade, quais sistemas podem ser tocados e sob qual autorização. Sem essa base, o hunter descobre no meio da execução que a fonte não cobre o período investigado, que a consulta estoura o custo do cluster ou que ninguém aprovou formalmente o acesso à telemetria de recursos humanos. Esta nota abre o processo do capítulo 07 e estabelece o contrato operacional que as cinco notas seguintes pressupõem cumprido.

Na biblioteca, a nota consome os controles de preparação do grupo HNT do capítulo 15, em especial o inventário de dados disponíveis para hunting e o estabelecimento de baselines, que fornecem a matéria-prima documental aqui transformada em plano. Dialoga com os tipos de hunting do capítulo 06, porque o escopo muda de forma conforme a caça seja orientada por hipótese, por inteligência ou exploratória. À frente, o template de plano de caça desta nota é o artefato que a geração de hipóteses da nota 02 preenche e que a execução de análises da nota 04 consome linha por linha.

2. O Que Prepara uma Caça: Dados, Janela, Sistemas e Autorização

Toda caça parte de quatro condições prévias, e a ausência de qualquer uma delas compromete as demais. Dados: o inventário de fontes deve dizer não apenas quais existem, mas qual é a retenção real, qual a cobertura de hosts e identidades, qual o grau de normalização e qual a latência de ingestão. Janela temporal: o período investigável precisa ser compatível com a cadência do adversário de interesse, já que caçar uma técnica de movimento lateral com 7 dias de proxy, quando o dwell time típico do setor passa de semanas, limita a caça antes de ela começar. Sistemas: o conjunto de ativos em escopo deve refletir os crown jewels da organização, e não apenas a conveniência de quem escreve a consulta.

Quinta condição frequentemente tratada como acréscimo, a baseline de referência decide a qualidade do julgamento durante a execução. Caçar sem saber o que é normal transforma cada resultado em pergunta aberta, porque o hunter não distingue raridade de novidade. A baseline não precisa ser sofisticada no início: contagens de logon por conta, listas de processos comuns por tipo de servidor e mapas de comunicação entre ativos já permitem decidir se o que apareceu é exceção ou rotina. O controle de baselines do capítulo 15 fornece o ponto de partida, e o plano de caça deve declarar qual baseline será usada como referência de comparação.

A autorização é a condição mais negligenciada e a mais cara de ignorar. A caça consulta dados de pessoas, inclui ambientes de produção e, em caças de resposta, pode disparar ações em endpoints; por isso exige aprovação documentada, com o dono do ambiente ciente, limites de acesso a dados pessoais alinhados à LGPD e registro em auditoria de quem executou o quê. A autorização tem validade: uma caça aprovada por três dias não pode ser retomada semanas depois sem renovação, porque o contexto do ambiente e do negócio muda. A tabela abaixo resume as quatro condições com o produto verificável de cada uma, no formato exigido no plano de caça da seção 7.

A ordem das condições importa menos que a completura, mas a experiência de operações reais mostra um padrão. Dados e sistemas são os limites objetivos que ninguém negocia, autorização é o limite processual que se resolve com fluxo, e baseline é o limite analítico que se constrói com o tempo. Por isso a preparação de um programa jovem tende a produzir caças de refutação e de lacuna, e não de achado, e isso é sinal de saúde, e não de fracasso, porque é assim que a operação aprende o que precisa coletar.

3. Definição de Escopo Realista

Escopo realista é aquele que cabe na janela de tempo do hunter e nas fontes efetivamente disponíveis. A regra prática da biblioteca é uma caça por vez: uma hipótese central, um conjunto fechado de fontes, uma janela temporal declarada e um teto de esforço, tipicamente entre 4 e 16 horas para caças pontuais. Escopos que tentam cobrir simultaneamente várias técnicas do ATT&CK, todos os sites e todo o período de retenção não terminam, porque o volume de resultados cresce mais rápido que a capacidade de triagem do hunter. O escopo existe para ser respeitado, e não para decorar um documento.

Escopo declarado também é escopo comunicado. O plano em status aprovado circula para o dono do ambiente e para o turno do SOC, com resumo de uma linha sobre o que será consultado e quando, porque consultas pesadas e acessos incomuns geram alertas de segurança da informação que precisam de contexto antecipado. A comunicação prévia evita que a própria caça seja investigada como atividade suspeita, um desencontro mais comum do que parece em ambientes com monitoramento maduro de uso de plataforma.

O escopo se declara em quatro dimensões complementares, e a tabela abaixo traz o exemplo e a armadilha típica de cada uma. A dimensão de técnica ancora a caça no MITRE ATT&CK; a de ativos restringe o conjunto de hosts e identidades; a de dados delimita fontes e campos; a de tempo fixa início e fim. Ao declarar as quatro dimensões, o hunter ganha um critério objetivo para recusar desvios de rota durante a execução, o que não impede bifurcações, apenas exige que elas sejam registradas como novas hipóteses no backlog, conforme a nota 04.

4. Critérios de Sucesso e Critérios de Parada

Critério de sucesso é a resposta à pergunta: o que precisa ser verdade ao final para esta caça valer o investimento? A resposta não é apenas encontrar um adversário, porque caças legítimas terminam sem achado e ainda assim produzem valor: a hipótese refutada com evidência, a lacuna de coleta documentada, o baseline atualizado e a detecção candidata são resultados válidos. O que não é resultado válido é a caça encerrada sem registro, porque ela não pode ser repetida, auditada ou convertida em detecção, e o mesmo terreno tende a ser recaçado de forma improvisada por outro analista.

Critério de parada é a resposta à pergunta: sob quais condições eu interrompo a execução mesmo sem esgotar a hipótese? Paradas legítimas incluem o esforço atingir o teto declarado no plano, o custo de consulta ameaçar a disponibilidade do ambiente, o volume de falsos positivos superar a capacidade de triagem da sessão e a hipótese ser refutada pela evidência disponível. Diferenciar sucesso de parada evita os dois vícios opostos: a caça que se estende indefinidamente por perfeccionismo e a caça abandonada silenciosamente por frustração. A tabela abaixo operacionaliza os dois conjuntos de critérios.

Os critérios só funcionam quando combinados antes da execução, e não impostos depois. A prática recomendada é aprovar sucesso e parada em revisão em pares, com o revisor assinando o plano, porque decisão registrada antes da pressão vale mais que decisão idealizada depois do fato. Critérios combinados também protegem a relação com a gestão: quando a caça encerra por teto, o plano mostra que a interrupção foi prevista e aceita, e não um fracasso improvisado.

5. Riscos Operacionais: Impacto em Produção e Consultas Pesadas

O maior risco técnico da execução é a consulta pesada contra ambiente de produção compartilhado com o SOC. Os padrões perigosos são conhecidos e evitáveis: varredura sem filtro temporal sobre índices grandes, expressões regulares abertas sobre campos de texto livre, junções sem chave restritiva, agregações sobre a retenção completa e inspeções de arquivo disparadas em massa pelo próprio motor de busca. Cada um desses padrões já degradou plataformas reais, e a defesa começa no plano de caça, com teto de custo por consulta e regra de iniciar sempre pela janela mais estreita antes de expandir.

A disciplina de escrita da consulta reduz a maior parte do risco sem sacrificar a busca. O bloco abaixo contrasta uma formulação pesada e uma formulação disciplinada da mesma hipótese em KQL, com filtro temporal primeiro, filtros seletivos antes da projeção e saída delimitada.

// Formulação pesada: sem janela, regex aberta, agregação sobre tudo
DeviceProcessEvents
| where ProcessCommandLine matches regex @"(?i).*(enc|b64|http|exec).*"
| summarize count() by DeviceName

// Formulação disciplinada: janela estreita, filtros seletivos, saída delimitada
DeviceProcessEvents
| where Timestamp > datetime(2025-05-01) and Timestamp < datetime(2025-05-08)
| where FileName =~ "powershell.exe"
| where InitiatingProcessParentFileName !in~ ("explorer.exe", "svchost.exe")
| where ProcessCommandLine has_any ("-enc", "FromBase64String")
| project Timestamp, DeviceName, AccountName, ProcessCommandLine
| take 500

Além do custo de consulta, a caça tem riscos de manuseio de dados. Exportações com informação pessoal, capturas de pacote com credenciais e cópias de memória exigem tratamento conforme a classificação da informação, com destino controlado, acesso restrito e prazo de eliminação. A própria caça deve deixar rastro auditável, porque o acesso amplo que o hunter tem à telemetria é exatamente o tipo de acesso que a organização precisa conseguir revisar depois, e um plano sem auditoria de execução falha nesse teste. O conjunto mínimo de salvaguardas operacionais cabe em quatro itens:

• Janela inicial estreita com expansão gradual, e nunca o inverso, porque o custo cresce de forma não linear com o período varrido.
• Execução em ambiente espelho ou em janela de menor carga quando a consulta é pesada, com migração de volta documentada.
• Teto de custo por consulta declarado no plano e monitorado na plataforma, com alerta ao hunter quando metade for consumida.
• Log de auditoria da própria caça, com usuário, horário e consultas executadas, disponível para revisão posterior.

6. Checklist de Prontidão para Execução

A checklist abaixo é o teste de prontidão que antecede a mudança de status da caça para aprovada. Ela não substitui o plano, apenas verifica se o plano está completo, e a caça só entra em execução com os nove itens confirmados pelo hunter e pelo revisor.

• Hipótese central declarada em SE-ENTÃO e registrada no backlog com proveniência documentada.
• Fontes confirmadas por amostragem, com retenção real verificada para a janela planejada.
• Ativos em escopo listados com dono e criticidade, e donos notificados quando a caça toca seus ambientes.
• Autorização registrada com validade cobrindo a janela planejada da execução.
• Baseline de referência disponível e citada no plano.
• Tetos de esforço e de custo por consulta declarados e aceitos pela plataforma.
• Critérios de sucesso e de parada aprovados em revisão em pares.
• Consultas do pacote já versionadas no repositório, com execução de teste em janela curta.
• Ambiente de execução definido, com preferência por espelho quando a caça toca produção sensível.

7. Template de Plano de Caça

O plano de caça é o artefato que amarra preparação e execução, e o template abaixo é o padrão da biblioteca. Ele cabe em uma página, preenche-se em cerca de 30 minutos quando o inventário de dados está em dia e serve de cabeçalho do relato final da nota 05. Campos entre colchetes são preenchidos por caça, e nenhum campo é opcional, porque cada um corresponde a uma decisão que a execução vai exigir sob pressão.

# Plano de Caça: [identificador curto, ex. HUNT-2025-014]

- Data de criação: [data] | Hunter responsável: [nome] | Revisão: [nome]
- Status: [backlog / aprovada / em execução / encerrada]
- Autorização: [referência ao registro de aprovação, com data e validade]

## Objetivo e hipótese central
- Hipótese (SE-ENTÃO): [SE o adversário usar X, ENTÃO Y será observado em Z]
- Fonte da hipótese: [intel / incidente / anomalia / lacuna de detecção]

## Escopo
- Técnica ATT&CK: [ID e nome] | Ativos: [conjunto] | Fontes: [lista]
- Janela temporal: [início a fim, justificada pela retenção real]
- Teto de esforço: [horas] | Teto de custo por consulta: [segundos ou unidades]

## Critérios de sucesso e de parada
- Sucesso: [achado / refutação com evidência / lacuna documentada / detecção candidata]
- Parada: [teto de tempo / teto de custo / saturação de falsos positivos / refutação]

## Riscos e mitigação
- [risco previsto]: [mitigação, ex. janela estreita, ambiente espelho, aprovação extra]

## Resultado (preencher na nota 05)
- Achado: [descrição ou nenhum] | Evidência: [referências às consultas e capturas]
- Desdobramentos: [detecção candidata / requisito de coleta / nova hipótese]

8. Erros Comuns e Pontos de Atenção

O erro mais frequente é começar pela consulta em vez de começar pelo plano, o que produz caças sem critério de parada e sem registro recuperável. O segundo é confiar no inventário nominal de fontes sem testar a cobertura real, porque fontes cadastradas com cobertura de 100% frequentemente não cobrem servidores recém-integrados, filiais ou contas de serviço. O terceiro é ignorar a autorização formal sob pressão de prazo, um risco que se transforma em problema de conformidade exatamente quando a caça encontra dados sensíveis de pessoas e o acesso precisa ser justificado.

Um erro sutil merece destaque: definir sucesso apenas como presença de achado positivo, o que alimenta o viés de confirmação e penaliza a refutação honesta. Programas maduros celebram refutações bem documentadas tanto quanto achados, porque refutação reduz incerteza e retroalimenta a matriz de cobertura de detecção. O plano de caça existe, em última análise, para proteger o hunter dessas pressões, dando à caça um contrato que pode ser mostrado à gestão quando alguém perguntar por que dez horas foram gastas sem encontrar nada.

Um quarto erro é definir escopo a partir da ferramenta disponível, e não da pergunta: a caça vira aquilo que a plataforma favorita consegue responder, e não o que a hipótese exige. Quando a pergunta correta precisa de fonte que a operação não tem, o resultado honesto do planejamento é um requisito de coleta, e não uma consulta improvisada sobre dados incorretos. Reconhecer essa limitação cedo economiza horas e protege a credibilidade do programa, porque caça mal instrumentada produz refutações falsas com aparência de rigor.

9. Integração com o Restante da Biblioteca

Esta nota é a porta de entrada do processo do capítulo 07 e se conecta diretamente com a nota 02, que preenche o campo de hipótese do template com formulação SE-ENTÃO priorizada por custo e valor. A nota 03 resolve as lacunas de coleta que o plano expõe, e a nota 04 executa a caça respeitando os tetos aqui declarados, com documentação em tempo real. O resultado da execução volta para a nota 05, que converte o plano preenchido em relato de descobertas, e para a nota 06, que decide se a caça vira rotina automatizada.

Para fora do capítulo, o plano de caça consome o inventário de dados do controle TH.1 e as baselines do TH.2 do capítulo 15, e o par de critérios de sucesso e parada alimenta os KPIs de hunting medidos no mesmo capítulo. A disciplina de autorização dialoga com a governança e o ciclo de vida de dados do capítulo 02, e a conversão de achados em detecções desemboca no capítulo 18, fechando o ciclo de melhoria contínua que transforma preparação bem feita em capacidade permanente de detecção.