¿Qué es la confianza cero?

El modelo «Zero Trust» sustituye la confianza basada en la ubicación por una verificación continua. Mientras que el modelo perimetral consideraba por defecto que todo lo que se encontraba dentro de la red era de confianza, el modelo «Zero Trust» evalúa cada solicitud como si procediera de un lugar no fiable, independientemente de su origen real o de los permisos que se le hubieran concedido al mismo usuario una hora antes.

En la práctica, hay tres ideas que definen el modelo:

• No hay confianza implícita. La ubicación en la red no garantiza nada por sí sola, y el hecho de que una solicitud se encuentre dentro del cortafuegos no es prueba de que sea legítima.
• Verificación continua. La confianza se evalúa en cada solicitud, en lugar de establecerse una sola vez al iniciar sesión y mantenerse durante toda la sesión.
• Privilegio mínimo. El acceso se limita a lo que requiere una solicitud concreta y no va más allá de ello.

El modelo «Zero Trust» no es un producto que las organizaciones puedan adquirir. Se trata de una estrategia que abarca la identidad, los dispositivos, las redes, las aplicaciones y los datos, y no de una tecnología que se encuentre en una de esas capas concretas. Los proveedores que la presentan como un producto suelen estar describiendo un único componente de la arquitectura.

El término en sí se remonta a 1994, cuando Stephen Paul Marsh lo utilizó en una tesis doctoral sobre la confianza computacional en la Universidad de Stirling. Se popularizó en el ámbito de la seguridad en 2010, cuando el analista de Forrester John Kindervag publicó “No More Chewy Centers: Introducing the Zero Trust Model of Information Security” y defendió que la confianza era en sí misma una vulnerabilidad. El proyecto BeyondCorp de Google, iniciado en 2009, fue una de las primeras implementaciones a gran escala.

La norma NIST SP 800-207 define siete principios que debe cumplir cualquier arquitectura de confianza cero.

1. Todas las fuentes de datos y los servicios informáticos son recursos. Las bases de datos, las aplicaciones, los servicios SaaS, los dispositivos IoT y las estaciones de trabajo de los usuarios requieren protección, sin que se concedan excepciones en función de la ubicación o la importancia que se les atribuya.
2. Todas las comunicaciones están protegidas, independientemente de la ubicación de la red.. El tráfico que atraviesa la red interna se autentica y se cifra siguiendo el mismo estándar que el tráfico procedente de la Internet pública.
3. El acceso se concede por sesión.. La confianza se evalúa para la sesión en cuestión y no se traslada a otras, por lo que el acceso a un recurso no implica en modo alguno el acceso a otro.
4. El acceso viene determinado por una política dinámica. Las decisiones tienen en cuenta la identidad del cliente, el estado de la aplicación, la situación de los activos y los atributos de comportamiento y del entorno, en lugar de basarse en un conjunto de reglas estáticas.
5. La empresa supervisa el estado de seguridad de todos los activos. Por defecto, no se confía en ningún activo, y la integridad de los dispositivos se evalúa de forma continua para que pueda tenerse en cuenta en las decisiones de acceso.
6. La autenticación y la autorización son procesos dinámicos y se aplican de forma estricta antes de conceder el acceso.. La verificación funciona como un ciclo continuo de concesión, análisis, adaptación y reevaluación, en lugar de como un único control al inicio de una sesión.
7. La empresa recopila toda la información que puede y la utiliza para mejorar su situación.. Los datos de telemetría recopilados de los activos, la infraestructura y las comunicaciones se tienen en cuenta a la hora de definir las políticas que regulan el acceso.

También se difunde ampliamente un esquema más breve, compuesto por tres partes: verificar explícitamente, dar por hecho que se ha producido una brecha de seguridad y aplicar el principio del privilegio mínimo. Esa formulación tiene su origen en Microsoft y funciona razonablemente bien como resumen, pero no es lo que especifica realmente la norma SP 800-207, por lo que las organizaciones que se rijan por el NIST deben basarse en los siete principios anteriores.

Cada solicitud de acceso se intercepta y se resuelve en tiempo real, siguiendo una secuencia que se mantiene constante independientemente de quién haya desarrollado la pila subyacente:

