Seguridad de confianza cero: por qué es importante la confianza cero (y no solo para el acceso)

Uno de los temas principales del acceso a las redes y las aplicaciones de los últimos años ha sido el concepto de «confianza cero». En este artículo mostramos cómo, en su esencia, la confianza cero puede caracterizarse por un pequeño conjunto de creencias simples que pueden aplicarse no solo al acceso, sino también de forma más amplia en el espacio de la ciberseguridad.

Este artículo presenta un marco donde se engloban los amplios conceptos sobre la confianza cero, relacionándolos con el contexto empresarial actual que motiva a los líderes empresariales de seguridad para aplicaciones de hoy en día. Por último, ofrece una caracterización del sistema de creencias de la confianza cero, motor de las herramientas y las implementaciones de seguridad que mitigan las amenazas actuales y emergentes, que será el tema central de un documento posterior.

El objetivo de este artículo es doble: en primer lugar, transmitir el enfoque en la seguridad que deben adoptar los líderes de las empresas de aplicaciones y, en segundo lugar, presentar un marco para los profesionales de la seguridad que ampliaremos en futuros documentos técnicos.

El término «confianza cero» se asocia con una serie de conceptos diferentes en varios niveles de abstracción: a veces como una arquitectura de solución específica, otras como una prescripción para aplicar tecnologías específicas, y en otras ocasiones puede referirse a una propiedad de un producto. Creemos que la seguridad de confianza cero es, en el fondo, una mentalidad (un sistema de creencias) de la que surgen las técnicas y las tácticas que aprovechan tecnologías específicas y que luego pueden aplicarse para hacer frente a un amplio espectro de amenazas a la seguridad.

El sistema de creencias que subyace bajo la seguridad de confianza cero (ZTS) puede considerarse el siguiente paso en la evolución de la mentalidad centrada en la seguridad, que comenzó hace años con la «defensa en profundidad». La defensa en profundidad se basa en la creencia de que, si bien cualquier pantalla defensiva individual tiene una pequeña, pero real, probabilidad de ser vulnerada, la adición de más capas de protección en los activos clave reduce esa probabilidad y detiene a los atacantes, mientras les obliga a utilizar más recursos para que su ataque tenga éxito.

La confianza cero es un desarrollo de esta mentalidad en tres dimensiones:

• En primer lugar, hace evolucionar la premisa de la protección, que pasa de ser un conjunto de simples «filtros» que impiden acceder a las aplicaciones, a un conjunto de protecciones más adecuadas a los activos y aplicadas contextualmente en cualquier transacción del sistema. La mentalidad de cada transacción es comprender: Quién intenta qué acción sobre quién. El «quién» y el «sobre quién» pueden ser cualquier componente del sistema o que lo utilice, sea humano, automatizado o un trozo de código. El concepto de identidad es clave para el quién y el sobre quién, y el concepto de privilegios otorgados a una identidad se utiliza para codificar qué se puede hacer.
• En segundo lugar, considera que la evaluación de las decisiones de seguridad no es estática ni absoluta, sino más bien dinámica y adaptable que debe reevaluarse continuamente con base en los comportamientos observados. La decisión sobre la disposición de cada transacción (si se permite la interacción, se bloquea, se genera más confianza, etc.) debe tener en cuenta también el contexto empresarial más amplio y, en concreto, el equilibrio entre riesgo y recompensa.
• Por último, se da por sentado que, independientemente del número de capas de protección que se proporcionen, un adversario lo suficientemente motivado o afortunado podrá vulnerar las protecciones o eludirlas. Por tanto, la detección oportuna de cualquier peligro y la mitigación de los intentos de explotación también deben ser una parte clave de la estrategia general.

Esta evolución ha sido, en parte, el resultado del tiempo y la experiencia, pero está cada vez más impulsada por la confluencia de otras dos tendencias en la seguridad de las aplicaciones. En concreto, las arquitecturas de las aplicaciones actuales abren un espacio mucho mayor de vulnerabilidades en las aplicaciones (en particular, las amenazas procedentes del «interior» de la infraestructura de las aplicaciones) que están abiertas a la explotación por parte de los cada vez más sofisticados adversarios. Afortunadamente, los avances simultáneos en las herramientas de seguridad, especialmente cuando se utilizan junto con las modernas funciones de recopilación y análisis de datos, han permitido la aplicación práctica de los componentes clave de la estrategia defensiva.

El resto de esta introducción presenta una visión general del marco de nuestro enfoque sobre seguridad de confianza cero, así como su alcance. A partir de ahí, las siguientes secciones amplían el planteamiento del problema y su relación con otros enfoques contemporáneos de la confianza cero, lo que conduce a un debate sobre las creencias fundamentales (el «porqué») que deben guiar la elección de las tecnologías de solución y su aplicación. En futuros artículos profundizaremos en el «cómo», es decir, en los requisitos impuestos a tecnologías específicas como la autenticación, el control de acceso y el análisis asistido por IA en relación con el modelo de madurez de la confianza cero.

El enfoque de Simon Sinek, «Empieza por el porqué» es una herramienta eficaz para comunicar el marco de la ZTS, como se muestra en la Figura 1 a continuación. Puede ver este gráfico de fuera hacia dentro, empezando por las clases de amenazas que aborda la ZTS. Profundizando después en los métodos de seguridad utilizados y, finalmente, sintetizándolo todo a los principios comunes. O bien puede verlo desde una perspectiva de dentro hacia fuera, comenzando por las creencias fundamentales que sirven de brújula y de la que surgen las herramientas y técnicas apropiadas que luego permiten hacer frente a una amplia variedad de amenazas.

Figura 1 -- Seguridad de confianza cero: sistema de creencias, herramientas y beneficios.

Las secciones posteriores profundizan en cada una de las capas concéntricas de este diagrama, pero en resumen:

