A Framework for Secure DevOps & Cloud Adoption
This is the first in a series of posts that will outline a framework I’ve developed and successfully deployed for applying effective security to a DevOps environment.
Part 0 — Setting The Scene
Part 1 — Identity
Part 2 — Environment
Part 3 — Secure SDLC
Part 4 — Embedded Expertise
On my first day at a new client, I was introduced to the Project Manager and the Technical Lead for the implementation of an internal Platform-as-a-Service programme, and invited to a workshop to show off where they were up to. My brief was simple — and understated — make what they’re doing secure.
Information Security is often seen as slow to move. Security is more about layering up and doubling-down on things that are already done. And through this, security inherits its reputation as ‘Business Prevention Officers’.
In the old world of 4–6 week implementation times for new projects, security could comfortably take a couple of days — or a week — if it needed to so that it could plow through its standard incantations and, ultimately, provide the project team with the necessary ticked boxes.
Much consternation was given to where in that multi-day process different parts of the voodoo should be deployed — “should we pen test earlier in the process?”, “should we check for compliance with baseline controls on first build or last build or all builds?”, etc.
Almost as an aside to the workshop on my first day, the Technical Lead set off a handful of scripts in the background whilst he talked us through the solution’s components.
About an hour later, he’d provisioned a basic, but functional, multi-component platform, networked it up, and could access it via a web-browser and interact with it as a service.
I grabbed a sticky note and did a back of a napkin calculation about how long the same would have taken and how much it would have costed at previous clients:
Suddenly taking even a day to ‘do security’ was laughable — the entire stack of infrastructure and applications was deployed in around an hour, so the idea that they were going invest in and develop a capability of this level and then hamstring it with bureaucracy was a non-starter.
Even pitching for 5 minutes in a 1 hour deployment cycle was going to look ridiculous.
I wrote a second sticky note too:
Thankfully I stayed and fought it out and in the process I think that we as a project achieved some pretty amazing things. We tried to benchmark ourselves against our peers but mostly found that they weren’t really playing at anywhere near the same level, and when we were assessed by a ‘Big Four’ consultancy they were unusually quiet.
Eventually the Platform-as-a-Service model we were pursuing became wider and started to lend itself into DevOps adoption and cloud adoption, and the control set that I had to pitch for grew.
So this series will explore each of those controls we implemented — some of the necessary compromises that we made — and ultimately stitch it all together in what is hopefully a useful and re-useable framework.
