72 horas ante una brecha de datos: a dónde se va el tiempo en el lado del software

La notificación de una brecha se presenta como un proceso jurídico. Pero cuánto de ese plazo se pierde lo determina cómo se diseñó el sistema meses antes del incidente.

Una alerta llega a la mesa de una organización un lunes por la mañana: se ha detectado un acceso inusual en un servidor. A partir de ese momento, el reloj de las setenta y dos horas empieza a correr.

Setenta y dos horas suena a mucho tiempo. Lo que sigue es un relato hora a hora de adónde va realmente ese tiempo, porque sin ver ese desglose es difícil entender por qué la preparación frente a una brecha tiene que hacerse meses antes, no durante ella.

Las primeras ocho horas: ¿es esto realmente una brecha?

La primera tarea es determinar si la alerta es real. Puede ser un falso positivo, una operación de mantenimiento o un permiso mal configurado.

En esta fase, el equipo técnico revisa los registros. Si los registros no son lo bastante buenos, y en la mayoría de las organizaciones no lo son, esto se alarga. Sin saber qué cuenta accedió a qué tabla desde qué dirección, no se puede dar ningún paso posterior.

El primer punto crítico es este. Si no lleva registros, el reloj empieza a agotarse aquí, y ese tiempo no se recupera nunca.

Las siguientes veinticuatro horas: qué datos se vieron afectados

Una vez establecido que se trata de una brecha, surge una sola pregunta. ¿Qué datos personales había en ese servidor?

Una organización con un inventario actualizado responde a esto en diez minutos. Una que no lo tiene intenta averiguarlo examinando el esquema de la base de datos, comprobando nombres de tablas, extrayendo registros de muestra, preguntando a los desarrolladores. Solo eso puede llevar fácilmente un día entero.

La segunda mitad de la pregunta es más difícil. ¿Qué hay en las copias de seguridad? ¿Existe una copia que se exportó para un informe? ¿Se cargó una muestra en un entorno de pruebas? Si las respuestas no están escritas en ningún sitio, acaban basándose en suposiciones, y una notificación basada en suposiciones termina teniendo que corregirse después.

Las siguientes doce horas: a cuántas personas afecta

Una vez delimitado el alcance, hay que producir una cifra. Cuántos interesados, qué categorías de datos, qué zonas geográficas.

Un error frecuente aquí es redondear la cifra. Decir "aproximadamente diez mil personas" no hará que se rechace la notificación, pero que más tarde aparezca una cifra real bien distinta daña la credibilidad de lo declarado por la organización. Si no se puede obtener una cifra precisa, es mejor decirlo así, y explicar por qué, que aventurar una.

El tiempo restante: preparar y enviar la notificación

La notificación al Consejo debe cubrir cuándo y cómo ocurrió la brecha, qué categorías de datos se vieron afectadas, sus posibles consecuencias y las medidas adoptadas y previstas.

Redactar eso partiendo de una página en blanco consume el tiempo que quede. Una organización con una plantilla ya lista la rellena en media hora. Quién está autorizado a firmarla también debe decidirse de antemano, porque si esa discusión empieza en esta fase, no hay tiempo para ella.

Notificar a las personas afectadas es una tarea aparte. Se hace tan pronto como sea razonablemente posible una vez identificadas las personas afectadas; si el contacto directo no es posible, se recurre a otro medio adecuado. El lenguaje importa aquí. Un mensaje enterrado en detalle técnico impide que la persona entienda lo que realmente tiene que hacer.

Lo que el plan tiene que contener de verdad

La lección de este recorrido es esta. El valor de un plan de respuesta a incidentes está en haber pensado de antemano lo que hay que pensar en el momento del incidente.

Necesita un reparto claro de funciones. Quién delimita el incidente, quién decide que es una brecha, quién firma. Un plan que depende de una sola persona se hunde el día que esa persona está de baja.

Necesita un umbral definido. Qué se considera brecha debe estar escrito de antemano; de lo contrario, esa discusión ocurre dentro de las setenta y dos horas.

Necesita una regla de preservación de pruebas. El primer instinto suele ser limpiar los sistemas afectados, lo que hace imposible una investigación adecuada. El plan debe decir explícitamente que los registros se conservan intactos.

Necesita plantillas de comunicación ya preparadas, tanto para el Consejo como para los interesados afectados.

Nada termina cuando se envía la notificación

La notificación no es el fin de la obligación. El Consejo evalúa si las medidas técnicas y organizativas adoptadas fueron suficientes.

Una brecha que se repite en la misma organización se interpreta como prueba de que esas medidas no eran suficientes. Por eso la acción correctiva adoptada tras una brecha debe quedar registrada y su efecto debe medirse. La frase "se han tomado las medidas necesarias" no es, por sí sola, prueba de nada.

Lo único que merece la pena hacer hoy

Lo más rentable que puede hacer antes de sufrir una brecha es elaborar el inventario junto con la ubicación física de los datos: qué base de datos, qué tabla, qué campo y qué copia de seguridad contiene cada dato.

Si esa tabla existe, aproximadamente las primeras treinta de las setenta y dos horas quedan recuperadas de hecho. Si no existe, por bien redactado que esté el plan, el tiempo no alcanzará.