5min. read

«Zero Trust» (confianza cero), un término que muchas veces se entiende y se utiliza mal, representa un modelo que tiene verdadero potencial para ayudar a reducir los riesgos cibernéticos sistemáticos y mejorar la resiliencia.

La migración a la nube da una nueva oportunidad a las arquitecturas Zero Trust.

¿Qué es y qué no es el modelo Zero Trust?

Algunos proveedores afirman que el modelo Zero Trust (confianza cero) se reduce a la gestión de identidades y accesos, es decir, al modo en que una empresa autoriza a los usuarios a acceder a los recursos. Si bien este es un pilar fundamental del modelo Zero Trust, solo es un componente más de lo que se debería entender como una estrategia más amplia que tiene en cuenta todas las superficies de riesgo de la empresa en términos de identidad, infraestructura, producto, procesos y cadena de suministro.

Cualquier profesional de la seguridad le dirá que confiar en las redes y arquitecturas tecnológicas nunca ha sido una buena idea: una red de confianza conectada a la de su centro de datos puede sufrir un ataque, se puede hackear un endpoint, un usuario de confianza con las llaves de su reino puede tener malas intenciones, un troyano puede secuestrar un proceso autorizado del sistema operativo, un archivo de confianza puede resultar ser malicioso…

De ahí surge el modelo Zero Trust (confianza cero), que proporciona una metodología estratégica para eliminar toda confianza implícita que se haya establecido entre distintas entidades tecnológicas. Por poner un ejemplo: en el caso de una discoteca, se trataría de no solo poner porteros en la entrada, sino también dentro y en el aparcamiento, además de contratar a varios guardaespaldas que escoltasen a los clientes a la salida. Pero ¿en eso consiste simplemente el modelo Zero Trust? ¿Es solo una forma de reforzar la seguridad?

A decir verdad, la cuestión no es si las organizaciones deberían o no adoptar el modelo Zero Trust, sino por qué iba a funcionar esta vez y por dónde empezar, teniendo en cuenta su elevado coste y las reticencias al cambio.

El modelo Zero Trust para cisnes negros

Mi experiencia personal me dice que las organizaciones que lograron adoptar el modelo Zero Trust con éxito centraron sus programas, en primer lugar, en la gestión del riesgo, un ámbito que, tras haber trabajado más de una década para una gran organización de servicios financieros, conozco muy bien. Sobre todo sé que, a veces, pequeños eventos pueden ocasionar daños a toda una organización o, incluso, a todo un sector.

Últimamente, estos eventos sistemáticos, también conocidos como «cisnes negros», se han convertido en algo habitual en el metaverso de la ciberseguridad. Tanto el ransomware como los incidentes que afectan a la cadena de suministro pueden ser los síntomas más visibles de esos riesgos que vemos en las noticias día sí y día también. Precisamente, esos riesgos representan un buen punto de partida para su programa Zero Trust.

Si analizamos la causa principal de tal riesgo tecnológico sistemático, aparecen distintas variedades o, en el peor de los casos, una combinación de todas ellas:

  • Puntos de fallo únicos. Incluyen los componentes principales de la infraestructura que aglutinan toda su solución tecnológica. Una infraestructura Active Directory, WebSSO o DNS poco segura o mal diseñada puede convertirse rápidamente en una pesadilla.
  • Monocultivos de software obsoleto.Sistemas operativos, firmware y software con altas tasas de adopción entre las organizaciones que no se actualizan con regularidad. Una sola vulnerabilidad puede conllevar riesgos de ransomware o de sabotaje catastróficos.
  • Efecto de las redes planas.Una organización sin la segmentación ni los controles de red adecuados en sus sistemas de TI (piense en todos los dispositivos que tiene sin gestionar), TO e IdC es un blanco fácil para cualquier intruso, virus o ataque de ransomware.

La pirámide del modelo Zero Trust

Las empresas tradicionales que heredan varios de esos riesgos sistemáticos suelen empezar su programa Zero Trust a partir de dos pilares fundamentales: la armonización de su solución de gestión de identidades y accesos y la armonización de la conectividad. Estos serán los cimientos de otros componentes clave de la estrategia Zero Trust que responden a otros riesgos sistemáticos, como los monocultivos de firmware, las aplicaciones, etc.

Qué función desempeñan las plataformas en el modelo Zero Trust

Si tuviera que explicar la resiliencia en ciberseguridad, empezaría por aquí: para crear una organización resiliente, es necesario que la seguridad se conciba como un sistema, no como un componente más. Por ejemplo, en lugar de poner todas sus energías en probar la eficacia de los controles de su sandbox, priorice el modo en que ese sandbox se integra con los demás controles de seguridad del resto de su organización. O no se gaste millones de euros en someter su aplicación más crítica a pruebas de penetración si la aplicación está conectada, en la misma red, a un dispositivo IdC de un millón de euros y ejecuta varios servicios expuestos más en el servidor.