1. Un interesado solicita acceso a un recurso, pudiendo ser dicho sujeto una persona, una cuenta de servicio, una carga de trabajo o un agente de IA.
2. Se recopilan las señales, incluyendo la identidad, el estado del dispositivo, la ubicación, la hora, el comportamiento previo y la información sobre amenazas.
3. Un motor de políticas evalúa la solicitud en contra de la política de la organización y una puntuación de riesgo calculada.
4. Se dicta y se ejecuta una resolución, conceder el acceso, denegarlo o reforzarlo con un factor de autenticación adicional.
5. La sesión está siendo supervisada, de modo que cualquier cambio en el nivel de riesgo dé lugar a una reevaluación y se pueda revocar el acceso mientras la sesión siga abierta.

Ese último paso es lo que distingue al modelo «Zero Trust» de los modelos que lo precedieron, ya que la seguridad perimetral toma una decisión en el límite y luego asume las consecuencias, mientras que el modelo «Zero Trust» sigue evaluando mientras dura la sesión.

La forma más clara de entender la diferencia es que una VPN amplía el perímetro, mientras que el modelo «Zero Trust» lo elimina por completo.

Cuando un usuario se conecta a través de una VPN tradicional, se le integra en la red corporativa y obtiene un amplio acceso a nivel de red basándose únicamente en una única verificación realizada en el momento de la conexión. Todo aquello a lo que se pueda acceder desde esa posición en la red queda al alcance de ese usuario y de cualquiera que consiga sustraer sus credenciales.

El modelo «Zero Trust» concede acceso a recursos concretos en lugar de a redes, por lo que la autorización para acceder a una aplicación no se extiende a otros recursos. Cada solicitud se reevalúa en función de las condiciones de riesgo actuales.

La Publicación Especial 800-207 del NIST, publicada en agosto de 2020, es la arquitectura de referencia en la que se basan la mayoría de las organizaciones. Establece una distinción clara entre los componentes que toman y aplican las decisiones de acceso y las fuentes de datos en las que se basan dichas decisiones.

Tres componentes lógicos fundamentales

Motor de políticas (PE). Toma la decisión de acceso evaluando la política de la empresa en función de los datos que se describen a continuación, aplicando un algoritmo de confianza y, a continuación, concediendo, denegando o revocando el acceso.

Administrador de pólizas (PA). Ejecuta dicha decisión abriendo o cerrando la vía de comunicación y emitiendo la credencial o el token que el sujeto utiliza para acceder al recurso. Juntos, el PE y el PA conforman lo que el NIST denomina «punto de decisión de política».

Punto de aplicación de políticas (PEP). Establece, supervisa y finaliza la conexión entre el sujeto y el recurso, situándose en la ruta de la solicitud y aplicando lo que determine el punto de decisión de la política.

Fuentes de datos que alimentan el motor de políticas

Los siguientes elementos proporcionan las señales que evalúa el motor de políticas, sin tomar decisiones por sí mismos:

• Sistema de gestión de identidades. Cuentas, registros de identidad, roles, atributos y derechos.
• Políticas de acceso a los datos. Las normas que definen quién puede acceder a qué recursos y en qué condiciones.
• Diagnóstico y mitigación continuos. Inventario de activos y estado de los dispositivos.
• Información sobre amenazas. Indicadores internos y externos de ataques y vulnerabilidades recién descubiertos.
• Registros de actividad y SIEM. Telemetría agregada utilizada para perfeccionar la política a lo largo del tiempo.
• Sistemas de cumplimiento normativo del sector. Requisitos normativos que la empresa está obligada a cumplir.
• PKI. Emisión y validación de certificados para entidades y recursos.

A menudo, los equipos difuminan esta línea durante la implementación, tratando un sistema de identidad o una fuente de amenazas como si tomaran decisiones de acceso, cuando en el modelo del NIST esos sistemas solo proporcionan información al motor de políticas, que es el que realmente toma las decisiones. Esta distinción cobra mayor importancia a la hora de evaluar qué partes de la arquitectura cubre realmente un proveedor.

Como concepto, el «Zero Trust» es bastante sencillo: no confíes en nadie ni apruebes ninguna acción hasta que hayas validado a la persona y autorizado la solicitud. La implementación es donde la mayoría de las organizaciones se estancan, ya que el «Zero Trust» afecta simultáneamente a la identidad, la red, los terminales, las aplicaciones y los datos, y pocos equipos de seguridad cuentan con el presupuesto o el capital político necesarios para abordar estos cinco aspectos a la vez. Esto plantea la cuestión práctica de por dónde empezar, y la respuesta es casi siempre la identidad.

