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

Resumen

Uno de los principales temas en el ámbito del acceso a redes y aplicaciones durante los últimos años ha sido el concepto de «confianza cero». En este documento mostramos cómo, en esencia, la confianza cero puede caracterizarse mediante un pequeño conjunto de principios sencillos que pueden aplicarse no solo al acceso, sino también de forma más amplia en todo el ámbito de la ciberseguridad.

Este documento presenta un marco que engloba los conceptos generales en torno a la confianza cero y los relaciona con el contexto empresarial actual que impulsa a los responsables de negocio en materia de seguridad de aplicaciones. Por último, el documento describe el sistema de principios de la confianza cero, que constituye la base de las herramientas y las implementaciones de seguridad destinadas a hacer frente a las amenazas actuales y emergentes, y que será el tema central de un documento posterior.

Los objetivos de este documento son dos: en primer lugar, transmitir la mentalidad de seguridad que deberían adoptar los responsables de negocio de las aplicaciones y, en segundo lugar, presentar un marco para los profesionales de la seguridad que ampliaremos en futuros libros blancos.

ZTS: Empiece por los principios, no por las tecnologías

El término «confianza cero» se asocia a diversos conceptos en distintos niveles de abstracción: a veces se entiende como una arquitectura de solución específica; otras, como la recomendación de aplicar determinadas tecnologías; y, en ocasiones, puede referirse a una propiedad de un producto. Creemos que la seguridad de confianza cero es, en esencia, una mentalidad —un sistema de creencias— de la que surgen técnicas y tácticas que aprovechan tecnologías específicas y que, a su vez, pueden aplicarse para hacer frente a un amplio abanico de amenazas de seguridad.

El sistema de creencias en el que se basa la seguridad de confianza cero (ZTS) puede considerarse el siguiente paso en la evolución de la mentalidad de seguridad que comenzó hace años con la «defensa en profundidad». La defensa en profundidad parte de la premisa de que, aunque cualquier barrera defensiva individual presenta una probabilidad pequeña, pero real, de ser vulnerada, añadir más capas de protección para los activos clave reduce esa probabilidad, ralentiza a los atacantes y, al mismo tiempo, los obliga a emplear más recursos para llevar a cabo un ataque con éxito.

La confianza cero supone la maduración 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 controlan el acceso a la aplicación a un conjunto de medidas de protección más adecuadas para el activo y aplicadas de forma contextual a cualquier transacción del sistema. El enfoque de cada transacción consiste en comprender: quién intenta realizar qué acción sobre quién. El «quién» y el «sobre quién» pueden ser cualquier componente del sistema o que utilice el sistema, ya sea una persona, un proceso automatizado o un fragmento de código. El concepto de identidad es clave para determinar quién y sobre quién, mientras que el concepto de privilegios concedidos 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 dinámica y adaptativa, y que debe reevaluarse continuamente a la luz de los comportamientos observados. La decisión sobre cómo proceder con cada transacción —ya sea permitir la interacción, bloquearla, recabar garantías adicionales, etc.— también debe tener en cuenta el contexto empresarial más amplio y, en concreto, el equilibrio entre riesgos y beneficios.
• Por último, da por sentado que, independientemente de cuántas capas de protección se implementen, un adversario suficientemente motivado o afortunado logrará vulnerar o eludir las protecciones. Por lo tanto, la detección oportuna de cualquier vulneración y la mitigación de los intentos de explotación también deben ser una parte fundamental de la estrategia global.

Esta evolución ha sido, en parte, fruto del tiempo y la experiencia, pero cada vez está más impulsada por la convergencia de otras dos tendencias en materia de seguridad de las aplicaciones. En concreto, las arquitecturas de aplicaciones actuales amplían considerablemente el abanico potencial de vulnerabilidades —en particular, las amenazas procedentes del «interior» de la infraestructura de las aplicaciones— que pueden ser explotadas por unos adversarios cada vez más sofisticados. Afortunadamente, los avances paralelos en las herramientas de seguridad, especialmente cuando se utilizan junto con las modernas capacidades de recopilación y análisis de datos, han permitido llevar a la práctica componentes clave de la estrategia defensiva.

El resto de esta introducción ofrece una visión general del marco de nuestro enfoque de seguridad de confianza cero, así como de su alcance. A continuación, las siguientes secciones profundizan en el planteamiento del problema y su relación con otros enfoques contemporáneos de confianza cero, para dar paso a un análisis de los principios fundamentales —el «porqué»— que deben orientar la elección de las tecnologías de las soluciones y su aplicación. En futuros documentos se profundizará en el «cómo»: los requisitos que deben cumplir 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 confianza cero.

ZTS: Todo empieza por el porqué

El enfoque «Empieza con el porqué» de Simon Sinek es una herramienta eficaz para explicar el marco ZTS, como se muestra en la Figura 1. Este gráfico puede interpretarse de fuera hacia dentro, comenzando por los tipos de amenazas que aborda ZTS, profundizando después en los métodos de seguridad empleados y, por último, reduciéndolo todo a una serie de principios comunes. También puede interpretarse de dentro hacia fuera, partiendo de las creencias fundamentales como guía, de las que surgen las herramientas y técnicas adecuadas que, a su vez, permiten hacer frente a una amplia variedad de amenazas.

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

En secciones posteriores se analiza en profundidad cada capa concéntrica de este diagrama, pero, en resumen:

