Por qué la seguridad de API es asunto de todos

Aug 20, 2023

El planeta está inundado de API, los mecanismos utilizados por las computadoras para intercambiar información, los componentes básicos de todo software. Las empresas crean sus propias API para uso interno o para permitir que los clientes interactúen con sus sistemas. Utilizan API para comunicarse con socios en extranets y a través de nubes. Utilizan API de terceros para acceder a funciones ya preparadas: mostrar Google Maps o utilizar tablas de búsqueda de códigos postales en formularios, por ejemplo.

La cantidad de API está creciendo exponencialmente a medida que proliferan las aplicaciones móviles, web y en la nube. Algunas estadísticas de la industria:

No es sorprendente que las API también sean un vector de ataque importante y de rápido crecimiento. Según Gartner: "El crecimiento explosivo de las API está ampliando la superficie de ataque de las organizaciones, brindando a los actores maliciosos nuevas oportunidades de filtración y filtración de datos".

Dependiendo de su punto de vista, es muy sorprendente o no sorprendente que alrededor del 50% de las API en uso no estén administradas.

Sorprendentes porque suponen un riesgo evidente y creciente. No es de extrañar, porque la explosión en el uso de API se ve agravada por una falta de conciencia de los riesgos y porque las API son difíciles de gestionar. Los desarrolladores publican con frecuencia nuevas API o nuevas versiones sin molestarse en eliminar sus predecesoras. El ciberespacio está plagado de API zombis, que exponen sistemas y datos de back-end pero no están supervisados ​​y no proporcionan ningún valor comercial.

Una superficie de ataque en constante expansión y mal patrullada: este es el sueño de un hacker hecho realidad.

La advertencia de Gartner destaca uno de los riesgos obvios de la seguridad de las API: las API son puntos de cruce para una gran cantidad de tráfico sensible. En aplicaciones bancarias o de comercio electrónico, estos pueden incluir detalles de la cuenta de los clientes o números de tarjetas de crédito. Pero las API exponen no sólo los datos de una empresa (y sus clientes), sino también la lógica empresarial detrás de los servicios. Las debilidades en la lógica empresarial presentan a los piratas informáticos nuevas formas de lanzar ataques que probablemente pasen desapercibidos antes de que se produzcan pérdidas graves.

Por ejemplo, trabajamos para un banco que utilizaba una rutina para redondear sumas muy pequeñas en transacciones de cambio de divisas. El algoritmo era intrascendente para las operaciones típicas, ya que significaba una diferencia de una fracción de centavo. Pero el sistema no aplicaba ningún límite a la cantidad de transacciones que un solo cliente podía realizar en un día, y al eludir los controles frontales y atacar directamente su lógica de negocios, era posible realizar una gran cantidad de pequeñas transacciones que permitirían a un atacante utilizar la función de redondeo para imprimir dinero en nuestra propia cuenta. Hemos obtenido resultados similares con clientes de la industria de la criptografía, donde el abuso de la lógica empresarial de la API también nos permitió robar criptomonedas.

Por supuesto, el banco tenía controles que eventualmente lo habrían alertado sobre el problema, pero reconoció que podría haber realizado operaciones anómalas por valor de varios millones de dólares antes de que surgieran señales de alerta. Este ejemplo ilustra un par de principios importantes de seguridad de API. Las API más útiles son públicas. Están destinados a ser usados. No puede ocultarlos ni dificultar demasiado el acceso a ellos sin impedir que hagan su trabajo.

Técnicas como las pruebas de penetración pueden ayudar, pero incluso las pruebas de penetración son solo ejercicios puntuales y los evaluadores solo evalúan el alcance proporcionado. Las empresas con puntos ciegos de API no saben cómo abarcar las API, y a la mayoría de los evaluadores de penetración no se les pedirá que prueben la lógica empresarial o carecen de habilidades específicas de API para evaluar qué podría hacer un atacante de API competente con su acceso. .

La segunda lección es que no tiene sentido centrarse sólo en una parte del ciclo de vida de la API. Los principios de cambio a la izquierda se centran correctamente en incorporar la seguridad en el punto de diseño y codificación, pero el ciclo de vida de producción del código es igualmente importante. Las cosas cambian. Otro desarrollador modificó el código original. La documentación es pobre o inexistente. El negocio está bajo presión. Es posible que las actualizaciones no se prueben exhaustivamente. E incluso si el desarrollo y las pruebas fueran impecables y las revisiones fueran meticulosas, es posible que haya algo que se haya pasado por alto en el diseño original y que podría volverse en su contra. Muévete hacia la izquierda, sí, pero deja de mirar hacia la derecha bajo tu propio riesgo.

No se limitan las pruebas de un avión de pasajeros únicamente a las fases de diseño de la construcción. Realiza un programa de vuelos de prueba sin pasajeros a bordo. Cuando está en servicio, sigue realizando comprobaciones automáticas y monitorea continuamente sus sistemas críticos todo el tiempo que está en el aire. Necesitamos hacer algo similar con las API. El problema, como ya hemos visto, es la gran cantidad de ellos. No todos transportan pasajeros o carga valiosa. Algunos de ellos realizan trabajos banales, o no tienen trabajo si han sido jubilados o reemplazados.

Como todo CISO sabe, el mayor desafío en seguridad no es identificar las amenazas, sino detectar las que importan y ordenarlas por orden de prioridad.

La forma de hacer esto es fundamental. En primer lugar, es necesario hacer visibles los riesgos.

Esto no es difícil si sabes dónde buscar y los equipos de seguridad ya están alerta hasta la cintura. Lo difícil es clasificarlos de manera significativa. Hacer esto requiere una vista tridimensional que tenga en cuenta:

En otras palabras, usted quiere saber: ¿puede suceder algo malo? ¿Qué tan malo sería para su negocio si sucediera y qué tan alta es la probabilidad de que ocurra algo malo? Luego, cada uno de estos factores debe ponderarse y correlacionarse para proporcionar una puntuación de riesgo. Para usar una analogía no técnica, si uno de sus riesgos es un "león salvaje", pero el contexto es que el león está en una jaula de acero, la puntuación podría ser baja. Si otro es una familia de ratones, pero el contexto es una bolsa de papel, se podría llegar a una conclusión similar. Si tu león está en una bolsa de papel, ya entiendes la idea. Hacer esto requiere datos mucho más granulares que los que proporcionan la mayoría de las herramientas actualmente. El secreto es recopilar la información desde múltiples lentes. Eso significa no mirar solo, digamos, el análisis del tráfico (aunque sea útil cuando una API está en producción) sino el análisis del código fuente, que proporciona el contexto y la escala de la superficie de ataque, que informa la probabilidad.

Este enfoque 3D de alta definición permite a las empresas gestionar sus riesgos de API con certeza y precisión, proporcionando una orientación muy necesaria sobre cómo utilizar los recursos de desarrollo e ingeniería ya sobreasignados para centrarse primero en sus riesgos más altos.

Terminemos con dos pensamientos sorprendentes. En primer lugar, qué tan abiertas están las API a ataques externos. En segundo lugar, lo poco que parece haber hecho la industria para producir soluciones integrales que aborden todo el problema, desde el código fuente hasta el mundo exterior. Dado que el tráfico API representa 9 de cada 10 paquetes en la web hoy en día y sigue creciendo, este es un problema que todos debemos resolver ahora mismo.