PEAK Framework (Splunk)

Nota do Capítulo 23, Frameworks e Metodologias Emergentes.
Apresenta o PEAK da Splunk, Platform, Experiences, Analytics e Knowledge, com pré-requisitos de plataforma, as três selvas de hunting experiences, o catálogo de analytics e o knowledge engine, com exemplo de caça organizada no framework.
Dialoga com o Hunt Loop do capítulo 6, com a TaHiTI e o THRIVE desta pasta e com os controles HNT e DAT do capítulo 15.

1. Contexto e Posicionamento na Biblioteca

A maioria dos programas de hunting nasce viciada em um único tipo de caça, normalmente a hipótese derivada de relatório de CTI, e descobre tarde que esse recorte deixa vazios enormes de cobertura. O PEAK, publicado pela Splunk como framework aberto, organiza o hunting em quatro componentes interdependentes, Platform, Experiences, Analytics e Knowledge, e classifica as experiências de caça em famílias que cobrem desde a hipótese clássica até baselines amplas e caças assistidas por modelo. O framework é agnóstico de produto apesar da origem, e a plataforma da Splunk é apenas a materialização mais conhecida das suas exigências.

O posicionamento na biblioteca é o de modelo de portfólio de caça. O Hunt Loop do capítulo 6 descreve o ciclo individual de uma caça, o THRIVE desta pasta ordena a fila, e o PEAK organiza o portfólio inteiro do programa, garantindo mistura adequada entre tipos de caça e sustentando o reaproveitamento do que cada caça produz. A leitura conjunta com a TaHiTI desta pasta mostra dois pontos de vista complementares, um de taxonomia de processo e outro de ecossistema de capacidades.

2. Os Quatro Componentes: Platform, Experiences, Analytics, Knowledge

O PEAK parte de uma tese simples: hunting maduro exige uma plataforma de dados, experiências de caça diversificadas, um catálogo de analytics reutilizáveis e um motor de conhecimento que preserve e dissemine o aprendizado. A ausência de qualquer componente estrangula os demais, e o diagnóstico de um programa doente quase sempre encontra o mesmo padrão, caças produzindo conhecimento que ninguém preserva, ou analytics órfãos que ninguém reexecuta. A tabela a seguir resume o papel de cada componente no ecossistema.

3. Pré-requisitos de Plataforma

O PEAK é explícito ao dizer que hunting começa em plataforma, não em inspiração, e define os pré-requisitos mínimos que viabilizam as experiências. O primeiro é centralização de dados com normalização, porque caça que exige saltar entre dez consoles se transforma em auditoria cansativa e mal replicada, e os controles DAT do capítulo 15 existem exatamente para essa fundação. O segundo é capacidade de consulta expressiva sobre janelas longas, com linguagem de busca que suporte estatística e correlação, como SPL no caso Splunk ou KQL e EQL em plataformas equivalentes, porque baselines exigem comparar períodos e distribuições.

O terceiro pré-requisito é governança de retenção e de qualidade, com janelas de dados suficientes para distinguir sazonalidade de anomalia, e inventário de fontes que diga a verdade sobre lacunas, ligando a plataforma ao controle TH.1 de inventário de dados. O quarto é separação de ambientes e controle de acesso, porque queries de caça são caras e algumas exploram dados sensíveis, e o controle TH.3 do capítulo 15, de ambiente isolado de hunting, cobre essa exigência. Time com tempo protegido completa os pré-requisitos, porque plataforma excelente com hunter sem hora dedicada produz caças de madrugada sem documentação, o antipadrão conhecido.

A checagem de maturidade da plataforma pode ser feita com perguntas objetivas, e o resultado orienta o investimento antes de qualquer promessa de caça em escala. A lista a seguir resume as perguntas mínimas do diagnóstico:

• Existe um lugar único onde a maior parte da telemetria pode ser consultada com linguagem de busca, ou o hunter precisa abrir dez consoles por caça?
• As fontes críticas têm normalização consistente, com nomes de campos estáveis entre sistemas, ou cada caça começa descobrindo o formato dos dados?
• A retenção cobre janelas suficientes para comparar períodos e identificar sazonalidade, ou as caças ficam limitadas a dias?
• O acesso de caça é isolado do acesso operacional, com limites de custo por consulta para proteger a plataforma da carga do hunting?
• Existe inventário honesto do que não é coletado, para que hipóteses inviáveis sejam transformadas em requisitos de coleta e não em frustração silenciosa?

