DevOps presents certain challenges for compliance. One such example is Segregation of Duties. In a nutshell, it is designed to reduce the risk of fraud and prevent costly mistakes and insider attacks by ensuring that changes are not propagated without approval or transparency. It is spelled as a fundamental control in some security and governance frameworks like ISO 27001, NIST 800-53, COBIT and ITIL, SSAE 16 assessments, and regulations such as SOX, GLBA, MiFID II, and PCI DSS.

It is also known as Separation of Duties (SoD) and is the concept of having more than one person required to complete a task. It is meant to be an internal control put in place to prevent fraud and error. DevOps and SoD are not usually mentioned in the same sentence for a very apparent reason. DevOps is all about removing barriers and reducing hand-offs. SoD is all about adding gates to minimize risk. But these two can be combined to operate together seamlessly.

If someone is working together in a highly regulated industry, for example Finance or Healthcare, moving teams towards a DevOps way of working can be quite hard. This is because regulators want assurances that only requested, approved, and fully tested changes make it all the way to production. In that case, SoD is used as the main control for giving assurances.

Segregation of Duties

As the reader already knows, DevOps is the merging of two once discrete functions of Development and Operations into one. The same team that develops and tests the code also supports the operation of the code in production. Segregation is the act or practice of setting apart people or things from others or from the main body or group. It is the exact opposite of merging. Yet it is still one of the most common practices to control on what can or cannot be sent to production.

Drawbacks of Segregation of Duties

1. It can slow down teams by introducing unnecessary hand-offs and even potential errors. Every single hand-off leads to a transfer of information. This transfer not only slows down things but also introduces a Chinese Whispers effect. When deploying changes, there will be hand-offs that will affect responses to incidents that occur in production. In most scenarios there is no better responder to an incident than the person/team responsible for the change.

2. It shows lack of trust to teams which yields a culture of fear. DevOps teams need independence in order to get the full value and speed benefits that the practice preaches. The team needs to be trusted to do the right thing at all times. If they do the wrong thing, they should be expected to take on the responsibility of fixing the error. Uncle Ben once said that with great power comes great responsibility.

3. Collusion. There have been attempts in the past to deliberately push unauthorized changes into production, either due to malicious intent or to undermine the process because of urgency. This has always popped up as an issue no matter the number of controls.

How To Implement SoD

1. Minimize the number of hand-offs. With DevOps, the focus is generally with the Software Development Life Cycle (SDLC) but cutting down on hand-offs can be applied to most processes within the team.

2. Automation. This is an investment for a company’s builds, testing and deployments. By automating the delivery pipeline, the risk of human error is minimal. Continuous Integration is a development practice that requires developers to integrate code into a shared repo several times a day. Check in are then verified by an automated build and unit testing process, thus allowing teams to detect problems early. Continuous Delivery is the natural extension of Continuous Integration – teams make sure that every change to the system is releasable, any version can be released at the push of a button. The aim is to make releases boring, so we can deliver frequently and get fast feedback on what users care about. Continuous Deployment is an extension of Continuous Delivery; code is released to production as soon as it is ready.

3. Remove External Dependencies such as external teams. Attempt to keep sign-offs within the team. This will speed up overall process time. Going back to DevOps principles, teams should made up of full stack or T-shaped developers who can wear multiple hats when required to perform all tasks for the team. The main reason to get rid of external ties is that is now easier to get access to people within the team rather than those outside of the team.

4. Safety Nets over Controls. When it comes to software development, safety nets include high quality system monitoring of production systems. The team can now understand the current state of the system and the ability to respond to an incident before the user does and potentially avoid an incident in the first place. In the event of a major incident, blue/green deployments is another safety net that can be applied. Blue/green deployments is a well-known but under-utilized cloud pattern used to minimize downtime for a release as well as provide a rapid way to rollback if something goes wrong. Fail safe and fail fast, rather than trying to avoid failure at all costs.

Auditing and Compliance 

Auditors look closely at SoD, to make sure that requirements for data secrecy and integrity are satisfied, and no unauthorized individuals have access to or are making changes. There should be audit trails for all of this. 

There are requirements to integrate Security Controls and Audit Capabilities which can potentially generate capital for CI/CD pipeline automation. But there is one caveat – there will be unique challenges for a scalable organization. 

One of the goals of DevOps is meet cross-functional requirements more effectively and efficiently by “shifting left”. This will integrate security and quality concerns into the normal developer feedback cycle. However Compliance controls and Audit activities are very needed for meeting regulatory standards. 

There are so many methodologies out there that have been developed to provide proof of compliance with regulatory requirements. Each one has its own benefits and trade-offs. 

 Segregation of Duties in Software Production development environment is Implementation by Kaiburr through Rules such as 

  1. Merged PR contains at least one reviewer.
  2. Business Approval for Production Deployment is provided.
  3. Merged PR contains only approved reviewers.

You can implement any Internal Controls to meet Regulatory Compliance requirements through a robust Kaiburr’s Rules Engine powered with AI. You can also track and measure KPIs, KRIs and metrics like Change Failure Rate, Lead Time for Changes, Deployment Frequency. Kaiburr helps software teams to measure themselves on 350+ KPIs and 600+ Best Practices so they can continuously improve every day.

Reach us at contact@kaiburr.com to get started with metrics driven continuous improvement in your organization.