¡Hola a todos! Estoy muy contento de colaborar con Open Security Network, que sin duda es una red, además de amigos, que se dedica a promover la seguridad digital y compartir conocimientos y desde ahora les agradezco por la lectura y espero que sea de utilidad y aprendizaje para todos.

Para aquellos que me conocen, saben el entusiasta de ciberseguridad que soy, pero hace 1 año he empezado a trabajar con más profundidad en seguridad en el mundo de la nube, y, por cierto, he descubierto y reformulado muchos conceptos que he vivido.  Para iniciar esta “conversación”, es importante definir el punto cero de toda la jornada de seguridad de nube que es la aplicación, desde el momento de su desarrollo y construcción de código.

La seguridad de las aplicaciones se refiere a las prácticas y estrategias que protegen las aplicaciones de software de vulnerabilidades, amenazas y accesos no autorizados para que las organizaciones puedan garantizar la confidencialidad, integridad y disponibilidad de su aplicación y sus datos.

El objetivo principal de la seguridad de aplicación (AppSec) se centra en identificar y mitigar los riesgos que pueden surgir debido a fallas de diseño, errores de codificación o ataques maliciosos dirigidos a la aplicación. Al aplicar controles de seguridad durante todo el ciclo de vida de desarrollo de la aplicación, puede identificarlos y abordarlos lo antes posible para minimizar el impacto potencial en la seguridad.

En esencia, la seguridad de las aplicaciones es un problema de personas, procesos y tecnología.  Con demasiada frecuencia centramos nuestra atención en la parte tecnológica de AppSec, con la esperanza de que las herramientas y la automatización nos salven. Pero ¿qué pasa si las herramientas y la automatización son parte de la superficie de ataque de nuestra aplicación?

Para comprender y abordar este problema, primero debemos observar cómo ha evolucionado AppSec historicamente.

Entre 2005 y 2015, las organizaciones pasaron de las aplicaciones de escritorio a aplicaciones basadas en web. A medida que surgieron vulnerabilidades como secuencias de comandos entre sitios (XSS), inyección SQL y falsificación de solicitudes entre sitios (CSRF), la seguridad de las aplicaciones web se convirtió en un tema fuerte.

Para abordar estas nuevas vulnerabilidades, las herramientas de prueba de seguridad, como las pruebas de seguridad de aplicaciones estáticas (SAST), las pruebas de seguridad de aplicaciones dinámicas (DAST) y las pruebas de seguridad de aplicaciones interactivas (IAST), se volvieron más sofisticadas y populares.

