Qué datos salieron

4 tareas · 55 min · Principiante

18:40 UTC. La contención ya corre y la pregunta que viene es la que importa fuera del equipo técnico: qué se llevaron y a cuántas personas toca. El trail no lo dice, porque no registra la lectura de objetos; lo dice el registro de acceso del almacenamiento, otra fuente con otra forma. Tienes ese registro, el catálogo de depósitos y objetos, la política interna de incidentes de datos y la bitácora del caso. Cambia de consola: aquí se cuenta, no se busca. No hay un paso a paso y cada número que escribas va a un informe.

0 de 4 · 0%

Objetivo de la sala

Cuando un registro calla, otra fuente habla. El del almacenamiento anota cada lectura de objeto con quién la pidió, desde dónde y cuántos bytes salieron. El atacante tocó más de un depósito y no todos importan igual: se mide cuál se llevó la mayor parte de lo que salió, y se mira después qué contiene.

Suma por depósito lo que leyó la identidad que creó el atacante. No cuentes las lecturas de la rutina diaria, que son de otra cuenta.

Responde para continuar

Escribe el nombre del depósito del que la identidad creada por el atacante leyó más bytes.

Ver pista de ayuda

Filtra el registro por la identidad nueva y agrupa mentalmente por la parte del objeto que va antes de la barra. Compara las sumas de bytes.

La cifra que la gerencia va a leer es la de personas afectadas, y se cuenta con una regla de la política interna: cada objeto leído una sola vez, aunque se haya leído más de una. Dos errores son frecuentes: sumar las lecturas en vez de los objetos y sumar objetos que no tienen datos personales.

Cuenta solo lo que se confirmó leído y que contiene datos personales de clientes.

Responde para continuar

Escribe cuántos registros de clientes hay en los objetos leídos con éxito por el atacante, contando cada objeto una sola vez.

Ver pista de ayuda

Une el registro de acceso con la tabla de objetos. Quita las lecturas repetidas del mismo objeto y los objetos sin datos personales.

La última fila del registro es una lectura de datos personales con resultado denegado, hecha después de que se reactivó el trail. No salió ningún byte, pero el atacante lo intentó, y esa fila también cuenta algo. Hay que decidir qué hacer con ella en el informe: sumarla, ignorarla o leerla por lo que es.

La política interna dice qué se confirma como lectura. Léela antes de decidir.

Responde para continuar

La última fila del registro es una lectura denegada de un objeto con datos de clientes. ¿Cómo se trata?

Como una lectura más de datos personales, y se suma al conteo y se avisa de cuatro objetos leídos en vez de tres Como una lectura no confirmada que no suma clientes, pero que prueba que la sesión seguía viva y que el atacante seguía intentándolo Como ruido sin valor: un acceso denegado no deja información útil, así que se retira del informe para no confundir al lector ni a la gerencia

Ver pista de ayuda

Una lectura confirmada exige resultado ok. Pero el intento es un hecho, y dice cosas sobre la hora y sobre el atacante.

La política interna fija un plazo para avisar al responsable de datos y lo expresa en hora de Bogotá. El reloj no empieza cuando se produjo la lectura ni cuando llegó la alerta, sino cuando el equipo confirmó que hubo datos personales de por medio. La bitácora del caso tiene esa hora, y está en UTC.

Calcula la hora límite como se escribiría en el aviso: con la fecha y con el huso de la empresa.

Responde para continuar

Escribe la fecha y la hora límite del aviso al responsable de datos, en hora de Bogotá, con el formato AAAA-MM-DD HH:MM.

Ver pista de ayuda

Busca en la bitácora la hora de la confirmación y en la política cuántas horas dura el plazo. Suma el plazo y convierte el resultado a la hora de Bogotá.

Inicia sesión para registrar tus puntos y progreso en el ranking.

Entrar · Registrarse

1 A dónde fue a mirar Lab

2 A cuánta gente toca Lab

3 El intento que falló Lab

4 El plazo corre desde la confirmación Lab

Whoami-Labs Pro utiliza cookies