Logs de seguridad: qué son, tipos y cómo analizarlos

Una cuenta intenta iniciar sesión veinte veces en menos de dos minutos. Diecinueve intentos fallan. El siguiente funciona.

¿Es un ataque?

Todavía no lo sabemos.

Puede ser un ataque de fuerza bruta. Puede ser una contraseña recién cambiada que sigue guardada en una aplicación local. Puede ser un servicio desconfigurado intentando sincronizar. Incluso puede ser el propio usuario insistiendo hasta recordar su contraseña correcta.

El log registra lo que ocurrió. El trabajo del analista consiste en descubrir qué significa.

Esa diferencia es importante porque analizar logs no consiste en buscar líneas rojas, palabras como «error» o eventos con una severidad alta. Consiste en reconstruir actividad a partir de evidencias dispersas: quién hizo qué, desde dónde, sobre qué sistema, cuándo ocurrió, qué sucedió antes y qué pasó después.

Para un analista SOC, los logs son una de las materias primas fundamentales de una investigación.

Criterio analítico fundamental: No investigamos líneas de texto. Investigamos actividad utilizando líneas de texto como evidencia.

1. Qué es un log en ciberseguridad #

Un log o registro es un conjunto de eventos generados por un sistema, aplicación, dispositivo o servicio mientras funciona.

• Un servidor puede registrar conexiones de red entrantes.
• Windows puede registrar intentos de autenticación locales y remotos.
• Un firewall puede registrar paquetes permitidos y bloqueados según sus políticas de filtrado.
• Un servicio cloud puede registrar modificaciones en permisos administrativos o políticas IAM.
• Un servidor DNS puede registrar consultas de resolución de nombres de dominio.
• Un EDR puede registrar la creación de un subproceso en memoria y su árbol de ejecución.

Cada fuente observa una parte diferente de la actividad. Por eso, un log aislado rara vez cuenta toda la historia de una intrusión.

Imagina esta secuencia temporal:

10:03:14 Fallo de autenticación de usuario administrador
10:03:20 Fallo de autenticación de usuario administrador
10:03:27 Fallo de autenticación de usuario administrador
10:03:41 Autenticación correcta
10:04:02 powershell.exe inicia una conexión externa
10:04:07 Firewall registra conexión hacia 203.0.113.50:443

La primera línea, por sí sola, tiene poco valor investigable: un fallo de contraseña ocurre habitualmente en cualquier organización. En cambio, la secuencia completa cambia radicalmente la interpretación: un patrón de fallos rápidos que culmina en éxito seguido inmediatamente por la ejecución de una consola de comandos con conexión externa es una señal de alta prioridad.

2. Log, evento, alerta e incidente no son lo mismo #

Estos cuatro términos suelen mezclarse en conversaciones informales, pero en el SOC tienen definiciones precisas que delimitan las etapas del análisis:

El flujo operativo transcurre de forma progresiva:

FUENTE ↓ EVENTOS ↓ LOGS / TELEMETRÍA ↓ DETECCIÓN ↓ ALERTA ↓ TRIAJE ↓ INVESTIGACIÓN ↓ INCIDENTE O FALSO POSITIVO

Comprender esta jerarquía evita uno de los errores más frecuentes de los analistas principiantes: tratar cada alerta como si fuera automáticamente una intrusión consumada.

3. Qué información debemos buscar dentro de un log #

Los formatos técnicos varían considerablemente entre Windows Event Logs, Syslog en Linux, registros de cortafuegos o eventos JSON de plataformas cloud. A pesar de esa disparidad sintáctica, las preguntas analíticas esenciales siempre se repiten:

1. Cuándo ocurrió (Timestamp)

Busca la marca temporal precisa, preferentemente en formato ISO 8601 con milisegundos y zona horaria explícita:

2026-10-03T21:47:18.422Z

La hora es crítica porque más adelante necesitaremos cruzar fuentes distintas. Un detalle aparentemente menor puede arruinar una investigación: que un servidor registre en UTC mientras otro registra en hora local o mantiene el reloj desfasado varios minutos. Por eso la sincronización temporal mediante NTP importa tanto como la propia recolección.

