Por qué Seguridad requiere transparencia

Todos los proveedores afirman que su producto es “seguro” hasta cierto punto, pero la palabra ha perdido significado. Seguridad se ha convertido en un descriptor de marketing más que en una propiedad medible. En los sistemas de copia de seguridad y almacenamiento, donde lo que está en juego es máximo, la transparencia es la única forma de convertir la seguridad de un eslogan en algo que las organizaciones puedan evaluar.  

Los administradores necesitan entender no solo lo que afirma un proveedor, sino en qué supuestos se basan esas afirmaciones, para qué está diseñada la arquitectura y cómo se han validado esos objetivos. 

Para evaluar arquitecturas de Zero Trust y Zero Trust Data Resilience (ZTDR), los proveedores deben articular qué asumen que ocurrirá durante un ataque, qué asumen que no ocurrirá y cómo se comporta su sistema cuando esos supuestos se ponen a prueba. Sin esa claridad, las organizaciones se quedan intentando interpretar garantías vagas en lugar de evidencia concreta. 

Cuando los proveedores no son transparentes, los clientes se ven obligados a separar la realidad del ruido. La transparencia es lo que les permite entender qué es realmente cierto. 

Zero Trust empieza por asumir que habrá una brecha.

Zero Trust a menudo se reduce a un conjunto de funcionalidades de endurecimiento como MFA, TLS y control de acceso basado en roles; sin embargo, el principio general que más importa es la mentalidad de “Asumir brecha”. Esto significa asumir el compromiso no solo del entorno de red, sino también del propio producto del proveedor. Si un atacante obtiene acceso administrativo, roba credenciales o suplanta a un operador, el sistema de almacenamiento debe seguir protegiendo los datos de copia de seguridad. Un diseño Zero Trust no puede tener éxito si todas las partes no adoptan la mentalidad de “Asumir brecha”.  

Si aceptas que no es cuestión de si ocurrirá, sino de cuándo, entonces debes estar preparado para recuperarte de un ataque en el peor escenario posible, no solo del esperado. 

Por eso las decisiones de arquitectura importan más que las listas de verificación de endurecimiento. Debe aplicarse el principio de mínimo privilegio para que ninguna persona por sí sola pueda destruir los datos de copia de seguridad de una empresa. La segmentación de funciones garantiza que el software de copia de seguridad y el almacenamiento de copias de seguridad no formen parte del mismo dominio de confianza.  

La segmentación de dominios de autenticación evita que un compromiso en un plano de identidad se propague en cascada a otro. Y la segmentación de red reduce las rutas que un atacante puede utilizar para alcanzar sistemas críticos. 

Las funcionalidades de endurecimiento no responden a la pregunta central: ¿Qué ocurre cuando el atacante ya tiene las llaves?  

Por eso Object First es un firme defensor de Zero Trust y lo demuestra mediante pruebas independientes que verifican que el sistema se comporta según lo diseñado, incluso cuando se conocen todos los secretos. 

Por qué históricamente se ha desincentivado la transparencia 

Las pruebas de seguridad con valor real requieren independencia, transparencia y repetibilidad. Las pruebas internas del proveedor por sí solas son insuficientes porque no pueden separarse de presiones e incentivos internos.  

Las pruebas independientes de terceros proporcionan una evaluación externa de si el sistema se comporta como se afirma, especialmente en condiciones adversarias. Estos informes deben publicarse íntegramente, no extraerse de forma selectiva para crear una fachada positiva construida de manera incorrecta. 

Las organizaciones también deberían tener la opción de probar el sistema por sí mismas o contratar a un tercero para hacerlo. Muchas organizaciones no tendrán el tiempo ni los recursos para realizar este tipo de pruebas, pero la capacidad de hacerlo es esencial. Si el acuerdo de licencia de un proveedor prohíbe las pruebas, esa restricción debe tratarse como una señal de alerta. Un sistema que no puede probarse no puede ser confiable. 

La mayoría de las organizaciones no tienen el tiempo ni la experiencia para validar cada afirmación de seguridad. Por eso los proveedores deben aportar evidencia y ganarse la confianza, no darla por sentada. 

Object First predica con el ejemplo 

Las pruebas independientes también son la única forma fiable de validar afirmaciones sobre inmutabilidad, Zero Access y segmentación. No son características que puedan evaluarse únicamente mediante documentación; deben demostrarse mediante pruebas de penetración externas que simulen las condiciones que se dan durante un ataque activo de ransomware. Esto es especialmente importante para la Inmutabilidad Absoluta, que asume que el atacante sabe todo lo que sabe el administrador y aun así no puede alterar ni eliminar los datos de copia de seguridad. 

El almacenamiento Backup debe servir como la última línea de defensa cuando fallan todos los demás controles, y como la primera línea de recuperación cuando la organización necesita recuperar sus datos. 

Documentación abierta y definición de la superficie de ataque 

Un proveedor también debe poder definir con claridad su superficie de ataque. Sin esta definición, ni las pruebas internas ni las externas pueden ser significativas. Un sistema de almacenamiento de copias de seguridad bien diseñado tiene una superficie de ataque pequeña y de alcance estrictamente acotado, con límites, protocolos y comportamientos claramente documentados. 

Un proveedor que no documenta estos componentes está pidiendo a las organizaciones que confíen en una caja negra. Sin documentación, las organizaciones no pueden entender cómo funciona el sistema, qué expone o cómo debe evaluarse. Cuando los proveedores evitan la documentación, en la práctica mantienen a las organizaciones “a oscuras” sobre cómo está diseñado el sistema y cómo se comporta. 

La documentación oculta o incompleta crea un riesgo simple pero grave: las organizaciones no saben en qué están confiando. No pueden probar lo que no pueden ver, y no pueden evaluar lo que no pueden definir. La transparencia no exige abrumar a los equipos de TI y seguridad con detalles innecesarios; exige documentar la superficie de ataque real y mantener esa documentación alineada con patrones de despliegue creíbles y modelos de amenazas. 

Cómo deberían evaluar los compradores las afirmaciones de seguridad de los proveedores 

En última instancia, todos los proveedores están pidiendo a los clientes que confíen en ellos. La cuestión es si esa confianza se gana. Los equipos de TI y seguridad deberían buscar explicaciones claras de la arquitectura de seguridad del proveedor, incluyendo qué asume el proveedor que ocurrirá y qué no ocurrirá durante un ataque. Deberían exigir una definición de la superficie de ataque, documentación que refleje el uso en el mundo real y términos de licencia que permitan pruebas independientes. 

Lo más importante es que los clientes deberían exigir pruebas independientes de terceros que validen la inmutabilidad del sistema, los controles de Zero Access y la segmentación en condiciones adversarias. También deberían buscar el compromiso de un proveedor con el compromiso CISA Seguro por diseño, que indica disposición a abordar los desafíos de seguridad de forma abierta. 

Las afirmaciones de un proveedor deben estar respaldadas por acciones, no por palabras. La transparencia es lo que convierte esas afirmaciones en algo verificable.