Por: Jaye Tillson / HPE
Los atacantes no siempre necesitan vulnerar los controles de seguridad. Aprovechando la confianza ya existente en nuestros entornos, pueden convertir el acceso legítimo en una oportunidad.
En el primer artículo de esta serie, argumenté que el perímetro de seguridad no ha desaparecido, sino que se ha multiplicado, ya que cada interacción entre un usuario, un dispositivo, una carga de trabajo, una aplicación, una API y, cada vez más, un agente de IA, crea un nuevo punto donde debemos tomar una decisión de seguridad. Concluí planteando la que considero una de las preguntas más importantes en ciberseguridad hoy en día: ¿en qué estamos realmente dispuestos a confiar y por qué?
Cuanto más reflexiono sobre esta cuestión, más me convenzo de que debemos replantearnos la forma en que nuestra industria habla de vulnerabilidades, porque cuando oímos la palabra vulnerabilidad, pensamos inmediatamente en fallos de software, sistemas sin parchear, CVE y errores de configuración. Dedicamos muchísimo tiempo a encontrarlas, priorizarlas, parchearlas y medir la rapidez con la que podemos eliminarlas, y todo ese trabajo sigue siendo de vital importancia.
Pero existe otra vulnerabilidad latente en casi todas las organizaciones que no aparece en los escáneres de vulnerabilidades y que no tiene un número CVE asociado.
Confianza.
Más concretamente, se trata de la confianza implícita que hemos construido deliberadamente en nuestros entornos a lo largo de décadas.
Diseñamos nuestros entornos para confiar.
Durante mucho tiempo, la confianza fue increíblemente útil porque facilitaba la operación de nuestros entornos. Si un usuario se había autenticado correctamente y estaba conectado a la red corporativa, podíamos asumir razonablemente que su presencia allí era legítima. Si un dispositivo había sido emitido por el departamento de TI, confiábamos más en él que en un dispositivo desconocido. Si dos sistemas se encontraban en el mismo centro de datos, les permitíamos comunicarse porque ambos formaban parte de nuestro entorno.
Ninguna de esas decisiones fue intrínsecamente errónea, y en muchos casos resultaron totalmente apropiadas para la tecnología y las prácticas laborales de aquel entonces. El problema radica en que esas decisiones individuales, acumuladas a lo largo de muchos años, han creado complejas relaciones de confianza que ahora resultan increíblemente difíciles de comprender para las organizaciones, y mucho menos de validar de forma continua.
Tras haber gestionado infraestructuras empresariales durante muchos años, sé lo fácil que es que esto ocurra, ya que las redes y las arquitecturas de seguridad rara vez se presentan completamente desarrolladas. Evolucionan. Se implementa una nueva aplicación, se adquiere otra empresa, se crea una regla de firewall temporal para solucionar un problema urgente, un tercero necesita acceso a algo, se añade otra VLAN, una aplicación se traslada a la nube y, de repente, una relación de confianza que tenía todo el sentido del mundo hace diez años sigue vigente hoy en día, aunque nadie recuerde con exactitud por qué existe.
El resultado es que muchas organizaciones han creado entornos con mucha más confianza de la que se dan cuenta.
Los atacantes lo saben y son muy buenos aprovechándose de ello.
Los atacantes no siempre rompen la confianza. A veces la heredan.
Cuando pensamos en un atacante que ingresa a una organización, es tentador imaginar que vulnera continuamente los controles de seguridad mientras avanza hacia su objetivo, pero a menudo no es así. Una vez que un atacante compromete una identidad, un dispositivo o una carga de trabajo legítimos, puede llegar a aprovecharse de la confianza que la organización ya le ha otorgado.
Esa distinción es increíblemente importante.
Si robo las credenciales válidas de alguien, no necesariamente necesito burlar el sistema de autenticación, ya que puedo autenticarme legítimamente. Si comprometo un punto final de confianza, es posible que no necesite convencer a la red de que mi dispositivo pertenece allí, porque la organización ya lo cree. Si comprometo una carga de trabajo que tiene permiso para comunicarse ampliamente con otras cargas de trabajo, podría usar esas relaciones existentes para avanzar en el entorno.
En otras palabras, el atacante no siempre necesita generar confianza.
A veces, ya lo hemos creado para ellos.
Por eso, los ataques de identidad, el robo de credenciales y el movimiento lateral siguen siendo tan valiosos para los atacantes, ya que la vulneración inicial suele ser solo el comienzo del ataque. La verdadera oportunidad reside en descubrir qué permisos y relaciones tiene ya la identidad o el sistema comprometido, y luego utilizarlos para alcanzar algo más valioso.
La autenticación no es lo mismo que la confianza.
Por eso creo que debemos ser cautelosos al hablar de que la identidad se convierta en el nuevo perímetro de seguridad. La identidad es, sin duda, una de las señales de seguridad más importantes que tenemos, pero por sí sola no resuelve el problema de la confianza, ya que saber quién es alguien no nos indica automáticamente si lo que intenta hacer debería estar permitido.
Un usuario puede autenticarse correctamente y aun así tener un dispositivo comprometido. Es posible que le hayan robado sus credenciales. Su comportamiento puede ser repentinamente muy diferente al habitual. Podría estar intentando acceder a una aplicación que nunca ha usado, desde una ubicación desconocida, o intentando realizar una acción que se sale completamente de sus responsabilidades normales.
El mismo principio se aplica más allá de las personas. Una carga de trabajo puede tener una identidad válida y aun así verse comprometida, un dispositivo IoT puede ser exactamente lo que creemos que es y aun así comportarse de forma maliciosa, y un agente de IA puede ser completamente legítimo al intentar realizar una acción que excede sus capacidades previstas.
La autenticación responde a una pregunta importante: ¿quién o qué eres?
No responde a la siguiente pregunta: ¿debería permitirse hacer esto?
Esa segunda pregunta es donde la confianza cero se vuelve mucho más interesante.
El principio de confianza cero no significa no confiar en nada.
El término «confianza cero» siempre ha generado cierta confusión, ya que da la impresión de que el objetivo es eliminar la confianza por completo, lo cual, evidentemente, no es práctico. Las organizaciones deben permitir que las personas y los sistemas se comuniquen, de lo contrario, nada se lograría; por lo tanto, siempre existirá algún tipo de confianza.
Para mí, el objetivo no es eliminar la confianza, sino dejar de hacerla innecesariamente amplia, permanente o implícita.
En lugar de conceder acceso simplemente porque alguien está en la red correcta, podemos usar la identidad y el contexto para comprender sus necesidades reales. En lugar de permitir que un dispositivo se comunique con todo un segmento de red porque necesita acceso a un servicio, podemos limitar esa comunicación al servicio que realmente requiere. En lugar de asumir que una autenticación exitosa debería proporcionar acceso durante el resto del día, podemos seguir analizando las señales que nos indiquen que la situación ha cambiado.
Aquí es donde conceptos como el de mínimo privilegio, la segmentación, el acceso basado en la identidad y el acceso a la red de confianza cero se vuelven increíblemente importantes, porque nos permiten reducir la cantidad de confianza innecesaria incorporada al entorno, al tiempo que permiten que el negocio siga funcionando.
En HPE, una de las áreas en las que nos hemos centrado es en extender estos principios de forma coherente a entornos remotos, sucursales y campus, en lugar de aplicar el principio de confianza cero únicamente al acceso remoto. Si un mismo usuario recibe un acceso estrictamente controlado y basado en la identidad mientras trabaja desde casa, pero de repente obtiene un amplio acceso a la red cuando se conecta a la LAN corporativa, el problema de la confianza no ha desaparecido; simplemente se ha trasladado.
El objetivo debe ser que el acceso sea adecuado al usuario, al dispositivo y al recurso, independientemente de dónde se origine la conexión.
El principio de “privilegio menor” debe volverse dinámico.
El principio del mínimo privilegio no es una idea nueva en ciberseguridad, pero creo que la forma en que lo implementamos debe evolucionar, ya que tradicionalmente los privilegios han sido relativamente estáticos. Decidimos qué necesita una persona, la asignamos a un grupo o rol y luego revisamos periódicamente si esos permisos siguen siendo apropiados.
El problema radica en que nuestros entornos son cada vez más dinámicos, mientras que nuestros permisos suelen permanecer estáticos.
Las personas cambian de rol, los proyectos finalizan, los contratistas se marchan, los dispositivos se ven comprometidos, las aplicaciones se trasladan y los riesgos cambian constantemente, pero las relaciones de acceso que creamos pueden permanecer vigentes durante meses o incluso años. Cualquiera que haya dedicado tiempo a revisar las reglas del firewall, los grupos de Active Directory o las antiguas listas de control de acceso sabrá con qué rapidez se acumulan estos permisos y lo difícil que puede ser eliminarlos cuando nadie sabe con certeza qué podría fallar.
Esto cobra aún más importancia a medida que introducimos agentes de IA, ya que estamos creando una nueva clase de identidad que puede necesitar acceso a múltiples sistemas y la capacidad de realizar acciones en nuestro nombre, potencialmente miles de veces más rápido que un ser humano.
Otorgar a un agente de IA un acceso amplio y persistente porque podría necesitarlo en algún momento se parece mucho a muchas de las decisiones de confianza que ahora estamos tratando de revertir en otros ámbitos de nuestro entorno.
Deberíamos aprender de esa historia, no repetirla.
El fideicomiso debe tener una fecha de vencimiento.
Quizás este sea, en última instancia, el cambio que debemos realizar en nuestra forma de concebir la confianza.
En lugar de preguntarnos si algo es de confianza, deberíamos preguntarnos si se confía en que haga qué, durante cuánto tiempo y bajo qué condiciones.
Ese pequeño cambio en el lenguaje crea un modelo de seguridad muy diferente, ya que la confianza deja de ser un atributo permanente y se convierte en algo contextual, limitado y que se evalúa continuamente. Se puede confiar en que un usuario acceda a una aplicación pero no a otra; se puede confiar en un dispositivo siempre que su nivel de seguridad sea óptimo; se puede permitir que una carga de trabajo se comunique con una API pero con ninguna otra; y se puede autorizar a un agente de IA a realizar una acción específica, pero solo dentro de límites claramente definidos.
Esto no significa que las organizaciones deban tomar todas las decisiones de seguridad manualmente ni generar tanta fricción que impida el trabajo de los empleados. Todo lo contrario. Cuanto más contexto podamos integrar y más consistentemente se apliquen las políticas en todo el entorno, más imperceptibles serán muchas de esas decisiones para el usuario.
El objetivo no es dificultar el acceso. El objetivo es dificultar la confianza innecesaria.
Y eso nos lleva al siguiente desafío de esta serie, porque una vez que aceptamos que la confianza debe ser contextual, limitada y evaluada continuamente, el control de acceso tradicional comienza a parecer cada vez más inadecuado.
La cuestión ya no es simplemente si alguien puede acceder a algo.
La cuestión es si esta interacción en particular debería permitirse en este momento.
Y eso significa que la seguridad está empezando a evolucionar, pasando del control de acceso a algo mucho más interesante: la toma de decisiones continua.
