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, evoluciona la premisa de que la protección pasa de ser un conjunto de “filtros” simples que controlan el acceso a la aplicação a un conjunto de protecciones más apropiadas para los activos y aplicadas contextualmente a cualquier transacción del sistema .  La mentalidad de cada transacción es entender:  ¿Quién está intentando realizar qué acción sobre quién ?  El “quién” y “a quién” pueden ser cualquier componente dentro del sistema o que utilice el sistema, ya sea humano, automatizado o un fragmento de código.  El concepto de identidad es clave para quién y a quién , y el concepto de privilegios otorgados a una identidad se utiliza para codificar lo que se puede hacer.
• En segundo lugar, considera que la evaluación de las decisiones de seguridad no es estática y absoluta, sino más dinámica y adaptativa , y que debe reevaluarse continuamente a la luz de los comportamientos observados.  La decisión sobre la disposición de cada transacción (si permitir la interacción, bloquearla, generar confianza adicional, etc.) también debe considerar el contexto comercial más amplio y, específicamente, la relación riesgo-recompensa.
• Finalmente, se da por sentado que, sin importar cuántas capas de protección se proporcionen, un adversario suficientemente motivado o afortunado violará o eludirá las protecciones . Por lo tanto, la detección oportuna de cualquier compromiso 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 centrales del enfoque surgen de la formulación del caso de uso como:
  “¿Quién está intentando qué (acción) a quién?”
  • Para establecer Quién y a Quién, verificar explícitamente cualquier certificación de identidad.
  • Una vez que establezca Quién , utilice el principio del mínimo privilegio para limitar Qué se puede realizar.
  • Evaluar y reevaluar continuamente los tres factores Quién, Qué y Quién, y continuar validándolos frente a las restricciones de la política.
  • Suponga siempre que se producirán infracciones y vulneraciones . Esté preparado para intervenir si la acción ( Qué a Quién ), basada en un análisis de riesgo versus recompensa (la probabilidad de fraude en la autenticación, ponderada por el impacto comercial de una aprobación de transacción errónea), excede un umbral de seguridad aceptable predeterminado.
• Los métodos utilizados son:
  • Autenticación y control de acceso para determinar Quién en cierto nivel de confianza y luego limitar los privilegios en torno a Qué (acciones) debe permitir esa identidad con respecto a un objetivo Quién específico.
  • Visibilidad y análisis asistido por ML para observar y evaluar continuamente el contexto completo de cada transacción: quién hace qué a quién.
  • Remediación automatizada consciente del riesgo para intervenir en una transacción cuando el nivel de riesgo-recompensa supera el umbral de tolerancia especificado.
• Aborde una amplia gama de ciberataques aplicando estos métodos:
  • Ataques tradicionales como la desfiguración o la exfiltración de datos : puede abordar Estos ataques detectan el compromiso de identidad o la escalada de privilegios y utilizan técnicas de autenticación y control de acceso para limitar quién puede hacer qué mediante políticas.
  • Ataques de disponibilidad/DDoS : aborde estos ataques combinando la autenticación y el control de acceso con una solución que tenga en cuenta los riesgos.  Por ejemplo, puede bloquear (o limitar) el acceso a actores no autenticados o mal autenticados que intenten realizar transacciones que consuman muchos recursos.
  • Amenazas avanzadas , como ransomware o ataques a la cadena de suministro : puede abordar estas amenazas detectando cambios y anomalías en los comportamientos de quién le hace qué a quién, junto con una solució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 sistema operativo de nivel de aplicação /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 involucrados
   Los activos que intervienen en las transacciones tienen diferentes niveles de importancia. Por ejemplo, una base de datos que contiene información de identificación personal es más valiosa que una base de datos que enumera puntos de venta que venden productos fabricados por la empresa.  Los equipos de seguridad y TI pueden utilizar un proceso determinista para crear un inventario de todos los activos, categorizados por una puntuación que representa el “valor” del activo.


2. Impacto del compromiso
   La naturaleza del compromiso determina el impacto relacionado con él.  Por ejemplo, el impacto del sigilo de la información en el almacén de datos que contiene información de identificación personal es mucho mayor que la interrupción en la disponibilidad de ese almacén de datos.  Aunque es un poco más nebuloso, es posible enumerar varios tipos de compromisos y asignarles un puntaje de “impacto”.


