Las API modernas (especialmente en microservicios interconectados) erosionan los límites típicos de la red y reducen la efectividad de las protecciones perimetrales tradicionales, como los firewalls de aplicaciones web (WAF). Mauny sugiere que con la importancia cada vez menor del perímetro, es más importante proteger los datos que el perímetro en sí.

La otra consideración clave es garantizar que las herramientas de seguridad de API tengan el contexto completo para garantizar que la herramienta tome la decisión correcta, ya sea de forma estática (como cuando se audita un contrato de API con el estándar OpenAPI) o dinámicamente al imponer el comportamiento del tráfico en un punto final de API. Los WAF también ejemplifican cómo la falta de contexto los hace ineficaces para proteger una API: un WAF no puede distinguir el comportamiento malo (no intencionado) del comportamiento bueno (intencionado). 

Finalmente, el artículo destaca el valor de los contratos API como medio hacia un modelo de seguridad positivo, en el que se define claramente el comportamiento esperado, lo contrario de un modelo de seguridad negativo donde se infiere un mal comportamiento. Al utilizar una definición de API (como una definición de OpenAPI del contrato de API) es posible verificar el proceso de desarrollo de API en cada etapa del ciclo de desarrollo e implementación. Este enfoque le brinda al oficial de seguridad una visión temprana de la postura de seguridad de las API y garantiza que las API se pueden probar con sus contratos.

Aunque los entornos en la nube ofrecen a las empresas muchos beneficios de seguridad, continúan surgiendo nuevas vulnerabilidades que ofrecen a los atacantes nuevos caminos hacia los entornos basados en la nube. 

Una de esas rutas de ataque es la API. Cada aplicación móvil conectada, web moderna o alojada en la nube utiliza y expone API. Estas API permiten el acceso a los datos y llamar a la funcionalidad de la aplicación. Si bien son relativamente fáciles de exponer, son difíciles de documentar y defender. 

Como resultado, abundan las API ocultas y zombies, la verificación de tipos es laxa, las especificaciones de la API están incompletas y los problemas de autenticación y autorización a menudo aumentan. Para abordar estos desafíos, 42Crunch colaboró con Cisco para crear APIClarity, una nueva herramienta de código abierto para mejorar la configuración y protección de las API.

Un informe reciente de IBM revela que dos tercios de las brechas en la nube tienen su origen en una mala configuración de las implementaciones de API. El informe contiene 12 meses de hallazgos de varios equipos de investigación de IBM y concluye que los entornos de nube deben estar mejor protegidos, los hallazgos clave del informe incluyen:

  • Existe un vasto y próspero mercado negro para la reventa de detalles y credenciales de acceso a la nube pública, como el acceso al Protocolo de escritorio remoto.
  • Muchos sistemas podrían verse comprometidos debido a contraseñas deficientes y políticas inadecuadas.
  • Las API fueron la causa más común de compromiso, representando casi dos tercios de los casos identificados en el informe.
  • La erosión del perímetro tradicional ha dado lugar a escenarios más complejos que son difíciles de proteger con sistemas heredados.

Las principales recomendaciones del informe incluyen:

  • Los entornos deben protegerse mediante un refuerzo más sólido de los sistemas (por ejemplo, mediante la protección de contraseñas o la aplicación de políticas).
  • Se debe imponer un gobierno más estricto a la “TI en la sombra” porque representa un riesgo comercial no cuantificado y es una fuente frecuente de compromiso.
  • Las organizaciones deben comprender los riesgos inherentes a la rápida apertura al acceso público de las APIs que hasta ahora solo eran internas, ya que esto abre nuevos vectores de ataque. 

Cada vez más, los puntos finales de las APIs destinados a aplicaciones web o móviles están siendo atacados por robots y actores deshonestos, ser capaz de identificar estos ataques en los sistemas permite frustrar los ataques potenciales antes de que tengan éxito estas son algunas sugerencias clave (y relativamente simples) para los desarrolladores de API:

  • Utilice un dominio separado para aplicaciones web y móviles. Esto permite identificar la actividad espuria, por ejemplo, al poder detectar cuándo un navegador está accediendo a un punto final destinado a una aplicación móvil, un indicador principal de que un atacante humano puede estar intentando aplicar ingeniería inversa a la API.
  • Preste atención a la presencia de “rastreadores”, como Facebook y Google, que se utilizan comúnmente para enumerar sitios web, en los puntos finales de la API, especialmente en los de aplicaciones móviles. La presencia de rastreadores en los registros suele ser una indicación de reconocimiento activo y un ataque inminente.
  • Revise los registros de API periódicamente, prestando especial atención a las cadenas de agentes de usuario: una señal de comportamiento inusual o inesperado suele ser el precursor de un ataque.

Dado el aumento de los ataques de bots a las API, estas simples recomendaciones deberían resultar valiosas para los creadores de API.

     Queremos ser su aliado tecnológico

Permítanos conocer sus requerimientos y desarrollar una estrategia de automatización innovadora para su empresa.

Recommended Posts

No comment yet, add your voice below!


Add a Comment