Repensar el software en la jerarquía organizativa

Una versión de este artículo apareció en Dark Reading. Ha sido actualizado y distribuido aquí.

‍

Cualquiera que haya trabajado ha visto alguna vez uno de esos organigramas que definen quién depende de quién en una empresa. A veces llamado simplemente organigrama, es una herramienta útil para saber quién trabaja para quién y quiénes son los jefes. Por ejemplo, en un organigrama típico, el jefe de un grupo de programación podría depender del director de desarrollo de producto, quien a su vez depende del vicepresidente de innovación. Las líneas de autoridad continúan por toda la estructura. ¿Quién no ha buscado su propio bloque en uno de estos gráficos?

No es de extrañar que nos fascine la jerarquía. Históricamente, es lo que nos ha mantenido vivos como especie, incluso en tiempos antiguos cuando nos enfrentábamos a un mundo muy peligroso. Nunca fuimos los más fuertes ni los más rápidos, pero trabajamos bien en equipo, donde cada uno conocía su lugar y su responsabilidad para mantener a la familia, la tribu o el grupo unidos, vivos y prósperos. El organigrama moderno es, en realidad, una extensión de esos tiempos y de aquel éxito ancestral.

Pero hay algo que casi todos los organigramas tienen en común, sin importar el tamaño de la empresa. En su mayoría, todos los bloques representan a personas o grupos de personas. No hemos llegado al punto en que las máquinas supervisen a los humanos, así que, por ahora, los organigramas son un asunto exclusivamente humano. Pero, ¿necesita nuestro software una jerarquía organizativa?

Por supuesto, no sugiero añadir software a nuestros organigramas corporativos. Nadie quiere tener una aplicación como jefe. ¿Cómo le pedirías un aumento? Sin embargo, el panorama de amenazas al que se enfrentan nuestras aplicaciones hoy en día no es muy distinto del entorno peligroso que afrontaban nuestros ancestros. Al definir las responsabilidades de nuestro software dentro de una jerarquía estricta y aplicar políticas de menor privilegio, podemos asegurar que nuestras aplicaciones sobrevivan y prosperen a pesar del devastador panorama de amenazas.

Los ataques a aplicaciones y software alcanzan un máximo histórico

Para entender la necesidad de crear mejores jerarquías organizativas para el software, primero hay que comprender el panorama de amenazas. Los atacantes actuales, junto con los bots y el software automatizado que utilizan, escanean constantemente cualquier fallo en las defensas para explotarlo. Aunque el phishing y otros ataques contra humanos siguen existiendo, los hackers más hábiles han centrado la mayor parte de sus esfuerzos en atacar el software.

Y aunque todo el software es un objetivo, los ataques más exitosos se dirigen contra las interfaces de programación de aplicaciones, o API. Esas discretas API son pequeñas piezas de software que los desarrolladores utilizan para realizar diversas tareas, pequeñas pero importantes, para sus aplicaciones. Suelen ser flexibles y únicas, y a veces se crean sobre la marcha según las necesidades del proceso de desarrollo.

Las API son ciertamente flexibles, pero a menudo tienen demasiados permisos para sus funciones. Los desarrolladores tienden a otorgarles muchos permisos para que puedan seguir funcionando incluso a medida que el programa que ayudan a gestionar evoluciona y cambia. Pero esto significa que, si un atacante las compromete, obtiene mucho más que acceso a una parte de una base de datos específica. Podrían llegar a capturar derechos casi de administrador de toda una red.

No es de extrañar que varias firmas de investigación de seguridad afirmen que la gran mayoría de los ataques de robo de credenciales actuales se dirigen contra software como las API. Akamai sitúa esa cifra en el 75% del total, mientras que Gartner señala que las vulnerabilidades en las API se han convertido en el vector de ataque más frecuente. El informe más reciente de Salt Labs muestra que los ataques contra API aumentaron casi un 700% en comparación con el año pasado.

Creación de un organigrama para el software

Una de las formas en que las organizaciones combaten las amenazas de robo de credenciales es aplicando el principio de menor privilegio o incluso la confianza cero dentro de sus redes. Esto limita a los usuarios a recibir solo los permisos mínimos necesarios para realizar su trabajo. Este acceso suele restringirse aún más por factores como el tiempo y la ubicación. De este modo, incluso si un ataque tiene éxito, no será de gran utilidad para el atacante, ya que solo tendrá permisos limitados durante un breve periodo.

El menor privilegio es una buena defensa, pero normalmente solo se aplica a usuarios humanos. Solemos olvidar que las API también tienen privilegios elevados y, a menudo, no están tan reguladas. Esa es una de las razones por las que el control de acceso deficiente es ahora el enemigo público número uno según el Open Web Application Security Project (OWASP), que rastrea los patrones de ciberataques.

Es fácil decir que la solución es aplicar el menor privilegio al software, pero es mucho más difícil de implementar. Primero, hay que concienciar a los desarrolladores sobre los peligros. Luego, las API y otros programas deberían integrarse, o al menos visualizarse, como parte de un organigrama dentro de la red informática donde residen. Por ejemplo, si una API debe obtener datos de vuelos en tiempo real para una aplicación de reservas, no hay razón para que pueda conectarse con sistemas de nómina o finanzas. En el organigrama de software, no debería haber líneas que conecten esos sistemas.

Es poco realista que los desarrolladores creen un organigrama con los millones de API de su organización. Pero ser conscientes del peligro y restringir sus permisos a lo estrictamente necesario ayudará a frenar los ataques de robo de credenciales. Todo empieza con la concienciación y termina tratando a las API con el mismo rigor que a los usuarios humanos.
‍

¿Quieres potenciar a tu equipo? Gestiona la seguridad de tus API con nuestra plataforma de aprendizaje ágil y herramientas de seguridad.