The MEASURE of DevSecOps
The start of DevOps was simple enough: get some developers and operations folks together and build something. With together being the keyword. The concept of DevOps came from this notion that operations needed to take part in the Agile movement. Many articles chronicle the history of how Patrick Debois and Andrew Clay Shafer coined the term and how the historic presentation by John Allspaw and Paul Hammond at Velocity 2009, “10 Deploys a Day at Flickr” launched DevOps into being, so I won’t repeat all that here, but if you are looking for more, please see this excellent write up on the topic by Ernest Mueller.
In the hubbub and flurry of launching DevOps, the security crowd wasn’t really included. Of course, we tried to bring the security folks in early on, but it was many years later that real traction started happening. Security just had their own problems and generally expressed little interest in what they considered another development practice fad. They had seen all the Agile and the XP, and the scrumming, and figured this too shall pass. DevOps wouldn’t last.
But it did.
And this is where things get interesting. If you go to a security conference today, I guarantee that one of the topics you will find is DevOps, or often, as this blog post starts out with: DevSecOps. This new moniker, DevSecOps, has been created from the security industry to put security in the mix of DevOps. It is a fitting name because it put security right in the middle of DevOps. Bringing security into the software delivery (and value creation) process seems to be on everyone’s minds.
It would be easy to write this off as a replay of DevOps, but with this go-around, security gets involved. In some ways, this is bound to be true, but it’s more than just a rebranding applied to DevOps. It’s a culmination of many software movements coming together: Agile and InfoSec and DevOps, yes, but also Chaos Engineering and Continuous Delivery. This is Security’s chance to participate in the software delivery process and be a relevant part of the organization in delivering value.
The MEASURE Framework
I created the MEASURE framework to help us think about how DevSecOps is radically changing the security industry. In fact, in the last 20 years, I haven’t seen anything in Security that comes close to the impact and changes that are starting to take place at many companies today brought on by DevSecOps. The MEASURE framework is a way to understand the component parts of DevSecOps.
Maker Driven
Our DevSecOps movement is one that is driven by builders and defenders who write code to solve real problems. Security has struggled in the past with writing code and participating in the software development process, but this is changing. High-performing organizations recruit security pros who feel comfortable writing code, or they look for developers who want to try out security as a career. Either way, the result is the same: the organization adds security into the development pipeline, or they write code to solve security problems.
Experimenting
Experimenting brings in the iterative approach that dev teams have learned with Agile. Instead of implementing that shiny new auth framework across all users, why not try it out in a subset of accounts through the use of feature flags? Security teams leading DevSecOps initiatives will also run experiments to sort out the types of attackers they are dealing with based on attack payloads used or targeted assets. The key is creating a learning culture where security informs the rest of the software delivery organization.
Automation
This is small experiments that can be run at a faster cadence. Think of performing audit and compliance evidence gathering daily or weekly rather than annually. Automation is where we turn our experimenting and learning culture into code. This is where the bulk of the time spent in DevSecOps programs these days goes and that is great. We love automation, but one of the risks is that (much like happened in the early days of DevOps) we will confuse automation as what DevSecOps is all about. It certainly is a piece, but DevSecOps is an extension of the DevOps culture not just piling in more tools.
Safety Aware
Safety in complex adaptive systems is not exactly straightforward, but we have decades of research on the topic. Security and software engineering as a whole have a lot to learn from the safety sciences discipline. Some of this we see in the Chaos Engineering, where Casey Rosenthal, John Allspaw, and Nora Jones have been bringing awareness of the safety literature to the software engineering discipline, and the interesting thing is that we see Security has very complementary set of concerns to Safety. Aaron Rinehart first connected this with his work on Security Chaos Engineering at UnitedHealthcare where he bridged security and chaos through experiments that created more secure and resilient software.
Unrestrained Sharing
Security likes to be a little cloak and dagger. This is understandable given the history and roots of the discipline from government services and three letter agencies, but that needs to change. Security controls that are only accessible by the security team don’t benefit the learning of the team-at-large. One of the things I notice at high-performing DevSecOps organizations is that these organizations look for ways to share information. Developers should know if their application is under attack. Engineers should be able to answer security questions about what attacks are being stopped in the application layer. Of course this is not as easy as giving access to the firewall to everyone, but finding ways to share is key.
Ruggedization
Ruggedization means building defensible software that can withstand attacks from unknown sources. It was a call to arms in security that started almost ten years ago, by Josh Corman sparking the conversation in InfoSec. There is a Rugged Software (https://ruggedsoftware.org/) manifesto which talked of the basic principles of defensibility and building software that can last. It was important in the security echo chambers and as a precursor to DevSecOps, we often spoke of Rugged DevOps being a way to achieve many of the goals of the Rugged Software manifesto. There are two movements in software which I feel echoes the sentiment of Rugged. First, the Principles of Chaos (https://principlesofchaos.org/) , which injects failure conditions to build more resilient software. The second is deception techniques that lay down traps for attackers in your system so that you can better defend against them and track lateral movements.
Empathy
This is probably the most important part of MEASURE because empathy is at the heart of DevOps and DevSecOps. It is a realization that the silos that Information Security built up around waterfall, compliance, and a culture of “no” in many organizations has led them to being seen as an outsider. As other.
Empathy changes security in the organization so that instead of being the security team that says no, you can be the security team that says yes. A team that identifies with the organization struggles of delivering software is one that takes the path of empathy. This team now understands the pressures of operating at scale or developing features under business pressure and offers to help others meet goals. By being shoulder-to-shoulder with those who are building and running software for your organization, you are building empathy muscles.
Want more on MEASURE?
I hope you enjoyed this blog and see where security is changing and how Continuous Verification and Chaos Engineering fit in DevSecOps. Stayed tuned to this blog for deeper dives to each piece of the MEASURE framework.
