¿Qué hay de nuevo en DEVSECOPS?

El pasado 3 de Octubre participamos en el evento DevSecOps Leadership Forum, para poder compartir impresiones con otros interesados en el tema, ya que hace un año aproximadamente estuvimos trabajando en detallar prácticas asociadas a incorporar seguridad en todas las etapas del ciclo de desarrollo. Sacando una primera conclusión de lo que compartimos, vemos que DevOps está bastante extendido en gran parte de las compañías, aunque queda bastante camino por recorrer, y uno de los principales hándicap es la seguridad.

En gran parte de las compañías el equipo de seguridad se ve como un cuello de botella, como el equipo que paraliza los despliegues a entornos productivos porque no se han tenido en cuenta los requisitos de seguridad.

Uno de los temas principales que se mencionó en las diferentes charlas y en el que claramente estamos de acuerdo es que se debe de cambiar el paradigma actual:

• Hay que pensar en la seguridad de principio a fin y cuanto antes mejor.
• Todos los miembros del equipo que interviene en el desarrollo de un producto es responsable de la seguridad. Este punto es muy relevante a la hora de tomar decisiones.
• Hay que implementar de manera segura las decisiones y acciones de seguridad a misma escala que las de desarrollo y operaciones.

Un diagrama que solemos usar que representa bastante bien las diferentes etapas del ciclo de vida con algunas prácticas DevOps, muestra como la seguridad se debe considerar en todas y cada una de estas etapas:

Ilustración 1. Security into the DevOps

En el día a día vemos que las compañías invierten gran cantidad de recursos en seguridad, sin embargo seguimos leyendo noticias de ataques masivos, claramente algo no funciona:

• Se tiende a que se protejan las aplicaciones de los ataques externos pero se debe de tener en cuenta de que gran parte de los ciberataques se cometen también desde dentro. Además, las vulnerabilidades también están relacionadas con las aplicaciones, por lo que hay que pensar en la seguridad de manera más granular, desde las primeras etapas del desarrollo del software.
• Debemos incluir en el análisis de nuestra entrega de valor el impacto que tienen las directivas de seguridad, sobre todo teniendo en cuenta que el coste de solucionar vulnerabilidades crece cuanto más tarde aparezcan o las abordemos.

Equivocarse antes es equivocarse más barato, es algo que se lleva mencionando desde hace años, quien no ha oído hablar o incluso ha difundido el concepto de “Shift left Testing”, cuyo principal objetivo es no dejar las pruebas para el final. En esta línea, por qué no aplicar lo mismo a la seguridad, incorporar la seguridad desde etapas tempranas reducirá de manera notable el coste asociado a la identificación de bugs o vulnerabilidades detectadas. @Kizerv en su charla “Shift left (Sin perder el norte)”, inició con este gráfico que refleja el coste relativo para corregir defectos. Aunque parece un argumento sólido para poner medidas que nos ayuden a detectar defectos en etapas tempranas, no siempre es fácil de explicar y por eso es importante un cambio cultural en las organizaciones.

Ilustración 2. Relative Costs to Fix Software Defects (Source: IBM Systems Sciences Institute)

@Kizerv hizo hincapié en que en cada una de las fases se deben de realizar los ajustes correspondientes de seguridad. De esta manera nos estaremos protegiendo tanto de los ataques externos como de los internos. Como se refleja en la siguiente figura donde se reflejan algunas de las diferentes prácticas que se deberían incorporar:

• SAST = Static Application Security Testing.
• IAST = Interactive Application Security Testing.
• SCA = Software Composition Analysis.
• DAST = Dynamic Application Security Testing.

Ilustración 3. Prácticas de seguridad en el ciclo de vida de desarrollo de software por @Kizerv

Es imprescindible que cada una de las técnicas de seguridad utilizadas en cada una de las fases genere un reporte que puedan visualizar tanto los equipos de desarrollo como los de seguridad y solventar las posibles vulnerabilidades conjuntamente.

Revisando el diagrama mostrado en la charla, con el framework de prácticas DevSecOps que manejamos en NTT Data resultado del trabajo que hicimos hace un año, no parece que estuviéramos muy desencaminados. El punto clave que se vuelve a destacar es que en cada una de las fases del ciclo de vida se deben añadir las tareas asociadas con la seguridad, no se pueden dejar para el final.

Ilustración 4. Framework de referencia de Prácticas DevSecOps de NTT Data

En la fase de desarrollo es habitual utilizar los plugins de Análisis estático de código que proporcionan los diferentes IDEs y los equipos de desarrollo lo tienen interiorizado aunque, seguramente, sin darle la importancia que se merece.

Adicionalmente a realizar las validaciones de seguridad del propio código se deben de detectar las vulnerabilidades de las dependencias que se usen en la aplicación. Uno de los mensajes que se repitió en varias charlas es que normalmente el mayor número de vulnerabilidades de las aplicaciones que desarrollamos no están en las líneas de código que desarrolla el equipo, si no en librerías de terceros. Nadie en la sala se atrevió a levantar la mano para asegurar que su código no tenía librerías de terceros con vulnerabilidades conocidas.

Por tener una idea, el equipo de Sonatype mostró resultado de un análisis de vulnerabilidades sobre los paquetes o dependencias disponibles en algunos de los repositorios centrales con los que se integra Nexus y los números realmente eran impactantes, por ejemplo en JavaScript, el 51% de los componentes que se descargan tienen vulnerabilidades conocidas.

Ilustración 5. Slide presentación Security at DevOps Speed de Mitun Zavery

Para ello es recomendable consultar el listado de vulnerabilidades CVE existentes de las librerías de terceros que se están utilizando. El listado y descripción de las vulnerabilidades se pueden consultar en https://www.cvedetails.com/ y también se puede disponer de una descripción detallada en https://nvd.nist.gov.

Algunas medidas que se pueden tomar, que dan para otra entrada en el blog, son las siguientes:

• Usar herramientas de firma de código.
• Realizar revisiones automáticas de código.
• Enmascarar e encriptar los datos.
• Incluir seguridad en la invocación a las APIs mediantes cabeceras para identificar al consumidor de la misma.
• Utilizar herramientas de escaneo de vulnerabilidades.
• Automatizar pruebas de Pentesting junto con el resto de Test automatizados.

Como punto final nos gustaría destacar algunos de los mensajes que se mencionaron en el evento y que se deberían tener en cuenta para que la implantación de DevSecOps sea exitosa:

• Práctica y comunicación son claves para el éxito.
• DevSecOps no va sobre herramientas pero son necesarias unas herramientas correctas.
• La credibilidad y ser habilitadores en vez de pass/fail gates son nuestras armas. Según @Kizerv “False Positives are the evil!”. Los falsos positivos son problemáticos y hay que tratar de minimizarlos.
• No se deben aplicar Security Gates si no se está seguro de las reglas.
• Los informes de vulnerabilidad son recetas para desastres. Estos informes deben de vigiliarse bien, tanto la generación como la distribución, puesto que pueden dar pie a usarlos para explotar las vulnerabilidades dentro de la compañía.
• Shift to left ya no es una opción, hay que cambiar.