Qué registra una aplicación y qué no

Una aplicación registra para poder contestar cuatro preguntas después de un incidente: qué pasó, quién lo hizo, desde dónde y a qué hora. Por eso lo que vale la pena escribir son los hechos que cambian el estado de la seguridad: los intentos de entrar (los que salen bien y los que fallan), el cierre de sesión, el cambio de contraseña, los cambios de permisos y de configuración, el acceso a datos sensibles y los errores que la aplicación no esperaba.

Cada línea necesita un mínimo para servir: la hora con su zona, la cuenta, el origen, el evento y su resultado. Una línea que dice «error» sin cuenta ni origen no ayuda a nadie.

El registro tiene su propio problema: todo lo que se escribe ahí lo leen más personas que las que leen la base de datos. El soporte, el equipo de operaciones, la herramienta de monitoreo y, si algo sale mal, quien se lleve el archivo. Una contraseña tecleada, un token o un número de documento en una línea de registro es una fuga con otro nombre. La debilidad se clasifica como CWE-532, inserción de información sensible en un archivo de registro.

Entre las líneas de la mañana de Ancuyo hay una advertencia de inicio de sesión fallido que guarda más de lo que debería. El marcador de la clave en el laboratorio es ficticio, pero el patrón es el real.

Registrar de más es un riesgo; registrar de menos es el otro, y es el que más cuesta en una investigación. La debilidad se llama registro insuficiente (CWE-778): el hecho ocurrió y no dejó huella. Los candidatos clásicos son los que nadie piensa hasta que hacen falta, como los cambios de permisos de una cuenta, que son justo lo que un intruso hace para quedarse.

El código de la aplicación define una lista de eventos que sabe emitir, y no todos llegan al registro. Compara esa lista con la categoría de cada evento.

El auditor clasifica antes de recomendar, porque la clasificación guía el arreglo. La línea que guarda la clave del usuario que falló es un caso de información sensible en un registro, no de un registro que falta ni de un registro que alguien pueda falsificar.

En la misma mañana, la línea de una actualización de cliente copia el documento de identidad y la fecha de nacimiento completos. La finalidad de ese registro es saber quién cambió qué, no guardar una segunda copia de los datos del cliente. Cuantos más datos personales viven en los registros, más lugares hay que proteger, más tiempo hay que conservarlos y más grande es el daño si se filtran. La ley colombiana de protección de datos personales (Ley 1581 de 2012) exige tratar los datos con una finalidad y con medidas de seguridad; un registro es un tratamiento más.

La salida práctica es registrar el hecho sin el valor: quién, qué entidad, qué campos cambiaron, con el identificador interno del cliente.