Adapte la seguridad de API de terceros a tres casos de uso específicos

COMENTARIO

La seguridad de las API a menudo implica API de terceros en lugar de API propias, y cada caso de uso puede tener requisitos diferentes. En lugar de intentar que un enfoque tecnológico funcione para todas las instancias, los líderes de seguridad y gestión de riesgos deben adaptar su enfoque a cada caso de uso.

Según un encuesta actual de GartnerEl 71% de los líderes de TI dicen que utilizan interfaces de programación de aplicaciones (API) de terceros en sus organizaciones. Al abordar el uso y la integración de API de terceros, muchos líderes de seguridad y gestión de riesgos deben centrarse en la seguridad de las API en lugar de en la exposición de las API propias.

Además, cuando se trata de API de terceros, muchas acciones correctivas, como parches de vulnerabilidad, no están bajo el control directo de la organización. Por lo tanto, el enfoque debe ser fundamentalmente diferente al de las API propias.

Para estos líderes de seguridad, lo primero que deben tener en cuenta son tres casos de uso.

Caso de uso 1: descubrir y gestionar flujos de datos salientes a API de terceros

En este primer caso de uso, la empresa envía datos a terceros a través de API, normalmente llamándolos desde aplicaciones de desarrollo propio. Por ejemplo, en un escenario de comercio electrónico, el servicio que proporciona la API podría ser una pasarela de pago. En este ejemplo, el tráfico saliente contendría datos de pago utilizados para procesar un pago. Hay diferentes formas de llamar a la API desde la aplicación, como por ejemplo: B. integración directa, el uso de un kit de desarrollo de software o un webhook.

Un riesgo clave es que se envíen datos confidenciales a la API. Esta actividad puede entrar en conflicto con las políticas de la empresa o las regulaciones de la industria. Las API de terceros también pueden poner en riesgo sus datos o los de sus clientes. Por ejemplo, un atacante podría robar datos de pago de clientes aprovechando una API de pago vulnerable. Dependiendo del escenario, inyectar una carga útil maliciosa también puede dañar la base de datos de un socio comercial.

En este escenario, los administradores de seguridad deben detectar las API de terceros realizando una inspección del tráfico, una revisión del repositorio de código y un análisis de la composición del software, ya que se puede acceder a ciertas API de terceros a través de bibliotecas de terceros en lugar de código propio.

Los líderes de seguridad también deben trabajar con el equipo que gestiona las adquisiciones, la gestión de adquisiciones y proveedores (SPVM) y el riesgo cibernético de terceros para garantizar que las aplicaciones de software como servicio (SaaS) sean auditadas y cumplan con las políticas de la empresa.

Los líderes de seguridad también deben detectar la filtración de datos confidenciales monitoreando el tráfico saliente en estos intercambios de API. Esto normalmente se logra mediante la implementación de capacidades de Prevención de pérdida de datos (DLP). Se podrían utilizar diferentes herramientas; por ejemplo, las herramientas de protección Security Service Edge (SSE), DLP y API tienen capacidades DLP específicas.

Finalmente, los administradores de seguridad pueden implementar la autenticación y autorización adecuadas del cliente API (en este escenario de aplicación) utilizando los mecanismos ofrecidos por el proveedor de API. Al menos prefiera tokens a claves API para la autorización. Evalúe cómo los tokens opacos y de prueba de propiedad (o al menos las credenciales que rotan con frecuencia) y la fijación de certificados pueden mitigar de manera eficiente los riesgos de fugas e intercepciones de tokens en casos de uso específicos. Considere el esfuerzo técnico que puede ser necesario para configurarlo y los problemas de control de tráfico.

Caso de uso 2: Protección contra el tráfico entrante de API de terceros

En este caso de uso, la organización utiliza una API de terceros y los datos ingresan. Un ejemplo típico podría ser una aplicación empresarial que realiza una llamada API para obtener datos de un proveedor comercial de SaaS o de un socio comercial.

Un riesgo en este caso de uso es recibir entradas potencialmente maliciosas de la API. Las entradas maliciosas de API de terceros pueden comprometer las aplicaciones, sus usuarios o la infraestructura que aloja las aplicaciones. Por ejemplo, enviar una respuesta API que contenga una carga útil maliciosa a una base de datos podría resultar en un ataque de inyección.

