Using blockchain to validate records in DCDR
Security is a guiding principle for DCDR, and protecting user data has been baked in from the start. However, there’s more to data security than restricting access and managing user permissions. I’ve used the INFOSEC abbreviation CIA — confidentiality, integrity, and availability — as a guide to help determine the steps required to protect your data while also ensuring that the system does what it’s supposed to. Overall, the intent is to ensure:
- Confidentiality — only those authorized by the owners of the data can see it.
- Integrity — the data in the system can be trusted to be accurate and unchanged
- Availability — users should be able to get the data they need when they need it.
I’m always looking for ways to improve each of these elements, and the specific area I’m focused on right now is data integrity.
Data integrity
There are several aspects to ensuring the integrity of user data, starting with the methodology used to assess risks that powers the assessment. However, I’ve recently been looking at ways to prove that the data is accurate in relation to governance and audit support.
Here are a couple of scenarios I’ve had in mind that illustrate the need for a specific kind of verification around data integrity.
Scenario 1
During the development of the annual risk register, a significant (high likelihood) threat is assessed as posing a moderate risk because the impact on the firm would be relatively low. This assessment is based upon the best available information at the time of the assessment. There are several mitigation measures designed to mitigate this threat, but these are not executed properly. The event, when it occurs, causes a greater degree of damage than was anticipated because of the inadequacy of these mitigation measures. The subsequent investigation would want to know: who knew what and when; the mitigation planned; and which of the planned actions were actually undertaken. The challenge is that a spreadsheet, or even a record in DCDR, can be edited and updated because we need a way to keep things up to date.
So how can you verify that a record was created at a specific date/time and not altered afterwards?
Scenario 2
Similarly, if an incident occurs, the initial report will be very sparse on details. As time goes on, the amount of information will grow as accounts become more accurate, photos and documents are added, and the picture becomes clearer. However, decisions made during the incident can only be based upon what was known at the time. These decisions can seem misguided when viewed in retrospect when all the information is available. The legal standard is often ‘how would a reasonable person have acted in similar circumstances,’ but this requires you to know what those circumstances were and what was known at the time.
As in the first scenario, you need a way to verify the historical provenance of a record.
The case for adding this feature to DCDR
Both scenarios suggest a requirement to verify the data’s integrity using a trusted source that all parties can rely upon. Adding this functionality to DCDR would help users in this situation and support them in their overall risk management activities. This makes a compelling case to add this feature to DCDR.
So how can we do that?
Blockchain and distributed ledgers
The solution I’ve settled on is to utilize the blockchain to maintain a verifiable, trusted record of activities within DCDR which still protects data confidentiality.
Blockchain is the technology that underpins cryptocurrency as it is “a decentralized, distributed, and oftentimes public, digital ledger consisting of records called blocks that is used to record transactions across many computers so that any involved block cannot be altered retroactively, without the alteration of all subsequent blocks” (Wikipedia)
In our case, the data that forms these blocks will be a randomly generated UUID for each record. No data from the record is stored in the block.
The UUID block and the previous record’s block are added to each record. Combining these two blocks creates the ‘chain’ of records within the DCDR registry.
Illustration of a blockchain being created. In our case, the block transaction which becomes the root is the UUID of the current record. (Illustration Computerworld)
If a record is updated later, both the block for that record will change (because a new UUID is created) and the block for the previous record will be different. Therefore the updated record has a different ID and place in the chain than the original.
We now have an auditable and verifiable sequence of records that we can use to prove the historic provenance of records. This meets the requirements outlined in the scenarios above.
Additional trust
A copy of the DCDR ledger will also be stored in a third-party distributed registry to further increase the records’ trustworthiness.
This means that the DCDR ledger can also be validated, adding an extra level of confidence to the integrity of the DCDR records.
Ilustration Stephan Junestrand
Only the UUID records will be stored in the registry so no PII or confidential data will leave the DCDR system.
Now we have created a two-level process for verification. First, records can be verified against the DCDR registry to determine provenance. Second, the DCDR registry can also be verified against the archived versions stored in the third-party distributed registry.
This two-level system means that the records in DCDR can be verified to a very high standard and that any changes or alterations can be identified. This two-tier validation will allow users to meet the requirements of investigations and audits similar to those outlined in the scenarios above with a very high degree of confidence in the records.
Roll out
This work is ongoing as at February 2021. The aim to have the DCDR registry established by late March 2021 and the third-party registry established by mid-year. The majority of this functionality will occur at the system level and requires no action by the user. Record IDs will be discretely added to reports once the DCDR registry has been established.
Queries / comments
Please email me with any questions you have. I’m particularly interested to hear about any use-cases that I haven’t addressed above. I’d also love to hear any criticisms or challenges you can see.
Please email me at andrew@dcdr.io
Clarifications*
Opt-out
There is no opt-out from this service for Solo, Pro, and Team DCDR users. Enterprise users running a non-standard version of DCDR may opt-out of the service but would need to provide a waiver declaring that DCDR cannot support any audit or investigation of their records.
GDPR and personal information
No PII is associated with the UUID or the records stored in the DCDR register and the third-party registry. I therefore believe that this approach meets the GDPR anonymization requirement: that data be “rendered anonymous in such a manner that the data subject is not or no longer identifiable”. (https://gdpr-info.eu/recitals/no-26/)
Audit requests
A process for making requests for audit support will be issued mid-year.
Read more on DCDR risk management software at dcdr.io
