A lo largo del blog se va a presentar un caso genérico del ciclo completo formado por los tres ciclos. Decir de antemano que esta interpretación es susceptible de las características propias de la organización que lo emplee pudiéndose darse casos en que algunas fases de los ciclos estén intercambiadas o se hable únicamente de ciclo de integración y ciclo de despliegue.
Tiempos, Requerimientos de negocio y Seguridad
Desde que se identifica un nuevo requerimiento de negocio hasta que, finalmente, sea rentabilizado existe un tiempo de espera forzado por el ciclo de integración, entrega y despliegue. Estos ciclos poseen características propias y están formados cada uno de ellos por fases que involucran distintos Roles y Tecnologías.
Cada una de estas fases implican posibles vulnerabilidades que serán arrastradas a lo largo del ciclo y de no ser interceptadas de forma temprana no solo serán arrastradas a las siguientes fases, sino que su remediación será más compleja y en algunos casos deberá esperarse a que el ciclo completo termine, para, en la siguiente iteración, ser corregidas.
Desde el equipo de seguridad se deben tener en cuenta algunos factores a la hora de implementar los controles de seguridad correspondientes en cada una de las fases ya que un nuevo control implicara añadir tiempos al cómputo total del ciclo retrasando la entrada final de la funcionalidad en producción. Con esto en mente, el equipo de seguridad debe evaluar cada uno de los controles para no redundarlos y sobre todo no convertirse en Stopers porque si esto llega a suceder el control será sacado del ciclo y el riesgo podría aumentar de forma considerable.
Ciclo de Integración continua
El ciclo comienza con la fase de ticketing. Aquí el equipo de IT identifica las nuevas funcionalidades requeridas por negocio. Se genera un (o varios) tickets describiendo las ‘historias’ de las funcionalidades requeridas y se inicializa el ticket con estado OPEN. Los desarrolladores asignados al ticket modifican su estado a DESARROLLO (o similar). Es en esta fase donde generan el nuevo código en base a dichos requerimientos. Cuando el desarrollador sube los cambios al repositorio de código, se realizan test automáticos que aseguran que dichas modificaciones no afecten al funcionamiento completo del código. En caso de que las pruebas fallen los cambios no serán integrados y será notificado el problema de forma temprana. Si las pruebas son exitosas el nuevo código será almacenado en los repositorios a la espera de ser empaquetados.
Tabla 1 Tecnologías y roles que intervienen en el ciclo de integración continua
Controles de seguridad por fases
Ticket: En esta fase se debe realizar la identificación de requerimientos de seguridad que dependerán en gran medida de los intereses de la empresa (por ejemplo, PCI) y las leyes del país o zona (por ejemplo, GDPR). Además, es importante hacer un análisis del modelo de amenazas que implicaría dicha nueva funcionalidad.
Desarrollo: Es de vital importancia la concienciación y formación de los desarrolladores con técnicas de desarrollo seguro para evitar la inserción de código vulnerable y la generación de vectores de entrada tales como SQLi/XSS/ CSRF/DDoS etc. Por otra parte, es necesario implementar medidas que permitan controlar contraseñas, datos sensibles, secrets o tokens en los commits.
Test Code: Entran en juego los test automáticos que deben asegurar que el código que finalmente va a subirse al repositorio no es vulnerable realizando análisis satico del código. Es en esta fase, donde se puede realizar una identificación temprana de las vulnerabilidades arrastradas por las fases y arreglarlas o dar marcha atrás antes de que pasen al siguiente ciclo.
Ciclo de Entrega continua
Aquellos cambios que pasen los test de forma exitosas serán añadidos a la rama del repositorio que represente la nueva reléase. Esta nueva versión del código es unificada en un único artefacto, paquete o imagen junto con las librerías y paquetes necesarios. Para terminar este ciclo, si el empaquetado ha sido exitoso, el artefacto será alojado en un repositorio central generando un tag de la nueva reléase.
Tabla 2 Tecnologías y Roles que intervienen en el ciclo de entrega continua
Controles de seguridad por fases
Empaquetado: Al generar un nuevo artefacto, paquete o imagen se añaden nuevas vulnerabilidades introducidas por librerías, dependencias y configuraciones por lo que una vez generado deben realizarse escaneos de vulnerabilidades sobre dicho paquete de forma automática. Por Política es necesario especificar un umbral mínimo (véase cvss) que cada paquetización debe superar para que pueda pasar como nueva reléase. De lo contrario dará un fallo y será corregido.
Reléase: Al generar una nueva versión del software/aplicación y dejarla “congelada” para que sea posteriormente desplegada es fundamental garantizar la integridad de la versión por lo que un control de acceso y mecanismos fuertes de autentificación contra el registro serán la salvaguarda más apropiada.
Ciclo de Despliegue continuo
En este momento entran en juego los entornos de test y preproducción donde el código empaquetado es desplegado. En esta fase se evalúa el comportamiento de la “aplicación” como si estuviera en un entorno real y se hacen mediciones de QA. Si estas pruebas son exitosas finalmente el artefacto o paquete es desplegado en producción y las funcionalidades requeridas por negocio son apreciables por el cliente final. Este entorno de producción tiene sistemas de monitorización que permiten obtener feedback para desestimar, arreglar o generar nuevas funcionalidades.
Tabla 3 Tecnologías y Roles que intervienen en el ciclo de Despliegue
Controles de seguridad por fases
Despliegue/QA: Durante esta fase el paquete o imagen será desplegado en un entorno lo más similar posible a producción y cuando los secrets/tokens serán añadidos durante el despliegue. En el caso de usar dockers, por ejemplo, las imágenes serán empleadas para desplegar contenedores a las cuales se les harán la infección de secretos. Un KMS simplificará y centralizará el control de los datos sensibles que serán introducidos durante el despliegue. Una parte importante de este punto es el control de los permisos con los que la Solución final va a correr en el sistema. Esto evitará sorpresas con las elevaciones de privilegios. En caso de usar un orquestador como kubernetes puede controlarse mediante los SecurityContext en los yaml de deployment.
Será en esta fase donde se realizarán tareas de HackingEtico mediante herramientas clásicas (nmap, sqlmap, nikto, metasploit, empire etc.)
Producción: En esta fase estamos expuestos a cualquier posible atacante externo a través de internet, por lo que para evaluar la seguridad hay que actuar como lo haría una amenaza real. Entra en juego el ReadTeam. Aquí ya no hay escusas, “¡no lo hagas que se puede romper!”, porque si no lo hace tu propio equipo, lo harán otros en su lugar.
Monitorización: De forma simultánea a la fase de producción se encuentra la fase de monitorización. El BlueTeam emplea la centralización de logs para la generación de un SIEM donde poder identificar ataques (SQLi/XSS/ CSRF/DDoS) y poder reaccionar en tiempo real de ser necesario. De esta fase saldrán nuevos requerimientos de seguridad y conclusiones de los controles ya implementados.
______
Autor: Juan Gordo