Consideración de las técnicas y tecnologías para la adopción de Zero Trust

Expandiéndose desde el “por qué”: los principios rectores¹ —de confianza cero, la siguiente preocupación es “cómo”: las técnicas y tecnologías utilizadas para implementar esos principios.

Desde la perspectiva más amplia, los principios de confianza cero se pueden aplicar a todo el ciclo de vida del desarrollo de aplicação , incluido el diseño del sistema, las plataformas de hardware utilizadas y los procedimientos de adquisición.² Sin embargo, este documento analiza los aspectos operativos de la implementación de confianza cero para defender aplicações y datos en tiempo de ejecución. 

En términos generales, la seguridad de zero trust utiliza tecnologías para lograr uno de estos tres objetivos:

1. Hacer cumplir las restricciones transaccionales: ¿Quién puede hacerle qué a quién ?
2. Proporcionar conocimiento de la situación al operador humano del sistema.
3. Realizar una reducción/remediación de riesgos más avanzada basada en los indicadores de sospecha asistidos por aprendizaje automático (ML) y el perfil de riesgo-recompensa de las transacciones en cuestión.

El siguiente gráfico representa este modelo transaccional de seguridad de zero trust, y las siguientes secciones profundizan en cada tipo de tecnología.

Las dos primeras tecnologías (autenticación y control de acceso) están estrechamente relacionadas y están directamente motivadas por los principios de “verificación explícita” y “mínimo privilegio”, ya que estas tecnologías son fundamentales para hacer cumplir “ quién puede hacer qué ”. Las implementaciones más sofisticadas de autenticación observan el comportamiento continuo de un actor, capturando la mentalidad de “evaluar continuamente”. 

Las tecnologías de autenticación tienen como objetivo generar confianza en una identidad certificada: ¿Quién actúa en una transacción? El proceso de autenticación tiene tres componentes: 

1. Existe una declaración, o reclamación, hecha por el actor, en la que se declara la identidad del mismo.
2. Hay algunos datos, normalmente proporcionados por el actor, que prueban la veracidad de la declaración.
3. El sistema emite un veredicto o una decisión sobre la probabilidad de que la declaración sea correcta: el actor es quien dice ser. El siguiente gráfico muestra los diferentes aspectos de la autenticación y los modelos de madurez de cada uno de ellos, seguido de un análisis más profundo de cada aspecto.

La forma más básica de certificación a menudo se conoce como “usuario”: un ser humano o un agente que actúa en nombre de un ser humano y que desea realizar una transacción. Sin embargo, en el caso de confianza cero utilizada dentro de una aplicação, un actor podría ser una carga de trabajo (como un proceso, servicio o contenedor), por lo que el concepto generalizado de identidad debería incluir a dichos actores. En otros casos, la noción de Quién incluye no sólo lo humano o la carga de trabajo, sino también consideraciones o dimensiones adicionales de la identidad. Desde esa perspectiva, las dimensiones adicionales de la identidad podrían incluir el dispositivo o la plataforma del usuario/carga de trabajo, o el ecosistema utilizado para la interacción o la ubicación del agente. Por ejemplo, un usuario “Alice” puede estar en una PC etiquetada como “ABC-0001” y usar una instancia de navegador específica con huella digital, proveniente de la dirección IPv4 10.11.12.13. 

Algunos sistemas permiten a los usuarios no autentificados, a veces denominados «invitados» o «anónimos», realizar un conjunto limitado de transacciones. Para estos sistemas, los pasos adicionales de probar la identidad y que el sistema emita un veredicto no son relevantes. Sin embargo, para cualquier identidad atestiguada específica, se utilizan comúnmente los siguientes métodos para apoyar esa declaración:

• Conocimiento de un secreto compartido, como una contraseña.
• Algún tipo de credencial de un tercero de confianza, como un certificado firmado.
• Interrogación —sea automatizada (como la huella digital del dispositivo) o activa (como un captcha)— del usuario, la carga de trabajo o la plataforma.
• Metadatos relacionados con el actor, como la geolocalización, la reputación IP o la hora de acceso.
• Análisis del comportamiento, como el análisis biométrico pasivo o los patrones de flujo de trabajo de la interacción con la aplicación.

