Repensar el software en la jerarquía organizacional

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

‍

Es probable que todos, en algún momento de su carrera, hayan visto uno de esos informes operativos o gráficos jerárquicos que definen quién depende de quién en una organización. A veces simplemente se llama organigrama, es una herramienta útil para que las personas sepan quién trabaja para ellas y quiénes son sus jefes. Por ejemplo, en un organigrama típico, el jefe de un grupo de programación puede depender del director de desarrollo de productos, quien a su vez depende del vicepresidente de innovación. Y luego, las líneas de autoridad suben y bajan en la estructura de la empresa. ¿Quién no ha mirado uno de esos gráficos para intentar encontrar su pequeño bloque personal escondido en algún lugar?

No es de extrañar que los humanos estén tan fascinados por 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, ya que todos sabían cuál era su lugar y su responsabilidad a la hora de mantener unidos, vivos y prósperos a nuestra familia, tribu o grupo. El organigrama moderno es en realidad una extensión de aquellos tiempos y de ese éxito ancestral.

Pero hay algo que casi todos los organigramas tienen en común, independientemente del tamaño de la empresa u otros factores. En su mayor parte, todos los componentes básicos de esos gráficos representan a personas o grupos de personas. No estamos en un punto en el que las máquinas puedan supervisar a los humanos, por lo que, por ahora, los organigramas son un asunto exclusivamente humano. Pero, ¿nuestro software también necesita una jerarquía organizacional?

Por supuesto, no estoy sugiriendo que agreguemos software a los organigramas de nuestra empresa. Nadie quiere tener una aplicación para un jefe. ¿Cómo les pedirías un aumento? Sin embargo, el panorama de amenazas al que se enfrentan nuestras aplicaciones y programas en estos días no es muy diferente del peligroso entorno al que se enfrentaron nuestros antiguos parientes humanos hace mucho tiempo. Si ayudamos a definir las responsabilidades de nuestras aplicaciones y software dentro de una jerarquía estricta y a hacer cumplir esas políticas con los mínimos privilegios, podemos asegurarnos de que nuestras aplicaciones y software también sobrevivan y prosperen a pesar del panorama de amenazas devastadoramente difícil que se les presenta.

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, es importante entender primero el panorama de amenazas. Hoy en día, los atacantes, así como los bots y el software basado en la automatización que les funciona, buscan constantemente cualquier error en las defensas para aprovecharlo. Y aunque siguen lanzándose ataques de suplantación de identidad y de otro tipo contra seres humanos, los hackers más hábiles han centrado la mayor parte de sus esfuerzos en atacar el software.

Y mientras todo el software está en el punto de mira, los ataques más exitosos se realizan contra las interfaces de programación de aplicaciones o API. Estas sencillas API son pequeñas piezas de software que utilizan los desarrolladores para realizar una variedad de tareas pequeñas pero importantes para sus aplicaciones y programas. Suelen ser flexibles y únicas y, a veces, incluso se crean sobre la marcha según sea necesario en el proceso de desarrollo.

Las API son ciertamente flexibles, pero también lo son a menudo muy sobreautorizado por sus funciones. Los desarrolladores suelen concederles muchos permisos para que, por ejemplo, puedan seguir funcionando aunque el programa que ayudan a gestionar siga desarrollándose y cambiando. Pero eso significa que si un atacante los compromete, obtiene mucho más que solo los derechos de acceso, por ejemplo, a una parte de una base de datos específica. Incluso pueden obtener derechos prácticamente de administrador sobre toda una red.

No es de extrañar que varias firmas de investigación de seguridad digan que la inmensa mayoría de los ataques de robo de credenciales actuales se realizan contra software como las API. Akamai sitúa ese número en 75% del total, mientras que Gartner también afirma que vulnerabilidades relacionadas con las API se han convertido en el vector de ataque más frecuente. Y el informe más reciente de Salt Labs muestra los ataques contra las API aumentando 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 luchan contra las amenazas de robo de credenciales es imponiendo el mínimo privilegio o incluso la confianza cero en sus redes. Esto limita a los usuarios a recibir apenas los permisos suficientes para realizar su trabajo o sus tareas. Ese acceso a menudo se ve restringido aún más por factores como la hora y la ubicación. De este modo, aunque un ataque de robo de credenciales tenga éxito, no servirá de mucho al atacante, ya que solo tendrá permiso para realizar funciones limitadas durante un breve período de tiempo.

El mínimo privilegio es una buena defensa, pero normalmente solo se aplica a usuarios humanos. Tendemos a olvidar que las API también tienen privilegios elevados y, a menudo, no están tan reguladas. Esa es una de las razones control de acceso roto 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 a este problema crítico es simplemente aplicar los privilegios mínimos al software. Pero es mucho más difícil de implementar. En primer lugar, los desarrolladores deben ser conscientes de los peligros. Y luego, de ahora en adelante, las API y otros tipos de software deberían colocarse oficialmente, o al menos imaginarse, como parte de un organigrama dentro de la red informática en la que residirán. Por ejemplo, si se supone que una API recopila datos de vuelos en tiempo real como parte de una aplicación de reservas, no hay motivo para que también pueda conectarse con los sistemas de nómina o de financiación. En el organigrama del software, no habría líneas directas ni punteadas que conectaran esos sistemas.

Probablemente no sea realista que los desarrolladores creen realmente un organigrama que muestre los miles o incluso millones de API que operan en su organización. Sin embargo, ser conscientes del peligro que representan y restringir sus permisos solo a lo que necesitan para hacer su trabajo contribuirá en gran medida a detener los ataques desenfrenados de robo de credenciales a los que todo el mundo se enfrenta hoy en día. Comienza con la toma de conciencia y termina con tratar las API y el software con el mismo escrutinio que los usuarios humanos.
‍

¿Quieres mejorar tu equipo de desarrollo? Resolver los problemas de seguridad de la API y más con nuestro plataforma de aprendizaje ágil y herramientas de seguridad que dan prioridad a los desarrolladores.