Splunk (SPL, ES, SOAR)

Nota da subpasta 02 - Plataformas de Detecção e Resposta, no Capítulo 24 (Ferramentas e Plataformas Atualizadas).
Trata do Splunk como plataforma de detecção e caça: SPL, Enterprise Security com o CIM, Splunk Security Content e SOAR com playbooks, com as diferenças de uso para hunting e para alerta.
Dialoga com as notas de Elastic Security e Wazuh da mesma pasta, com a nota de consultas e linguagens do Capítulo 09 e com o controle AUT.1 de orquestração com SOAR do Capítulo 15.

1. Contexto e Posicionamento na Biblioteca

O Splunk permanece como referência de mercado em plataformas de busca sobre dados de máquina, e o ecossistema de segurança construído sobre ele é o mais denso da indústria. Para o programa de CTI-TH, a plataforma entrega três camadas distintas que esta nota separa com clareza: a linguagem SPL como ferramenta universal de caça sobre qualquer índice, o Enterprise Security (ES) como camada de detecção estruturada sobre o Common Information Model (CIM) e o Splunk SOAR como motor de playbooks de resposta. A confusão entre essas camadas é a causa mais comum de desenho ruim, por exemplo tentar caçar dentro do ES sem tocar o índice cru, ou automatizar resposta antes de ter detecção calibrada.

A comparação com Elastic Security e Wazuh da mesma pasta posiciona o Splunk como o investimento de maior custo e maior ecossistema: licenciamento por volume de ingestão, content pack de detecções público e integração profunda com SOAR. A leitura recomendada acompanha o fluxo real do time: caça no índice cru com SPL, descoberta vira regra no ES sobre o CIM, alerta vira notable, notable vira playbook no SOAR, e o resultado alimenta as métricas do Capítulo 16.

2. SPL como Linguagem de Caça

A SPL é uma linguagem de pipeline: cada comando recebe a tabela do anterior, transforma e repassa, e essa estrutura conversacional é o que a torna ideal para caça, onde a pergunta muda a cada passo. O hunter começa amplo, filtra, agrega, enriquece com lookup e refina a hipótese em minutos, sem precisar de dashboard pronto. Os comandos que concentram o dia a dia de caça são poucos e vale dominá-los com profundidade: index e sourcetype para escopo, where e match para condições, stats e eventstats para agregação, transaction para sessões, lookup para enriquecimento e tstats para velocidade sobre data models.

A família de agregação merece estudo separado porque cada membro responde a uma pergunta diferente. O stats colapsa eventos em linhas de resumo e fecha quase toda caixa de caça; o eventstats devolve o resultado da agregação a cada evento original, permitindo comparar o evento contra a média do grupo sem perder o detalhe; o streamstats calcula sobre janelas incrementais na ordem da busca, o que habilita intervalo entre eventos, soma acumulada e contagem em sequência sem subconsulta; o transaction agrupa eventos em sessões por campos e limites de tempo, reconstruindo a narrativa executada pelo adversário. A prática madura usa os três primeiros para medir e reserva o transaction para reconstrução exploratória de sessão, porque é o comando de maior custo do pipeline.

O exemplo a seguir materializa uma caça clássica do capítulo de emulação: processo ofimático criando tarefa agendada, com enriquecimento por criticidade do host e filtro por volume anômalo por usuário. O desenho da consulta segue a disciplina do Capítulo 07, com escopo declarado e saída agregada.

index=sysmon EventCode=1
| where match(Image, "(?i)schtasks\.exe")
    AND match(ParentImage, "(?i)winword|excel|wscript")
| stats count dc(host) as hosts_afetados
    values(CommandLine) as linhas_comando
    by User, host, ParentImage
| lookup criticidade_hosts host OUTPUT nivel
| eval prioridade=case(count >= 3, "alta",
                      nivel == "critico", "alta",
                      true(), "media")
| sort - prioridade, - count

A caça de canal de comando e controle exercita os comandos incrementais em cadeia, e o bloco abaixo mede o intervalo entre conexões de cada combinação de host, destino e porta para isolar periodicidade com baixa variância, assinatura de beacon com jitter curto. O streamstats com current=false captura o timestamp do evento anterior na mesma partição, o eval calcula o intervalo em segundos e o stats final condensa a métrica por grupo. O filtro final cruza com lookup de reputação para destacar destinos que o feed ainda não conhece, exatamente os de maior interesse.