A menudo, si se requiere un alto grado de confianza, se utilizan múltiples métodos. Esto se evidencia en el modelo de Google BeyondCorp,³ que requiere autenticación multifactor (MFA) antes de permitir transacciones de mayor valor. Las soluciones de autenticación más sofisticadas asocian una “confianza” a cada identidad y especifican un nivel mínimo de confianza para cada tipo de transacción, en función del valor y el riesgo de la transacción.

Por último, hay que tener en cuenta que algunos de estos métodos no son acciones estáticas ni puntuales, sino que pueden y deben ser continuas según el principio de «evaluar continuamente». En estos casos, la puntuación de confianza asignada a la declaración de identidad puede cambiar hacia arriba o hacia abajo con el tiempo. Por ejemplo, la huella del navegador o la dirección IP pueden cambiar en la misma sesión de usuario, lo que podría considerarse sospechoso y reduce la confianza; o a medida que se recopilan más datos sobre el comportamiento del actor en una sesión, la puntuación de confianza puede aumentar o disminuir en función de cómo se compare el comportamiento actual con las observaciones anteriores.

La autenticación dinámica puede colaborar con el control de acceso en sistemas más avanzados. Como primer nivel de esta interacción, la política de control de acceso puede especificar una puntuación mínima de confianza para diferentes clases de transacciones, como se ha mencionado anteriormente. El siguiente nivel de interacción permite que el subsistema de control de acceso proporcione información al subsistema de autenticación, normalmente solicitando una autenticación adicional para aumentar la puntuación de confianza hasta el mínimo.

Después de utilizar técnicas de autenticación para determinar quién está actuando en una transacción, las siguientes preguntas son: ¿Qué se le permite hacer a ese actor? ¿Y a quién ? Esto es competencia de las tecnologías de control de acceso.

Si hacemos una analogía con la seguridad física, imagine que quiere visitar una base militar. Después de que los guardias determinen con seguridad que es un civil, un político o un soldado, utilizarían esa determinación para decidir a qué edificios podría entrar y si podría entrar con una cámara en los edificios a los que pueda entrar. La política que rige estas opciones puede ser muy general y aplicarse a todos los edificios (por ejemplo, «los políticos pueden entrar en cualquier edificio») o puede ser más precisa («los políticos solo pueden entrar en los edificios <A> y <B>, y solo pueden llevar cámaras al <A>»).

Aplicadas al contexto de la ciberseguridad, las técnicas de control de acceso deben incorporar el principio de confianza cero de “mínimo privilegio”. En otras palabras, la política de control de acceso óptima sólo permitiría exactamente aquellos privilegios que el actor requiere y prohibiría todos los demás privilegios. Además, una política robusta ideal estaría condicionada a un nivel mínimo específico de confianza en la autenticidad de la identidad del actor, con un umbral de confianza especificado en la granularidad de cada privilegio permitido.

Por lo tanto, el valor de una solución de control de acceso puede juzgarse en función de su adecuación a estos ideales. Específicamente, una solución de seguridad de confianza cero debe incluir el control de acceso y debe evaluar la tecnología de control de acceso a lo largo de las dimensiones representadas y descritas a continuación.

1. ¿Qué grado de detalle tienen los privilegios de control de acceso?

1. ¿Cuál es la granularidad de la acción (el qué) en la transacción? ¿Es esto?:

1. Binario : Permitir “todas” las transacciones o “ninguna”. En la analogía de la base militar, esto correspondería a “todos los soldados pueden entrar en cualquier edificio y hacer lo que quieran” y “los civiles no pueden entrar en ningún edificio”.
2. Grueso : Granular al punto final de la API o al “tipo” de transacción (como E/S de archivos, comunicación de red y controles de procesos). En nuestro ejemplo, esto permitiría cierto nivel de matices en torno a la acción permitida, como por ejemplo “los políticos pueden entrar a los edificios, pero no tomar fotografías”. 
3. Bien: En la sub-API (es decir, que depende de los parámetros o la versión de la API) o “subtipo” de transacción (por ejemplo, E/S de archivo de sólo lectura o sólo recepción TCP). Usando nuestra analogía una vez más, esto permitiría controles más precisos, como “los civiles pueden ingresar a los edificios solo si están acompañados por un soldado”. 