Al mismo tiempo, la definición de AppSec se amplió más allá de las medidas de seguridad basadas en el perímetro para captar la necesidad de un enfoque de seguridad más proactivo y holístico. El proyecto OWASP Top 10 (https://owasp.org/www-project-top-ten/) reflejó estos cambios e incluyó nuevas vulnerabilidades. Las referencias inseguras a objetos directos (IDOR) y CSRF figuraron en la lista OWASP de 2007 (https://github.com/owasp-top/owasp-top-2007), por ejemplo.

La migración a la nube cambió significativamente la definición de AppSec.  Ahora abarca múltiples áreas: modelado de amenazas y diseño seguro, codificación segura, respuesta a incidentes y una gran cantidad de otras formas de pruebas de seguridad de aplicaciones.  Un componente central de AppSec, la implementación segura, experimentó una revisión completa.

Antes de 2015, la industria definía la implementación segura como la implementación de prácticas de implementación segura. Esto implicó la configuración segura de servidores y redes, la transmisión segura de datos y controles de acceso adecuados. Si bien la definición cumplió su propósito antes de que las organizaciones migraran a la nube, ahora necesitamos una nueva definición para modernizar las prácticas actuales y alejarnos de un enfoque obsoleto de implementación segura.

Pero ¿por qué necesitamos repensar cómo definimos la implementación segura?

En los entornos locales tradicionales, las organizaciones tenían control total sobre la pila de infraestructura, incluido el hardware, el sistema operativo y las capas de aplicaciones. Pero en la computación en la nube, los proveedores de servicios en la nube (CSP) y los usuarios de la nube operan dentro de un modelo de responsabilidad compartida.  El CSP asume la responsabilidad de proteger la infraestructura subyacente, mientras que el usuario de la nube sigue siendo responsable de proteger sus aplicaciones y datos.  Este cambio ha transformado AppSec en un esfuerzo conjunto entre el cliente y el CSP.

Debido a la naturaleza compartida de la infraestructura y los recursos, los entornos de nube introducen una nueva superficie de ataque.  Las aplicaciones y los datos del usuario de la nube pueden ser vulnerables a ataques que aprovechen configuraciones erróneas en el entorno de la nube o que se dirijan a otros inquilinos. AppSec ahora necesita abordar no sólo las vulnerabilidades tradicionales sino también las amenazas y riesgos específicos de la nube.

Para abordar estas nuevas amenazas específicas de la nube, debemos definir con precisión qué se considera una aplicación en nuestros entornos de nube modernos.

El objetivo de la AppSec moderna sigue siendo el mismo: garantizar que las aplicaciones de una organización cumplan con la tríada de la CIA. Esta tríada combina los tres principios clave de seguridad: confidencialidad, integridad y disponibilidad (el “A” del inglés Availability) de datos de alto valor, ya sean datos de los clientes o de la organización.

Desafortunadamente, la definición de “aplicación” no es tan clara. ¿Qué constituye una solicitud? ¿Es solo el código que escribimos o incluye las dependencias de terceros que los desarrolladores aprovechan para acelerar el tiempo de comercialización?

Cuando hablamos del ciclo de vida de una aplicación, tendemos a pasar por alto todo lo que no forma parte directamente de la aplicación. Nos olvidamos de las herramientas y la automatización (incluso de las personas) que crean y trasladan la “aplicación” tradicional desde su concepción a la nube.

Pero pasar por alto los componentes del ciclo de vida de las aplicaciones impide que las organizaciones adopten un enfoque moderno para AppSec en la nube.  Debido a que el panorama de amenazas en la nube ha cambiado drásticamente (con un aumento significativo de los ataques dirigidos a la cadena de de software), la forma en que definimos las aplicaciones también debe capturar el flujo completo de valor de esa aplicación.

En la práctica, a medida que protegemos una aplicación, debemos considerar cómo cada uno de sus componentes básicos, incluidas todas las dependencias de la aplicación, trabajan juntos para crear una aplicación única y valiosa. Los componentes básicos de una aplicación implican todo, desde código propietario y de terceros hasta las cuatro C de la seguridad nativa de la nube: el código, el contenedor, el clúster y la nube (cloud).

Pero a medida que buscamos modernizar nuestro enfoque de AppSec, necesitamos agregar una quinta “C”: el proceso de integración y entrega continuas (CI/CD).

Toda la infraestructura y el código de aplicación pasan a través de una canalización de CI/CD, comúnmente utilizada para optimizar el desarrollo y la implementación de aplicaciones. Un programa AppSec integrará la seguridad en este proceso aprovechando las pruebas de seguridad automatizadas, el análisis de código y las herramientas de escaneo de vulnerabilidades.

Los desarrolladores deben tratar la seguridad como código e incorporarla al proceso de desarrollo para que puedan detectar y abordar los problemas de seguridad en las primeras etapas del ciclo de vida del desarrollo. Además, la seguridad debe proteger el proceso de desarrollo. Tanto la edición OWASP Top 10 2021 (https://owasp.org/Top10/) como la OWASP Top 10 CI/CD Security Risks (https://owasp.org/www-project-top-10-ci-cd-security-risks/) describen los pasos que los profesionales de AppSec deben tomar para adoptar un enfoque más centrado en el riesgo para las debilidades de los canales y las configuraciones incorrectas de seguridad.

Para proteger sus pipelines de posibles vulnerabilidades, amenazas y accesos no autorizados, deberá adoptar varias prácticas recomendadas.

Controles de acceso seguros: asegúrese de implementar controles de acceso adecuados a sus herramientas, repositorios e infraestructura de CI/CD. Sólo las personas autorizadas deben tener acceso a los componentes de la tubería. También deberá aplicar mecanismos de autenticación sólidos, como la autenticación multifactor.

Integridad del código y los artefactos: el código y los artefactos que se implementan a través del proceso de CI/CD deben protegerse contra manipulaciones y modificaciones no autorizadas. Puede hacerlo implementando firma de código, verificación de suma de verificación, repositorios de artefactos seguros y otros mecanismos.

Gestión de configuración segura: aplique prácticas de configuración segura a los componentes de su canalización de CI/CD, incluidos servidores de compilación, sistemas de control de versiones y herramientas de implementación. Revise y actualice periódicamente las configuraciones para alinearlas con las mejores prácticas y pautas de seguridad.

Pruebas de seguridad automatizadas: integre pruebas de seguridad automatizadas en su canal de CI/CD para identificar vulnerabilidades y debilidades de seguridad en las primeras etapas del proceso de desarrollo. Esto puede incluir análisis de código estático, DAST, análisis de composición de software (SCA) y escaneo de vulnerabilidades.

Gestión de dependencias: administre y proteja las dependencias de terceros utilizadas en la aplicación. Actualice y parchee periódicamente las dependencias para mitigar las vulnerabilidades conocidas y reducir el riesgo de ataques a la cadena de suministro.

Gestión de secretos: maneje y proteja adecuadamente la información confidencial, como claves API, credenciales y claves de cifrado utilizadas en la canalización de CI/CD. Utilice mecanismos seguros de almacenamiento y cifrado para salvaguardar los secretos y minimizar el riesgo de acceso no autorizado.

Ahora que hemos ampliado nuestra definición de AppSec para incluir la protección de su canal de CI/CD, queda una pregunta. ¿Cómo abordaríamos la seguridad de las aplicaciones si pudiéramos empezar desde cero?

Veamos una analogía. Imagine que está construyendo un automóvil, es decir, una aplicación. Construir un automóvil es un proceso complejo que involucra a muchos ingenieros, diseñadores y especialistas en automatización que trabajan juntos para garantizar que el automóvil sea seguro y seguro para conducir. Pero no se puede conducir el automóvil si no se tienen carreteras bien pavimentadas, es decir, tuberías de CI/CD configuradas de forma segura.

Dado que se necesitan carreteras seguras para conducir un automóvil, ¿por qué construir el automóvil antes de construir las carreteras? E incluso si construimos el automóvil más seguro y las carreteras mejor pavimentadas, ¿nos hemos tomado el tiempo para asegurar nuestro destino, es decir, la nube?

La seguridad de las aplicaciones lo es todo, y todo es seguridad de las aplicaciones. Para proteger nuestras aplicaciones, debemos comenzar asegurando primero el pipeline (es decir, la carretera) y luego asegurando la nube (es decir, nuestro destino) para que podamos estar seguros de que el código de nuestra aplicación es seguro.

Proteger el pipeline delivery llega a ser tan importante como asegurar el software que se construye.

Con todo esto, sabemos que no es sencillo, pero es posible con metodologías, tecnologías, procesos y colaboración entre las áreas de DevOps, Seguridad, Negocios.  Pero esta colaboración es otro tema para otro artículo.

Espero haber colaborado para que su jornada hacia la nube empieza de forma segura desde el momento cero del desarrollo de su aplicación nativa.

¡Saludos y nos vemos pronto!

Marcos Nehme es actualmente Head para Latín América y El Caribe de Prisma Cloud en Palo Alto Networks.