Respostas negativas não bloqueiam o início do programa, porque a primeira caça pode ser uma partial baseline sobre a fonte mais madura disponível, e cada resposta negativa vira requisito de coleta priorizado. O erro é o inverso, prometer portfólio completo de selvas com plataforma que ainda não sustenta baselines, e o PEAK é explícito em colocar Platform antes de Experiences por essa razão.

4. Hunting Experiences e as Três Selvas

A contribuição mais citada do PEAK é a classificação das experiências de caça em três famílias, chamadas de selvas, que juntas cobrem o espectro completo de abordagens. A selva de hypothesis hunts reúne a caça clássica orientada por hipótese derivada de CTI, TTP ou lição de incidente. A selva de model-assisted hunts usa modelos estatísticos ou de aprendizado de máquina como assistente do hunter, e não como substituto, com o humano investigando os desvios que o modelo sinaliza. A selva de baseline hunts constrói e monitora baselines do ambiente, dividida em três tipos com escopos crescentes, conforme a tabela a seguir.

A lição de portfólio do PEAK é que as selvas precisam de mistura deliberada, porque programas puramente de hipótese nunca descobrem o que não procuravam, e programas puramente de baseline afogam em anomalias sem narrativa. Uma distribuição inicial saudável para um time pequeno é a maioria dos ciclos em hypothesis hunts, uma parcela constante em partial e tactical baselines, e strategic baselines anuais ou semestrais, com model-assisted entrando quando a plataforma e o volume de dados suportam manutenção de modelo honesta.

4.1 Escolhendo a selva por objetivo

A escolha da selva parte do objetivo da semana, e não da preferência do hunter, e a tabela a seguir organiza a decisão pelos objetivos mais comuns de um programa real. O objetivo define a selva, a selva define o formato do registro e o formato do registro define o que o knowledge engine vai receber no fim.

O erro comum é escolher a selva pelo apelo técnico do momento, com times talentosos gastando semanas em model-assisted hunts de retorno marginal enquanto nenhum baseline crítico existe, e a tabela acima existe justamente para tirar essa escolha da preferência. A revisão trimestral do portfólio compara a mistura executada com a mistura planejada, e a divergência entre as duas é a métrica de aderência ao PEAK que o programa acompanha junto com os KPIs de hunting do capítulo 11.

5. O Catálogo de Analytics

O catálogo de analytics é a memória técnica do PEAK e transforma cada caça em capital reutilizável. Cada entrada documenta a lógica de detecção ou de busca, a fonte de dados exigida, o que o analytics distingue de ruído, exemplos de resultados benignos e maliciosos, o mapeamento ATT&CK e o estado de validação, seguindo a filosofia das ADS do capítulo 18. O catálogo é versionado em repositório, e a regra de ouro é que nenhum analytics entra no catálogo sem ter rodado em dados reais com resultado documentado, porque analytics teórico é hipótese, não ativo.

O fluxo de trabalho conecta as selvas ao catálogo nas duas direções. Caças de hipótese consomem analytics existentes quando possível e criam novos quando necessário; baselines geram analytics de distribuição que depois alimentam model-assisted hunts; e toda caça encerrada devolve ao catálogo suas consultas refinadas, com os falsos positivos descobertos registrados como documentação. Esse fluxo é a materialização da ponte entre hunting e detecção descrita no capítulo 18, e o PEAK apenas exige que ela seja sistemática, e não ocasional. A entrada de catálogo resultante do baseline tático de acesso a LSASS, usada no exemplo da seção 7, ilustraria o formato mínimo esperado:

id: ANA-2026-0031
nome: baseline de acesso a lsass por processo
selva_origem: tactical baseline
tecnica_attck: T1003.001
fontes_exigidas:
  - telemetria de acesso a processo do EDR
logica: >
  Distribuicao de processos que abrem lsass.exe por host e por horario,
  comparada a janela de 30 dias, com lista de consumidores legitimos
  mantida no campo de contexto.
consumidores_legitimos_conhecidos:
  - agente de EDR
  - agente de backup
  - ferramenta de monitoramento
falsos_positivos_registrados:
  - script de inventario trimestral da TI
estado: validado em producao, uso em model-assisted hunts
dono: equipe de detection engineering

A lista de consumidores legítimos é o campo que dá valor ao analytics de baseline, porque é ele que transforma uma distribuição estatística em entendimento operacional do ambiente, e cada falso positivo descoberto em caça posterior atualiza a lista, mantendo o ativo vivo. O catálogo sem atualização degrada com o tempo, e o dono nomeado na entrada é quem responde pela revisão quando a versão da plataforma ou da fonte muda.

