Cómo apoyamos DevSecOps en Azure

Azure es la plataforma de computación en la nube pública de Microsoft. Siendo uno de los principales proveedores, superó a Amazon Web Services (AWS) y Google Cloud en crecimiento de adopción durante el 2021. Como tal, Azure ofrece herramientas y funcionalidades, así como infraestructura, almacenamiento y capacidad de procesamiento. Esto permite a empresas de todos los tamaños desarrollar aplicaciones escalables y ahorrar costos. Puesto que estas aplicaciones deben ser seguras, Azure cuenta con servicios que ayudan a los usuarios a seguir las buenas prácticas de DevSecOps.

A pesar de que algunas actividades de DevSecOps consisten en automatizar las pruebas y actualizaciones de seguridad, la tecnología por sí sola no es suficiente. El mismo Azure aconseja en el Microsoft cloud security benchmark (MCSB) que técnicas manuales como el red teaming y pentesting deben complementar el escaneo de vulnerabilidades para descubrir riesgos. Debería prestarse más atención a esto, ya que nuestros hackers éticos suelen encontrar configuraciones inseguras en los servicios en la nube. En este artículo del blog, hablamos sobre cómo Fluid Attacks apoya tu implementación de DevSecOps en Azure con técnicas manuales en combinación con pruebas de seguridad automatizadas.

Antes de pasar al tema principal de este post, abordemos primero un tema relevante: el modelo de responsabilidad compartida de seguridad en la nube (SRM, por sus siglas en inglés). No te distraeremos durante mucho tiempo. Todo lo que necesitas recordar es que Azure, como proveedor de servicios en la nube, será responsable de acciones como mantener la disponibilidad de sus servicios, la seguridad de la infraestructura física que los soporta y la incorporación de características de seguridad en sus soluciones.

Pero los usuarios también tenemos que ser conscientes de nuestras responsabilidades. Tenemos que proteger nuestro ambiente DevOps y desplegar aplicaciones seguras en la nube. Por lo tanto, tendremos que responsabilizarnos si no protegemos la cadena de suministro de software, no realizamos pruebas de seguridad continuas, no configuramos los servicios correctamente, etc. Para cumplir con esta responsabilidad, los usuarios debemos recurrir a DevSecOps en la nube.

La cultura DevSecOps busca unir a los equipos de desarrollo, seguridad y operaciones desde el inicio del desarrollo de software para construir apps más seguras. (Explicamos en otro artículo cómo implementar DevSecOps). En la nube, esta cultura requiere que los equipos presten atención lo antes posible a la configuración adecuada de los servicios en la nube y realicen pruebas de seguridad continuas de los archivos de infraestructura como código (IaC, por sus siglas en inglés) y las imágenes de contenedores, entre otras cosas. Este enfoque de mover la seguridad hacia la izquierda facilita y hace menos costoso resolver los problemas.

Para ayudar a sus usuarios a lograr DevSecOps, Azure ha proporcionado recomendaciones para automatizar la seguridad con sus productos, lo que además está en el centro del MCSB publicado en octubre de 2022, el cual es un cambio de marca del Azure Security Benchmark (ASB). Este recurso proporciona controles prescriptivos que ayudan a los usuarios a mejorar su ambiente multinube y la seguridad de las cargas de trabajo, datos y servicios en Azure.

Existen herramientas de DevSecOps en Azure para ayudar a implementar estos controles. De modo que, por ejemplo, los equipos de desarrollo pueden utilizar el servicio Azure Pipelines para CI/CD. Esta herramienta les permite compilar y agrupar código en contenedores, protegiendo así el ambiente del desarrollador, y tener control de versiones. Para abordar la cuestión de la protección de datos, redes y accesos, Azure ofrece el servicio Azure Key Vault para almacenar claves de API, certificados, tokens, contraseñas y otros secretos, y Azure Active Directory (Azure AD) para gestionar la identidad y el control de acceso.

A la hora de evaluar los riesgos, dos aspectos del MCSB merecen atención especial: la gestión de posturas y vulnerabilidades y la seguridad en DevOps. Estos son algunos controles que, en nuestra opinión, resumen las actividades de evaluación en estos dominios:

Si se tiene en cuenta el último control de la lista anterior, se puede ver que se queda corto un enfoque centrado únicamente en el uso de herramientas de seguridad Azure DevOps y otro software DevSecOps. Una razón importante es que las herramientas automatizadas arrojan resultados con tasas significativas de falsos positivos y falsos negativos. Se necesita trabajo manual para revisar los resultados e identificar problemas que una herramienta, por ejemplo, para SAST o DAST, no haría.

Sin ir más lejos: en nuestro State of Attacks de 2022, en el que mostramos los análisis de los resultados de las pruebas de seguridad de nuestros clientes a lo largo de un año, descubrimos que fueron solo nuestros hackers éticos, y no las herramientas, quienes detectaron todas las vulnerabilidades de gravedad crítica reportadas en los sistemas.

Como expertos en pentesting y red teaming, ahora te mostramos cómo podemos apoyar tu implementación de DevSecOps con estos enfoques.

Las pruebas de penetración se realizan mediante simulaciones de ataques reales, por ejemplo, utilizando ataques personalizados para eludir las defensas. Este es un excelente ejemplo de pruebas funcionales que exigen creatividad y un conocimiento de las técnicas de los autores de amenazas actuales que no puede lograrse mediante herramientas. (De hecho, sostenemos que no existen las pruebas de penetración "automatizadas"). Pero evaluar la aplicación desde el exterior no es la única forma de realizar pentesting. También existe la revisión manual del código fuente para encontrar problemas recurrentes como credenciales en el código fuente y errores de configuración de los servicios. Por lo tanto, te recomendamos que vayas más allá del consejo de las pruebas de penetración "regulares" y las conviertas en una actividad continua a lo largo del SDLC.

Utilizando nuestra solución de pentesting, puedes disfrutar de los siguientes beneficios:

Red teaming también es una simulación de ataques reales, pero se acerca aún más a la realidad. Por ejemplo, no se limita a las evaluaciones a nivel tecnológico, sino que también incluye pruebas a nivel propiamente humano. Esto forma parte de un enfoque holístico para averiguar la eficacia de las estrategias de prevención, detección y respuesta a los ataques de una organización. Por consiguiente, en red teaming, los ataques se realizan con el consentimiento de los directivos de la organización, pero la mayoría de las personas del equipo de respuesta a incidentes y los empleados no son conscientes de ello. Y otra característica que lo hace más realista es que el red team no se centra en encontrar todas las vulnerabilidades, sino que se fija objetivos específicos.

Utilizando nuestra solución de red teaming, además de los de nuestra solución de pentesting, puedes disfrutar de los siguientes beneficios:

Obtienes una visualización constantemente actualizada de todos los hallazgos en nuestra plataforma. En ella, trazamos un mapa de todos los activos digitales de tu organización y puedes realizar un seguimiento de su exposición al riesgo a lo largo del tiempo. También puedes ver las pruebas de explotación de vulnerabilidades técnicas, asignar su remediación a miembros de tu equipo, hablar con nuestros hackers para que te orienten y muchas otras cosas.

Ahora es el momento de comenzar Azure DevSecOps con Fluid Attacks. ¡Contáctanos!

¿No estás seguro? Disfruta de nuestras pruebas de seguridad automatizadas gratuitamente durante 21 días. Puedes cambiar de plan en cualquier momento para añadir pruebas de seguridad manuales.