Problema

En entornos donde AWS CloudTrail se indexa en Splunk, los equipos de detección e incident response reciben alertas generadas por búsquedas guardadas. Cada alerta suele contener solo la información mínima del evento que disparó la regla (por ejemplo, un CreateUser inesperado). El reto surge cuando se necesita reconstruir rápidamente la cadena de acciones alrededor del actor, el recurso y la IP involucrados. Sin una vista consolidada, los analistas pierden tiempo correlacionando búsquedas, revisando logs de distintas fuentes y tratando de ordenar cronológicamente los eventos. El patrón típico es: “tengo una alerta de CloudTrail, pero no sé qué más ocurrió antes o después, ni cómo se relaciona con otras identidades o recursos”. Esta falta de contexto retrasa la respuesta y aumenta la probabilidad de pasar por alto indicadores críticos.

Causa

  1. Separación de datos – CloudTrail se ingiere como eventos crudos; las alertas son resultados de búsquedas que no incluyen automáticamente la actividad circundante.
  2. Ausencia de lógica de correlación – Splunk no enlaza automáticamente eventos de la misma entidad (usuario, rol, IP) a menos que se diseñe una búsqueda específica.
  3. Falta de visualización orientada a la investigación – Los paneles estándar muestran series temporales genéricas, pero no ofrecen un “timeline” que agrupe por entidad y permita pivotes rápidos.
  4. Configuración de alert actions limitada – La acción de alerta predeterminada envía solo un correo o webhook; no hay mecanismo integrado para lanzar una vista de investigación enriquecida.

Estos factores aparecen con frecuencia en implementaciones que usan Splunk para monitorear CloudTrail sin una capa de aplicación que automatice la recopilación de contexto.

Solución

Implementar un flujo que, a partir de cualquier alerta de CloudTrail, genere automáticamente un timeline investigativo con:

  • Búsqueda de contexto – una búsqueda parametrizada que recupere eventos de la misma entidad (user, role, IP, resource) en un rango de tiempo configurable (p.ej., ± 2 h).
  • Enriquecimiento MITRE – asignar tácticas y técnicas a los eventos usando un lookup estático o el framework mitre_attack.
  • Pivot y filtrado – permitir al analista cambiar rápidamente el foco a otra entidad relacionada (p.ej., de IP a recurso).
  • Acción de alerta personalizada – una acción que abra la vista de timeline directamente desde la notificación.

Paso a paso

  1. Instalar una app de timeline
    Existen apps gratuitas que ya implementan la lógica anterior (por ejemplo, EventTimeline). La instalación vía CLI garantiza consistencia en clústers:
splunk install app EventTimeline.spl -auth admin:changeme
splunk restart
  1. Crear la búsqueda de contexto
    Defina una búsqueda guardada que acepte los siguientes tokens: $user$, $role$, $ip$, $resource$, $alert_time$. Un ejemplo simplificado:
index=cloudtrail earliest=$alert_time$-2h latest=$alert_time$+2h
( userIdentity.arn="$user$" OR userIdentity.sessionContext.sessionIssuer.arn="$role$"
 OR sourceIPAddress="$ip$" OR requestParameters.resourceId="$resource$" )
| eval mitre=case(
    eventName="CreateUser","T1078",
    eventName="DeleteUser","T1078",
    eventName="ConsoleLogin","T1078",
    true(),"")
| table _time eventName userIdentity.arn sourceIPAddress requestParameters.resourceId mitre
| sort _time

La búsqueda devuelve una tabla ordenada cronológicamente y ya incluye la columna mitre para mapear a ATT&CK.

  1. Configurar la acción de alerta
    En la definición de la alerta original, añada la acción “EventTimeline: Open Investigation”. Asocie los tokens de la alerta a los parámetros de la búsqueda de contexto. La app se encargará de lanzar la vista con los resultados y de ofrecer botones de pivot (p.ej., “Ver todas las IPs usadas por este usuario”).

  2. Ajustar el rango de tiempo y los filtros
    La app permite definir valores por defecto (± 2 h) y sobreescribirlos desde la UI. También se pueden añadir filtros de eventSource o eventCategory para reducir ruido.

  3. Integrar con MITRE
    Si la app no incluye el lookup, importe uno propio:

splunk add lookup mitre_attack.csv userIdentity.arn AS user, eventName AS technique

Luego actualice la búsqueda para usar lookup en vez de eval.

Cuándo aplicar esta solución

  • Alertas de CloudTrail con alta frecuencia – cuando la cantidad de eventos supera la capacidad de revisión manual.
  • Incidentes que requieren trazado de acciones – por ejemplo, compromisos de credenciales, escalado de privilegios o movimiento lateral.
  • Equipos que ya usan Splunk como SIEM – la solución se apoya en la infraestructura existente y no requiere herramientas externas.

No es adecuada si:

  • No se indexa CloudTrail en Splunk (la app depende de los datos).
  • El caso de uso es exclusivamente de cumplimiento y no necesita investigación en tiempo real.

Código

# Instalación vía CLI (reemplazar ruta si es necesario)
splunk install app EventTimeline.spl -auth admin:changeme
splunk restart

Verificación

  1. Generar una alerta de prueba – cree una búsqueda que dispare cuando eventName="ConsoleLogin" y configure la acción de timeline.
  2. Revisar la vista – al recibir la notificación, haga clic en “Open Investigation”. Verifique que aparecen eventos antes y después del login, con columnas mitre y botones de pivot.
  3. Comprobar pivotes – seleccione “Ver todas las IPs de este usuario”. La nueva vista debe mostrar únicamente los eventos asociados a la IP filtrada.
  4. Validar el lookup – confirme que la columna mitre contiene códigos ATT&CK correctos para al menos tres eventos diferentes.

Si alguna de estas comprobaciones falla, revise los tokens de la alerta y la definición de la búsqueda guardada.

Notas adicionales

  • Rendimiento – limitar el rango de tiempo y los tipos de eventos (p.ej., excluir ReadOnly) reduce la carga en el motor de búsqueda.
  • Persistencia de tokens – Splunk no guarda automáticamente los valores de los tokens entre alertas; asegúrese de que la acción de alerta los pase explícitamente.
  • Actualizaciones de MITRE – el framework evoluciona; programe una tarea mensual para refrescar el CSV de mapping.
  • Control de acceso – la app muestra datos sensibles; aplique roles de Splunk para que solo los analistas de incidentes tengan permiso de visualización.

Con este enfoque, cualquier alerta de CloudTrail se transforma en una línea de tiempo investigativa lista para pivotar, filtrar y mapear a MITRE, lo que acelera la detección y respuesta sin necesidad de desarrollar una solución desde cero.