La protección de las aplicaciones comienza con la protección del flujo de trabajo del SDLC

Las prácticas de desarrollo modernas están automatizando cada vez más el ciclo de vida del desarrollo. Desde el IDE hasta los repositorios de código, desde la creación y el escaneo automatizados hasta el lanzamiento a producción, las herramientas se combinan para formar un canal de entrega continua.

Los repositorios actúan como lugares para almacenar código y para iniciar los eventos que componen el proceso de entrega. Cuando se confirma el código, es posible que se ejecute un análisis de seguridad. Cuando se cambia una configuración, se puede enviar automáticamente a la infraestructura adecuada para su implementación inmediata.

Estas herramientas están acelerando el proceso de desarrollo, entrega e implementación, y cada vez más están "en la nube". Los que residen localmente suelen ser accesibles a través de Internet para apoyar a una comunidad cada vez mayor de desarrolladores remotos. Si bien la mayoría de las organizaciones son lo suficientemente conocedoras de la seguridad como para exigir acceso con credenciales a los repositorios, lo que no necesariamente están haciendo es proteger ese acceso contra las amenazas modernas.

Una de esas amenazas modernas es el credential stuffing . Aunque generalmente se presenta como un riesgo para los recursos corporativos, la realidad es que cualquier sistema acreditado accesible a través de Internet corre el riesgo de verse comprometido. Los desarrolladores no tienen mayor ni menor probabilidad que cualquier otro profesional de TI de aplicar prácticas de uso de contraseñas seguras. La reutilización de contraseñas en Internet es común, y la exposición de miles de millones de credenciales permite a los atacantes aprovechar un amplio conjunto de recursos en sus esfuerzos por obtener acceso a una variedad de sistemas. Considere este artículo que expone este aforismo: " Una encuesta realizada a 306 profesionales de seguridad de la información en la Conferencia de Seguridad de la Información de 2018 en Londres, realizada por Lastline, mostró que el 45 % comete uno de los mayores pecados capitales en materia de seguridad: reutilizar contraseñas en distintas cuentas". Si casi la mitad de los profesionales de seguridad reutilizan contraseñas, imaginemos cómo es el perfil del resto de la comunidad de TI, incluidos los desarrolladores.

Desde el punto de vista existencial, la infame filtración de datos en Estados Unidos... La Oficina de Administración de Personal (OPM), que comenzó en 2014, fue llevada a cabo por atacantes que habían comprometido con éxito las credenciales de un usuario privilegiado. Una vez que los atacantes lograron robar esas credenciales, no solo pudieron acceder a la información confidencial contenida en los servidores de la OPM, sino que también pudieron moverse lateralmente a los servidores y la infraestructura de Estados Unidos. Departamento del Interior donde también causaron estragos.

El acceso a los sistemas y servicios que componen el SDLC permite a los atacantes envenenar el pozo, por así decirlo. La inyección de comportamiento malicioso o el robo de ideas se logra fácilmente si uno tiene acceso al código fuente. 

Para combatir esta amenaza, las organizaciones deberían considerar extender el concepto de una arquitectura de confianza cero a las herramientas en su proceso de desarrollo de software. Desde el IDE hasta las consolas de administración en la nube y los repositorios de código, el uso del acceso de usuario privilegiado puede implementar prácticas de seguridad sólidas basadas en MFA/CAC.

Acceso de usuario privilegiado y canalización SDLC

El acceso de usuario privilegiado (PUA) es básicamente una federación sin SAML ni el requisito de que las aplicações admitan algún tipo de método exótico de autenticación. Puede extender los principios de confianza cero a aplicaciones heredadas y también brindar soporte a aplicações modernas basadas en la web.

Esta solución se basa en la capacidad de F5 Access Policy Manager (APM) de actuar como un proxy de credenciales junto con su capacidad para generalizar automáticamente credenciales efímeras. En pocas palabras, los usuarios se autentican frente a un almacén de credenciales corporativas (controlador de dominio, LDAP) y luego APM genera credenciales efímeras que se pueden usar para iniciar sesión en el sistema protegido. En el caso del pipeline de desarrollo, este podría ser el repositorio de código como Bitbucket , GitHub o GitLab . Este enfoque mantiene un control más estricto sobre el acceso al repositorio sin introducir una gran cantidad de sobrecarga de proceso para el desarrollador. 

1. El usuario proporciona credenciales a BIG-IP
2. BIG-IP valida las credenciales del usuario frente a un servicio de directorio local o IaaS
3. BIG-IP proporciona credenciales efímeras al usuario autenticado
4. Credenciales efímeras del usuario a través de IDE o navegador al repositorio
5. El repositorio pasa el nombre de usuario y las credenciales efímeras a BIG-IP para su validación
6. BIG-IP devuelve la validación
7. El usuario ha iniciado sesión correctamente en el repositorio.

Los datos sensibles deben incluir código. Esto significa que, al igual que los datos, el acceso al código debe estar protegido. El código es el corazón de un negocio digital y el proceso de entrega se considera cada vez más un vector de ataque. Al implementar un modelo de acceso de usuario privilegiado , puede tener más confianza de que tanto las credenciales como el usuario detrás de ellas son legítimos.

Puede obtener más información sobre F5 APM aquí .