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:
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.
Las secciones posteriores profundizan en cada una de las capas concéntricas de este diagrama, pero en resumen:
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:
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:
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.
Las exigencias de aceleración del negocio conducen a nuevas prácticas que agravan el riesgo de ciberseguridad. A continuación analizamos este punto con más detalle.
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.
Tras un aluvión de ciberataques persistentes contra varias agencias gubernamentales federales, estatales y locales de Estados Unidos, y diferentes empresas estadounidenses, el presidente Joe Biden emitió una orden ejecutiva para mejorar la ciberseguridad de la nación el 12 de mayo de 2021. Uno de los elementos clave de esta orden es que los organismos gubernamentales utilicen los principios de confianza cero para estar preparados frente a los ciberataques. La Administración Biden siguió esta orden con un memorando de la oficina de gestión y presupuesto (OMB) para los jefes de departamentos y agencias ejecutivas el 26 de enero de 2022. Este memorando de la OMB «establece una estrategia federal de arquitectura de confianza cero (ZTA) que exige a los organismos que cumplan normas y objetivos específicos de ciberseguridad para finales del año fiscal de 2024 con el fin de reforzar las defensas del Gobierno contra las campañas de amenazas cada vez más sofisticadas y persistentes».1 Tanto la orden ejecutiva como el memorando de la OMB hacen referencia a la arquitectura de confianza cero descrita en la publicación SP 800-207 del Instituto Nacional de Estándares y Tecnología (NIST), publicada en agosto de 2020, y exigen a los organismos gubernamentales que la sigan.
Los líderes de opinión de las agencias gubernamentales y del sector privado han publicado documentos que ayudan a explicar la arquitectura de confianza cero y ofrecen consejos sobre la mejor manera de adoptarla. A continuación resumimos las ideas contenidas en estos documentos. Observamos que la esencia crítica de las ideas y sugerencias de estos documentos es examinar cada transacción para evaluar Quién intenta Qué acción sobre Quién, y tomar una decisión en tiempo real para permitir o rechazar la transacción con base en el cálculo del riesgo asociado a ella.
El equipo del NIST enumera los principios de la confianza cero y define una arquitectura abstracta de confianza cero (ZTA) en su documento NIST SP 800-207.2 Además, analiza las variaciones de los enfoques de confianza cero y describe diferentes maneras de desplegar la arquitectura abstracta.
Las abstracciones clave que se analizan en el documento son el punto de decisión de directivas (PDP) y el punto de aplicación de directivas (PEP), que funcionan conjuntamente. El punto de decisión de directivas está compuesto por el motor de directivas (PE) y el administrador de directivas (PA). El motor de directivas utiliza un algoritmo de confianza para tomar decisiones sobre si se debe conceder acceso a un recurso a un sujeto. Esta decisión la ejecuta el Administrador de Políticas, que se comunica con el Punto de Aplicación de Políticas para permitir o rechazar una nueva sesión y para modificar o terminar una sesión existente. Además, el documento analiza las variaciones del algoritmo de confianza, los componentes de la red para un entorno de confianza cero y diversos casos de uso o escenarios de despliegue. Por último, se examinan las formas en que la arquitectura de confianza cero puede ser frustrada por los atacantes, de modo que los implementadores sean conscientes de las amenazas y tomen las medidas adecuadas para proteger sus componentes de la arquitectura de confianza cero.
Con el objetivo de ayudar a las agencias a desarrollar sus planes de confianza cero, los líderes de la Agencia de Ciberseguridad y Seguridad de las Infraestructuras (CISA), publicaron un modelo de madurez de confianza cero.3 El trabajo se basa en la arquitectura abstracta de confianza cero descrita en el documento del NIST SP 800-207. Los autores identifican cinco áreas y recomiendan que las organizaciones avancen de forma consistente en el seguimiento de los principios de la confianza cero en cada área. Las áreas son (i) identidad, (ii) dispositivo, (iii) red, (iv) carga de trabajo de la aplicación y (v) datos. Recomiendan el uso de visibilidad y análisis, y la automatización y orquestación en cada una de las cinco áreas.
El documento ofrece un modelo de madurez de alto nivel en los cinco pilares fundamentales de la confianza cero identificados anteriormente, y profundiza en cada área. Las organizaciones pueden utilizar el modelo de madurez para entender su estado actual y establecer un curso iterativo hacia el estado óptimo.
Tras el descubrimiento de los ataques de Solar Winds, la Agencia de Seguridad Nacional (NSA) publicó unas directrices en las que aconsejaba a los equipos de ciberseguridad que adoptaran un modelo de seguridad de confianza cero en su documento «Adoptar un modelo de seguridad de confianza cero».4 Los expertos del equipo de ingeniería de confianza cero de la Agencia de Sistemas de Información de Defensa (DISA) y la Agencia de Seguridad Nacional fueron los autores de la arquitectura de referencia de confianza cero del Departamento de Defensa (DOD).5 Los autores expresan la necesidad de adoptar la confianza cero con la siguiente afirmación: «Las vulnerabilidades expuestas por las violaciones de datos dentro y fuera del DOD demuestran la necesidad de aplicar un nuevo modelo de ciberseguridad más sólido que facilite la toma de decisiones bien informadas basadas en el riesgo».6
Esta arquitectura de referencia basa sus recomendaciones en las abstracciones definidas en el documento sobre arquitectura de confianza cero del NIST SP 800-207. El documento presenta un modelo operativo de alto nivel y describe sus elementos en detalle. También incluye un modelo de madurez de alto nivel y la asignación de capacidades para aplicar los principios de confianza cero a diversas áreas de interés. En conjunto, estos documentos ayudan a las organizaciones a evaluar su estado actual y a diseñar un plan.
Tener una actitud que «asuma el incumplimiento» y seguir los principios de confianza cero puede ayudar a las organizaciones en sus prácticas de gestión de riesgos y gobernanza. Los principios de confianza cero de «supervisión continua» y «verificación explícita» de los actores que participan en las transacciones permiten a las organizaciones crear una puntuación de riesgo dinámica para todos los actores y sus actividades. Esto está en consonancia con la recomendación de Gartner de utilizar la metodología de «evaluación adaptativa y continua del riesgo y la confianza» (CARTA, por sus siglas en inglés) para mejorar los programas de seguridad existentes. Adoptar el principio de permitir únicamente el acceso a los recursos con los mínimos privilegios reduce el riesgo de pérdidas incluso tras una infracción. La información generada por la supervisión continua y la verificación explícita también es útil para generar informes de cumplimiento.
Esta sección pretende centrarse en la mentalidad (el sistema de creencias, el «porqué») que motiva la estrategia y las decisiones en torno a las herramientas y el diseño que debe adoptar una empresa para lograr una seguridad de confianza cero. De hecho, es posible simplificar el ímpetu de todos los métodos y las tecnologías de componentes empleados por las soluciones actuales de confianza cero a cuatro simples principios clave. Esta sección comienza con una enumeración de estos principios, seguida de un debate sobre cómo pueden aplicarse en el contexto más amplio del ciclo de vida del desarrollo de aplicaciones (es decir, cómo tener en cuenta estos principios desde el primer momento, en la fase de diseño, así como desde el punto de vista operativo, en el despliegue/ejecución de la aplicación).
Si las soluciones de confianza cero se entienden fundamentalmente como la generación de confianza en las interacciones del sistema («¿Quién hace Qué a Quién?»), entonces la creación de un nivel de confianza apropiado para la interacción puede resumirse en cuatro componentes.
Como su nombre indica, la mentalidad de confianza cero es la de «no confiar ciegamente, siempre es necesario verificar». Por tanto, cualquier actor del sistema (el Quién y el Sobre quién en las interacciones) debe poder:
Además, el principio de verificación explícita no solo puede aplicarse a la identidad, sino también a la acción: el Qué de la transacción. Un caso de uso común es cuando la acción se expresa como una llamada a la API, usar una API para realizar una consulta a la base de datos. En este ejemplo, el principio de verificación explícita puede utilizarse no solo para confiar en la identidad del actor que llama a la API, sino también para verificar la corrección del uso de la acción de la API, como por ejemplo verificar que los parámetros pasados a la API se ajustan a las restricciones adecuadas.
En una mentalidad madura de confianza cero, la «prueba» casi nunca es absoluta. Las credenciales de identidad pueden ser robadas, los dispositivos pueden verse comprometidos y las restricciones de los parámetros de la API suelen ser incompletas. Por lo tanto, el término «confianza» en el contexto de la confianza cero debe interpretarse más bien como una indicación de la probabilidad de que los parámetros confirmados de la identidad o la transacción sean legítimos. Así, el nivel de «confianza» debe considerarse un factor clave, pero no el único, a la hora de tomar la decisión de si permitir, bloquear o inspeccionar más a fondo una transacción.
Una vez que se establece un nivel aceptable de «confianza» en los actores que participan en una transacción, el enfoque de confianza cero requiere que al actor (normalmente, el solicitante, el «Quién») se le conceda solo el conjunto mínimo de privilegios necesarios para que pueda hacer lo que se haya determinado en ese sistema. Este principio encarna lo que también se denomina «modelo de seguridad positiva»: un enfoque en el que todas las acciones están prohibidas por defecto, y en el que solo se conceden los privilegios específicos necesarios para el funcionamiento del sistema. Por ejemplo, un sistema de reservas puede permitir que usuarios anónimos consulten los horarios de los vuelos, pero, según los requisitos de diseño de la aplicación, no reservar un vuelo.
Estos privilegios pueden aplicarse a actores individuales o a clases de actores. Normalmente, los consumidores de aplicaciones son actores o representantes humanos, y se agrupan en clases, como «usuarios anónimos», «clientes», «socios» o «empleados». Las clases menos fiables de actores suelen requerir un umbral de confianza más bajo para superar la autenticación, pero también tienen acceso a menos API o a API menos sensibles. Los actores internos a la aplicación o a su infraestructura, como servicios o contenedores específicos dentro de una aplicación, pueden tener privilegios más personalizados, como «solo contenedores, pueden acceder a la base de datos. Solo pueden escribir en el almacén de objetos, pero y pueden leer los datos que contiene».
Una consideración importante para la implementación del mínimo privilegio es esforzarse por aplicarlo de una manera más personalizada, con previsión.7 Específicamente, en lugar de aplicar un conjunto genérico de privilegios a todos los actores, o a una clase de actores, una implementación madura de confianza cero debería tener una visión más detallada del Qué, la acción que se intenta realizar. Por ejemplo, de forma general, se puede conceder el privilegio de «acceso al sistema de archivos», pero el de «lectura del sistema de archivos» es una especificación más estricta del verdadero privilegio requerido, lo que sería una implementación de alta calidad del modelo de seguridad positiva.
Por último, las formas más sofisticadas del privilegio mínimo pueden funcionar junto con las implementaciones maduras de «verificación explícita» al considerar que los privilegios autorizados para un actor no son absolutos, sino que se basan en la confianza proporcionada por la autenticación. Así, los privilegios solo se conceden si la confianza en la identidad confirmada (el Quién) alcanza el umbral mínimo, siendo estos específicos para la acción que se intenta realizar. Por ejemplo, las acciones especialmente impactantes (por ejemplo, apagar el sistema) pueden requerir un 90 % o más de confianza al determinar que el actor es un administrador. En este ejemplo, si la confianza del sistema en la identidad es solo del 80 %, al intentar apagar el sistema, este pedirá una verificación adicional para aumentar la puntuación de confianza antes de permitir la acción.
La verificación explícita y el mínimo privilegio son conceptos clave, sin embargo, el principio de evaluación continua recoge el hecho de que esos principios deben ser evaluados continuamente, en el sentido de que:
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í:
Si el enfoque elegido es utilizar ajustes basados en políticas, los ajustes pueden aplicarse aprovechando cualquiera de las herramientas de política estática disponibles. Ejemplos de ajustes basados en políticas serían restringir los privilegios de control de acceso a las transacciones (es decir, dejar de permitir que Quién haga Qué a Quién) o aplicar en su lugar una «norma de prueba» más estricta (es decir, requerir MFA o una puntuación de confianza más alta) para que un actor (o clase de actores) pueda realizar una acción específica.
Si, por el contrario, se opta por el enfoque de utilizar una capa adicional de «respaldo», esta estrategia también puede implementarse de forma detallada o más amplia. La estrategia más detallada consistiría en bloquear únicamente las transacciones que superen una relación riesgo-recompensa específica, aunque esta solución también tiene la posibilidad de añadir niveles inaceptables de latencia en algunas transacciones permitidas si la implementación requiere un análisis adicional. En su lugar, se podrían utilizar estrategias más generales, como el aislamiento de las futuras transacciones de ese actor o incluso la prohibición total del actor en el sistema. En casos extremos, pueden ser apropiados métodos de mitigación aún más amplios, como el cierre de la E/S de los archivos.
Por supuesto, en igualdad de condiciones, suele ser preferible una mitigación de respaldo más detallada. Sin embargo, a menudo hay que hacer concesiones en función de las limitaciones de las tecnologías disponibles, y tener un respaldo más amplio suele ser mejor que no tener respaldo. Por ejemplo, si la respuesta general para evitar un posible ransomware es deshabilitar la E/S de los archivos, los efectos secundarios de esa respuesta pueden ser preferibles a la alternativa, es decir, permitir que el actor siga operando en el sistema sin control, asumiendo que el resultado de la falta de acción sería tener un sistema de archivos cifrado por el ransomware.
El mejor punto de partida para el desarrollo de una aplicación segura que utilice la confianza cero es, como es lógico, el principio. Los principios fundamentales que permiten hacer operativos los principios de la confianza cero deben estar presentes en la fase de diseño de los procesos de desarrollo de las aplicaciones. Por lo tanto, cualquier discusión sobre una solución operativa de confianza cero integrada en el proceso de CI/CD debe comenzar con una comprensión de estos elementos fundacionales que deben ser consideraciones de diseño de primera clase.
El núcleo de estos elementos fundacionales debe capturar el comportamiento deseado/previsto de la interacción de los comportamientos del sistema, junto con la suficiente visibilidad y control para detectar las desviaciones y actuar sobre ellas. Las interacciones previstas se utilizan para definir el conjunto deseado de acciones (Qué) para cada actor (Quién) sobre cada objetivo (Sobre quién). Dicho esto, puede haber algunos escenarios y entornos en los que se desconozcan los patrones de interacción previstos. En estos casos, una organización puede aprovechar una visibilidad más profunda para «descubrir» el conjunto de interacciones apropiadas,8 que luego puede codificar en la política.
Por ejemplo, en las soluciones actuales de ZTNA, que se centran en el control de acceso basado en la identidad a las API externas de una aplicación, se requiere visibilidad y controles en las API de autenticación. O, en el contexto de la plataforma de protección de cargas de trabajo en la nube (CWPP), la detección de una carga de trabajo de contenedor comprometida requiere visibilidad de las acciones que realiza cada contenedor, y en tiempo real, si se requiere una reparación en tiempo real.
A continuación se presenta una lista de los «cubos» de alto nivel relacionados con las consideraciones fundamentales que deberían formar parte del proceso de diseño, con desgloses adicionales para proporcionar preguntas específicas sobre las que pensar en cada uno de los puntos clave:
Según la premisa de «asumir la infracción», un profesional de la seguridad debe asumir que los adversarios suficientemente motivados se las arreglarán para ejecutar una transacción maliciosa, un caso de Quién hace Qué a Quién que cumpla las normas de la política, pero, que no debería haber sido permitido en un mundo ideal. En tales casos, el enfoque se centra en tener un mecanismo eficaz de «respaldo» que pueda encontrar esos casos, generalmente con base en observaciones de patrones de transacciones y efectos secundarios del sistema, como se describe en la sección anterior «Asumir las infracciones».
Sin embargo, al igual que con la noción de identidad, el conocimiento de si una transacción específica es malintencionada o no nunca será perfecto. Por tanto, al igual que con la identidad, una solución ideal de confianza cero debería informar de una puntuación de «confianza» en la legitimidad de la transacción. Por ejemplo, ver una lectura y escritura de un demonio 10 veces más rápido que la tasa normal de archivos durante 10 segundos podría dar como resultado una puntuación de confianza (de malicia) del 70 %, pero si la tasa aumenta 100 veces de forma sostenida durante 1 minuto, podría elevar la confianza al 95 %. En este ejemplo, tomar la acción correctiva de inhibir futuras escrituras de archivos seguirá teniendo alguna posibilidad (un 30 % o 5 %) de ser la respuesta incorrecta (un «falso positivo»). Por tanto, la decisión de corregir el problema o no debe considerar el riesgo de tener falsos positivos, frente al impacto potencial de permitir el comportamiento posiblemente malicioso.
El objetivo del ejemplo es destacar que cualquier decisión basada en realizar una acción correctiva visible para el usuario es en realidad una decisión empresarial. Una decisión que considera todos los riesgos, los costes y las recompensas en relación a la actividad sospechosa. Introducir más fricciones en la transacción aumenta la probabilidad de no recibir el valor, pero no intervenir y no añadir esta fricción introduce el riesgo de compromiso. Por tanto, la decisión de actuar (o no) en estos casos es una función de tres entradas:
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.
1 https://www.whitehouse.gov/wp-content/uploads/2022/01/M-22-09.pdf
2 https://csrc.nist.gov/publications/detail/sp/800-207/final
3 https://www.cisa.gov/zero-trust-maturity-model
4 https://media.defense.gov/2021/Feb/25/2002588479/-1/-1/0/CSI_EMBRACING_ZT_SECURITY_MODEL_UOO115131-21.PDF
5 https://dodcio.defense.gov/Portals/0/Documents/Library/(U)ZT_RA_v1.1(U)_Mar21.pdf
6 https://dodcio.defense.gov/Portals/0/Documents/Library/(U)ZT_RA_v1.1(U)_Mar21.pdf
7 La reflexión comienza en la fase de diseño, como se describe más adelante.
8 O, al menos, el conjunto de interacciones «consideradas apropiadas» que el sistema parece requerir. Siempre existe el riesgo de que el conjunto de interacciones derivadas de la observación sea incompleto o tenga algún riesgo preexistente. Por tanto, en el diseño siempre es preferible la previsión.