2. ¿Existe granularidad en cuanto al objetivo de la acción (el Quién en la transacción)? ¿Es esto?:

1. No granular al objetivo: La política de control de acceso no considera el objetivo de la acción. En nuestro ejemplo, este enfoque se correspondería con la granularidad de permitir la entrada a algunos edificios, pero no a otros (siendo los edificios el objetivo de la acción "entrar").
2. Objetivo granular, nivel de infraestructura: La política de control de acceso puede incluir el objetivo de la acción, pero utiliza alguna etiqueta o rótulo específico de la infraestructura, como la dirección IP, el nombre DNS o el nombre del contenedor Kubernetes (K8S) para el objetivo. Esto permitiría que la política fuera granular para cada edificio, pero cada base militar podría tener una convención de nomenclatura diferente para los edificios.
3. Granularidad del objetivo, reconocimiento de identidad: La política de control de acceso puede incluir el objetivo de la acción, identificando el objetivo utilizando el mismo espacio de nombre de identidad (por ejemplo, SPIFFE) utilizado para el actor (el Quién). La ventaja sobre el enfoque anterior es que todas las bases militares utilizarían un esquema consistente para identificar los edificios, lo que haría la política más portátil.

2. ¿Cómo aborda la solución de control de acceso el concepto de acciones de menor o mayor riesgo?

1. No consciente del riesgo: La solución de control de acceso trata todos los privilegios de control de acceso de manera idéntica, en términos de la decisión de permitir o no la acción.
2. Gestión de riesgos mediante MFA: La solución de control de acceso administra el riesgo al permitir que la política especifique que algunas transacciones permitidas aún deban usar la autenticación multifactor, en función del actor ( Quién ), la acción ( Qué ) o el objetivo ( Quién ) involucrado en la transacción.
3. Gestión de riesgos a través de la confianza: La solución de control de acceso gestiona el riesgo al permitir que la política especifique que cualquier transacción aún puede requerir un nivel mínimo de confianza en la autenticidad del actor, en función de la acción ( Qué ) y el objetivo ( Quién ) en la transacción. La MFA puede aumentar la confianza, aunque se pueden utilizar otros medios; en otros casos, puede que no se permita la transacción en absoluto si la misma es de alto valor y la autenticidad del actor es suficientemente incierta.

Teniendo en cuenta el principio de «evaluar (y reevaluar) continuamente», cualquier creencia en la autenticidad del actor debería ajustarse con el tiempo. En una solución sencilla puede ser simplemente un tiempo de espera. En sistemas más sofisticados, la confianza podría variar en función de las observaciones del comportamiento del actor a lo largo del tiempo.

Si la autenticación y el control de acceso son implementaciones de la mentalidad de «verificar siempre» y «mínimo privilegio», entonces la visibilidad y el análisis contextual son fundamentales para los principios de «evaluar continuamente» y «asumir la infracción».

La visibilidad es el precursor necesario del análisis: un sistema no puede mitigar lo que no puede ver. Por lo tanto, la eficacia de la solución de seguridad de zero trust será directamente proporcional a la profundidad y la amplitud de la telemetría que pueda recogerse de las operaciones del sistema y del contexto exterior. Sin embargo, una infraestructura de visibilidad moderna será capaz de proporcionar muchos más datos, metadatos y contextos potencialmente útiles de los que ningún humano sin ayuda podrá encargarse a tiempo. Como resultado del deseo de obtener más datos y de la capacidad de destilar esos datos en ideas más rápidamente, un requisito clave es la asistencia de las máquinas a los operadores humanos.

Esta asistencia se suele llevar a cabo mediante algoritmos automatizados que abarcan todo el espectro, desde el análisis basado en reglas, hasta los métodos estadísticos y los algoritmos avanzados de aprendizaje automático. Estos algoritmos se encargan de convertir los datos en bruto sin procesar en un conocimiento situacional procesable y operativo que pueda ser utilizado por los operadores humanos para evaluar y, si es necesario, remediar. Por esta razón, el análisis asistido por aprendizaje automático va de la mano de la visibilidad.

