I just got back from the Boston DevOps Days. I really enjoy hanging around DevOps and cloud people. The energy of these conferences is great, and they are genuinely excited about transforming how their organizations build and deploy applications. Many don’t have a negative perception of security folks, but they don’t really understand what security folks do either.
I did a workshop called Quick and Dirty DevSecOps, to provide some context and perspective to DevOps people about security and how to integrate it into their DevOps environments. I borrowed a bunch of content from Rich’s Advanced DevSecOps training class to give real examples (and code) of how to do this integration. That brought up the inevitable push/pull between securing the Dev side of the equation and focusing on securing the Ops.
Should you prioritize (DevSec)Ops or Dev(SecOps)?
In other words, when you are getting started on your journey to integrate security into the DevOps environment, do you start by helping the Developers understand secure coding practices? Getting the developers to Shift Left and add a bunch of security testing to their development processes would result in code with fewer security issues. We all know that saves a bunch of money. Or do you focus on helping the operational teams manage the on-going life of the environment while in production? Prioritizing Ops can avoid potentially serious security issues that put production systems at risk.
Not that security folks want to hear this, but we’ve presented a false choice. You shouldn’t and can’t choose because the most significant risk to the environment lies in the weakest link. DevOps became a movement to eliminate the silos between functional groups and ensure accountability. Playing favorites between Dev and Ops counteracts that mission.
We suggest you look at the choices from the perspective of short versus long-term impact. Start with what you can do today and what would require procedural evolution/maturity. To be clear, because something falls into the process (and therefore longer term) bucket, doesn’t mean you don’t need to get started. Long-term starts right now. You won’t realize the impact of that work for a little while.
Regarding short-term activities, we remain partial to integrating security testing into your deployment pipeline where possible across your entire infrastructure as code. That means making sure no obvious vulnerabilities exist in the images you use to drive your auto scale groups and the source code that gets pumped into your pipeline. Getting developers to embrace a security mindset will take some time, but you can add some tests to the pipeline and ensure some measure of application security before deployment.
On the operations side…
We believe that you can (and should) implement Guardrails right now. You can make sure operational changes don’t do things like open up S3 buckets to the world, allow anyone to access your admin servers, or stand up a cloud account without proper logging and monitoring. As much as you try to automate everything in your DevOps world, humans still play, and they make mistakes. We all do. Having Guardrails in place to monitor, and most importantly automatically fix, the issues found will dramatically reduce risk.
Longer term, you can map out a set of workflows that automate multi-step operations and make your operational team more efficient. Beyond that, orchestrating third-party tools and controls represents the highest order of operational automation.
But first things first. Get those short-term wins and start planning for the long-term process changes required to integrate Sec into Dev and Ops. Remember it’s (DevSec)Ops AND Dev(SecOps).