Controles de DevSecOps

DevSecOps aplica seguridad de la innovación mediante la integración de procesos y herramientas de seguridad en el proceso de desarrollo de DevOps.

Dado que DevOps es una materia emergente con un alto grado de variaciones de proceso, para tener éxito con DevSecOps, lo más conveniente es comprender e integrar bien la seguridad en el proceso de desarrollo. La adición de seguridad debe comenzar con cambios de baja fricción en el código, los procesos de desarrollo y la infraestructura que hospeda la carga de trabajo. Céntrese primero en los cambios que tienen el mayor efecto positivo en la seguridad y, al mismo tiempo, imponga poca carga a las aptitudes y los procesos de DevOps.

En esta documentación, se revisa cada fase de un proceso de DevOps de integración continua y entrega continua (CI/CD) y qué controles de seguridad se recomienda integrar primero.

Planeamiento y desarrollo

Normalmente, el desarrollo moderno sigue una metodología de desarrollo ágil. Scrum es una implementación con una metodología ágil en la que cada sprint se inicia con una actividad de planeamiento. La introducción de la seguridad en esta parte del proceso de desarrollo debe centrarse en lo siguiente:

• Modelado de amenazas para ver la aplicación desde la perspectiva de un posible atacante
• Complementos de seguridad del IDE y enlaces previos a la confirmación para la comprobación de análisis estáticos ligeros dentro de un entorno de desarrollo integrado (IDE).
• Revisiones por homólogos y estándares de codificación seguros para identificar estándares de codificación de seguridad eficaces, procesos de revisión por homólogos y enlaces previos a la confirmación.

No es obligatorio agregar todos estos pasos. Pero cada paso ayuda a revelar problemas de seguridad temprano, cuando son mucho más baratos y más fáciles de corregir.

Modelado de amenazas

El modelado de amenazas es, sin duda, la práctica de seguridad más importante. Ofrece resultados inmediatos y ayuda a establecer una mentalidad de seguridad en los desarrolladores para mejorar la seguridad en todos sus proyectos futuros.

El modelado de amenazas es un concepto sencillo, aunque puede ser detallado y técnico si es necesario. El modelado de amenazas muestra y documenta una vista de seguridad realista de la aplicación que incluye lo siguiente:

• Cómo los atacantes pueden abusar del diseño de la aplicación
• Cómo corregir vulnerabilidades
• Lo importante que es corregir las incidencias

El modelado de amenazas le permite adoptar de forma eficaz la misma mentalidad de un atacante. Le permite ver la aplicación desde los ojos de un atacante. Aprenderá a bloquear los intentos antes de que los atacantes puedan hacer algo al respecto. Si el equipo tiene roles de usuario en el diseño, puede tratar al atacante como un rol de usuario malintencionado.

Hay enfoques publicados para el modelado de amenazas que van desde métodos sencillos de preguntas y respuestas hasta análisis detallados basados en herramientas. Puede basar su enfoque en metodologías como el modelo STRIDE o el modelo de amenazas de OWASP.

Modelado de amenazas: empieza por algo simple

Dado que algunos enfoques para el modelado de amenazas pueden ser lentas y requerir mucha aptitudes, se recomienda comenzar con un enfoque más sencillo basado en preguntas básicas. Los métodos más sencillos no son tan exhaustivos, pero inician el proceso de reflexión crítico y le ayudan a identificar rápidamente los principales problemas de seguridad.

Los siguientes métodos de preguntas simples le ayudarán a empezar:

• Método de preguntas sencillas de Microsoft: este método plantea preguntas técnicas específicas diseñadas para que se expongan errores comunes de diseño de seguridad.
• Modelado de amenazas de OWASP: este método se centra en hacer preguntas sencillas y no técnicas para iniciar el proceso de modelado de amenazas.

Puede usar cualquiera de estos enfoques o ambos, en función de lo que sea más conveniente para el equipo.

Cuando el equipo se sienta más cómodo con el proceso, puede aplicar técnicas más avanzadas del ciclo de vida de desarrollo de seguridad de Microsoft. Además, pueden integrar herramientas de modelado de amenazas como la herramienta de modelado de amenazas de Microsoft para obtener más información y ayudar a automatizar el proceso.