• Los principios fundamentales del enfoque se derivan de la formulación del caso de uso de la siguiente manera:
  «¿Quién intenta hacer qué (acción) a quién?»
  • Para determinar quién y a quién, verifique explícitamente cualquier declaración de identidad.
  • Una vez que determine quién, aplique el principio de mínimo privilegio para limitar qué se puede hacer.
  • Evalúe y reevalúe continuamente los tres factores de quién, qué y a quién, y siga validándolos con respecto a las restricciones de la política.
  • Siempre dé por sentado que se producirán brechas de seguridad y vulneraciones. Esté preparado para intervenir si la acción (qué a quién), según un análisis de riesgos y beneficios (la probabilidad de fraude en la autenticación, ponderada en función del impacto empresarial de aprobar erróneamente una transacción), supera un umbral de seguridad aceptable predeterminado.
• Los métodos utilizados son:
  • Autenticación y control de acceso para determinar Quién con cierto grado de confianza y, a continuación, limitar los privilegios relativos a Qué (acciones) deben permitirse a dicha identidad con respecto a un Quién específico.
  • Visibilidad y análisis asistido 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 basada en el riesgo para intervenir en una transacción cuando el nivel de riesgo-beneficio supere el umbral de tolerancia especificado.
• Aborde una amplia variedad de ciberataques aplicando estos métodos:
  • Ataques tradicionales como el vandalismo de sitios web o la exfiltración de datos: puede hacer frente a estos ataques detectando la vulneración de identidades o la escalada de privilegios, y utilizando técnicas de autenticación y control de acceso para limitar mediante políticas quién puede hacer qué .
  • Ataques de disponibilidad/DDoS -- Aborde estos ataques combinando la autenticación y el control de acceso con medidas correctivas basadas en el riesgo. Por ejemplo, puede bloquear (o limitar la frecuencia de) el acceso de agentes no autenticados o con una autenticación deficiente que intenten realizar transacciones que consuman muchos recursos.
  • Amenazas avanzadas, como ransomware o ataques a la cadena de suministro -- Puede hacer frente a estas amenazas detectando cambios y anomalías en los comportamientos relativos a quién hace qué a quién, de nuevo en combinación con medidas correctivas basadas en el riesgo.

El alcance de ZTS

La seguridad de confianza cero se extiende de forma integral a toda la pila de aplicaciones, infraestructura y entrega, y debe abarcar todo el proceso de desarrollo. Más concretamente, debe incluir:

• Pila completa de aplicaciones e infraestructura, «de arriba abajo»
  • Sustrato de computación de hardware, incluidos servidores, tarjetas de interfaz de red, coprocesadores y componentes de la placa base
  • Firmware de bajo nivel y BIOS para el hardware.
  • El sistema operativo de la capa más baja, como el hipervisor o el entorno de ejecución.
  • El sistema operativo a nivel de aplicación/contenedor.
  • Componentes de aplicaciones de terceros importados, ya 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 continuo y las actualizaciones de cada elemento de la pila «de arriba abajo».
  • Cualquier componente en línea para la entrega de aplicaciones, como cortafuegos, equilibradores de carga, puertas de enlace de API, controladores de entrada/salida/malla y dispositivos en línea para la mitigación del fraude.
  • Cualquier componente de entrega de aplicaciones que afecte indirectamente a la gestión del tráfico, como los resolutores del sistema de nombres de dominio (DNS), o que reciba metadatos de forma indirecta, como las soluciones de gestión de eventos e información de seguridad (SIEM) o los servicios de identidad federada.

Tradicionalmente, el enfoque de confianza cero se ha centrado en los equipos de desarrollo y entrega de aplicaciones, a menudo representados por perfiles como Dev, DevOps, DevSecOps y SRE. Señalamos esto principalmente para destacar una perspectiva más amplia: un enfoque integral de confianza cero debería incluir, idealmente, perfiles e infraestructuras no tradicionales, así como flujos de trabajo adicionales, como la estrategia de aprovisionamiento de la cadena de suministro.

Planteamiento del problema

Una de las principales prioridades del CIO y el CISO es modernizar las tecnologías de la información para contribuir a acelerar el negocio. También desempeñan un papel clave en la gestión de los riesgos corporativos. Su objetivo es ayudar a la empresa a satisfacer a los clientes con nuevas experiencias digitales, aumentar la eficiencia operativa mediante la conectividad digital con terceros y permitir que los empleados sean productivos desde cualquier lugar, al tiempo que se minimizan los riesgos empresariales. Para ello, las organizaciones del CIO y el CISO deben dar libertad a sus equipos para utilizar las tecnologías, arquitecturas y mejores prácticas más recientes con el fin de ganar agilidad y, al mismo tiempo, encomendar a esas 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 posibles pérdidas.

Las organizaciones deben comprender y controlar los riesgos relacionados con los cambios en las condiciones del mercado y macroeconómicas, el comportamiento de los consumidores, la cadena de suministro y la exposición a amenazas de seguridad. Una evaluación precisa del riesgo y la capacidad de adoptar rápidamente medidas de mitigación suponen una ventaja competitiva para las empresas. En este documento nos centramos en el riesgo derivado de la exposición a amenazas de seguridad, que, entre otras consecuencias, puede provocar la pérdida de propiedad intelectual, la interrupción de los procesos empresariales, la pérdida de información de identificación personal y la imposición de multas por parte de los organismos reguladores. El riesgo de seguridad puede calcularse evaluando los siguientes aspectos de la situación objeto de análisis:

1. Valor de los activos implicados
   Los activos implicados en las transacciones tienen distintos 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 los establecimientos minoristas 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, clasificados mediante una puntuación que represente el «valor» del activo.
2. Impacto de la vulneración
   La naturaleza de la vulneración determina su impacto. Por ejemplo, el impacto del robo de información del almacén de datos que contiene información de identificación personal es mucho mayor que el de una interrupción de la disponibilidad de dicho almacén. Aunque se trata de un aspecto algo más impreciso, es posible enumerar distintos tipos de vulneraciones y asignarles una puntuación de «impacto».
