In highly regulated environments, such as the Financial Services sector, Segregation of Duties is an essential mechanism for avoiding collision amongst individuals with development responsibilities and production privileges.
Traditionally this has meant that Developers develop code and then hand it over to Operations however in many DevOps Operating Models the segregation between Development and Operations is, at a minimum, blurred:
In Google's Site Reliability Engineering, or SRE, practice there is a separate SRE function within Google, however, Developers are brought in to backstop the SREs in times of high operational load.
In the "You Build It, You Run It" model there is no separate operations function.
After spending months drilling down to the root causes of a Segregation of Duties mechanism it seems it predominantly exists to satisfy Sarbanes Oxley Section 404: Management Assessment of Internal Controls:
(a) Rules Required. The Commission shall prescribe rules requiring each annual report required by section 13(a) or 15(d) of the Securities Exchange Act of 1934 to contain an internal control report, which shall--
(1) state the responsibility of management for establishing and maintaining an adequate internal control structure and procedures for financial reporting; and
(2) contain an assessment, as of the end of the most recent fiscal year of the issuer, of the effectiveness of the internal control structure and procedures of the issuer for financial reporting.
(b) Internal Control Evaluation and Reporting. On the internal control assessment required by subsection (a), each registered public accounting firm that prepares or issues the audit report for the issuer shall attest to, and report on, the assessment made by the management of the issuer. An attestation made under this subsection shall be made in accordance with standards for attestation engagements issued or adopted by the Board. Any such attestation shall not be the subject of a separate engagement.
Based upon the comments it is important to call out a couple of assumptions I am making:
- I am predominantly considering mass-market financial services, i.e. transaction volumes are high but relatively low value. This would be as opposed to commercial financial services which has a different transaction value profile.
- A financial institution's online offering will be made up of many components that have differing risk considerations:
- Move Money - Moving money between accounts or transfers between accounts of different owners. An operation that has to consider Anti-Money Laundering, Fraud Protection, and Embargo'ed countries to name a few.
- Customer Acquisition - Less "Risky" as it has low transaction volumes compared to Move Money but still needs consideration.
- Internet Banking - Covers a wide range of services with varying levels of risk, Move Money would be considered part of this.
- Conceivably a different approach could be taken for each depending on the risk, however, in the interests of keeping it simple, I am working towards a solution that would apply to some of the riskiest operations.
Sarbanes Oxley 404 is normally satisfied through the completion of a Top-Down Risk Assessment, part of which will assess the risk of collusion and puts forward mitigation strategies.
Within a company which employs DevOps practice and culture, where Developers routinely have access to both source control and production how can Segregation of Duties be achieved, or more generally how can the risk of collusion be mitigated.