Another day, another catastrophic data breach. This time it’s medical records in Singapore, where I live. At this stage we’re almost immune to this kind of headline:
Cyberattack on Singapore health database steals details of 1.5 million, including Prime Minister (Reuters)
Singapore has suffered its “most serious” data breach, compromising personal data of 1.5 million healthcare patients including that of its Prime Minister Lee Hsien Loong.
The affected users are patients of SingHealth, which is the country’s largest group of healthcare institutions comprising 42 clinical specialties, four public hospitals, five speciality centres, nine polyclinics, as well as three community hospitals.
Non-medical personal details of 1.5 million patients who visited SingHealth’s specialist outpatient clinics and polyclinics between May 1, 2015, and July 4, 2018, had been accessed and copied. The stolen data included patients’ name, national identification number, address, gender, race, and date of birth.
In addition, outpatient medical data of some 160,000 patients were compromised, though, the records were not modified or deleted, said the Ministry of Health and Ministry of Communications and Information (MCI), in a joint statement late-Friday.
That’s not a great look. SingHealth did, to their credit, notify all affected parties by SMS fairly soon after the breach became public.
So, what to do? It’s time to come to understand that while personal data is potentially commercially useful and potentially lucrative, it is at the same time a burden. It’s toxic data; it’s liability data; it’s “Prepare-the-comms-plan” data. But things could be different.
In my piece A gentle introduction to self-sovereign identity, I explain the concept of self-sovereign identity. Since writing that, my understanding has become more nuanced, and here I will outline the elements of a more secure system for storing sensitive in more detail.
Data warehouses containing large amounts of personal identity data are honey pots and extremely attractive for bad actors who want to copy the data. They don’t need to alter or tamper with the data, just taking a copy is enough.
But how can we remove the single source of data yet retain the usefulness of being able to pull up relevant and up to date data when, say, a doctor needs to access a patient’s records, or a bank needs to access a client’s corporate documents?
The key is in maintaining data structures and standards while decentralising the storage and accessibility of that data. This means, for any system, ensuring that there are machine readable “boxes” or data fields containing standard data (Name, address, etc) but moving the storage of that data to multiple locations – as many as practical – rather than a central database, and encrypting that data with many different keys, held by many different parties (usually, the data subject ie the person who the data is about). While a determined attacker can still probably get a single person’s data if they try hard enough, it’s much harder for them to get all of the data together in one juicy valuable database file.
One part of the solution lies in allowing each user to store their data in a consistent standard format, but allowing them to encrypt it with keys that they themselves hold (of course, it shouldn’t need saying, that there should be no master or backdoor key). So even if a bad actor was able to download the full database, they would need to decrypt each individual patient’s data using different keys.
The other part of the solution lies in physically decentralising the data – allowing it to be stored in different vaults, whether it’s a known number of locations on different cloud providers, controlled by the health provider, or whether it’s more decentralised still and stored at a location determined by the end user (for example on their smartphone, or on their dropbox or iCloud).
Doctors needing the information would send a request to the patient’s smartphone app and the patient would need to tap to allow access to certain data fields for a certain period of time. Patients without smartphones could use facilities (ie an ipad) at the location of the doctor, perhaps logging in to an account they created earlier. This adds a layer of inconvenience to the patient, but it puts the patient in greater control of their data.
Where does blockchain come into this? Well, this is the final part of the solution. Something needs to coordinate the permissions, access, and revocations. Something that connects various healthcare centres, clinics, and patients. An immutable, or at least tamper-evident log of who asked permission from whom, and when and possibly with a log of which data fields they accessed. This can be done, perhaps not on a traditional blockchain (because even the metadata should be private), but on a privacy-focused distributed ledger such as Corda.
I declare an interest here. Corda was developed by my employer R3, together with a large number of financial institution clients.
R3 and 39 clients recently completed a “KYC-on blockchain” project demonstrating this “decentralised data warehouse” concept, and I hear there are plans to have it commercialised. Hint: Personal data isn’t widely shared on the ledger; “permission tokens” are moved from party to party on Corda.
According to GT Review:
The banks and corporates involved in the project include: ABN Amro, ALD Automotive, Alfa Bank, Bank ABC, Bank of Cyprus, BCI, BNP Paribas, China Merchants Bank, Commercial International Bank, CTBC Holding, Deutsche Bank, DNB, Hana Bank, ING, KB Kookmin Bank, Banca Mediolanum, Natixis, National Bank of Egypt, NH Nonghyup Bank, Qiwi, Raiffeisen Bank International, RCI Bank and Services, SBI Bank, Shinhan Bank, Société Générale, US Bank and Woori Bank. In addition, a number of regulators and central banks took part, including Banco de la República (Colombia’s central bank), Federal Reserve of Boston, Superintendencia Financiera de Colombia and Superintendencia de Banca Seguros y AFP de Peru.
I also discussed this concept at the 2nd Blockchain for Finance, APAC conference in June in Singapore in a panel discussion entitled “Can blockchain save KYC & AML challenges?”.
I hope this has been helpful. Please don’t hesitate to get in touch if this resonates and you want to learn more.
If you found this interesting, I explore blockchains more deeply in my book The Basics of Bitcoins and Blockchains. It is an essential guide for anyone who needs to learn about cryptocurrencies, ICOs, and business blockchains. Written in plain English, it provides a balanced and hype-free grounding in the essential concepts behind the revolutionary technology. You can order “The Basics of Bitcoins and Blockchains” on Amazon. If you are undecided, you can also read some reviews about it, totally not written by my friends.