La filtración de datos todavía representa un riesgo para este caso de uso y muchas de las recomendaciones del primer caso de uso todavía se aplican aquí. Si la solicitud de API saliente contiene datos confidenciales, estos datos pueden interceptarse. Por ejemplo, si una llamada API solicita una lista de restaurantes basada en coordenadas GPS, esas coordenadas GPS podrían interceptarse si la conexión no es segura. Lo más importante es que la API de terceros puede recuperar datos específicos de la empresa. (Por ejemplo, considere una API que recupera datos sobre clientes de instancias específicas de una aplicación CRM SaaS).

Los administradores de seguridad deben realizar la validación de las entradas. Solicite a los desarrolladores que agreguen controles de validación de entradas al ingerir entradas, incluidas las de API de terceros. Esto evita una amplia gama de ataques de entrada maliciosos, como los ataques de inyección SQL. Las herramientas de prueba de seguridad de aplicaciones (AST) pueden ayudar a automatizar estas comprobaciones.

Aproveche la funcionalidad del firewall de aplicaciones web de una aplicación web y una herramienta de protección API en línea para protegerse contra ataques de inyección y otros tipos de entradas maliciosas.

Finalmente, valide la entrada con un antivirus, sandboxing o una solución de reconstrucción y desactivación de contenido, integrando aplicaciones con una o más de estas herramientas, generalmente a través de protocolos de adaptación de contenido de Internet o API.

Caso de uso 3: descubrir, inspeccionar y administrar datos de aplicaciones de terceros que se comunican a través de API

Muchos líderes de seguridad se centran en la seguridad de las API, pero describen un escenario en el que una o más aplicaciones SaaS normalmente se comunican e intercambian datos corporativos a través de las API. Este problema puede agravarse porque los usuarios pueden conectar aplicaciones SaaS sin tener derechos administrativos. Si bien la comunicación subyacente puede estar basada en API, resolver este problema se acerca más a las mejores prácticas de seguridad de SaaS.

Esta situación presenta un desafío particular cuando un usuario autorizado de una aplicación SaaS la conecta a una aplicación SaaS no autorizada a través de la API. Muchas organizaciones tienen poca o ninguna visibilidad de la existencia de la conexión, y mucho menos de las transferencias de datos a través de ella. En segundo lugar, la visibilidad se limita a lo que los proveedores de SaaS exponen a través de sus propias API de gestión, ya que no hay un lugar claro para insertar el control en línea. El principal riesgo en este escenario es que la aplicación SaaS pueda exponer datos confidenciales de la empresa a través de la API y que los datos puedan transferirse a una ubicación no autorizada o incluso desconocida que no haya sido examinada por seguridad.

Los líderes de seguridad deben identificar las aplicaciones SaaS en uso mediante la realización de un censo, la publicación de una política y la auditoría del tráfico. Utilice SSE, firewalls, plataformas de administración SaaS u otras herramientas para identificar las aplicaciones SaaS a las que acceden los usuarios, especialmente aquellas que contienen datos confidenciales. A menos que sepan a qué aplicaciones acceden los usuarios, no pueden auditar la conectividad de SaaS a SaaS.

Detecte tokens de acceso SaaS fraudulentos consultando las aplicaciones SaaS en uso, si son compatibles. Cree y promueva políticas de usuario para conectar aplicaciones SaaS a través de OAuth.

Para los casos de uso anteriores, debe comunicarse con el equipo que administra SPVM y el riesgo cibernético de terceros para asegurarse de que las aplicaciones SaaS sean auditadas y cumplan con las políticas de la empresa, tales como: B. para la seguridad de los datos y su divulgación por parte de terceros. Además, inventario de conexiones SaaS a SaaS; Las herramientas automatizadas como las ofertas de SSPM pueden ayudar a garantizar que sea un proceso continuo.

Al adaptar sus enfoques a estos tres casos de uso específicos y sus posibles variaciones, los líderes de seguridad pueden abordar los riesgos que las API de terceros representan para sus organizaciones.