Written by: Pooja Arya, Principal, CG Infinity Inc.
In the Part 1 of my blog about Separation of Duties the DevOps way, I have discussed what separation of duties is in the IT world and how it helps IT security in its intention to prevent the manipulation of data and systems by unauthorized parties. We have also discussed why separation of duties (SoD) is important and common areas where we should include the SoD. We also have discussed at a high level about how we can implement SoD in a DevOps way. In this part of my blog, we will discuss in detail about the challenges of SoD and how we can implement SoD using DevOps best practices.
Challenges with Separation of Duties
One of the major challenges that I see with the SoD is that it is less efficient and more time-consuming than having a single person be responsible for all aspects of a transaction. This is due to the number of hand-offs introduced. Another challenge is external dependencies. Having external dependencies such as needing an approval from a particular stakeholder, or having a separate team performing the deployment slows the process down. Both challenges can be overcome if we implement SoD using the DevOps way.
Implementation of Separation of Duties in a DevOps World
The primary principle for DevOps is to modify the processes to have the minimal number of hand-offs to perform a task. Further introducing automation will not only remove the handoffs but also ensure that there is a SoD among developers, QA, release managers and system engineers. Maturing the pipelines to do the automated deployments also reduces the risk of human errors. Build and release automation can be done in one of the ways described below:
Continuous Integration
Continuous Integration is a development practice that requires developers to integrate code into a shared repository several times a day. Each check-in is then verified by an automated build and unit testing process, allowing teams to detect problems early. With Continuous Integration automation in place, developers will just check-in their code and automated tests will run as part of the build pipeline to ensure build quality. Thus, not only ensuring SoD between developers and QA but also removing the hand off complexity between them.
Continuous Delivery
Continuous Delivery is the extension of Continuous Integration in which teams ensure that every change to the system is releasable, and that we can release any version at the push of a button. Continuous Delivery aims to make delivery more frequently. Deployment to production can then be controlled by having the permissions in place so that developers are not able to release to production.
Continuous Deployment
Continuous Deployment further extends Continuous Delivery by automatically performing the deployment of a release of code to production as soon as it is ready.
Removing Dependencies
The other area of concern for SoD was removing the dependency on external teams and attempts to keep all signoffs within the team. Having external dependencies such as needing an approval from a particular stakeholder, or having a separate team performing the deployment slows the process down. It is easier to gain access to those within your team, so at least minimizing your dependency on those outside. Introducing a product owner role in your team can help reduce this dependency.
Conclusions
Finally, I would like to re-iterate that Introducing only a few changes in your DevOps world can help you achieve the goal for SoD. Having a static application security testing (SAST) tool, a software composition analysis (SCA) tool, dynamic application security testing (DAST), or using test-driven development (TDD) methodology are just several beneficial approaches to solidifying your SoD.
I would also like to hear about your organization and implementation of SoD.