3. Probabilidad de vulneración
   La probabilidad de que una transacción provoque la vulneración de un activo es el factor menos determinista a la hora de evaluar el riesgo asociado a dicha transacción. Los seres humanos no son capaces de manejar el volumen de observaciones necesarias, por lo que las organizaciones recurren al aprendizaje automático y a la inteligencia artificial para aumentar la fiabilidad del cálculo de la probabilidad de vulneración.

El reto consiste en calcular, prácticamente en tiempo real, el riesgo asociado a cada transacción y adoptar las medidas de mitigación adecuadas para controlar el impacto de una posible vulneración.

Identificar el problema

Las exigencias de aceleración empresarial dan lugar a nuevas prácticas que agravan el riesgo de ciberseguridad. A continuación, analizamos este aspecto con más detalle.

Figura 2. Las presiones empresariales impulsan nuevas prácticas, lo que aumenta el riesgo.

1. Exigencias de aceleración empresarial
   1. Experiencias digitales
      Los consumidores tienen un deseo insaciable de disfrutar de experiencias digitales y exigen mejoras frecuentes en múltiples plataformas (ordenadores, tabletas y teléfonos móviles).
   2. Empresa conectada
      Los procesos empresariales digitales requieren conectividad con socios, proveedores, distribuidores y servicios prestados por otras empresas.
   3. Plantilla móvil
      Los empleados deben poder acceder a las aplicaciones empresariales desde cualquier lugar para trabajar de forma eficiente.
2. Prácticas para satisfacer las demandas empresariales
   1. Metodología de desarrollo ágil
      Las empresas adoptaron el enfoque de desarrollo ágil, incremental e iterativo, centrado especialmente en la satisfacción del cliente, en lugar del enfoque secuencial en cascada, que se centra en entregar los proyectos a tiempo.
   2. Uso de software listo para usar
      Para ofrecer nuevas experiencias digitales lo antes posible, los desarrolladores reutilizan código que otros profesionales del sector han publicado como código abierto.
   3. Desarrollo por contrato
      Externalizar el trabajo a desarrolladores contratados ayuda a las empresas a ampliar su plantilla según sus necesidades.
   4. Uso de infraestructura en la nube
      La agilidad, la flexibilidad y la escalabilidad de la nube, así como su facilidad de uso, permiten a los desarrolladores obtener la infraestructura necesaria bajo demanda.
   5. Adopción de SaaS
      El software como servicio (SaaS) resulta ventajoso para las aplicaciones de operaciones empresariales, ya que reduce considerablemente la carga que supone adquirir, implementar y mantener dichas aplicaciones en centros de datos privados.
   6. Arquitectura de microservicios
      Los equipos utilizan microservicios para lograr una entrega continua y reducir el tiempo de comercialización.
   7. Componentes de aplicaciones distribuidas
      Las organizaciones mejoran su eficiencia ejecutando microservicios en la infraestructura que ofrece las mejores herramientas para desarrollar o proporcionar las funcionalidades del servicio. Las ampliaciones recientes de los flujos de trabajo heredados se realizan mediante arquitecturas de aplicaciones modernas que necesitan comunicarse con los elementos heredados, y ambos suelen ejecutarse 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 optimizar los procesos empresariales.
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 se heredan todas las vulnerabilidades del software desarrollado externamente. Los desarrolladores contratados están motivados para completar a tiempo las funcionalidades, y la seguridad no es su prioridad. Además, una vez que entregan el software y abandonan el proyecto, a los equipos internos les resulta difícil y laborioso revisar el código y detectar brechas de seguridad. Los sprints ágiles son muy eficaces para entregar funcionalidades, pero el aumento de la velocidad de desarrollo deja poco tiempo para realizar auditorías y pruebas de seguridad exhaustivas. Un solo microservicio vulnerable que pueda comunicarse con otros microservicios aumenta el riesgo de seguridad de todo el sistema. Aunque las empresas interconectadas mejoran la eficiencia operativa, una consecuencia grave es que las brechas de seguridad de cualquiera de ellas afectan a todas. Los atacantes localizan el eslabón más débil para propagarse por el resto. Una vulnerabilidad o un fallo de seguridad en la plataforma SaaS o en la infraestructura en la nube se convierte en un vector de ataque adicional, y el modelo de responsabilidad compartida puede complicar la detección temprana y la corrección.
   2. Mayor complejidad arquitectónica
      Los elementos de aplicaciones distribuidas, desarrollados con distintas arquitecturas e implementados en múltiples infraestructuras, tienen diferentes necesidades de seguridad y cumplimiento normativo. Esto dificulta que los equipos de seguridad diseñen e implementen mecanismos adecuados para proteger las aplicaciones y los datos empresariales, así como para cumplir los requisitos normativos.
   3. Hackers bien financiados, altamente motivados y cualificados
      Desde la Operación Aurora de 2010 hasta Solargate en 2020, hemos vivido una década de ciberataques avanzados que solo se descubren después de haber causado graves daños. Se produjeron brechas de seguridad en organizaciones dotadas de la mejor tecnología de seguridad y gestionadas por equipos de seguridad altamente cualificados. Los atacantes permanecieron durante largos periodos en la infraestructura de TI de estas organizaciones antes de ser detectados. Se robó propiedad intelectual e información de identificación personal, se interrumpieron las operaciones empresariales y se mantuvo a organizaciones como rehenes mediante ransomware, a pesar de que los equipos de TI y seguridad hicieron todo lo posible por cumplir las normativas diseñadas para mantener a raya los ciberataques.

Directivas del Gobierno de Estados Unidos