En un mundo descentralizado y fragmentado, en el que las cargas de trabajo y las identidades pueden residir en cualquier punto de Internet, un enfoque sistemático de la ciberseguridad se complicaría en demasía si no se armonizaran algunos factores clave necesarios para gestionar la seguridad:

  • Una solución común de políticas e identidades.
  • Un mismo parecer sobre las posibles amenazas.
  • Un protocolo/control común para aplicar su política y la información sobre amenazas en todo el sistema.

Phil Venables da su propia explicación en una entrada de blog reciente. Según él, «una de las técnicas de seguridad empresarial más eficaces que utilizan muchas organizaciones consiste en crear una base de controles universal que se apliquen en todas partes y, después, ir reduciendo el coste unitario de los controles (tanto de los preexistentes como de los nuevos) para aumentar dicha base de forma económica».

En su blog, pone de ejemplo el sector automovilístico y sugiere que la incorporación de las prestaciones de seguridad de los coches de carreras a los turismos puede extrapolarse a la ciberseguridad. De hecho, la seguridad de la red y la conectividad son un buen ejemplo.

Antes, la seguridad de la red se basaba en este principio: todo lo que estaba dentro de la organización era de confianza y todo lo de fuera no lo era; es decir, la seguridad solo se aplicaba en los límites de la organización. Ese modelo deja de funcionar desde el momento en que no cubre los requisitos del teletrabajo, la nube, el perímetro y el acceso remoto.

Todos esos entornos, aunque hoy en día se conectan directamente a la red de Internet, carecen hasta de los controles más básicos, como la segmentación y la detección de intrusiones. ¿El motivo? Que probar o implementar controles y políticas individuales encarece los costes y hace que la mayoría de los controles de ciberseguridad sean inasumibles para las organizaciones.

De ahí que las plataformas de ciberseguridad se estén revelando como la mejor estrategia para implementar el modelo Zero Trust y como un factor de diferenciación económica para la mayoría de los programas de ciberseguridad

La nube: una oportunidad para el modelo Zero Trust

Modernizar las soluciones de conectividad o seguridad obsoletas no es nada fácil y, si el cambio no está motivado por los programas de teletrabajo y de nube, algunas organizaciones se ven obligadas a hacerlo por las malas (porque son víctimas de un ataque de ransomware, por ejemplo). Pero esto abre una nueva oportunidad para su programa Zero Trust que no debería dejar pasar.

Ahora que las organizaciones están migrando cada vez más cargas de trabajo, aplicaciones y usuarios a la nube, por un lado, y adoptando la metodología DevOps, por el otro, es el momento perfecto de diseñar bien la arquitectura de su sistema de seguridad desde el principio, y no a posteriori. En este contexto, una metodología sistemática le exigiría replantearse, además de la seguridad de su entorno de producción, la protección de su ciclo de CI/CD y la integración de los controles de seguridad lo antes posible. Si se toma en serio la seguridad de sus entornos de DevOps y en la nube, debería plantearse las siguientes cuestiones en todas sus iniciativas Zero Trust:

  • ¿Confía en que el dispositivo de su ingeniero de software esté a salvo?
  • ¿Confía en que su repositorio de código esté a salvo?
  • ¿Cree que la integridad del código está garantizada a lo largo de todo el proceso de desarrollo e implementación?
  • ¿Confía en que la seguridad de su plantilla de infraestructura como código (IaC, por sus siglas en inglés) de terceros o del contenedor de Docker esté a salvo? Recuerde que, de media, la mitad de ellos contienen vulnerabilidades graves.
  • ¿Qué hay de las otras dependencias de aplicaciones de software que se utilizan en sus proyectos?
  • ¿Confía en que a sus identidades se les estén asignando los derechos de acceso adecuados?
  • ¿Confía en que se esté comprobando la seguridad de su código o si contiene errores de configuración (p. ej., credenciales codificadas de forma rígida, ajustes de red con privilegios excesivos, etc.)?
  • ¿Confía en que el orquestador de sus microservicios, por ejemplo, esté a salvo?

Aunque quedan muchas otras preguntas que responder, lo importante es tener siempre presente que, en los entornos de DevOps, los riesgos sistemáticos aumentan en dirección tanto vertical como horizontal. En vertical, hay muchos más riesgos que considerar comparado con otros entornos más tradicionales. En horizontal, un solo paquete infectado puede tener gravísimas consecuencias (tal y como hemos visto en numerosos casos, como el de SolarWinds).

Ahora que quiere adoptar una metodología DevOps y migrar a la nube, tiene una oportunidad de oro para implementar una estrategia Zero Trust desde el principio: aprovéchela.