Durante años, la pregunta dominante ha sido siempre la misma:
«¿Cómo evitamos el próximo ataque?»
Cortafuegos. EDR. Copias de seguridad. Zero Trust.
Todo importante. Todo necesario.
Pero hay una pregunta que casi nunca se plantea - y que solo aparece cuando ya es demasiado tarde:
¿Qué ocurre con sus datos cuando la seguridad falla?
Porque el fallo no es una posibilidad - es una certeza
Da igual lo madura que sea su arquitectura de seguridad.
Da igual el tamaño de su equipo, su presupuesto o sus proveedores.
Los incidentes ocurren.
Y cuando ocurren, el problema deja de ser técnico y pasa a ser existencial:
• ¿Podemos confiar en los datos que quedan?
• ¿Podemos demostrar qué se modificó - y qué no?
• ¿Son nuestros registros defendibles ante clientes, reguladores o un tribunal?
• ¿Pueden continuar las operaciones, o se paraliza todo?
La mayoría de las organizaciones descubre demasiado tarde que restaurar los sistemas no es lo mismo que restaurar la confianza.
Las copias de seguridad restauran datos. No restauran la verdad.
Cuando se produce un incidente, las copias de seguridad pasan a primer plano.
Pero hay una verdad incómoda que rara vez se dice:
Una copia de seguridad le dice lo que tiene. No le dice si es verdad.
Tras un incidente:
• Las auditorías se estancan
• Las posiciones jurídicas se debilitan
• Los reguladores pierden la confianza
• Los clientes dudan - o se marchan
• Un archivo restaurado puede haber sido alterado antes de hacerse la copia de seguridad.
• Un registro puede haber sido manipulado sin dejar pruebas.
• Un contrato puede existir - pero nadie puede demostrar cuándo, cómo o en qué estado existía.
Y sin pruebas, llegan las consecuencias:
El verdadero problema es la ambigüedad
El mayor enemigo tras un ataque no es el malware. Es la ambigüedad.
Cuando nadie puede decir con certeza:
• qué es válido,
• qué se ha visto comprometido,
• qué puede usarse como prueba,
la organización entra en parálisis operativa.
Los sistemas pueden volver a estar en línea.
Pero las decisiones se retrasan.
Los contratos se cuestionan.
Los informes se aplazan.
La confianza se evapora.
Aquí es donde importa la resiliencia - no como palabra de moda, sino como práctica
La resiliencia no consiste en evitar el fallo a toda costa. Consiste en aceptar que el fallo se producirá - y en diseñar sistemas que sigan funcionando pese a ello.
Una estrategia de ciberresiliencia responde a preguntas distintas:
• ¿Cómo demostramos la integridad de los datos, incluso después de un incidente?
• ¿Cómo mantenemos registros listos para auditoría mientras los sistemas están bajo ataque?
• ¿Cómo demostramos, de forma independiente y verificable, que la información es auténtica?
La resiliencia no empieza en el momento del ataque. Empieza antes, en cómo se crean, registran y validan los datos a lo largo de todo su ciclo de vida.
La seguridad protege. La resiliencia demuestra.
La seguridad intenta impedir que ocurra lo peor. La resiliencia garantiza que, cuando ocurre, la verdad sobrevive.
Y en un mundo regulado, litigioso y digital por defecto, la verdad - una verdad demostrable, verificable y lista para auditoría - es el activo más crítico que puede tener una organización.
En los próximos artículos, analizaremos:
• por qué las copias de seguridad y los logs no bastan,
• cómo demostrar la integridad a lo largo de todo el ciclo de vida de los datos,
• y qué significa realmente estar preparado para el «día después» de un incidente.
Porque cuando todo falla,
la cuestión no es si tiene datos - es si puede demostrar que son verdaderos.