Ciberseguridad y seguridad de la información

Splunk Enterprise Security: de la detección a la investigación

7 min de lecturaPublicado: 5 de agosto de 2026

Ilustración visual profesional sobre la investigación de incidentes en Splunk Enterprise Security en el campo de SIEM y detección

Respuesta rápida

La investigación de un incidente en Splunk Enterprise Security comienza con la comprensión de la detección y la entidad a la que apunta, continúa con la verificación de los eventos contribuyentes, el enriquecimiento de activos e identidades, la construcción de un Timeline y la búsqueda de actividad relacionada, y finaliza con la disposición, la documentación y la retroalimentación para la detección. En las versiones de Splunk ES 8, los términos Finding y Analyst Queue son más comunes; en versiones anteriores, a menudo verá Notable e Incident Review.

Splunk Enterprise Security — o Splunk ES — añade una capa de operaciones de seguridad sobre el motor de búsqueda de Splunk: Detecciones, enriquecimiento de activos e identidades, gestión de Findings, investigaciones, riesgos y respuestas. El desafío de un analista no es solo “abrir una alerta”, sino entender qué lógica la generó, qué datos contribuyeron a ella, cuál es el alcance real y qué falta para tomar una decisión.

La interfaz y los términos varían entre versiones. En Splunk ES 7 son comunes Notable Event e Incident Review. En Splunk ES 8, Splunk utiliza más Findings, Finding Groups, Analyst Queue y Mission Control. El principio profesional sigue siendo el mismo: la Detección produce un hallazgo; el analista examina el contexto y la evidencia; y si existe una sospecha real, el hallazgo se convierte en una investigación estructurada o se une a ella.

Este artículo se centra en Risk-Based Alerting — RBA — porque ilustra bien la transición de una alerta única a una historia de comportamiento. Los ejemplos utilizan datos de laboratorio y puntuaciones de riesgo solo a modo de ilustración. La puntuación de riesgo no debe interpretarse como una conclusión automática de una infracción.

De Detección a Finding o Notable

La detección en Splunk ES generalmente se basa en una Correlation Search o en un mecanismo de detección más nuevo según la versión. La búsqueda examina datos, devuelve Resultados y activa una Respuesta. En un escenario tradicional, la Respuesta crea un Notable o Finding. En un escenario RBA, la detección puede escribir un Risk event en el índice de riesgo en lugar de abrir un Caso inmediatamente.

Esta elección cambia la unidad de trabajo. Una alerta tradicional dice: “Ha ocurrido un Patrón específico ahora”. RBA dice: “A una entidad específica se le han añadido varias indicaciones a lo largo del tiempo, y su acumulación ha superado una condición que justifica una investigación”. Así se pueden conectar señales débiles — por ejemplo, un Inicio de sesión anómalo, la ejecución de una herramienta de administración y la comunicación con un nuevo destino — en un solo caso con un contexto más rico.

Componente	Pregunta para el analista	Evidencia requerida
Detection	¿Qué comportamiento intentaba detectar la regla?	Nombre de la regla, SPL, condiciones de tiempo, campos, MITRE
Finding/Notable	¿Qué se presentó exactamente en la cola de analistas?	Título, urgencia, entidad, eventos contribuyentes
Risk event	¿Qué riesgo se añadió y a qué entidad?	risk_object, risk_object_type, risk_score, risk_message
Investigation	¿Qué Alcance ya se ha recopilado?	Findings relacionados, artefactos, notas, plan de respuesta

Objetos de riesgo y puntuación de riesgo

Un Risk object es una entidad sobre la cual se puede acumular riesgo: un usuario, un sistema, un dispositivo o un tipo personalizado. Dos campos fundamentales son risk_object y su tipo. Si el mismo usuario aparece una vez como tair, otra como tair@company.example y otra con una escritura diferente, una normalización inconsistente podría dividir la historia en tres entidades o unir entidades que no son idénticas. Por lo tanto, la calidad de los datos de Asset and Identity es parte de la Detección, no un tema administrativo secundario.