2. Dónde ocurrió (Activo implicado)

Identifica el equipo de origen o destino. Puede manifestarse como un nombre de host (hostname=WS-FINANZAS-023), un identificador de dispositivo (device_id=8a993bc...) o una dirección IP privada. Debemos saber qué equipo produjo el evento y qué función cumple dentro de la infraestructura (estación de trabajo, servidor de bases de datos, controlador de dominio).

3. Quién realizó la acción (Identidad y credenciales)

Localiza el usuario, cuenta de servicio, token de API, ID de sesión o contexto de seguridad asociado:

user.name=acontabilidad

Una acción de administración ejecutada por una cuenta administradora autorizada puede ser legítima. La misma acción ejecutada desde una cuenta de usuario estándar o una cuenta de servicio sin interacción interactiva cambia drásticamente la interpretación.

4. Qué ocurrió (Acción o tipo de evento)

Describe la operación técnica que tuvo lugar: inicio de sesión, creación de proceso, modificación de archivo, consulta DNS, establecimiento de conexión de red, cambio de permisos, adición de usuario a un grupo local o modificación de claves de registro. Cuando exista un identificador numérico estable (como un Event ID de Windows), utilízalo como referencia canónica.

5. Sobre qué objeto (Objetivo de la acción)

Una acción habitualmente afecta a un elemento concreto: un archivo del sistema de archivos, un proceso en memoria, una clave de registro, un puerto de red, una URL, un nombre de dominio o un bucket en la nube. Ese objeto se convertirá en nuestro punto de pivote analítico para continuar tirando del hilo.

6. Resultado de la operación (Outcome)

El resultado describe si la operación tuvo éxito o fue rechazada (login failed frente a login successful, traffic ALLOW frente a traffic DROP). Éxito no significa benigno: una autenticación maliciosa ejecutada con credenciales legítimas robadas mediante phishing se registrará técnicamente como exitosa.

7. Contexto adicional de correlación

Aquí reside la diferencia entre una lectura superficial y un análisis técnico profundo. Dependiendo del tipo de registro, buscaremos campos enriquecidos como:

source.ip / destination.ip
source.port / destination.port
process.name / process.command_line
parent.process.name / parent.process.entity_id
user.domain / logon.type
event.code / event.outcome

Cuanto mejor estructurados y normalizados estén los campos, más sencillo resultará cruzarlos entre múltiples sistemas.

4. Los tipos de logs que más vas a utilizar en Blue Team #

Intentar almacenar absolutamente toda la telemetría generada en una organización corporativa rara vez es viable técnica o económicamente. Una estrategia defensiva razonable prioriza aquellas fuentes que ofrecen mayor visibilidad sobre identidades, endpoints críticos, comunicaciones perimetrales y servicios en la nube.

A. Logs de autenticación e identidad

Responden a las preguntas básicas de control de acceso: ¿quién intentó autenticarse?, ¿desde qué dirección de red?, ¿el intento funcionó?, ¿se requirió un segundo factor de autenticación (MFA)?, ¿se elevaron privilegios?, ¿se creó, eliminó o deshabilitó alguna cuenta? Son esenciales porque una gran proporción de los ataques termina interactuando con la capa de identidad.

B. Logs de Windows (Security Event Log)

El registro de seguridad de Windows permite auditar una variedad enorme de comportamientos del sistema operativo. Si necesitas profundizar en los identificadores clave, consulta nuestra guía especializada en Windows Event Logs y Event IDs. Dos ejemplos fundamentales:

• Event ID 4624: Inicio de sesión correcto (audita tipo de logon, cuenta de origen, estación e IP).
• Event ID 4625: Inicio de sesión fallido (audita el código de estado específico del error, como contraseña incorrecta o cuenta deshabilitada).