6. O Knowledge Engine

O knowledge engine é o componente menos glamouroso e o mais decisivo do PEAK, e cobre tudo que preserva e dissemina o conhecimento do programa. Ele inclui a documentação de cada caça executada, com hipótese, dados usados, consultas, achados e destino do resultado; o registro de lições sobre o ambiente, como quais serviços legítimos produzem comportamento parecido com técnicas específicas; e a ligação com CTI, documentando quais TTPs foram caçados, com qual resultado e qual lacuna de telemetria permaneceu. O formato do registro é livre, mas o PEAK exige três atributos mínimos, rastreabilidade da caça ao pedido original, reprodutibilidade das consultas e destino explícito do achado, os mesmos três atributos que a nota de documentação de descobertas do capítulo 7 estabelece para o ciclo individual.

A função estratégica do knowledge engine é permitir que o programa sobreviva à rotatividade e provar valor à liderança, porque a soma de caças documentadas, analytics catalogados e lacunas mapeadas é a resposta factual quando alguém pergunta o que o hunting entrega. Programas sem knowledge engine repetem caças, perdem achados e apresentam valor por anedota, o padrão que o PEAK existe para eliminar.

7. Exemplo de Caça Organizada no PEAK

Considere uma model-assisted hunt partindo de um tactical baseline. O time construiu um baseline tático de acesso a LSASS por processo em toda a malha Windows, documentado no catálogo com a lista de consumidores legítimos conhecidos, EDR, agente de backup e ferramenta de monitoramento, e o modelo simples de frequência e horário apontou três desvios na última semana. A consulta central do baseline, em SPL, que alimenta o modelo e depois a investigação dos desvios, segue abaixo.

index=edr event_type="process_access" target_process="lsass.exe"
| bin _span=1h _time
| stats count by host, source_process, _time
| eventstats avg(count) as media_host by host, source_process
| where count > media_host * 3
| lookup process_info process_name OUTPUT categoria_consumidor
| where isnull(categoria_consumidor)

A caça segue a estrutura do framework conforme o registro abaixo.

O exemplo ilustra a economia do PEAK: a caça não nasceu do zero, consumiu baseline e analytics existentes, e devolveu dois ativos ao acervo, uma detecção promovida e um baseline corrigido. É essa circulação, e não a genialidade da consulta individual, que diferencia um programa maduro.

8. Erros Comuns e Pontos de Atenção

Os desvios mais comuns na adoção do PEAK ficam no meio do caminho entre componente e prática, e valem checklist de revisão:

• Tratar PEAK como produto da Splunk e descartar o framework por não usar Splunk, quando o modelo se aplica a qualquer plataforma com os pré-requisitos cumpridos.
• Ignorar baselines por parecerem work de dados e não de segurança, deixando o programa cego ao comportamento normal, exatamente o que sustenta model-assisted hunts.
• Populá-lo de analytics teóricos nunca executados, transformando o catálogo em biblioteca aspiracional que ninguém confia.
• Executar strategic baseline anual sem dividir em etapas, gerando um projeto gigante que nunca termina.
• Registrar caças em mensagens instantâneas e não no knowledge engine, perdendo rastreabilidade e reprodutibilidade.
• Usar modelo estatístico como veredito automático, invertendo a proposta do PEAK de humano investiga e modelo assiste.

O ponto de atenção central é que o PEAK exige investimento em fundação antes de resultados espetaculares, e times que pulam Platform e Knowledge colhem caças isoladas sem acúmulo, o oposto do propósito do framework.

9. Integração com o Restante da Biblioteca

O Hunt Loop e a nota de ciclo de caça do capítulo 6 descrevem o microciclo que o PEAK repete em escala de portfólio, e os controles DAT, TH.1 e TH.3 do capítulo 15 cobrem os pré-requisitos de plataforma que esta nota assumiu. A ponte entre hunting e detecção do capítulo 18 materializa o fluxo entre catálogo de analytics e detecções promovidas, e a nota de documentação de descobertas do capítulo 7 define o registro que o knowledge engine exige.

No capítulo 23, o THRIVE ordena a fila de hypothesis hunts que o PEAK balanceia com as demais selvas, e a TaHiTI fornece a estrutura de fases para cada caça individual, com o OTHF cobrindo a parcela de execução terceirizada, tipicamente baselines rotineiras e model-assisted de manutenção. O exercício de caça do capítulo 16 pode ser conduzido em formato PEAK, exigindo do aluno que classifique a caça, consulte o catálogo e registre o destino do achado.