Shifting Security Left – Moving to a DevSecOps Model
September 23, 2020 | Best practices
Romeel Khan Principal Consultant
As more and more organisations shift their infrastructure and applications to public cloud, one of the biggest questions that arises is how they will approach security.
Organisations who are leveraging the dynamic nature of cloud with modern DevOps practices are also realising that traditional approaches to security are outdated.
With the advent of Infrastructure as Code, the ability to deploy infrastructure via APIs, as well as practices such as Continuous Integration and Continuous Delivery (CI/CD), security teams are facing the dilemma of how to manage, govern and secure cloud environments effectively.
The shared responsibility model
One of the key principals of security in the cloud is the shared responsibility model. This fundamentally means that the responsibility of security is not just in the hands of the provider or partner (managed service provider), but rather, security in the cloud is a collaborative model. As you move through the service stacks of IaaS to SaaS, the shared responsibility model also shifts.
Additionally, customers always retain responsibility of data and identities, access control and endpoints.
The cost of failure
Security breakouts are a CIO/CTO’s nightmare scenario. As more and more companies move workloads, data and applications to the cloud, the nature of security attacks is becoming more sophisticated.
In the Accenture report ( “The Cost of Cybercrime 2019“), it mentions that from 2017 to 2018, the average cost of cybercrime increased by 12% from $11.7 million to $13 million. In the past 5 years up to 2018, there had been a 72% increase!
As more and more teams adopt practices of DevOps to build applications and infrastructure in a consistent and reliable manner, the need for security teams to understand how shifting security concerns to the left in the development life cycle, is as crucial as ever.
Shifting security left
In many organisations security is usually governed by a separate team. However, with constant demand for new features and the spinning up of cloud environments, the traditional security audit at the end of development cycle no longer fits the model of constant and frequent release cycles. As alluded to before, security now becomes a crucial concern across the whole IT team. Developers, ops, testers and CISO all play a crucial role in this new security paradigm. To be successful, security teams should shift their focus left so a fail fast approach to security can be adopted at the beginning of any project.
The key glue in all of this is the CI/CD process. With the advent of automation, traditional security steps can now be automated into tasks which form part of the overall process of delivering secure applications and environments. The first step for the IT security team is to collaborate with developers and operations in how the security steps will integrate into the existing CI/CD workflow. This requires a shift in thinking from traditional waterfall approaches to more agile methodologies. The shift left approach allows the security team to transition from just being an approval gate to a more cross functional role where they can audit and review the entire CI/CD process.
Applying DevSecOps in Azure
In this blog, I will use Azure DevOps as the example. Azure DevOps is a comprehensive release management tool that allows organisations to plan, deploy and manage projects at scale in the cloud and on premise.
Compliance plays a big part in an IT security team’s task. Making sure the Azure environment is correctly audited and issues are flagged, is a crucial part of security governance.
In the above example of CI/CD workflow, it is clearly shown how security teams can work with developers to ensure that a particular web app is deployed to a valid region. This is achieved through authoring an Azure policy to deny deployments to regions not on the list. By adding a compliance gate to the application security process, IT teams can catch compliance issues early in the development life cycle.
The same principles can then be applied to multiple use cases. To name a few:
In this blog article we discovered how IT security teams can collaborate with engineers, architects and developers by shifting their view of security to the left in the cloud. IT security teams can then review CI/CD workflows by creating security policies for effective auditing of environments, making sure automated security checks are integrated into the CI/CD workflow. By following this approach, teams can be confident of catching security issues early and build confidence in the product or service they are creating.