Financial Services Regulatory Compliance

Introduction

GitLab is used extensively to achieve regulatory compliance in the financial services industry. Many of the world's largest financial institutions are GitLab customers. This page details the relevant rules, the principles needed to achieve them, and the features in GitLab that make that possible.

Regulators and regulations

Examples of regulators include the following

  1. America: FEB in the US, also see the FFIEC IT Handbook
  2. Europe: FCA and PRA in the UK, FINMA in Switzerland
  3. Asia: MAS in Singapore and HKMA

Examples of relevant regulations include the following

  1. GLBA Safeguards rule requires that financial institutions must protect the consumer information they collect and hold service providers to same standards.
  2. Dodd-Frank’s purpose is to promote the financial stability of the United States by improving accountability and transparency in the financial system. It sets the baseline for what is “reasonable and appropriate” security around consumer financial data. You must be ready to prove your security controls and document them.
  3. Sarbanes Oxley (SOX) exists to protect investors by improving the accuracy and reliability of corporate disclosures made pursuant to the securities laws, and for other purposes. Advice for achieving this is augmented by other frameworks such as COBIT14 and the CIS Critical Security Controls.
  4. PCI DSS is intended to maintain payment security and is required for all entities that store, process or transmit cardholder data. It requires companies using credit cards to protect cardholder data, manage vulnerabilities, provide strong access controls, monitor and test, and maintain policy.

Specific controls common amongst these regulations are outlined below, along with features of GitLab that aid in their compliance.

Control Rule Principles How GitLab helps
Segregation of Duties To protect a system from unauthorized changes and fraud, more than one person is required to complete a task. * You never merge your own code.
* All code needs to be peer reviewed.
* Only authorized people can approve the code.
* You need a log of who approved it.
1. Protected branches
2. Merge request approvals
3. Unprotect permission
4. Approval jobs in CI pipelines
5. Two-person access controls
Security Business application software needs to support the following:
* Evidence that data has not been modified.
* Role-based access and revocation of accounts.
* Auditing and logging of events in systems that process sensitive data.
* Log system changes in a way that those logs are resistant to tampering and accessible only to privileged users.
Note: Application Security Testing can help identify vulnerabilities that enable unauthorized access to data, logic, and reporting.
* Scan applications regularly for vulnerabilities.
* Establish criteria for the prioritization of vulnerabilities and remediation activities.
* Pay special attention to internally or custom developed applications with dynamic and static analysis.
* Establish secure coding as a culture, and provide qualified training on secure coding.
* Establish and document a secure development life-cycle approach that fits your business and developers.
* Combine functional testing and security testing of applications: Assess for operational bugs and coding errors.
1. SAST
2. DAST
3. Dependency Scanning
4. Container Scanning
5. Security Dashboard
6. Security Paradigm
In addition to Application Security Testing to help you deliver secure apps, GitLab's own application has security to prevent unauthorized access to the application code as well as audit and logging capabilities of changes to the code.
Auditing Systems must have clear audit logs to trace changes to the data and also to the logic flow. * Auditability of the production application: Software systems must generate all of the necessary logging information to construct a clear audit trail that shows how a user or entity attempts to access and utilize resources.
* Auditability of the software itself to detect changes in logic flow: Whether urban legend or not, the example is relevant of the developer who pockets rounding errors to his own bank account
* Logs must be resistant to tampering and accessible only to privileged users.
1. One concept of a user across the lifecycle to ensure the right level of permissions and access
2. Audit logs
3. Audit events
4. Container image retention
5. Artifact retention
6. Test result retention
7. Future: Disable squash of commits
8. Future: Prevent purge
Change Management All changes must be tracked. Sarbanes-Oxley specifically requires companies to notify the SEC of any material changes to the process that governs the flow of financial data. * Change Management is required with changes tracked, reviewed and approved.
* Changes should be made in such a way that they can be rolled back to a previous version quickly and easily. Here are two examples as to why: Flash Crash and TSB Bank Disaster.
* Source control systems should prevent unauthorized changes using access control or, at least showing changes for a clear audit trail.
1. Automated deploy
2. Revert button
3. Review apps make it easy to visualize the changes in code review and ensure changes function in a legitimate manner.
License Code Usage Third party and open source code use must comply with license constraints. * To comply with license constraints, you must track license expiration and usage. This is important to manage risk from legal costs for license agreement violations and risk to your reputation. 1. License Management

Learn how GitLab can help solve your compliance challenge

Contact sales

Reference articles of interest

  1. DevOps Survival
  2. How the Federal Reserve Bank of New York Navigates the Supply Chain of Open Source
  3. Primer Ensuring Regulatory Compliance in Cloud Deployments
  4. Understanding Security Regulations in the Financial Services Industry
  5. Regulatory Compliance Demystified