• Las creencias fundamentales del enfoque se derivan del encuadre del caso de uso
  «¿Quién intenta qué (acción) sobre quién?»
  • Para establecer el Quién y a quién, verifique explícitamente cualquier certificado de identidad.
  • Una vez establecido el Quién, use el principio de menor privilegio para limitar el Qué se puede hacer.
  • Evalúe y reevalúe continuamente los tres factores de Quién, Qué y Sobre quién, y siga validándolos con respecto a las limitaciones de la política.
  • Asuma que siempre se producirán infracciones y riesgos. Prepárese para intervenir si la acción (el Qué a Quién), basada en un análisis de riesgo-recompensa (la probabilidad de fraude en la autenticación, ponderada por el impacto empresarial de una de transacción errónea aprobada), supera un umbral predeterminado de seguridad aceptable.
• Los métodos utilizados son:
  • Autenticación y control de acceso para determinar Quién con cierto nivel de confianza, y luego para limitar los privilegios sobre Qué (acciones) debería estar permitido con respecto a un objetivo concreto, el Sobre quién.
  • Visibilidad y análisis asistidos por aprendizaje automático para observar y evaluar continuamente el contexto completo de cada transacción: quién hace qué a quién.
  • Corrección automatizada del riesgo para intervenir en una transacción cuando el nivel de riesgo-recompensa supere el umbral de tolerancia especificado.
• Enfrentarse a una amplia variedad de ciberataques aplicando estos métodos:
  • Ataques tradicionales como el defacement o la exfiltración de datos: puede enfrentarse a estos ataques detectando el compromiso de la identidad o la escalada de privilegios y utilizando las técnicas de autenticación y control de acceso para limitar Quién puede hacer Qué según la política.
  • Ataques a la disponibilidad o de DDoS: aborde estos ataques combinando la autenticación y el control de acceso con una reparación consciente del riesgo. Por ejemplo, se bloquea el acceso (o se limita la velocidad) a los actores no autenticados o mal autenticados que intentan realizar transacciones que consumen muchos recursos.
  • Amenazas avanzadas, como el ransomware o los ataques a la cadena de suministro: puede hacer frente a estas amenazas detectando los cambios y las anomalías en los comportamientos de Quién hace Qué a Quién, de nuevo junto a la reparación consciente del riesgo.

La seguridad de confianza cero se extiende de forma global a toda la pila de aplicaciones, infraestructuras y entregas, y debe abarcar todo el proceso de desarrollo. Más concretamente, debería incluir:

• Pila completa de aplicaciones e infraestructuras «de arriba a abajo»
  • Superficie informática de hardware, incluidos los servidores, las tarjetas de interfaz de red, los coprocesadores y los componentes de la placa del sistema
  • Firmware de capa baja y BIOS para el hardware.
  • El sistema operativo de la capa más baja, como el hipervisor o el ejecutivo en tiempo de ejecución.
  • El nivel de aplicación/sistema operativo del contenedor.
  • Componentes de aplicaciones de terceros importados, sean comerciales o de código abierto.
  • Cualquier software de aplicación desarrollado internamente o a medida.
• Pila completa de entrega de aplicaciones «de izquierda a derecha»
  • La cadena de suministro utilizada para el mantenimiento y las actualizaciones continuas de cada elemento de la pila «de arriba a abajo».
  • Todos los componentes de entrega de aplicaciones en línea, como cortafuegos, equilibradores de carga, pasarelas API, controladores de entrada/salida/malla y dispositivos de mitigación del fraude en línea.
  • Cualquier componente de entrega de aplicaciones que afecte indirectamente a la gestión del tráfico, como los solucionadores del sistema de nombres de dominio (DNS), o que reciba indirectamente metadatos, como las soluciones de gestión de eventos de información de seguridad (SIEM) o los servicios de identidad federados.

Tradicionalmente, el enfoque de la confianza cero se ha dirigido a los equipos de desarrollo y entrega de aplicaciones, a menudo considerados los encargados del desarrollo y las DevOps, DevSecOps y SRE. Señalamos esto principalmente para mostrar un panorama más amplio. Un enfoque integral de confianza cero debería incluir a personas e infraestructuras no tradicionales, así como flujos de trabajo adicionales, como la estrategia de adquisición de la cadena de suministro.

Una de las prioridades de los CIO y CISO es modernizar la tecnología de la información para ayudar a acelerar el negocio. También desempeñan un papel clave en el gobierno de los riesgos corporativos. Su objetivo es ayudar a la empresa a deleitar a los clientes con nuevas experiencias digitales, aumentar la eficiencia operativa a través de la conectividad digital con terceros y permitir que los empleados sean productivos desde cualquier lugar, todo ello mientras se minimiza el riesgo empresarial. Esto requiere que las organizaciones de los CIO y CISO liberen a sus plantillas para utilizar las tecnologías, arquitecturas y prácticas recomendadas más recientes para ganar en agilidad, mientras que simultáneamente se encarga a estas mismas personas la adopción de medidas de seguridad adecuadas y el establecimiento de controles sobre el comportamiento de las personas, la información a la que acceden y la tecnología que utilizan para evitar la exposición a pérdidas.

Las organizaciones deben comprender y controlar los riesgos relacionados con los cambios en el mercado y las condiciones macroeconómicas, el comportamiento de los consumidores, la cadena de suministro y los riesgos de seguridad. Una evaluación precisa del riesgo y la capacidad de tomar medidas rápidas de mitigación es una ventaja competitiva para las empresas. En este artículo nos centramos en el riesgo de exposición a la seguridad que, entre otras cosas, puede causar la pérdida de propiedad intelectual, la interrupción de los procesos empresariales, la pérdida de información personal identificable y multas de los reguladores. El riesgo de seguridad puede calcularse evaluando los siguientes aspectos:

1. Valor de los activos implicados
   Los activos que intervienen en las transacciones tienen diferentes niveles de importancia. Por ejemplo, una base de datos compuesta por información personal identificable es más valiosa que una que enumera los puntos de venta de los productos fabricados por la empresa. Es posible que los equipos de seguridad y de TI utilicen un proceso determinista para crear un inventario de todos los activos, clasificados por una puntuación que represente el «valor» del activo.


2. Impacto del compromiso
   La naturaleza del compromiso determina su impacto. Por ejemplo, el impacto de la infiltración en el almacén de datos que contiene información personal identificable es mucho mayor que la interrupción de la disponibilidad del almacén de datos. Aunque es algo más difuso, es posible enumerar varios tipos de compromisos y asignarles una puntuación de «impacto».