A continuación, se muestra el recorrido generalizado, desde los datos en bruto (visibilidad) hasta la acción (corrección):

La visibilidad es la aplicación —el «cómo»— del principio de zero trust «evaluar continuamente». Incluye el mantenimiento de un inventario de entradas de datos disponibles (Catálogo) y la telemetría en tiempo real, además de la retención de datos históricos (Recopilar).

La madurez de una implementación de visibilidad de confianza cero debe considerar cuatro factores:

1. Latencia : ¿Qué tan cerca del tiempo real están los datos?

La latencia proporciona un límite inferior a la rapidez con la que se puede responder a una amenaza potencial. La latencia de una solución de zero trust debe medirse en segundos, o menos; de lo contrario, es muy probable que cualquier análisis, por muy preciso que sea, llegue demasiado tarde para evitar el impacto del exploit, como la exfiltración/cifrado de datos o la indisponibilidad por agotamiento de recursos. Los sistemas más sofisticados pueden permitir mitigaciones tanto síncronas como asíncronas. La mitigación sincrónica inhibiría la finalización de la transacción hasta que se complete la visibilidad y el análisis. Dado que es probable que la mitigación sincrónica añada latencia a la transacción, este modo de funcionamiento se reservaría para las transacciones especialmente anómalas o arriesgadas, mientras que permitiría que todas las demás transacciones enviasen telemetría y fuesen analizadas de forma asíncrona.

2. Consumibilidad : ¿Con qué facilidad se pueden consumir los datos?
   

Esta preocupación es relevante si los datos llegan de múltiples fuentes o tipos de sensores de datos, lo cual es un escenario común. Este factor suele dividirse en dos preocupaciones secundarias.

• A nivel sintáctico, cómo se pueden extraer y representar los datos. Por ejemplo, si la reputación de la IP de origen llega como campo de texto (como «malicioso», «sospechoso», «desconocido», etc.) en un mensaje syslog de una fuente, y como campo numérico, codificado en binario, en un archivo de datos, se debe identificar una representación canónica. La serialización de datos será necesaria para extraer y transformar los datos entrantes en esa representación.

• A nivel semántico, las diferentes fuentes no solo pueden variar en su sintaxis y transporte, sino también en la semántica. Utilizando de nuevo el ejemplo de la reputación de la IP, un proveedor puede proporcionar una puntuación de amenaza en forma de número, mientras que otro puede clasificar la IP en un cubo como «nodo TOR», «Control de DNS» o «Phishing» La solución de visibilidad también debe proporcionar un mecanismo para normalizar los datos entrantes en una sintaxis coherente.

3. Lo completo: ¿Cuál es la amplitud y profundidad de los datos disponibles?

Un valor clave derivado de una solución de visibilidad de alta calidad es la capacidad de descubrir actividades sospechosas como indicador de una posible violación. Para hacerlo con eficacia, la solución debe recibir telemetría en todas las «capas» relevantes de la entrega de la aplicación: la propia aplicación, por supuesto, pero también la infraestructura de la aplicación, la infraestructura de la red, cualquier servicio aplicado o utilizado por la aplicación, e incluso los eventos en el dispositivo del cliente. Por ejemplo, identificar a un usuario que llega desde un dispositivo nuevo, nunca visto antes, puede ser ligeramente sospechoso por sí solo; pero cuando se combina con información de la red (como la asignación de la GeoIP de un país extranjero) el nivel de sospecha aumenta. Este nivel de sospecha se manifiesta como una menor puntuación de confianza en la identidad del usuario. En el contexto de una política de seguridad de confianza cero, cuando este actor intente realizar una transacción de alto valor (como la transferencia de fondos a una cuenta extranjera), la solución de control de acceso puede optar por bloquear la transacción, basándose en la baja confianza.

En relación con la mentalidad de confianza cero, cuanto más profunda y completa sea la solución de visibilidad, más eficaz será el sistema para limitar adecuadamente las transacciones y detectar las infracciones.

