Microsoft’s transition of its corporate resources to the cloud required us to rethink how we integrate security into the agile development environment. In the old process, we often worked on 6- to 12-month development cycles for internal products. The security operations team was separate from the application development team and was responsible for ensuring that applications met security requirements. There was time to troubleshoot security between the two teams. Once we shifted to a shorter development cycle, we had to compress the new process to bake security into DevOps.
Our experience has led us to adopt four best practices that guide our thinking about integrating security with DevOps:
- Inventory your cloud resources.
- Establish a governance structure for cloud services.
- Give DevOps accountability for security.
- Redefine centralized security.
This post walks you through these tenets with some advice we hope you can apply to your own organization.
Inventory your cloud resources
Cloud subscriptions are so easy to spin up that many organizations don’t have a comprehensive understanding of which teams are using which services. This makes it challenging to manage your costs and enforce security policies. If you are uncertain which services you are currently paying for, billing is good place to start.
Establish a governance structure for cloud services
Once you understand your cloud inventory, you can begin the work of making sure your investments align with your business strategies. This may mean limiting which services your organization uses to maximize the ones that will help you meet your business goals. Then, align your organization to your cloud strategy by defining a governing structure:
- Develop business scenarios that define acceptable use and configuration of cloud resources.
- Define architecture and patterns for the cloud services you plan to use.
- Limit who can create new subscriptions.
Give DevOps accountability for security
The only way to effectively enforce security policies in a short development cycle is to integrate security into the application development process. Early in our evolution, we dropped security team members into application development teams to create a single team with shared goals. This revealed cultural challenges and unexamined assumptions. Initially, both the application developers and the security team expected to conduct their jobs as they had in the past. Application developers wrote code and then security operations queued up issues to address. This proved unworkable for two reasons. Security analysts were queuing up too many security tasks to fit within the cycle. The application developers were often confused because security operations underestimated how well they understood the nuances of security.
The only way to meet our goals was to shift accountability for security to the DevOps teams. We wanted application developers to try to solve security issues as part of their process. This required education, but we also implemented some practices that encouraged the team to take on that responsibility:
- Secure DevOps Kit for Azure—The Secure DevOps Kit for Azure provides scripts that can be configured for each resource. During development and before production, DevOps can easily validate that security controls are at the right level.
- Security scorecard—The scorecard highlights which members of the team are skilled at addressing security and encourages people to improve and collaborate with each other.
- Penetration testing—When a red team conducts a penetration test of an application, the results typically inspire the team to take security more seriously.
Redefine centralized security
We experimented with eliminating a central security team entirely, but ultimately, we realized that we needed a centralized team to monitor the big picture and set baselines. They establish our risk tolerance and measure security controls across subscriptions. They also automate as much of the security controls as they can. This includes configuring the Secure DevOps Kit for Azure. This team also needed training to better understand the vulnerabilities of the cloud. Tabletop exercises to talk through possible attacks with red teams was one way they got up to speed.
As our evolving process suggests, our biggest challenge was shifting culture and mindset. We recommend that you take time to define roles and start with a small team. You can expect to continuously discover better ways to improve teamwork and the security of your process and your applications.