No los memorices como números aislados. Aprende primero qué pregunta resuelven. Si recibes veinte eventos 4625 y después un 4624 para la misma cuenta, la pregunta útil no es «¿qué significa el ID 4624?», sino: «¿por qué una cuenta que acumulaba veinte fallos consecutivos acaba de autenticarse con éxito, desde qué dirección IP lo hizo y qué proceso ejecutó a continuación?». Esa forma de razonar escala mucho mejor que intentar memorizar cientos de identificadores.

C. Logs de procesos y Sysmon

El registro de creación de procesos permite comprender qué programas se ejecutaron y, cuando disponemos de suficiente telemetría, cómo se relacionan jerárquicamente entre sí.

Un árbol de procesos habitual y benigno podría ser:

explorer.exe
 └── chrome.exe

Mientras que una relación como la siguiente amerita una revisión inmediata:

winword.exe
 └── powershell.exe

No porque PowerShell sea malware en sí mismo. PowerShell es una herramienta administrativa legítima utilizada a diario en administración de sistemas. Lo relevante es el contexto: qué proceso lo inició (un procesador de texto), con qué argumentos en la línea de comandos, bajo qué cuenta de usuario y qué conexiones de red abrió posteriormente.

La telemetría de Sysmon (System Monitor) de Microsoft Sysinternals amplía sustancialmente esta visibilidad en endpoints Windows. Entre otros eventos críticos, registra:

• Event ID 1: Creación de procesos con línea de comandos completa, directorio de trabajo y hashes criptográficos (MD5, SHA256).
• Event ID 3: Conexiones de red originadas por procesos locales (con IP, puerto y protocolo).
• Event ID 11: Creación de archivos (útil para detectar descargas o persistencia).
• Event ID 22: Consultas DNS generadas por aplicaciones específicas del host.

D. Logs de Linux

En sistemas basados en Linux podemos auditar autenticaciones SSH, elevación de privilegios con sudo, actividad de servicios, llamadas al kernel, tareas programadas (cron) y aplicaciones web. Dependiendo de la distribución y su configuración de logging, encontraremos estos datos consultando el diario de systemd o revisando archivos en texto plano bajo /var/log/:

# Consultar eventos del servicio SSH mediante journalctl
journalctl -u ssh -n 50 --no-pager

# Buscar intentos fallidos de contraseña en distribuciones tipo Debian/Ubuntu
grep "Failed password" /var/log/auth.log

# En distribuciones basadas en RHEL/CentOS/Rocky Linux
grep "Failed password" /var/log/secure

No conviene estudiar Linux pensando únicamente en una ruta de archivo fija. Las ubicaciones exactas y los mecanismos de recolección (Syslog tradicional, rsyslog, journald) varían según el sistema operativo. Lo importante es saber qué subsistema genera el evento que estás investigando.

E. Logs de firewall

Un cortafuegos perimetral o de host registra decisiones de filtrado basadas en reglas de red:

SOURCE 10.10.20.15 DESTINATION 203.0.113.50 DST_PORT 443 PROTOCOL TCP ACTION ALLOW

Ese registro demuestra que existió una decisión de red en la capa de transporte. No demuestra automáticamente qué aplicación originó la conexión ni qué contenido viajó cifrado dentro del túnel TLS. Para responder a esas preguntas necesitarás correlacionar el evento con telemetría de endpoint y conocimientos sólidos de redes para ciberseguridad.

F. Logs de DNS

El protocolo DNS es una de las fuentes más enriquecedoras en investigaciones defensivas porque la inmensa mayoría del malware necesita resolver un nombre de dominio antes de establecer comunicación con su servidor de comando y control (C2):

HOST: WS-FINANZAS-023 QUERY: update-example.net TYPE: A ANSWER: 203.0.113.50

A partir de ese registro podemos plantearnos preguntas clave: ¿qué equipo realizó la consulta?, ¿qué proceso concreto la provocó?, ¿otros equipos de la red preguntaron por el mismo dominio?, ¿la consulta ocurrió inmediatamente antes de una conexión externa?, ¿es un dominio habitual para ese host?