3. Probabilidad de compromiso
   La probabilidad de que una transacción conduzca al compromiso de un activo es el factor menos determinante a la hora de evaluar el riesgo asociado a la transacción.  Los humanos no pueden manejar la escala de observaciones requeridas, por lo que las organizaciones emplean aprendizaje automático e inteligencia artificial para aumentar la confianza en sus cálculos 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, tableta, teléfonos móviles).
   2. Negocio conectado
      Los procesos comerciales digitales requieren conectividad con socios, proveedores, distribuidores y servicios proporcionados por otras empresas.
   3. Fuerza laboral móvil
      Los empleados necesitan poder acceder a las aplicações comerciales desde cualquier lugar para lograr una ejecución eficiente.


2. Prácticas para satisfacer las demandas de las empresas
   1. Metodología de desarrollo ágil
      Las empresas cambiaron al enfoque de desarrollo ágil, incremental e iterativo con un fuerte foco en la satisfacción del cliente, en lugar del enfoque secuencial en cascada que se centra en la entrega oportuna del proyecto.
   2. Uso de software ya preparado
      Para ofrecer nuevas experiencias digitales lo más rápido posible, los desarrolladores reutilizan el código abierto de sus colegas en la industria.
   3. Desarrollo de contratos
      La subcontratación de trabajo a desarrolladores contratados ayuda a las empresas a ampliar su fuerza laboral según demanda.
   4. Uso de la infraestructura en la nube
      La agilidad, flexibilidad y escalabilidad 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) es ventajoso para las aplicações de operaciones comerciales, ya que reduce la carga significativa de adquisición, implementación y mantenimiento de dichas aplicações 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 aplicação distribuidas
      Las organizaciones logran eficiencia al ejecutar microservicios en una 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 utilizando arquitecturas de aplicação modernas que necesitan comunicarse con los elementos heredados, y ambos a menudo se ejecutan en infraestructuras diferentes.
   8. API abiertas
      Un ecosistema de diversos servicios es más eficiente que una empresa que desarrolla 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 comerciales.


3. Mayor riesgo de seguridad
   1. Mayor superficie de ataque
      El uso de software de terceros y bibliotecas de código abierto crea oportunidades para ataques a la cadena de suministro, y todas las vulnerabilidades del software desarrollado externamente se heredan.  Los desarrolladores contratados están motivados a finalizar la funcionalidad de las características 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 y requiere mucho tiempo para los equipos internos revisar el código y encontrar agujeros de seguridad. Los sprints ágiles son muy eficientes a la hora de entregar funcionalidades, pero la mayor velocidad de desarrollo no deja mucho tiempo para pruebas y auditorías de seguridad detalladas.  Un microservicio vulnerable, que tiene la capacidad de comunicarse con otros microservicios, aumenta el riesgo de seguridad para 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. Mayor complejidad arquitectónica
      Los elementos de aplicação distribuidas, desarrollados utilizando distintas arquitecturas e implementados en múltiples infraestructuras, tienen diferentes necesidades de seguridad y cumplimiento.  Esto hace que sea complicado para los equipos de seguridad diseñar e implementar mecanismos apropiados para proteger las aplicações y los datos empresariales y cumplir con los requisitos de cumplimiento normativo.
      
   3. Hackers bien financiados, altamente motivados y capacitados
      Desde la Operación Aurora de 2010 hasta Solargate de 2020, hemos tenido una década de ciberataques avanzados que se descubren solo después de que han causado un gran daño.  Las violaciones ocurrieron en organizaciones equipadas con la mejor tecnología de seguridad, operadas por equipos de seguridad altamente capacitados.  Los atacantes persistieron en la infraestructura de TI de estas organizaciones durante largos períodos antes de ser detectados.  Se robó propiedad intelectual , se robó información de identificación personal, se interrumpieron operaciones comerciales y las organizaciones quedaron como rehenes de ransomware, incluso cuando los equipos de TI y seguridad se esforzaban al máximo para cumplir con las regulaciones diseñadas para mantener a raya los ciberataques.

Después de una serie de ciberataques persistentes contra varias agencias gubernamentales federales, estatales y locales de EE. UU., y varias corporaciones estadounidenses, el presidente Joe Biden emitió una orden ejecutiva para mejorar la ciberseguridad del país el 12 de mayo de 2021.  Uno de los elementos clave de esta orden es que las agencias gubernamentales utilicen los principios de confianza cero para prepararse ante los ciberataques. La administración Biden siguió esta orden con un memorando de la Oficina de Administració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 de arquitectura de Confianza Cero (ZTA) federal, que exige que las agencias cumplan con estándares y objetivos específicos de ciberseguridad para fines del año fiscal (AF) 2024 a fin de reforzar las defensas del gobierno contra 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) , que se publicó en agosto de 2020, y requieren que las agencias gubernamentales la sigan.

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

