Cibersegurança e segurança da informação

Splunk Enterprise Security: Do processo de Deteção à Investigação

7 min de leituraPublicado: 5 de agosto de 2026

Ilustração visual profissional sobre investigação de incidentes no Splunk Enterprise Security na área de SIEM e deteção

Resposta rápida

A investigação de incidentes no Splunk Enterprise Security começa com a compreensão da Deteção e da entidade que ela aponta, continua com a validação dos eventos contribuintes, enriquecimento de Ativos e Identidades, construção de uma Timeline e procura de atividade relacionada, e termina com a Disposição, documentação e feedback para a Deteção. Nas versões do Splunk ES 8, os termos Finding e Analyst Queue são mais comuns; em versões anteriores, pode ver Notable e Incident Review.

O Splunk Enterprise Security — ou Splunk ES — adiciona uma camada de Operações de Segurança sobre o motor de pesquisa do Splunk: Deteções, enriquecimento de ativos e identidades, gestão de Findings, investigações, risco e respostas. O desafio de um analista não é apenas “abrir um alerta”, mas compreender a lógica que o gerou, os dados que contribuíram para ele, qual é o Scope real e o que falta para tomar uma decisão.

A interface e os termos variam entre as versões. No Splunk ES 7, Notable Event e Incident Review são comuns. No Splunk ES 8, o Splunk usa mais Findings, Finding Groups, Analyst Queue e Mission Control. O princípio profissional permanece o mesmo: uma Deteção gera um achado; o analista examina o contexto e as evidências; e se houver uma suspeita real, o achado torna-se uma investigação estruturada ou junta-se a ela.

Este artigo foca-se no Risk-Based Alerting — RBA — porque ilustra bem a transição de um alerta individual para uma história comportamental. Os exemplos usam dados de laboratório e pontuações de risco apenas para demonstração. A pontuação de risco não deve ser interpretada como uma conclusão automática sobre um comprometimento.

Da Deteção a um Finding ou Notable

A Deteção no Splunk ES é geralmente baseada em Correlation Search ou num mecanismo de Deteção mais recente, dependendo da versão. A pesquisa examina dados, retorna Resultados e aciona uma Resposta. Num cenário tradicional, a Resposta cria um Notable ou um Finding. Num cenário RBA, a Deteção pode escrever um evento de Risco para o índice de risco em vez de abrir um Caso imediatamente.

Esta escolha muda a unidade de trabalho. Um alerta tradicional diz: “Um determinado Padrão ocorreu agora”. O RBA diz: “Várias indicações foram adicionadas a uma entidade específica ao longo do tempo, e a sua acumulação ultrapassou uma condição que justifica investigação”. Assim, sinais fracos — por exemplo, Login anómalo, execução de uma ferramenta de gestão e comunicação com um novo destino — podem ser conectados a um único caso com um contexto mais rico.

Componente	Pergunta para o Analista	Evidência necessária
Deteção	Que comportamento a regra tentou detetar?	Nome da regra, SPL, condições de tempo, campos, MITRE
Finding/Notable	O que exatamente foi apresentado à fila de analistas?	Título, urgência, entidade, eventos contribuintes
Evento de risco	Que risco foi adicionado e a que entidade?	risk_object, risk_object_type, risk_score, risk_message
Investigação	Que Scope já foi recolhido?	Findings relacionados, artefactos, notas, plano de resposta

Objetos de Risco e Pontuação de Risco

Um objeto de risco é uma entidade sobre a qual o risco pode ser acumulado: um utilizador, sistema, dispositivo ou tipo personalizado. Dois campos fundamentais são risk_object e o seu tipo. Se o mesmo utilizador aparecer uma vez como tair, outra vez como tair@company.example e outra vez com uma grafia diferente, a normalização inconsistente pode dividir a história em três entidades ou unir entidades que não são idênticas. Portanto, a qualidade dos dados de Ativos e Identidades faz parte da Deteção, e não um assunto administrativo secundário.

