DevOps and Segregation of Duties
By Bob Aiello and updated Thursday November 10th, 2016
Editor’s note – this article was originally written in response to a July 31, 2016InfoQ article, DevOps Survival in the Highly Regulated Financial Industry, written by my esteemed colleague, Manuel Pais. Many people read the original article and came to the wrong conclusion that there is no legal requirement for a segregation of duties. I wrote my response to this article and contacted Mr. Manuel Pais, asking him to comment. Please do not interpret my words as criticizing Manuel or his writing in any way. Manuel Pais is a skilled technology professional and a talented technology writer. That said, I feel compelled to set the record straight on the issue of whether or not a segregation of duties is an actual requirement. Specific references to the requirement for segregation of duties are included at the end of this article.
Here are my original comments and Mr. Pais’ response.
Bob Aiello’s original comments:
In a July 31, 2016 InfoQ article, DevOps Survival in the Highly Regulated Financial Industry, my esteemed colleague, Manuel Pais quoted a presentation by Robert Scherrer, head of application engineering at SIX, which questioned the need for some regulatory requirements such as a segregation of duties.
Pais quotes Scherrer as saying, “Particularly noteworthy was an internal rule that developers could not access production systems. Turned out there was no external regulation with such requirement, instead this was a literal interpretation of the segregation of duties requirement. “
According to the article, Scherrer reportedly suggested that “blindly following internal directives is a costly mistake that hinders the benefits of DevOps.”
Response from Manuel Pais…
“As with many, if not most, ideas in the tech world, context is key. The story was not trying to claim there are no segregation of duties requirements at all. Instead it tried to summarize a 20m talk about an organization that was able to move to a better place in terms of deployability and recoverability with advanced mechanisms for controlling access to production environments. A mechanism that complies with regulations while allowing more flexible ways of working and organizing teams and work. It is hard to summarize such a dense talk about a complex system in a highly regulated environment. It should be clear that the need for adequate controls should never be taken lightly. Instead each organization must fully understand what are the regulations applicable in their context and geography, while at the same time (hopefully) trying to reduce waste and (often self-imposed) constraints that have become obsolete due to evolutions in technology, people and understanding of those very regulations. I urge readers to watch the recording of the presentation that the story tried to summarize (with inherent shortcomings) in order to better understand its intricacies.”
Hope that helps.
Manuel Pais | @manupaisable | InfoQ | LinkedIn | SlideShare
Bob Aiello’s analysis…
The premise that we need to discuss is that some folks believe that there is no explicit requirement for a segregation of duties…
I disagree with this premise completely. Effective IT controls help those responsible develop secure and reliable code much faster while also minimizing costly mistakes. As discussed in my latest book on Agile Application Lifecycle Management, DevOps requires right-sized IT controls. In my opinion, the above mentioned InfoQ article could lead some of our colleagues to believe that there is no explicit requirement for a segregation of duties (actually I know for a fact that it did which is why I wrote this article).
In fact, there are many specific references to a segregation of duties.
For example, the Office of the Currency (OCC) comptrollers handbook states (page 7), “Segregation of duties to reduce a person’s opportunity to commit and conceal fraud or errors. For example, assets should not be in the custody of the person who authorizes or records transactions.” And on page 23 it states that auditors are trained to ask “Is there segregation or rotation of duties to ensure that the same employee does not originate a transaction, process it, and reconcile it to the general ledger account?”
FINRA has similar requirements for Technology management, “We have observed deficiencies in firms’ risk management practices in these areas, for example through a lack of written procedures and evidence of supervision, insufficient segregation of duties for personnel involved in the development and deployment of technology changes, as well as insufficient user acceptance testing and quality assurance.”
ISACA Cobit (used for compliance with section 404 of the Sarbanes-Oxley act of 2002) explicitly lists the requirement for a segregation of duties. For example, in PO4.11 – Segregation of Duties, we see COBIT Control Objective PO4.11 – Segregation of Duties is contained within PO4 Define the IT Processes, Organisation and Relationships.
Another Cobit 4.1 control object, AI2 – Acquire and Maintain Application Software states that:
Control over the IT Process of Acquire and Maintain Application Software that satisfies the business requirement for IT of aligning available applications with business requirements, and doing so in a timely manner and at a reasonable cost by focusing on ensuring that there is a timely and cost-effective development process is achieved by
- Translating business requirements into design specifications
- Adhering to development standards for all modifications
- Separating development, testing and operational activities ***
and is measured by
- Number of production problems per application causing visible downtime
- Percent of users satisfied with the functionality delivered
In practice, regulatory Compliance always comes down to what (compliance) lawyers will defend, but the assertion that the requirements are not specified and clear is just not true. Both internal and external auditors will write up audit violations when there is a lack of segregation of duties – and rightfully so. If you are working in a bank or other financial services firm you may find yourself receiving a letter from regulatory authorities – telling you that your organisation must correct deficiencies or cease and desist from a particular area of business. It is also unlikely that you will pass your ISO 9000 review without effective IT controls in place.
It is time for some common sense guidance on how to implement DevOps and still comply with regulatory and audit requirements. I have good news for you. Many of us are involved with efforts to create industry standards for DevOps. Our goal is to focus on establishing the right balance of IT controls that help to avoid human error while focusing on building secure and reliable systems. Let me know if you would like to participate in these efforts!
Bob Aiello
bob.aiello@ieee.org