Tras una oleada de ciberataques persistentes contra diversos organismos federales, estatales y locales de Estados Unidos, así como contra varias empresas 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 los organismos gubernamentales utilicen los principios de confianza cero para prepararse ante los ciberataques. Posteriormente, la Administración Biden emitió un memorando de la Oficina de Gestión y Presupuesto (OMB) dirigido a los responsables de los departamentos y organismos del poder ejecutivo 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 cumplir normas y objetivos específicos de ciberseguridad antes de que finalice el año fiscal 2024, con el fin de reforzar las defensas del Gobierno frente a 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.

Arquitecturas Zero trust architecture y modelos de madurez

Expertos de referencia de organismos públicos y del sector privado han publicado documentos que ayudan a explicar la arquitectura de confianza cero y ofrecen recomendaciones sobre la mejor manera de adoptarla. A continuación, resumimos las ideas recogidas en estos documentos. Cabe señalar que la esencia fundamental de las ideas y sugerencias que contienen consiste en examinar cada transacción para determinar quién intenta realizar qué acción sobre quién, y tomar una decisión en tiempo real para permitir o denegar la transacción en función del cálculo del riesgo asociado.

Instituto Nacional de Estándares y Tecnología (NIST): Zero trust architecture

El equipo del NIST enumera los principios de la confianza cero y define una arquitectura abstracta de confianza cero (ZTA) en su publicación NIST SP 800-207.² Además, analiza distintas variantes de los enfoques de confianza cero y describe diferentes formas de implementar la arquitectura abstracta.

Las abstracciones clave analizadas en el documento son el punto de decisión de políticas (PDP) y el punto de aplicación de políticas (PEP), que funcionan conjuntamente. El punto de decisión de políticas está compuesto por el motor de políticas (PE) y el administrador de políticas (PA). El motor de políticas utiliza un algoritmo de confianza para decidir si se debe conceder a un sujeto acceso a un recurso. 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 denegar una nueva sesión, así como para modificar o finalizar una sesión existente. Además, el documento analiza distintas variantes del algoritmo de confianza, los componentes de red para un entorno de confianza cero y diversos casos de uso o escenarios de implementación. Por último, se examinan las formas en que los atacantes pueden vulnerar la arquitectura de confianza cero, con el fin de que los responsables de su implementación sean conscientes de las amenazas y adopten las medidas adecuadas para proteger los componentes de dicha arquitectura.

Agencia de Seguridad de Infraestructuras y Ciberseguridad (CISA): modelo de madurez de confianza cero