Cada decisión en el marco del modelo «Zero Trust» se reduce a una única pregunta: si ese sujeto es quien dice ser y si debería tener ese acceso en este momento. Ni la segmentación ni el cifrado pueden responder a esa pregunta, y el estado del dispositivo la delimita sin resolverla, lo que deja a la identidad como el único control capaz de resolverla. Cuando la identidad es débil, todos los controles posteriores aplican fielmente una decisión basada en una premisa no verificada.

La identidad asume la responsabilidad en tres ámbitos:

• Autenticación. Verificación del sujeto a través de métodos resistentes al phishing en lugar de claves compartidas que pueden ser robadas, reproducidas o objeto de ingeniería social.
• Autorización. Determinar a qué tiene derecho a acceder un sujeto verificado, basándose en funciones reguladas en lugar de un acceso que se ha ido acumulando a lo largo de años de cambios de funciones.
• Evaluación continua. Reevaluar ambos a medida que cambian las señales de riesgo y revocar el acceso cuando las señales lo justifiquen.

Hay una consecuencia incómoda que se esconde tras todo esto, y es que no se puede aplicar un principio de «privilegio mínimo» que nunca se haya definido, y no se puede definir dicho principio sin saber quién tiene acceso a qué en la actualidad. La mayoría de las organizaciones no pueden responder a esa pregunta con certeza, y por eso gobernanza de la identidad debe integrarse desde el inicio de un programa de «Zero Trust», en lugar de en una fase posterior.

Gestión de identidades y accesos proporciona los componentes de los que depende una arquitectura de «Zero Trust».

Hay dos requisitos que suelen subestimarse más que cualquier otro.

La autenticación debe ser resistente al phishing. Autenticación multifactorial basada en códigos de acceso de un solo uso El envío de códigos mediante SMS o correo electrónico eleva el nivel de seguridad sin cerrar la brecha, ya que los ataques de «hombre en el medio» y las campañas de «fatiga de la autenticación multifactorial» logran burlar los métodos de notificaciones push y códigos OTP con cierta frecuencia. FIDO2 y claves de acceso vinculadas al dispositivo vincular la credencial tanto al dispositivo como al origen, lo cual constituye el mecanismo que realmente detiene el ataque, en lugar de simplemente ralentizarlo. RSA lleva defendiendo este argumento desde mucho antes de que se convirtiera en la postura consensuada, en su calidad de miembro de la junta directiva de la Alianza FIDO y copresidente del grupo de trabajo «Enterprise».

Access tiene que seguir funcionando aunque la nube no lo haga. Una arquitectura que canaliza todas las decisiones de acceso a través de un motor de políticas en la nube introduce, por su propio diseño, un único punto de fallo, y cuando ese servicio deja de estar disponible, nadie puede trabajar. Para las organizaciones que operan en entornos locales, híbridos, aislados físicamente o de disponibilidad constante —en los que una interrupción conlleva consecuencias operativas más allá de un simple inconveniente—, se trata de una mala opción. El modelo «Zero Trust» debería reducir el número de elementos capaces de dejar a una organización fuera de línea, en lugar de concentrarlos; por eso, las vías de aplicación fuera de línea y locales son las que hacen que el modelo sea viable en estos entornos.

Una vez que una organización se compromete con el modelo «Zero Trust», empieza el verdadero trabajo. Se trata de un programa que se prolonga durante varios años, y las organizaciones que logran avanzar en él suelen organizar las tareas por fases, en lugar de intentar hacerlo todo a la vez.

1. Identidades de inventario, recursos y acceso actual. El principio del privilegio mínimo no se puede aplicar si no se conoce una referencia de partida, así que empieza por determinar quién y qué tiene acceso a qué recursos en la actualidad, incluidas las cuentas de servicio, los contratistas y las identidades de los equipos.

2. Lo primero es reforzar la autenticación. La implantación de la autenticación multifactorial (MFA) resistente al phishing en las vías de acceso de mayor valor ofrece la mayor reducción de riesgo por unidad de esfuerzo, y es un requisito previo para la mayor parte de lo que viene a continuación.

3. Definir y aplicar políticas de acceso. Convertir las funciones y las necesidades empresariales en políticas explícitas; a continuación, eliminar el acceso general permanente y sustituirlo por derechos de acceso con un alcance definido y revisables.

4. Aportar contexto a las decisiones sobre el acceso. La implantación de la autenticación basada en el riesgo permite que las solicitudes de bajo riesgo se procesen sin problemas, mientras que las anómalas se someten a verificación o se bloquean; esta es también la forma de evitar que los usuarios encuentren formas de eludir el programa.

