Blockchain based general data protection regulation compliant data breach detection system

Contributions

The major contributions of our work are as follows:

1. A blockchain based data breach detection system is developed. Every row is turned into an evidence hash and stored with the unique id of the off-chain data inside the smart storage contract. This allows the application to detect any alteration in the database record and verify the authenticity of any record 24/7 without depending on the internal database in a centralized organization.

2. An access control mechanism is developed, where only authorized entities can disseminate sensitive functions like adding proofs. These functions are highly restricted and can only be called by the authorized person (Data Controller in our case) using Data Controller’s wallet key (“Public and Private”) cryptography.

3. To verify the authenticity of the data owner, a digital consent model is developed, where the Data Owner digitally signs his consent using a secret key using PKI cryptography.

4. Since smart contracts are immutable and cannot be changed, proxy patterns with separate dynamic data storage are developed to support contract versioning and future features update.

5. Before the Data Controller stores Data Owner’s data off-chain, it generates irreversible evidence with a timestamp and stores it on the blockchain network. This system keeps every record’s proof on the network, which is used to verify the authenticity of an individual row of the data. It also helps the Data Controller in the process of determining the necessary mitigation measures for data breach events

6. The system presented in this work also complies with the GDPR articles 6, 7, 8, 12, 14, 15, 16, 17, 18, 20 and 33.

Theoretical and practical significance

Our proposed system provides data controllers with an automated tool to detect data breaches instantly. That will help them identify malicious activities and mitigate them before escalating further. Before the Data Controller stores Data Owner’s data off-chain, it generates irreversible evidence with a timestamp and stores it on the blockchain network. This system keeps every record’s proof on the network, which is used to verify the authenticity of an individual row of data. It also helps the Data Controller in the process of determining the necessary mitigation measures for data breach events.

The rest of the article is organized as follows: ‘Literature Review’ presents a detailed review of the closely related research works. In  ‘Case Study’, a case study is presented to illustrate the approach and methodology. A comprehensive discussion of the proposed system is provided in ‘System Design and Proposed Framework’. ‘Experimental Results and Discussion’ presents detailed information about the simulation setup and simulation results. In ‘Conclusions and Future Work’, the conclusion and future work are discussed.

Non-blockchain-based techniques

Numerous research works have been carried out using non-blockchain-based solutions to address the data breach detection challenges. The authors proposed a data leakage prevention system in Hanan, Traore & Woungang (2021). The authors have used semantic signatures of documents to detect leakages. The system detects data leaks when the outgoing document’s semantic signatures are matched with the original document’s semantic signature. However, a sensitive file can circumvent the detection system if an adversary encrypts it and sends it via email. This detection system cannot view the encrypted data as a sensitive file in this scenario. Hence, sensitive data can be exposed. Additionally, this system is domain-specific, specifically designed for the financial industry business domain. We cannot deploy in any other organization/domain (e.g., hospital, bank, etc.). In contrast to this limitation, our system does not have this constraint because it depends on smart contracts, which use a public blockchain to store the proof, which cannot be tempered or controlled by any entity.

For the protection of the database, an anomaly detection model is presented in Daren, Bertino & Sallam (2020). The authors used the hidden Markov model (HMM) for prediction and achieved low false-positive rates. However, the HMM-based system relies on the training dataset. The system might produce false-positive alerts if the training dataset is insufficient. In contrast to this limitation, our system does not have this constraint because it depends on smart contracts, regardless of the data and future changes.

In Ponemon Institute (2022), the authors proposed a data leakage detection algorithm to detect anomalous user behavior in computer sessions. The proposed algorithm works based on the probability of sequences of the tasks. By simulations, they show that the proposed algorithm outperforms other techniques in terms of accuracy with low false-positive rates. However, the limitation of this work is that it utilizes historical data and necessitates the requirement for user data to develop behavioral patterns. If a user completes too few tasks in a session, the system will not be able to tell if that session is normal or not.

The authors presented the data breach challenges in Barona & Anita (2017). Data breaches or leaks can hamper organizations’ reputation and credibility if the breach compromises sensitive information. A semantic rule-based fraud detection system is proposed in Ahmed et al. (2021). A method for sensitive data breach detection and prevention is presented in Gaikwad, Chougule & Charhate (2016). The authors used Shingling and Rabin filters for data leakage detection tasks. The approaches based on Rabin algorithms show some benefits over traditional approaches. However, they have some constraints, such as coverage and unavoidable false-positive rates.