El equipo del NIST enumera los principios de la confianza cero y define una arquitectura de confianza cero abstracta (ZTA) en su artículo NIST SP 800-207.² Además, analizan variaciones de enfoques de confianza cero y describen diferentes formas de implementar 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 opinión de la Agencia de Seguridad de Infraestructura y Ciberseguridad (CISA) publicaron un modelo de madurez de confianza cero .³  El trabajo se basa en la arquitectura abstracta de confianza cero descrita en el documento NIST SP 800-207.  Los autores han identificado cinco áreas y recomiendan que las organizaciones realicen avances constantes en el seguimiento de los principios de confianza cero en cada área.  Las áreas son (i) identidad, (ii) dispositivo, (iii) red, (iv) carga de trabajo de la aplicação y (v) datos.  Recomiendan el uso de visibilidad y análisis, así como de 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) emitió una guía que aconseja a los equipos de ciberseguridad adoptar un modelo de seguridad de confianza cero en su documento “Adopción de un modelo de seguridad de confianza cero”.⁴  Los expertos del equipo conjunto de ingeniería de confianza cero de la Agencia de Sistemas de Información de Defensa (DISA) y la Agencia de Seguridad Nacional crearon 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 declaración: Las vulnerabilidades expuestas por las filtraciones de datos dentro y fuera del Departamento de Defensa demuestran la necesidad de un modelo de ciberseguridad nuevo y más sólido que facilite la toma de decisiones bien informadas y basadas en riesgos.⁶

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 como la construcción fundamentalmente de confianza en las interacciones del sistema –“¿ Quién le hace qué a quién ?”– entonces la construcción de un nivel de confianza apropiado para la interacción se puede dividir en cuatro componentes.

Como sugiere el nombre, la mentalidad de confianza cero es la de “No confíes ciegamente, verifica siempre”.  Por lo tanto, cualquier actor del sistema –el Quién y Quién en las interacciones del sistema– debe ser capaz de:

1. Dar fe de su identidad, incluido el caso especial de una identidad “anónima”, si el sistema permite interacciones originadas o destinadas a identidades anónimas, como navegadores anónimos en un sistema de reservas de aerolíneas.  Para todas las demás identidades, el actor debe poder indicar 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 concedan únicamente los privilegios mínimos necesarios para que pueda hacer lo que está diseñado para lograr en ese sistema.  Este principio encarna lo que también se conoce como un “modelo de seguridad positivo”: un enfoque en el que se prohíben todas las acciones de forma predeterminada y se conceden privilegios específicos solo cuando son necesarios para el funcionamiento del sistema.  Por ejemplo, un sistema de reservas puede permitir a usuarios anónimos consultar horarios de vuelos pero, según los requisitos de diseño de la aplicação , es posible que no se permita a un usuario anónimo 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, <X> <Y> pueden acceder a la base de datos. Solo <X> pueden escribir en el almacén de objetos, pero <Y> y <Z> pueden leer los datos que contiene».

Una consideración importante para la implementación del privilegio mínimo es esforzarse por aplicarlo de una manera más personalizada y 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 granular de qué acción se está intentando.   Por ejemplo, a gran escala, se puede conceder el privilegio de “acceso al sistema de archivos”, pero “lectura del sistema de archivos” es una especificación más estricta del verdadero privilegio requerido, lo que produce una implementación de alta calidad del modelo de seguridad positiva.

