## 4 Proposal Framework
### The Proposal Software System Architecture
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  
Figure 4: Software system architecture for Attack Detection Preparation (ADP) Subsystem. 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. Figure 5: _Cont._  
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.