La puntuación de riesgo es un medio de priorización. No es una probabilidad matemática de un compromiso y no reemplaza la evidencia. Se debe verificar quién otorgó la puntuación, cuáles fueron los Risk modifiers, si el evento es esperado en el entorno, cuál es la criticidad del activo y cuál es la ventana de tiempo. Una regla que añade 80 puntos a cada acción común creará una “inflación de riesgo” y afectará la confianza de los analistas.

Una regla de incidente de riesgo o una detección basada en hallazgos puede agrupar eventos de riesgo por entidad, Threat object o condición acumulativa. El analista debe abrir los eventos contribuyentes y no conformarse con la suma. Dos puntuaciones idénticas pueden representar historias completamente diferentes: cinco señales medianas de fuentes independientes, o veinte repeticiones del mismo evento ruidoso.

Verificación de activos e identidades

Splunk ES puede enriquecer los Findings mediante listas de Asset e Identity. Un buen enriquecimiento añade criticidad, propietario, departamento, categoría de sistema, expectativas operacionales y datos adicionales. Antes de una investigación profunda, verifique si la entidad está correctamente identificada: si la IP pertenece a una VPN, si el Host es un servidor de Producción, si el usuario es una Service account y si existe una etiqueta de Privilegio.

Se debe distinguir entre hecho y enriquecimiento. src=203.0.113.10 es un valor del evento. “VPN Gateway” es un Context que proviene de un Lookup. Si el Lookup está obsoleto, la decisión también será incorrecta. Documente la fuente del enriquecimiento y la fecha de actualización cuando afecte al cierre o la escalada.

Flujo de trabajo de investigación práctico

Lea el nombre de la Detección, la descripción, el Propietario, la asignación MITRE y el Drill-down. Resuma en una frase lo que afirma la regla.
Identifique la Entidad central y el rango de tiempo. Verifique si es un Usuario, Sistema o una entidad personalizada, y si existe una criticidad empresarial.
Abra los eventos contribuyentes. Asegúrese de que existen, que los campos son correctos y que no hay duplicidad debido a Lookback o Ingestion delay.
Construya un Timeline cronológico. Añada Autenticación, Endpoint, Red, DNS, Nube y Email según el escenario.
Busque Related findings sobre la misma entidad, la misma IP, Hash, Proceso o Threat object. No limite la búsqueda solo al título original.
Verifique explicaciones legítimas: actividad de TI aprobada, Scanner, Automatización, cambio de sistema, VPN o herramienta de administración conocida.
Clasifique el hallazgo según la evidencia: True Positive, Benign Positive, False Positive, Duplicate o un estado intermedio que requiera escalada.
Actualice el Propietario, Estado, Urgencia/Disposición y Notas. Si se inició una Investigación, adjunte Artefactos, tareas y acciones de respuesta.

Escenario de laboratorio: riesgo acumulado para el usuario

Supongamos que durante 40 minutos se reciben cuatro Risk events sobre el usuario lab.user. Las puntuaciones a continuación son solo un ejemplo. El objetivo no es sumar números a ojo, sino entender si los eventos están relacionados con la misma actividad.

Tiempo	Señal	Riesgo de ilustración	Verificación principal
09:02	Login desde un nuevo país	20	VPN, Dispositivo, MFA, Historial
09:14	PowerShell con Command line anómala	35	Host, Proceso padre, Origen del script
09:21	Acceso a Share sensible	25	Permiso, volumen, archivos, rol del usuario
09:37	DNS a un nuevo dominio	30	Proceso iniciador, Reputación, otros usuarios

La investigación comienza con un Drill-down en cada señal. Si el Login provino de una VPN corporativa y el dispositivo está administrado, no se debe cerrar de inmediato: aún es necesario verificar PowerShell y DNS. Si PowerShell fue ejecutado por un sistema de administración conocido, el Share coincide con el rol y el dominio pertenece a una actualización de software, puede ser un Benign Positive. Si varias señales se conectan al mismo Host y a un proceso desconocido, se debe escalar y considerar la Contención según un Playbook aprobado.