index=sysmon EventCode=3 earliest=-24h
| sort host, _time
| streamstats current=false window=1 global=false
    last(_time) as t_prev by host, dest_ip, dest_port
| eval intervalo_s = _time - t_prev
| stats count avg(intervalo_s) as media_s
    stdev(intervalo_s) as desvio_s
    sum(bytes_out) as upload by host, dest_ip, dest_port
| where count >= 20 AND media_s < 120 AND desvio_s < 5
| lookup reputacao_ip ip AS dest_ip OUTPUT verdict
| where isnull(verdict) OR verdict == "desconhecido"

O transaction entra quando a pergunta exige narrativa e não métrica: reconstruir a sequência em um host entre a criação do processo e a conexão de saída. O comando agrupa por campos declarados, com limites de duração e de pausa, e devolve eventos multivalorados com a duração calculada, mas cada agrupamento consome memória proporcional ao volume da busca, motivo pelo qual ele permanece na caça e fora das regras de produção.

index=sysmon EventCode IN (1, 3) earliest=-24h
| transaction host maxspan=10m maxpause=120s
    startswith="EventCode=1" endswith="EventCode=3"
| where mvcount(EventCode) > 2 AND duration < 600
| table _time host duration EventCode Image dest_ip dest_port
| sort - duration

Duas práticas separam caça amadora de caça profissional em SPL. A primeira é escopo temporal e de índice explícito desde o primeiro comando, porque varredura sem janela custa licença e tempo. A segunda é salvar toda consulta de caça como artefato versionado com contexto, na lógica da nota de documentação de descobertas do Capítulo 07, para que a caça seja reexecutável e vire regra quando a hipótese se confirmar.

3. Enterprise Security e o CIM

O Enterprise Security estrutura a detecção sobre o Common Information Model, um dicionário de data models que padroniza campos entre fontes: Endpoint.Processes, Authentication, Network Traffic, Web, Email e outros. Correlation searches, as regras de detecção do ES, consultam data models acelerados via tstats, o que muda a economia da detecção: consulta sobre resumo acelerado custa uma fração da consulta sobre índice cru. O preço é a disciplina de alimentar o CIM: toda fonte nova precisa de addon que mapeie para o modelo, e a nota de normalização do Capítulo 02 descreve o mesmo problema em termos gerais.

A consulta abaixo mostra o padrão de detecção sobre data model, equivalente em lógica à caça da seção 2, porém executada sobre resumo acelerado com custo por ordem de grandeza menor. O mesmo conteúdo existe nas duas formas, e a decisão de qual usar é de custo e cadência, não de capacidade.

| tstats summariesonly=true count
    from datamodel=Endpoint.Processes
    where Processes.process_name="schtasks.exe"
      AND Processes.parent_process_name IN ("winword.exe", "excel.exe")
    by _time span=5m, Processes.dest, Processes.user, Processes.process
| rename Processes.* as *
| table _time dest user process count

O Enterprise Security também entrega o Risk-Based Alerting, que acumula risco por entidade em vez de alertar por evento isolado, e a nota de resposta a incidentes do Capítulo 15 discute o desenho de risco por entidade em detalhe. Para CTI-TH, o RBA é o mecanismo natural para incorporar a priorização da inteligência: técnicas observadas em campanhas ativas do setor ganham peso maior no índice de risco, alinhando o motor de alerta à fila de ameaças reais.

Na prática, o desenho do RBA começa pela escolha do risk object, o ativo ou identidade que acumula pontos, e pela definição dos pesos por regra e por técnica, calibrados com o volume real medido no ambiente. A nota de risco que acompanha o alerta lista os pontos somados, as regras que contribuíram e a técnica ATT&CK de cada uma, e essa transparência é o que permite ao analista julgar o alerta em vez de confiar em número cego. O ajuste é contínuo, porque pesos altos demais inflam o índice e produzem fadiga, enquanto pesos baixos demais deixam cadeias reais abaixo do limiar de alerta.

4. Splunk Security Content

