Controles de DevSecOps

DevSecOps es la aplicación de 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 conseguir unas operaciones de é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 impacto 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; sin embargo, cada uno de ellos ayuda a detectar los problemas de seguridad pronto, cuando son mucho más baratos y 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 desarrollar una mentalidad de seguridad en los desarrolladores que puede 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 desarrolla 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 estos problemas
• Lo importante que es corregirlos

El modelado de amenazas le permite adoptar de forma eficaz la misma mentalidad de un atacante. Permite ver la aplicación a través de sus ojos y puede bloquear su ataque antes de que el atacante pueda hacer algo por impedirlo. Si el equipo usa roles de usuario en el diseño, puede tratar al atacante como un rol de usuario malintencionado.

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

Modelado de amenazas: inicio sencillo

Dado que algunos enfoques para el modelado de amenazas pueden suponer la ejecución de un proceso lento que requiere mucha aptitudes, se recomienda comenzar con un enfoque más sencillo basado en preguntas básicas. Estos métodos más sencillos no son tan exhaustivos, pero inician el proceso de reflexión crítico e identifican rápidamente los principales problemas de seguridad.

Estas preguntas sencillas para el modelado de amenazas son ideales para empezar a trabajar:

• 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.

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

A medida que 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 e integrar herramientas de modelado de amenazas, como Microsoft Threat Modeling Tool, para obtener información más detallada y ayudar a automatizar el proceso.

Otro recurso útil es una 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 detectará la posible vulnerabilidad después de insertar el código en el repositorio. Para acelerar este 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 IDE identifican diferentes problemas de seguridad durante el proceso de desarrollo en la zona de confort del desarrollador, que es su entorno de desarrollo integrado (IDE). Los complementos pueden proporcionar comentarios inmediatos si hay un riesgo de seguridad potencial en el código escrito del desarrollador o en la biblioteca o el paquete de terceros incluidos. Según el IDE elegido, muchas empresas de seguridad disponibles en el mercado proporcionan muchos complementos comerciales o de código abierto.

Otro paso que merece la pena tener en cuenta es introducir 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 habilitan problemas de identificación antes de enviar el código para su revisión. Un ejemplo es la confirmación previa y se puede implementar 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 permiten detectar defectos, errores o problemas 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 incorporar y guiar al desarrollador durante la 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, como las prácticas de codificación segura de OWASP, disponibles e incorporadas 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 se puede colaborar fácilmente. Sin embargo, habilitar muchos colaboradores en un único código base también puede presentar 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 exploración de repositorios realizan análisis de código estático en el código fuente dentro de los repositorios y buscan vulnerabilidades o credenciales y marcan los elementos encontrados para la 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

Se sabe que hasta el 90 % del código de las aplicaciones actuales contiene paquetes y bibliotecas externos y 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 implementan de forma coherente el ciclo de vida adecuado y las mantienen actualizadas.

Los equipos de desarrolladores deben asegurarse de que saben qué componentes se incluyen en sus aplicaciones, asegurarse de que las versiones seguras y actualizadas se descargan de los orígenes conocidos y de que hay un proceso para mantenerlos actualizados. Esto se puede hacer con 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 a los sistemas de administración de paquetes: typosquatting, poner en peligro los paquetes existentes, ataques de sustitución y otros. Por lo tanto, los responsables de la administración de paquetes deben abordar esos riesgos. Para obtener más información, vea las notas del producto Tres formas de mitigar el riesgo al usar fuentes de paquetes privadas.

Pruebas de seguridad de aplicaciones estáticas

Una vez que se han abordado las bibliotecas de terceros y la administración de paquetes, es esencial cambiar el enfoque y mejorar el estado de seguridad del código escrito. Hay diferentes maneras de mejorar la seguridad del código, como usar complementos de seguridad del IDE y conectar comprobaciones de confirmación y confirmación previa de análisis estáticos incrementales que se han tratado anteriormente. También es posible realizar la exploración completa del código fuente para detectar algunos errores no identificados en los pasos anteriores. Es necesario, pero puede tardar horas o días en ejecutarse en un bloque de código grande. Este enfoque puede ralentizar el desarrollo e imponer cargas.

Es necesario empezar desde algún lugar cuando empiece a implementar prácticas de exploración de código estático. Una manera es introducir el análisis de código estático dentro de la integración continua para comprobar la seguridad en cuanto se realizan los cambios. Una de estas herramientas es SonarCloud, que incluye varias herramientas de pruebas de seguridad de aplicaciones estáticas (SAST) para distintos lenguajes. SonarCloud evalúa la deuda técnica y realiza un seguimiento de ella prestando especial atención al mantenimiento, como la calidad y el estilo del código, y tiene controles específicos de la seguridad. Hay muchas otras herramientas comerciales y de código abierto disponibles en un mercado.

Para asegurarse de que el bucle de comentarios es eficaz, es fundamental adaptar la herramienta para minimizar los falsos positivos y proporcionar comentarios claros y útiles sobre los problemas que se deben corregir. Además, es conveniente implementar el flujo de trabajo, lo que impide que el código se confirme en la rama predeterminada si hay resultados. Para resultados de calidad y 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 en el que todo pasa a través de las canalizaciones. La integración continua y la entrega continua son una parte muy importante del desarrollo moderno. La infraestructura es la razón por la que las canalizaciones son una parte fundamental del desarrollo y tienen las llaves del reino. Las canalizaciones presentan desafíos de seguridad únicos. Se pueden poner en peligro para ejecutar código malintencionado, se podrían robar credenciales de las canalizaciones o un atacante sin acceso a la producción podría modificar la canalización para lograr sus objetivos.