Otro recurso útil es la guía para desarrolladores sobre el modelado de amenazas.

Complementos de seguridad del IDE y enlaces previos a la confirmación

Los desarrolladores se centran en la velocidad de entrega, y los controles de seguridad pueden ralentizar el proceso. Normalmente, la ralentización se produce si las comprobaciones de seguridad se inician en la canalización. Un desarrollador detecta la posible vulnerabilidad después de insertar el código en el repositorio. Para acelerar el proceso y proporcionar comentarios inmediatos, merece la pena agregar pasos, como complementos de seguridad del IDE y enlaces previos a la confirmación.

Los complementos de seguridad del entorno de desarrollo integrado (IDE) identifican diferentes problemas de seguridad durante el proceso de desarrollo en el entorno de desarrollo integrado (IDE) con el que está familiarizado. Los complementos pueden proporcionar comentarios inmediatos si hay un riesgo de seguridad potencial en el código escrito del desarrollador. Los complementos también pueden revelar riesgos en la biblioteca o el paquete de terceros. Según el IDE que elija, muchas empresas de seguridad proporcionan muchos complementos comerciales o de código abierto.

Otra opción que merece la pena tener en cuenta es usar un marco de confirmación previa si el sistema de control de versiones lo permite. Un marco de confirmación previa proporciona scripts de enlace de Git que ayudan a identificar problemas antes de que el desarrollador envíe el código para su revisión. Un ejemplo es la confirmación previa que puede configurar en GitHub.

Revisión por homólogos y estándares de codificación seguros

Las solicitudes de incorporación de cambios son un estándar en el proceso de desarrollo. Parte del proceso de solicitud de incorporación de cambios son las revisiones por homólogos que suelen detectar defectos, errores o problemas no identificados relacionados con errores humanos. Es un procedimiento recomendado tener un compañero del equipo de seguridad experto o un experto en seguridad que pueda guiar al desarrollador durante el proceso de revisión por homólogos antes de crear una solicitud de incorporación de cambios.

Las directrices de prácticas de codificación segura ayudan a los desarrolladores a aprender los principios esenciales de codificación segura y cómo se deben aplicar. Hay prácticas de codificación segura disponibles, como las prácticas de codificación segura de OWASP para incorporar con las prácticas de codificación generales.

Confirmación del código

Normalmente, los desarrolladores crean, administran y comparten su código en repositorios como GitHub o Azure Repos. Este enfoque proporciona una biblioteca central de código controlada por versiones en la que los desarrolladores pueden colaborar fácilmente. Sin embargo, habilitar muchos colaboradores en un único código base también tiene el riesgo de que se introduzcan cambios. Ese riesgo puede provocar vulnerabilidades o la inclusión involuntaria de credenciales o tokens en las confirmaciones.

Para abordar este riesgo, los equipos de desarrollo deben evaluar e implementar una funcionalidad de exploración del repositorio. Las herramientas de examen de repositorios realizan análisis de código estáticos en el código fuente dentro de los repositorios. Las herramientas buscan vulnerabilidades o cambios en las credenciales y marcan los elementos encontrados para su corrección. Esta funcionalidad sirve de protección frente a errores humanos y es una medida de seguridad útil para los equipos distribuidos en los que muchas personas colaboran en el mismo repositorio.

Administración de dependencias

Hasta el 90 % del código de las aplicaciones actuales contiene elementos de paquetes y bibliotecas externos o se basa en ellos. Con la adopción de dependencias en el código fuente, es esencial abordar los posibles riesgos. Muchas bibliotecas de terceros tienen problemas de seguridad graves. Además, los desarrolladores no siguen de forma coherente el mejor ciclo de vida ni mantienen actualizadas las dependencias.

Asegúrese de que el equipo de desarrollo sepa qué componentes incluir en sus aplicaciones. Querrán descargar versiones seguras y actualizadas de orígenes conocidos. Y querrán tener un proceso para mantener actualizadas las versiones. El equipo puede usar herramientas como el proyecto Dependency-Check de OWASP, WhiteSource y otras.

