Pipeline y DevOps – Integrar seguridad y capacidad de auditoría 2

En el artículo anterior descubrimos las Best Practices en seguridad con DevOps, y hoy seguimos hablando de Pipeline seguro en entorno DevOps.

Pipeline seguro

La automatización de DevOps abarca todo el proceso. Desde el desarrollo y las pruebas de código hasta la configuración e implementación de la infraestructura.

Como hemos visto, necesitamos pasar a pensar en la seguridad como una idea de último momento a ser evaluada en cada paso del proceso.

“Asegurar las aplicaciones es un proceso continuo que abarca una infraestructura segura, diseñando una arquitectura con seguridad en capas, validación de seguridad continua y monitoreo de ataques.”

El objetivo es cambiar la conversación con el equipo de seguridad de “aprobar cada versión a aprobar el proceso de CI / CD” y tener la capacidad de monitorear y auditar el proceso en cualquier momento.

Para ello deberemos incorporar los mecanismos de seguridad en cada uno de los pasos del pipeline. También ser capaces de reaccionar a la identificación de posibles fallas, garantizando la entrega de valor seguro.

IDE y Pull Request

La validación comienza antes de que el desarrollador confirme su código. Las herramientas de análisis de código estático en el IDE proporcionan la primera línea de defensa para ayudar a garantizar que las vulnerabilidades de seguridad no se introduzcan en el proceso DevOps.

El proceso para ingresar código en un repositorio central debe tener controles para ayudar a evitar que se introduzcan vulnerabilidades de seguridad. El uso del control de código fuente de Git con políticas de ramas puede proporcionar esta validación. Esto se puede lograr a través de un pull request.

El pull request debe requerir una revisión del código, que es una verificación manual pero importante para identificar nuevos problemas que se están introduciendo en su código.

Junto con esta verificación manual, los commits deben estar vinculados a los ítems de trabajo para auditar el motivo por el que se realizó el cambio y requerir un proceso de build de integración continua (CI) para que el proceso sea exitoso antes de que se complete.

En el siguiente enlace se puede entender el proceso para el caso de Github. Asimismo para el caso de BitBucket.

Integración Continua

El build CI debe ejecutarse como parte del proceso de pull request (PR-CI) discutido anteriormente una vez que se complete el merge.

Por lo general, la diferencia principal entre las dos ejecuciones es que el proceso PR-CI no necesita realizar ningún proceso de empaquetado/almacenamiento en el build CI.

Estos build deben ejecutar pruebas de análisis de código estático para garantizar que el código sigue todas las reglas de mantenimiento y seguridad.

Varias herramientas pueden ser utilizadas para este fin. Owasp ofrece una buena lista en el siguiente enlace.

Otras dos validaciones tediosas o ignoradas son escanear paquetes de terceros para detectar vulnerabilidades y el uso de licencias OSS.

Para ello se pueden usar algunas de las siguientes herramientas de código libre.

Despliegue de aplicaciones a DEV y TEST

Una vez que se verifica la calidad del código y la aplicación se implementa en un entorno más bajo, como desarrollo o control de calidad, el proceso debe verificar que no haya vulnerabilidades de seguridad en la aplicación en ejecución.

Esto se puede lograr ejecutando una prueba de penetración automatizada contra la aplicación en ejecución para analizarla en busca de vulnerabilidades.

Existen diferentes niveles de pruebas que se clasifican en pruebas pasivas (Pasive Scan) y pruebas activas (Active Scan):

Pasive Scan

Analizan el sitio de destino tal como está, pero no intenta manipular las solicitudes para exponer vulnerabilidades adicionales.
Estos pueden ejecutarse rápidamente y, por lo general, son un buen candidato para un proceso de IC que desea completar en unos minutos.
En este ámbito destaca OWASP ZAP.

Active Scan

Se pueden usar para simular muchas técnicas que los hackers suelen usar para atacar sitios web.

Estas pruebas también se conocen como pruebas dinámicas o difusas. Porque a menudo las pruebas están probando una gran cantidad de combinaciones diferentes para ver cómo reacciona el sitio y verificar que no revela ninguna información.

Estas pruebas pueden durar mucho más tiempo y, por lo general, no se desea cortarlas una vez iniciadas. Por eso se suelen ejecutar cada noche como parte de una versión separada.

Validación de la infraestructura

Además de validar la aplicación, la infraestructura también debe validarse para verificar si hay vulnerabilidades.

Al usar la nube pública como Azure, AWS o Google, es fácil implementar la aplicación y la infraestructura compartida, por lo que es importante validar que todo se haya hecho de manera segura.

Por ejemplo, Azure incluye muchas herramientas para ayudar a informar y prevenir estas vulnerabilidades, como el Centro de seguridad y las Políticas de Azure. En la plataforma han configurado un escáner que puede garantizar que los puntos finales públicos y los puertos se hayan incluido en la lista blanca. De lo contrario, planteará un problema de infraestructura. Esto se ejecuta como parte del canal de la red para proporcionar una verificación inmediata. Pero también debe ejecutarse cada noche para garantizar que no haya recursos expuestos públicamente que no deban estarlo.

Reflexiones finales

Como hemos visto, incorporar la seguridad en un modelo DevOps implica tomar en consideración todos los elementos implicados en el pipeline de entrega de valor. Lo cual puede suponer un esfuerzo importante.

No obstante, podemos tomar ventaja del modelo en sí mismo. Ya que DevOps es holístico por definición, y apoyarnos en las buenas prácticas para lograr nuestro objeto. Para ello necesitaremos implicar casi seguramente al equipo de seguridad; estar al día en las herramientas de seguridad para cada paso del proceso y gestinarlas adecuadamente.

La seguridad en nuestra implementación debe ser un trabajo en marcha y con mejoras continuas, tal como enfatiza el modelo.