Cuando algo sale mal, se restaura.
Cuando se pierden datos, se recuperan.
Cuando los sistemas fallan, se vuelve a una versión anterior.
Las copias de seguridad son esenciales.
Pero, tras un ciberincidente, responden a la pregunta equivocada.
La verdadera pregunta no es «¿Podemos restaurar los datos?»
Es esta:
«¿Podemos demostrar que los datos siguen siendo verídicos?»
Recuperar no es lo mismo que verificar
Tras un incidente, las organizaciones se apresuran a volver a poner los sistemas en línea.
Las copias de seguridad cumplen su función: los archivos reaparecen, las bases de datos se restauran, los servicios se reanudan.
Pero falta algo crítico.
Una copia de seguridad puede decirle:
• qué datos existían en un momento determinado,
• qué versión se restauró,
• cuándo se realizó la restauración.
Lo que no puede decirle es:
• si los datos ya estaban comprometidos antes de la copia de seguridad,
• si los registros se alteraron de forma silenciosa,
• si la información es fiable como prueba.
La recuperación le da continuidad.
La verificación le da credibilidad.
La suposición peligrosa detrás de las copias de seguridad
La mayoría de las organizaciones opera bajo una suposición implícita:
«Si viene de una copia de seguridad, tiene que ser correcto.»
Tras un incidente, esa suposición se convierte en un riesgo.
Los atacantes no siempre borran los datos.
Los modifican. Con sutileza. De forma selectiva. Sin hacer ruido.
Un único campo alterado.
Una marca de tiempo cambiada.
Una cláusula modificada en un documento.
Las copias de seguridad lo conservan todo fielmente - incluidos los datos comprometidos.
Desde el punto de vista técnico, todo parece correcto. Desde el punto de vista jurídico, regulatorio o de auditoría, todo es cuestionable.
Los auditores no piden copias de seguridad. Piden pruebas.
Cuando intervienen auditores, reguladores o equipos jurídicos, no les interesa si la recuperación tuvo éxito.
Hacen otras preguntas:
• ¿Cómo sabe que este registro no fue alterado?
• ¿Puede demostrar que este documento existía exactamente en esta forma en ese momento?
• ¿Qué evidencias tiene de que estos datos son auténticos?
«Porque lo restauramos desde una copia de seguridad» no es una respuesta. Es una suposición - y las suposiciones no resisten el escrutinio.
Sin pruebas verificables:
• las auditorías se ralentizan o fracasan,
• los informes de cumplimiento se cuestionan,
• las posiciones jurídicas se debilitan,
• las decisiones se retrasan.
El problema no es el almacenamiento. Es la confianza.
La mayoría de las estrategias de seguridad se construyen en torno a proteger el almacenamiento:
• cifrar la base de datos,
• reforzar el control de acceso,
• replicar los datos,
• hacer copias de seguridad.
Todo necesario. Nada suficiente.
La confianza no depende de dónde se almacenan los datos.
Depende de si su integridad puede verificarse de forma independiente.
Tras un incidente, la confianza debe ganarse - no presuponerse.
Y la confianza que depende únicamente de sistemas internos es frágil, sobre todo cuando esos sistemas acaban de ser comprometidos.
La prueba debe existir fuera del radio de impacto
Si la única evidencia de la que dispone reside en los mismos sistemas que fueron atacados, no tiene evidencia - tiene incertidumbre.
Una prueba real tiene tres propiedades:
• Inmutable: no puede modificarse retroactivamente
• Con sello de tiempo: demuestra cuándo existió algo
• Independiente: sobrevive aunque fallen los sistemas internos
Sin estas propiedades, los datos pueden ser recuperables - pero no son defendibles.
Las copias de seguridad son necesarias. No son suficientes.
Esto no es un argumento en contra de las copias de seguridad.
Es un argumento en contra de confiar en ellas para algo para lo que nunca se diseñaron.
Las copias de seguridad tienen que ver con la disponibilidad.
La prueba tiene que ver con la integridad.
La continuidad sin credibilidad es frágil.
Y en entornos regulados, donde hay mucho en juego, la fragilidad es un riesgo que las organizaciones no pueden permitirse.
En el próximo artículo, analizaremos qué significa realmente demostrar la integridad de los datos desde el diseño - y por qué la verificación debe empezar en el momento de la creación, no después de un incidente.
Porque, tras una brecha de seguridad, la cuestión ya no es si recuperó los datos - sino si alguien puede confiar en ellos.