4. Gobernancia: ¿En qué medida se cumplen los requisitos de uso de datos establecidos por ley y por licencia?

Por último, cualquier recopilación de datos debe cumplir los requisitos legales y de concesión de licencias relativos a la seguridad, la conservación y el uso de los datos. Por lo tanto, una solución de visibilidad sólida debe abordar cada una de estas necesidades. Una solución de visibilidad de confianza cero debe tener en cuenta las limitaciones en el uso de los datos que implica la gobernanza. Por ejemplo, si una IP se considera Información Personalmente Identificable (PII), entonces el uso y la retención a largo plazo de las direcciones IP para su análisis debe atender al uso permitido de las direcciones IP.

Además de la visibilidad, la otra maquinaria necesaria para implementar la «evaluación continua» es la herramienta analítica necesaria para realizar una evaluación significativa; es decir, tener una evaluación que pueda ser utilizada por una solución de confianza cero.

Una consideración para el análisis es el alcance y la amplitud de los datos de entrada. Las entradas de los algoritmos de análisis pueden limitarse a un único flujo de datos de una sola fuente, o pueden abarcar varios flujos, incluso de varias fuentes de datos y de todas las capas de la infraestructura y la aplicación.

• La contextualización más básica se produce en el ámbito de un único «tipo» o «flujo» de datos (como un flujo de eventos de «información de inicio de sesión del usuario con la hora y la dirección IP de origen»), normalmente con un contexto histórico y/o datos de varios usuarios. Este análisis puede dar lugar a algunas ideas básicas, como «este usuario <X> nunca se ha conectado durante esta hora del día» o «este usuario <X> parece que siempre se conecta inmediatamente después de otro usuario <Y>». Lo primero puede reducir la confianza en la identidad; lo segundo puede ser indicativo de algún patrón de nivel superior, quizás malicioso.
• Una contextualización más avanzada considera el alcance temporal y multiinstancia no solo para un único «tipo» de datos, sino que también realiza una correlación temporal entre diferentes «tipos» o «flujos» de datos. Un ejemplo sería correlacionar los datos de inicio de sesión del usuario con acciones específicas en la capa de aplicación (como la transferencia de dinero o la actualización de los contactos por correo electrónico) o en la capa de red (como una búsqueda de geolocalización basada en la IP).

Un segundo aspecto especialmente relevante del análisis en el marco de la confianza cero es el tratamiento del volumen y la tasa de datos ingeridos, que superarán la capacidad de cualquier ser humano. Por lo tanto, se requiere algún tipo de asistencia automática para formar ideas digeribles por el ser humano. Una vez más, la sofisticación de la asistencia puede describirse como una progresión.

• Sólo visualización: El primer paso es la presentación simple de estadísticas y eventos, normalmente a través de paneles disponibles en un portal de gestión. Los datos presentados se basan en flujos de datos recopilados (generalmente una serie temporal o una sección transversal longitudinal de usuarios/transacciones dentro de una ventana de tiempo fija). Los paneles más avanzados ofrecen la posibilidad de ordenar y agrupar los datos, así como de realizar desgloses mediante filtrado. En este modelo, el ser humano realiza toda la exploración de datos, la priorización de eventos, el análisis y la remediación, mientras que la automatización ayuda principalmente con la exploración de datos.
• Visualización más reglas estáticas configurables: La siguiente extensión más común de la visualización es la capacidad de permitir que el ser humano defina reglas estáticamente especificadas, ya sea para alertar o remediar. Algunos ejemplos de tales reglas serían “notificar al humano < John > si < la carga de la CPU excede el 80 % durante un período de 5 minutos >” o “requerir < MFA por correo electrónico > si se invoca < API [Y] y el país no es [Estados Unidos] >”. Estas reglas pueden limitarse a las predefinidas especificadas por el proveedor de la solución, o los subsistemas basados en reglas más avanzados también pueden permitir reglas personalizadas escritas por un ingeniero de SecOps. En cualquier caso, las reglas aplicadas normalmente se controlan (y se definen, si es necesario) mediante la configuración. 
• Visualización más asistencia de ML: El siguiente nivel utiliza técnicas más avanzadas que encuentran anomalías de comportamiento y/o transacciones que coinciden con los patrones de transacciones maliciosas previamente identificadas. Si bien se utilizan muchas técnicas (y una discusión profunda de las compensaciones técnicas y comerciales está fuera del alcance de este documento), hay algunos puntos clave a considerar: 