A pontuação de risco é um meio de priorização. Não é uma probabilidade matemática de violação e não substitui as evidências. Deve-se verificar quem deu a pontuação, quais foram os modificadores de Risco, se o evento é esperado no ambiente, qual a criticidade do ativo e qual a janela de tempo. Uma Regra que adiciona 80 pontos a cada ação comum criará “inflação de risco” e prejudicará a confiança dos analistas.

Uma regra de incidente de risco ou deteção baseada em Finding pode agregar eventos de Risco por entidade, objeto de Ameaça ou condição cumulativa. O analista deve abrir os eventos contribuintes e não se contentar com a soma. Duas pontuações idênticas podem representar histórias completamente diferentes: cinco sinais médios de fontes independentes, ou vinte repetições do mesmo evento ruidoso.

Verificação de Ativos e Identidades

O Splunk ES pode enriquecer Findings usando listas de Ativos e Identidades. Um bom enriquecimento adiciona criticidade, proprietário, departamento, categoria de sistema, expectativas operacionais e outros dados. Antes de uma investigação aprofundada, verifique se a entidade está corretamente identificada: se o IP pertence a uma VPN, se o Host é um servidor de Produção, se o utilizador é uma Service account e se existe uma etiqueta de Privilegiado.

Deve-se distinguir entre fato e enriquecimento. src=203.0.113.10 é um valor do evento. “VPN Gateway” é um Contexto que vem de um Lookup. Se o Lookup for antigo, a decisão também será errada. Documente a fonte do enriquecimento e a data de atualização quando isso afetar o encerramento ou a escalada.

Fluxo de Trabalho de Investigação Prática

Leia o nome da Deteção, a descrição, o Proprietário, o mapeamento MITRE e o Drill-down. Formule numa frase o que a regra afirma.
Identifique a Entidade central e o intervalo de tempo. Verifique se é um Utilizador, Sistema ou entidade personalizada, e se existe criticidade de negócio.
Abra os eventos contribuintes. Verifique se existem, se os campos estão corretos e se não há duplicação devido a Lookback ou Ingestion delay.
Construa uma Timeline cronológica. Adicione Autenticação, Endpoint, Rede, DNS, Cloud e Email conforme o cenário.
Procure por Findings relacionados na mesma entidade, no mesmo IP, Hash, Processo ou objeto de Ameaça. Não restrinja a pesquisa apenas ao título original.
Verifique explicações legítimas: atividade de IT aprovada, Scanner, Automação, alteração de sistema, VPN ou ferramenta de gestão conhecida.
Classifique o achado de acordo com as evidências: True Positive, Benign Positive, False Positive, Duplicate ou um estado intermédio que exija escalada.
Atualize Proprietário, Estado, Urgência/Disposição e Notas. Se uma Investigação for aberta, anexe Artefactos, tarefas e ações de resposta.

Cenário de Laboratório: Risco Cumulativo para um Utilizador

Suponha que, durante 40 minutos, quatro eventos de risco são recebidos para o utilizador lab.user. As pontuações abaixo são apenas um exemplo. O objetivo não é somar números visualmente, mas entender se os eventos estão relacionados à mesma atividade.

Tempo	Sinal	Risco Ilustrativo	Verificação Central
09:02	Login de um novo país	20	VPN, Dispositivo, MFA, histórico
09:14	PowerShell com linha de comando anómala	35	Host, Processo pai, Origem do script
09:21	Acesso a Share sensível	25	Permissão, volume, ficheiros, função do utilizador
09:37	DNS para novo domínio	30	Processo iniciador, Reputação, outros utilizadores

A investigação começa com um Drill-down para cada sinal. Se o Login veio de uma VPN organizacional e o dispositivo é gerido, não feche imediatamente: ainda é preciso verificar o PowerShell e o DNS. Se o PowerShell foi executado por um sistema de gestão conhecido, o Share corresponde à função e o domínio pertence a uma atualização de software, pode ser um Benign Positive. Se vários sinais se conectam ao mesmo Host e a um processo desconhecido, deve-se escalar e considerar o Containment de acordo com um Playbook aprovado.

