“This [referring to the earlier thread] isn't about "separation of duties." This topic is about job descriptions. Separation of duties is an important security principle, first established by the Clark-Wilson model, and initially applied to programs, mandating that the agent responsible for doing the task, is not the agent responsible for checking the task.”
This note is to point out that the principle of separation of duties is an essential tool for security process design, far beyond the computer programming focus of the Clark-WIlson model. Using the systems engineering framework of three system components of people, processes, and tools, we need to design business processes addressing all three components. Designing business processes that protect against insider threat demands using both processes and tools to deal with potentially malicious people inside the enterprise.
The Clark-Wilson paper may have introduced separation of duties into computer programming practice, but the authors did not invent the concept. Separation of duties, also called segregation of duties, had been around in the fields of financial management, accounting practice, and audit principles decades before Turing was a gleam in his father’s eye. Separation of duties as a security tool long predates computer programming and the digital world. Also called Segregation of Duties (SoD), the principle has been used by the accounting and auditing communities since the days of ledger books. The concept is straightforward: the same person should not have both authority to approve an expense and the physical ability to issue the funds. More broadly, one person should not be able to approve a critical action and then carry it out. Separation, or segregation, of duties is a key principle for reducing the impact of a single malicious insider.
The American Institute of CPAs (AICPA) described SoD:
Segregation of Duties (SOD) is a basic building block of sustainable risk management and internal controls for a business. The principle of SOD is based on shared responsibilities of a key process that disperses the critical functions of that process to more than one person or department. Without this separation in key processes, fraud and error risks are far less manageable.
More complete discussions on this topic are available, such as the following articles.
Separation of duties and IT security by Beyer & Colemen in CSOOnline,
Separation of Duties in Information Technology by Gregg, Nam, Northcutt & Pokladnik at SANS Institute.
As cybersecurity professionals we are in the business of system security engineering (SSE), not just computer programming. See the old Information Assurance Technical Framework, Chapter 3, for the baseline for Information SSE discussion and the current NIST SP 800-160, Volume 1, for current SSE guidance. Add the core focus in the INCOSE Handbook on dealing simultaneously with people, processes, and tools to apply them to dealing with the challenge of insider threats.
And I proposed yet another name for it, isolation of duties. The theory being that you would want to isolate duties that when combined with other duties gave undesirable access or power that could lead to undesirable consequences. Once isolated you would be able to put into place systems to keep those duties isolated from one another.
@CISOScott I strongly recommend that you avoid trying to promote an alternate term to represent the very well-established and widely recognized terms Separation of Duties and Segregation of Duties (SoD). You only fog up clear communication when you introduce such a new term instead of helping folks use what is already wide spread in use and definition.
I think your idea of isolation of people or processes could be used effectively when describing details of how to implement SoD in any specific situation, but use it to describe the process, not name the principle.
As an analog, look at the mess our profession has caused by replacing information security with information assurance and then with cybersecurity. All true practitioners should understand that in all cases we are approaching infosec and IA, but the general public, and some newbies in our field, are fooled by the chybersecurity word into thinking we deal only with the digital computer aspects of protection.