A signatures and pattern based data leakage detection system is proposed by the authors in Desai & Gaikwad (2016). The system detects data breaches when the outgoing data’s pattern is matched with the original data’s signatures. It also raises the alarm when a high similarity is found. However, the adversary can modify sensitive files and data by substituting, adding, and subtracting words before sending data. Furthermore, the semantics of sensitive files can be rewritten as a summary. These modifications can change the identity of original sensitive data. Hence, sensitive data can be exposed.

In recent years, several insider threat mitigation techniques and data breach detection schemes have been proposed that are based on machine learning techniques (Lin, Yang & Lin, 2020; Moghaddam & Zincir-Heywood, 2020; Ferreira, Le & Zincir-Heywood, 2019; Meng et al., 2018; Le, Zincir-Heywood & Heywood, 2020; Sun et al., 2021; Al-Shehari & Alsowail, 2021; Le & Zincir-Heywood, 2021a; Le & Zincir-Heywood, 2019; Hu et al., 2019). Yan et al. (2022) proposed a field theory-based risk calculation approach for further development of three-dimensional risk assessment. In Krishnaveni et al. (2020), the authors proposed an effective anomaly detection system with the help of support vector machine algorithms. However, the main limitation of this work is that the classifier may need to be retrained each time there is a sizable change in the monitored data for an anomaly detection system based on machine learning, and there must be sufficiently representative samples of the monitored data for training.

In Le & Zincir-Heywood (2021b), the authors proposed a machine learning-based user-centered system for insider threat detection, but there is no learning-based approach to achieve early detection. The proposed system was tested on the CERT (Software Engineering Institute, 2021) dataset. However, the limitation of this work is that once the system is trained, it is unable to detect other new types of attacks. A hybrid intelligent system for insider threat detection is proposed in Ren & Wang (2020). The hybrid system comprises pre-processing, rule matching, entity portrait, and iterative attention unit. The proposed system was evaluated on the CERT dataset.

Considering the information leakage problem caused by indexing in the cloud, the authors presented a three layers data protection framework in Squicciarini, Sundareswaran & Lin (2020). However, the methodology requires a pre-defined data classification. Misclassified data can be leaked. In Gomez-Hidalgo et al. (2010), authors have proposed named entity recognition(NER) based data leak prevention approach. However, the presented approach did not use semantic technologies to give meaning to entities. Consequently, NER could be affected by spelling mistakes and connected words.

Blockchain-based techniques

Presently, blockchain technology has been applied in various fields (Ali et al., 2020; Jamil et al., 2021; Iqbal et al., 2021; Jamil et al., 2020). To solve the data breach detection issues, numerous research works have been conducted using blockchain technologies. However, there are some issues that are not addressed by existing schemes. As such, a blockchain-based traceability system for insider threat detection is designed in Hu et al. (2020). However, the model discussed in the article does not explain how the framework will technically work. Additionally, no practical application example or solution is identified in the article. It is important that storing any data in some sort of structure requires a smart contract; however, this model does not share any knowledge of the smart contract at all. Additionally, long-lasting storage requires a smart contract on the blockchain network, which the authors do not mention in this study. Furthermore, this article did not organize how to store data evidence or fingerprints on the blockchain network. The lack of a proper framework will make this solution vague and impractical.

A blockchain-based event-driven data alteration detection system is proposed in Srivastava et al. (2021). However, the solution provided in the article is not using smart contracts on any public blockchain network. Additionally, the solution does not comprehensively comply with GDPR requirements such as “Forgetting Data”. The centralized application creates the wallet key generation, which can be exposed to cyber-attacks from the server side. Furthermore, the current system does not explain how technically the entire solution is built and what network or technologies are used to develop this whole system. Additionally, the data storage is inaccurately explained with regards to storing data in blocks.

The authors proposed a blockchain-based framework in Srivastava et al. (2019) to detect insider attacks in relational database systems. However, the solution provided by the authors addresses only the private data and centralized control system where a private blockchain network is created under a privately controlled environment without democratic participants. Additionally, attackers can temper any data or network within an organization regardless of whether the network is built on blockchain technology. Storing all proof within the same centralized controls or system can create an insider risk. Authors have used a fully private blockchain network, which means technically and logically, anyone inside that organization, if he has access, can also manipulate the private blockchain network. Even in this case, the whole organization becomes compromised. That is why using a public blockchain network is safe and secure.

Furthermore, the existing research work lacks GDPR complaint-based real solutions for data breach detection that Data Controllers and data protection authorities could use to determine whether there is a need to notify the affected Data Owners.

