Ciberseguridad y seguridad de la información

Cómo construir una línea de tiempo para la investigación de incidentes cibernéticos

6 min de lecturaPublicado: 5 de agosto de 2026

Ilustración visual profesional sobre la construcción de una línea de tiempo para la investigación de incidentes en el ámbito de SOC y operaciones

Respuesta rápida

Una línea de tiempo para la investigación de incidentes es una tabla cronológica que unifica eventos de diferentes fuentes en un tiempo estándar y los conecta a través de usuarios, estaciones, direcciones IP, procesos y sesiones. Una construcción correcta incluye mantener el tiempo original, convertir a UTC, especificar la fuente y la fiabilidad, identificar lagunas y distinguir entre hechos, interpretación e hipótesis.

Un incidente cibernético casi nunca aparece en un solo registro. La conexión está en el sistema de identidades, la ejecución del proceso en el EDR o en Windows, la solicitud de dominio en el DNS y la conexión externa en el Firewall. Cada fuente describe una parte diferente, en un formato de tiempo diferente y con diferentes identificadores. Sin una línea de tiempo, el investigador ve una colección de signos; con una línea de tiempo, puede ver una posible secuencia causal.

Una línea de tiempo no es solo un ordenamiento por hora. Es un proceso de normalización, vinculación y evaluación de la fiabilidad. Un reloj desincronizado, una zona horaria incorrecta o un retraso en la recepción pueden invertir el orden y llevar a una conclusión errónea. NIST define la gestión de registros como un proceso que incluye la creación, transferencia, almacenamiento y acceso; cada etapa afecta la capacidad de reconstruir un evento.

En este artículo, construiremos una línea de tiempo a partir de un escenario que incluye Windows, DNS, Firewall y EDR. Los ejemplos son independientes de un producto específico y pueden implementarse en una hoja de cálculo, SIEM, Notebook o herramienta DFIR.

Por qué la línea de tiempo es el corazón de la investigación

La línea de tiempo responde a preguntas que no pueden resolverse con un solo evento: ¿Cuál fue el Acceso Inicial, qué proceso creó la conexión, la conexión precedió a la ejecución, qué sucedió después del aislamiento y el mismo usuario actuó en otros activos?

También revela lagunas. Si el EDR muestra la ejecución de un archivo pero no hay un evento de creación de proceso en Windows, es posible que la Auditoría no esté habilitada, que el registro haya sido eliminado, que el evento haya sido filtrado o que los identificadores de tiempo no estén alineados. La laguna en sí misma es un hallazgo.

En una investigación compleja, es aconsejable mantener dos líneas de tiempo: una Línea de Tiempo Maestra que incluya los eventos centrales y una Línea de Tiempo detallada para cada activo o fuente. De esta manera, el informe sigue siendo legible sin perder los datos.

Normalización de tiempos y fuentes

Guarde siempre dos campos: Original Timestamp tal como apareció en la fuente y Normalized Timestamp en UTC. Indique la zona horaria original, la desviación de reloj conocida y el tiempo de ingestión en el SIEM. No sobrescriba el tiempo original, ya que es necesario para la auditoría y la resolución de conflictos.

Distinga entre tiempo de evento y tiempo de Ingestión. Un Firewall puede enviar un registro con retraso, un Agente puede estar Offline y cargar datos más tarde, y un producto en la nube puede calcular la Detección después del evento. Ordenar solo por tiempo de ingestión puede ser incorrecto.

Verifique la sincronización NTP, la configuración de horario de verano, los formatos con/sin Offset, los milisegundos y los campos que contienen el tiempo de creación frente al tiempo de actualización. Al cambiar la hora del sistema, documente la desviación y no intente “corregir” en silencio.

Conexión de usuarios, Hosts, IP y procesos

Los eventos de diferentes fuentes se conectan mediante Pivot Keys. Identidad: UPN, SID, Object ID, Session ID. Estación: hostname, Device ID, Agent ID, dirección MAC. Red: IP, NAT translation, port, protocol. Proceso: PID, Parent PID, Process GUID, hash y línea de comandos.

El PID por sí solo no es un identificador estable a lo largo del tiempo porque el sistema operativo puede reciclarlo. En Windows, el Process GUID de Sysmon o una combinación de Host + PID + tiempo son más útiles. Una dirección IP interna puede pasar entre estaciones en DHCP, por lo que debe cruzarse con Lease u otra Telemetry.

En cada línea, agregue un campo “Entity Link”: por qué el evento está relacionado con el anterior. Por ejemplo: “La consulta DNS fue creada por el PID 4120, que es un hijo de powershell.exe de la línea anterior”. Un enlace explícito evita que el lector asuma una conexión no probada.

Separación entre hechos, interpretación e hipótesis

Hecho: “A las 10:14:22, EDR registró powershell.exe con Parent winword.exe.” Interpretación: “La secuencia coincide con la posibilidad de ejecución de código desde un documento.” Hipótesis: “Es posible que el usuario haya abierto un archivo de Phishing.” La separación es crítica para que el informe no presente una suposición como si fuera una evidencia.

Se puede añadir una columna de Confidence: alta cuando varias fuentes independientes lo apoyan; media cuando una fuente de calidad lo apoya; baja cuando los datos son parciales o dependen de una hipótesis. El nivel de confianza no es una puntuación matemática obligatoria, sino una forma de comunicar la incertidumbre.

