Secure DevOps Framework — Summary
DevOps is a new mindset for a business adopting it, and it’s one that is necessarily going to take some time to really get it working. Since it’s new for everyone, there are concerns, questions, and objections going to come from all parts of your business and IT teams.
With this framework, hopefully the questions from security have started to be answered and a path has started to be plotted out showing how the security function can not only accept the arrival of DevOps, but steer its arrival and actively benefit from it.
This diagram summarises the main areas we’ve covered:
Identity sits throughout the entirety of the model and your organisation. This is born from the need to know who’s supposed to be doing what, and who isn’t. And then, more pressingly who’s not even supposed to be here. Read about the core areas of Identity which need to be considered here.
Environment controls start conceptually just beyond your Dev environment. We’ve agreed to leave Dev alone, but we’re going to strongly leverage other existing environmental controls within your non-Dev environments and bolster them to make sure they’re doing what security need too. We’re going to keep a close eye on what’s going on right through from the edge of Dev into production. More detail here.
Secure SDLC is a biggie, and involves working closely with your development teams to understand their workflows and working out how we can integrate the controls we need into what they’re doing by default. Only in rare cases should we be trying to change workflows. The Secure SDLC doesn’t end at Dev though — it runs right the way through everything, and that’s part of why it needs to be kept lightweight and flexible. More here.
Embedded Expertise is the difficult one in this. It’s more about changing the way we, security, look at ourselves, the problems we’re trying to solve, and the businesses we’re trying to support than any single technology, process, or policy control. This should be the wake-up call that we as an industry need — it’s almost the culmination of years of worrying about whether we’re the dog or the tail, and who should be wagging whom. The reality is: we’re all the dog and if the tail needs to wag, we need to find a way to get ok with that and make sure we don’t wag it into something’s mouth. The details.
DevOps represents a huge opportunity. In fact, it represents two. One: we can work out how we make this huge security juggernaut we’ve been building over the years drive a bit faster, turn a bit sharper, and get through smaller holes, hoping that will be enough. Or two: we can take the years of learning and apply them to the new, and very different, scenario that we’re faced with. And we can spend some time to understand the (frankly massive) opportunities there are for us here and modernise the security approach making it useful, relevant, and part of the wider team.
In closing, I want to take some time to acknowledge the other people that have been a part of building this. Whilst this framework presented here is the culmination of years of my work and experience in security, it would also have been absolutely impossible to realise without the Technical Specialists, Developers, Server Operations, Security Operations, Systems Engineers, Security Managers, Change and Release Teams, Networks Engineers, Project Managers, Test and QA Teams, and an organisational management team who supported what we were trying to build.
I hope it’s useful to you in your organisations too.
