Monday, March 8, 2021

Audit Trail

We do a much better job of designing our access controls than we do designing our audit trail.  We should start by identifying what an audit trail should do for us.  It should enable management to determine:

  • how every record or object (e.g. program, file, record) got to look the way it looks currently,
  • how every record or object looked at any given time in the past,
  • and enable us to fix accountability for every significant event or change to a single process or individual.  
The result should be reliable and resistant to fraudulent modification. 

This requires that, not only must there be logs and journals of every relevant event, but that they be related in such a way as to support each other.  There should be logs or journals on both sides of any interface where control passes from one process or person to another.  For example, an application should log every request that it makes of the database manager and of the result that it gets back.  The database manager should record every request that it receives and what response it returned. 

Logs and journals should be protected from late, or potentially fraudulent, modification.  Consider reconciliation of the results of the independent processes on both sides of the interface, "write-only" processes or storage, or blockchains.  The correction of errors should be memorialized by new correcting entries, never by changing earlier entries.  

Log and journal records should include the action taken, the user or process on whose behalf it was taken, the date and time, and a reference or sequence number to make the entry unique.  In order to be able to establish how any record looked in the past, the record of the current change to a record should include reference by time, date, and sequence number of the next most recent change.  

Finally, the logs or journals should include images of the object both before and after the change.  While in some cases it may be sufficient to keep only the after image, since the after image in the record of the previous change is the same as the before image, keeping both improves integrity and further resists fraudulent change.  

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.