No basta con centrarse únicamente en las vulnerabilidades de dependencias o en su ciclo de vida. También es importante abordar la seguridad de las fuentes de paquetes. Hay vectores de ataque conocidos que se dirigen a los sistemas de administración de paquetes: typosquatting, poner en peligro los paquetes existentes, ataques de sustitución y otros. Por lo tanto, la administración responsable de la gestión de paquetes debe abordar estos riesgos. Para obtener más información, consulte Tres formas de mitigar el riesgo al usar fuentes de paquetes privadas.

Pruebas de seguridad de aplicaciones estáticas

Después de que el equipo aborde las bibliotecas de terceros y la administración de paquetes, es esencial cambiar el foco y mejorar la seguridad del código. Hay varias maneras de mejorar la seguridad del código. Puede usar complementos de seguridad del entorno de desarrollo integrado. O bien, puede conectar las comprobaciones de confirmación y confirmación previa incrementales de análisis estáticos como se ha descrito antes. También es posible realizar una exploración completa del código fuente para detectar los errores no identificados en los pasos anteriores. Es necesario, pero puede tardar horas o incluso días en examinar un bloque de código grande. Por lo que este enfoque puede ralentizar el desarrollo e imponer cargas.

Pero un equipo debe empezar en algún lugar para implementar prácticas de examen de código estático. Una manera es introducir el análisis de código estático dentro de la integración continua. Este método comprueba la seguridad en cuanto se realizan los cambios. Un ejemplo es SonarCloud, que incluye varias herramientas de pruebas de seguridad de aplicaciones estáticas (SAST) para distintos lenguajes. SonarCloud valora las deudas técnicas y hace un seguimiento centrándose en el mantenimiento. Examina la calidad y el estilo del código y tiene comprobadores específicos de la seguridad. Pero hay muchas otras herramientas comerciales y de código abierto disponibles en el mercado.

Para asegurarse de que el bucle de comentarios sea eficaz, es fundamental retocar la herramienta. Quiere minimizar los falsos positivos y proporcionar comentarios claros y accionables sobre los problemas para solucionarlos. Además, es conveniente implementar un flujo de trabajo, lo que impide que el código se confirme en la rama predeterminada si hay resultados. Quiere cubrir tanto los resultados de calidad como los de seguridad. De esta manera, la seguridad se convierte en una parte de la experiencia de las pruebas unitarias.

Protección de las canalizaciones

DevOps lleva la automatización a otro nivel porque todo el ciclo de vida de desarrollo pasa por una canalización. La integración continua y la entrega continua (CI/CD) son una parte muy importante de los ciclos de desarrollo moderno. En CI/CD, el equipo combina el código de desarrollo en un código base central según una programación periódica y, después, ejecuta automáticamente procesos de compilación y prueba estándar.

Las canalizaciones de infraestructura son una parte central del desarrollo. Pero el uso de canalizaciones para ejecutar scripts o implementar código en entornos de producción puede presentar desafíos de seguridad únicos. Quiere asegurarse de que las canalizaciones de CI/CD no se conviertan en vías para ejecutar código malintencionado, permitir que se roben las credenciales o proporcionar a los atacantes cualquier área expuesta para el acceso. También quiere asegurarse de que solo se implementa el código que su equipo pretende publicar.

Los equipos de DevOps deben asegurarse de que implementan los controles de seguridad adecuados para la canalización. En función de la plataforma elegida, hay diferentes directrices sobre cómo abordar los riesgos. Para más información, vea Protección de Azure Pipelines.

Compilación y prueba

Muchas organizaciones usan canalizaciones de compilación y versión para automatizar y estandarizar los procesos de compilación e implementación de código. Las canalizaciones de versión permiten a los equipos de desarrollo realizar cambios iterativos en secciones de código rápidamente y a escala. Los equipos no tendrán que dedicar grandes cantidades de tiempo a volver a implementar ni actualizar entornos existentes.

El uso de las canalizaciones de versión también permite a los equipos promover el código desde los entornos de desarrollo, a través de entornos de prueba y, en última instancia, en producción. Como parte de la automatización, los equipos de desarrollo deben incluir herramientas de seguridad que ejecuten pruebas automatizadas con scripts cuando se implementa código en los entornos de prueba. Las pruebas deben incluir pruebas unitarias en las características de la aplicación para comprobar si hay vulnerabilidades o puntos de conexión públicos. Las pruebas garantizan el acceso intencionado.

