SPL para Iniciantes: Pesquisa e Investigação no Splunk

A Pesquisa Inicial

Uma pesquisa simples no Splunk pode começar assim:

index=lab sourcetype=auth earliest=-24h

O Time Range Picker pode definir o tempo, mas a escrita explícita de earliest e latest é útil para reprodução e documentação. index restringe a um determinado repositório e sourcetype descreve a estrutura da fonte. Pode-se adicionar uma condição de campo já na pesquisa inicial:

index=lab sourcetype=auth action=failure earliest=-24h

Quando um campo existe no momento da pesquisa, especificar `field=value` é mais preciso do que uma pesquisa de texto livre. Aspas são necessárias para valores com espaços. Wildcards podem ser úteis, mas um Wildcard inicial ou uma pesquisa ampla afetam o desempenho e podem gerar resultados inesperados.

Pipe e Comandos de Visualização

O símbolo | passa os resultados para o próximo comando. `fields` mantém ou remove campos, e `table` exibe uma tabela na ordem selecionada. No início de uma investigação, table ajuda na leitura, mas não o use muito cedo se um comando posterior precisar de campos que removeu.

index=lab sourcetype=auth earliest=-24h
| fields _time user src_ip action host
| table _time user src_ip action host

`rename` altera nomes para exibição. `sort` ordena, e `head` limita os resultados. Os eventos são geralmente exibidos do mais recente para o mais antigo, mas ao construir uma Timeline é aconselhável ordenar explicitamente:

index=lab sourcetype=auth user="student" earliest=-4h
| table _time user src_ip action host
| sort 0 _time

O número 0 em sort desativa uma determinada limitação padrão do número de resultados para ordenação, mas em grandes volumes, uma ordenação completa pode ser cara. Numa investigação, use um intervalo restrito.

eval — Criação de Campos

`eval` calcula ou cria um campo. Pode-se usar if, case, lower, coalesce, tonumber e outras funções. Por exemplo, criar um Outcome uniforme:

index=lab sourcetype=auth earliest=-24h
| eval outcome=case(action="success", "Success", action="failure", "Failure", true(), "Other")
| table _time user src_ip action outcome

`where` filtra usando uma expressão depois que os eventos são coletados ou depois que os campos são criados. A pesquisa inicial `action=failure` é geralmente preferível para filtragem básica. `where` é útil para comparar campos, condições numéricas ou campos criados em eval.

index=lab sourcetype=auth earliest=-24h
| stats count as attempts by user src_ip
| where attempts >= 5
| sort - attempts

stats — Transformar Eventos em uma Pergunta

`stats` calcula Aggregations sobre os resultados. Sem BY, obtém-se uma única linha; com BY, obtém-se uma linha para cada combinação de valores. Comandos comuns incluem count, sum, avg, min, max, values e dc — distinct count.

index=lab sourcetype=auth action=failure earliest=-24h
| stats count as failures,
        earliest(_time) as first_seen,
        latest(_time) as last_seen,
        values(src_ip) as src_ips
  by user
| convert ctime(first_seen) ctime(last_seen)
| sort - failures

`values` retorna valores únicos sem ordem garantida e pode aumentar. Use-o com cautela e prefira uma lista restrita ou Drill-down quando houver muitos IPs. `list` mantém valores em ordem, mas pode consumir mais memória.

stats vs. eventstats e streamstats

Iniciantes devem dominar stats antes de usar transaction. `transaction` pode ser conveniente para agrupamento, mas em grandes volumes é caro e às vezes esconde a lógica. Muitas vezes, stats, streamstats ou eventstats oferecem uma solução mais eficiente e transparente.

Janelas de Tempo e timechart

`timechart` cria uma série temporal e agrupa por `_time`. É bom para identificar Spikes, tendências e mudanças de volume. Por exemplo:

index=lab sourcetype=auth action=failure earliest=-24h
| timechart span=30m count by src_ip limit=10

