Is Segregation of Duties a Requirement?

Question

In our environment. Developers have full rights and privileges in the dev, test, and production environments. This gives them the ability to create, manipulate, and promote code associated with financial transactions. To our security department, this represents a segregation/separation of duties issue. But the developers don't agree, they say that there is nothing that requires it. Aside from putting in our company policies, is there anything we can reference?

Answer 1

As the O'Reilly book, DevOpsSec details in chapter 2, Separation of Duties (SoD) is a major component of the information-security standards: ISO 27001, NIST SP 800-53, COBIT, ITIL, etc -- and part of the regulatory requirements for (at the very-least): FFIEC, Sarbanes-Oxley Section 404, SSAE 16, GLBA, MiFID II, and PCI DSS.

Developers do agree that read-only environments such as Immutable Infrastructure (i.e., the "No-SSH Movement") are best-practice. You will even see developer heroes such as Martin Fowler directly prescribe the PhoenixServer concept, if not the full ImmutableServer model.

However, in an org where the Three Lines of Defense (3LoD) are instilled (e.g., financial services companies or anywhere that has an internal and/or external audit function), even read-only functionality may not be enough to meet the requirements (and pass an audit).

The DevOpsSec book makes the following recommendations beyond Immutable Infrastructure and SoD (which it also recommends):

• Limit access to nonpublic data and configuration.
• Review logging code carefully to ensure that logs do not contain confidential data.
• Audit and review everything that developers do in production: every command they execute, every piece of data that they looked at.
• You need detective change control in place to track any changes to code or configuration made outside of the Continuous Delivery pipeline.
• You might also need to worry about data exfiltration: making sure that developers can’t take data out of the system.

Another compensation control is Rotation of Duties (RoD), which often goes along with SoD. If you rotate people out every-so often and avoid situations of collusion, then this can compensate and back up the other strong controls. A final piece would be two-party integrity where a full checks-and balances system includes the ability to prevent trusted insiders via the "No Dark Corners" paradigm.

Here also are some fresh perspectives from Ben Tomhave, an industry expert on DevOps and application security -- http://www.newcontext.com/devops-and-separation-of-duties/

Answer 2

As a practicing Information Security professional, I agree with the assessment of your IT Security department. Following security best practices often requires individuals understand the intent behind such practices, in this case proper segregation of duties, SoD

As the developers in you company don't seem to be motivated enough / understand the benefits of SoD, I would explain to them how abiding by SoD would benefit themselves. Take a look at what happened to the OP in this instance. Reasonable developers should understand if they don't have access to production, and assuming that the other 2 elements of security AAA of authentication and accountability is working, they cannot be blamed if an issue arises from their code after development is completed.

Developers should also understand that while they may be responsible and never maliciously cause damage to the financial data / credit card information in the production environment by breaching a CIA principle, other developers may be not be as responsible. If a incident were to occur with the sensitive financial data in production, there can be significant fines to the company along with a damaged reputation causing loss of future revenue, that based on the size of the company, may call into doubt business survival, directly impacting developer's career / livelihood.

Finally, I would like to expand on a point in the excellent answer provided by @atdre that you should have corrective incident response controls to complement detective change management controls. If you detect unauthorized changes made to production data from monitoring programs (e.g: TripWire), you should have compensating controls in place to recover from the damage done (e.g: utilization of a restore from tested backups).