3. Probabilidad de compromiso
   La probabilidad de que una transacción lleve a poner en peligro un activo es el factor menos determinista a la hora de evaluar el riesgo asociado a la transacción. Los seres humanos no son capaces de hacer frente a la escala de observaciones necesarias, por lo que las organizaciones emplean el aprendizaje automático y la inteligencia artificial para aumentar la confianza en su cálculo de la probabilidad de compromiso.

El reto consiste en calcular el riesgo asociado a cada una de las transacciones casi en tiempo real y tomar las medidas de mitigación adecuadas para controlar el impacto de un posible compromiso.

Figura 2 -- Las presiones empresariales impulsan nuevas prácticas, lo que conduce a un mayor riesgo.

1. Demandas de aceleración empresarial
   1. Experiencias digitales
      Los consumidores tienen un deseo insaciable de experiencias digitales y exigen mejoras frecuentes en múltiples plataformas (PC, tabletas, teléfonos móviles, etc.).
   2. Empresa conectada
      Los procesos empresariales digitales requieren conectividad con socios, proveedores, distribuidores y servicios de otras empresas.
   3. Plantilla móvil
      Los empleados necesitan poder acceder a las aplicaciones empresariales desde cualquier lugar para lograr la eficiencia en la ejecución.


2. Prácticas para satisfacer las demandas de las empresas
   1. Metodología de desarrollo ágil
      Las empresas se han decantado por el enfoque de desarrollo ágil, incremental e iterativo, centrado en la satisfacción del cliente, en lugar del enfoque secuencial en cascada que se centra en la entrega puntual de los proyectos.
   2. Uso de software ya preparado
      Para ofrecer nuevas experiencias digitales lo más rápidamente posible, los desarrolladores reutilizan código de código abierto de compañeros del sector.
   3. Desarrollo por contrato
      La subcontratación de trabajo a desarrolladores por contrato ayuda a las empresas a ampliar su plantilla en función de la demanda.
   4. Uso de la infraestructura en la nube
      La agilidad, flexibilidad y capacidad de ampliación de la nube y su facilidad de uso permiten a los desarrolladores obtener la infraestructura necesaria bajo demanda.
   5. Adopción de SaaS
      El software como servicio (SaaS) tiene muchas ventajas para las aplicaciones de operaciones empresariales, ya que reduce una importante carga de adquisición, despliegue y mantenimiento de dichas aplicaciones en centros de datos privados.
   6. Arquitectura de microservicios
      Los equipos utilizan microservicios para lograr una entrega continua con un tiempo de comercialización más rápido.
   7. Componentes de aplicación distribuidos
      Las organizaciones logran la eficiencia ejecutando microservicios en la infraestructura que ofrece las mejores herramientas para desarrollar o entregar la funcionalidad del servicio. Las extensiones recientes de los flujos de trabajo heredados se realizan mediante arquitecturas de aplicaciones modernas que necesitan comunicarse con elementos heredados, y ambos suelen ejecutarse en infraestructuras diferentes.
   8. API abiertas
      Un ecosistema de varios servicios es más eficiente que una empresa que desarrolle todos los servicios por su cuenta.
   9. Conectividad de red con terceros
      Las empresas se conectan entre sí mediante túneles cifrados con sus socios, proveedores y distribuidores para automatizar y agilizar los procesos empresariales.


3. Mayor riesgo de seguridad
   1. Mayor superficie de ataque
      El uso de software de terceros y de bibliotecas de código abierto crea oportunidades para los ataques a la cadena de suministro, ya que se heredan las vulnerabilidades del software desarrollado externamente. Los desarrolladores contratados están centrados en terminar la funcionalidad a tiempo y la seguridad no es su preocupación. Además, una vez que entregan el software y salen del proyecto, es difícil que los equipos internos revisen el código y encuentren agujeros de seguridad, y además lleva mucho tiempo. Los sprints son eficientes a la hora de entregar la funcionalidad, pero esa mayor velocidad de desarrollo no deja tiempo para realizar auditorías y pruebas de seguridad detalladas. Un microservicio vulnerable que tenga la capacidad de hablar con otros microservicios aumenta el riesgo de seguridad en todo el sistema.

      Aunque los negocios interconectados mejoran la eficiencia operativa, una consecuencia grave es que los agujeros de seguridad en cualquiera de ellos afectan a todos. Los atacantes encuentran el eslabón más débil para propagarse al resto. Una vulnerabilidad o un fallo de seguridad en la plataforma de SaaS o en la infraestructura de la nube se convierte en un vector de ataque adicional, y el modelo de responsabilidad compartida puede complicar la detección anticipada y la reparación.

   2. Aumento de la complejidad arquitectónica
      Los elementos de las aplicaciones distribuidas, desarrolladas y desplegadas en distintas infraestructuras, tienen diferentes necesidades de seguridad y cumplimiento. Esto complica a los equipos de seguridad el diseño y el despliegue de los mecanismos adecuados para proteger las aplicaciones y los datos de la empresa, así como el cumplimiento de los requisitos normativos.
      
   3. Hackers bien financiados, altamente motivados y capacitados
      Desde la Operación Aurora de 2010, hasta Solargate de 2020, hemos sufrido una década de ciberataques avanzados que se descubren después de haber causado grandes daños. Las brechas se produjeron en organizaciones que contaban con la mejor tecnología de seguridad y con equipos de seguridad altamente capacitados. Los atacantes persistieron en la infraestructura informática de estas organizaciones durante largos períodos antes de ser detectados. Robaron propiedad intelectual e información personal identificable, interrumpieron las operaciones comerciales y mantuvieron rehenes a las organizaciones mediante ransomware, incluso aunque los equipos de TI y de seguridad superaron los requisitos de cumplimiento de las normas diseñadas para mantener a raya los ciberataques.

