Throughout software development, robust security and compliance measures are required, especially in industries like financial services where data integrity and regulatory adherence are non-negotiable. One critical aspect of maintaining these standards is separation of duties (SoD). SoD ensures that no individual has complete control over a process from beginning to end, thereby reducing the risk of errors and unauthorized activities. SoD mitigates software supply chain risks by preventing external and malicious acts that could compromise the integrity of the software development process.
Importance of SoD in the financial services industry
In the financial services sector, SoD plays a pivotal role in safeguarding sensitive information and upholding regulatory compliance. Here’s how SoD contributes strategically to the industry:
- Risk mitigation: By distributing responsibilities across different roles, SoD reduces the risk of errors, fraud, and unauthorized activities that could compromise system integrity or regulatory compliance.
- Enhanced accountability: Clear division of duties guarantees that no individual can independently initiate, authorize, and execute a process from start to finish. This promotes transparency and accountability, which are crucial for maintaining trust with stakeholders and regulatory bodies.
- Regulatory compliance: SoD is mandated by financial regulations so that sensitive operations are conducted with oversight and scrutiny. Compliance with these standards not only avoids penalties, but also protects the organization’s reputation.
- Operational resilience: By decentralizing decision-making and execution, organizations become less susceptible to disruptions caused by human errors, malicious actions, or unexpected events.
GitLab for SoD and best practices
GitLab provides end-to-end separation of duties covering the DevSecOps workflow.
The diagram above illustrates the integration of key elements like merge request approval policies, protected features, user permissions, compliance frameworks, and audit events, all working together to uphold the principles of SoD. Each of these components is detailed in the sections below, demonstrating how to establish a secure and compliant development environment.
Merge request approval policies
One challenge the financial services industry faces is the implementation of approval mechanisms that prevent unauthorized or unchecked changes from being integrated. This is where merge request approval policies come into play. These policies enforce the separation of duties between security and development, preventing individual developers from approving their own code changes if they contain vulnerabilities, and development teams from deploying their code directly to production environments without appropriate oversight.
When creating a policy, it’s advisable to consider who would be an appropriate approver. This can be defined as an individual user, group such as the Application Security team, or role type such as a Maintainer. To implement further restrictions, please consider these key policy features:
-
Prevent approval by author: This policy puts a guardrail in place so that a merge request author cannot approve their own changes. By requiring independent review, this policy helps maintain objectivity and impartiality in the approval process.
-
Prevent approvals by users who add commits: Users who have added commits to a merge request are also prevented from approving it. This further enforces the principle of independent review so changes are scrutinized by team members who are not directly involved in the modifications.
-
Prevent editing approval rules: To maintain the integrity of the approval process, GitLab allows administrators to prevent editing approval rules at the project or merge request level. This guarantees that once approval policies are defined, they cannot be bypassed or altered by unauthorized users.
-
Require user password to approve: For an added layer of security, GitLab can require users to enter their password to approve a merge request.
To maintain a clear separation of duties, it is advisable to create a separate top-level group dedicated to housing your security policies, including merge request approval policies. This setup minimizes the number of users who inherit permissions and enforces tighter control over policy management. From this separate group, you can link security policy projects at the highest group level that aligns with your objectives, reducing policy management overhead and providing comprehensive coverage across your development environment.
It’s also important to note that when a policy is enabled by default, it applies to all projects within the associated linked groups, subgroups, and individual projects. If you want to enforce policies more selectively, GitLab recommends you scope your policies to a compliance framework label. Commonly, our highly regulated customers will architect compliance labels that correspond with regulatory requirements, like “SOX” and “PCI.” This link to a framework also enables the native compliance center to manage security policies tailored to various use cases.
Compliance frameworks and controls
Customers in regulated industries face significant challenges in maintaining compliance in large organizations. Manual processes are prone to errors, and maintaining consistent enforcement of policies across teams can be difficult.
By using GitLab’s compliance frameworks, organizations can automate and administer preventive measures, systematically manage risks, and enforce regulatory compliance seamlessly. These frameworks can enforce security protocols and custom jobs across any pipeline.
To safeguard compliance settings at the organizational level, GitLab allows only group or project owners to add or remove compliance frameworks. This measure blocks development teams or managers from altering compliance configurations without appropriate permission levels, providing an additional layer of security. It’s important to note that if an individual with Maintainer permission is allowed to create a subgroup, they become the owners of that subgroup and can change the compliance framework. This can be prevented by limiting who can create subgroups under permissions and group settings.
SoD through permissions and roles
To effectively enforce the separation of duties in the financial services industry, it’s essential to establish clear and precise access control. GitLab provides a tiered permissions model with predefined roles such as Guest, Reporter, Developer, Maintainer, and Owner. Each role has a specific set of permissions so individuals can perform their duties without overstepping boundaries, which could lead to conflicts of interest or security risks. GitLab recommends assigning roles following the principle of least privilege access.
For organizations with granular needs, particularly those using GitLab Ultimate, custom roles offer even greater flexibility. These roles allow organizations to define specific permissions tailored to their unique workflows and compliance requirements. This is particularly useful in enforcing the separation of duties because no individual can perform conflicting tasks.
A common use case is the need for a deployer role — individuals who need to deploy jobs but should not have access to edit or push code. GitLab addresses this requirement through the use of protected environments. Protected environments allow you to invite groups approved to deploy jobs while limiting the role of users to Reporters. Please note that the deployment job should include the environment keyword. This configuration enables users to deploy jobs without the ability to edit the code, ensuring compliance requirements are met.
By carefully defining and enforcing roles and permissions, organizations can create a secure and compliant development environment. If you’d like to review your user permissions on a broader scale, you can use this Group Member report to see how many members of a role are in your environment and evaluate the next steps accordingly.
Protected features
GitLab offers several “protected” features to enforce additional layers of control over your development process. These features can be vital for maintaining SoD so that only designated individuals can make significant changes.
- Protected branches: A protected branch restricts who can push, merge, or force push to the branch. This is particularly beneficial for branches like “main” or “production,” so that only authorized users can make modifications.
- Protected Git tags: These tags allow control over who has permission to create tags. This prevents accidental updates or deletions once the tag is created, preserving the integrity of your versioning.
- Protected environments: Protecting specific environments, especially productions, from unauthorized access is imperative. In a protected environment, only users with the appropriate privileges can deploy to it, safeguarding the environment from unintended changes. This ties back to the deployer role functionality mentioned earlier, where individuals can deploy jobs without editing the code, establishing compliance and security.
- Protected packages: Using package protection rules restricts which users can make changes to your packages.
These protected features collectively help maintain a secure and compliant development environment that aligns with the principles of SoD.
Audit event and compliance center
Having discussed approval policies, compliance frameworks, roles, and protected features, the final step is how GitLab allows you to monitor and audit these implementations to guarantee adherence. GitLab’s audit events provide a detailed record of activities and changes, such as user activity and project modifications, for owners and admins. This logging is vital for tracking user actions and detecting unauthorized behavior. Audit event streaming enhances this by allowing organizations to stream audit events to external systems for real-time analysis and alerting. By doing so, any alterations or violations are detected, allowing swift remediation.
The Compliance Center in GitLab is a centralized hub for managing and monitoring compliance activities. It provides an overview of compliance status across projects and groups, highlighting violations of merge request approval rules or other policies. Administrators can promptly address issues, certifying adherence to predefined compliance standards. This centralized approach simplifies compliance management, maintaining a high level of oversight and control.
If you are interested in learning more about GitLab’s thoughts on SoD and compliance, check out the GitLab Govern product direction and the GitLab compliance documentation.