El registro y su ausencia

Que un registro no muestre un evento no prueba que el evento no ocurriera. Solo prueba que no se capturó, y la diferencia importa: si el registro estuvo apagado, estaba mal configurado o no cubría ese servicio, la ausencia no dice nada. Un pentester que se lo cuenta al cliente como «no pasó» comete un error de método; el informe correcto separa lo demostrado de lo que no se puede afirmar y reporta el vacío como hallazgo.

En AWS un registro de auditoría puede cubrir una sola región o todas. Si cubre una sola, lo que ocurre en las demás no queda registrado. Para saber si hay un hueco hay que cruzar dos documentos: dónde hay recursos desplegados y qué regiones cubre el registro. El hallazgo es la región con datos importantes y sin cobertura.

En Azure, el registro de la suscripción se guarda por separado de los registros de cada servicio. Para el almacenamiento hay que activar el de lectura de blobs, y sin él no se sabe quién descargó qué. Cuando un contenedor está abierto al público y además no registra lecturas, la exposición no se puede medir ni después: el cliente jamás sabrá cuántas veces se descargó.

Entre los eventos de gestión exportados hay uno que no es una acción más: alguien detuvo el registro de auditoría. Apagar el registro es lo primero que haría quien quiere pasar desapercibido, aunque también puede ser un descuido o una tarea de mantenimiento. El informe no acusa: describe el evento, la identidad que lo ejecutó, el origen de la conexión y lo que se sabe y lo que no.

Tener la hora exacta de apagado y de reinicio permite medir cuánto tiempo quedó la cuenta sin registro. Esa cifra va en el informe porque es lo que el cliente necesita para decidir cuánto de ese día debe tratar como no verificable.

Calcula los minutos entre el evento que detuvo el registro y el que lo reanudó, en el mismo día.