Tras un aluvión de ciberataques persistentes contra varias agencias gubernamentales federales, estatales y locales de Estados Unidos, y diferentes empresas estadounidenses, el presidente Joe Biden emitió una orden ejecutiva para mejorar la ciberseguridad de la nación el 12 de mayo de 2021. Uno de los elementos clave de esta orden es que los organismos gubernamentales utilicen los principios de confianza cero para estar preparados frente a los ciberataques. La Administración Biden siguió esta orden con un memorando de la oficina de gestión y presupuesto (OMB) para los jefes de departamentos y agencias ejecutivas el 26 de enero de 2022. Este memorando de la OMB «establece una estrategia federal de arquitectura de confianza cero (ZTA) que exige a los organismos que cumplan normas y objetivos específicos de ciberseguridad para finales del año fiscal de 2024 con el fin de reforzar las defensas del Gobierno contra las campañas de amenazas cada vez más sofisticadas y persistentes».¹  Tanto la orden ejecutiva como el memorando de la OMB hacen referencia a la arquitectura de confianza cero descrita en la publicación SP 800-207 del Instituto Nacional de Estándares y Tecnología (NIST), publicada en agosto de 2020, y exigen a los organismos gubernamentales que la sigan.

Los líderes de opinión de las agencias gubernamentales y del sector privado han publicado documentos que ayudan a explicar la arquitectura de confianza cero y ofrecen consejos sobre la mejor manera de adoptarla. A continuación resumimos las ideas contenidas en estos documentos. Observamos que la esencia crítica de las ideas y sugerencias de estos documentos es examinar cada transacción para evaluar Quién intenta Qué acción sobre Quién, y tomar una decisión en tiempo real para permitir o rechazar la transacción con base en el cálculo del riesgo asociado a ella.

El equipo del NIST enumera los principios de la confianza cero y define una arquitectura abstracta de confianza cero (ZTA) en su documento NIST SP 800-207.² Además, analiza las variaciones de los enfoques de confianza cero y describe diferentes maneras de desplegar la arquitectura abstracta.

Las abstracciones clave que se analizan en el documento son el punto de decisión de directivas (PDP) y el punto de aplicación de directivas (PEP), que funcionan conjuntamente. El punto de decisión de directivas está compuesto por el motor de directivas (PE) y el administrador de directivas (PA). El motor de directivas utiliza un algoritmo de confianza para tomar decisiones sobre si se debe conceder acceso a un recurso a un sujeto. Esta decisión la ejecuta el Administrador de Políticas, que se comunica con el Punto de Aplicación de Políticas para permitir o rechazar una nueva sesión y para modificar o terminar una sesión existente. Además, el documento analiza las variaciones del algoritmo de confianza, los componentes de la red para un entorno de confianza cero y diversos casos de uso o escenarios de despliegue. Por último, se examinan las formas en que la arquitectura de confianza cero puede ser frustrada por los atacantes, de modo que los implementadores sean conscientes de las amenazas y tomen las medidas adecuadas para proteger sus componentes de la arquitectura de confianza cero.

Con el objetivo de ayudar a las agencias a desarrollar sus planes de confianza cero, los líderes de la Agencia de Ciberseguridad y Seguridad de las Infraestructuras (CISA), publicaron un modelo de madurez de confianza cero.³  El trabajo se basa en la arquitectura abstracta de confianza cero descrita en el documento del NIST SP 800-207. Los autores identifican cinco áreas y recomiendan que las organizaciones avancen de forma consistente en el seguimiento de los principios de la confianza cero en cada área. Las áreas son (i) identidad, (ii) dispositivo, (iii) red, (iv) carga de trabajo de la aplicación y (v) datos. Recomiendan el uso de visibilidad y análisis, y la automatización y orquestación en cada una de las cinco áreas.

El documento ofrece un modelo de madurez de alto nivel en los cinco pilares fundamentales de la confianza cero identificados anteriormente, y profundiza en cada área. Las organizaciones pueden utilizar el modelo de madurez para entender su estado actual y establecer un curso iterativo hacia el estado óptimo.

Tras el descubrimiento de los ataques de Solar Winds, la Agencia de Seguridad Nacional (NSA) publicó unas directrices en las que aconsejaba a los equipos de ciberseguridad que adoptaran un modelo de seguridad de confianza cero en su documento «Adoptar un modelo de seguridad de confianza cero».⁴  Los expertos del equipo de ingeniería de confianza cero de la Agencia de Sistemas de Información de Defensa (DISA) y la Agencia de Seguridad Nacional fueron los autores de la arquitectura de referencia de confianza cero del Departamento de Defensa (DOD).⁵  Los autores expresan la necesidad de adoptar la confianza cero con la siguiente afirmación: «Las vulnerabilidades expuestas por las violaciones de datos dentro y fuera del DOD demuestran la necesidad de aplicar un nuevo modelo de ciberseguridad más sólido que facilite la toma de decisiones bien informadas basadas en el riesgo».⁶

Esta arquitectura de referencia basa sus recomendaciones en las abstracciones definidas en el documento sobre arquitectura de confianza cero del NIST SP 800-207. El documento presenta un modelo operativo de alto nivel y describe sus elementos en detalle. También incluye un modelo de madurez de alto nivel y la asignación de capacidades para aplicar los principios de confianza cero a diversas áreas de interés. En conjunto, estos documentos ayudan a las organizaciones a evaluar su estado actual y a diseñar un plan.

Tener una actitud que «asuma el incumplimiento» y seguir los principios de confianza cero puede ayudar a las organizaciones en sus prácticas de gestión de riesgos y gobernanza. Los principios de confianza cero de «supervisión continua» y «verificación explícita» de los actores que participan en las transacciones permiten a las organizaciones crear una puntuación de riesgo dinámica para todos los actores y sus actividades. Esto está en consonancia con la recomendación de Gartner de utilizar la metodología de «evaluación adaptativa y continua del riesgo y la confianza» (CARTA, por sus siglas en inglés) para mejorar los programas de seguridad existentes. Adoptar el principio de permitir únicamente el acceso a los recursos con los mínimos privilegios reduce el riesgo de pérdidas incluso tras una infracción. La información generada por la supervisión continua y la verificación explícita también es útil para generar informes de cumplimiento.

