Según Raidiam, la mayoría de las organizaciones exponen datos confidenciales a través de API sin controles de seguridad establecidos y es posible que ni siquiera se den cuenta.
Su informe se basa en una evaluación detallada de 68 organizaciones de diversos sectores. Excluye deliberadamente entornos regulados como la Banca Abierta del Reino Unido, donde se exige una seguridad avanzada. El objetivo era comprender cómo las empresas típicas, aquellas sin presión regulatoria, protegen sus API. Los resultados no son alentadores.
Más del 80 % de las organizaciones se clasificaron en la categoría «Actuar con Urgencia», según el informe. Se trata de empresas que gestionan datos personales o de pago de alto valor a través de API, pero utilizan controles deficientes, como claves API estáticas , tokens de portador de larga duración o OAuth básico con secretos compartidos. Solo una organización de la muestra había implementado lo que los investigadores consideran una solución de seguridad moderna para API, basada en la autenticación de certificados de cliente, tokens restringidos por el remitente y TLS mutuo (mTLS).
Esta brecha entre la confidencialidad de los datos y la seguridad es el problema central que los investigadores quieren exponer. «La mayoría de las organizaciones están retrasadas en el fortalecimiento de la seguridad de las API, a pesar de que su dependencia de ellas ha aumentado», advierte el informe.
Una base frágil
El uso generalizado de API para dar soporte a aplicaciones móviles, servicios en la nube e integraciones con socios implica que la superficie de ataque ha cambiado. Sin embargo, las prácticas de seguridad a menudo no lo han hecho. Hoy en día, las API gestionan todo, desde solicitudes de identidad y datos de titulares de tarjetas hasta información de salud y cuentas. Sin embargo, en muchas organizaciones, quedan fuera del alcance de los programas de seguridad estándar.
El informe señala que solo el 27 % de las organizaciones tienen visibilidad de los datos confidenciales expuestos a través de sus API. Menos de la mitad realiza pruebas de seguridad específicas para cada API, como fuzzing o análisis dinámico. Además, la monitorización es insuficiente, lo que significa que los atacantes pueden investigar o usar indebidamente las API durante semanas sin ser detectados.
¿Qué aspecto tiene mejor?
Raidiam establece un camino hacia una mayor seguridad de las API , y gran parte de ello se basa en la adopción de prácticas ya probadas en entornos regulados. Las API de grado financiero, por ejemplo, se basan en TLS mutuo para autenticar tanto al cliente como al servidor, lo que dificulta considerablemente que los atacantes suplanten aplicaciones legítimas. También utilizan tokens vinculados a certificados, lo que impide que el robo de tokens se convierta en un método de acceso válido.
Estas no son mejoras teóricas. Los regímenes de banca abierta en el Reino Unido, Europa y Australia exigen estos controles, y todos los bancos del Reino Unido los han implementado. Sin embargo, en sectores sin presión regulatoria, la adopción sigue siendo baja.
Esto crea un entorno de dos velocidades: un grupo de organizaciones trata las API como una infraestructura empresarial central con gobernanza de seguridad, mientras que el otro grupo las trata simplemente como otra herramienta para desarrolladores.
“Si bien la mayoría de las organizaciones encuestadas en el informe están rezagadas en seguridad de API, aquellas que han avanzado, como los bancos obligados por la regulación o las redes globales de tarjetas que han actuado voluntariamente, eclipsan a las rezagadas en escala y madurez”, declaró David Oppenheim , director de Estrategia Empresarial de Raidiam, a Help Net Security. “Esto crea un marcado contraste en la postura de riesgo”.
Oppenheim añadió que una supervisión significativa a nivel de junta directiva no requiere dominio técnico. «En un ámbito tan técnicamente complejo, puede ser difícil obtener métricas relevantes a nivel de junta directiva, pero aún existen maneras eficaces de orientar la supervisión y la inversión. Los directores deberían preguntar qué estándares reconocidos (por ejemplo, FAPI) se han adoptado o se encuentran en la hoja de ruta, y si la organización ha aplicado un modelo o marco de madurez para comparar su postura actual y hacer un seguimiento de las mejoras a lo largo del tiempo».
También mencionó un punto de partida sencillo: «Un KPI simple pero eficaz podría ser el porcentaje de integraciones de API que aún dependen de claves estáticas o secretos compartidos, junto con un cronograma para migrar hacia protecciones criptográficas. El seguimiento de la reducción a lo largo del tiempo proporciona una visibilidad no técnica de las mejoras de seguridad».
Puede que se avecine un cambio estructural
Hasta ahora, las mayores mejoras en la seguridad de las API se han logrado mediante regulación directa o mandatos de la industria. Sin embargo, la presión está aumentando en otros ámbitos.
“Una vez más, el tamaño de la organización juega un papel clave”, afirmó Oppenheim. “Las grandes empresas y los proveedores de infraestructura ya están avanzando voluntariamente, no solo en banca, sino también en plataformas de pagos e identidad, porque consideran que una sólida seguridad de API es fundamental para la escalabilidad y la confianza”.
Agregó que están surgiendo factores favorables para el cumplimiento normativo: «Los cambios en los requisitos básicos de TLS afectarán a todas las organizaciones con presencia digital, mientras que regulaciones como DORA están generando nuevas expectativas en torno al riesgo de terceros, especialmente relevante para las API expuestas a socios externos».
Oppenheim también prevé tendencias arquitectónicas más amplias que impulsen el progreso. «El Marco de Confianza Cero del NIST está empezando a servir de modelo para muchas organizaciones que buscan reducir la confianza implícita en sus entornos digitales. En ese contexto, una identidad de cliente sólida mediante PKI o TLS mutuo forma parte de una estrategia más amplia hacia arquitecturas defendibles y verificables».
Fuente y redacción: helpnetsecurity.com