Los equipos de DevOps deben asegurarse de que se implementan los controles de seguridad adecuados para la canalización. En función de la plataforma elegida, hay diferentes directrices sobre cómo abordar esos 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. Este uso de las canalizaciones permite a los equipos de desarrollo realizar cambios iterativos en las secciones de código de forma rápida y a gran escala, sin necesidad de dedicar demasiado tiempo a reimplementar o actualizar los entornos existentes. El uso de las canalizaciones 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 esta automatización, los equipos de desarrollo deben incluir herramientas de seguridad que ejecuten pruebas automatizadas con scripts cuando implementen código en los entornos de prueba. La prueba debe incluir las pruebas como pruebas unitarias de las características de las aplicaciones para comprobar si hay vulnerabilidades o comprobar los puntos de conexión públicos para asegurarse de que se puede acceder a ellos intencionadamente.

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 o las pruebas de lápiz. La prueba de penetración es un paso importante, que permite observar la aplicación desde la perspectiva de seguridad de la caja negra, más cerca de la mentalidad del atacante. Una prueba de penetración consta de varios puntos de acción, y uno de ellos se conoce como 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. Una de ellas es un proxy Zed Attack Proxy (ZAP) de OWASP de código abierto, que detecta vulnerabilidades en la aplicación web en ejecución. Hay varias maneras en las que ZAP de OWASP realiza el examen: examen de línea de base pasiva o examen completo en función de la configuración.

El inconveniente de una prueba de lápiz es que lleva tiempo. La prueba de lápiz adecuada puede tardar hasta varias semanas y, con la velocidad de desarrollo de DevOps, se hace insostenible. Sin embargo, todavía merece la pena agregar una versión más ligera de la prueba de lápiz durante el proceso de desarrollo para descubrir lo que podría faltar en SAST y los pasos anteriores. Las herramientas DAST como ZAP de OWASP pueden ayudar. Los desarrolladores pueden integrar ZAP de OWASP en la canalización como una tarea. Durante la ejecución, el detector ZAP de OWASP se activa en el contenedor y realiza el proceso de examen después de publicar los resultados. Este enfoque podría no ser perfecto, ya que no se han completado las pruebas de penetración; sin embargo, es una puerta 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, es importante asegurarse de que los entornos en los que se implementan las aplicaciones también son seguros. Esto es clave para las organizaciones que desean moverse a buen ritmo, innovar y usar nuevas tecnologías o crear entornos rápidamente para la experimentación. Azure tiene funcionalidades que permiten a las organizaciones crear estándares de seguridad a partir de entornos, como Azure Policy, que se pueden usar para crear conjuntos de directivas que 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.

Uno de los aspectos de DevOps a la hora de acercar a los desarrolladores y las operaciones en cooperación es transferir la infraestructura a 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, empleando el mismo control de versiones que utiliza el equipo de DevOps 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 fundamental de DevOps y se usa junto con la entrega continua.

DevSecOps está mejorando la seguridad, y ya no solo se trata de la seguridad de las aplicaciones, sino también de la seguridad de la infraestructura. Uno de los pasos es introducir el examen de seguridad de la infraestructura antes de implementarla en la nube. A medida que la infraestructura se convirtió en código, fue posible aplicar las mismas acciones de seguridad que para la seguridad de las aplicaciones mostrada en los desafíos anteriores. Hay herramientas de seguridad que pueden realizar el examen de seguridad según la estrategia de IaC elegida.

Con la adopción de la nube, la contenedorización es un enfoque popular 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 contenga software desactualizado. Debido a este riesgo, es fundamental examinar el contenedor en busca de riesgos de seguridad. Hay muchas herramientas de seguridad comercial y de código abierto destinadas a esta área y que admiten una firme integración en el proceso de entrega continua. Estas herramientas ayudan a adoptar DevSecOps para la infraestructura como parte del código y de los contenedores específicamente.

Entrega en producción y operaciones

Cuando la solución se entrega en producción, es fundamental seguir supervisando y administrando el estado de seguridad. En esta fase, 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, se puede usar la solución de seguridad de inquilinos de Azure del equipo de AzSK.

Azure incluye funcionalidades de supervisión y seguridad diseñadas para detectar y notificar eventos o configuraciones anómalos que precisan de una investigación y una posible corrección. Tecnologías como Microsoft Defender for Cloud, Microsoft Defender for Cloud y Microsoft Sentinel son herramientas propias que se integran de forma nativa en los entornos de Azure. Estas herramientas complementan el entorno y las herramientas de seguridad de código para proporcionar un amplio conjunto de supervisión de seguridad, a fin de permitir que las organizaciones experimenten e innoven a buen ritmo y de forma segura.

Pruebas de penetración

Las pruebas de penetración son una práctica recomendada para que los entornos comprueben 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.

Hay muchos productos y asociados que proporcionan servicios de pruebas de penetración. Microsoft proporciona instrucciones para las pruebas de penetración en Azure.

Las pruebas típicas abarcan 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 pueden contribuir significativamente a 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 controlados por eventos que permiten que las tres funciones se ejecuten de forma eficaz para identificar y evaluar posibles riesgos y responder a ellos. Muchas organizaciones deciden integrar estas alertas y telemetría en su plataforma de Administración de servicios de TI (ITSM) con el fin de incorporar el mismo flujo de trabajo estructurado a los eventos de seguridad que usan para otros incidentes como 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 estos comentarios es integrarlo en el sistema de administración del trabajo para desarrolladores de la organización, como Azure DevOps o GitHub, para vincular alertas o incidentes a elementos de trabajo para que los desarrolladores planeen y realicen acciones. 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.