Relevancy of Separation of Duties in software development?

I find the concept of Segregation of Duties a mildly interesting one - largely because, for software development it has never sat comfortably with me.

Separation, or Segregation of Duties (SoD) is a concept rooted in financial controls: it aims to provide a control against financial fraud in organisations.  What's stopping somebody (let's call them Bob) who has the ability to transfer company money about from doing so into their own account?  The idea of SoD is to introduce another person into the process (let's call them Alice), and only allow the to transfer the money, but not to request transfers.  Thus we now have two people involved.  Bob requests the money goes to his account Alice can call him out.

In an old school example (as this is the world that these sorts of concepts originated), this could be materialised by Alice having the physical cheque-book, but only Bob being able to sign the cheques.  In a more modern world, maybe this could be an application permission.

How SoD is implemented can vary a bit, by having managers involved in signing things off; co-signing payments etc.  And we tend to see this sort of idea frequently in businesses.

It is also frequently talked about in IT - probably because IT has traditionally been under the same umbrella as finance in the good-old days.  When a financial audit is conducted, one of the questions you'll routinely see is around who has access to release software into the live environment.  The objective of SoD in software is similar to the above, e.g. a software developer wanting to adjust an application to have money transferred to their own interests.  By having somebody else involved requires collusion to accomplish that.

Atomic transactions vs Software

Or does it?

In our first financial fraud example, we're talking about an atomic, discrete financial transaction.  A cheque is a cheque, and who is getting the money is who is getting the money - it can be made more convoluted by obfuscating where the money is going, but it is still clear what is going on: money is being moved.

Software release though is a different ball-game, mixing my metaphors, it is comparing apples and oranges, an example if you will:

Bob is now a software developer working on a financial package; he decides to do something nefarious with the financial transactions, bypassing controls in place.  With SoD he cannot release this into the production environment, Alice is the only person with access.  Bob compiles his nefarious code and hands it over to Alice to release.  It's an executable, Alice isn't a computer and has no way to know what it is inside the machine code, and she releases it.  And what about Alice?  What if Alice wants to release something nefarious?  SoD serves no useful function here.  There are various arguments and scenarios that can be thrown at this, but I haven't found one that really sticks.

Objectives of segregation of duties

There are other places we could separate duties in the above software-release process that may be more useful, but the reason I focused on having somebody else deploy code is because this is frequently the control that is asked for by financial auditors: no access to production systems for software developers.

I have recently had the pleasure of discussing this with an auditor from one of The Big Four. It seems that from their perspective, SoD is about ensuring the process is followed and changes cannot go unchecked.  This is significantly different from the leading questions about who has access to production servers.  The theory is that by removing access to the live environment any processes that are in-place cannot simply be ignored.  The person who is releasing the software can check that the developer has followed the process (such as receiving sign-off).  It's a blunt stick to ensure process is followed.

It is interesting at this point to look at other areas of IT.  We don't tend to see the same reasoning being applied to infrastructure engineers and database administrators.  As far as I can tell, this is because it would be too difficult to provide an effective segregation in these roles - I'm not convinced it is any different.

Keeping under control

All this aside, it's important to be able to demonstrate to an auditor that your production systems haven't been tampered with by an upset developer.  How do we do this if Segregation of Duties is not effective?

What auditors are looking for is that the process for a change has been followed, the relevant people are aware, and nobody can take an action against the live environment in a stealthy fashion.  It isn't about quality of code or including the security of code - whilst those might be other compliance requirements and part of a process, SoD itself doesn't concern itself with that any more than ensuring that if there is something in place to address those areas, it can be demonstrated as being checked off for all releases.

There are various approaches that can provide the freedom to developers whilst maintaining that handle on your systems.  At the heart of this is largely going to be logging security information and event management (SIEM).  Even with manual processes in place, an effective (and acted on) SIEM process can provide the visibility that is needed to show that whatever processes and controls that are mandated by an organisation are followed.

For instance, have your system automatically log when a deployment has occurred and ping that around the relevant developers and stakeholders.  Nobody will be doing a release without everybody knowing about it.  With most build and deployment systems this should be relatively simple to link back to an authorised change and exceptions can easily be highlighted.  Using code-signing and cryptographic hashes it is also possible to verify the integrity of the production system against the known, trusted, source code.

In closing, I'd urge anybody who has had this question thrown at them to take a look at the underlying requirements from their compliance teams and think about what effective measures can be leveraged to a) actually provide a real benefit, and b) not hinder the agility and performance of your technical staff.

I believe this is an ongoing conversation to have, and invite any views people have on the subject to drop me a line via the contact form on this site.