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

Partiendo del «por qué», los principios rectores¹ de zero trust, la siguiente preocupación es el «cómo», las técnicas y las tecnologías utilizadas para aplicar esos principios.

Desde una perspectiva más amplia, los principios de zero trust pueden aplicarse en todo el ciclo de vida del desarrollo de aplicaciones, incluyendo el diseño del sistema, las plataformas hardware utilizadas y los procedimientos de adquisición.² Sin embargo, este documento analiza los aspectos operativos de la aplicación de zero trust para proteger las aplicaciones y los 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. Aplicar restricciones transaccionales: Quién puede hacer 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 directamente motivadas por los principios de «verificación explícita» y «mínimo privilegio», ya que son la base para aplicar el «Quién puede hacer Qué». Las implementaciones más sofisticadas de la autenticación observan el comportamiento continuo de un actor, capturando la mentalidad de «evaluar continuamente».

Las tecnologías de autenticación consisten en 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 declaración se suele denominar «usuario»: un humano o agente que actúa en nombre de un humano y que quiere realizar una transacción. Sin embargo, en el caso de la zero trust utilizada dentro de una aplicación, 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 del Quién incluye no solo al humano o la carga de trabajo, sino otras consideraciones o dimensiones de identidad. Desde esta perspectiva, las dimensiones adicionales de la identidad podrían incluir el dispositivo o la plataforma del usuario/carga de trabajo, o el ecosistema que se utiliza para la interacción, o la ubicación del agente. Por ejemplo, el usuario «Alice» puede estar en un PC etiquetado como «ABC- 0001» utilizando una instancia específica de navegador con huella digital, procedente 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 varios métodos. Esto se pone de manifiesto en el modelo de Google BeyondCorp³, que exige una autenticación multifactorial (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 de confianza mínimo para cada tipo de transacción basado en el valor y el riesgo de la misma.

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 autentificación para determinar Quién actúa en una transacción, las siguientes preguntas son: ¿Qué puede hacer ese actor? ¿Y para Quién? Este es el ámbito 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 y , y solo pueden llevar cámaras al »).

Aplicadas en el contexto de la ciberseguridad, las técnicas de control de acceso deberían incorporar el principio de confianza cero de «mínimo privilegio». En otras palabras, una política óptima de control de acceso solo permitiría exactamente los privilegios que el actor requiere y desautorizaría 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 el umbral de confianza especificado en la especificación 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 el nivel de detalle de la acción: el Qué de la transacción?:

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 pueden hacer lo que quieran» y «los civiles no pueden entrar en ningún edificio».
2. Amplio: Específico en el punto de conexión de la API o del «tipo» de transacción (como E/S de archivos, comunicación de red y controles de procesos). En nuestro ejemplo, esto permitiría una matización sobre la acción permitida, como «los políticos pueden entrar en los edificios, pero no hacer fotos».
3. Estrecho: En la API secundaria (es decir, en función de los parámetros o la versión de la API) o en el «subtipo» de transacción (como la E/S de archivos de solo lectura o la recepción TCP). Utilizando nuestra analogía una vez más, esto permitiría controles más precisos, como «los civiles solo pueden entrar en los edificios si van acompañados de un soldado».

2. ¿Existe un nivel de detalle en cuanto al objetivo de la acción, el Quién de la transacción?:

1. Sin especificación de objetivo: La política de control de acceso no tiene en cuenta el objetivo de la acción. En nuestro ejemplo, este enfoque se correspondería con la especificación de permitir la entrada a algunos edificios, pero no a otros: los edificios son el objetivo de la acción («entrar»).
2. Específico del objetivo, nivel de infraestructura: La política de control de acceso puede incluir el objetivo de la acción, pero utiliza alguna etiqueta específica 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 a nivel de edificio, pero cada base militar podría tener una convención de nomenclatura diferente para los edificios.
3. Específico del objetivo, consciente de la identidad: La política de control de acceso puede incluir el objetivo de la acción, identificando el objetivo utilizando el mismo espacio de nombres de identidad (por ejemplo, SPIFFE) utilizado para el actor (el Quién). La ventaja con respecto al enfoque anterior es que todas las bases militares utilizarían un esquema coherente para la identificación de los edificios, lo que hace que la política sea 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 es consciente del riesgo: La solución de control de acceso trata todos los privilegios de control de acceso de la misma forma en cuanto a la decisión de permitir o no la acción.
2. Gestión del riesgo a través de MFA: La solución de control de acceso gestiona el riesgo permitiendo que la política especifique si algunas de las transacciones permitidas deben utilizar la autenticación multifactorial en función del actor (Quién), la acción (Qué) o el objetivo (Para quién) involucrados en la transacción.
3. Gestión del riesgo a través de la confianza: La solución de control de acceso gestiona el riesgo permitiendo que la política especifique si alguna transacción puede seguir pidiendo un nivel mínimo de confianza en la autenticidad del actor en función de la acción (Qué) y el objetivo (Quién) de la transacción. La MFA puede aumentar la confianza, aunque se pueden utilizar otros medios. En otros casos, puede que la transacción no se permita en absoluto si es de alto valor y la autenticidad del actor es lo 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: ¿Cómo de actuales son 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. Capacidad de consumo: ¿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. Integridad: ¿Cuál es la amplitud y la 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. Gobernanza: ¿En qué medida se apoyan los requisitos de uso de los datos, tanto los legales como los basados en licencias?

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 nunca se ha conectado durante esta hora del día» o «este usuario parece que siempre se conecta inmediatamente después de otro usuario ». 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.