Con el objetivo de ayudar a las agencias a desarrollar sus planes de confianza cero, expertos de la Agencia de Seguridad de Infraestructuras y Ciberseguridad (CISA) publicaron un modelo de madurez de confianza cero (https://www.cisa.gov/zero-trust-maturity-model).³ Este 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 avancen de forma constante en la aplicación de los principios de confianza cero en cada una de ellas. Estas áreas son: (i) identidad, (ii) dispositivos, (iii) red, (iv) cargas de trabajo de las aplicaciones y (v) datos. Recomiendan utilizar la visibilidad y el análisis, así como la automatización y la orquestación, en cada una de las cinco áreas.

El documento ofrece un modelo de madurez de alto nivel que abarca los cinco pilares fundamentales de la confianza cero identificados anteriormente y, a continuación, profundiza en cada área. Las organizaciones pueden utilizar el modelo de madurez para comprender su situación actual y definir un proceso iterativo que les permita alcanzar el estado óptimo.

Departamento de Defensa (DOD): arquitectura de referencia de confianza cero

Tras descubrirse los ataques de SolarWinds, la Agencia de Seguridad Nacional (NSA) publicó unas directrices en las que recomendaba 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».⁴ 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 elaboraron la arquitectura de referencia de confianza cero del Departamento de Defensa (DOD).⁵ Los autores expresan la necesidad de adoptar la confianza cero mediante la siguiente afirmación: «Las vulnerabilidades puestas de manifiesto por las filtraciones de datos dentro y fuera del DOD demuestran la necesidad de un modelo de ciberseguridad nuevo y más sólido que facilite la toma de decisiones fundamentadas y basadas en el riesgo».⁶

Esta arquitectura de referencia basa sus recomendaciones en las abstracciones definidas en el documento de arquitectura de confianza cero 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 un mapeo de las capacidades necesarias para aplicar los principios de confianza cero a diversas áreas de interés. En conjunto, estos documentos ayudan a las organizaciones a evaluar su situación actual y elaborar un plan.

Gestión del riesgo y la gobernanza con principios de confianza cero

Adoptar una actitud que «dé por sentada una brecha» 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 intervienen en las transacciones permiten a las organizaciones crear una puntuación de riesgo dinámica para todos los actores y sus actividades. Esto concuerda con la recomendación de Gartner de utilizar la metodología de «evaluación continua y adaptativa de riesgos y confianza» (CARTA) para mejorar los programas de seguridad existentes. Adoptar el principio de permitir únicamente el acceso con privilegios mínimos a los recursos reduce el riesgo de pérdidas incluso cuando se produce una brecha. La información generada mediante la supervisión continua y la verificación explícita también resulta útil para elaborar informes de cumplimiento normativo.

La mentalidad en mayor detalle

Esta sección se centra en la mentalidad —el sistema de creencias, el «porqué»— que guía la estrategia y las decisiones relativas a las herramientas y el diseño que una empresa debe adoptar para implementar la seguridad de confianza cero. De hecho, la motivación que subyace a todos los métodos y tecnologías que componen las soluciones actuales de confianza cero puede resumirse en cuatro principios clave. La sección comienza enumerando estos principios y, a continuación, analiza cómo pueden aplicarse en el contexto más amplio del ciclo de vida del desarrollo de aplicaciones; es decir, cómo tenerlos en cuenta desde el principio, durante la fase de diseño, así como en el ámbito operativo, durante el despliegue y la ejecución de la aplicación.

Principios operativos de confianza cero

Si se entiende que las soluciones de confianza cero consisten fundamentalmente en generar confianza en las interacciones entre sistemas —«Quién hace Qué a Quién»—, la generación de un nivel de confianza adecuado para cada interacción puede desglosarse en cuatro componentes.

Verificar explícitamente

Como su propio nombre indica, la mentalidad de confianza cero se basa en el principio «No confíes ciegamente; verifica siempre». Por tanto, cualquier actor del sistema —el quién y el a quién de las interacciones del sistema— debe poder:

1. Acreditar su identidad, incluido el caso especial de una identidad «anónima», si el sistema permite interacciones procedentes de identidades anónimas o destinadas a ellas, como navegadores anónimos en un sistema de reservas de una aerolínea. 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 «pruebas» complementarias de la identidad declarada por el actor (para cualquier identidad declarada que no sea anónima). La naturaleza de las «pruebas» —contraseñas, certificados, comportamientos, etc.— puede variar, al igual que su solidez, pero el sistema debe poder determinar cierto grado de confianza en la declaración. Los sistemas sencillos pueden adoptar una valoración binaria (sí/no) de la confianza en las pruebas, mientras que los sistemas más avanzados pueden utilizar una puntuación numérica de confianza a la que se pueda hacer referencia explícita como parte de una política basada en el equilibrio entre riesgos y beneficios. Téngase en cuenta que el sistema también puede aumentar o reducir la confianza por otros medios, como la respuesta a un desafío activo o incluso la observación pasiva del comportamiento del actor.
3. Evaluar y ajustar el grado de confianza en la identidad declarada, basándose en una contextualización adicional del comportamiento actual en relación con comportamientos anteriores. Por ejemplo, el sistema puede conservar metadatos históricos sobre el actor, como su geolocalización anterior y actual, las plataformas de hardware, las direcciones IP, la reputación, etc., con el fin de aumentar o reducir la confianza en la «prueba» de identidad.

Además, el principio de verificar explícitamente puede aplicarse no solo a la identidad, sino también a la acción, es decir, al «qué» de la transacción. Un caso de uso habitual es aquel en el que la acción se expresa como una llamada a una API, por ejemplo, una API para realizar una consulta en una base de datos. En este ejemplo, el principio de verificar explícitamente puede utilizarse no solo para confiar en la identidad del actor que llama a la API, sino también para comprobar que la acción de la API se utiliza correctamente, por ejemplo, verificando que los parámetros enviados a la API cumplen las restricciones pertinentes.

En un enfoque maduro de confianza cero, la «prueba» casi nunca es absoluta. Las credenciales de identidad pueden ser robadas y los dispositivos pueden verse comprometidos; las restricciones de los parámetros de las API suelen ser incompletas. Por tanto, en el contexto de la confianza cero, el término «confianza» debe interpretarse más bien como una indicación de la probabilidad de que la identidad acreditada o los parámetros de la transacción sean legítimos. Así pues, el nivel de «confianza» debe considerarse un factor clave, pero no el único, a la hora de decidir si se permite, se bloquea o se somete una transacción a una inspección más exhaustiva.

Privilegio mínimo

Una vez establecido un nivel aceptable de «confianza» en los actores que participan en una transacción, el enfoque de confianza cero exige que al actor (normalmente, el solicitante, el «Quién») se le conceda únicamente el conjunto mínimo de privilegios necesarios para poder hacer aquello para lo que ha sido diseñado en ese sistema. Este principio encarna lo que también se conoce como «modelo de seguridad positiva»: un enfoque en el que todas las acciones están prohibidas de forma predeterminada y solo se conceden privilegios específicos cuando son necesarios para el funcionamiento del sistema. Por ejemplo, un sistema de reservas puede permitir que los usuarios anónimos consulten los horarios de los vuelos, pero, según los requisitos de diseño de la aplicación, es posible que un usuario anónimo no tenga permiso para reservar un vuelo.

Estos privilegios pueden aplicarse a actores individuales o a clases de actores. Por lo general, los usuarios de una aplicación son personas o representantes de estas, y se agrupan en clases como «usuarios anónimos», «clientes», «socios» o «empleados». Las clases de actores menos fiables 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 de la aplicación o de su infraestructura, como determinados servicios o contenedores de una aplicación, suelen tener privilegios más personalizados, por ejemplo: «solo los contenedores <X> e <Y> pueden acceder a la base de datos; solo <X> puede escribir en el almacén de objetos, pero <Y> y <Z> pueden leer de él».

Una consideración importante a la hora de implementar el principio de mínimo privilegio es procurar aplicarlo de forma más específica y meditada.⁷  En concreto, 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 debe tener una visión más granular de qué acción se está intentando realizar. Por ejemplo, a un nivel muy general, se puede conceder el privilegio de «acceso al sistema de archivos», pero «lectura del sistema de archivos» es una especificación más precisa del privilegio realmente necesario, lo que permite una implementación de alta calidad del modelo de seguridad positivo.

Por último, las aplicaciones más sofisticadas del principio de mínimo privilegio pueden combinarse con implementaciones maduras de «verificar explícitamente», al considerar que los privilegios autorizados de un actor no son absolutos, sino que dependen del nivel de confianza proporcionado por la autenticación. Por tanto, los privilegios solo se conceden si la confianza en la identidad acreditada (Quién) alcanza un umbral mínimo, cuyos valores dependen de la acción que se intenta realizar. Por ejemplo, una acción especialmente trascendente (como apagar el sistema) puede requerir un nivel de confianza igual o superior al 90 % en que el actor sea un administrador. En este ejemplo, si al intentar apagar el sistema el nivel de confianza en la identidad es solo del 80 %, el sistema requerirá una verificación adicional para aumentar el nivel de confianza en la identidad acreditada antes de permitir la acción.

Evaluar continuamente

La verificación explícita y el privilegio mínimo son conceptos clave; sin embargo, el principio de evaluación continua refleja que dichos principios deben evaluarse de forma permanente, en el sentido de que:

1. Todas las transacciones deben estar sujetas a verificación y a la aplicación del principio de mínimo privilegio. En otras palabras, no se debe inspeccionar únicamente un subconjunto de las transacciones, como «la primera transacción de una sesión de usuario» o «las transacciones iniciadas mediante una carga de trabajo en un contenedor Docker». Aunque esto pueda parecer evidente, muchas implementaciones de confianza cero no validan todas las transacciones, ya sea por un diseño deficiente o por falta de visibilidad. Entre las deficiencias habituales en este ámbito se encuentran aplicar la confianza cero únicamente a los actores externos, pero no a los internos, o asumir que un dictamen de confianza cero sigue siendo válido durante un periodo prolongado.
2. Los factores clave de la evaluación —la confianza en la identidad del actor y los derechos que se le conceden— 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 canal lateral; por tanto, cualquier política basada en la confianza también debe adaptarse dinámicamente a esas variaciones. Además, un umbral de privilegios concedido previamente por una política puede revocarse poco después, o puede cambiar el nivel mínimo de confianza necesario para realizar una acción determinada. Aunque los plazos de los cambios en las políticas pueden variar —pueden producirse lentamente (según los plazos propios de los procesos operativos humanos) o con rapidez (mediante agentes de gobernanza automatizados)—, el sistema debe ser capaz de responder dinámicamente a esos cambios y aplicarlos.

Dar por sentada una brecha de seguridad

El principio final se basa en la presunción de que existen adversarios muy motivados, en un contexto de paranoia saludable. En concreto, la premisa es «dé por hecho que ha sufrido una brecha», donde «brecha» 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 raíz de esta elusión puede ser un conocimiento imperfecto (por ejemplo, una puntuación de confianza alta e incorrecta en la autenticación debido a credenciales fraudulentas no detectadas), limitaciones de implementación (por ejemplo, no disponer de un nivel de detalle suficiente en los privilegios concedidos, como tener «abrir una conexión de red» como privilegio, pero sin poder diferenciar en función de la geolocalización del destino de la red) o una implementación incompleta de la confianza cero (por ejemplo, no aplicar la confianza cero a componentes vulnerables de código abierto utilizados internamente).

Por lo tanto, el enfoque de confianza cero también debe abordar la mejor manera de gestionar y minimizar el impacto de dichas brechas de seguridad.

La implementación de este principio varía más que la de los demás, pero generalmente se manifiesta de las siguientes formas:

• En primer lugar, identifique las transacciones que, aunque estén técnicamente permitidas por la política, resulten sospechosas. El concepto de «sospechoso» suele depender mucho del contexto, pero las interpretaciones habituales son: (a) transacciones anómalas muy diferentes de los comportamientos observados anteriormente; (b) grupos de transacciones que son normales por separado, pero inusuales en conjunto; por ejemplo, leer y escribir un archivo puede ser habitual, pero hacerlo a una velocidad de 1000 archivos por segundo puede resultar inusual; o (c) acciones relacionadas con un efecto no deseado en el sistema que no se haya observado anteriormente; por ejemplo, un patrón en el que una transacción específica abre una conexión de red con un nodo TOR o provoca un aumento significativo de la carga de la CPU del sistema.
• A continuación, realice un análisis más exhaustivo, ya sea mediante un flujo de trabajo totalmente automatizado o mediante uno híbrido, controlado por personas y asistido por aprendizaje automático, para determinar si esas transacciones no son válidas. Si se determina que no lo son, aplique medidas de mitigación. Estas pueden consistir en una actualización general de las políticas o, como capa adicional de mitigación, en una «salvaguarda» para las demás medidas de mitigación basadas en políticas.

Si se opta por utilizar ajustes basados en políticas, estos pueden aplicarse mediante 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 a nivel de transacción (es decir, dejar de permitir que Quién haga Qué a Quién) o, en su lugar, aplicar un «criterio de prueba» más estricto (es decir, exigir MFA o una puntuación de confianza más alta) para que un actor (o una clase de actores) lleve a cabo una acción específica.

Si, por el contrario, se opta por utilizar una capa adicional de «protección», esta estrategia también puede implementarse con un nivel de granularidad fino o grueso. La estrategia más granular consistiría en bloquear única y exclusivamente aquellas transacciones que superen una determinada relación entre riesgo y beneficio, aunque esta solución también podría añadir niveles de latencia inaceptables a algunas transacciones permitidas si la implementación requiere un análisis adicional. En su lugar, podrían utilizarse estrategias menos granulares, como ejecutar en un entorno aislado las futuras transacciones de ese actor o incluso impedir por completo su acceso al sistema. En casos extremos, podrían ser apropiados métodos de mitigación aún menos granulares, como deshabilitar la E/S de archivos.

Por supuesto, en igualdad de condiciones, suele ser preferible una mitigación de último recurso más granular. Sin embargo, a menudo es necesario buscar un equilibrio en función de las limitaciones de las tecnologías disponibles para la solución, y una medida de último recurso poco granular suele ser mejor que no contar con ninguna. Por ejemplo, si la respuesta poco granular para prevenir un posible ataque de ransomware consiste en deshabilitar la E/S de archivos, los efectos secundarios de dicha respuesta podrían seguir siendo preferibles a la alternativa —permitir que el agente continúe operando en el sistema sin ningún control—, suponiendo que la inacción diera lugar a un sistema de archivos cifrado por ransomware.

Confianza cero: en realidad, empieza antes de las operaciones

Como era de esperar, el mejor punto de partida para desarrollar aplicaciones seguras mediante un modelo de confianza cero es el principio. Los principios fundamentales que permiten aplicar el modelo de confianza cero en la práctica deben incorporarse en la fase de diseño de los procesos de desarrollo de aplicaciones. Por tanto, cualquier debate sobre una solución operativa de confianza cero integrada en el flujo de CI/CD debe comenzar por comprender estos elementos fundamentales, que deben considerarse aspectos prioritarios del diseño.

El núcleo de estos elementos fundamentales debe reflejar el comportamiento deseado o previsto de las interacciones entre los sistemas, junto con una visibilidad y un control suficientes para detectar desviaciones y actuar ante ellas. Las interacciones previstas se utilizan para definir el conjunto de acciones deseado (Qué) para cada actor (Quién) con respecto a cada objetivo (A quién). Dicho esto, puede haber situaciones y entornos en los que se desconozcan los patrones de interacción previstos. En esos casos, una organización puede aprovechar una mayor visibilidad para «descubrir» el conjunto de interacciones adecuadas,⁸ que posteriormente puede codificar en una política.

Por ejemplo, en las soluciones ZTNA actuales, que se centran en el control de acceso basado en la identidad a las API externas de una aplicación, se requiere visibilidad y control sobre las API de autenticación. Asimismo, en el contexto de las plataformas de protección de cargas de trabajo en la nube (CWPP), para detectar una carga de trabajo de contenedor comprometida es necesario tener visibilidad de las acciones que realiza cada contenedor y, si se requiere una corrección inmediata, disponer de ella en tiempo real.

A continuación se enumeran las principales «categorías» relacionadas con las consideraciones fundamentales que deben formar parte del proceso de diseño, junto con un análisis más detallado que plantea preguntas específicas sobre las que reflexionar para cada uno de los puntos clave:

• ¿Cuáles son las interfaces de caja negra —entradas y salidas— del sistema?
  • ¿Cuáles son los tipos de usuarios —administradores, usuarios autenticados, usuarios no autenticados y socios— 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 «sin procesar» o comunicaciones 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 mediante API, ¿hasta qué punto está bien definida la API en cuanto a qué usuarios pueden interactuar con ella y las restricciones aplicables a dichas interacciones (p. ej., restricciones de parámetros, límites de frecuencia, etc.)?
    • En cualquier comunicación de red, ¿se cifran todos los datos transmitidos?
    • Si existen interfaces de datos «sin procesar» (por ejemplo, si se comparte información entre el cliente y la aplicación mediante un almacén de objetos o una base de datos), ¿hay registros de auditoría que permitan saber quién accedió a qué información y cuándo?
• Del mismo modo, en el ámbito interno de «caja blanca», ¿cuáles son los servicios que componen las aplicaciones en su conjunto, incluidos los servicios prestados externamente, y cómo se comunican entre sí?
  • ¿Cómo se comunican estos servicios? ¿Qué API se utiliza y qué restricciones (roles, controles de acceso, límites de frecuencia, parámetros, etc.) se aplican a esas interacciones?
    • Existen cuestiones similares a las anteriores en torno al grado de formalización de la API, sus restricciones y el cifrado de las comunicaciones.
    • Es más probable que las comunicaciones «internas» (p. ej., entre cargas de trabajo o contenedores) utilicen memoria compartida e interfaces basadas en el sistema de archivos; se debe identificar cualquier interfaz de este tipo.
• ¿Qué mecanismos de control ofrece el sistema para limitar el acceso a las interfaces de caja negra y a las vías de comunicación internas?
  • ¿Existe alguna política que indique quién —qué roles— puede invocar API específicas y qué ocurre si se incumple dicha política? Asimismo, ¿qué mecanismos existen para detectar y mitigar cualquier tipo de uso indebido de las API, como el uso de parámetros no válidos o una frecuencia de invocación excesiva? ¿Pueden actualizarse dinámicamente esas políticas en función de la información contextual procedente de otros sistemas?
  • De forma análoga, ¿existen políticas que restrinjan las demás formas de comunicación entre cargas de trabajo —sistemas de archivos, almacenes de objetos y tablas de bases de datos— en cuanto a quién puede acceder a qué archivos, almacenes o tablas, y que eviten el uso indebido de esos recursos (p. ej., «SELECT * from <table>»)?
• ¿Qué mecanismos de 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 cada API y en qué momento? ¿Se conservan estos datos y, de ser así, durante cuánto tiempo? ¿Con qué rapidez se ponen a disposición dichos datos (en tiempo real, cada hora, etc.)? ¿En qué medida son fáciles de utilizar? ¿Se trata de un registro de archivo no estructurado, de datos estructurados en formato JavaScript Object Notation (JSON) que pueden enviarse a un servicio de gestión de eventos e incidentes de seguridad (SEIM), o de datos almacenados en una tabla de una base de datos de macrodatos?
  • ¿Cuáles son las respuestas a esas mismas preguntas en lo que respecta a otras vías de comunicación, como la memoria, los archivos, los objetos y las 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 mecanismos de control y supervisión ofrece el sistema para evitar la asignación o el consumo excesivos de recursos?
  • ¿Ofrece el sistema visibilidad sobre las métricas de consumo de recursos (CPU, memoria, ancho de banda, escalado de pods, etc.)? En caso afirmativo, ¿qué nivel de granularidad tienen y hasta qué punto son fáciles de utilizar esos datos?
  • ¿Dispone el sistema de controles o mecanismos de protección para el consumo de recursos, como límites de memoria, CPU y E/S de archivos por carga de trabajo, seguimiento de las llamadas al sistema para la creación de procesos, límites para el escalado vertical y horizontal de los pods, y límites de frecuencia para las API que invocan otros servicios?

Plantear explícitamente estas preguntas le ayudará a detectar las carencias existentes en la base necesaria para habilitar un modelo de confianza cero. A menudo, el mero hecho de formularlas en las primeras fases del diseño hará que la carencia se subsane con un esfuerzo de diseño adicional mínimo. Y, cuando una carencia pueda persistir, el simple hecho de conocerla ayudará a centrar los esfuerzos adicionales de seguridad o a identificar superficies de ataque vulnerables.

Realizar este tipo de análisis previo de desarrollo seguro es una parte fundamental de la mentalidad de confianza cero. Sin embargo, pese a ello, gran parte de la atención que recibe actualmente la confianza cero se centra en lo que ocurre después del diseño inicial, y la mayoría de las empresas centran buena parte de sus esfuerzos en los aspectos de la confianza cero posteriores al diseño. No obstante, considerar detenidamente durante la fase de diseño los requisitos para implementar eficazmente la confianza cero evitará tener que realizar esfuerzos adicionales mucho mayores para «tapar los agujeros» una vez desplegada la aplicación.

Consideraciones sobre la mitigación: rapidez, falsos positivos/negativos y riesgo

Tal como refleja la premisa «presuponer una brecha» de este enfoque, un profesional de la seguridad debe asumir que algún adversario con la suficiente motivación logrará ejecutar una transacción maliciosa: un caso de Quién hace Qué a Quién que cumplía las reglas de la política, pero que, en un mundo perfecto, no debería haberse permitido. En tales casos, la atención pasa a centrarse en disponer de un mecanismo de «última línea de defensa» eficaz que pueda detectar esos casos, normalmente a partir de la observación de patrones de transacciones y efectos secundarios en el sistema, tal como se describe en la sección anterior sobre «presuponer una brecha».

Sin embargo, al igual que ocurre con el concepto de identidad, nunca se podrá saber con total certeza si una transacción concreta es maliciosa o no. Por tanto, como en el caso de la identidad, una solución de confianza cero ideal debería indicar un nivel de «confianza» en la legitimidad de la transacción. Por ejemplo, observar que un demonio lee y escribe archivos a una velocidad 10 veces superior a la habitual durante 10 segundos podría dar lugar a un nivel de confianza (en que se trate de una actividad maliciosa) del 70 %, mientras que observar un aumento de 100 veces durante 1 minuto podría elevarlo al 95 %. En este ejemplo, adoptar la medida correctiva de impedir futuras escrituras de archivos seguiría conllevando cierta probabilidad (del 30 % o del 5 %) de que la respuesta fuera incorrecta, es decir, un «falso positivo». Por tanto, la decisión de aplicar o no medidas correctivas debe tener en cuenta el riesgo de falsos positivos frente al posible impacto de permitir un comportamiento potencialmente malicioso.

El objetivo del ejemplo es destacar que cualquier decisión de adoptar una medida correctiva visible para el usuario es, en realidad, una decisión empresarial que tiene en cuenta todos los riesgos, costes y beneficios asociados a la actividad sospechosa. Introducir obstáculos adicionales en la transacción aumenta la probabilidad de que no se obtenga el valor esperado, pero no intervenir ni añadir obstáculos conlleva el riesgo de que se produzca una vulneración. Por tanto, la decisión de actuar (o no) en estos casos depende de tres factores:

1. ¿Cuál es el riesgo de permitir que continúen transacciones potencialmente maliciosas?
   Este riesgo puede ser directamente económico, como en el caso de una transferencia de fondos bancarios, o puede conllevar costes indirectos, ya sean operativos (por ejemplo, el cifrado de registros clave para exigir un rescate) o reputacionales (por ejemplo, la alteración maliciosa de un sitio web). También puede haber costes legales o derivados del cumplimiento normativo, como los ocasionados por la filtración de datos personales de clientes. En esencia, la evaluación del riesgo es una cuestión de gobernanza, y una buena gobernanza permitirá comprender y cuantificar los riesgos para la aplicación.
2. ¿Cuáles son los efectos secundarios de adoptar la medida correctiva?
   Los efectos secundarios pueden expresarse en función de dos dimensiones: (a) la fricción introducida y (b) el radio de impacto. La fricción indica cuánto más difícil resulta llevar a cabo una transacción legítima; puede ir desde una ligera molestia adicional (por ejemplo, un nivel adicional de autenticación) hasta la imposibilidad de realizarla (la transacción simplemente no se permite). El radio de impacto hace referencia a si otras transacciones independientes también se verán afectadas y, de ser así, a cuántas. Por ejemplo, bloquear a un usuario concreto solo afectará a ese usuario, pero desactivar un servicio de registro afectará a la capacidad de auditoría de todos los usuarios y transacciones. 
3. ¿Qué grado de certeza se tiene de que la transacción es maliciosa?
   Aumentar el grado de certeza suele implicar recopilar más datos y correlacionarlos entre un mayor número de fuentes, dos tareas que requieren tiempo. Por eso, en la práctica, esta disyuntiva suele plantearse así: «¿Cuánto tiempo debo observar antes de decidirme a actuar?»

Así pues, aunque una estrategia de confianza cero debe asumir que se producirán brechas de seguridad, un enfoque bien meditado sopesará los riesgos y beneficios a la hora de corregir las transacciones permitidas que parezcan sospechosas. Para ello, se tendrán en cuenta el nivel de riesgo de las distintas transacciones de la aplicación y las consecuencias de aplicar medidas correctivas, que solo se adoptarán si el nivel de riesgo supera el beneficio empresarial esperado.

_{¹ 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
⁷ Esta previsió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 derivado de la observación esté incompleto o presente algún riesgo preexistente. Por lo tanto, siempre es preferible preverlo durante el diseño.}

PUBLICADO EL 4 DE MAYO DE 2022