5. Recursos por segmento. Limitar el alcance de una sesión comprometida reduce el alcance de los efectos cuando —no «si», sino «cuando»— falle un control.

6. Supervisar, revisar y revocar. Las revisiones de los derechos deben realizarse según un calendario establecido, ya que los accesos que se acumulan sin ser revisados acaban convirtiéndose en esa proliferación de privilegios que el programa pretendía evitar.

En este caso, la secuencia es más importante que el ritmo, ya que la segmentación aplicada sin una identidad regulada subyacente da lugar a redes bien divididas que siguen protegiendo cuentas con privilegios excesivos.

Las organizaciones nunca alcanzan ni logran el modelo «Zero Trust». Deben evaluar continuamente su situación de seguridad y revisar cada decisión relativa al acceso.

Dificultades para el usuario. Una verificación demasiado estricta da lugar a soluciones alternativas, a la «TI en la sombra» y a un aumento del volumen de consultas al servicio de asistencia, aunque la accesibilidad y la seguridad no tienen por qué ser incompatibles. La autenticación basada en el riesgo adapta el nivel de seguridad al riesgo que supone cada solicitud individual, en lugar de aplicar un nivel de restricción uniforme a todo el mundo.

Sistemas heredados. Las aplicaciones anteriores a los estándares modernos de autenticación a menudo no pueden integrarse sin una pasarela, un proxy o una sustitución completa, lo que las convierte en el mayor obstáculo en la mayoría de los programas y en el aspecto que más se suele subestimar en la fase de planificación.

Dependencia de disponibilidad. Concentrar las decisiones de acceso en un único servicio en la nube crea una nueva dependencia crítica, y si el motor de políticas queda inaccesible, todo el mundo se queda sin acceso a nada. Vale la pena preguntar directamente a cualquier proveedor qué ocurre con la autenticación cuando su servicio deja de funcionar.

Ámbito de aplicación de la organización. Dado que el modelo «Zero Trust» abarca a los equipos de identidad, red, terminales, aplicaciones y datos, los programas que se gestionan íntegramente desde una sola función tienden a estancarse en los límites de dicha función.

Confundir a los proveedores. No existe ningún producto que ofrezca por sí solo el modelo “Zero Trust”, por lo que la mejor forma de evaluar a los proveedores es fijarse en los componentes arquitectónicos que realmente proporcionan, y es mejor considerar la «plataforma Zero Trust» como una afirmación que hay que verificar más que como una categoría de producto que se pueda adquirir.

La proliferación de datos de identidad. La gestión de identidades es un problema de datos cada vez mayor, más que uno estático, y los derechos de acceso se acumulan más rápido de lo que la mayoría de los equipos pueden revisarlos manualmente, lo que supone el punto en el que la automatización y el análisis de datos dejan de ser opcionales.

El modelo «Zero Trust» ha pasado de ser una buena práctica a convertirse en un requisito en varios entornos regulados.

• Decreto 14028 dirige Agencias civiles federales de EE. UU. hacia una arquitectura «Zero Trust».
• Modelo de madurez de «Zero Trust» de la CISA ofrece el marco de referencia según el cual las agencias federales evalúan su nivel de madurez, estructurado en torno a cinco pilares: identidad, dispositivos, redes, aplicaciones y cargas de trabajo, y datos.
• Estrategia «Zero Trust» del Departamento de Defensa establece las actividades relacionadas con el modelo «Zero Trust» para los componentes de defensa.
• CMMC 2.0 impone requisitos de control de acceso y de autenticación multifactorial (MFA) en toda la base industrial de defensa.
• DORA y NIS2 imponer requisitos de control de acceso, resiliencia y continuidad operativa a Servicios financieros de la UE y las infraestructuras críticas que se ajustan a los principios de «Zero Trust», independientemente de que el término aparezca o no en el texto.

La identidad aparece como un pilar o un grupo de controles en cada uno de ellos, y es también el ámbito en el que los auditores suelen solicitar pruebas en primer lugar y en el que las organizaciones suelen estar menos preparadas para presentarlas.

Los requisitos de resiliencia y las arquitecturas exclusivamente en la nube también entran en conflicto entre sí de formas que conviene analizar desde el principio. Las expectativas de continuidad operativa en el marco de la DORA, junto con los requisitos de disponibilidad constante en los sectores de la defensa y las infraestructuras críticas, son difíciles de cumplir utilizando un modelo de acceso que deja de funcionar cada vez que el servicio de un proveedor deja de estar disponible.