• Solo visualización: El primer paso es la presentación desnuda 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 recogidos (normalmente una serie de tiempo o una sección longitudinal a través de usuarios/transacciones dentro de una ventana de tiempo fija). Los paneles más avanzados ofrecen la posibilidad de clasificar y agrupar los datos, así como de desglosarlos mediante filtros. En este modelo, el ser humano realiza toda la exploración de datos, la priorización de eventos, el análisis y la corrección, mientras que la automatización ayuda principalmente en 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 al humano definir reglas especificadas estáticamente, ya sea para alertar o remediar. Ejemplos de estas reglas serían «notificar al humano <John> si la <carga de la CPU supera el 80 % durante un periodo de 5 minutos>» o «requerir la <MFA por correo electrónico> si <se invoca la API [Y] y el país no es [Estados Unidos]>». Estas reglas pueden limitarse a las predefinidas y especificadas por el proveedor de la solución, o los subsistemas más avanzados basados en reglas pueden también permitir reglas personalizadas escritas por un ingeniero de SecOps. En cualquier caso, las reglas aplicadas suelen controlarse (y definirse, si es necesario) mediante la configuración.
• Visualización más asistencia de aprendizaje automático: 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. Aunque son muchas las técnicas utilizadas (y el debate sobre las compensaciones técnicas y empresariales queda fuera del alcance de este documento) hay algunos puntos clave a tener en cuenta:

• Se requiere esfuerzo humano: Algunas técnicas de aprendizaje automático requieren «entrenamiento» (también conocido como aprendizaje supervisado), lo que significa que un corpus de datos de tamaño razonable debe ser precategorizado utilizando un «clasificador» fiable. A menudo, para tener una categorización fiable, el «clasificador» acaba siendo un humano o un grupo de humanos. En esos casos, hay que tener en cuenta el esfuerzo humano necesario. Otras técnicas (también conocidas como aprendizaje no supervisado) detectan anomalías y/o reconocen patrones por sí mismas, sin esfuerzo humano.
• Explicabilidad: Las salidas de un sistema de aprendizaje automático resulta de la evaluación de los datos de entrada con respecto 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 en el último mes?». También podría basarse en una similitud fácil de explicar, como «este usuario entra en el patrón general de usuarios que nunca se conectan durante las horas de trabajo». En otros casos, el modelo puede basarse en la aplicación de un complejo conjunto 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 anteriores. En algunos casos, la explicabilidad es un factor importante para la comprensión humana o la auditabilidad. En esos casos, se preferirá un modelo explicable a uno inescrutable.
• Disponibilidad de la puntuación de confianza: Como se ha mencionado anteriormente, una métrica que indique el grado de confianza del modelo en 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 la salida de una métrica de confianza se produce de forma natural; para otros, como los basados en reglas, sería necesario especificar explícitamente un nivel de confianza como una de las salidas. En cualquier caso, los algoritmos que pueden proporcionar una puntuación de confianza son más robustos que los que no pueden hacerlo.

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 si ».

El último principio de la mentalidad de «confianza cero» es «asumir la infracción». Para ser claros y ofrecer perspectiva, los métodos de autenticación y control de acceso correctamente aplicados son eficaces para evitar la inmensa mayoría de las transacciones maliciosas. Sin embargo, uno debe, por abundancia de paranoia, asumir 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 las infracciones, necesaria para responder a estas fugas a tiempo, requiere visibilidad y análisis asistido por máquinas. Por lo tanto, debido a que los otros mecanismos de aplicación serán derrotados en ocasiones, las tecnologías de visibilidad que alimentan el análisis contextual asistido por aprendizaje automático son una necesidad crítica para alimentar la solución de seguridad de confianza cero de la remediación basada en el riesgo.

