Tema 3.1 - SecDevOps & DevSecOps

Introducción

En el mundo, diariamente diferentes empresas y/o compañías ponen en marcha aplicaciones de manera continua y automatizada bajo un concepto denominado DevOps, cuyo objetivo ayuda a desarrollar productos y servicios software de calidad, a un bajo costo y tiempos menores.

Su secreto, se centra principalmente en ser una metodología de desarrollo de software centrada en la comunicación, colaboración e integración entre desarrolladores y profesionales de IT como administradores de sistemas; lo que permite que los desarrolladores se centren solo en desarrollar, desplegando el sistema rápidamente; no obstante, es necesario que no se deje de lado la seguridad, factor que permite evitar o reducir el riesgo de amenazas y ataques que se pueden materializar por la existencia de vulnerabilidades, evitando así, millonarias pérdidas y afectación a las compañías y usuarios, por lo anterior, surgen los términos de SecDevOps y DevSecOps integrando la seguridad en los equipos de desarrollo y operaciones (DevOps).

¿Qué es DevSecOps y SecDevOps?

Como ya se había dicho DevSecOps y SecDevOps tienen en común su finalidad, la aplicación de prácticas de codificación seguras, están compuestas por las mismas abreviaturas de las palabras Development, Security and Operations y claramente estos no abandonan los ideales y la filosofía de su antecesor DevOps, no obstante, pese a las similitudes encontradas, ambos términos son diferentes.

DevSecOps nos indica que primero se realiza el desarrollo, validación de seguridad y finalmente se lleva a cabo la operación de despliegue, aplicando siempre algo de automatización, el proceso de verificación de seguridad se encarga de analizar el código tanto en su forma estática como dinámica, por medio de herramientas como: (Sonarqube, Fortify o Crucible), todos analizadores de código, responsables de verificar el cumplimiento de reglas definidas para el desarrollo del software; lo que significa que si algún desarrollador sube el código a los repositorios centrales, éste es leído por analizadores de código que darán un dictamen, que permitirá saber que tan bien está nuestro desarrollo a nivel modular, antes de fusionar los cambios en ambientes pre-productivos, o al hacer merge en una rama principal de GIT; además, debemos tener en cuenta cómo es la seguridad en la integración de la aplicación en módulos como bases de datos y APIs,  para hacerlo más rápido, se pueden utilizar aplicaciones como OWASP ZAP en aplicaciones web que se encargaran de hacer el análisis de seguridad.

Ahora, es el turno de SecDevOps, la seguridad aquí se debe anteponer al desarrollo, por lo que ésta debe estar presente al inicio de cada etapa del SDLC, de esta manera se combaten las vulnerabilidades en el código a través de Linters, ( herramientas incluidas en los IDEs para el desarrollo de software) . 

Los Linterns: Tienen como objetivo indicar en qué momento se está incurriendo en una mala práctica que desencadene a futuro una vulnerabilidad; entre los linters conocidos están el Sonarqube, ESLint y Sonarlint, estos linters son flexibles ante la presencia de modificaciones y adición de nuevas reglas.

Con todo lo anterior, encontramos que en DevSecOps no nos orientamos en el análisis del código, exhaustivamente desde la máquina donde surge; a diferencia de SecDevOps en el cual nos enfocamos en que lo construido, el código fuente sea mucho más confiable, por lo que trabajar con SecDevOps termina siendo una tarea bastante exhaustiva, pero con menos margen de error.

Sin embargo, aplicar estos conceptos en un mundo donde todo fluye rápidamente, es un tema bastante complejo, evidenciándose un desplazamiento de la seguridad al final del proceso de desarrollo y no durante éste como debería ser (Shif left), con la típica excusa de la falta de recursos y tiempo para dedicarle al tema de seguridad.

Algunos de los principios de SecDevOps o DevSecOps para reducir el ciclo tardío y mejorar cada uno de estos son:

• Todos los equipos comparten la misma responsabilidad por la seguridad.
•  La empresa debe establecer una guía o políticas de seguridad.
• Se debe integrar la seguridad en las etapas de planificación, análisis, diseño e implementación como también en las pruebas.
• Los procedimientos de seguridad tanto para el desarrollo como en las operaciones se automatizan siempre que sea posible.
• Los cambios en el código de aplicación están vinculados a los procedimientos y reglas de implementación.

Estas metodologías se pueden combinar con otras prácticas o modelos cuyo objeto sea reforzar la seguridad sin comprometer la agilidad. Los modelos más comunes serian:

1. Implementación de defensa en profundidad: consiste en segmentar la aplicación y su entorno en múltiples capas, cada una con controles de seguridad autónomos. Este modelo, diseñado por Microsoft muestra las prácticas necesarias para dar seguridad a un sistema o red de sistemas, se definen por capas, de esta forma si se llegara a filtrar una amenaza a alguna de ellas, el sistema de seguridad implementado en la siguiente capa puede mitigar los riesgos y evitaría que dicho ataque siga su transcurso normal.

El modelo expuesto, se encuentra representado en la siguiente imagen, donde se pueden observar las diferentes capas tenidas en cuenta

Cada capa requiere de la aplicación de acciones o estrategias de seguridad, por lo cual en la siguiente tabla se mostrarán algunas de ellas en las capas existentes

Nota: Es necesario resaltar que para asegurar el éxito en la aplicación de SecDevOps y DevSecOps se debe proceder por capas y no intentar cambiar de modelo repentinamente, además de involucrar a todos los empleados para evitar desequilibrios de seguridad.

Finalmente, solo por dejar una visión de la importancia de implementar estas metodologías, en el top 10 de OWASP se expone los riesgos de seguridad más críticos de las aplicaciones, ilustrados en la siguiente imagen, lo que nos debe llevar a reflexionar y buscar las mejores formas de desarrollar nuestras aplicaciones dando prioridad a su seguridad.