Esta sección pretende centrarse en la mentalidad (el sistema de creencias, el «porqué») que motiva la estrategia y las decisiones en torno a las herramientas y el diseño que debe adoptar una empresa para lograr una seguridad de confianza cero. De hecho, es posible simplificar el ímpetu de todos los métodos y las tecnologías de componentes empleados por las soluciones actuales de confianza cero a cuatro simples principios clave. Esta sección comienza con una enumeración de estos principios, seguida de un debate sobre cómo pueden aplicarse en el contexto más amplio del ciclo de vida del desarrollo de aplicaciones (es decir, cómo tener en cuenta estos principios desde el primer momento, en la fase de diseño, así como desde el punto de vista operativo, en el despliegue/ejecución de la aplicación).

Si las soluciones de confianza cero se entienden fundamentalmente como la generación de confianza en las interacciones del sistema («¿Quién hace Qué a Quién?»), entonces la creación de un nivel de confianza apropiado para la interacción puede resumirse en cuatro componentes.

Como su nombre indica, la mentalidad de confianza cero es la de «no confiar ciegamente, siempre es necesario verificar». Por tanto, cualquier actor del sistema (el Quién y el Sobre quién en las interacciones) debe poder:

1. Confirmar su identidad, incluyendo el caso especial de una identidad «anónima», si el sistema permite interacciones originadas por o destinadas a identidades anónimas (como los navegadores anónimos en un sistema de reservas de aerolíneas). Para todas las demás identidades, el actor debe ser capaz de declarar Quién es en un espacio de nombres que el sistema acepte.
2. Recibir y validar la «prueba» colateral de la identidad verificada del actor (para cualquier identidad atestiguada no anónima). La naturaleza de la «prueba» (contraseñas, certificados, comportamientos, etc.) puede variar, al igual que la solidez de dicha prueba, pero el sistema debe ser capaz de determinar cierto grado de confianza en la confirmación. Los sistemas sencillos pueden tener una visión binaria de sí/no en cuanto a la confianza en la prueba, mientras que los más avanzados pueden tener una puntuación de confianza numérica que puede formar parte de una política basada en el riesgo. Obsérvese que el sistema también puede aumentar o reducir la confianza por otros medios, como la respuesta a un desafío activo o incluso a partir de la observación pasiva del comportamiento del actor.
3. Evaluar y ajustar la confianza en la identidad confirmada basándose en la contextualización adicional del comportamiento actual en relación con los comportamientos anteriores. Por ejemplo, el sistema puede mantener metadatos históricos del actor, como la geolocalización anterior y actual del actor, las plataformas de hardware, las direcciones IP, la reputación, etc., para utilizarlos con el objetivo de aumentar o disminuir la confianza en la «prueba» de identidad.

Además, el principio de verificación explícita no solo puede aplicarse a la identidad, sino también a la acción: el Qué de la transacción. Un caso de uso común es cuando la acción se expresa como una llamada a la API, usar una API para realizar una consulta a la base de datos. En este ejemplo, el principio de verificación explícita puede utilizarse no solo para confiar en la identidad del actor que llama a la API, sino también para verificar la corrección del uso de la acción de la API, como por ejemplo verificar que los parámetros pasados a la API se ajustan a las restricciones adecuadas.

En una mentalidad madura de confianza cero, la «prueba» casi nunca es absoluta. Las credenciales de identidad pueden ser robadas, los dispositivos pueden verse comprometidos y las restricciones de los parámetros de la API suelen ser incompletas. Por lo tanto, el término «confianza» en el contexto de la confianza cero debe interpretarse más bien como una indicación de la probabilidad de que los parámetros confirmados de la identidad o la transacción sean legítimos. Así, el nivel de «confianza» debe considerarse un factor clave, pero no el único, a la hora de tomar la decisión de si permitir, bloquear o inspeccionar más a fondo una transacción.

Una vez que se establece un nivel aceptable de «confianza» en los actores que participan en una transacción, el enfoque de confianza cero requiere que al actor (normalmente, el solicitante, el «Quién») se le conceda solo el conjunto mínimo de privilegios necesarios para que pueda hacer lo que se haya determinado en ese sistema. Este principio encarna lo que también se denomina «modelo de seguridad positiva»: un enfoque en el que todas las acciones están prohibidas por defecto, y en el que solo se conceden los privilegios específicos necesarios para el funcionamiento del sistema. Por ejemplo, un sistema de reservas puede permitir que usuarios anónimos consulten los horarios de los vuelos, pero, según los requisitos de diseño de la aplicación, no reservar un vuelo.

Estos privilegios pueden aplicarse a actores individuales o a clases de actores. Normalmente, los consumidores de aplicaciones son actores o representantes humanos, y se agrupan en clases, como «usuarios anónimos», «clientes», «socios» o «empleados». Las clases menos fiables de actores suelen requerir un umbral de confianza más bajo para superar la autenticación, pero también tienen acceso a menos API o a API menos sensibles. Los actores internos a la aplicación o a su infraestructura, como servicios o contenedores específicos dentro de una aplicación, pueden tener privilegios más personalizados, como «solo contenedores, pueden acceder a la base de datos. Solo pueden escribir en el almacén de objetos, pero y pueden leer los datos que contiene».

Una consideración importante para la implementación del mínimo privilegio es esforzarse por aplicarlo de una manera más personalizada, con previsión.⁷ Específicamente, en lugar de aplicar un conjunto genérico de privilegios a todos los actores, o a una clase de actores, una implementación madura de confianza cero debería tener una visión más detallada del Qué, la acción que se intenta realizar. Por ejemplo, de forma general, se puede conceder el privilegio de «acceso al sistema de archivos», pero el de «lectura del sistema de archivos» es una especificación más estricta del verdadero privilegio requerido, lo que sería una implementación de alta calidad del modelo de seguridad positiva.

Por último, las formas más sofisticadas del privilegio mínimo pueden funcionar junto con las implementaciones maduras de «verificación explícita» al considerar que los privilegios autorizados para un actor no son absolutos, sino que se basan en la confianza proporcionada por la autenticación. Así, los privilegios solo se conceden si la confianza en la identidad confirmada (el Quién) alcanza el umbral mínimo, siendo estos específicos para la acción que se intenta realizar. Por ejemplo, las acciones especialmente impactantes (por ejemplo, apagar el sistema) pueden requerir un 90 % o más de confianza al determinar que el actor es un administrador. En este ejemplo, si la confianza del sistema en la identidad es solo del 80 %, al intentar apagar el sistema, este pedirá una verificación adicional para aumentar la puntuación de confianza antes de permitir la acción.

