Financial Services Regulatory Compliance

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.

Regulations

GLBA Safeguards rule requires that financial institutions must protect the consumer information they collect and hold service providers to same standards.

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.

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.

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.

Common controls

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 Incompatible Duties (SODs)

To protect a system from unauthorized changes and fraud, organizations must establish organization-defined duties and roles, document separation of duties of these individuals and roles, and define associated system access authorizations to support these separation of duties.

NIST's Configuration Management control as outlined in NIST 800-53, Rev. 4: CM-2 establishes that baseline configurations are documented, formally reviewed and agreed-upon. As baseline configurations serve as a basis for future builds, releases, and/or changes to information systems, it is critical for organizations to have the ability to control changes and evidence the integrity of the deployment process.

Configuration Change Control is outlined in NIST 800-53, Rev. 4: CM-3: the organization implements approved configuration controlled changes to the information system and retains a record of the configuration controlled-changes - and changes to deployment configurations.

All changes to baseline orchestration configurations are stored and tracked.

Changes to configurations of protected branch and environment configurations are stored and tracked.

Both the NIST and the ISO security frameworks outline requirements related to developer security testing and evaluation. NIST 800-53, Rev. 4: SA -11 establishes that organization must require the developers of the information system, system component, or information service to implement a security assessment plan, produce evidence of execution of security testing, and correct flaws identified.

As a result, business application software needs to support the following:

Evidence that data has not been modified.

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.

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.

Operations Security via Protections on Branches and Environments

Organizations need to evidence the integrity of their production environments and critical code branches.

Changes to configuration of protections for branches and environments are tracked and logged.

Organizations must have access to readily available, human-readable audit trail of all actions taken to label and protect environments.

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.

One concept of a user across the lifecycle to ensure the right level of permissions and access

All changes must be tracked. Compliance with Sarbanes-Oxley mandates that publicly traded companies report any material changes to the processes and systems that govern the flow of financial data so as to reduce the risk of material misstatement of financial statements.

Systems used to support change management procedures must retain records of changes made, of who reviewed and approved changes, and the sequence in which they were performed.

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.