O Splunk Security Content é o repositório público de detecções, analytic stories e baseline searches mantido pela Splunk e pela comunidade, e é o ativo que mais diferencia o ecossistema Splunk para o time de detecção. As detecções chegam em formato Sigma-conformante com mapeamento ATT&CK, nota de investigação e testes, e os analytic stories agrupam detecções por campanha ou técnica, com contexto de inteligência sobre como o adversário opera. A integração com o pipeline de DaC do Capítulo 18 é direta: as detecções podem ser versionadas, convertidas e testadas como qualquer regra própria.

A rotina recomendada é trimestral: revisar as detecções novas do repositório contra a cobertura de dados da organização, importar as que aplicam, medir volume por duas semanas e ajustar. O mesmo gabarito de revisão vale para os stories ligados às campanhas monitoradas pela CTI, porque o story traz junto a narrativa que alimenta hipóteses de caça do Capítulo 06.

Vale também tratar o repositório como referência de qualidade para as regras próprias, e não apenas como fonte de importação. O padrão das detecções públicas, com teste de unidade, explicação de falsos positivos e dados falsos para validação, é o gabarito que a engenharia de detecção interna deve imitar, e a ausência desses três elementos em regra própria é sinal de que ela ainda não é confiável para produção.

5. SOAR e Playbooks

O Splunk SOAR automatiza a resposta com playbooks que consomem alertas, enriquecem com integrações e executam ações nos controles, sempre com a decisão humana no ponto certo. O desenho maduro separa playbook de enriquecimento, que roda automático para todo alerta, de playbook de contenção, que exige aprovação ou limiar de confiança alto, na mesma fronteira discutida na nota de Wazuh sobre resposta ativa. A tabela de etapas abaixo descreve um playbook de triagem para o notable da regra ofimática das seções anteriores.

playbook: triage-notable-ofimatico-schtasks
gatilho: notable com rule_name "Ofimatico criando tarefa agendada"
etapas:
  - enriquecer com assets e identities do ES
  - consultar historico do usuario e criticidade do ativo
  - coletar linha de comando, hash e caminho do binario agendado
  - consultar reputacao do hash em sandbox e na TIP
  - classificar: verdadeiro, falso positivo justificado ou pendencia
  - verdadeiro: abrir caso e propor isolamento do host para aprovacao
  - falso positivo: documentar criterio e abrir ajuste de regra via PR
saida: comentario no notable, status atualizado e metrica de tempo por etapa

A fronteira com a TIP da pasta 01 deste capítulo merece decisão documentada: o SOAR consome a inteligência, e não a mantém, então reputação e contexto vêm da TIP por integração, e o SOAR registra o uso. A métrica de tempo por etapa do playbook alimenta os KPIs de automação do Capítulo 16 e prova o valor da plataforma em linguagem de orçamento.

6. Exemplo Completo de Consulta de Caça

O exemplo a seguir acompanha uma caça do relatório de inteligência à regra candidata, para fixar a disciplina descrita nas seções anteriores em um caso único. O relatório da semana descreve campanhas de ransomware que baixam ferramenta de administração remota legítima por script de plataforma pública e conectam a destino novo, e a hipótese de caça é que a cadeia deixa assinatura em dois elos: binário criado em diretório gravável por processo de script e conexão de saída nova na mesma janela de minutos. O plano declara escopo de 30 dias no índice de endpoint, e a primeira consulta elimina ruído nos hosts com criticidade conhecida.

index=sysmon EventCode=1 earliest=-30d
    ParentImage IN ("*powershell.exe", "*wscript.exe", "*mshta.exe")
    Image IN ("*\\AppData\\*", "*\\Temp\\*", "*\\ProgramData\\*")
| bin _time span=10m
| stats values(Image) as binarios count as execucoes
    by _time, host, User
| lookup criticidade_hosts host OUTPUT nivel
| where nivel == "critico" OR execucoes >= 3
| table _time host User binarios execucoes nivel

A segunda consulta cruza os dois elos na mesma janela de dez minutos por host, sem subconsulta e sem transaction, porque a agregação por janela resolve a correlação temporal com custo menor. O filtro exige os dois tipos de evento no mesmo intervalo, e os destinos conhecidos ficam de fora após o lookup de reputação, que anula o veredito já classificado. O resultado é a lista de hosts onde script criou binário e houve conexão de saída nova, com os destinos listados para julgamento humano.