MITRE ATT&CK se puede añadir después de comprender el incidente para describir técnicas, pero no debe usarse el mapeo para rellenar lagunas. El hecho de que exista PowerShell no prueba Initial Access o Persistence.

Identificación de lagunas y contradicciones

Busque huecos en los tiempos, eventos que aparecen solo en una fuente, direcciones que no coinciden con NAT, usuarios en diferentes formatos y resultados opuestos. Una laguna de cinco minutos antes de la primera conexión puede contener la acción más importante.

Cuando dos fuentes muestran tiempos diferentes, verifique Clock Skew, Time Zone, tiempo de escritura frente a tiempo de ingestión, rounding y caché. Mantenga ambas versiones e indique cuál se utilizó para ordenar y por qué.

Construya una “lista de faltantes”: los logs del Proxy no se guardaron, la creación de procesos no se activó, el EDR estaba Offline o no hay acceso a Mailbox Audit. La lista ayuda a comprender las limitaciones de la conclusión y a mejorar el Logging en el futuro.

Presentación de la línea de tiempo en el informe

La línea de tiempo en un informe ejecutivo debe incluir solo los eventos que cambian la comprensión del incidente: acceso inicial, ejecución, persistencia, movimiento lateral, acceso a la información, contención y recuperación. Un anexo técnico puede incluir los registros completos.

Para cada línea, se recomienda mostrar: UTC, tiempo original, fuente, entidad, evento, evidencia/identificador, interpretación y nivel de confianza. Utilice un lenguaje consistente y verbos precisos: “creado”, “bloqueado”, “fallido”, “observado”, no “comprometido” sin pruebas.

Adjunte una línea de tiempo abreviada también al Ticket para que el siguiente analista pueda continuar sin leer todas las notas.

Escenario: Windows, DNS, Firewall y EDR

UTC	Fuente	Entidad	Evento	Enlace e interpretación
08:41:03	Windows Security	WS-17 / user1	Conexión interactiva exitosa	Inicio de sesión; verificar fuente y Logon ID
08:43:18	EDR	WINWORD.EXE	Creación de powershell.exe	El árbol de procesos indica ejecución desde un documento
08:43:20	EDR	powershell.exe	Línea de comandos codificada	Requiere descifrado en un entorno seguro y guardar la fuente
08:43:22	DNS	WS-17	Consulta a new-example-domain.tld	Mismo Host, dos segundos después de la ejecución
08:43:23	Firewall	10.0.4.17	Conexión TLS a IP externa	La IP coincide con la respuesta DNS; NAT verificado
08:44:01	EDR	powershell.exe	Creación de archivo en la carpeta Temp	Hash guardado; aún no se determina si es malicioso
08:47:55	Microsoft Sentinel	user1 / WS-17	Incidente creado	Tiempo de detección posterior al tiempo de los eventos
09:02:11	EDR	WS-17	Aislamiento de estación exitoso	Punto de Contención; verificar conexiones posteriores

Lista de verificación práctica

Guardé el tiempo original y el tiempo UTC.
Distinguí entre Event Time y Ingestion Time.
Documenté la fuente y el campo identificador.
Vinculé entidades mediante identificadores fiables.
Separé el hecho de la interpretación.
Indiqué lagunas y contradicciones.
Añadí Confidence.
Creé una línea de tiempo abreviada y un anexo detallado.

Errores comunes

Ordenar solo por tiempo de ingestión.
Convertir el tiempo sin guardar el valor original.
Vincular eventos solo basándose en una IP dinámica.
Escribir una hipótesis como si fuera un hecho.
Sobrecargar miles de eventos en la Línea de Tiempo Maestra sin filtrado.

Resumen y CTA

Tome un escenario de laboratorio y construya manualmente una línea de tiempo a partir de cuatro fuentes. Luego, compárelo con el proceso de investigación del primer artículo y verifique qué campos deberían agregarse al Playbook del equipo. En el curso Cybersecurity & AI de HPI, las habilidades de logs, redes y SIEM se aprenden como parte de una práctica de investigación de incidentes.

Preguntas frecuentes

¿Siempre se usa UTC?

Se recomienda normalizar a UTC para unificar fuentes, pero también guardar el tiempo y el Offset originales y mostrar la hora local según la necesidad del negocio.

¿Qué hacer si no hay sincronización de reloj?

Se estima el Clock Skew mediante un evento compartido o una fuente fiable, se documenta la diferencia y se guardan los tiempos originales. No se debe modificar la evidencia sin documentación.

¿Qué herramienta se utiliza para construir una línea de tiempo?

Se puede empezar con una hoja de cálculo o un SIEM. En investigaciones grandes, se utilizan herramientas DFIR o Notebook. La herramienta es menos importante que los campos, la normalización y la vinculación.

¿Cuántos eventos se deben incluir?

En la Línea de Tiempo Maestra se incluyen eventos sustanciales. Todos los registros se guardan en un anexo o en un repositorio de evidencia.

¿La línea de tiempo prueba la causalidad?

No necesariamente. La proximidad en el tiempo refuerza la posibilidad de una conexión, pero se requiere un identificador o evidencia adicional para determinar que un proceso causó otro.