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:
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:
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:
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:
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: