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.  

Blockchain Revealed

Many of you must be frustrated following so many links about blockchain without finding out what it is, how it works, or what it is good for.  While it was invented a quarter of a century ago by Haber and Stornetta, it has recently been popularized by its most famous application, Bitcoin.

One might well ask why anyone might choose to write on something where so much has already been written.  The answer is that finding the answer to my three questions has proved to be difficult.  In this blog, I will attempt to answer those three questions but to the extent that I fail, I hope that readers will follow up with questions.

A blockchain is a collection of digital objects related in such a way that changing any one of the objects will be obvious and changing all of them in a non-obvious way is computationally infeasible.   Thus, it is a data integrity mechanism.  It is an example of a zero knowledge proof, i.e., making a demonstration without prior knowledge or pre-arrangement.

The objects are “chained” in such a way that object N includes a hash of object N-1 and its hash is included in object N+1.   The hash of the last, or latest, object in the chain depends upon, is an arithmetic function of, the content of every object in the chain.  Therefore, one can demonstrate that the chain is complete and that no objects have been altered.   We also know that object N-1 existed before N and N before N+1.

This works for any set of similar digital data objects.  The objects determine the application.  For a simple example, the objects might be the entries in a journal, or entries in a database.  More complex examples might include a digital record for all the transactions of a digital currency, bills of lading, warehouse receipts, or public records.

Blockchains enable anyone to demonstrate, by recomputing the hash of the last object, the integrity of the data. Therefore many applications may not require or rely upon a trusted party or access control of the data.  On the other hand, demonstrating the integrity of the chain is computationally intensive so blockchains work best for applications where the number and size of objects is low.  Said another way, blockchains may not scale well.

Note that trusted third parties, such as banks, often assume risk and collect fees for their role; disintermediating them can reduce cost.  For example, one might be able to transfer large sums internationally more cheaply using digital currency than by using orders on central or correspondent banks.