Qué registrar y por cuánto tiempo: logging útil sin quebrar el presupuesto

Con los logs se cometen dos errores opuestos y ambos caros. Uno es registrarlo todo "por si acaso": el volumen se dispara, la factura de almacenamiento también, y encontrar algo útil se vuelve buscar una aguja en un pajar que tú mismo construiste. El otro es no registrar casi nada, y descubrir el día del incidente que no hay rastro de lo que pasó. El logging útil vive en medio, y ese medio es una decisión, no un default.

Qué registrar

La pregunta guía no es "¿qué puedo capturar?", sino "¿qué necesitaría para investigar un incidente o demostrar cumplimiento?". Con ese criterio, la prioridad suele ser clara:

• Seguridad y autenticación: accesos, intentos fallidos, cambios de privilegios. Es lo primero que se mira tras un incidente.
• Cambios de configuración: quién tocó qué y cuándo. La causa raíz suele esconderse aquí.
• Errores de sistemas críticos: lo que anticipa una caída.
• Eventos exigidos por cumplimiento: lo que una norma o contrato te obliga a poder mostrar.

Y con el nivel de detalle adecuado a cada fuente: no todo merece registro exhaustivo.

Por cuánto tiempo

La retención rara vez es un solo número. Lo habitual es un esquema por capas que equilibra acceso y costo:

• Caliente: consulta rápida para las semanas o meses recientes, que es cuando más se investiga.
• Frío: almacenamiento más barato para periodos largos, con acceso más lento.
• Archivo: largo plazo, cuando una regulación o contrato lo exige.

El plazo de cada capa sale de cruzar tres cosas: necesidad forense, obligaciones de cumplimiento y costo. Ignorar cualquiera de las tres desequilibra el diseño.

El log que decide una investigación

Un ejemplo que se repite con incómoda frecuencia. Tras un acceso no autorizado, la pregunta de oro es siempre la misma: ¿qué hizo el atacante una vez dentro y hasta dónde llegó? Si los logs de autenticación y de cambios de configuración existen y se conservaron el tiempo suficiente, la respuesta es una línea de tiempo reconstruible: entró aquí, escaló allá, tocó esto. Si esos registros se sobrescribieron a los siete días "para ahorrar disco", la respuesta es un encogimiento de hombros —y una notificación a clientes o reguladores que, sin evidencia, hay que redactar en el peor de los términos: "no podemos descartar que...". La diferencia entre esos dos desenlaces no la marcó un SIEM carísimo, sino haber decidido de antemano que los logs de seguridad se guardan meses y no días. Es una decisión barata de tomar en frío y carísima de lamentar en caliente —y es, además, lo que separa poder responder "esto fue lo que pasó" de solo poder responder "algo pasó".

El logging es la memoria del incidente

Cuando algo pasa, tu runbook de respuesta solo es tan bueno como los datos que puede consultar: sin los logs correctos, el triage es a ciegas. Por eso definir qué registrar y cuánto guardarlo no es un tema de almacenamiento, sino de capacidad de respuesta. Diseñar ese equilibrio —útil, defendible y sostenible en costo— es parte de nuestro NOC/SOC administrado. La meta no es tener más logs: es tener los que sirven cuando los necesitas.