Repensar el software en la jerarquía organizativa

Una versión de este artículo apareció en Lectura oscura. Se ha actualizado y sindicado aquí.

‍

Todo el mundo ha visto en algún momento de su carrera uno de esos organigramas que definen quién depende de quién en una organización. A veces se denominan simplemente organigramas y son una herramienta útil para que la gente sepa quién trabaja para ellos y quiénes son sus jefes. Por ejemplo, en un organigrama típico, el jefe de un grupo de codificación puede depender del director de desarrollo de productos, que a su vez depende del vicepresidente de innovación. Y luego las líneas de autoridad continúan hacia arriba y hacia abajo en la estructura de la empresa. ¿Quién no ha mirado uno de esos organigramas para intentar encontrar su pequeño bloque personal en algún lugar?

No es de extrañar que a los humanos nos fascinen tanto la jerarquía y la estructura. Es lo que históricamente nos ha mantenido vivos como especie durante tanto tiempo, incluso en la antigüedad, cuando nos enfrentábamos a un mundo muy peligroso. Nunca fuimos las criaturas más fuertes ni las más rápidas, pero trabajábamos bien en equipo y cada uno sabía cuál era su lugar y su responsabilidad a la hora de mantener unida, viva y próspera a nuestra familia, tribu o grupo. El organigrama moderno es en realidad una prolongación de aquellos tiempos y de aquel antiguo éxito.

Pero hay algo que casi todos los organigramas tienen en común, independientemente del tamaño de la empresa o de otros factores. En su mayor parte, todos los componentes de esos organigramas son humanos o grupos de humanos. Aún no hemos llegado al punto en que las máquinas puedan supervisar a los humanos, así que, por ahora, los organigramas son un asunto exclusivamente humano. Pero, ¿nuestro software también necesita una jerarquía organizativa?

Por supuesto, no estoy sugiriendo que añadamos software a los organigramas de nuestras empresas. Nadie quiere tener una aplicación como jefe. ¿Cómo le pedirías un aumento? Pero el panorama de amenazas al que se enfrentan nuestras aplicaciones y programas hoy en día no es muy distinto del peligroso entorno al que se enfrentaban nuestros antiguos parientes humanos hace mucho tiempo. Ayudando a definir las responsabilidades de nuestras aplicaciones y programas dentro de una jerarquía estricta, y aplicando esas políticas con el menor privilegio, podemos asegurarnos de que nuestras aplicaciones y programas también sobrevivan y prosperen a pesar del devastador y duro panorama de amenazas que se les presenta.

Los ataques a aplicaciones y programas informáticos alcanzan su máximo histórico

Para entender la necesidad de crear mejores jerarquías organizativas para el software, es importante comprender primero el panorama de las amenazas. Hoy en día, los atacantes, y los bots y el software automatizado que trabajan para ellos, buscan constantemente cualquier fallo en las defensas que puedan aprovechar. Y aunque se siguen lanzando ataques de phishing y de otro tipo contra humanos, los hackers más hábiles han trasladado la mayoría de sus esfuerzos a atacar software.

Y aunque todo el software está en el punto de mira, los ataques más exitosos se están realizando contra las interfaces de programación de aplicaciones, o API. Estas sencillas API son pequeñas piezas de software utilizadas por los desarrolladores para realizar una serie de pequeñas pero importantes tareas para sus aplicaciones y programas. A menudo son flexibles y únicas, y a veces incluso se crean sobre la marcha, según las necesidades del proceso de desarrollo.

Las API son ciertamente flexibles, pero también suelen tener demasiados permisos para sus funciones. Los desarrolladores tienden a darles muchos permisos para que puedan, por ejemplo, seguir funcionando aunque el programa que están ayudando a gestionar siga desarrollándose y cambiando. Pero eso significa que si un atacante los compromete, entonces obtienen mucho más que los derechos para acceder, por ejemplo, a una parte de una base de datos específica. Pueden incluso obtener derechos de casi administrador para toda una red.

No es de extrañar que varias empresas de investigación de seguridad afirmen que la inmensa mayoría de los ataques actuales de robo de credenciales se realizan contra software como las API. Akamai cifra esa cifra en el 75% del total, mientras que Gartner también afirma que las vulnerabilidades que afectan a las API se han convertido en el vector de ataque más frecuente. Y el informe más reciente de Salt Labs muestra que los ataques contra las API han aumentado casi un 700% en comparación con el año pasado.

Creación de un organigrama para software

Una de las formas en que las organizaciones están luchando contra las amenazas de robo de credenciales es aplicando el mínimo privilegio o incluso la confianza cero dentro de sus redes. Esto limita a los usuarios a recibir permisos apenas suficientes para realizar su trabajo o tareas. Ese acceso suele restringirse aún más por factores como la hora y la ubicación. De esta forma, incluso si un ataque de robo de credenciales tiene éxito, no servirá de mucho al atacante, ya que sólo tendrá permiso para realizar funciones limitadas durante un breve periodo de tiempo.

El mínimo privilegio es una buena defensa, pero normalmente sólo se aplica a los usuarios humanos. Tendemos a olvidar que las API también tienen privilegios elevados, y a menudo no están tan reguladas. Esta es una de las razones por las que un control de acceso defectuoso es ahora el enemigo público número uno según el Open Web Application Security Project (OWASP), que rastrea los patrones de los ciberataques. 

Es fácil decir que la solución a este problema crítico es simplemente aplicar el mínimo privilegio al software. Pero es mucho más difícil de aplicar. En primer lugar, hay que concienciar a los desarrolladores de los peligros. Y luego, de cara al futuro, las API y demás software deben situarse oficialmente, o al menos preverse, como parte de un organigrama dentro de la red informática en la que residirán. Por ejemplo, si una API debe obtener datos de vuelos en tiempo real como parte de una aplicación de reservas, no hay razón para que también pueda conectarse con los sistemas de nóminas o finanzas. En el organigrama del software, no habría líneas directas, ni siquiera discontinuas, que conectaran esos sistemas.

Probablemente sea poco realista para los desarrolladores crear un organigrama que muestre los miles o incluso millones de APIs que operan en su organización. Pero ser conscientes del peligro que suponen y restringir sus permisos a lo estrictamente necesario para realizar su trabajo contribuirá en gran medida a detener los ataques desenfrenados de robo de credenciales a los que todo el mundo se enfrenta estos días. Comienza con la concienciación y termina tratando las API y el software con el mismo escrutinio que a los usuarios humanos.
‍

¿Quiere elevar su equipo de desarrollo? Navegue por los problemas de seguridad de las API y mucho más con nuestro ágil learning platform herramientas de seguridad ágiles y orientadas al desarrollador.