Pruebas de seguridad de aplicaciones dinámicas

En un modelo de desarrollo en cascada clásico, la seguridad se introdujo normalmente en la última fase, justo antes de pasar a producción. Uno de los enfoques de seguridad más populares son las pruebas de penetración. Las pruebas de penetración permiten a un equipo examinar la aplicación desde una perspectiva de seguridad de caja negra, lo más cercano a la mentalidad de un atacante.

Una prueba de penetración consta de varios puntos de acción, y uno de ellos son las pruebas de seguridad de aplicaciones dinámicas (DAST). DAST es una prueba de seguridad de aplicaciones web que detecta problemas de seguridad en la aplicación en ejecución al ver cómo responde la aplicación a solicitudes diseñadas especialmente. Las herramientas de DAST también se conocen como detectores de vulnerabilidades de aplicaciones web. Un ejemplo es una herramienta de código abierto, Zed Attack Proxy (ZAP) de OWASP. Encuentra vulnerabilidades en la aplicación web en ejecución. Hay distintas maneras en las que ZAP de OWASP examina: examen de línea de base pasiva o examen completo en función de la configuración.

La desventaja de las pruebas de penetración es que son lentas. Una prueba de penetración exhaustiva puede tardar hasta varias semanas y, con la velocidad del desarrollo de DevOps, ese período de tiempo podría ser insostenible. Sin embargo, todavía merece la pena agregar una versión más ligera de las pruebas de penetración durante el proceso de desarrollo para incidencias que SAST y los pasos anteriores podrían haber pasado por alto. Las herramientas DAST como ZAP de OWASP pueden ayudar.

Los desarrolladores integran ZAP de OWASP en la canalización como una tarea. Durante la ejecución, el escáner ZAP de OWASP se pone en marcha en el contenedor y realiza su examen y, a continuación, publica los resultados. Este enfoque podría no ser perfecto, ya que no es una prueba de penetración completa, pero sigue siendo valiosa. Es una medida de calidad más en el ciclo de desarrollo para mejorar la posición de seguridad.

Validación de la configuración de la nube y examen de la infraestructura

Además de examinar y proteger el código de las aplicaciones, asegúrese de que los entornos en los que implementa las aplicaciones también son seguros. Los entornos seguros son clave para las organizaciones que desean moverse a buen ritmo, innovar y usar nuevas tecnologías. Los entornos seguros también ayudan a los equipos a crear nuevos entornos rápidamente para la experimentación.

Las funcionalidades de Azure permiten a las organizaciones crear estándares de seguridad a partir de los entornos, como Azure Policy. Teams puede usar Azure Policy para crear conjuntos de directivas. Los conjuntos de directivas impiden la creación de determinados tipos de carga de trabajo o elementos de configuración, como direcciones IP públicas. Estos límites de protección permiten a los equipos experimentar en un entorno seguro y controlado, equilibrando la innovación y la gobernanza.

Una de las formas en que DevOps puede ayudar a juntar a los desarrolladores y las operaciones es admitir la conversión de la infraestructura existente en un enfoque de infraestructura como código.

Infraestructura como código (IaC) es la administración de la infraestructura (redes, máquinas virtuales, equilibradores de carga y topología de conexión) en un modelo descriptivo. IaC usa el mismo modelo de control de versiones que el equipo de DevOps usa para el código fuente. Al igual que el principio de que el mismo código fuente genera el mismo archivo binario, los modelos de IaC genera el mismo entorno cada vez que se aplica. IaC es una práctica clave de DevOps que se usa con la entrega continua.

DevSecOps desplaza la seguridad a la izquierda y muestra que la seguridad no se trata solo de la seguridad de las aplicaciones, sino también de la seguridad de la infraestructura. Una de las formas en que DevSecOps admite la seguridad de la infraestructura es incluir el examen de seguridad antes de que la infraestructura se implemente en la nube. A medida que la infraestructura se convirtiera en código, aplicaría las mismas acciones de seguridad a la infraestructura que a la seguridad de la aplicación. Hay herramientas de seguridad disponibles para ejecutar el examen de seguridad de la infraestructura en función de la estrategia de IaC elegida.