Cierre y retroalimentación para la detección

Un buen cierre incluye lo que se verificó, qué Eventos respaldaron la decisión, qué fuentes no estaban disponibles y cuál es la explicación. En RBA es importante indicar qué Risk events fueron útiles y cuáles generaron ruido. Así, un ingeniero de Detección puede cambiar los Risk modifiers, añadir Entity zones, mejorar la Normalization o actualizar las condiciones de Aggregation.

No realice una exclusión amplia sobre un usuario, Host o IP solo para reducir el volumen. Prefiera una Excepción limitada en tiempo y condiciones, con Propietario y fecha de vencimiento. Después del cambio, ejecute una prueba de Regresión en True Positives históricos y en escenarios de laboratorio.

Lista de verificación para el analista

Entendí lo que la Detección afirma y lo que no demuestra.
Verifiqué todos los eventos contribuyentes y no solo la puntuación final.
Validé el objeto de riesgo, el tipo de entidad y la normalización del nombre.
Verifiqué el enriquecimiento de Activos/Identidades y su origen.
Construí un Timeline y busqué Findings relacionados.
Separé hechos, suposiciones y explicaciones legítimas.
Documenté la Disposición y las pruebas de manera que otro analista pueda continuar a partir de ella.
Proporcioné retroalimentación específica a la Detección y no creé una Exclusión generalizada.

Errores comunes

Tratar la puntuación de riesgo como prueba de un compromiso.
Investigar solo el evento con la puntuación más alta.
Unir identidades diferentes o dividir la misma identidad debido a una Normalization deficiente.
Asumir que el enriquecimiento de Activos es correcto sin verificar la actualidad.
Cerrar un Finding sin Drill-down a los eventos brutos.
Escribir notas generales como “verificado y correcto” sin pruebas.
Realizar un Tuning que elimina el síntoma pero no aborda la raíz del ruido.

Resumen y CTA

Tome una Detección en el laboratorio de Splunk ES y construya una página de investigación para ella: hipótesis, objeto de riesgo, eventos contribuyentes, Drill-down, fuentes de enriquecimiento, condiciones de cierre y retroalimentación para el Tuning. El ejercicio conecta SPL con el flujo de trabajo de un analista. En el curso de Cybersecurity & AI de HPI se puede practicar la misma transición de un log bruto a una investigación documentada, utilizando entornos autorizados y solo datos simulados.

Preguntas frecuentes

¿Cuál es la diferencia entre Finding y Notable?

Los términos dependen de la versión de Splunk ES y del modelo de trabajo. En las versiones 8.x, Splunk utiliza más Finding y Analyst Queue; en las versiones 7.x son comunes Notable e Incident Review. Desde la perspectiva del analista, ambos son hallazgos que requieren Triage.

¿RBA reemplaza a las Correlation Searches?

No. RBA utiliza la lógica de detección y el marco de riesgo para acumular señales por entidad. Una búsqueda de correlación puede generar un evento de riesgo, un hallazgo/notable u otras respuestas según el diseño.

¿Qué puntuación de riesgo se considera alta?

No existe un número universal. El umbral debe establecerse según la línea base, la criticidad, la calidad de las fuentes y el tipo de comportamiento. La puntuación es una herramienta de priorización local.

¿Cuándo abrir una Investigación?

Cuando se requiere un alcance amplio, colaboración entre analistas, acciones de respuesta, recopilación de artefactos o seguimiento más allá de un Triage corto. La política de la organización establece el umbral.

¿Qué hacer cuando la misma identidad aparece con varios nombres?

Verifique las búsquedas de activos e identidades (Asset and Identity lookups), el objeto de riesgo normalizado (normalized risk object), las zonas de entidad (Entity zones) y las reglas de fusión. Cualquier cambio en la normalización debe validarse para evitar la unión de personas o sistemas diferentes.