Algo que probablemente debería incluir al construir sus próximos modelos de amenazas

Estamos trabajando en nuestros modelos de amenazas aquí en DisruptOps, así que decidí actualizar mis conocimientos sobre los distintos enfoques. Algo que destacó rápidamente es que casi ninguna de las herramientas ni de la documentación sobre modelado de amenazas que he visto cubre el pipeline de CI/CD.

Esto. Es. Un. Problema. Incluya su pipeline en sus modelos de amenazas.

En los últimos años he realizado personalmente algunas docenas de evaluaciones de seguridad en el cloud, además de diversos trabajos de asesoría. De manera constante incluyo los pipelines de desarrollo/despliegue dentro del alcance, y suelen ser donde veo algunos de los problemas de seguridad más grandes. Su entorno cloud súper seguro es un castillo de naipes si alguien puede modificar infraestructura fundamental cambiando una plantilla en algún lugar o comprometiendo llaves almacenadas.

La mayoría de los modelos de amenazas comienzan con un diagrama de flujo de datos o una arquitectura, que puede usar para recorrer su aplicación modelando amenazas (a mí me gusta STRIDE, que proviene de Microsoft). Esto cubre la funcionalidad de la aplicación, pero no el pipeline.

Al usar su modelo de amenazas *du jour* para su pipeline, trate a sus desarrolladores/administradores como usuarios, y trate también al pipeline mismo como un usuario si tiene credenciales almacenadas (considerando cómo se conecta a su entorno).

Por ejemplo, ¿puede alguien falsificar una llamada de API hacia Jenkins para desencadenar un cambio en su aplicación de producción? (Probablemente sí, por la forma en que Jenkins suele configurarse). ¿Y el repudio de cambios en los jobs frente a cambios en el código? ¿La escalada de privilegios en el pipeline?

Los pipelines no suelen resistir muy bien el escrutinio de seguridad, así que los abordaremos en futuras publicaciones sobre fundamentos de seguridad. Probablemente no le sorprenda saber que suelo recomendar barreras de protección tanto en los despliegues del pipeline como en cualquier infraestructura conectada para reducir el riesgo. Por ejemplo, su servidor de CI nunca debería estar expuesto ni ser expuesto públicamente. Podría usar barreras de protección reforzadas para asegurar que esté en un segmento de red sin un Internet Gateway y que sus grupos de seguridad no permitan el acceso público (mejor aún, asegure también que los servidores de CI estén siempre detrás de balanceadores de carga elásticos).

Los días en que la superficie de ataque de una aplicación se limitaba a sus componentes quedaron muy atrás. En el cloud, la mayoría de nuestras aplicaciones se alimentan de pipelines, que tienen un enorme potencial de ser un punto vulnerable, gracias a su acceso profundo y a las credenciales almacenadas.