Triagem de Alertas de Segurança no Splunk

Quando Usar

Use esta habilidade quando:

• Analistas de SOC Nível 1 precisarem processar a fila de Revisão de Incidentes no Splunk Enterprise Security (ES)
• Eventos notáveis exigirem classificação rápida de severidade e investigação inicial antes da escalada
• O volume de alertas exceder a capacidade e os analistas precisarem de uma metodologia de triagem sistemática
• A gerência solicitar métricas sobre a disposição dos alertas (positivo real, falso positivo, benigno)

Não use para investigação forense aprofundada — escale para Nível 2/3 após a triagem inicial confirmar atividade maliciosa.

Pré-requisitos

• Splunk Enterprise Security 7.x+ com o painel Incident Review configurado
• Fontes de dados normalizadas pelo CIM (Logs de Eventos do Windows, firewall, proxy, endpoint)
• Papel com capacidade ess_analyst para atualizações de status de eventos notáveis
• Familiaridade com SPL (Search Processing Language)

Fluxo de Trabalho

Passo 1: Acessar Revisão de Incidentes e Priorizar a Fila

Abra o painel Incident Review no Splunk ES. Ordene os eventos notáveis por urgência (calculada a partir de severidade x prioridade). Aplique filtros para focar em eventos não atribuídos:

| `notable`
| search status="new" OR status="unassigned"
| sort - urgency
| table _time, rule_name, src, dest, user, urgency, status
| head 50

Concentre-se primeiro em eventos de urgência Crítica e Alta. Agrupe alertas relacionados por src ou dest para identificar cadeias de ataque em vez de tratar cada alerta independentemente.

Passo 2: Investigar o Contexto do Evento Notável

Para cada evento notável, navegue para os eventos brutos. Exemplo para um alerta de força bruta:

index=wineventlog sourcetype="WinEventLog:Security" EventCode=4625
src_ip="192.168.1.105"
earliest=-1h latest=now
| stats count by src_ip, dest, user, status
| where count > 10
| sort - count

Verifique se o IP de origem é interno (movimentação lateral) ou externo (ataque de perímetro). Cruze informações com lookups de ativos e identidades:

| `notable`
| search rule_name="Brute Force Access Behavior Detected"
| lookup asset_lookup_by_cidr ip AS src OUTPUT category, owner, priority
| lookup identity_lookup_expanded identity AS user OUTPUT department, managedBy
| table _time, src, dest, user, category, owner, department

Passo 3: Correlacionar Entre Fontes de Dados

Verifique se a mesma origem aparece em outra telemetria:

index=proxy OR index=firewall src="192.168.1.105" earliest=-24h
| stats count by index, sourcetype, action, dest_port
| sort - count

Procure por evidências corroborativas: O mesmo IP também disparou anomalias de DNS, bloqueios de proxy ou alertas de detecção de endpoint?

index=main sourcetype="cisco:asa" src="192.168.1.105" action=blocked earliest=-24h
| timechart span=1h count by dest_port

Passo 4: Verificar Enriquecimento de Inteligência de Ameaças

Consulte o framework de inteligência de ameaças para IOCs conhecidos:

| `notable`
| search search_name="Threat - Threat Intelligence Match - Rule"
| lookup threat_intel_by_ip ip AS src OUTPUT threat_collection, threat_description, threat_key
| table _time, src, dest, threat_collection, threat_description, weight
| where weight >= 3

Para domínios, verifique contra listas de ameaças:

| tstats count from datamodel=Web where Web.url="*evil-domain.com*" by Web.src, Web.url, Web.status
| rename Web.* AS *

Passo 5: Classificar e Dispor o Alerta

Atualize o status do evento notável no Incident Review:

Atualize via interface do Splunk ES ou API REST:

| sendalert update_notable_event param.status="2" param.urgency="critical"
  param.comment="Confirmed brute force from compromised workstation. Escalated to IR-2024-0431."
  param.owner="analyst_jdoe"

Passo 6: Documentar Descobertas da Triagem

Registre no campo de comentário do evento notável:

• Origem/destino envolvidos
• Fontes de dados examinadas
• Descobertas de correlação (alertas relacionados, correspondências de TI)
• Racional da disposição
• Próximos passos para escalada

| `notable`
| search rule_name="Brute Force*" status="closed"
| stats count by status_label, disposition

…