As I mentioned in our (DevSec)Ops vs. Dev(SecOps) post, we’ve been traveling around to a couple of DevOpsDays conferences presenting our Quick and Dirty DevSecOps talk. One of the things I tend to start with early in the talk is the fact that, like DevOps, DevSecOps is not a product. Or something you can deploy and forget. It’s a cultural change. It’s a process. It’s a journey.
So there is no such thing as Quick and Dirty DevSecOps. So I feel a bit bad that I get people into seats by offering up something that doesn’t exist. OK, not that bad — the benefit of educating DevOps people on the basics of security outweigh the one or two folks cranky they didn’t get a quick fix for cloud security.
It is a compelling talk (if I do say so myself!) and the folks at the Philadelphia DevOpsDays event had a visual notetaker there to capture the high points of the talk. Check out their encapsulation below.
Caveats aside, how do you get to DevSecOps? As Rich Mogull says, Cloud Security starts with architecture and ends with automation. Our DevSecOps roadmap adheres to this guidance. This post will dig into the three sections of the roadmap at a high level. Then we’ll follow up with additional posts to delve into each aspect of the roadmap.
1) Design Secure Architectures
Many cloud security architectural concepts are intrinsic to DevSecOps. These include fitting the architecture to the application, meaning that you build the technology stack the application needs — not just use familiar tech.
You also want to use architecture as a control. At a high level that means you use tactics like multi-account strategies, network segregation, immutable infrastructure and infrastructure as code as fundamental mechanisms to make it harder to compromise the entire infrastructure.
These architectural constructs lead us to the challenges of making a lift and shift type of approach (basically just moving your existing data center into the cloud) work. Such an approach does not offer opportunity to leverage these kinds of cloud-unique approaches.
2) Security in and of the Pipeline
In the DevOps world the main focus is the continuous deployment pipeline because that’s how you build, test, and deploy code. And as mentioned above, everything is code, so everything is in the pipeline. That means the (DevSec) side needs to ensure application security tests happen within the pipeline, which gets close to the holy grail for many security folks — actually building security into the process. There are significant ramifications to this, which we will dig into over time.
If your code is intellectual property (it is), and it’s all in your pipeline, it’s essential to make sure your pipeline is secure. Whatever tech you use to manage your pipeline (and plenty is available), you’ll need to spend a bunch of time hardening it and ensuring it stays that way.
3) Secure Operations
We’ll finish up this roadmap with operations. You want to make sure your infrastructure is reliable, resilient, and performs well. We mentioned above that cloud security ends with automation, so let’s define what that means.
We have outlined three levels of automation.
- Guardrails: This aspect of automation is near and dear to our hearts because it’s what we do at DisruptOps. The key to a guardrail is enforcement. It’s not enough to flag issues. You need to fix them. Check out our other blog posts on building guardrails for much more information.
- Workflows: When you link together automated functions, triggered by activity, you are in the realm of workflows. We have a bunch of them identified, but think about the ability to quarantine and investigate a potentially compromised server automatically. That’s a workflow.
- Orchestrations: Finally, when you start to integrate third party tech into workflows, you have orchestration. You access most things cloud via API, which means you can program how you interact with cloud services. When we were developing a lot of this content at Securosis, Rich built a cool orchestration to automatically move a web server behind a cloud WAF, integrating external DNS and WAF services.
Any organization that has embraced the cloud to any degree has started playing around with automating the operational motions in their environment. Making those automations more reliable and resilient is why DisruptOps exists. So we will post a lot more automation goodness on this blog.