True records

Thinking back to the early days of the Cloud, I was a big fan of SaaS solutions and could hardly imagine a future where ‘Cloud First’ would become the strategy adopted by most corporations. Now, in 2022, it is hard to imagine any company not moving a significant part of, if not all, workloads into the cloud.

The rise of the cloud is not only moving compute and storage to a fluffy place nearer to the sun, but also the biggest deriver of Infrastructure as Code. What efficiencies this new world brings, when one can spin up a full system with a few clicks! I was in awe of my ability to replicate the system holding data of all projects to connect 8 million happy homes, perform an upgrade on that system, take a few screenshots destined for an options paper.

Problem

The great power of the cloud, and Spiderman, got me thinking about the astonishing responsibility to guard against malicious intent. Picture a scenario where a trusted employee has access to the systems of a given company, and goes about their job, quite happy that there is a lot of good work to be done. They then learn about invoicing and payment systems, and the reconciliation process, they are also aware of the back-up and restore process.

Now picture if they put the time to replicate the processes in their personal cloud account, create some code that could edit historical transactions and massage the totals so that the entire data trail would make perfect sense and look completely normal, when in fact there are records inserted and altered to produce the net effect of a new payment to be made to a secrete account. What if this process was repeatable, and they could run it hundreds of times a month?

In the illustration, the fraud is committed by creating rogue records in different systems to receive a refund for an order that was not cancelled. To avert suspicion, the crime is committed using old orders that won’t be showing up on critical reports that the business reviews monthly. The chain of systems are made to look consistent as the inventory will not expect the item to be returned.

Solution

There is a new kind of database that is immutable, this database uses block-chain to create a journal type entry where all transactions are represented as new records superimposed onto its previous version. In this type of database, the fraudster would leave behind a trail and with analysis, the transactions would be evident. It is not feasible to replace our systems with immutable databases, because the compute requirement difference is substantial, as on top of data transactions, there is calculation required to superimpose over the version history and the cryptography to sign new records.

As I think about this fictitious clever trick, I wonder what if there was a shortcut to assure the data is as it should be, perhaps, this is not a problem for the database to solve, what if the critical records we extract from the system can be validated and independently stored in a system where it is immutable.

Perhaps this scenario is not something happening every day. A different scenario and a more practical one, would be to look at an auditing process, where a consultant is hired to inspect the systems for evidence of compliance. This can be a financial audit or a compliance audit. The inspector will be given access and record their findings and prepare a report and so forth. The records produced and evidence gathered for the report will largely be hand crafted or stored in the auditors’ systems/documents. A useful tool would be to create a journal of compliance evidence, and perhaps preamp the process.

In building a system to comply to a particular standard, one could produce the artifact that is required by the auditor and streamline this process. At the very least, the company can retain the detailed evidence of an audit, should there be disruption on the process and a change of auditor, this journal will retain the knowledge there-in.

In addition, the role of the auditor requires system wide read access to everything. This poses a risk that the auditor can access data that may be sensitive or confidential when in practice, it is only possible to perform spot checks or cross-checking sums.

The generic use case would consider any artifact that requires high fidelity and assurance in the form of human verification, then this can apply to any business transaction. As is the case with the auditor, there are already manual processes where this use case can be implemented with EUC tools. For example, I can print an artifact to PDF, include a statement of veracity and sign it digitally. This paper is looking at the use case from a systemic-corporate perspective.

In this case, the system would need to record trails of evidence, rather than individual business transactions. It would need to be able to verify veracity of the information and protect the information at the same time.

Let’s imagine a set of personas

The system would then be organised around topics/sub-topics and trails. A trail can branch into different subjects.

Let’s illustrate with an example.

Topic: Annual Financial Report

The business record of the final topic would reside in the top of several sub-topics.

An incomplete list could include Financial Performance, Sales Statistics and Investments.

The team working on the report would then access different systems and collect a myriad of information to go into the report. Each journey would be recorded in a trail of evidence and journaled, and signed by the Record Signatories, and the evidence attached to trail.

The CEO can then be confident that any number written into the report has been verified, and if they wish, they can see the evidence for themselves. The Process/Business Owner can also verify the process and sight the evidence collected within their ownership but not data that is not for their eyes to see. The public can see the report at the right time, and can independently verify that the evidence was collected, along with public notes, but cannot see the artifacts.

If the company is requested to show evidence of backing their report, then an Auditor Role can be created to access specific trails, and one would anticipate that the likelihood of an audit would be inversely proportional to the rigor of the evidence trail.

A second prominent topic could be Data Integrity. This can be a generic topic to systemically perform checksums in systems of record and report on any issues. Each system can have its own trail and branches to validate data in significant date ranges. The process would create digests of specific views that are expected to remain immutable. Any inappropriate change to the data would be flagged on repeating the process, in which case the System Owner would be able to inspect data against a back-up and rectify specific changes.

Trail: Sales --> Branch: Historic Sales

--> FY23-01: Original: Check 1 = Valid: Check 2 = Valid

--> FY23-02: Original: Check 1 = Invalid

--> FY23-03: Original: Check 1 = Pending

As illustrated, the system seems to have an issue where the data for February changed in March, the System Owner would need to create a rectification action, and either have a Record Signatory confirm the data change was legitimate to reset the Original or correct the records that changed from comparing it to a back-up.

Suppose there was an error in the month of February and the record Signatory has confirmed the changes are legitimate, given our records are immutable then a rectification can be recorded in the trail.

--> FY23-02: Original: Check 1 = Invalid: Original Replaced (signed by user): Check 2 = Valid.

In this scenario the auditor has successfully identified and corrected the data. If this was a valid reason, no further action is required. If the person responsible for the data is concerned about fraud, the back-ups can be retrieved for investigation. An example of fraud could be changing order values at the time of calculating sales commission. In both scenarios, the auditing task is performed immediately so that at year end, the confidence of its veracity is high.

Conclusion

Whist the premiss that a rogue employee will create a criminal mastermind script is a lesser threat (although similar fraud has happened in the past), in imagining such scenario, and exploring a systemic approach to create of evidence of data veracity and identifying tempering, it has been surprisingly fun to me.

With minimal impact to operational processes and with the ability to streamline that auditing activates, such an approach can use cryptograph to prove the integrity of key data.

Businesses can benefit from the increased trust in their brand due to the level of transparency afforded. It’s worth noting that the decoupled nature of the architecture resulting in minimal performance penalties to operational systems and minimal development effort for the target systems.

Whist this solution is only hypothetical, AWS services such as Amazon Quantum Ledger Database, Amazon S3 and AWS Lambda can work together to make-up the basis of such an application.