## 4 Proposal Framework
### The Proposal Software System Architecture
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. Figure 5: Runtime Attack Detection (RAD) Subsystem software system architectures for (**a**) Mode A; (**b**) Mode B; (**c**) Mode C.  
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,  
Figure 6: Software system architecture for Blockchain Networks (BNs) Subsystem. 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.