Summarizing the above discussion, we conclude that existing blockchain-based data breach detection systems suffer from several issues, such as non-democratic control in the private blockchain networks, questionable data trust under private organizations, lack of smart contracts, lack of authenticity of the owner and security issues in private blockchain networks, while existing non-blockchain-based systems suffer from problems such as non-transparency, non-immutability, training overhead, unable to detect encrypted data, domain dependent, dataset dependent, non-practical usage, vague framework, and GDPR non-compliant systems. Hence, designing a system capable of handling the abovementioned issues is challenging. Considering the limitations of the research works mentioned above, we have proposed a novel data breach detection system in this work. In our proposed model, we have comprehensively developed a GDPR compliant system with properly identified technologies using the Ethereum blockchain network.

General overview

To show how the system works, we discuss the use case scenario of the health sector. In hospitals, the collection and processing of personal data from patients have become a necessity today. Almost every department in a hospital deals with personally identifiable information and protected health information of patients. As a result of an insider attack, when a patient’s sensitive data are breached, it is not possible to restore privacy or reverse psychosocial harm. Moreover, these types of attacks not only pose a risk to the patient’s identity, but tempered data can also delay hospital operations and harm the patient’s health and well-being. Due to these operating delays, if emergency treatment is not received, this disease might result in death or lifelong disability.

Use case scenario

The objective of this section is to discuss the use case scenario of our proposed system. We assume that the data owner, Alice, is the patient in this case scenario, and the data processor Bob is a surgeon that often requests patients’ medical records for operation purposes. Figure 1 provides a high-level overview of the hospital use case, where Alice’s medical data are stored on the blockchain after receiving consent from Alice. Bob can obtain their desired patient data from the patient database by sending a request to the data controller Mike. Mike uses our proposed system to perform necessary tasks such as consent validation and data verification. Our proposed system allows Mike to detect any alteration in the database record and verify the authenticity of any record 24/7 before sharing data with Bob. The step-by-step method of the proposed system is discussed in the subsequent section.

Assumptions

The following assumptions are considered in this article while designing the proposed system.

1. The Data Controller and data protection authority are fully honest entities and do not have malicious intentions.

2. The database has one or more Data Controllers, and they have full access to the database. Thus, the Data Controllers can also modify the records of database tables and logs.

3. The attacker phishes the Data Controller and uses stolen credentials to access the Data Controller’s portal.

4. The database is clear from tampering or existing attacks at the very beginning.

Workflow of proposed system

In the context of the GDPR, there are four main entities, namely Data Controller, Data Owner, Data Protection Authorities, and Data Processor. The Data Controller defines the purpose of collecting and processing the data. The Data Controller decides why and how data will be processed. Generally, an entity that collects the data are known as a Data Controller. A Data Owner is a person whose data are processed. The data protection authority is an entity that guides the Data Controller in their duties. An entity that processes data on behalf of the Data Controller is known as a data processor or data consumer. However, the primary objective of our work is to provide Data Controllers with an automated tool to detect data breaches instantly. That will help them identify malicious activities and mitigate them before escalating further. This will also support the Data Controller in the process of performing detailed analyses and preparing breach reports concerning the reported personal data breaches. The proposed system’s step-by-step execution is demonstrated below:

1. Data protection authorities assign a Data Controller to do data entries inside their user data repository. The Data Controller accepts the Data Owner’s personally identifiable information (PII) such as first name, last name, email, phone number, age, address, and a dedicated Ethereum Request for Comments 20 (ERC-20) compliant wallet address; all are mandatory. The submitter, Data Owner, gives this information verbally by visiting the Data Controller’s office to be registered.

2. Once the Data Controller receives PII data, they enter these details into a dedicated application built with Nodejs/MYSQL centrally controlled by the Authority/Data Controller called “App Data Entry”.

3. This submission creates a “consent dynamic link” and sends it to the Data Owner’s email address or on their mobile. This link provides a consent panel called “Dapp 2 Data Consent”.

4. The Data Owner receives this link, which allows them to see their details on the page. To verify these details, they would be asked to use their Ethereum account, which they submitted at the registration time. The Data Owner uses their MetaMask Ethereum-compliant wallet to sign these details. The text is signed using the private key of the Data Owner, and they are only allowed to sign if they select the same address on their MetaMask, which was given to the Data Controller.

5. The “DAPP2 Data Consent” application sends this data signature hash and all relevant PII data to store inside the MYSQL database (off-chain). The Authority’s Data Controller verifies all data that have been given consent for the blockchain network.

