La Metodología DevSecOps
¿Qué hace que DevOps sea diferente? Lo primero es la velocidad: La filosofía DevOps eleva los principios de las metodologías ágiles a un nuevo nivel de velocidad, aumentando enormemente el ratio con el que se publica código fuente en los repositorios e incrementando también los posteriores despliegues a producción. La adopción de herramientas de integración contínua, como por ejemplo Jenkins, facilita incluso despliegues más rápidos. Los ciclos de lanzamiento de una aplicación han pasado de “unos cuantos despliegues al año” a “despliegues semanales” (o incluso más frecuentes).
Lo segundo es la escalabilidad: DevOps soporta sistemas con cientos (o miles) de aplicaciones creadas por cientos de desarrolladores, que se ejecutan en docenas de servidores que pueden incrementarse de 10 a 100 en apenas segundos.
Cuando la velocidad y escalabilidad se convierten en un factor tan importante, los equipos de desarrollo responden introduciendo tantas optimizaciones como sean necesarias para eliminar los cuellos de botella que surgen en el Ciclo de Vida del Desarrollo de Software; también llamado SDLC. Muy a menudo, las actividades relacionadas con la seguridad en el SDLC son desvalorizadas o pasadas por alto. Sin embargo, no podemos culparnos por “rendirnos” tras ver un informe con cientos de falsos positivos generada por alguna que otra herramienta de revisión de código.
¿Qué es DevSecOps/SecDevOps?
DevSecOps, también conocida como SecDevOps, es una filosofía de desarrollo de software que promueve la adopción de la seguridad en todo el ciclo de vida del desarrollo de software (SDLC). DevSecOps va más allá de ser una herramienta o una práctica en concreto; favoreciendo la automatización de la seguridad, la comunicación y la escalabilidad. Este enfoque en la filosofía del desarrollo de software incluye a todos los equipos involucrados en el SDLC, como son Desarrollo, Operaciones y Seguridad.
En el pasado, la evaluación y validación de la seguridad en las aplicaciones solo se realizaba al final del proyecto. Los ciclos de lanzamiento de releases eran largos (meses o incluso años), por lo que siempre se aplazaba la seguridad que, a pesar de no ser lo ideal, se podía gestionar hasta cierto punto. Sin embargo, la aceleración en los ciclos de lanzamiento de software ha hecho que este enfoque de desarrollo sea poco práctico e incluso inaplicable, quedándose totalmente obsoleto. Hoy en día es habitual desplegar nuevo código en producción semanalmente e incluso diariamente. Esto hace que la automatización de la seguridad y la escalabilidad sea un requisito indispensable y ya no puede ser algo opcional.
DevSecOps por tanto, favorece la inclusión de las actividades relacionadas con la seguridad en las aplicaciones al inicio de las etapas del desarrollo. En este sentido, la automatización resulta clave para adoptar esta metodología ágil. La concienciación y una buena cultura relacionada con la seguridad es sin duda prioritaria, pero algunas herramientas de “AppSec” hacen que la automatización de la seguridad sea más sencilla.
DevOps VS DevSecOps
DevOps es una metodología de ingeniería de software que unifica las actividades de Desarrollo y Operaciones, con el objetivo de facilitar la entrega continua de forma ágil. En general, los equipos que adoptan las prácticas de DevOps experimentan una sustancial mejoría en las métricas relacionadas con la productividad y el rendimiento, que dan como resultado un software de mejor calidad. Otros beneficios incluyen:
- Reduce el “Time-to-market”.
- Aumenta la estabilidad de las aplicaciones.
- Mayor agilidad para responder a cambios competitivos.
Además de los beneficios que aporta DevOps, DevSecOps introduce la automatización de la seguridad así como nuevos procesos que se incluyen dentro del flujo de DevOps. Por ejemplo, una de las implementaciones más básicas consiste en añadir elementos de DevSecOps al “pipeline” de Continuous Integration and Continuous Delivery (CI/CD).
DevSecOps no solo añade elementos de seguridad, sino que aplicada correctamente, hace de la seguridad una parte integral dentro de todo el proceso, desde el inicio hasta el final.
Como consecuencia, el equipo de seguridad se compromete mucho más con el resto de equipos que intervienen en el SDLC, incluyendo Desarrollo y Operaciones. Esto elimina fricción, ya que la tensión natural que existe entre velocidad y seguridad se comparte por todos los equipos.
Beneficios que aporta DevSecOps a la organización
Adoptar DevSecOps en la organización proporciona beneficios inmediatos. El primero es una mejora general del posicionamiento de la seguridad en las aplicaciones. DevSecOps favorece la identificación y mitigación temprana de riesgos, lo que se traduce en un mejor “time-to-market” y como resultado, una reducción de los costes en desarrollo.
Con el fin de poder adoptar la automatización de la seguridad en la cultura de empresa, recomendamos los siguientes pasos:
- Ciclos de desarrollo cortos y frecuentes.
- Incorporar la seguridad desde el principio.
- Aprovechar las tecnologías que fomentan la agilidad, como pueden ser contenedores o microservicios.
- Inculcar en la organización una cultura de colaboración proactiva entre los equipos involucrados en el SDLC.
- Automatizar la seguridad tanto como sea posible para facilitar un desarrollo ágil.
DevOps: Puntos Débiles relacionados con la Seguridad
Basándonos en nuestra experiencia con entornos DevOps, vemos los siguientes puntos débiles relacionados con la seguridad:
1. Ineficiente puesta a punto de herramientas estáticas (SAST) y falsos positivos.
Las herramientas SAST (también llamadas “Static AST”), son la solución más extendida en términos de detección de vulnerabilidades durante la fase de desarrollo. Sin embargo, éstas generan una alta tasa de falsos positivos que hace que muchos desarrolladores se frustren al ver los extensos y áridos informes generados por el SAST; acabando por ignorarlos. Como consecuencia, las herramientas SAST consumen tiempo de configuración y revisión para poder discernir entre los falsos positivos y las vulnerabilidades reales.
Las herramientas DAST (“Dynamic AST”) también son muy populares, pero la falta de visibilidad sobre el código fuente se traduce en una baja tasa de detección de vulnerabilidades (son capaces de detectar en torno al 18% de vulnerabilidades). Además, al no tener acceso al código fuente, las vulnerabilidades detectadas por un DAST no se pueden ubicar en el código (se pierde la trazabilidad) y por tanto muchas de ellas permanecen ocultas.
2. Falta de coordinación entre los equipos de Seguridad y Desarrollo.
En relación a la calidad del software, las cuestiones de seguridad suelen tratarse de forma separada. El equipo de Calidad o QA y los “pentesters” suelen proporcionar largos y estáticos informes que contienen toda la información relacionada con la seguridad. Como resultado, los desarrolladores deben verificar diferentes sistemas para revisar errores relacionados con la funcionalidad frente a los problemas de seguridad. Además, los desarrolladores tienden en general a resolver primero los errores relacionados con la funcionalidad, y después se centran en los problemas de seguridad. Esto se traduce en que muchos fallos de seguridad no se resuelven durante la fase de desarrollo. Una vez que un problema crítico de seguridad acaba en el entorno de producción, se tarda un promedio de 129 días en arreglarlo.
3. Despliegue de aplicaciones contínuo caótico.
Los equipos no tienen una forma eficiente de evaluar el nivel de seguridad de las aplicaciones, y como resultado, los problemas de seguridad acaban en el entorno de producción. Así como los errores de compilación del código fuente bloquean los “builds” en el proceso de integración contínua, no hay una forma automatizada de bloquear el despliegue a producción cuando existen fallos de seguridad. Como consecuencia, los equipos tienen que asegurarse manualmente de la política de seguridad, lo cual genera retrasos y/o despliegue de aplicaciones inseguras.
4. El “Pen-testing” manual se convierte en un cuello de botella.
Primero de todo, es importante destacar que las soluciones de detección (AST) solo detectan vulnerabilidades de que siguen un patrón común y son exactamente iguales en todas las aplicaciones. Ejemplos de este tipo de vulnerabilidades son “SQL injection”, “XSS”, etc.
Desafortunadamente, hay otro grupo importante de vulnerabilidades relacionadas con la lógica de negocio de las aplicaciones (business logic flaws) que no pueden ser detectadas por herramientas tradicionales (AST). Hablamos de vulnerabilidades del tipo “Access Control”, “Binding”, “Abuse”, etc.
Ante esta situación y visto que las herramientas de detección automáticas solo detectan errores de seguridad (el 50% del total), las compañías y organizaciones realizan pruebas manuales para detectar dichos errores de diseño. Las actuales metodologías ágiles, que realizan despliegues prácticamente cada día, no se adaptan correctamente a estas pruebas manuales. Incluso cuando el presupuesto no es un problema, estas pruebas manuales afectan de forma severa al “time-to-market” de las aplicaciones.
5. Poca visibilidad sobre el histórico de seguridad.
Los equipos no tienen herramientas inteligentes que les permitan monitorizar la evolución de la seguridad y las vulnerabilidades entre “build” y “build”. Muchos equipos no son conscientes del número, gravedad o tiempo que tienen las vulnerabilidades de las aplicaciones.
Arreglar los fallos de seguridad se convierte en algo prácticamente imposible, y además los equipos carecen de una forma clara para clasificar las vulnerabilidades por el grado de gravedad. Como resultado, los equipos pierden el tiempo arreglando fallos que no son vulnerables, dejando sin resolver los que sí lo son.
6. Falta de soporte para Cloud.
Los entornos en la nube no tienen un perímetro que pueda defenderse de ataques utilizando herramientas tradicionales, como por ejemplo los WAFs. Los proveedores de servicios en la nube o las condiciones de los despliegues pueden variar a lo largo del tiempo. La mayor parte de las herramientas de seguridad no son capaces de adaptarse a estos cambios.
Frecuentemente, la seguridad queda relegada a un escenario sin contexto claro y sin visibilidad sobre la aplicación. La información solo se revisa en un punto del proceso, lo cual limita la precisión del análisis de seguridad e introduce falsos positivos.
7. Los sistemas no escalan.
Estrategias de revisión externas con herramientas AST, como pueden ser las llamadas “testing-as-a-service”, provocan retrasos en la fase de despliegue, que se pueden demorar de 4 a 24 horas. Este retraso reduce la escalabilidad e incrementa el “time-to-market”. Una vez en producción, es muy común escalar de 10 servidores a 100 en cuestión de segundos. Los equipos de DevOps suelen quejarse de que las herramientas de seguridad son un cuello de botella y que carecen de flexibilidad para escalar de forma dinámica a medida que la carga de la aplicación aumenta.
DE DEVOPS A DEVSECOPS: LOS 7 PASOS CLAVE
La comunidad de “Application Security” reaccionó a estos retos y “pain-points”, tomando la filosofía de DevOps y añadiendo la capa de seguridad. El resultado de ello es DevSecOps.
DevSecOps trata de aumentar la velocidad y la productividad, introduciendo de forma estrecha la automatización y monitorización de la seguridad. DevSecOps aprovecha herramientas para securizar el SDLC, al mismo tiempo que no obstaculiza la cadencia de “releases”.
En próximos artículos profundizaremos sobre cada uno de estos 7 pasos clave, pero a continuación te mostramos una versión resumida de nuestra “receta” para implementar DevSecOps con éxito:
Pain Point 1: Ineficiente puesta a punto de los SAST y falsos positivos.
Solución: Utilizar una herramienta IAST
Muchos de los equipos de desarrollo de software carecen de expertos dedicados a la seguridad; como resultado, la seguridad suele implementarse por personas poco especializadas. La adopción de herramientas Application Security Testing (AST) permite a los desarrolladores crear código seguro.
Para evitar la falta de precisión y la extensa e intensa labor de revisión de los informes generados por un SAST, recomendamos la utilización de una herramienta de detección más precisa como es un IAST (“Interactive Application Security Testing”). Las herramientas IAST no requieren de una “puesta a punto” o revisiones manuales ya que no generan falsos positivos. Te recomendamos utilizar el indicador de cobertura de “OWASP Benchmark” para clasificar las diferentes soluciones.
Con la ayuda de una herramienta IAST no es necesario realizar la revisión del código manualmente ya que, con un IAST, la información de las vulnerabilidades se recibe en tiempo real. Una herramienta IAST ayuda a que la seguridad se verifique cuanto antes en el proceso de desarrollo (SDLC).
Pain Point 2: Falta de coordinación entre los equipos de Seguridad y Desarrollo
Solución: Integrar los fallos de seguridad en herramientas de colaboración (Jira, Asana, etc.)
Integra el sistema de seguimiento de errores (“bug tracker”) que tu equipo esté utilizando, por ejemplo Jira, con las herramientas de seguridad para que los desarrolladores puedan visualizar los errores de seguridad como tareas habituales. Crea nuevos errores y tareas que representen vulnerabilidades para que el equipo las verifique en las revisiones y auditorías de la aplicación.
El objetivo detrás de esta recomendación es que los desarrolladores no se alejen de su entorno de integración contínua o de las herramientas de implementación contínua que utilicen habitualmente [2]. Como resultado, se resuelven muchos más fallos de seguridad en la fase de desarrollo; mucho mejor que resolverlos en procesos posteriores.
Pain Point 3: Despliegue de aplicaciones continuo caótico
Solución: Definir métricas y umbrales para asegurar la calidad
De la misma forma que los errores de compilación paralizan el despliegue, los errores de seguridad también deberían hacerlo. Conocidos como “controles de seguridad” estos “checkpoints” aseguran que el código que llegue al CI/CD respete los estándares de seguridad.
Crea “checkpoints” automáticos de seguridad para cumplir los objetivos de calidad, y paraliza el “build” si el número de vulnerabilidades sobrepasa un límite. Busca soluciones que se integren con el servidor de despliegue (como puede ser Jenkins).
Es importante adaptarse al conocimiento y madurez que posee el equipo sobre seguridad, empezando por unos umbrales más flexibles y progresando poco a poco a umbrales más estrictos.
Pain Point 4: El “Pen-testing” manual se convierte en un cuello de botella
Solución: Automatizar la protección de errores en diseño o “business logic flaws”
Los “Business Logic Flaws”, (también conocidos como errores de diseño) son un importante grupo de problemas de seguridad que las herramientas de detección no son capaces de identificar. Para mitigar el cuello de botella que supone verificar manualmente estos errores, recomendamos automatizar la validación utilizando soluciones y arquitecturas que sean seguras desde el inicio. Es conveniente ayudar a los “pentesters” a enfocar sus esfuerzos en las secciones adecuadas de la aplicación. Los equipos de “pentesters” son más productivos cuando tienen una imagen clara de las zonas donde atacar.
Después, integra el resultado con las herramientas de auditoría. Si combinamos la automatización de la protección junto con las herramientas de auditoría, permitimos automatizar prácticamente todas las tareas manuales del “Pen-testing”.
Pain Point 5: Poca visibilidad sobre el histórico de seguridad
Solución: Mejorar el proceso de “reporting”
Se debe realizar un control de versiones en cada “release”, implementando métricas e informes que rastreen la evolución, el número y la severidad de las vulnerabilidades de cada lanzamiento. Es recomendable utilizar herramientas como Jenkins Reports o Web Reports y mejorar los informes incluyendo los fallos de seguridad.
Identifica las métricas que incrementen la productividad de los desarrolladores y soluciona primero las cuestiones más críticas. Es conveniente promover una cultura en el equipo, que incentive una progresiva reducción del número de fallos de seguridad así como celebrar cuando hay una clara mejoría. Artefactos relacionados con la infraestructura tales como “deployment descriptors” o “build scripts” deben estar sujetos a un riguroso control de versiones. Los análisis “post mortem” también deberían incluir informes con los problemas de seguridad que se han detectado.
Pain Point 6: Falta de soporte para Cloud
Solución: Integrar la seguridad
Crea aplicaciones incorporando siempre la seguridad de forma ágil. Las aplicaciones que han sido concebidas teniendo en cuenta la seguridad, pueden adaptarse fácilmente a los cambios (por ejemplo a un cambio de proveedor de Cloud o un cambio en las condiciones del despliegue).
Creemos que el mejor enfoque es lo que nosotros denominamos “security as code”, donde las vulnerabilidades en realidad son “defectos” en el código. Si incorporas cuanto antes la seguridad en el proceso de desarrollo, tus aplicaciones serán seguras desde el inicio y se mantendrán seguras siempre.
Pain Point 7: Los sistemas no son escalables
Solución: Escalabilidad lineal y costes asequibles
Asegúrate de que la infraestructura de seguridad de tu aplicación no es un cuello de botella en lo que a rendimiento se refiere. Busca soluciones de seguridad que puedan escalar de forma constante y lineal en el tiempo. Monitoriza la evolución del retraso que pueda ocasionar la herramienta de seguridad utilizada y escoge aquella que mejor rendimiento obtenga.
Ingeniero en Ciberseguridad por la Universidad Tecnológica de Chile, Speaker, Analista de Ciberinteligencia, Investigador y Redactor para CronUp Ciberseguridad.