G. Logs de proxy y tráfico web

Los proxies web y gateways perimetrales aportan visibilidad sobre el tráfico HTTP y HTTPS inspeccionado: URL completa consultada, dominio, método HTTP (GET, POST), cabecera User-Agent, código de respuesta HTTP (200, 403, 404), volumen de bytes transferidos y categoría del sitio web. Resultan indispensables para investigar campañas de phishing, descargas de payloads y canales de exfiltración web.

H. Logs de plataformas cloud

En infraestructuras en la nube (AWS, Microsoft Azure, Google Cloud) la investigación defensiva se traslada frecuentemente al plano de control. Herramientas como AWS CloudTrail o Azure Activity Logs registran llamadas a las APIs de administración: creación o borrado de máquinas virtuales, cambios en grupos de seguridad, asignación de roles y generación de claves de acceso. Un servidor puede no haber sido comprometido localmente y, sin embargo, un atacante con credenciales cloud válidas puede haber modificado toda la arquitectura desde la consola de gestión.

5. Cómo analizar logs: un método repetible en 7 pasos #

Abrir un panel de SIEM y comenzar a escribir filtros sin un objetivo concreto suele terminar en una montaña abrumadora de resultados sin valor. El análisis profesional requiere un método estructurado:

6. Caso práctico: investigar una autenticación sospechosa en Windows #

Supongamos que durante el turno de monitorización recibes una alerta de anomalía de acceso en el controlador de dominio. Al inspeccionar el visor de eventos observamos varios registros fallidos seguidos de un éxito:

Event ID: 4625
Time: 2026-10-03 08:14:03
Account Name: operador
Source Network Address: 198.51.100.72
Failure Reason: Unknown user name or bad password

Event ID: 4625
Time: 2026-10-03 08:14:28
Account Name: operador
Source Network Address: 198.51.100.72
Failure Reason: Unknown user name or bad password

Event ID: 4624
Time: 2026-10-03 08:15:31
Account Name: operador
Source Network Address: 198.51.100.72
Logon Type: 10 (RemoteInteractive / RDP)

El patrón llama la atención de inmediato, pero no debemos apresurarnos a emitir una conclusión categórica. Siguiendo el método, formulamos preguntas sucesivas:

1. ¿Es habitual esa dirección IP para el usuario? Comprobamos el historial de accesos de operador durante los últimos 30 días. Si la IP pertenece a un rango residencial nunca visto antes o a un nodo de salida VPN comercial, la probabilidad de anomalía se incrementa.
2. ¿Qué tipo de inicio de sesión se produjo? El Logon Type 10 indica una sesión de escritorio remoto (RDP). Esto confirma interacción de usuario interactiva y no un servicio automatizado.
3. ¿Qué actividad realizó la cuenta inmediatamente después de ingresar? Pivotamos hacia la telemetría del equipo destino en ese intervalo.

Al revisar los eventos de creación de procesos (Sysmon Event ID 1) en la misma máquina a las 08:16:10, localizamos:

UtcTime: 2026-10-03 08:16:10.125
ParentImage: C:\Program Files\Microsoft Office\root\Office16\WINWORD.EXE
Image: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
CommandLine: powershell.exe -NoP -NonI -W Hidden -Enc SQBFAFgA...
User: DOMINIO\operador

Ahora disponemos de una correlación robusta: una sesión interactiva sospechosa precedida de fallos de contraseña da paso a un documento Word que ejecuta PowerShell de manera oculta y con parámetros codificados en Base64. A partir de aquí podemos extraer el payload decodificado, buscar las conexiones de red asociadas en el firewall perimetral y proceder a la contención del host.

Fíjate en el aprendizaje central: ninguno de esos eventos, aislado, demuestra por sí solo una intrusión. La fuerza de la investigación reside en la secuencia temporal y en la relación entre ellos.

7. Por qué la hora y la sincronización temporal son críticas #

Considera estos tres eventos registrados en distintos dispositivos de una misma red corporativa:

Servidor A  → 21:03:17
Firewall    → 19:03:19
EDR         → 21:03:22

¿Significa esto que la conexión en el cortafuegos ocurrió dos horas antes que el evento en el servidor? Muy probablemente no. Es muy habitual que el cortafuegos registre en horario UTC (Tiempo Universal Coordinado) mientras que los servidores locales registran en huso horario local (UTC+2), o que alguno de los sistemas tenga su reloj desfasado.

Para correlacionar telemetría distribuida de forma veraz debemos considerar cinco factores técnicos:

• Sincronización NTP (Network Time Protocol): Todos los servidores, enrutadores, estaciones y dispositivos de seguridad deben sincronizar periódicamente con fuentes horarias fiables y estratos consistentes.
• Zona horaria unificada: La recomendación de la industria es almacenar y normalizar todos los registros centrales en UTC, convirtiendo a hora local únicamente en la interfaz visual de visualización del analista.
• Precisión del timestamp: En incidentes de ejecución rápida (como scripts automatizados o inyecciones de memoria), la precisión en segundos resulta insuficiente; se requieren marcas de tiempo con precisión de milisegundos o microsegundos.
• Momento de generación vs. momento de ingestión: El timestamp en que un evento ocurre en el host puede diferir del instante en que el agente lo transmite y el SIEM lo indexa. Es indispensable documentar ambos campos.

Las agencias internacionales de ciberseguridad (incluyendo CISA, la NSA y el ACSC de Australia) en su guía conjunta sobre buenas prácticas de registro de eventos y detección de amenazas destacan la sincronización temporal precisa y el uso de UTC como uno de los requisitos fundamentales para garantizar la integridad de las investigaciones forenses.

8. Centralización de logs y normalización: cuando cada fabricante habla un idioma distinto #

En una infraestructura de diez equipos, revisar eventos localmente accediendo por SSH o mediante el Visor de Eventos de Windows puede resultar viable. Cuando una organización opera con 5.000 estaciones de trabajo, 300 servidores, 40 cortafuegos y múltiples plataformas cloud, ese enfoque manual resulta inviable.

Aquí surge la necesidad de la centralización mediante plataformas SIEM (Security Information and Event Management). Un SIEM ingesta telemetría masiva de diversas tecnologías, almacena los registros de forma segura para evitar manipulaciones locales, permite ejecutar búsquedas analíticas complejas y dispara reglas de detección en tiempo real.

Sin embargo, centralizar los registros no equivale automáticamente a entenderlos. El SIEM acelera el análisis; no sustituye el criterio técnico necesario para interpretar los datos. Para comprender cómo interactúan estas herramientas con la automatización en el SOC, puedes profundizar en nuestra guía sobre SIEM vs SOAR: diferencias, ejemplos y qué debe aprender un analista SOC.

El desafío de la normalización: Elastic Common Schema (ECS)

Cada fabricante estructura sus campos según convenciones propias:

• Un firewall de un fabricante puede denominar a la dirección de origen como src_ip.
• Un proxy web puede etiquetarla como client_ip.
• Un sistema de autenticación puede llamarla sourceAddress.

Si un analista quisiera buscar todas las conexiones originadas por la IP 198.51.100.72, tendría que escribir consultas con múltiples sinónimos sintácticos. Los esquemas normalizados resuelven este problema mapeando campos equivalentes hacia un modelo de datos común.

Un estándar ampliamente adoptado en la industria es el Elastic Common Schema (ECS), que define campos estructurados y coherentes:

source.ip: 198.51.100.72
destination.ip: 203.0.113.50
user.name: mlopez
host.name: WS-FINANZAS-023
event.category: authentication
event.type: start
event.outcome: failure

Normalizar no significa alterar el mensaje original del log (que debe conservarse intacto por razones de custodia forense); significa que la capa analítica permite buscar conceptos uniformes independientemente de qué tecnología produjo el evento.

9. Qué logs deberíamos priorizar en una organización #