6. It provides a unique identification primary (incremented) key against that new record and a timestamp.

7. The application creates a new transaction packet to send to the Ethereum blockchain network. This transaction packet is a Secure Hash Algorithm 256-bit (SHA256) hash (proof of record) created using an embedded string of the entire new record’s detail such as first name, last name, email, phone number, age, address, and a dedicated ERC-20 compliant wallet address. The SALT for this encryption is the user’s wallet public address.

8. To submit this new transaction on the blockchain network, the application “App1 Data Entry” retrieves the address of the latest version of the smart contract. Technically, to obtain the latest smart contract address, the “Main Data Relay Contract” must be called, which acts as a registry of all old or recent versions of the “Main Data Contract”. Since smart contracts are immutable, we cannot change any existing smart contract, but to add a new feature, we can create a new one. That is why relay or registry patterns can help organize new contracts without worrying about their address. Algorithm 3 presents how the main data relay activity takes place.

9. Once the application receives the latest correct “Main Data Contract” address, it sends the transaction packet of user identification number (UID) (“Record’s Primary key”), Timestamp, and SHA256 hash (proof of record) to the smart contract function called “AddRecordProof”. This function is highly restricted and can only be called by the Authorized person (Data Controller in our case) using the Data Controller’s Wallet Key (“Public and Private”) Cryptography. Functional access controls are defined in the “Security Layer Contract”, which has different security functions such as ownable and breaker. The concrete steps of security layer activity are shown in Algorithm 4 .

10. The “Main Data Contract” uses its storage library contract called “Data Storage Layer Contract” to store these data inside the smart contract. “Data Storage Layer Contract” is an independent contract compared to its caller. Separating the data storage layer gives the power to add or change any variable or structure inside the contract. It is impossible to change any variable after the deployment; therefore, creating a storage library using a dynamic array helps control the situation. On a successful transaction, a new hash is generated by the Ethereum, which is called a “Transaction hash”. Authority must pay the gas fees in order to record these data. Algorithm 1 presents how the main data storage activity takes place. While main data contract activity is presented in Algorithm 2 .

11. The third app, called “App3 Data Breach Viewer”, is strictly developed to view the record’s authenticity. It shows all the user records in a grid view with the “Verify” button. Clicking this button will send the request to the “Main Data Contract” function called “getRecordProof” using a newly generated SHA256 hash as an off-chain record identifier. This function returns the “Proof of Record” SHA256 hash to the application; this record was registered previously by the data collector.

12. The application backend retrieves the off-chained data record from the MYSQL Database and generates a new Proof of Record using SHA256. The proof of record from the smart contract and off-chained must be equal to be considered valid. Otherwise, a record is considered invalid or tampered with.

13. The compromised records are sent as a notification to the Data Controller. The compromised database can be replicated or updated to its original position using backup databases in the data center.

Simulation setup

The experiments were conducted on a Hewlett-Packard Laptop with 1.50 GHz Intel Core i7 and 8 Gb RAM running Windows 11. Table 3 presents the tools and technologies that were used to develop this system.

Simulation results

We built a blockchain network to set up the environment using the truffle console simulator. Ten accounts are created by the Truffle blockchain console node and then assigned to the Data Controller and Data Owners. The accounts created on the Ethereum network are displayed in Fig. 3. The network requires that each participant create an account with a private key and account ID. The smart contract is deployed once the network is operational, as seen in Fig. 4. A smart contract can be accessible by all network members once it has been distributed on the network by a single instance and has been added to the ledger. As a result, the smart contract will be updated and available to all participants. Since the smart contract cannot be changed, it validates the network security. The transaction hash, block number, and contract address are crucial elements that should be considered.

We can test the contract’s methods after deployment using the truffle test functionality. The Ethereum framework for developing, deploying, and compiling solidity contracts is called truffle. Solidity contracts are tested by truffle automation tests using the MOCHA framework. Following the deployment of the solidity contract, Fig. 5 depicts the contract’s execution as it is tested on our network. We can see from the test execution how long (in milliseconds) it takes to perform each contract method.

To verify the functionality of the proposed system, we created the following six sets of tests. System performance in terms of execution time for each test (gas consumption, breach detection/data integrity, consistency, access control/consent authenticity, immutability and time consumption) is shown in Figs. 6 to 11.

Gas consumption (test 1): To test Ethereum gas consumption, we have used a unit test framework written in JavaScript on each contract call. Using specific scenarios and parameters, we can see each contract’s time consumption, gas consumption, and speed.

