DevOpsSec

Chapter 6. Conclusion: Building a Secure DevOps Capability and Culture

DevOps—the culture, the process frameworks and workflows, the emphasis on automation and feedback—can all be used to improve your security program.

You can look to leaders like Etsy, Netflix, Amazon, and Google for examples of how you can do this successfully. Or the London Multi-Asset Exchange, or Capital One, or Intuit, or E*Trade, or the United States Department of Homeland Security. The list is growing.

These organizations have all found ways to balance security and compliance with speed of delivery, and to build protection into their platforms and pipelines.

They’ve done this—and you can do this—by using Continuous Delivery as a control structure for securing software delivery and enforcing compliance policies; securing the runtime through Infrastructure as Code; making security part of the feedback loops and improvement cycles in DevOps; building on DevOps culture and values; and extending this to embrace security.

Pick a place to begin. Start by fixing an important problem or addressing an important risk. Or start with something simple, where you can achieve a quick win and build momentum.

Implementing Software Component Analysis to automatically create a bill of materials for a system could be an easy win. This lets you identify and resolve risks in third-party components early in the SDLC, without directly affecting development workflows or slowing delivery.

Securing the Continuous Delivery pipeline itself is another important and straightforward step that you can take without slowing delivery. Ensuring that changes are really being made in a reliable, repeatable, and auditable way that you and the business can rely on the integrity of automated changes. Doing this will also help you to better understand the engineering workflow and tool chain so that you can prepare to take further steps.

You could start at the beginning, by ensuring that risk assessments are done on every new app or service, looking at the security protections (and risks) in the language(s) and framework(s) that the engineering team wants to use. You could build hardening into Chef recipes or Puppet manifests to secure the infrastructure. Or, you could start at the end, by adding runtime checks like Netflix’s monkeys to catch dangerous configuration or deployment mistakes in production.

The point is to start somewhere and make small, meaningful changes. Measure the results and keep iterating. Take advantage of the same tools and workflows that dev and ops are using. Check your scripts and tools into version control. Use Docker to package security testing and forensics tools. Use the Continuous Delivery pipeline to deploy them. Work with developers and operations to identify and resolve risks. Use DevOps to secure DevOps.

Find ways to help the team deliver, but in a secure way that minimizes risks and ensures compliance while minimizing friction and costs. Don’t get in the way of the feedback loops. Use them instead to measure, learn, and improve.

Working with dev and ops, understanding how they do what they do, using the same tools, solving problems together, will bring dev and ops and infosec together.

In my organization, moving to DevOps and DevOpsSec has been, and continues to be, a journey. We began by building security protection into our frameworks, working with a security consultancy to review the architecture and train the development team. We implemented Continuous Integration and built up our automated test suite and wired-in static analysis testing.

We have created a strong culture of code reviews and made incremental threat modeling part of our change controls. Regular pen tests are used as opportunities to learn how and where we need to improve our security program and our design and code. Our systems engineering team manages infrastructure through code, using the same engineering practices as the developers: version control, code reviews, static analysis, and automated testing in Continuous Integration. And as we shortened our delivery cycle, moving toward Continuous Delivery, we have continued to simplify and automate more steps and checks so that they can be done more often and to create more feedback loops. Security and compliance are now just another part of how we build and deliver and run systems, part of everyone’s job.

DevOps is fundamentally changing how dev and ops are done today. And it will change how security is done, too. It requires new skills, new tools, and a new set of priorities. It will take time and a new perspective. So the sooner you get started, the better.