Separation of Duties the DevOps way – Part 1

IT security is intended to prevent the manipulation of data and systems by unauthorized parties. The issue comes when anyone who is developing code has access to deploy the code or someone who is in development team have access to production box, or one who is coding is also validating or approving the changes. To overcome these issues Separation of Duties come in picture.

 Separation of Duties (SoD) is a key concept of internal controls. The concept of Separation of duties (SoD) became more relevant to the IT organization when regulatory mandates such as Sarbanes-Oxley (SOX) and the Gramm-Leach-Bliley Act (GLBA) were enacted. A very high portion of SOX internal control issues, for example, come from or rely on IT. This forced IT organizations to place greater emphasis on SoD across all IT functions, especially security.

With SoD we are introducing boundaries of different persons or teams responsible for different operations whereas DevOps emphasis on breaking down the barriers and silos. The question that we may think of now is how does these two go together. Although in the DevOps world, we are talking about bringing the development and operational teams into one, implementing the Segregating of duties, is still one of the most common practices to control what/who can or cannot be promoted to production.

Separation of Duties

Before going further into what problem Separation of duties solve, let us understand what Separation of duties is. Separation of Duties is the concept of having more than one person required to complete a task. In software engineering world, this basically means the person who has developed the code cannot approve or deploy the code.

“The principle of Separation of duties is based on fact that no individual person or group should be able to execute all parts of a SDLC. It should be shared responsibilities of more than one person or department of a key process to disperses the critical functions of that process.”

SoD has two primary objectives. The first is the prevention of conflict of interest, wrongful acts, fraud, abuse, and errors. The second is the detection of control failures that include security breaches, information theft and circumvention of security controls.

Why is Separation of Duties important?

In terms of IT security there are 3 main types of internal control that can be implemented: detective, preventive, and corrective. These controls are processes or policies implemented to prevent any security breaches. Separation of duties is critical to effective internal control implemented to reduces the risk of both erroneous and inappropriate actions. All business units should attempt to separate functional responsibilities to ensure that errors, intentional or unintentional, cannot be made without being discovered by another person. It is imperative that there be separation between operations, development and testing of software, security, and all controls to reduce the risk of unauthorized activity or access to operational systems or data.

Common areas for Separation of Duties in IT Organizations include:

1.      Separation of development and Test: This is common scenario that we have seen commonly. A developer should not be able to mark the software ready for production without an approval from a QA team.

2.      Separation of development and Release: Another area of concern is during the release process the developer should not be able to release the software into production without quality check.

3.      Separation of development and Production Access: Many times, we have seen developers having access to production box or production confidential data.

 Implementing Separation of Duties, the DevOps way:

Introducing only a few changes in your DevOps practices can help you achieve the goal for separation of duties in the DevOps way. Few suggestions to begin with include:

• The IDE should have integrated checks for code quality and code security.
• The repository should be scanned on a regular, recurring basis by both a static application security testing (SAST) tool and a software composition analysis (SCA) tool (SCA checks libraries and functions/methods for versions with known vulnerabilities).
• Later in the pipeline use dynamic application security testing (DAST) in addition to standard code quality testing.
• UAT testing can also be heavily automated, especially when leveraging a test-driven development (TDD) methodology.
• Infrastructure configurations can also be automated and checked using tools like terraform and kitchen-terraform. Additionally, images or containers should be pre-hardened with appropriate security tools integrated into the images or the hosting environment (such as sidecars for containers).
• All these tools and tests will generate output that must be fed into your issue tracker (e.g., JIRA, Pivotal)

 We will continue this discussion next blog as we take a deep dive around challenges of SoD and how we can implement SoD using devops best practices.