• Esfuerzo humano requerido: Algunas técnicas de ML requieren “entrenamiento” (también conocido como aprendizaje supervisado), lo que significa que un corpus de datos de tamaño razonable debe categorizarse previamente utilizando un “clasificador” confiable. A menudo, para tener una categorización confiable, el “clasificador” termina siendo un humano o un conjunto de humanos. En esos casos, se debe tener en cuenta el esfuerzo humano requerido. Otras técnicas (también conocidas como aprendizaje no supervisado) detectan anomalías y/o reconocen patrones por sí solas, sin esfuerzo humano. 
• Explicabilidad: Los resultados de un sistema de aprendizaje automático resultan de la evaluación de los datos de entrada frente a un modelo. Este modelo puede basarse en una serie de preguntas sencillas y fáciles de responder, como: "¿Se ha visto a este usuario en este dispositivo durante el último mes?" También podría basarse en una similitud fácilmente explicable, como “este usuario cae dentro del patrón general que he visto de usuarios que nunca inician sesión durante el horario laboral”. En otros casos, el modelo puede basarse en la aplicación de un conjunto complejo de operaciones de álgebra vectorial sobre los datos de entrada, sin una lógica de alto nivel fácilmente discernible. Este último caso es claramente menos explicable (más bien una “caja negra”) que los dos ejemplos anteriores. En algunos casos, la explicabilidad es un factor importante para la comprensión humana o la auditabilidad. En esos casos, será mucho más preferible un modelo explicable que uno inescrutable. 
• Disponibilidad de la puntuación de confianza: Como se mencionó anteriormente, una métrica que indique qué tan seguro es el modelo para tomar una decisión (en otras palabras, una idea de la probabilidad relativa de un falso positivo o un falso negativo) suele ser muy útil. Algunos algoritmos son tales que naturalmente se obtiene como resultado una métrica de confianza; para otros, como los basados en reglas, se necesitaría especificar explícitamente un nivel de confianza como uno de los resultados. En cualquier caso, los algoritmos que pueden proporcionar una puntuación de confianza son más sólidos que aquellos que no pueden. 

Al igual que con el enfoque basado en reglas, la asistencia de aprendizaje automático puede ser únicamente para la detección o puede estar vinculada a la corrección automática. Además, la asistencia de aprendizaje automático puede utilizarse junto con un sistema basado en reglas, en el que el «veredicto» del aprendizaje automático (u opinión, confianza) puede utilizarse como entrada en una regla, como «hacer una acción <X> si <el evaluador de aprendizaje automático [bot_detector_A] informa del bot con una confianza superior al 90 %>».

El principio final de la mentalidad de cero óxido es “asumir el incumplimiento”. Para ser claros y brindar perspectiva, los métodos de autenticación y control de acceso implementados correctamente son efectivos para prevenir la gran mayoría de transacciones maliciosas. Sin embargo, uno debería, por un exceso de paranoia, suponer que los mecanismos de aplicación de la autenticación y el control de acceso serán derrotados por algún adversario suficientemente motivado o afortunado. La detección de infracciones, necesaria para responder a estas fugas de manera oportuna, requiere visibilidad y análisis asistido por máquinas. Por lo tanto, es debido a que en ocasiones otros mecanismos de cumplimiento serán derrotados que las tecnologías de análisis contextual asistido por ML que alimentan la visibilidad son una necesidad crítica para alimentar la solución de respaldo de seguridad de confianza cero de la remediación basada en riesgos. 

