Roey Eliyahu, cofundador y CEO de Salt Security, y Ed Amoroso, fundador y CEO de TAG Cyber, se reunieron recientemente en un seminario web conjunto sobre seguridad de API y confianza cero. Cuando expertos de la industria debaten sobre dos de los temas más candentes de la ciberseguridad, el resultado siempre es informativo, y esta vez no fue la excepción.
¿Qué nos llevó a la confianza cero?
En los años 90 y principios de los 2000, las organizaciones dependían de protecciones perimetrales, aprovechando la autenticación para facilitar el acceso sin restricciones a los usuarios dentro del perímetro. Con el auge de los entornos híbridos y el crecimiento de la nube, este tipo de protecciones quedaron obsoletas, lo que dio lugar a la arquitectura de "confianza cero".
Ed define la "confianza cero" como una condición que ocurre cuando el perímetro desaparece, lo cual abarca casi todo dentro de las arquitecturas híbridas actuales. Dado que ahora se puede acceder a los recursos desde casi cualquier punto, no es posible trazar un perímetro. La confianza cero aboga por construir entornos "de confianza" para alojar aplicaciones, sistemas y datos que operen con el principio de menor privilegio.
La gran mayoría de las organizaciones buscan adoptar alguna forma de confianza cero, un hecho que validamos fácilmente durante una breve encuesta en el seminario web con la siguiente pregunta:
¿Es la confianza cero una consideración en su arquitectura de seguridad actual?
- 57% – la confianza cero es una consideración importante
- 7% – la confianza cero es una consideración menor
- 35% – la confianza cero aún no es una consideración, pero estamos avanzando hacia ella
Dicho de otro modo, ¡solo el 1% respondió que no tenía absolutamente ninguna consideración de confianza cero en su arquitectura! Dada la enorme influencia que tiene la confianza cero en los planes de seguridad, las organizaciones también deben comprender sus debilidades en lo que respecta a la seguridad de las API.
El dilema de la confianza cero y la seguridad de las API
Muchos riesgos de las API no pueden mitigarse con la confianza cero. Debido a que las API requieren acceso para funcionar, los métodos de confianza cero fallan en la seguridad de las API. A continuación, tres ejemplos, discutidos por Roey y Ed, que ilustran cómo las metodologías de confianza cero se quedan cortas a la hora de proteger las API:
- Las API habilitan las aplicaciones empresariales
- Las API desconocidas no pueden protegerse con confianza cero
- Muchos ataques a API provienen de usuarios autenticados
Las API habilitan las aplicaciones empresariales
Con el aumento de las iniciativas de transformación digital, el uso de API se ha disparado. Las API han sido diseñadas específicamente para compartir datos y servicios entre aplicaciones. La mayoría de los datos que entran y salen de nuestras organizaciones se transmiten a través de API. De hecho, como mencionó Roey en el seminario web, ¡el 83% del tráfico de Internet es tráfico de API!
Debido a que las API habilitan todas sus aplicaciones, son fundamentales para ofrecer valor comercial. Las API utilizadas en aplicaciones de comercio electrónico le permiten comprar los productos a la venta. Las API de tecnología financiera le permiten transferir fondos desde su cuenta bancaria según lo desee. Para gestionar un negocio digital, las organizaciones no pueden bloquear estas API, o de lo contrario no tendrían negocio que gestionar.
Las API desconocidas no pueden protegerse con confianza cero
Debido a que las API se desarrollan, implementan y modifican con tanta rapidez, resulta imposible realizar un seguimiento manual de todas ellas.
En nuestro informe sobre el estado de la seguridad de las API del tercer trimestre, descubrimos que las API «en la sombra» o desconocidas, así como las API «zombis» u obsoletas, representan una gran preocupación para las organizaciones. El 42 % de las empresas afirma que su mayor inquietud en cuanto a la seguridad de las API son las versiones obsoletas. De hecho, las API obsoletas han sido señaladas como la principal preocupación de seguridad en las últimas cuatro encuestas realizadas por Salt Security.
Estas API desconocidas y sin protección podrían estar expuestas sin que las organizaciones siquiera lo sepan. Independientemente de la práctica de seguridad que adopte, si no sabe que un activo existe, no puede protegerlo.
Muchos ataques a las API provienen de usuarios autenticados
Muchos incidentes de seguridad en las API ocurren utilizando la API tal como fue diseñada. Por ejemplo, los atacantes pueden emplear técnicas de ingeniería social para obtener las claves o credenciales de un usuario autorizado y así facilitar la explotación. En este caso, no importa que cada usuario haya sido autenticado mediante un modelo de confianza cero (zero trust).
Los recientes incidentes de la clave de API de Twitter y Peloton ofrecen ejemplos de abuso de una API diseñada para la exfiltración de datos y el acceso no autorizado. El uso legítimo de una API puede permitir que los atacantes obtengan acceso a datos restringidos, tal como se explica en el OWASP API3: Exposición excesiva de datos.
En conclusión: algunos riesgos de las API no pueden mitigarse con un modelo de confianza cero
Según Roey y Ed, puede haber mucha confusión entre la seguridad de las API y la confianza cero. La realidad es que, incluso con una buena estrategia de confianza cero, algunos riesgos de seguridad de las API no pueden mitigarse mediante este enfoque. Puede escuchar el seminario web completo de Roey y Ed aquí.
Para saber cómo la plataforma de protección de API de Salt Security puede ayudar a proteger sus servicios y datos críticos, regístrese para obtener una demostración personalizada.