Para los casos de «falsos negativos» en los que una transacción maliciosa real haya burlado la autenticación y el control de acceso, debería utilizarse como respaldo el mecanismo de corrección automatizada basada en el riesgo. Pero dado que esta tecnología se aplica como un respaldo a las transacciones que han superado las comprobaciones de cumplimiento previas, existe una mayor preocupación por marcar incorrectamente lo que era, en realidad, un «verdadero negativo» (una transacción válida y deseable) como un «falso positivo» (marcado incorrectamente como transacción maliciosa). Para mitigar esta preocupación, cualquier acción de remediación desencadenada por la creencia de una posible malicia, que de alguna manera no sea detectada por la autenticación o el control de acceso, debe basarse en los siguientes tres factores⁴:

• Valor comercial de la transacción: Las diferentes transacciones tendrán diferentes niveles de riesgo y recompensa. Por ejemplo, una transacción que visualiza una cuenta bancaria es menos arriesgada que una que transfiere dinero a una cuenta extranjera. Del mismo modo, para una compañía aérea, la compra de un billete es probablemente una transacción de mayor recompensa comercial, en relación con una transacción que enumera los retrasos actuales de los vuelos. El valor comercial es el beneficio de la posible recompensa comercial sopesado con el perfil de riesgo de la transacción. Es más aceptable tolerar los efectos de «falso positivo» de la reparación especulativa de las transacciones de baja recompensa/alto riesgo, en comparación con las transacciones de alta recompensa/bajo riesgo que tienen un alto valor comercial.
• Confianza en la creencia de «malicia:» Por supuesto, no todas las propuestas de reparación especulativa son iguales. En concreto, además del riesgo-recompensa mencionado anteriormente, el otro factor clave es la confianza en las creencias en torno a esa operación, como la confianza en la identidad declarada del actor. A grandes rasgos, la probabilidad de un «falso negativo», es decir, la probabilidad de que los mecanismos de aplicación no se hayan activado, aunque deberían haberlo hecho, es inversamente proporcional a la confianza en el actor. Y dado que la reducción de los «falsos negativos» es el objetivo de la corrección basada en el riesgo, cuanto menor sea la confianza, más inclinado estará el sistema a aplicar la corrección.
• Impacto de la corrección: Por último, no todas las correcciones son decisiones binarias: permitir o bloquear. De hecho, es posible aplicar diversas técnicas de reducción de riesgos, que van desde algunas visibles para el usuario (por ejemplo, solicitar credenciales adicionales/MFA, proporcionar un desafío como un captcha, etc.), hasta otras que son casi invisibles para el usuario (realizar una inspección de tráfico más profunda, como DLP, o hacer un análisis más avanzado/intensivo en términos de computación). Por lo tanto, el impacto de estas técnicas de reducción de riesgos —medido por la fricción experimentada por el usuario y los costes operativos de la aplicación (como en el caso de la DLP o el análisis de computación intensiva)— es el tercer factor a tener en cuenta. Se prefieren las soluciones de bajo impacto y transparentes para el cliente frente a los desafíos de mayor impacto y visibles para el cliente. El bloqueo total de la transacción es la opción menos atractiva. Sin embargo, puede ser apropiado cuando la confianza es alta, o para las transacciones arriesgadas que no pueden aumentar suficientemente la confianza a través de los otros mecanismos de reducción de riesgos.

La seguridad de confianza cero es una versión más moderna de los enfoques de seguridad anteriores, como la defensa en profundidad, que amplía el arte anterior adoptando una visión de la seguridad centrada en las transacciones: Quién intenta hacer Qué para Quién. Este enfoque permite proteger no solo el acceso externo a una aplicación, sino que también es aplicable a la protección de las partes internas de la aplicación.5 Teniendo en cuenta este punto de vista transaccional fundamental, la seguridad de confianza cero está arraigada en un conjunto de principios básicos que se utilizan para defender las aplicaciones en el entorno más complejo y desafiante de hoy en día, con los principios asignados a un conjunto de soluciones a nivel de subsistema, o métodos, que incorporan esos principios. A continuación se resumen los principios básicos y su correspondencia con 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