La verificación explícita y el mínimo privilegio son conceptos clave, sin embargo, el principio de evaluación continua recoge el hecho de que esos principios deben ser evaluados continuamente, en el sentido de que:

1. Todas las transacciones deben estar sujetas a la verificación y a los privilegios. En otras palabras, no debería darse el caso de que únicamente un subconjunto de transacciones esté sujeto a inspección (por ejemplo, «la primera transacción en una sesión de usuario» o «las transacciones que se inician a través de la carga de trabajo del contenedor Docker»). Aunque esto puede parecer evidente, muchas implementaciones de confianza cero no validan todas las transacciones, ya sea por un mal diseño o por falta de visibilidad. Las deficiencias más comunes en esta área surgen de la aplicación de la confianza cero solo a los actores externos, pero no a los internos, y/o de la suposición de que un veredicto de confianza cero se mantiene durante un largo periodo de tiempo.
2. Los factores clave de la evaluación (la confianza en la identidad del actor y sus derechos) deben considerarse dinámicos y sujetos a cambios. Por ejemplo, la confianza en una identidad puede aumentar o disminuir con el tiempo, basándose en los comportamientos observados y en los metadatos de banda lateral. Cualquier política basada en la confianza debe, por tanto, ajustarse también dinámicamente a los cambios de confianza. Además, los privilegios concedidos anteriormente por la política pueden ser revocados más tarde, o la confianza mínima requerida para realizar una acción puede cambiar. Aunque los plazos para los cambios de política variarán y pueden cambiar lentamente (según los plazos de los procesos operativos humanos) o rápidamente (a través de agentes de gobierno automatizados), el sistema debe ser capaz de responder dinámicamente y respetar esos cambios.

El último principio se basa en la presunción de que existen adversarios muy motivados, en un contexto de sana paranoia. En concreto, la premisa es «asumir que se ha producido una infracción», donde «infracción» se define como «una transacción que debería haberse denegado (con un conocimiento y una ejecución perfectos) pero que, en cambio, se permitió». La causa de esta fuga puede ser el conocimiento imperfecto (por ejemplo, una puntuación de confianza alta e incorrecta en cuanto a la autenticación, derivada de la no detección de credenciales fraudulentas), o pueden deberse a las limitaciones de la implementación (por ejemplo, no tener una especificidad suficientemente detallada de los privilegios concedidos, como tener el privilegio de «conexión de red abierta», pero sin la capacidad de diferenciar según la geolocalización del destino de la red), o puede ser por una implementación incompleta de la confianza cero (por ejemplo, no aplicarla en los componentes vulnerables de código abierto utilizados internamente).

Por tanto, la mentalidad de confianza cero también debe abordar la mejor manera de gestionar/minimizar el impacto de tales infracciones.

La aplicación de este principio varía más que la de los demás, pero se suele manifestar así:

• En primer lugar, identifique cualquier transacción que, aunque esté técnicamente permitida por la política, sea sospechosa. Lo «sospechoso» puede depender del contexto, pero las interpretaciones más comunes son: (a) transacciones anómalas muy diferentes de los comportamientos observados en el pasado, (b) grupos de transacciones normales individualmente, pero inusuales colectivamente (por ejemplo, puede ser común leer y escribir un archivo, pero leer y escribir a un ritmo de 1000 archivos por segundo puede ser inusual), o (c) acciones que se correlacionan con un impacto no deseado y no visto previamente en el sistema (un ejemplo sería un patrón en el que una transacción específica abre una conexión de red a un nodo TOR o hace que la carga de CPU del sistema aumente significativamente).
• A continuación, realice un análisis más profundo, ya sea un flujo de trabajo totalmente automatizado o uno híbrido y controlado por personas/asistido por aprendizaje automático, para determinar si esas transacciones no son válidas. Si se determina que no son válidas, aplique una mitigación. Esto puede ser una actualización de la política general, o la adición de una capa extra de mitigación, un «respaldo» para las otras mitigaciones basadas en la política.

Si el enfoque elegido es utilizar ajustes basados en políticas, los ajustes pueden aplicarse aprovechando cualquiera de las herramientas de política estática disponibles. Ejemplos de ajustes basados en políticas serían restringir los privilegios de control de acceso a las transacciones (es decir, dejar de permitir que Quién haga Qué a Quién) o aplicar en su lugar una «norma de prueba» más estricta (es decir, requerir MFA o una puntuación de confianza más alta) para que un actor (o clase de actores) pueda realizar una acción específica.

Si, por el contrario, se opta por el enfoque de utilizar una capa adicional de «respaldo», esta estrategia también puede implementarse de forma detallada o más amplia. La estrategia más detallada consistiría en bloquear únicamente las transacciones que superen una relación riesgo-recompensa específica, aunque esta solución también tiene la posibilidad de añadir niveles inaceptables de latencia en algunas transacciones permitidas si la implementación requiere un análisis adicional. En su lugar, se podrían utilizar estrategias más generales, como el aislamiento de las futuras transacciones de ese actor o incluso la prohibición total del actor en el sistema. En casos extremos, pueden ser apropiados métodos de mitigación aún más amplios, como el cierre de la E/S de los archivos.

Por supuesto, en igualdad de condiciones, suele ser preferible una mitigación de respaldo más detallada. Sin embargo, a menudo hay que hacer concesiones en función de las limitaciones de las tecnologías disponibles, y tener un respaldo más amplio suele ser mejor que no tener respaldo. Por ejemplo, si la respuesta general para evitar un posible ransomware es deshabilitar la E/S de los archivos, los efectos secundarios de esa respuesta pueden ser preferibles a la alternativa, es decir, permitir que el actor siga operando en el sistema sin control, asumiendo que el resultado de la falta de acción sería tener un sistema de archivos cifrado por el ransomware.