Finalmente, las realizaciones más sofisticadas del mínimo privilegio pueden funcionar en conjunto con implementaciones maduras de “verificación explícita”, al considerar los privilegios autorizados para un actor no como absolutos, sino como basados en la confianza proporcionada por la autenticación.  Por lo tanto, los privilegios se conceden sólo si la confianza en la identidad certificada ( Quién ) cumple un umbral mínimo, siendo los umbrales específicos para la acción que se está intentando. Por ejemplo, alguna acción particularmente impactante (por ejemplo, apagar el sistema) puede requerir un 90 % o más de confianza en que el actor es un administrador.  En este ejemplo, si la confianza del sistema en la identidad es solo del 80 % cuando se intenta el apagado, el sistema requerirá una verificación adicional para aumentar el puntaje de confianza en la identidad certificada 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 verificación y privilegio.  En otras palabras, no debería darse el caso de que solo un subconjunto de transacciones estén sujetas a inspección, como “la primera transacción en una sesión de usuario” o “aquellas transacciones que se inician a través de la carga de trabajo del contenedor Docker”.  Si bien esto puede parecer evidente, muchas implementaciones de confianza cero no validan todas las transacciones, ya sea por un diseño deficiente o por falta de visibilidad.  Las deficiencias comunes en esta área surgen de aplicar la confianza cero solo a actores externos, pero no a los internos, y/o de suponer que un veredicto de confianza cero sigue siendo válido durante un período prolongado de tiempo.
2. Los factores clave de la evaluación –la confianza en la identidad del actor y los derechos reconocidos a ese actor– deben considerarse dinámicos y sujetos a cambios .  Por ejemplo, la confianza en una identidad puede aumentar o disminuir con el tiempo, en función de los comportamientos observados y los metadatos de banda lateral, y cualquier política basada en la confianza debe, por lo tanto, también ajustarse dinámicamente a los cambios de confianza.  Además, un umbral de privilegio otorgado por una política anteriormente puede revocarse un poco más tarde, o puede cambiar la confianza mínima requerida para alguna acción.  Si bien los plazos para los cambios de políticas variarán (pueden cambiar lentamente (en escalas de tiempo de procesos operativos humanos) o rápidamente (a través de agentes de gobernanza 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, estos pueden aplicarse aprovechando cualquiera de las herramientas de políticas estáticas disponibles.  Algunos ejemplos de ajustes basados en políticas serían restringir los privilegios de control de acceso granulares de la transacción (es decir, ya no permitir que Quién haga Qué a Quién ) o, en cambio, aplicar un “estándar de prueba” más estricto (es decir, requerir MFA o un puntaje de confianza más alto) para que un actor (o clase de actores) realice 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 fundamentales debe capturar el comportamiento deseado/previsto de la interacción de los comportamientos del sistema, junto con suficiente visibilidad y control para detectar desviaciones y actuar en consecuencia.  Las interacciones previstas se utilizan para definir el conjunto deseado de acciones ( Qué ) para cada actor ( Quién ) hacia cada objetivo ( Quién ).  Dicho esto, puede haber algunos escenarios y entornos donde se desconozcan los patrones de interacción previstos. En tales casos, una organización puede aprovechar una visibilidad más profunda para “descubrir” el conjunto de interacciones apropiadas,⁸ que luego puede codificarse en políticas.

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 <table>»)?
• ¿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 proporciona el sistema para evitar el exceso de suscripción o consumo 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.

Realizar 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 de la confianza cero hoy en día se centra en lo que sucede después del diseño inicial, y la mayoría de la atención de la mayoría de las empresas se centra en los aspectos posteriores al diseño de la confianza cero.  Sin embargo, ser reflexivo, en la fase de diseño, acerca de los requisitos para la implementación efectiva de la confianza cero evitará esfuerzos incrementales mucho mayores necesarios para "tapar los agujeros" después de que se implemente la aplicação .

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 de tomar una acción correctiva visible para el usuario es realmente una decisión de negocios, que considera todos los riesgos, costos y recompensas en torno a la actividad sospechosa.  Introducir fricción adicional a la transacción aumenta la probabilidad de que no se reciba el valor, pero no intervenir o agregar fricción introduce el riesgo de compromiso. Por lo tanto, la decisión de actuar (o no) en tales casos es función de tres factores:

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


2. ¿Cuáles son los efectos secundarios de tomar medidas correctivas?
   Los efectos secundarios se pueden expresar a lo largo de las dimensiones de (a) fricción introducida y (b) zona de explosión. La fricción es cuánto más difícil es que se realice una transacción legítima; puede ser desde ligeramente más inconveniente (por ejemplo, un nivel adicional de autenticación) a imposible (la transacción simplemente no está permitida). La zona de explosión Se refiere a si otras transacciones independientes también se verán afectadas y, de ser así, cuántas.  Por ejemplo, bloquear a un usuario específico solo afectará a ese usuario, pero cerrar un servicio de registro afectará la auditabilidad de todos los usuarios y transacciones. 


3. ¿Cuál es la confianza en la creencia de que la transacción es maliciosa? 
   Generar confianza generalmente implica recolectar más puntos de datos y correlacionarlos entre más fuentes de datos, lo cual lleva tiempo, por lo que en la práctica, la disyuntiva suele ser: "¿Cuánto tiempo debo observar antes de decidir 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 previsión comienza en la fase de diseño, como se describe más adelante.

⁸ O, al menos, el conjunto de interacciones “que se consideran 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 lo tanto, siempre es preferible pensar con antelación en el diseño.