No existe una lista universal perfecta aplicable a todas las empresas. El alcance del registro depende de los activos críticos, las amenazas identificadas y el presupuesto disponible. Como criterio práctico orientado a la defensa en profundidad, suele tener sentido estructurar la visibilidad en niveles de prioridad:

La pregunta correcta para definir la política de logging no es: «¿cómo almacenamos todos los logs posibles?». La pregunta correcta es: «¿qué actividad necesitamos ser capaces de reconstruir de forma fehaciente cuando ocurra un incidente?».

10. Errores habituales al trabajar con logs (Antipatrones) #

Analizar registros de seguridad requiere experiencia y disciplina mental. Estos son los fallos metodológicos más recurrentes en equipos defensivos:

• Recopilar mucho y comprender poco: Almacenar terabytes de datos no aporta valor defensivo si el equipo no sabe qué eventos genera cada sistema ni cómo consultarlos.
• No sincronizar los relojes: Una línea de tiempo construida con servidores desfasados temporalmente distorsiona por completo la secuencia de los hechos y puede invalidar un informe forense.
• Registrar localmente pero no centralizar: Si un atacante compromete un servidor con privilegios de administrador, lo primero que intentará será vaciar o manipular los logs locales (wevtutil cl Security o borrado de /var/log). Si los eventos no se transmiten en tiempo real hacia un almacenamiento remoto protegido contra escritura, la evidencia desaparece.
• Conservar logs durante un periodo insuficiente: Muchas intrusiones avanzadas tardan semanas o meses en ser descubiertas. Una política de retención de solo 7 o 15 días impide investigar el vector de acceso inicial. La retención debe responder a necesidades operativas, riesgo y obligaciones normativas.
• Almacenar información sensible innecesaria: Los registros pueden llegar a capturar contraseñas escritas accidentalmente en el campo de usuario, tokens de sesión o datos personales confidenciales. Es indispensable aplicar filtrado y enmascaramiento para cumplir con marcos como el RGPD.
• Considerar sospechoso todo lo que falla: Los sistemas informáticos producen errores constantemente por fallos de red transitorios o dependencias obsoletas. Un error técnico no equivale a un ciberataque.
• Considerar benigno todo lo que funciona: Un inicio de sesión correcto puede ser resultado de credenciales robadas; una conexión autorizada por el cortafuegos puede conectar con un servidor malicioso en el puerto 443. La palabra SUCCESS o ALLOW describe el resultado técnico de la regla, no su legitimidad.
• Memorizar códigos de eventos sin entender el comportamiento: Memorizar números de Event ID ayuda a trabajar más rápido, pero comprender a fondo cómo funcionan la autenticación, los subprocesos de memoria y los protocolos de red es lo que realmente permite resolver investigaciones complejas.

11. Cómo practicar análisis de logs desde cero (4 Laboratorios) #

No necesitas disponer de una infraestructura corporativa empresarial para dominar el análisis de telemetría. Puedes desplegar un laboratorio virtualizado gratuito en tu propio ordenador con una máquina virtual Windows, una máquina Linux y una plataforma de recolección (como el stack de Elastic o Wazuh):

12. Cómo encajan los logs en el trabajo de un analista SOC #

Los logs no operan de forma aislada; son un eslabón fundamental dentro de una cadena técnica mucho más extensa:

Redes ↓ Windows / Linux ↓ Identidad ↓ Logs y telemetría ↓ SIEM / EDR ↓ Detección ↓ Triage ↓ Investigación ↓ Incident Response

Intentar aprender el manejo de una consola SIEM antes de comprender qué datos reflejan los sistemas operativos y los protocolos de red suele ser un error habitual. Una herramienta de monitorización es tan útil como la capacidad del profesional para interpretar la información que muestra.

Si tu objetivo profesional es incorporarte a un equipo de operaciones de seguridad, consulta nuestra guía completa sobre qué necesita saber un analista SOC para conocer las competencias y herramientas requeridas en el mercado laboral, o utiliza el Blue Team roadmap para estructurar todo tu itinerario formativo.