El mejor punto de partida para el desarrollo de una aplicación segura que utilice la confianza cero es, como es lógico, el principio. Los principios fundamentales que permiten hacer operativos los principios de la confianza cero deben estar presentes en la fase de diseño de los procesos de desarrollo de las aplicaciones. Por lo tanto, cualquier discusión sobre una solución operativa de confianza cero integrada en el proceso de CI/CD debe comenzar con una comprensión de estos elementos fundacionales que deben ser consideraciones de diseño de primera clase.

El núcleo de estos elementos fundacionales debe capturar el comportamiento deseado/previsto de la interacción de los comportamientos del sistema, junto con la suficiente visibilidad y control para detectar las desviaciones y actuar sobre ellas. Las interacciones previstas se utilizan para definir el conjunto deseado de acciones (Qué) para cada actor (Quién) sobre cada objetivo (Sobre quién). Dicho esto, puede haber algunos escenarios y entornos en los que se desconozcan los patrones de interacción previstos. En estos casos, una organización puede aprovechar una visibilidad más profunda para «descubrir» el conjunto de interacciones apropiadas,⁸ que luego puede codificar en la política.

Por ejemplo, en las soluciones actuales de ZTNA, que se centran en el control de acceso basado en la identidad a las API externas de una aplicación, se requiere visibilidad y controles en las API de autenticación. O, en el contexto de la plataforma de protección de cargas de trabajo en la nube (CWPP), la detección de una carga de trabajo de contenedor comprometida requiere visibilidad de las acciones que realiza cada contenedor, y en tiempo real, si se requiere una reparación en tiempo real.

A continuación se presenta una lista de los «cubos» de alto nivel relacionados con las consideraciones fundamentales que deberían formar parte del proceso de diseño, con desgloses adicionales para proporcionar preguntas específicas sobre las que pensar en cada uno de los puntos clave:

• ¿Cuáles son las interfaces de caja negra (entradas y salidas) del sistema?
  • ¿Cuáles son las clases de usuarios (administradores, usuarios autentificados, usuarios no autentificados, socios, etc.) que interactúan con la aplicación y qué necesitan hacer?
  • ¿Todas las comunicaciones se realizan a través de una API definida, o existen comunicaciones de red «en bruto» o a través de un almacén de datos, como una base de datos o un almacén de objetos?
    • En el caso de las comunicaciones de la API, ¿en qué medida está bien definida la API, en términos de qué usuarios pueden interactuar con ella, y las restricciones en torno a esas interacciones (por ejemplo, restricciones de parámetros, límites de velocidad, etc.)?
    • En las comunicaciones en red, ¿se cifran todos los datos transmitidos?
    • Si hay interfaces de datos «en bruto» (por ejemplo, la información se comparte entre el cliente y la aplicación a través de un almacén de objetos o una base de datos), ¿hay audit logs para rastrear quién accedió a qué información y cuándo?
• Del mismo modo, en el nivel interno de «caja blanca», ¿cuáles son los servicios que componen las aplicaciones en general, incluidos los servicios que se proporcionan externamente, y cómo se comunican?
  • ¿Cómo se comunican estos servicios? ¿Qué API se utiliza y cuáles son las restricciones (roles, controles de acceso, límites de velocidad, parámetros, etc.) en esas interacciones?
    • Existen cuestiones similares a las anteriores en torno a la formalidad de la API y sus limitaciones y sobre el cifrado de las comunicaciones.
    • Es más probable que las comunicaciones «internas» (por ejemplo, entre cargas de trabajo/contenedores) utilicen memoria compartida e interfaces basadas en sistemas de archivos. Cualquier interfaz de este tipo debe ser identificada.
• ¿Qué mecanismos de control ofrece el sistema para limitar el acceso a las interfaces de la caja negra y a las vías de comunicación internas?
  • ¿Existe una política que indique quién (qué roles) puede invocar API específicas y qué sucede si se infringe la política? Del mismo modo, ¿qué medios existen para detectar y mitigar los abusos de las API, como parámetros no válidos o que se invoquen a un ritmo demasiado elevado? ¿Pueden esas políticas actualizarse dinámicamente, basándose en las entradas contextuales de otros sistemas?
  • De forma análoga, ¿existen políticas que limiten las demás formas de comunicación entre cargas de trabajo (sistemas de archivos, almacenes de objetos, tablas de bases de datos) en términos de quién puede acceder a qué archivos/almacenes/tablas, y que eviten el abuso de esos recursos (por ejemplo, «SELECCIONAR * de »)?
    ¿Qué visibilidad (paneles, registros, estadísticas) ofrece el sistema para limitar el acceso tanto a las interfaces de caja negra como a las vías de comunicación internas?

    • ¿Puede el sistema identificar quién invoca qué API y en qué momento? ¿Se conservan estos datos y, en caso afirmativo, durante cuánto tiempo? ¿Con qué rapidez (en tiempo real, cada hora, etc.) están disponibles estos datos? ¿En qué medida se pueden consumir los datos? ¿Se trata de un archivo de registro no estructurado, de una notación de objetos de JavaScript (JSON) estructurada que puede enviarse a un servicio de gestión de eventos e incidentes de seguridad (SEIM), o de datos registrados en una tabla de base de datos de big data?
    • ¿Cuáles son las respuestas a las mismas preguntas cuando se trata de otras vías de comunicación: memoria, archivos, objetos y bases de datos? ¿Quién hace qué? ¿Cómo se exponen esos datos?
    Más allá de las vías de comunicación, ¿qué otros controles y visibilidad ofrece el sistema para evitar la sobresuscripción o el sobreconsumo de recursos?

    • ¿Tiene el sistema visibilidad de los parámetros de consumo de recursos (CPU, memoria, ancho de banda, escalado de pods, etc.)? En caso afirmativo, ¿con qué nivel de detalle y qué grado de consumo tienen esos datos?
    • ¿Tiene el sistema controles o barandillas para el consumo de recursos (límites de E/S de memoria/CPU/archivo por carga de trabajo, seguimiento de las llamadas al sistema de creación de procesos, límites en el escalado/descenso de los pods, límites de velocidad para las API que invocan otros servicios)?

    Formular explícitamente estas preguntas le ayudará a descubrir dónde están las carencias de sus cimientos para permitir la confianza cero. A menudo, el mero hecho de hacerse estas preguntas en una fase temprana del diseño, hará que se aborde la carencia con un mínimo esfuerzo de diseño adicional. Y, si la carencia persiste, el simple conocimiento de que existe le ayudará a dirigir el enfoque de seguridad o a identificar las superficies de amenaza vulnerables.

    Hacer este tipo de análisis de desarrollo seguro por adelantado es una parte crucial de la mentalidad de confianza cero. Sin embargo, a pesar de este hecho, gran parte del enfoque actual de la confianza cero se centra en lo que sucede después del diseño inicial, y la mayoría de las empresas se centran en los aspectos posteriores al diseño de la confianza cero. Sin embargo, ser reflexivo en la fase de diseño sobre los requisitos para lograr una implementación efectiva de la confianza cero evitará esfuerzos mucho más grandes, necesarios para «parchear los agujeros» tras implementar la aplicación.

