1. Introduction
Distributed systems have become one of the cornerstones of the contemporary computing model due to their compatibility with accelerated technology evolution in both hardware and software capabilities and functionalities. This compatibility is manifested in the ability to integrate independent computing resources and make them appear as a single coherent system [
1]. As a reflection of the nature of computing resources, distributed systems generally operate at two levels, the hardware level and the software level. While the responsibility for exploiting multi-hardware resources falls on the hardware level, the responsibility for making the software work in a distributed, integral, extendable and maintainable fashion, falls on the software level [
2]. Hence, software systems that run in a distributed environment, for whatever purpose, can be called distributed software systems. Distributed software systems which are derived from the features of distributed systems, bring many clear benefits for the users who adopt them, such as increased performance, flexibility and reliability [
3]. However, as a result of the natural complexity of distributed software systems, especially in terms of integration, they still face many outstanding challenges and threats, such as their required transparency and the consequent difficulty of management and their potential heterogeneity [
4].
In recent decades, it has become obvious that different kinds of cyberattacks using various methods constitute a real and rapidly increasing threat to distributed software systems. According to [
5], annual damage from cybercrime amounting to a loss of USD 10.5 trillion is expected by 2025. In addition, a study by [
6] indicated that an attack occurs every 39 s, which means that approximately 2244 attacks occur on average each day. Application vulnerabilities, insider attacks, and malware are still considered the most common forms of cyber-attack [
7], and therefore pose a direct threat to distributed software systems. Clearly, there is a need to deal with cyberattacks effectively to mitigate their consequences. Based on [
8], the cybersecurity framework should consist of five phases. If an attack has potentially occurred, the phase responsible for the initial attempt to counter the attack is the detection phase; therefore, more consideration for this phase is deserved.
Attack detection systems have many features and forms of classification. Initially, detection systems have three main functions, detecting the attacks, recording the detected attacks, and generating alerts [
9]. Furthermore, detection systems aim to achieve three main security criteria, confidentiality, integrity, and availability [
10]. In addition, detection systems employ two main analysis methods, data mining and pattern-matching techniques [
11]. The data mining analysis method focuses on adopting artificial intelligence techniques to perform the detection, while the pattern-matching analysis method focuses on creating patterns for either the attack or the target systems to perform the detection. Attack detection systems also perform in two styles: standalone style, where the detection system performs its tasks without the need to directly interact with other detection systems’ participants; or collaborative style, where groups of detection systems’ participants interact with each other directly in order to improve their detection experiences [
12]. Based on the target domain, attack detection techniques can be either Network-based systems or Host-based systems [
9]. In Network-based systems, the detection will act on the network level, including packages and communication control, while in Host-based systems, the detection will be at the host level, including processes and software activities.
Importantly, attack detection systems have three approaches [
13]. The first approach is the signature-based or misuse-based approach, where the main idea is to recognise the patterns of well-known attacks and then monitor the target system’s activities to detect such attacks based on their patterns. This approach has high performance but is inefficient at detecting zero-day attacks or any unknown attack strategies. The second approach is the anomaly-based or behaviour-based approach, where the main idea is to create target system profiles representing supposed “right behaviours”, where behaviour means a set of related events, with each event representing an interactive action that occurs in the system either internally or externally, and the ordered events collectively represent the system behaviour, then monitor the target system’s behaviour to detect attacks based on anomalies that may occur in conflict with the profiles’ details. This approach is more effective than the previous approach but assumes that the source codes for the target system will not be accessible when creating the profile. Therefore, profiles will be created based on several techniques, including some AI techniques, but these gained profiles do not provide all behaviours of the target system, including their correct but unusual behaviours. Consequently, high false-positive detection occurs by considering “correct but unusual” behaviour as an attack, which weakens the reliability of this approach. The third approach is the specification-based approach, which is considered in some studies as a sub-approach of the behaviour-based approach [
14]. The main idea of this approach is to operate analysis techniques on the source codes of the target system in order to extract all trusted behaviours for the target system. Then, during the runtime, just as in the previous approach, the technique will monitor the target system’s behaviour to detect the attacks based on any anomalies that may occur in conflict with the extracted behaviours. The main distinction between the second and third approaches is the reliability aspect, as the last approach should achieve high reliability due to the absence of false-positive detection, i.e., all truth behaviours are provided, so no false-positive detections are expected this not like the second approach [
12].
Table 1 shows the difference between the three detection approaches. These detection systems, especially standalone-style systems where no direct communication between the detection systems takes place, are commonly used in various cybersecurity products.
Our solution, as explained in the evaluation section with different scenarios, will detect any attacks to software in a distributed system that affects behaviour. These attacks can occur on any part of the distributed system software and not limited to the blockchain itself, given that the use of blockchain in the proposal architecture was based on the immutability feature provided in this technology. Examples of attacks that change normal behaviour include malicious code attacks and Denial-of-Service (DoS) attacks. However, some attacks do not affect the behaviour of the software directly; therefore, they remain undetected, such as shoulder surfing attacks and social engineering attacks.
However, behaviour-based attack detection techniques are facing challenges that affect their role to preserve distributed software systems against attacks. One of these challenges is ensuring the immutability of the data used for detecting the attacks. This data including both of the predefined trusted behaviours and the observed behaviours during runtime, are supposed to be unchangeable. In fact, such behavioural-based attack detection techniques have strict mechanisms in place that require high accuracy for any data and/or behaviours dealt with. Without these mechanisms the results obtained by these detection techniques will be wrong and thus unreliable. However, the potential vulnerability of stored and exchanged data in distributed systems, especially in terms of integrity, is that storage and extraction behaviours can alter during runtime. Hence, any direct or indirect effects on the data used for detecting the attacks will affect the data’s immutability and the whole detection systems’ results and thus its trustworthiness.
In addition, ensuring the reliability of detection systems is another challenge facing this kind of detection technique [
15] The reliability challenge comes from the fact that there is a need to ensure that the detection results provided by the attack detection techniques are correct and accurate. If the target system is a distributed system, there is a possibility that the results may be subjected to change if they have not been stored and transmitted securely. At the same time, the detection results have to be easily accessible without any access restrictions caused by security requirements. Hence, achieving the reliability for attack detection techniques that work for distributed systems is essential and must be achieved by balancing data security and accessibility. Therefore, and as a motivation for this research, more investigations to address these challenges are required.
From another perspective, blockchain has emerged as a cryptographic distributed data structure named “blocks” that can be shared and replicated among the independent network participants in a reliable manner [
16]. Accordingly, blockchain has several characteristics compared to other related technologies providing similar services, such as a distributed database. For instance, blockchain is a distributed peer-to-peer data structure and network with no trusted third parties between its participants. Thus, the concept of trusted third parties to serve as intermediaries in the blockchain is meaningless and unnecessary [
17]. In addition, blockchain is a shared, decentralised, and replicated ledger, where this ledger is readable, but it is append-only and cannot be removed or updated [
18]. Nevertheless, blockchain can be considered an application layer on top of many other forms of networks to easily interact with other Internet services and technologies [
19]. In
Table 2 below, the most important differences between blockchain and distributed databases are summarised to demonstrate the significance of blockchain technology [
20,
21].
From another perspective, blockchain networks can generally be categorised into two types: (1) Public-permissionless blockchain is an open network where any willing participant can join this network and view, read, and write blockchain. The availability of stored data and the full decentration from any form of authority are the main features of the public blockchain. However, confidentiality and privacy are not provided for public blockchain data. (2) A private-permissioned blockchain is a private network that allows predefined entries of verified participants, which private businesses prefer. While private blockchain does not achieve full decentralisation, it still achieves the blockchain principles for stored data in a distributed, private, and secure manner [
22].
In fact, blockchain relies principally on consensus algorithms which are considered the backbone of the blockchain. Consensus algorithms are “protocol sets that provide a technique with the help of which the users or machines can coordinate in a distributed and decentralised setting” [
23]. In the absence of the central governing authority in blockchain, consensus algorithms’ main role is to ensure the collective agreement by the majority of the blockchain entities on the blockchain about any action attempted to occur. Hence, consensus algorithms aim to achieve reliability, integrity, and security of the blockchain [
22].
Practically, every blockchain has various application scenarios. Thus, adopted consensus algorithms by blockchain need to be compatible with the requirements for each blockchain application. Hence, there are many forms of consensus that help to fit these requirements. The proof-of-work (PoW), the proof-of-stake (PoS), and the proof-of-authority (PoA) are the most popular consensus algorithms [
22,
23].
The PoW consensus algorithm involves a set of mechanisms that cause a considerable amount of effort when performing most of the network processing, such as mining new blocks. The purpose is to protect the blockchain against computing power-based attacks such as DoS attacks. More computing power nodes are often more likely to perform the mining and similar operations on the blockchain network, thus achieving the rewards [
23].
The PoS consensus algorithm applies a set of pseudorandom-based processes that determine the validator node for the subsequent blocks. The purpose is to distribute network tasks fairly among the network’s participants since the reward for the network process is not limited to the most computational power participants but instead is a right for everyone. Hence, PoS could provide a secure network against 51% of attacks given the fair distribution of tasks in the network [
22].
The PoA consensus algorithm grands authority for selected nodes in validating the transactions and other network tasks. As such, authorised nodes are considered as trusted entities for this blockchain and responsible for their security. The other nodes benefit from the network services and play a prominent role in monitoring the blockchain registry of their transactions and verifying the authority of their executors. Consequently, the transactions and other network tasks are performed significantly faster, which positively reflects on the network throughput. However, the concept of full decentralisation will be affected in this consensus algorithm as long as the majority of nodes do not have full authority, similar to the other consensus algorithms. However, there is a cost of obtaining high throughput and scalability. The PoA is secure against DoS and attacks and 51% of other attacks to some extent [
4].
Table 3 presents the main comparisons among the above-mentioned consensus algorithms.
Realistically, every distributed software system looking to leverage the blockchain must determine the blockchain type based on the nature and validity of the users’ access to the network. Additionally, based on the software scenario and requirements, the appropriate consensus algorithm should be determined. The appropriate blockchain network and consensus algorithm by each software are determined in light of the characteristics of each type, as mentioned above. For instance, if a distributed software system has been designed for a public business such as cryptocurrency, and is concerned about data immutability and availability and is not concerned about data privacy, where the throughput is not the ultimate goal for this system, thus a public blockchain that utilises PoW or PoS is a preferred choice for this software system.
Blockchain offers promising solutions for attack detection techniques to overcome their challenges. In terms of attack detection techniques and their immutability challenge, blockchain provides a solid solution through applying the immutable mechanisms of blocks mining and appending to the blockchain network, which can be adopted as a mechanism to store behavioural-based attack detection techniques’ data. Both trusted behaviours and the runtime behaviours detection techniques’ input data have a set of linked events that in total represent the whole behaviour. Once an event is generated, it can be mined in the same fashion as blocks mining, where each event depends on the previous event hash value as required data to mine the new event. Any attempt to make an unobserved change in an event block will require changing all previous blocks in the chain. Such an action would be costly computationally and easily noticeable by the other blockchain properties. Consequently, all of the behaviour’s events will be stored as linked blocks on a blockchain and once stored in this manner, any attempt to perform unobserved changes would be impossible. Therefore, the use of blockchain mining and storage mechanisms results in an increase of immutability for these detection systems.
In terms of the reliability challenges faced by attack detection techniques, blockchain can provide a solution through applying the distributed ledger recording mechanisms consensus protocol, to be adopted as a mechanism for the detection results announcement. In the blockchain, consensus protocols such as proof-of-work (PoW) and proof-of-stake (PoS) play a significant role in recording any mined block and/or any other transaction on the distributed ledgers in a non-repudiated manner, thus making the distributed ledgers more reliable. Applying consensus protocols such as these to record any detected attack will increase the detection techniques’ reliability at the level of exchanged data. In addition, abandoning the use of a trusted third party should increase the reliability at the level of participant communication. Therefore, it could be argued that blockchain can provide promising solutions for the challenges of immutability and reliability in attack detection techniques. However, it must be noted that the implementation of such mechanisms and protocols is not in itself a direct solution. There are many challenges facing the integration of blockchain with attack detection techniques, such as:
The right analysis of the software’s behaviour and correct arrangement of its events.
Determining the most appropriate data structure for the event to be properly stored as a block.
Determining the type of blockchain network best suited to attack detection techniques, either public or private.
Determining the most appropriate consensus protocol for these techniques.
This research seeks to explore these issues and to make the idea of integration possible.
In this paper, and based on the above-mentioned challenges and opportunities, we aim to make the following contributions:
To investigate the advantages of blockchain when it has been integrated with improved behaviour-based attack detection techniques.
To clarify to what extent we can address the current challenges of detection techniques in terms of data immutability and system reliability.
To address the detection techniques and blockchain integration challenges.
To design and develop our proposal to be compatible with the specification-based approach that has not previously been integrated with blockchain [
12]. Hence, we consider our proposal as the first novel proposal that integrates blockchain with a specification-based approach in one system.
To perform an experiment of our proposal for validation purposes.
It is important to mention that this article is a part of ongoing research aimed at investigating and analysing possible methods for improving the accuracy and the reliability of attack detection techniques through blockchain by exploiting the advantages of blockchain and through developing some of its characteristics, to achieve the research goals. The research objective is to provide two detection techniques styles, firstly, standalone detection techniques and secondly, collaborative detection techniques. From a research point of view, the purpose of developing the first detection style is to emphasise the significance of the research goals. Hence, the provided development and implementation at this stage was performed for conceptual validation purposes. On the other hand, the purpose of developing the second detection style is to demonstrate the full picture of the research outcomes in both conceptual and practical aspects. The following sections are an attempt to describe how to achieve this objective.
The paper is structured as follows:
Section 1 is the introduction to clarify the research domain, problem statement and research objectives.
Section 2 lays out the research methodology, focusing on how related studies have been collected and classified.
Section 3 consists of related works to highlight state-of-the-art studies as well as the field’s directions and limitations.
Section 4 is the proposal framework to illustrate our proposal, as well as its components and their functionalities, with more detailed explanations and diagrams.
Section 5 is the proposed experimental and attack models, which explains the environmental tools and how the experiment was performed.
Section 6 details our findings and discussion to explain the results and reflect on our research goal.
Section 7 is the conclusion, which summarises the project and outlines future work.
4. Proposal Framework
In this section, we will demonstrate our proposal’s design and its components in detail. By highlighting the proposal and its breakdown in a hierarchical structure and then demonstrating the proposal software system architecture by explaining its component functionalities, we will provide a detailed design for our proposal. In addition, the proposal’s implementation will be provided in the next section.
First of all, we would like to highlight our proposal’s five main features and their benefits in comparison to proposals from related studies.
Our proposal, to the best of our knowledge, is the first specification-based attack detection technique integrated with blockchain, which opens a new research direction in both detection techniques and blockchain fields.
Our proposal was designed based on generic distributed systems principles, thus it is compatible with and customisable for any type of distributed software system.
Our proposal is focused on extraction of the target system behaviours to provide a solid baseline for the detection technique and, thus, increase the detection techniques efficiency, instead of being distracted in identifying the various and renewable attack software behaviours, which is more computationally taxing and time consuming with less detection accuracy and efficacy.
Our proposal is producing a novel methodology to extract the runtime behaviours of the target system in such a manner that they will be stored in an immutable way.
Our proposal has leveraged extensively on the features of blockchain, going beyond its usual use as a secure medium to store data, into enhancing the immutability and reliability of detection techniques.
In the following subsections, we will highlight how our proposal exhibits all these features and benefits.
4.1. The Proposal and Its Breakdowns in a Hierarchical Structure
To begin with,
Figure 3 shows the proposal and its breakdown in a hierarchical structure. The top level in the hierarchical structure represents the
proposal from a technical point of view, which could be named Behavioural-based Attack Detection System via Blockchain for Distributed Software Systems.
The second level states that the proposed system consists of three integrated subsystems: Attack Detection Preparation (ADP) Subsystem, Runtime Attack Detection (RAD) Subsystem, and Blockchain Networks (BNs) Subsystem. The purpose of the ADP subsystem is to prepare both of the proposed attack detection systems by providing them with the required data and the target distributed software system by making it able to interact correctly and effectively with the runtime attack detection subsystem. The main objective of the RAD subsystem is to perform the proposed attack detection system on the target distributed software system, to report the detected attacks and to make suitable reactions in some cases. The BNs subsystem is responsible for managing the storage and retrieving behaviour and detected attack reports for both the ADP and RAD subsystems in an immutable secure manner.
The third level aims to state that each subsystem consists of a set of integrated techniques, each seeking to achieve its subsystem’s goal. For instance, one of the proposed techniques is Trusted Behaviour Immutable Storage Manager, which is located in the ADP subsystem; it is designed to store the extracted trusted behaviour in the blockchain in an immutable retrievable manner. We have already proposed, designed and implemented the majority of techniques in our proposal, especially where the techniques are relative to our research objectives.
The last two layers show two optional breakdowns: Components and Phases. In some contexts, we need to divide the proposed technique into several components in order to increase the readability of the proposal and to make the tracking and tracing easier and faster. Moreover, in some cases, we use the term ‘phase’ when the procedures of some techniques and/or components need to be explained in an ordered fashion.
4.2. The Proposal Deployment Architecture
The second feature of the proposal was designed to be deployed in any generic distributed software system. The key aim of the proposed deployment method is preparing the target system source codes through the ADP subsystem and then making the system run under the proposal supervision. Consequently, any target distributed software systems can be compatible with our proposal if the target system source codes are provided. Practically, the target system will include a part of the proposal in its structure as an output of the ADP subsystem processes. Additionally, during runtime, the target system will be monitored and controlled by the proposal to the extent of attack detection processes. The details of the proposed processes will be explained in the following subsection.
4.3. The Proposal Software System Architecture
Next, as shown in the following diagrams, we have a software system architecture for our proposal that involves three integrated subsystems and several interconnected techniques. The first subsystem we propose is the Attack Detection Preparation (ADP) Subsystem, which appears in the green L-shape border shown in
Figure 4. The main purposes of this subsystem are (1) to extract the trusted behaviours of the target distributed software system, e.g., website, to be stored in an immutable fashion through blockchain; (2) to generate an enhanced target system that is able to feed the Runtime Attack Detection (RAD) Subsystem real-time events that represent the runtime behaviours of the target system.
The ADP Subsystem consists of five main techniques that work in two directions as a reflection of the subsystem’s objectives. The first technique is Trusted Behaviours Extractor, which aims to analyse the source codes of the target system in the same manner as extracting the sequence diagrams from any other source codes, but in a text-based layout. In fact, this technique works similarly to reverse engineering technique principles, but it is more lightweight, as it simply reverses the source codes to text-based design descriptions. The output of this technique is lists of ordered trusted behaviour in text-based sequence diagram events linked with the behaviour form of the source codes, e.g., sequential, parallel, etc., in order to help RAD techniques work accordingly during runtime. The second technique is Trusted Behaviours Immutable Storage Manager, which is designed to store the trusted behaviour events on a static blockchain that has been configured to be updated only by authorised administrators and to exist as a read-only blockchain for the rest of the blockchain network participants. The third technique is Detected Attack Analyser, an optional technique that can access the reports of detected attacks on demand, in order to perform an offline analysis for the detected attacks as well as to perform some sort of long-term auditing to enhance the detection system’s functionalities. The above-mentioned techniques work in the direction of extracting and storing the trusted behaviours of the target system.
The fourth ADP technique is Enhanced Source Codes Generator, which takes the target system source codes, along with the extracted trusted behaviour events, as an input. The goal of this technique is to generate enhanced source codes that include new statements responsible for giving real-time events during the runtime. This technique works in a similar way as the Instrumentor applied in software testing systems, which analyses the source codes to add new statements that, when executed, will generate a set of test cases and their results [
38]. The fifth ADP technique is Source Code Compiler and EXE Generator, which easily compiles the enhanced source codes and makes executable files for the target system. These executable files will work exactly as the original target system should work, but they have the additional feature of generating real-time events to be fetched by RAD techniques. The last two ADP techniques work in the direction of generating an enhanced target system. In fact, ADP subsystem techniques functionalities show how the first and third features of our proposal are achieved.
The second subsystem proposed is the Runtime Attack Detection (RAD) Subsystem, located in the red rectangular border as shown in
Figure 5 below. The main objectives of this subsystem are (1) to monitor and fetch the target system’s real-time events during the runtime; (2) to perform the proposed detection mechanism based on the user/admin selection; (3) to store the extracted real-time events in an immutable fashion via blockchain. We should mention that the target system is run under the proposal supervisor, so the target system cannot work without running the attack detection system. Additionally, we proposed three detection modes and two detection mechanisms. Each detection mode, as will be described later, will determine the appropriate performance and performing order of detection mechanisms, as well as the way of storing the real-time events, either event-by-event or all events at once. The purpose of these detection modes is to achieve the optimal target and detection systems performance based on the sensitivity of the target system, i.e., higher sensitivity requires a stricter detection mode. The purpose of this detection mechanism is to determine the detection comparison level, which can be either at the level of event details implemented by the Each-To-Each Events Comparison technique, or at the level of the whole events sequence, number, and layout implemented by the All-To-All-Events Comparison technique.
The RAD Subsystem consists mainly of five techniques. The first technique is Runtime Subsystem Initiator, which is responsible for initialising the detection system, identifying the referred detection mode by the user, and importing the behaviour form of the target system from the static blockchain. The output of this technique is a package containing the detection mode selected by users, the behaviour form imported from static blockchain, and the location where the real-time events will be posted. Based on the result of the first technique, one of the three detection modes will be run. If the detection mode selected by the user was A (which means that no runtime attack detection is required), the Mode A Manager technique proposed for low-data-sensitive target systems will work as shown in
Figure 5a. Mode A Manager will simply execute the target system via EXE Executor technique and then fetch the real-time events through the All-Events Collector technique. Once the target system running the session is terminated, the Mode A Manager will not perform any sort of runtime detection mechanisms and will send all events, along with its behaviour mode and detection mode, to the Runtime Behaviours Immutable Storage Manager technique, which is responsible for storing gain data on the Runtime Behaviour Events Dynamic Blockchain. This blockchain is configured to be updated and accessed by any blockchain network participants for storing the real-time events, while the retrieval of their data is assigned to administrators and certain predefined participants.
If the selected detection mode was B (which means that runtime attack detection at the end of the session is required), the Mode B Manager technique proposed for moderately-data-sensitive target systems will work as shown in
Figure 5b. The Mode B Manager will execute the target system via EXE Executor technique and then fetch the real-time events through the All-Events Collector technique. Once the target system running session is terminated, the Mode B Manager will perform both detection mechanisms, the All-To-All-Events Comparison technique first, followed by the Each-To-Each Events Comparison. Both of these comparison techniques will call the corresponded trusted behaviours from the static blockchain as needed in order to perform the detection comparison. The results of these comparisons, either detected attacks or not, will be reported to the system user. This report will be stored on the Detected Attack Reports Dynamic Blockchain, which has the same configuration as the Runtime Behaviour Events Dynamic Blockchain but in a different data structure for the stored data. Simultaneously, all obtained real-time events, along with their behaviour mode and detection mode, will be sent to the Runtime Behaviours Immutable Storage Manager technique, which is responsible for storing the events on the Runtime Behaviour Events Dynamic Blockchain.
If the selected detection mode was C (which means that real-time attack detection is required), the Mode C Manager technique proposed for high-data-sensitive target systems will work. The Mode C Manager will execute the target system via EXE Executor technique and then fetch the real-time events through the Specific Event Collector technique. While the target system is running and the real-time event is fetched, the Each-To-Each Events Comparison technique and then the Runtime Behaviour Immutable Storage Manager technique will work, as described before, but in concurrency mode. The stored real-time events, in this case, will not be sorted for the whole session as is the case for the other mode managers; rather, it will be an event-by-event process, where the allocated details of each stored event can help related techniques to collect all related events in one unit, as desired. In actual fact, RAD subsystem technique functionalities show how the fourth feature of our proposal has been achieved.
The third subsystem proposed is the Blockchain Networks (BNs) Subsystem, located in the blue rectangular border on the right side of
Figure 6. The main objective of this subsystem is to provide an immutable, secure, transparent, and tractable storing and retrieving mechanism for the desired data that involve trusted events, real-time events, and detected attack reports to their corresponding blockchain. BNs consist of three private (permission-based) blockchains that have been mentioned and explained above. We chose to adopt the private blockchain given its compatibility with the majority of attack detection techniques and requirements, such as data privacy. However, it can also be a public blockchain if a particular detection system requirement is more conveniently compatible with public blockchain functionality in light of what has been demonstrated in
Section 1. Each of the proposed blockchains has a specific configuration and data structure for its data blocks’ body, based on their use scenario. The block is the unit of storage in the blockchain, which represents one event or detected report in our proposal.
Based on the Trusted Behaviours Extractor, the event header will be the same as any mined block, including timestamp, block ID, previous block hash, etc., wherein the event body structure looks like text-based sequence diagram data, as shown in
Table 4. Any potential attack will affect one or more of the event header or/and event body details and is thus easily detected. The report has a different data structure that is readable by human users and simultaneously readable by the related techniques. Consequently, the write (transaction)/read (call) from/to the blockchain could occur for one or several blocks, based on this technique’s mechanism. Furthermore, the consensus protocol adopted in our proposal is Proof-of-Authority (POA) since it is compatible with private blockchain functionalities. Additionally, because attack detection techniques require low latency and the high throughput of the transactions. That is because the response speed in terms of reading/writing data from/to the blockchain is an important requirement for attack detection techniques; otherwise, the reliability of these techniques will be affected. However, any consensus protocol can be adopted based on the desired system requirements, as demonstrated in
Section 1. In fact, BNs subsystem blockchains functionalities show how the fifth feature of our proposal has been achieved.
To sum up,
Figure 7 shows the proposal software system architecture, including the integration between all proposal subsystems as well as the full interactions between the subsystems’ techniques. In addition, it explains the symbols used in the diagrams, as well as their meanings.
6. Findings and Discussion
To start with, we should mention that this paper uses design science (DS) methodology in general. Iivari and Venable [
44] define design science research as an approach activity that builds novel artefacts for addressing issues or achieving improvement and establishing new means to achieve research goals. These methods create a new reality instead of explaining existing issues or trying to understand the existing reality. The methodology was chosen due to the need for innovation and reliable solutions for the problems. DS involves four main phases, namely problem identification, design, implementation, and evaluation that provide feedback to enhance the design again. This research achieves these phases as explained in the next sections.
Based on our literature review, detailed design, and implementation-based validation, we can state the obtained findings. Firstly, there is a significant benefit to utilising the specification-based detection method that has been applied in the ADP subsystem through extracting the trusted behaviours as well as generating an enhanced source code. In fact, the importance of this method is to reduce the false-positive rate in detecting system attacks to the lowest possible level—0%—due to its robustness characteristic, by identifying all the trusted behaviours of the target system, even unusual or rare behaviours, which makes attack detection systems more accurate.
In contrast, it could be stated that the optimal-automated implementation of the specification-based detection method to extract all trusted behaviours is a hard task. This is due to the high computational cost of determining and extracting all the trusted behaviours with a sufficient distinction between the expected overlapped behaviours. Additionally, the high cost of comparing the trusted behaviours with real-time behaviours during the runtime may require the application of some predictions and probability mechanisms during the fetching of the real-time behaviours to avoid any false-positive detection; this is another challenge facing this optimal-automated implementation. Hence, it could be argued that more investigations and improvement for specification-based detection automation is an essential area of this research field.
In our experiment, we applied two attack models to check the validity of our proposal. Clearly, as a consequence of applying the specification-based detection method, the proposal has detected both of the designed attacks. However, each proposed detection mode has a different rate of target system performance, as well as a different rate of detection response speed. That is because of the trade-off between the target system’s performance and detection speed, as a consequence of the required sensitivity level of the target system, as explained before. In
Figure 10, we present the observed difference between target system performance speed and detection response speed among the proposed detection modes.
As
Figure 10 highlights, Mode A has a high target system performance speed, while the detection response speed is slow. This is due to the low sensitivity of the target system. Thus, no high detection response speed is required in this mode, so no detection response will affect the target system performance. Mode B has a convergent performance between its target system speed and detection response speed. That is because of the moderate sensitivity of the target system’s data and hence the required moderate detection response for this mode, so the performance in the target system and the detection system will be moderate. Mode C, however, has opposite results to Mode A due to the high sensitivity of the target system, which requires a high detection response and subsequently affects the target system performance. Overall, the proposal has provided three detection modes in order to handle the trade-off between target system and detection system performance; the target system administrator can decide which detection mode is suitable for their needs.
Another finding of this research is the high efficiency of blockchain usage in attack detection systems. While some believe that blockchain can just be used as a secure data storage and sharing medium for this type of application, blockchain offers many other services and benefits. The immutability of stored data is one of the key features of blockchain that improve the robustness and accuracy of the detection techniques and thus the detection system’s overall reliability. In our proposal, the dependency and trustworthiness of the immutably stored behaviours are very high.
In addition, the transparency and non-repudiation of the stored data is another feature of utilising blockchain in detection systems; this feature comes from the fact that any behaviours will be recorded, along with its owner, whether they are trusted or real-time events, and will be accessible by all participants in the network. This feature is utilised implicitly in our proposal via the detected attack analyser technique, where it will be better exploited in the coming enhanced proposals. Traceability is another feature gained from blockchain, which allows for the tracing of a set of related events and then memorisation of the whole behaviour structure to be utilised as a trusted input of a detection mechanism designed for this level of detection. Overall, it could be argued that our proposal has achieved its objectives and overcome the limitations mentioned in previous proposals.
Based on our experiment, we can generally indicate that adopting blockchain in any detection system will increase the above-mentioned beneficial features in comparison to the detection systems that apply any other distributed method of data storage and exchange. However, it could be argued that as a consequence of the costly mining for each behaviour’s event, the overall performance may be affected, especially when data is written to the blockchain, where the effect is based on the applied consensus protocol such as PoW or PoA and network throughput. In fact, it should be said that these effects should be tolerated in order to obtain the required advantages of the blockchain. Therefore, it is observed that there is another trade-off between immutability and performance by adopting blockchain or not, respectively.