13. Preguntas frecuentes sobre logs de seguridad (FAQs) #

Respuestas directas a las dudas conceptuales y técnicas más habituales:

¿Qué es un log de seguridad? #

Es un registro de eventos producido por un sistema operativo, aplicación, dispositivo de red o servicio cloud que permite auditar y comprender actividades relevantes para la seguridad de la información. Puede documentar autenticaciones, creación de procesos, conexiones de red, modificaciones de archivos, errores y cambios administrativos.

¿Qué logs analiza un SOC? #

Depende de la arquitectura de la organización, pero es habitual trabajar con registros de sistemas de identidad (Active Directory, Azure AD/Entra ID), eventos de endpoints Windows y Linux, telemetría de EDR, cortafuegos perimetrales, servidores DNS, proxies web, registros de servidores de correo electrónico y auditoría de llamadas API en plataformas cloud.

¿Cuál es la diferencia entre un log y una alerta? #

El log es el registro histórico de que algo ocurrió en el sistema (actividad neutra). Una alerta aparece cuando una regla de detección o algoritmo analiza uno o varios logs y determina que ese patrón coincide con un comportamiento anómalo o sospechoso que amerita revisión humana.

¿Necesito memorizar los Event ID de Windows? #

No es necesario memorizarlos todos. Es útil familiarizarse con los más frecuentes (como el 4624 de logon correcto o el 4625 de logon fallido), pero resulta infinitamente más relevante comprender qué comportamiento estás investigando y saber consultar la documentación técnica oficial para interpretar cualquier evento particular.

¿Para analizar logs necesito aprender primero un SIEM? #

No necesariamente. El SIEM facilita la búsqueda y correlación a gran escala, pero la base fundamental reside en entender sistemas operativos, redes y la estructura de los eventos individuales. Dominar solo la interfaz gráfica de un software sin entender la telemetría conduce a aplicar filtros mecánicos sin saber interpretar los resultados.

¿Cuánto tiempo deberían conservarse los logs? #

No existe una cifra fija universal aplicable a todas las empresas. El periodo de retención debe definirse considerando las necesidades de investigación de incidentes, el nivel de riesgo de los activos, la capacidad de almacenamiento disponible y las obligaciones legales o sectoriales específicas aplicables a cada organización.

14. Conclusión: la pregunta del analista #

Un log no responde automáticamente si ha ocurrido un ataque informático. Lo que aporta es evidencia objetiva.

La diferencia entre limitarse a observar registros y analizarlos profesionalmente surge cuando comienzas a relacionar tiempo, identidad, activos, procesos y comunicaciones de red para reconstruir una narrativa coherente y verificable.

Cuando te enfrentes a tu próximo registro de seguridad, intenta no empezar preguntando de inmediato: «¿esto es malicioso?». Empieza con una pregunta mucho más sobria y disciplinada:

«¿Qué ocurrió exactamente y qué evidencia técnica necesito para demostrarlo?»

Esa pregunta es incomparablemente más rigurosa, y constituye el cimiento sobre el cual se construye todo el trabajo posterior de un analista SOC de primer nivel.

15. Fuentes primarias y estándares técnicos revisados #

• ASD's ACSC, CISA, FBI, NSA & socios internacionales: Best practices for event logging and threat detection (Publicado en agosto de 2024; marco de referencia para centralización, integridad y sincronización temporal).
• NIST (National Institute of Standards and Technology): NIST SP 800-92: Guide to Computer Security Log Management (Guía final de 2006) y su actualización preliminar en borrador público NIST SP 800-92 Rev. 1: Cybersecurity Log Management Planning Guide (Initial Public Draft) (Publicado en octubre de 2023).
• Microsoft Learn: Documentación oficial de auditoría de seguridad para Event ID 4624, Event ID 4625 y System Monitor (Sysmon).
• Elastic: Elastic Common Schema (ECS) Reference (Especificación oficial para la normalización de telemetría de eventos).

Última revisión técnica: 07 de octubre de 2026.

---