Según la premisa de «asumir la infracción», un profesional de la seguridad debe asumir que los adversarios suficientemente motivados se las arreglarán para ejecutar una transacción maliciosa, un caso de Quién hace Qué a Quién que cumpla las normas de la política, pero, que no debería haber sido permitido en un mundo ideal. En tales casos, el enfoque se centra en tener un mecanismo eficaz de «respaldo» que pueda encontrar esos casos, generalmente con base en observaciones de patrones de transacciones y efectos secundarios del sistema, como se describe en la sección anterior «Asumir las infracciones».

Sin embargo, al igual que con la noción de identidad, el conocimiento de si una transacción específica es malintencionada o no nunca será perfecto. Por tanto, al igual que con la identidad, una solución ideal de confianza cero debería informar de una puntuación de «confianza» en la legitimidad de la transacción. Por ejemplo, ver una lectura y escritura de un demonio 10 veces más rápido que la tasa normal de archivos durante 10 segundos podría dar como resultado una puntuación de confianza (de malicia) del 70 %, pero si la tasa aumenta 100 veces de forma sostenida durante 1 minuto, podría elevar la confianza al 95 %. En este ejemplo, tomar la acción correctiva de inhibir futuras escrituras de archivos seguirá teniendo alguna posibilidad (un 30 % o 5 %) de ser la respuesta incorrecta (un «falso positivo»). Por tanto, la decisión de corregir el problema o no debe considerar el riesgo de tener falsos positivos, frente al impacto potencial de permitir el comportamiento posiblemente malicioso.

El objetivo del ejemplo es destacar que cualquier decisión basada en realizar una acción correctiva visible para el usuario es en realidad una decisión empresarial. Una decisión que considera todos los riesgos, los costes y las recompensas en relación a la actividad sospechosa. Introducir más fricciones en la transacción aumenta la probabilidad de no recibir el valor, pero no intervenir y no añadir esta fricción introduce el riesgo de compromiso. Por tanto, la decisión de actuar (o no) en estos casos es una función de tres entradas:

1. ¿Cuál es el riesgo de permitir que continúen las transacciones posiblemente maliciosas?
   Este riesgo puede ser directamente monetario, como la transferencia de fondos bancarios, o puede tener costes indirectos, sean operativos (por ejemplo, registros clave cifrados y retenidos para pedir un rescate) o de marca (por ejemplo, desfiguración de un sitio web). También puede haber costes legales o de cumplimiento, como los derivados de la filtración de datos personales de clientes. En esencia, la asignación de riesgos es una cuestión de gobierno, y un buen gobierno comprenderá y cuantificará los riesgos de la aplicación.


2. ¿Cuáles son los efectos secundarios de la acción correctora?
   Los efectos secundarios se pueden expresar en las dimensiones de (a) fricción introducida y (b) zona de explosión. La fricción se refiere a lo difícil que le resulta a una transacción legítima continuar el proceso. Puede ir desde algo más difícil (por ejemplo, un nivel más de autenticación) a imposible (la transacción simplemente no está permitida). La zona de explosión se refiere a si también se verán afectadas otras transacciones independientes y, si ese es el caso, cuántas. Por ejemplo, el bloqueo de un usuario específico solo afectará a ese usuario, pero el cierre de un servicio de registro afectará a la capacidad de verificación de todos los usuarios y transacciones.


3. ¿Cuál es la confianza en la creencia de que la transacción es maliciosa?
   Crear confianza suele implicar la recopilación de más puntos de datos y la correlación a través de más fuentes de datos, y ambas cosas llevan tiempo, por lo que este compromiso suele ser, en la práctica, «¿cuánto tiempo debo observar antes de decidirme a actuar?».

Por lo tanto, mientras que una estrategia de confianza cero debe aceptar el hecho de que se producirán infracciones, un enfoque reflexivo adoptará un enfoque de riesgo-recompensa en la corrección de las transacciones permitidas pero que parecen sospechosas. Ese equilibrio comprenderá el nivel de riesgo de las diferentes transacciones de la aplicación y las consecuencias de aplicar la corrección, y aplicar la corrección solo si el nivel de riesgo supera la recompensa comercial esperada.

¹ https://www.whitehouse.gov/wp-content/uploads/2022/01/M-22-09.pdf

² https://csrc.nist.gov/publications/detail/sp/800-207/final

³ https://www.cisa.gov/zero-trust-maturity-model

⁴ https://media.defense.gov/2021/Feb/25/2002588479/-1/-1/0/CSI_EMBRACING_ZT_SECURITY_MODEL_UOO115131-21.PDF

⁵ https://dodcio.defense.gov/Portals/0/Documents/Library/(U)ZT_RA_v1.1(U)_Mar21.pdf

⁶ https://dodcio.defense.gov/Portals/0/Documents/Library/(U)ZT_RA_v1.1(U)_Mar21.pdf

⁷ La reflexión comienza en la fase de diseño, como se describe más adelante.

⁸ O, al menos, el conjunto de interacciones «consideradas apropiadas» que el sistema parece requerir. Siempre existe el riesgo de que el conjunto de interacciones derivadas de la observación sea incompleto o tenga algún riesgo preexistente. Por tanto, en el diseño siempre es preferible la previsión.