Breach detection/data integrity (test 2): To verify the data integrity, if the database record is not tempered, we have retrieved the off-chained user record (R1 = SHA256 of first name, last name, phone, etc.), and compare it with the evidence hash H1 from the smart contract. If the comparison between R1 and H1 is equal, then it would be considered a true record.

Consistency (test 3): To examine the consistency of the system, we have checked whether or not the registry contract can retrieve the latest “Main Data Contract” address.

The Truffle Automated JavaScript testing framework is used in the scenario where one contract is deployed and inserted inside the registry contract. After calling the “GetLatestAddress” of the registry contract, it must return the newly deployed address of the “Main Data Contract”.

Access control and consent authenticity (test 4): To ensure security, every method in the “Main Data Contract” is restricted by Authority’s wallet address. The transaction is rejected if anyone calls the “AddDataByAuthority” without an authorized address. Furthermore, to verify the authenticity of the data owner and consent, we have checked whether the user has provided consent or not, as the requested data are signed by the data owner’s private key. Then it is checked with the data owner’s public address to see the correct signature validity.

Immutability (test 5): To check validity, if the main data contract has the valid address of the storage contract. Since all data that are being stored are supposed to be stored independently in a separate contract instead of the main contract, a comparison between the storage contract address and the contract address inside the main contract needs to be compared.

Time consumption (test 6): To calculate the execution time for writing data to the blockchain, we ran the addproof function for multiple data to calculate the time consumption of the contract function call.

GDPR compliance

To ensure compliance and determine whether the system is GDPR compliant.

The system is categorized into the following GDPR clauses. In Table 4, we have mapped our system features with each clause to ensure that the system was compliant. The proposed system offers capabilities to comply with the GDPR from an application standpoint. This is because of the following factors:

Art. 6 “Lawfulness of processing”: According to the criteria of the GDPR, the proposed system provides a setting to aid Data Owners in maintaining control over their personal data. This framework aims to meet the primary GDPR requirements, according to which Data Controllers will be able to request consent from Data Owners and inform them clearly and transparently about the data to be managed, as well as the purpose of processing.

Art. 7, 8 “Conditions for consent” & “Conditions applicable to child’s consent in relation to information society services”: Our proposed system can manage the data consent that allows Data Owners to easily control consent regarding access to their personal data and exercise their rights defined by GDPR.

Art. 12–14 “Transparent information, communication, and modalities for the exercise of the rights of the data subject” & “Information to be provided where personal data are collected from the data subject” & “Information to be provided where personal data have not been obtained from the data subject”: The proposed system constantly needs Data Owners to sign off on data migration on blockchain and consent requests. On each blockchain data migration event, data are signed by the Data Owner’s private key. Then, it is checked with the Data Owner’s public address to see the correct signature validity. The data are signed using the private key of the Data Owner, and they are only allowed to sign if he selects the same address on his Metamask, which was given to the Data Controller.

Art. 15, 16 “Right of access by the data subject” & “Right to rectification”: In our proposed system, no one can alter the data without the Data Owner’s permission. It allows Data Owners to request a copy of their data. It assists them in understanding how their data are being processed. If they find their data inaccurate or incomplete, they have the right to update and rectify the data.

Art. 17 “Right to erasure (right to be forgotten)”: When using blockchain for data storage, the question of whether the platform is GDPR-compliant arises since distributed ledgers are immutable, which means they can never be deleted. Our system fulfills this principle since data are kept off-chain and the Data Controller can delete them at the Data Owner’s request.

Art. 18 “Right to restriction of processing”: In our system, Data Owners have complete permissions to manage consent, including the ability to grant or revoke consent at any time or location by using the Consent Grant, withdraw and reject functions. On the consent withdrawal event, no one can perform the activities (Create, Read, Update, Delete) anymore on their personal data, which are set in the default policy when consent is granted.

Art. 20 “Right to data portability” The proposed system provides Data Owners the ability to access and download their personal information from the database. Data Owners can also request that the Data Controller send them a copy of their stored personal information.

Art. 33 “Notification of a personal data breach to the supervisory authority”: Our system has the ability to store Data Owners’ data off-chain. It generates irreversible evidence with a timestamp and stores it on the blockchain network. Every datum is turned into an evidence hash and stored with the unique ID of the off-chain data inside the smart storage contract. This system keeps every record’s proof on the network. This allows the system to detect any alteration in the database record. This will support the Data Controller in detecting data breaches and notifying the data protection authorities accordingly.