Monday, March 8, 2021

Separation of Duties

One of our most efficient controls over insiders is to involve multiple parties in sensitive duties.  We assign roles and duties in such a way that: 

  • individuals, simply by doing their job, act as a control upon others  
  • increases the probability that errors will be detected and corrected
  • such as to limit temptation or the ability to commit fraud
  • such that cooperation would be required to both convert an asset and conceal that conversion. 
  • so as to improve transparency and accountability 
We separate management from staff, that is, execution from setting objectives, measurement, and reporting.  

We separate the Information Technology function and application development from their managers and users.  

Within Information Technology we may separate:

  • Data Entry
  • Operations
  • System Architecture
  • System Programming
  • Application Design
  • Application Coding
  • Program Testing
  • Maintenance 
  • Management
  • Other


The little monks, specifically Luca Pacioli and his colleagues, that documented the idea of  double-entry bookkeeping in the late 15th Century, suggested certain minimum rules that we use today as tests.  

They suggested that the individual who creates and authorizes an account should be separate from the ones who processes transactions within the account.  For example, the person who assigns the account number for a new customer or vendor, and enters the descriptive information like name, address, Duns number, credit information etc. should be separate from the person who processes debits and credits.  Normally, managers or officers authorize new accounts while clerks, cashiers, or tellers process orders, payments, deposits and withdrawals.  

Applying these tests to program development suggests that:

  • authorizing, naming, and specifying a program
  • be separated from coding
  • testing
  • acceptance
  • operation
  • execution
  • use
  • and maintenance 

can be usefully separated.







1 comment:

  1. How do you see the proliferation of DevOps (and ultimately DevSecOps) as congruent to the tenets of "segregation of duties" and "least privilege"? Ideally, organizations should employ "context switching" (aka Personas) to support explicit change in roles for the same user, but the reality is that Personas are too difficult to operationalize (and I haven't come across any vendor supporting this since VMWare's failed Persona project some years ago). As a result, many DevOps are given a broad swathe of permissions that break not only these two tenets, but go against the Zero Trust mindset altogether. How do we best address this dichotomy between efficiency and effectiveness?

    ReplyDelete