Lumeta is now Cyber Asset Manager. Learn More

Something You Probably Should Include When Building Your Next Threat Models

We are working on our threat models here at DisruptOps, so I decided to refresh my knowledge of different approaches. One thing that quickly stood out is that nearly none of the threat modeling documentation or tools I’ve seen covers the CI/CD pipeline.

This. Is. A. Problem. Include your pipeline in your threat models.

Over the past few years I’ve performed a few dozen cloud security assessments directly, on top of a variety of other advisory work. I consistently include development/deployment pipelines within scope, and they are often where I see some of the larger security issues. Your super-secure cloud environment is a bit of a house of cards if someone can modify fundamental infrastructure by changing a template somewhere or by compromising stored keys.

Most threat models start with a data flow diagram or architecture, which you can use to walk through your app modeling threats (I like STRIDE myself, which comes from Microsoft). This covers application functionality but not the pipeline.

When using your threat model *du jour* for your pipeline, treat your developers/admins as users, and also treat the pipeline itself as a user if it has stored credentials (considering how it connects to your environment).

For example, can someone spoof an API call into Jenkins to trigger a change in your production application? (Probably, the way Jenkins is often configured). How about repudiation of job changes vs. code changes? Privilege escalation in the pipeline?

Pipelines don’t tend to withstand security scrutiny very well, so we will address them in future posts on security fundamentals. It probably won’t shock you to learn I tend to recommend guardrails on both pipeline deployments and any connected infrastructure to reduce risk. For example your CI server should never be publicly exposed or exposable. You could use reinforcing guardrails to ensure it is on a network segment without an Internet Gateway and that your security groups don’t allow public access (better yet, also ensure CI servers are always behind elastic load balancers).

The days of an application’s attack surface being limited to its components are long over. In the cloud most of our applications are fed by pipelines, which have tremendous potential to be a soft underbelly, thanks to deep access and stored credentials.

About the Author

You May Also Like

MSP Landscape, an interview with Steve Martinez

We sat down with FireMon’s MSP & Cloud Operations Strategic Account Executive, Steve Martinez to discuss the latest MSP landscape. Here’s how it went: 1. Could you tell us a little about yourself and your role? In total, I have been with FireMon about 17 years, over two tours and

Read More >

Get 9X Better

See how to get:

90% Efficiency Gain by automating firewall support operations

90%+ Faster time to globally block malicious actors to a new line

90% Reduction in FTE hours to implement firewalls

Schedule a Demo