Con la adopción de la nube, la contenedorización es un enfoque popular que los equipos toman en las decisiones de la arquitectura de aplicaciones. Algunos de los repositorios de contenedores analizan imágenes para detectar paquetes con las vulnerabilidades conocidas. Todavía existe el riesgo de que un contenedor tenga software desactualizado. Debido a este riesgo, es fundamental examinar el contenedor en busca de riesgos de seguridad. Hay muchas herramientas de seguridad comerciales y de código abierto destinadas a esta área y que admiten una firme integración en el proceso de implementación continua. Las herramientas de seguridad ayudan a los equipos a adoptar DevSecOps para la infraestructura como código y, más específicamente, aprender a usar contenedores.

Entrega en producción y operaciones

Cuando la solución va a producción, es fundamental seguir supervisando y administrando el estado de seguridad. En esta fase del proceso, es el momento de centrarse en la infraestructura en la nube y la aplicación en general.

Examen de la configuración y la infraestructura

Para obtener visibilidad de las suscripciones en la nube y la configuración de recursos en varias suscripciones, use la solución de seguridad de inquilinos de Azure del equipo de AzSK.

Azure incluye funcionalidades de supervisión y seguridad. Estas funcionalidades detectan y notifican cualquier evento o configuración anómalo que precisa de una investigación y una posible corrección. Tecnologías como Microsoft Defender for Cloud y Microsoft Sentinel son herramientas propias que se integran de forma nativa en los entornos de Azure. Estas tecnologías complementan las herramientas de seguridad del entorno y del código. Además, las tecnologías proporcionan una supervisión exhaustiva de la seguridad para que las organizaciones puedan experimentar e innovar de forma rápida y segura.

Pruebas de penetración

Las pruebas de penetración son una práctica recomendada para que comprobar si hay vulnerabilidades en la configuración de la infraestructura o de la aplicación que puedan crear puntos débiles que los atacantes puedan aprovechar.

Muchos productos y asociados ofrecen servicios de pruebas de penetración. Microsoft proporciona instrucciones para las pruebas de penetración en Azure.

Las pruebas suelen abarcar los siguientes tipos de prueba:

• Pruebas en los puntos de conexión para detectar vulnerabilidades
• Pruebas de vulnerabilidad con datos preparados (búsqueda de errores del programa al proporcionar datos de entrada con formato incorrecto) de los puntos de conexión
• Exploración de puertos de los puntos de conexión

Inteligencia que requiere acción

Las herramientas y técnicas de esta guía ofrecen un modelo de seguridad holístico para las organizaciones que desean trabajar a buen ritmo y experimentar con nuevas tecnologías que pretenden impulsar la innovación. Un elemento clave de DevSecOps son los procesos controlados por datos y por eventos. Estos procesos ayudan a los equipos a identificar, evaluar y responder a posibles riesgos. Muchas organizaciones eligen integrar alertas y datos de uso en su plataforma de administración de servicios de TI (ITSM). A continuación, el equipo puede traer el mismo flujo de trabajo estructurado a los eventos de seguridad que usan para otros incidentes y solicitudes.

Bucles de comentarios

Todas estas técnicas y herramientas permiten a los equipos buscar y marcar los riesgos y las vulnerabilidades que requieren una investigación y una posible resolución. Los equipos de operaciones que reciben una alerta o detectan un posible problema cuando investigan una incidencia de soporte técnico necesitan una ruta de vuelta al equipo de desarrollo para marcar los elementos para su revisión. Un bucle de comentarios fluido y colaborativo es fundamental para abordar los problemas rápidamente y minimizar el riesgo de una vulnerabilidad en la medida de lo posible.

Un patrón común para los comentarios es integrarlos en un sistema de administración del trabajo de desarrolladores, como Azure DevOps o GitHub. Una organización puede vincular alertas o incidentes a elementos de trabajo para que los desarrolladores planeen y actúen. Este proceso proporciona una manera eficaz para que los desarrolladores resuelvan problemas dentro de su flujo de trabajo estándar, incluido el desarrollo, las pruebas y la versión.