Encerramento e Feedback para a Deteção

Um bom encerramento inclui o que foi verificado, quais Eventos apoiaram a decisão, quais fontes não estavam disponíveis e qual é a explicação. No RBA, é importante indicar quais eventos de Risco foram úteis e quais geraram ruído. Assim, o engenheiro de Deteção pode alterar modificadores de Risco, adicionar zonas de Entidade, melhorar a Normalização ou atualizar condições de Agregação.

Não faça uma Exclusão ampla de um utilizador, Host ou IP apenas para reduzir o Volume. Prefira uma Exceção restrita no tempo e nas condições, com Proprietário e data de expiração. Após a alteração, execute um teste de Regressão em True Positives históricos e em cenários de laboratório.

Checklist para o Analista

Compreendi o que a Deteção afirma e o que ela não prova.
Verifiquei todos os eventos contribuintes e não apenas a pontuação final.
Validei o objeto de Risco, o tipo de entidade e a normalização do nome.
Verifiquei o enriquecimento de Ativos/Identidades e a sua origem.
Construí uma Timeline e procurei por Findings relacionados.
Separei factos, suposições e explicações legítimas.
Documentei a Disposição e as evidências de forma que outro analista possa continuar a partir delas.
Forneci feedback direcionado à Deteção e não criei uma Exclusão generalizada.

Erros Comuns

Tratar a pontuação de risco como prova de comprometimento.
Investigar apenas o evento com a pontuação mais alta.
Unir identidades diferentes ou dividir a mesma identidade devido a normalização deficiente.
Assumir que o enriquecimento de Ativos está correto sem verificar a atualização.
Fechar um Finding sem Drill-down para os eventos brutos.
Escrever Notas genéricas como “verificado e OK” sem evidências.
Realizar Ajustes que ocultam o sintoma, mas não tratam a raiz do ruído.

Resumo e CTA

Pegue uma Deteção em seu laboratório Splunk ES e crie uma página de investigação para ela: hipótese, objeto de Risco, eventos contribuintes, Drill-down, fontes de enriquecimento, condições de encerramento e feedback para o Ajuste. O exercício conecta SPL à forma como um analista trabalha. No curso Cybersecurity & AI da HPI, pode praticar a mesma transição de um log bruto para uma investigação documentada, usando ambientes autorizados e apenas dados simulados.

Perguntas frequentes

Qual a diferença entre Finding e Notable?

Os termos dependem da versão do Splunk ES e do modelo de trabalho. Nas versões 8.x, o Splunk usa mais Finding e Analyst Queue; nas versões 7.x, Notable e Incident Review são comuns. Do ponto de vista do analista, ambos são achados que exigem Triage.

O RBA substitui as Correlation Searches?

Não. O RBA usa a lógica de Deteção e a estrutura de Risco para acumular sinais por entidade. Uma Correlation search pode gerar um evento de Risco, um Finding/Notable ou outras Respostas, dependendo do design.

Quão alta é considerada uma pontuação de risco?

Não há um número universal. O Threshold deve ser construído de acordo com a Linha de Base, Criticidade, qualidade das fontes e tipo de comportamento. A Pontuação é uma ferramenta de priorização local.

Quando abrir uma Investigação?

Quando é necessário um Scope amplo, partilha entre analistas, ações de resposta, recolha de Artefactos ou acompanhamento além de um Triage curto. A política da organização define o limiar.

O que fazer quando a mesma identidade aparece com vários nomes?

Verifique os lookups de Ativos e Identidades, o objeto de risco normalizado, as zonas de Entidade e as regras de fusão. A alteração da normalização deve ser verificada para não unir pessoas ou sistemas diferentes.