index=sysmon earliest=-30d EventCode IN (1, 3)
| bin _time span=10m
| stats values(Image) as binarios values(dest_ip) as destinos
    dc(EventCode) as tipos_evento by _time, host
| where tipos_evento == 2
| mvexpand destinos
| lookup reputacao_ip ip AS destinos OUTPUT verdict
| where isnull(verdict)
| table _time host binarios destinos

A interpretação segue a ficha da rodada de caça: cada linha vira hipótese a validar no host, com triagem da linha de comando e do destino, e a ausência de resultado em 30 dias também é resultado, porque fecha a hipótese com data e escopo. Quando o padrão se confirma, a lógica migra para o padrão tstats sobre o CIM descrito na seção 3, com limiar e lista de exceção ajustados nas duas primeiras semanas em modo sombra. O artefato de caça versionado referencia a regra que nasceu dele, e a regra referencia o relatório de inteligência que motivou a caça, fechando a cadeia de proveniência.

7. Hunting versus Alerta: Diferenças de Uso

As duas funções usam a mesma plataforma com economias opostas, e a tabela fixa as diferenças que o time precisa internalizar para não gastar mal a licença.

A implicação prática é que caça e detecção se alimentam em ciclo: a caça roda no índice cru porque precisa de todos os campos, e quando a hipótese se confirma, a regra correspondente nasce no CIM para rodar barata para sempre. O time que deixa as consultas de caça virarem regras perde o retorno do investimento em hunting, e o time que só opera regras não descobre o que nenhuma regra cobre, lacuna exatamente descrita na ponte hunting-to-detection do Capítulo 18.

8. Erros Comuns e Pontos de Atenção

• Caçar sobre data models acelerados e perder campos que o addon não mapeou; a caça começa no índice cru, e o CIM entra quando a lógica está estável.
• Rodar detecções sobre índice cru sem aceleração, transformando cada agenda em custo de licença e latência; o data model é a economia do alerta.
• Importar detecções do Security Content sem medir volume sobre os dados reais, acumulando regras silenciosas ou explosivas; meça por duas semanas antes de confiar.
• Deixar notables sem playbook e sem dono, acumulando fila; um notable sem rota de fechamento é ruído com etiqueta.
• Automatizar contenção no SOAR com limiar baixo, bloqueando ativos críticos por engano; contenção automática exige confiança alta e aprovação registrada.
• Ignorar o custo de ingestão no licenciamento, comprando fontes sem desenho de retenção e filtro; o desenho de dados precede o de detecção, como no Elastic.
• Misturar consulta de caça e regra de detecção no mesmo artefato sem separar parâmetros; a caça é exploratória, a regra é contrato versionado.
• Tratar o RBA como caixa preta de risco, sem revisão dos pesos por técnica; a priorização da CTI do Capítulo 05 deve alimentar os pesos com cadência.
• Usar transaction dentro de regra de produção por conveniência; o transaction é comando de caça e reconstrução, e a regra versionada deve usar stats e tstats pelo custo.
• Tratar streamstats como stats e esperar agregação final de uma janela incremental; revise a semântica de window, current e global antes de confiar no número.

9. Integração com o Restante da Biblioteca

A SPL é uma das três linguagens de consulta tratadas na nota de linguagens do Capítulo 09, e as traduções de Sigma do Capítulo 18 produzem exatamente o formato consumido pelo ES. As fontes do Capítulo 02 alimentam os data models via addons, e o hunting das rodadas do Capítulo 07 usa o padrão de consulta da seção 2 com as hipóteses do Capítulo 06. O SOAR conecta-se aos controles AUT.1 e AUT.5 do Capítulo 15, e os KPIs de automação do Capítulo 16 medem o que os playbooks entregam.

Para a decisão de plataforma, o Splunk vence quando o parque já é Splunk e o orçamento comporta volume, com o melhor content pack público do mercado; perde para o Wazuh em custo de entrada e para o Elastic em custo marginal de escala quando a organização já roda ELK. O fechamento desta nota é o mesmo princípio que atravessa a pasta: a plataforma é o motor, e o valor para CTI-TH nasce do ciclo completo, inteligência na entrada, caça no meio, regra versionada e playbook medido na saída, com qualquer das três ferramentas executando o papel.