Escolha o span de acordo com a pergunta. Uma janela muito pequena criará ruído, e uma janela muito grande esconderá Bursts. timechart é um comando Transforming: o resultado é uma tabela sumarizada, não os eventos brutos. Para fins de Evidência, execute Drill-down para o intervalo e o IP relevantes.

Exercício: Falhas e Sucessos na mesma Janela

O objetivo é encontrar janelas onde o mesmo utilizador e IP geraram várias falhas e pelo menos um sucesso. A Query a seguir usa eval, bin e stats:

index=lab sourcetype=auth earliest=-24h
| eval failed=if(action="failure", 1, 0), success=if(action="success", 1, 0)
| bin _time span=30m
| stats sum(failed) as failures,
        sum(success) as successes,
        earliest(_time) as window_start,
        latest(_time) as window_end
  by _time user src_ip
| where failures >= 5 AND successes >= 1
| sort - failures

A Query aponta para uma janela que requer investigação. Como os dados foram sumarizados, ela não prova que o sucesso ocorreu após as falhas. Use o resultado para executar um Drill-down no user, src_ip e no tempo:

index=lab sourcetype=auth user="student" src_ip="203.0.113.25" earliest="08/01/2026:09:00:00" latest="08/01/2026:09:30:00"
| table _time user src_ip action host reason
| sort 0 _time

Verifique: O sucesso pertence ao mesmo Host ou App? O endereço de origem é um VPN? As falhas foram causadas por uma senha antiga no serviço? Há atividade de acompanhamento? SPL fornece os dados; a Classification exige contexto.

Campos, Extração e CIM

O Splunk extrai campos no momento da Indexação ou Pesquisa. Um campo ausente pode exigir `rex`, `spath` para JSON ou definição de Field extraction. A Extração ad-hoc pode ajudar em laboratório, mas a Deteção em produção precisa de um Parser e um Data model mantidos.

CIM normaliza conceitos entre fontes, por exemplo Authentication.user ou Network_Traffic.src. Quando a organização usa CIM, é possível construir Detections e Dashboards que podem ser usados em vários produtos. É preciso verificar se os dados realmente estão em conformidade com o modelo e não apenas se o App está instalado.

Melhorar o Desempenho e a Leiturabilidade

• Defina o Time range o mais estreito possível.
• Comece com index, sourcetype e campos mapeados.
• Filtre cedo antes de stats ou sort.
• Evite Wildcard inicial e pesquisa de texto ampla quando um campo existe.
• Use fields para reduzir o Payload, mas não antes de um comando que precise do campo.
• Limite values/list e operações intensivas em memória.
• Dê nomes claros aos campos usando `as`.
• Guarde a Query com descrição, Owner, tempo e versão.
• Teste em uma pequena amostra antes de um intervalo longo.

Erros Comuns

• Pesquisar em todos os indexes sem necessidade.
• Assumir que um campo action ou user existe em todos os sourcetypes.
• Usar table cedo e remover um campo que será necessário depois.
• Interpretar stats como uma Timeline precisa.
• Usar transaction por padrão.
• Ativar um Alert em uma Query não verificada contra uma Baseline.
• Copiar SPL de uma versão ou Data model diferente sem adaptação.
• Ignorar o fuso horário e o Ingestion delay.

Checklist para Prática

1. Encontre o index e o sourcetype dos dados do laboratório.
2. Exiba cinco Events e verifique os campos.
3. Filtre um utilizador ou um IP.
4. Exiba uma Timeline usando table e sort.
5. Agregue falhas usando stats.
6. Crie um campo usando eval e filtre-o com where.
7. Exiba o volume ao longo do tempo usando timechart.
8. Escreva o que cada Query prova e o que não prova.

Resumo e CTA

Configure um pequeno index de laboratório ou use dados autorizados e execute o mesmo cenário em três visualizações: Raw events, stats e timechart. Escreva ao lado de cada visualização qual pergunta ela responde e qual Context está faltando. O próximo passo é transformar uma pesquisa estável em uma Deteção com Owner, Threshold e Playbook — não apenas salvar uma Query impressionante.

Perguntas frequentes