En las últimas semanas, la conversación sobre ciberseguridad cambió de tono. Este 1 de julio, investigadores de Sysdig documentaron el primer ataque de agentic ransomware, un caso inédito en el que un agente de IA, identificado como JADEPUFFER, ejecutó de forma autónoma todo el ciclo de extorsión, desde el reconocimiento hasta la entrega de la nota de rescate, pasando por la explotación, el movimiento lateral, el robo de credenciales y el cifrado.
El hallazgo confirma que los ataques han pasado de automatizar tareas a razonar, corregir errores y avanzar sin intervención humana. A ello se suma la rapidez que ya se venía detectando: en febrero pasado, CrowdStrike reportó que el tiempo que tardan los atacantes en pasar de una intrusión inicial a un compromiso total se ha desplomado a 29 minutos, con casos extremos de apenas 27 segundos. Este ritmo, combinado con ataques que razonan y persisten por sí solos, convierte en urgente la necesidad de evaluar cómo están construidos los sistemas de los proveedores y qué tan verificables son las afirmaciones de seguridad de cada proveedor.
Todos afirman que sus productos son "seguros" hasta cierto punto, pero el término ha perdido su significado. La seguridad se ha convertido en un slogan mercadológico en lugar de una propiedad medible. En los sistemas de respaldo y almacenamiento, donde hay más riesgos, la transparencia es la única forma de transformar la seguridad de un simple slogan en algo que las organizaciones puedan evaluar.
Los administradores deben comprender lo que afirma un proveedor, en qué supuestos se basan esas afirmaciones, qué arquitectura está diseñada para resistir y cómo se han validado tales objetivos.
Para evaluar las arquitecturas de Zero Trust y Zero Trust Data Resilience (ZTDR), los proveedores deben explicar qué creen que pasará y que no pasará durante un ataque y cómo se comporta su sistema cuando se ponen a prueba tales supuestos. Sin esa claridad, las empresas se ven obligadas a interpretar garantías vagas en lugar de pruebas concretas.
El modelo Zero Trust suele reducirse a un conjunto de medidas de seguridad, como la autenticación multifactor (MFA), TLS y el control de acceso basado en roles; con todo, el principio fundamental que más importa es la mentalidad de asumir la vulnerabilidad, tanto la del entorno de red, como la del propio producto del proveedor. Si un atacante obtiene acceso administrativo, roba credenciales o suplanta la identidad de un operador, el sistema de almacenamiento debe seguir protegiendo los datos de respaldo. Un diseño Zero Trust no tiene éxito cuando hay partes involucradas que no adoptan la mentalidad de asumir la vulnerabilidad.
Por eso, las decisiones de arquitectura son más importantes que las listas de verificación de seguridad. Se debe aplicar el mínimo nivel de privilegios para que ningún individuo pueda destruir los datos de respaldo de una organización.
En Object First defendemos con pasión el concepto de Zero Trust y lo demostramos mediante pruebas independientes que comprueban que el sistema se comporta según lo previsto, incluso cuando se conocen todos los secretos.
Transparencia, elemento históricamente desaconsejado
Las pruebas de seguridad significativas requieren independencia, transparencia y repetibilidad. Las pruebas internas del proveedor por sí solas son insuficientes, ya que no pueden separarse de las presiones e incentivos internos. En este contexto, las pruebas independientes realizadas por terceros brindan una evaluación externa de si el sistema se comporta como se afirma, especialmente en condiciones adversas. No está de más decir que estos informes deben publicarse íntegramente, en lugar de únicamente extraer fragmentos para crear una fachada positiva artificialmente construida.
Las empresas también deberían tener la opción de probar el sistema por sí mismas o contratar a un tercero para que lo haga. Muchas organizaciones no tendrán el tiempo ni los recursos para realizar dichas pruebas, pero la capacidad de hacerlo es esencial. Si el acuerdo de licencia de un proveedor prohíbe las pruebas, esa restricción debe considerarse una señal de alerta. Un sistema que no se puede probar no es confiable.
La mayoría de los negocios no tienen el tiempo ni la experiencia para validar cada afirmación de seguridad. Por eso, los proveedores deben proporcionar pruebas y ganarse la confianza, no darla por sentada.
¿Cómo andamos el camino en Object First? Para nosotros, las pruebas independientes son también la única forma confiable de validar las afirmaciones sobre inmutabilidad, acceso cero y segmentación. Estas características no pueden evaluarse únicamente mediante documentación; deben demostrarse mediante pruebas de penetración externas que simulen las condiciones de un ataque de ransomware real. Esto es especialmente importante para la inmutabilidad absoluta, que presupone que el atacante conoce toda la información del administrador y, aun así, no puede alterar ni eliminar los datos de respaldo.
El almacenamiento de respaldo debe servir como última línea de defensa cuando fallan todos los demás controles, y como primera línea de recuperación cuando la organización necesita recuperar sus datos.
La importancia de una documentación abierta y de definir la superficie de ataque
Un proveedor también debe poder definir claramente su superficie de ataque. Sin esta definición, ni las pruebas internas ni las externas resultan útiles. Un sistema de almacenamiento de respaldo bien diseñado tiene una superficie de ataque reducida y bien definida, con límites, protocolos y comportamientos claramente documentados.
Si un proveedor no documenta estos componentes, está pidiendo a las organizaciones que confíen en una caja negra. Sin documentación, las empresas no pueden comprender cómo funciona el sistema, qué vulnerabilidades expone ni cómo debe evaluarse; es decir, se quedan en la ignorancia sobre el diseño y el comportamiento del sistema.
La documentación oculta o incompleta crea un riesgo simple pero grave: los negocios desconocen en qué se basan. No pueden probar lo que no ven ni evaluar lo que no definen. La transparencia no implica abrumar a los equipos de TI y Seguridad con detalles innecesarios; requiere documentar la superficie de ataque real y mantener dicha documentación alineada con patrones de implementación y modelos de amenazas creíbles.
El otro gran punto: la evaluación de los compradores
Al final, todo proveedor pide a sus clientes que confíen en él; la cuestión es ¿se ha ganado esa confianza? Los equipos de TI y Seguridad deben buscar explicaciones claras de la arquitectura de seguridad del proveedor y esperar una definición de la superficie de ataque, incluyendo documentación que refleje el uso en el mundo real y términos de licencia que permitan realizar pruebas independientes.
Lo más importante es que los clientes deben esperar pruebas independientes de terceros que validen la inmutabilidad del sistema, los controles de acceso cero y la segmentación en condiciones adversas. También deben buscar el compromiso del proveedor con la iniciativa CISA Secure by Design, que indica su voluntad de abordar los retos de seguridad de forma transparente.
Evaluar las afirmaciones de seguridad de los proveedores es una tarea fundamental para los compradores. Lo que los proveedores afirman debe estar respaldado por sus acciones, no por palabras. La transparencia es lo que convierte esas afirmaciones en algo verificable.