En los casos de “falsos negativos” en los que una transacción maliciosa real logró vencer la autenticación y el control de acceso, se debe utilizar como respaldo el mecanismo de remediación automatizada basada en riesgos. Pero debido a que esta tecnología se aplica como respaldo contra transacciones que pasaron los controles de cumplimiento anteriores, existe una mayor preocupación por marcar incorrectamente lo que, en verdad, era un "verdadero negativo" (una transacción válida y deseable) como un "falso positivo" (marcado incorrectamente como una transacción maliciosa). Para mitigar este problema, cualquier acción de remediación desencadenada por la creencia en una posible malicia, que de alguna manera no fue detectada por la autenticación o el control de acceso, debe basarse en los siguientes tres factores:⁴

• Valor comercial de la transacción: Diferentes transacciones tendrán diferentes niveles de riesgo y recompensa. Por ejemplo, una transacción que consulta una cuenta bancaria es menos riesgosa que una transacción que transfiere dinero a una cuenta extranjera. De manera similar, para una aerolínea, comprar un boleto es probablemente una transacción con mayor recompensa comercial que una transacción que enumera los retrasos actuales de los vuelos. El valor comercial es el beneficio de la recompensa comercial potencial sopesada frente al perfil de riesgo de la transacción. Es más aceptable tolerar cualquier efecto “falso positivo” de la remediación especulativa en transacciones de baja recompensa y alto riesgo, en comparación con las transacciones de alta recompensa y bajo riesgo que tienen un alto valor comercial. 
• Confianza en la creencia de “malicia”: Por supuesto, no todas las sugerencias de solución especulativa son iguales. En concreto, además de la relación riesgo-recompensa mencionada anteriormente, el otro factor clave es la confianza en las creencias en torno a esa transacción, como por ejemplo la confianza en la identidad certificada del actor. En términos generales, la probabilidad de un “falso negativo” —es decir, la probabilidad de que los mecanismos de cumplimiento no se hayan activado, pero deberían haberlo hecho— es inversamente proporcional a la confianza en el actor. Y dado que la reducción de “falsos negativos” es el objetivo de la remediación basada en el riesgo, cuanto menor sea la confianza, más sesgado debería ser el sistema hacia la aplicación de la remediación.
• Impacto de la remediación: Por último, no todas las remediaciones son decisiones binarias: permitir o bloquear. De hecho, es posible aplicar una variedad de técnicas de reducción de riesgos, desde algunas que son visibles para el usuario (por ejemplo, solicitar credenciales adicionales/MFA, proporcionar un desafío como un captcha) hasta otras que son mayormente invisibles para el usuario (realizar una inspección de tráfico más profunda como DLP o realizar un análisis más avanzado/que requiere un uso intensivo de recursos informáticos). Por lo tanto, el impacto de realizar estas formas adicionales de reducción de riesgos (medido por la fricción experimentada por el usuario y los costos operativos de la aplicação , como DLP o análisis con gran consumo de recursos computacionales) es el tercer factor a considerar. Se prefieren las remediaciones de bajo impacto y transparentes para el cliente a los desafíos de mayor impacto y visibles para el cliente, y el bloqueo directo de la transacción es la opción menos atractiva. Sin embargo, el bloqueo puede ser apropiado cuando la confianza es alta o para transacciones riesgosas que no pueden aumentar suficientemente la confianza a través de otros mecanismos de reducción de riesgos. 

La seguridad de confianza cero es una versión más moderna de los enfoques anteriores a la seguridad, como la defensa en profundidad, que extiende la técnica anterior al adoptar una visión de seguridad centrada en las transacciones: quién intenta hacer qué a quién . Este enfoque permite proteger no solo el acceso externo a una aplicação , sino que también es aplicable para proteger el interior de la aplicação .⁵ Dada esta visión transaccional fundamental, la seguridad de confianza cero se basa en un conjunto de principios básicos que se utilizan para defender las aplicações dentro del entorno actual, más complejo y desafiante, y que luego se asignan a un conjunto de soluciones o métodos a nivel de subsistema que encarnan esos principios. A continuación se resumen los principios básicos y cómo se aplican a los métodos de solución. 

Estas herramientas —métodos de autenticación, control de acceso, visibilidad, análisis contextual y corrección de riesgos— son necesarias y suficientes para prevenir una amplia variedad de tipos de ataques.

Descargar el informe