Artiﬁcial Intelligence-Driven Composition and Security Validation of an Internet of Things Ecosystem

: Key challenges in Internet-of-Things (IoT) system design and management include the secure system composition and the calculation of the security and dependability level of the ﬁnal system. This paper presents an event-based model-checking framework for IoT systems’ design and management, called CompoSecReasoner. It invokes two main functionalities: (i) system composition veriﬁcation, and (ii) derivation and validation of security, privacy, and dependability (SPD) metrics. To measure the SPD values of a system, we disassemble two well-known types of security metrics—the attack surface methodologies and the medieval castle approach. The ﬁrst method determines the attackable points of the system, while the second one deﬁnes the protection level that is provided by the currently composed system-of-systems. We extend these techniques and apply the Event Calculus method for modelling the dynamic behavior of a system with progress in time. At ﬁrst, the protection level of the currently composed system is calculated. When composition events occur, the current system status is derived. Thereafter, we can deploy reactive strategies and administrate the system automatically at runtime, implementing a novel setting for Moving Target Defenses. We demonstrate the overall solution on a real ambient intelligence application for managing the embedded devices of two emulated smart buildings.


Introduction
In this era of Internet-of-Things (IoT) and the 4th Industrial Revolution, intelligence is integrated into ordinary things. These smart devices are composed in complex systems, forming ambient intelligence and pervasive computing applications (e.g., [1][2][3]). Case studies include among other assisting living, smart transportation, and e-health. Thus, design technologies are becoming imperative in order to guarantee the desired requirements of a heterogeneous system-of-systems, like security, privacy, and dependability (SPD).
During the lifecycle of a system, quantitating and measuring its features plays a significant part of the applied risk analysis. Industrial and scientific enterprises, such as the Ford Motor Company [4] and NASA [5], apply formal techniques to verify that the implemented systems and their counterparts guarantee the mission critical properties and achieve the intended design goals.

Security Validation
However, the aforementioned general composition methods do not take into consideration the special intrinsic of security. Theoretical works for secure system composition are presented in [36][37][38][39]. In [36], the authors document a set of composition theorems which can prove protocols' security under standard stand-alone and compositional definitions of security. The study in [37] documents a formal validation of automated policy refinement. The analysis evaluates the management procedures in network security systems. It formally validates policy hierarchies for model-based management and propagates from an abstract level to its immediate lower neighbor. The outcomes are two theorems that ensure the compliance among the actual system behavior and the abstract design policies. In [38], methods of concurrent general composition and universal composability are examined on public-key models and scenarios with no trust infrastructure. Newer studies [39] update the security composition theory with properties like mitigation of eavesdropping and identity faking. Therefore, a modeling framework is proposed [39] for security verification and is applied in distributed and industrial IoT infrastructures. The framework performs model-checking techniques and the overall analysis is supported by the Alloy Analyzer [40]. Yet, theoretical works cannot be immediately applied in real and dynamic systems. Nevertheless, the deduced security and composition outcomes are considered by practical solutions and developed tools for more robust formal documentation.
Also, in the field of Knowledge Representation and Reasoning event-driven model-based approaches are suggested to better express the dynamic behavior of the IoT ecosystem in a formal manner. Thus, security verification techniques are additionally proposed to tackle this issue (e.g., [41][42][43][44]).
SMoLES-SEC [41] integrates the Security Model Analysis Language (SMAL) [41] to the pure SMoLES. SMAL embodies security extensions to the DSML's meta-model composition and defines access control policies for IoT settings. However, the reasoning capabilities are bounded due to this constrained expressiveness. Also, SMoLES-SEC fails to define the security features which are valid after the composition as well as the overall security status of the composed setting.
The study in [42] proposes a framework for runtime enforcement mechanisms. An analyzed system is modeled as an automaton. Then, the framework can track a sequence of states and events to derive Appl. Sci. 2020, 10, 4862 5 of 32 wherever the security policy constraints are satisfied at runtime. The enforcement mechanism develops two main operations: (i) allows legal functionality without changes and (ii) blocks illegal functionality.
A modeling and visualization tool for security evaluation and secure system management is presented in [43]. Threat modeling is applied in the composed setting for the evaluation of metrics at the architectural level. Then, hierarchical presentation of security metrics is performed based on decomposition methods for the measured security objectives, while deriving the overall security status.
The work in [44] proposes IoT service secure composition verification based on Service Dependency Trees (SDTs). Each IoT device node builds its own SDT, denoting the external service nodes that the provided services are depending on. Also, each node may be aware of all recursive SDTs for its composed services. Henceforth, secure service composition can be assessed by permitting only integration with SDTs were all the paths and involved entities are considered trusted. However, constructing a SDT for a real IoT system is not ease, as well as, their consistency and trustworthiness in an actual complex and dynamically composed setting become challenging.

Quantifying Security
To further quantify the security of an integrated setting, we have to measure the security of the underlying components and afterwards calculate the total protection. One main methodology to measure the provided security for a system is the medieval castle model [45][46][47]. The system is considered as a castle with doors that the attacker tries to break through. The infiltration is successful, when the attacker passes the doors and reaches the protected treasure rooms (e.g., assets which the deploy defense mechanisms try to safeguard) in the inner layers of the castle/system. The difficulty of bypassing these doors and reach the inner treasure rooms designates the provided security level for this castle/system. A door represents a security mechanism with the resilience to assaults being assessed by related metrics. The overall method can evaluate the defense of static system instances. However, it is not directly applicable for dynamic system analysis.
Other approaches include the attack surface metrics [48][49][50][51][52][53] and multi-metric approaches [4,54]. A literature review for attack surface studies is conducted in [48]. Such methodologies (e.g., [49][50][51][52][53]) take into account that the attacker will utilize the system's channels, methods, and data elements to infiltrate the system. The set of these elements at the entry/exit ports which could be exploited by attackers, define the system's attack surface. Quantitative methods assess the damage potential-effort, determining the surface's size. In [4,54], multiply quantitative metrics are incorporated and capture the system's protection aspects. The various metrics take the form of vectors with each factor evaluates a specific property, such as Security, Privacy, Dependability, and/or Usability. The measured values are in the range of 0-100 (modelling no to optimal satisfaction) and easy the composition of several metrics as well their comparison. Thereby, meta-heuristic methods are applied to assess and visualize the offered parameters of the current system setting.
Moving Target Defenses (MTDs) [55] constitute an active and offensive protection strategy where the system configuration and setting is changed, either periodically or as a response to an occurred event, in order to harden the analysis of the system by an attacker or to mitigate ongoing attacks. Such solutions can incorporate security metrics in order to better evaluate the protection level of each potential system state. The study in [56] implements MTDs by exploiting the attack surface metrics. The proposed framework measures the distance of the security surface between different system states. The goal is to administrate responses to attackers' probes, so as to induce an external view of the system that complies with specific desirable properties. Minimizing the cost for the defender is also considered the study in [57] presents a multi-metric-driven management framework for e-health digital environments. The method is applied in e-health settings for chronic diseases and utilizes three metric categories. Risk-driven security engineering and assurance metrics are established at deployment-time, providing an early evaluation on the effectiveness of the deployed security. Continuous security monitoring metrics get assigned at operational-time and support the security correctness assessment, improved systematization as well as traceability among the various metric outcomes and product requirements. Then, automated adaptive decision-making metrics can be estimated at operational-time and achieve higher quality security effectiveness understanding in operational security monitoring and future versioning of the examined setting. The framework performs continuous security monitoring along with metric-driven fully-or semi-automated security decisions.
A first theoretical work for the measurement of security is conducted in [58]. The authors document a formal model for the representation and evaluation of security metrics and define a set of relevant metrics. Therefore, they examine associations to derive more secure metrics. In contrast to the above-mentioned practical solutions (e.g., [45][46][47][48][49][50][51][52][53][54][55][56][57]), which take into consideration only the structural aspects of the system, the authors conclude that a potential metric can be assumed good or bad based also on the attacker model.

Comparison
In this work, we present the CompoSecReasoner framework that monitors system and the ongoing changes, and evaluates the security, privacy, and dependability status. CompoSecReasoner utilizes an event and model-based approach and it implements dynamic system composition verification, properties validation, and automated administration based on metrics. As we know, no such method has been developed so far, combining the four design operations which are described in the introductory sections.
For the composition verification procedure, CompoSecReasoner presents a novel feature, defined as operation (see Section 4.3). An operation is a series of actions (such as protocols and technologies) that two components have to execute in order to be incorporated and work together. The abstraction level that is offered under this formalism is sufficient for modelling an actual application domain, in contrast to the interface and input/output proposals which are becoming quite modelling-intensive in the field of heterogeneous embedded systems.
For system properties validation, related methodologies apply either pre-or post-validation techniques, modelling a relevant sub-set of composition situations. CompoSecReasoner uses both validation types by enforcing rules during the composition procedure (pre-validation) and model-checking afterwards (post-validation). The overall validation procedure is implemented by a set of functions which are performed for each evaluated property. The procedure is further enhanced with the metrics characteristic.
For the core metrics formation, we adopt the well-studied techniques for attack surface calculation and medieval castle composition. The discussion of the underlying metrics is detailed in Section 2. The old surface metrics [49][50][51][52][53] consider only security as a system property and do not estimate the protection level. Moreover, the castle composition methodology evaluates static instances of a system. The SPD surface aggregates an analysis regarding security, privacy, and dependability while the SPD multi-metric reveals the provided protection level of the current setting. Finally, the composed SPD multi-metric tackles the measurement aspects of dynamic system composition and the added protection of subsequent layers of defense.
All these features contribute to a better understanding of the composition and SPD aspects. This enables the dynamic evaluation of the various system states and development of more effective MTDs. The implementation of CompoSecReasoner supports distributed reasoning as well as conflict resolution among the involved SPD agents [59].

Materials and Methods
This section details the measurement methodologies that are utilized by CompoSecReasoner. Initially, we introduce the core measurement method for estimating the SPD level of a single system component, which is based on our previous work, detailed in [60]. Here, we present the main concept. Then, we describe the extended version that is proposed in this paper for evaluating the composition of different components and systems (Section 3.3).

Attack Surface
Consider a man taking refuge inside a mountain to avoid lightning. The physical barrier provides full protection. Every hole in the mountain or any other mean to cause harm to the man reduces his defense.
The attack surface metrics [52] consider that attackers would utilize the system's communication channels, methods, and data to infiltrate the system. The attack surface is designated by those elements at the entry and exit points which may be exploited by attacks. A threat is successful if it enables direct or indirect interaction with a protected asset. Microsoft developed the Relative Attack Surface Quotient (RASQ) [53] and formally quantified the relative attackability of the Windows server operating system platforms. The metric's outcome is further assessed against real vulnerabilities (based on related reports in the Computer Emergency Response Team (CERT) and Common Vulnerabilities and Exposures (CVE) databases).
These dated surface metrics take into consideration only the security perspective. While the conventional viewpoint that a hacker will choose a high privilege process for a potential attack seems correct in several occasions, he/she can also target a method with lower privileges which accesses sensitive personal data. The aforementioned metrics would falsely result that the second method is the least presumable to be exploited, with low influence in the attack surface. Same as with dependability, components with several dependencies or methods that are mission critical may be more valued for the hacker's perspective than a method with administrator access rights.
Based on these studies and the attack surface formal basis, we proposed the SPD surface to evaluate the properties of a system [60]. As the individual analysis of the three SPD properties produces erroneous conclusions regarding attackability, the SPD surface evaluates the aggregated effect, resulting a more precise analysis and better design. Figure 1 illustrates the main SPD multi-metric concepts, which are detailed below.
Appl. Sci. 2020, 10, x FOR PEER REVIEW 9 of 33 evaluates the aggregated effect, resulting a more precise analysis and better design. Figure 1 illustrates the main SPD multi-metric concepts, which are detailed below.

Figure 1.
The main SPD multi-metric concepts of a system. The interaction points are located at the boundaries of the system's surface. Controls are placed along the dataflow to protect the system. The damage potential-effort ratio (DP-E) represents the opportunity to exploit a dataflow.
Not all threats contribute the same. Some resources are more likely to be attacked or an attacker may gain higher benefit from exploiting specific resources. An involving system resource introduces possible threat flows (TF). We analyze the system and determine the TFs where interaction between threats and assets is possible. For each of these flows, the damage potential-effort ratio (DP-E) is calculated, representing the flow's significance in the SPD surface. The higher the potential damage (or the lower the effort), the higher the flow's confluence in surface. As a result, the smaller the surface (lower assets' exposure) the higher the protection. The analysis is further enhanced with the contextual notions of standards and well-known evaluation methodologies for security, privacy, and dependability (   Not all threats contribute the same. Some resources are more likely to be attacked or an attacker may gain higher benefit from exploiting specific resources. An involving system resource introduces possible threat flows (TF). We analyze the system and determine the TFs where interaction between threats and assets is possible. For each of these flows, the damage potential-effort ratio (DP-E) is calculated, representing the flow's significance in the SPD surface. The higher the potential damage (or the lower the effort), the higher the flow's confluence in surface. As a result, the smaller the surface (lower assets' exposure) the higher the protection. The analysis is further enhanced with the contextual notions of standards and well-known evaluation methodologies for security, privacy, and dependability (Open Source Security Testing Methodology Manual (OSSTMM) [61] and Common Criteria Evaluation Methodology (CEM) [62] for security, ISO/IEC standards 27018 [63] 29100 [64], and the European General Data Protection Regulation (GDPR) for privacy, and IEC standard 60300 [65] for dependability).
The DP-E ratio of a TF integrates three primary ratios for security, privacy, and dependability, respectively. In security, the damage potential (DP) ratio reflects the method's privilege. The effort for the attacker is determined by the access rights of the examined method. In privacy-related interactions, DP is defined by the personal identifiable information (PII) type. The actuator's type, who processes the data, prescribes the effort. In dependability, DP is derived from the component's criticality. A component's dependency on other counterparts determines the effort. Table 2 details the DP-E parameters and the values that are applied in CompoSecReasoner. The values' assignment relies on the respective formal analysis of the primary attack surface metric [49,52]. The damage potential in case of a successful exploit on the legitimate system ranges from 1 (low damage) to 5 (high damage). The effort that the attacker has to devote to perform an attack ranges from 1 (low effort) to 4 (high effort). For each TF, the DP-E ratio is calculated by summing the related DP rates and dividing with E: where TF DP-E is the total DP-E ratio for a TF, [*] DP resembles the damage potential for each SPD property, while [*] E represents the related effort for each SPD property. The surface for a system is the DP-E summation for all TFs: where Surface sys is the system's surface and TF DP−E represents the summation of all underlying DP-Es.

Protection Level
At this point, the surface metrics reveal the attackability of a system, but not the protection level. The SPD multi-metric methodology further extends the system's surface with the porosity feature. The TFs in the surface constitute the system pores where interaction among threats and assets is possible. Every TF is disassembled in security, privacy, and dependability pores, called Access, Trust, and Complexity pores respectively, representing its effect in the three SPD properties respectively. The system designer places controls (defence mechanisms) to protect the pore from attacks. Limitations form known conditions under which a control does not work properly. If all types of controls are placed for a pore and work correctly, full coverage of the interaction point is achieved.
Controls are the means that are applied by the system to restrict a threat's impact and increase the separation with the assets (e.g., protection mechanisms imposing authentication, confidentiality, or integrity). Two control types are described: (i) interactive controls which affect directly the operation when the interaction happens; and process controls which influence indirectly the operation by safeguarding the assets after the interaction's occurrence. Totally, 12 interactive and 14 passive controls are defined based on the aforementioned relevant security, privacy, and dependability standards. Table A1 in Appendix A summarizes these controls.
The applied controls of each pore are identified. At least one instance of each control type must be acquired in order to accomplish the perfect coverage for the pore. All of them contribute equally to a pore's coverage. The porosity value is defined as the TFs' summation, called PorosityBase. Perfect coverage for the two control types, defined as PerfectCoverageInteractive and PerfectCoveragePassive respectively, is denoted as: (3) Limitations represent the inability for the defense mechanisms to work properly. They indicate the SPD state in regards to known restrictions and flaws. Six limitation types are modelled. Vulnerability, disclosure, and exposure limitations harm security, privacy, and dependability pores respectively. Weakness and concern limitations decrease the positive contribution of interactive and passive controls respectively. Anomaly limitations (faulty situation that cannot be controlled) state unidentifiable elements that are nor observed during the normal operation. A proper audit should take into account any anomalies as such situations cannot be controlled. They obstruct all three SPD factors and their effect is aggregated to each factor's evaluation.
For each pore, the deployed controls must be denoted. Then, the contribution of the relevant limitations on the deployed controls is measured based on the attack potential risk analysis that is described in CEM [15]. It is a function that assembles the hacker's preference, expertise, motive to presume upon specific limitations and attack particular assets, as well as, the resources that he/she is ready to dedicate in achieving his/her goal.
The function is further extended to cover not only successful wily attacks but the generic notion of a threat as well. Therefore, five factors are considered for the analysis of a potential threat: -Required time: The period that it takes (e.g., days or weeks) to detect and exploit a limitation. -Expertise: The technical knowledge and skills required (e.g., copy-cat, advanced, or expert). - Knowledge of the target: Familiarity with the victim's system and operation (e.g., public, sensitive, or critical knowledge regarding some subsystems, etc.). - Window of opportunity: Hackers may need appreciable access to the system to successfully presume upon a threat while avoiding detection. - Resources: The required software, hardware, or other equipment (e.g., common or specialized resources).
Henceforth, the exploitation possibility of a threat is categorized as basic, enhanced basic, moderate, high, or beyond high. The method does not examine every likely scenario but derives a good indication concerning the defense status in accordance with standard ratings.
The distinct values of each parameter could denote high protection. Nevertheless, a limitation can ease the exploitation of other ones, ending up with a lower defense state after all. Thus, in the SPD measurement, the assigned rate of each of the three individual limitations (L V for vulnerability, L D for disclosure, and L E for exposure, respectively) is calculated as the weighted summation of the related distinct ratings: V V , V D , and V E , respectively. Then, these results are divided by the attackability of the specific pore type (Access pores for vulnerability limitations, Trust pores for disclosure limitations, and Complexity pores for exposure limitations, respectively): The impact of the weaknesses and concerns is determined by measuring the absent interactive and process controls, divided by the PerfectCoverageInteractive and PerfectCoverageProcess, called L W and L C , respectively. Similarly with the relevant controls, the two limitations affect all three SPD parameters.
Anomalies cannot influence SPD by their own. The side-effects are considered in the presence of other limitations and estimated as their quantity divided by the sum of PerfectCoverageInteractive and PerfectCoverageProcess, called L A .

Measurement
The surface and the protection level analysis are integrated. The overall method calculates the actual protection level by integrating the risk analysis for the attackable points with the efficacy of the deployed defense mechanisms.
The outcome is a triple vector of Security, Privacy, Dependability representing the total SPD of the system. The final SPD vector reflects the perfect separation (100) subtracting the weighted sum of the limitations' impact: where W * represents the threat bias of each limitation type (as in Microsoft RASQ [53]).
The SPD evaluation is a function of separation among the possible threats and the defended assets. Each property's value falls in the range of 0-100, with 0 represents no defense and 100 full coverage and separation among the assets and threats. It has to be noted that the absolute SPD of 100,100,100 does not guarantee absolute protection. This designates that all required defense mechanisms have been deployed for all possible interaction points and set correctly, based on the current set of known limitations (e.g., CVE bulletins or CERT reports). Higher rating reveals redundancy of defense mechanisms, as well as, higher operational/implementation expenditures.
More information on the SPD multi-metric and the performed analysis can be obtained in the initiatory article [60].

Medieval Castle Approach
The medieval castle approach [20] is the main method to assess the security of composed systems. A system is considered as a medieval castle with security doors that constitute the target for assaults. Assaults are succeeded if they disrupt the castle's doors and reach the treasure room inside-the assets that the security mechanisms are safeguarding. The difficulty of breaking through the doors and reaching the treasure room reflects the security level for this castle/system. Each door represents a deployed security mechanism in the system and its resistibility in assaults is estimated by related metrics.
To quantify security, we have to measure the security of the system's sub-components and then calculate the overall protection based on composition rules. Figure 2 portraits the main settings of system composition under the medieval castle analysis. Circles designate protection mechanisms while the dashes represent the related doors (attack points). The assets are modelled as the black center of a circle. The SPD evaluation is a function of separation among the possible threats and the defended assets. Each property's value falls in the range of 0-100, with 0 represents no defense and 100 full coverage and separation among the assets and threats. It has to be noted that the absolute SPD of 〈100,100,100〉 does not guarantee absolute protection. This designates that all required defense mechanisms have been deployed for all possible interaction points and set correctly, based on the current set of known limitations (e.g., CVE bulletins or CERT reports). Higher rating reveals redundancy of defense mechanisms, as well as, higher operational/implementation expenditures.
More information on the SPD multi-metric and the performed analysis can be obtained in the initiatory article [Error! Reference source not found.].

Medieval Castle Approach
The medieval castle approach [20] is the main method to assess the security of composed systems. A system is considered as a medieval castle with security doors that constitute the target for assaults. Assaults are succeeded if they disrupt the castle's doors and reach the treasure room insidethe assets that the security mechanisms are safeguarding. The difficulty of breaking through the doors and reaching the treasure room reflects the security level for this castle/system. Each door represents a deployed security mechanism in the system and its resistibility in assaults is estimated by related metrics.
To quantify security, we have to measure the security of the system's sub-components and then calculate the overall protection based on composition rules. Figure 2 portraits the main settings of system composition under the medieval castle analysis. Circles designate protection mechanisms while the dashes represent the related doors (attack points). The assets are modelled as the black center of a circle. Assume that d constitutes a castle's overall protection level. Castle Figure 2A is the simplest composition set, with the assets been safeguarded by a single door. The castle's security is equal with the defense level of this door. The other castles have two doors (dmax and dmin). Consider that dmax is stronger than dmin. Castle Figure 2B deploys two doors at the same layer, allowing concurrent assaults on both doors. The castle's security is equal to or weaker than the security of the weakest door (we presume that offending dmax could further weaken the protection at dmin). Castle Figure 2C deploys the two doors in a sequential manner. To reach its assets, attackers have to pass through both doors. The security here is stronger than Figure 2B and is at least as good as the defense of dmax. In the composition Assume that d constitutes a castle's overall protection level. Castle Figure 2A is the simplest composition set, with the assets been safeguarded by a single door. The castle's security is equal with the defense level of this door. The other castles have two doors (d max and d min ). Consider that d max is stronger than d min . Castle Figure 2B deploys two doors at the same layer, allowing concurrent assaults on both doors. The castle's security is equal to or weaker than the security of the weakest door (we presume that offending d max could further weaken the protection at d min ). Castle Figure 2C deploys the two doors in a sequential manner. To reach its assets, attackers have to pass through both doors. The security here is stronger than Figure 2B and is at least as good as the defense of d max .
In the composition Figure 2D, there exist two castles that the wily attackers could mark. The assault is successful if it reaches at least one protected resource. However, it is assumed that the distance between the two castles is too long to enable concurrent assaults (e.g., we assume that an attacker will launch either a DoS attack on a web service or an on-line password guessing attack on the authentication service, but not both simultaneously). Thus, the interval of d min and d max determines the overall security in this setting.
Totally, three core composition operations are specified: The mediaeval castle analysis can be performed for more complex compositions as well, disassembling complex castles of any doors' topology. Based on the core composition operations, attack trees can represent the strain to infiltrate the system from the external protection layers. More information on the overall medieval castle methodology can be obtained in the primary article [45].

Composed SPD Multi-Metric
In this subsection, we describe the composed SPD multi-metric method which it is proposed in this paper. The SPD evaluation is applied as the basic metric to assess the defense level of the distinct system components. Then, the core security concept of the medieval castle analysis is extended with the SPD perspective. SPD multi-metrics are incorporated in the medieval castle approach, acting as a systematic methodology to estimate the protection of the castle's "SPD doors". The result is the integral SPD of the currently composed system, which progresses the medieval castle composition analysis and covers the requirements of two premier real-time SPD modelling features, as they are detailed below.
However, only static system instances can be examined under the medieval castle approach. On the other hand, the proposed method assesses dynamic systems with de/composition events changing the overall composition and SPD aspects at runtime. For instance, two sub-systems could be secure in some aspect, but their composition might not be necessarily safe in the same aspect. The composed SPD multi-metric enforces pre-and post-composition validation. Initially, it derives if the composition is feasible. Afterwards, it concludes the composition's result and its side-effects. Decomposition events are handled in a similar manner.
In an actual system, the deployed defenses at the various layers could interact with each other. This concept is not covered sufficiently by the castle analysis. In the proposed method, the missing controls of the SPD multi-metric are covered by the related controls which have been deployed in the adjacent outer layers, capturing the increasing defense of the interacting subsequent protection layers. Such as, consider an insecure data exchange service which can be defended by a secure communication service performed at the network layer, offering integrity, authentication, and confidentiality. The total SPD reflects the overall control coverage which is accomplished by the current composition.
The method is mounted in the ambient intelligence filed of a smart home. The idea is that every business that provides a smart home component (e.g., embedded equipment or software applications) will calculate the main SPD multi-metric features in advance. Then, the user buys on-the-self products. The in-house composed SPD multi-metric evaluates the final SPD, once these products are getting installed.
In a common installation, the deployed smart devices observe ubiquitous factors and interchange data. The user manages to the overall setting with computer or smart phone. We implement a smart home system with smart devices for assisting living conditions. The house includes a laptop and several smart devices (i.e., surveillance cameras, TV, air-condition, printer, fridge, etc.). A wireless router creates a LAN, interconnecting all equipment, and permits external connection with Internet. This smart home composition is depicted in Figure 3.
Initially, the SPD multi-metric of each distinct element (i.e., laptop, smart devices, and router) is measured. Afterwards, these ingredients can be integrated based on the medieval castle composition operations (the composed SPD assessment is detailed in Sections 3 and 4). These components are composed to a LAN with MEAN-operations, the LAN is composed with the router with an OR-operation, while the router is composed to Internet with an OR-operation. Figure 3A illustrates the overall composition. Attackers could penetrate the home router via Internet and then attack the rest components in the LAN. In Figure 3B, the legitimate user connects the LAN with a smart phone (MEAN-operation). The SPD is measured as in Figure 3A. However, in Figure 3C, the user connects the LAN similarly as Figure 3B (MEAN-operation), but here the phone also deploys its own mobile Internet connection (AND-operation with Internet). Hackers are given now an alternative port to infiltrate the system via the mobile Internet connection.
Appl. Sci. 2020, 10, x FOR PEER REVIEW 14 of 33 the LAN similarly as Figure 3B (MEAN-operation), but here the phone also deploys its own mobile Internet connection (AND-operation with Internet). Hackers are given now an alternative port to infiltrate the system via the mobile Internet connection. A user-driven scanning tool is implemented in Java to assist the SPD evaluation. Most evaluation steps that are mentioned above are automated, leaving a specific set of actions to the user. For the SPD multi-metric, this tool identifies the resources and the high-level entry and exit ports that constitute the surface. The user specifies which of them confluence the porosity and designates the appropriate controls. The tool performs the potential-threat analysis for the limitations and the estimation of the relevant values. Finally, the user matcher the limitations to controls and pores, with the software estimating the SPD level. System designers could easily test different configurations and deduce the best SPD for an examined setting. For the composed SPD multi-metric, the user must also define the composition operation types.

CompoSecReasoner
CompoSecReasoner acts a practical framework that captures the dynamic nature of a system with new sub-components (for which some SPD aspects are known) are incorporated into the main pre-existing one. In our work, we examine the secure composition procedure for systems-of-systems. As a case study, we study heterogeneous embedded ecosystems in the IoT domain which are composed and materialize a new system. We apply a systematic method to evince that the deployed technologies are actually composable under a metric-driven composition strategy and the composed result accomplishes the desired SPD features.
CompoSecReasoner can be utilized for secure system design and offers systematic verification of the underlying systems. The metric-driven strategy can be used for the comparison of different ongoing designs and extract the best ones based on their SPD properties. A user-driven scanning tool is implemented in Java to assist the SPD evaluation. Most evaluation steps that are mentioned above are automated, leaving a specific set of actions to the user. For the SPD multi-metric, this tool identifies the resources and the high-level entry and exit ports that constitute the surface. The user specifies which of them confluence the porosity and designates the appropriate controls. The tool performs the potential-threat analysis for the limitations and the estimation of the relevant values. Finally, the user matcher the limitations to controls and pores, with the software estimating the SPD level. System designers could easily test different configurations and deduce the best SPD for an examined setting. For the composed SPD multi-metric, the user must also define the composition operation types.

CompoSecReasoner
CompoSecReasoner acts a practical framework that captures the dynamic nature of a system with new sub-components (for which some SPD aspects are known) are incorporated into the main pre-existing one. In our work, we examine the secure composition procedure for systems-of-systems. As a case study, we study heterogeneous embedded ecosystems in the IoT domain which are composed and materialize a new system. We apply a systematic method to evince that the deployed technologies are actually composable under a metric-driven composition strategy and the composed result accomplishes the desired SPD features.
CompoSecReasoner can be utilized for secure system design and offers systematic verification of the underlying systems. The metric-driven strategy can be used for the comparison of different ongoing designs and extract the best ones based on their SPD properties.

Attributes
The attributes are services/technologies which are offered by the system's components, such as a specific cryptographic protocol, and are defined when a component is instantiated. Their defense status is evaluated by the SPD multi-metric method and they are mostly instantiated at the device layer. Each different device type provides a specific collection of attributes, based on its computational capabilities, i.e., of nano, personal/micro, and power nodes.

Sources
Sources constitute critical assets and data which are processed by components and constitute the main theme of the SPD assessment (modelling the treasure rooms of the medieval castle method and the subject of the malicious actions). Sources can be created/deleted, processed, or exchanged by system components. A component owns a specific set of them which can manipulate accordingly by performing operations that can alter their SPD properties. The SPD value of sources is defined by the SPD value of the latest operation that processed them (see the following subsection). When components exchange a source, like transmitting encrypted data via Internet, they really convey a new instance of that source. The sender preserves the original one while the receiver a copy of it, that is now deemed a different source (with indirect association).

Process Operation
Operations form a primary characteristic of the proposed method. They constitute series of actions which are executed by the components when creating and processing sources. An operation includes of a set of attributes and their execution sequence. The involved attributes are performed either in parallel or subsequently. At any given time-point, the minimum SPD of the concurrently performed attributes is disclosed, as it constitutes the weakest security link. The SPD for an operation is defined by these attributes. The absent controls of the SPD multi-metric are wrapped by affiliated controls in the adjacent previous time-point, modelling the added defense of the subsequent execution. The overall SPD reflects the operation's pore coverage which is provided at the final time-point. The exact operation's SPD calculation is also detailed in Algorithm 1. As a result, performing an operation could de/increase the SPD state of a source. Let's take as an example an attribute that defines a plain network transmission-service. The security property of the SPD vector is low, as the affiliated controls are absent (i.e., confidentiality, integrity, and authenticity). Thereupon, an attribute describing an encryption-service is defined. This service performs authenticated-encryption on the processed information (sources), offering the confidentiality, integrity, and authenticity features. Thus, the security is enhanced by performing the two services in a subsequent execution-information is encrypted by the encryption-service and then sent by the network transmission-service. Security controls are cascaded from the first service and cover the absent mechanisms of the second one. The total SPD describes the protection of the network transmission-service enhanced in security by the controls of the encryption-service.

Composition Operation
Under our methodology, an operation can also designate the composition steps which have to be performed to incorporate components. Components of the same system layer are composed to form a component of the adjacent higher layer, e.g., local nodes which are interconnected into a network. A set of operations determine the operation that these nodes have to execute to connect the network, i.e., the communication protocol steps.
Component execute composition operations as long as they can satisfy the functional and non-functional pre-conditions. Functional pre-conditions are determined by the attribute's set that is required for this operation. Components have to be capable to perform all the attributes of the set. The applicability check is also detailed in Algorithm 2. Non-functional pre-conditions are quality features which have to be also fulfilled. They are represented as minimum levels of the SPD multi-metric factors, such as the minimum coverage value of a confidentiality control. To execute a composition operation, components have to grant these SPD constraints as well.
The proof that a component can execute an operation is implemented in Event Calculus (EC) [21]. We define our context features and the validity checks of the functional/non-functional pre-conditions as fluents, events, and rules in EC. Thereafter, we can prove that if the pre-conditions are valid, then the functionality and the derived SPD values are valid.
For composition operations, apart from the relevant attributes, the composition definition denotes also the composition type, based on the corresponding composition operations of the medieval castle approach (i.e., AND, OR, MEAN). This concept is used by the process that estimated the SPD level of the composed component (refer to the following subsection).

System Components
Based on our method, a system is consisted of SPD-sensitive components. Component types include nodes, networks, middleware, and security agents (the overlay), and they can: • possess sources-processed data; • deploy attributes-technologies and protocols; • execute operations-series of attributes; • contain sub-components-components of lower layers; • offer specific SPD levels-based on the assessed metrics and their underlying sub-components.
A component's SPD value is strongly affected by the SPDs of its sub-components'-as the weaker inner defense links; and the component of higher layer with the minimum SPD which contains the examined component-as the weaker outer link. For single components of the lowest layer, we their sources act as the equivalent element for the sub-components.
The assessment of a component's SPD is formally described in Algorithm 3. The structural SPD for a component is estimated based on the medieval castle methodology on its sub-components. The sub-components are modelled as the castle's doors and their SPD reflects the difficulty of penetrating via those doors. The architectural significance for each sub-component/door is defined by the relevant composition operation type. The SPD for a component cannot overdraw the minimum SPD of the associated component at the higher layer. For instance, the SPD level for a node is determined by the networks that it is currently connected in (i.e., a device's security could be reduced when it connects to Internet, as more attack vectors are now open/possible due to the device being networked).

Composition and Decomposition
As an example, let us examine a network composition consisting of two nodes (i.e., LAN of two smart home devices) exchanging data with a secure communication protocol (e.g., IPsec via WiFi). Initially, the SPDs for individual node components are calculated. The communication protocol is defined as a series of subsequent operations. This series reflects the functional requirements for this composition. The non-functional pre-conditions are determined by relevant metrics along with their SPD parameters, which must be supported by all associated components. A related network component is modelled and all nodes have to fulfil those pre-conditions to connect (e.g., Figure 3A). A composition event occurs by each node, designating the connection attempt. If a node enters successfully the network, the network SPD will be re-calculated (e.g., Figure 3B). Them we also reason if other properties hold under this composition (i.e., the network component-two nodes under the secure communication protocol). For instance, when the placed controls of network confidentiality are deployed, it is derived that the network is now offering also the confidentiality property. The evaluation for a composition event on a component C to compose a sub-component subC is further detailed in Algorithm 4. Components which are affected by a composition will re-calculate their SPD and composition associations. Composition events might cascade sequential changes to the status of components at different system layers and even affect the whole setting (e.g., Figure 3C). The system balances after a few time-points (depending on the amount of components and layers) and the total SPD is evaluated. Decomposition events are encountered in the same manner. If a sub-component is decomposed from a component, their SPD aspects are re-calculated as aforementioned.

Compositions of SPD Metrics
The properties which are offered by a system can be attested with formal methods. In general, it is commonly accepted that no computer system is theoretically secure. Thus, validation methodologies confirm if a system meets some security properties against predefined threats, based on our specifications and best practices. For instance, when a system deploys the defenses against Denial of Service (DoS) attacks which are mentioned in the NIST's standards, we could deduce that the system is DoS resilient for the currently known DoS threats.
In this section, we frame the systematic representation of the system's security aspects and composition. The methodology is based on EC and the theoretical research in [58].

Definition 1 (Situations).
A situation S is defined as a system snapshot in a specific time-point.

Definition 2 (Events).
A set of events E includes all events that can alter the current system situation. If we consider that S is the current situation and e ∈ E, then after Happens(e, S, t) → HoldsAt(S , t + 1) , where S is the new state. The composition event is modelled as Happens(Compose(qcomp,qcomp 2 ,qcompop), S,t))→(HoldsAt(S ,t + 1) ∧ Happens(EvaluateComposedSPD(qcomp),S ,t + 2)). After a successful composition at S', it holds that qcomp 2 ∈ (QCompSub o f qcomp).
A component qcomp 2 could be disintegrate from qcomp at any time-point.
After a successful decomposition at S , it holds that qcomp 2 (QCompSub o f qcomp).

Definition 4 (System Composition).
Assume Sys as an evaluated system. Sys is a set that includes the composed components of the system along with their composition associations, properties, and metrics. Composition of the component comp ∈ QComp to Sys by executing the operation sysop ∈ QCompOp of Sys is modelled as Happens(Compose(Sys, qcomp, sysop ), S, t)) → HoldsAt(S , t + 1) , where it holds Sys = Sys ∩ qcomp.

SPD Validation Definitions
SPD validation is modelled by the features of metrics and properties. Metrics describe measurable aspects of a system. Section 2 presents the main characteristics and the assessment procedure for metrics and the SPD formation. The SPD multi-metric measurement is presented in [60]. The Medieval Castle compositions are detailed in [45]. The composed SPD multi-metric calculation of an operation is based on these two approaches and their systematic validation. The operation assessment procedure is detailed in the Section 4.3. The component's assessment procedure is based on similar assumptions and is detailed in the Section 4.4.
The Section 4.4 defines the association among components and metrics. Definition 3 and Definition 4 determine the prior-composition validation procedure for enforcing the pre-conditions which have to be fulfilled to materialize the composition. The definitions Definition 6 and Definition 7 describe the post-composition validation procedure.   (ComponentSub(qcomp, qcompsub), S, t))∧ Happens(ChangeCompStatus(qcomp), S, t) → Happens(EvaluateComposedSPD(qcompsub), S, t)).

System Layers
The EU research project nSHIELD [66,67] investigated new multi-layer architectures for heterogeneous embedded systems. It proposed four generic layers for embedded system designs. From bottom-up, the node layer is comprised of all the distinct components/devices. The network layer includes clusters of nodes which are composed into networks. The middleware layer forms the software layer for the networks' administration. Finally, at the top the overlay layer consists of security agents, which interchange knowledge and manage the individual sub-systems.

Motivating Example
We develop the CompoSecReasoner logic in Event Calculus (EC) [68], and deploy it for the evaluation of an actual IoT ecosystem. The application implements an ambient intelligence setting for the administration of a smart home system.
In the current smart home setting, most of the utilized devices reply to any access request and do not offer any secure access control techniques. Thus, cyber-attacks are becoming feasible as these devices are connected to Internet either directly or indirectly through the user's smart phone [69]. To improve security, we deploy the secure Policy-Based Access Control (PBAC) mechanism which is proposed in [70]. At the device/node layer, this framework enforces access control based on pre-defined security configurations. The policies are securely maintained at the framework's back-end framework, which is installed on a laptop. Furthermore, we use the lightweight cryptographic library (ULCL) [71] to develop a service for secure storage. This service encrypts information at the device-end to safeguard data from disclosure in case where the equipment gets compromised. The standardized cipher AES is utilized for the main cryptographic operations.
The embedded system is comprised by a BeagleBone and a BeagleBoard devices [72] (nodes with constraint computational/communicational features), and a laptop (power node administrates the whole setting). The BeagleBone/BeagleBoard nodes capture environmental factors (like humidity and temperature) and manage electrical devices, such as fridge, air-conditioning, room-lights, etc. The BeagleBones/BeagleBoard audit the associated electrical equipment based on the enforced access strategies of PBAC. The laptop runs the administration framework of smart home management, gathers data from the underlying resources, and displays them to the user. The offered functionality of each device is developed as a service. The nodes interact wirelessly with WiFi and IPsec. All data are encrypted and several security levels are provided, ranging from low-energy consumption settings for "green" operation to high security ones.
CompoSecReasoner runs on the laptop with the PBAC mechanism. CompoSecReasoner is implemented as the reasoning behavior of the home's SPD agent, which can also interact with other smart building agents laying in the overlay layer. The management framework forms the middleware layer which administrates the local ambient ecosystem. The devices are composed into networks. The BeagleBone/BeagleBoard and the laptop are the nodes. As an application scenario, we define a smart-home for assisting living conditions, while for the attacker's model we consider individual hackers with moderate cyber-security knowledge and low attack/computational capabilities (i.e., 1 to 5 PCs).

Reasoning System and Agent Technologies
EC [68] is implemented and extended by the Discrete Event Calculus Knowledge Theory (DECKT) [73], which provides reasoning for automated epistemic, casual, and temporal settings with dynamic, partially-known, and/or uncertain domains. DECKT is developed in Java and JESS. JESS is a rule engine for knowledge-based reasoning in the form of declarative rules, written in Java.
DECKT was further extended by [74] where preferences, rule priorities, and real-time events' evaluation were introduced. The overall solution was deployed as the reasoning behavior of agents implemented in the Java Agent DEvelopment framework (JADE). JADE constitutes one of the most popular agent platforms and it is open source. It simplifies the development of multi-agent systems and supports the associated specifications, made by the Foundation for Intelligent Physical Agents (FIPA) [75]-an IEEE Computer Society standards body. Moreover, JADE materializes the Agent Communication Language (ACL) [76]-the standard language for agent interaction specified by FIPA. Finally, a real-time multi-agent epistemic reasoner is implemented that also provides a conflict resolution mechanism, which resolves inconsistences among the agents' local knowledge and viewpoints, resulting in a coherent global view of the overall system.
We utilized this reasoner from [74] to develop the composition framework, which is presented in this study. Thus, the main reasoning behavior is extended to model our proposal, and henceforth, all "SPD agents" deploy the CompoSecReasoner behavior. Thereafter, we further proceed with the implementation of the technical aspects and offer the overall solution as a service.

Middleware and Service Platform
OSGi constitutes a standardized service platform and module system in Java, developing a holistic and dynamic component model. The components' services are materialized as bundles for deployment and are remotely installed/uninstalled and started/stopped without the need for reboot. The leading open source distribution, called Knopflerfish [77], is adopted by the CompoSecReasoner framework. JADE, apart from its pure distribution as a multi-agent platform, is also offered in the form of a JADE-OSGi bundle. Thus, the above mentioned CompoSecReasoner agent is deployed as a JADE-OSGi bundle, facilitating the real-time system administration functionality.
The components port their services as Knopflerfish-OSGi bundles and interact with the associated JADE-OSGi bundle that runs the CompoSecReasoner agent. The software modules of the proposed framework are portrayed in Figure 4. JADE, apart from its pure distribution as a multi-agent platform, is also offered in the form of a JADE-OSGi bundle. Thus, the above mentioned CompoSecReasoner agent is deployed as a JADE-OSGi bundle, facilitating the real-time system administration functionality.
The components port their services as Knopflerfish-OSGi bundles and interact with the associated JADE-OSGi bundle that runs the CompoSecReasoner agent. The software modules of the proposed framework are portrayed in Figure 4. The overall setting adopts a Service oriented Architecture (SoA). Each entity specifies semantic information such as the supported services and their type, in the standardized Device Profile for Web Services (DPWS), which is specified by the Organization for the Advancement of Structured Information Standards (OASIS). This enables device/service description, discovery, eventing as well as messaging functionality.

Platform Security Features
The build-in security mechanisms of the OSGi platform support inner-platform protection, both for devices and agents, by restricting the bundle operation to predefined capabilities, such as which bundle could be started or stopped, by whom, and when. The JADE-S add-on safeguards the ACL messages by offering the Java Cryptography Extension (JCE), Java Authentication and Authorization Service (JAAS), and Java Secure Socket Extension (JSSE) extensions. JADE-S enables among others message encryption and signature, agent actions authorization against agent permissions, and user authentication [Error! Reference source not found.]. The overall setting adopts a Service oriented Architecture (SoA). Each entity specifies semantic information such as the supported services and their type, in the standardized Device Profile for Web Services (DPWS), which is specified by the Organization for the Advancement of Structured Information Standards (OASIS). This enables device/service description, discovery, eventing as well as messaging functionality.

Platform Security Features
The build-in security mechanisms of the OSGi platform support inner-platform protection, both for devices and agents, by restricting the bundle operation to predefined capabilities, such as which bundle could be started or stopped, by whom, and when. The JADE-S add-on safeguards the ACL messages by offering the Java Cryptography Extension (JCE), Java Authentication and Authorization Service (JAAS), and Java Secure Socket Extension (JSSE) extensions. JADE-S enables among others message encryption and signature, agent actions authorization against agent permissions, and user authentication [78].

Demonstration
We implement the smart home system that is described in the Sections 3.3 and 6.2. We mainly model the aforementioned PBAC framework with IPsec [70], which is comprised of the following modules: PEP interplays with the PDP (between nodes and the middleware), supporting four configurations for different SPDs: plaintext-only, authentication-only, encryption and authentication, as well as, WS-Security. PEP interacts with user of a device, offering three configurations: plaintext-only, authentication-only, encryption-and-authentication. Further information can be found in the primary article [70].
In the node layer, the two BeagleBone/BeagleBoard devices and a laptop act as the nodes n 1 , n 2 , and n 3 , respectively. The nodes n 1 and n 2 are similar and deploy the attributes IPsec, ULCL, PEP with the three SPD configurations, and WiFi. As sources, they store the local information by PEP. The node n 3 offers the attributes IPsec, ULCL, PBAC with the four SPD configurations of the PDP module, CompoSecReasoner, and WiFi. As sources, it maintains the information from PDP, PIP, and PAP accordingly.
The network net is defined in the network layer. This network supports the attributes IPsec and WiFi. To connect the network net, a node has to execute a composition operation (MEAN-operation) that demands the subsequent performance of PEP, IPsec, and WiFi-op 5 . Nodes n 1 and n 2 execute the operation and connect net.
The middleware midl is defined in the relevant layer. It deploys the attribute PBAC and the aforementioned protections of OSGi. To connect the middleware, two composition operations are supported to incorporate node and network components, respectively. A node has to execute the attributes PBAC and IPsec-op 2 ; while a network has to execute only IPsec-op 6 . The middleware lays on the laptop node. Therefore, a composition event is executed by n 3 to midl. The network net executes the second operation and is integrated with midl.
In the demonstrated scenario, we model a single SPD agent, called SA. It offers the attributes CompoSecReasoner and the aforementioned protections of JADE-S. Two composition operations are supported to integrate components from the node and middleware layers, respectively. Nodes have to execute the attribute CompoSecReasoner-op 1 ; while the middleware component has to execute the attribute PBAC-op 3 . SA is installed on the laptop node, as well as, the PBAC middleware. Hench, n 3 executes the relevant composition event to SA. Thereafter, midl executes the second composition operation to be incorporated as well. Finally, the overlay over is defined in the top layer and includes two alike SAs. To be integrated in the overlay, the agents have to deploy the CompoSecReasoner-op 4 .

Levels of SPD
The SPD multi-metric evaluates the SPD value for all the demonstrated attributes. ULCL offers a single SPD level for the secure storage of local data of ULCL = 80, 50, 30 , which affects the confidentiality aspects of a node. WiFi enables the wireless communication of devices (nodes) and also provides a single SPD level of WiFi = 20, 20, 50 , which affects data integrity property of a network component. IPsec offers authentication and encryption and supports three SPD levels for relevant cryptographic key sizes (IPsec 128 = 68, 20, 70 , IPsec 191 = 75, 20, 70 , IPsec 256 = 85,20,70 ). if all node components in a network intercommunicate via IPsec, the SPD factor for data confidentiality is enhanced. The node attribute PEP supports three levels of SPD based on the underlying security configurations (PEP Plain = 10, 30, 10 , PEP Auth = 50, 50, 50 , PEP Enc_Auth = 80, 70, 80 ). In the same manner, PBAC incorporates four SPD states between the communication of the PEP and PDP modules (PBAC Plain = 10, 30, 10 , PBAC Auth = 50, 50, 50 , PBAC Enc_Auth = 80, 70, 80 , PBAC WS_Sec = 90, 80, 90 ). CompoSecReasoner's SPD is estimated at CompoSecReasoner = 70, 50, 70 . All metrics are assessed dynamically at runtime. The security parameter is supported by several protection features, such as IPsec and JADE-S. PBAC safeguards the overall privacy. Dependability is enhanced by all the deployed mechanisms.

Composition and SPD Assessment
Initially, we instantiate the system's components (n 1 , n 2 , n 3 , router, net, over) for moderate SPD with low power consumption. PBAC, PEP, and IPsec are set at the SPD's of PBAC Auth , PEP Auth , and IPsec 128 , accordingly. The SPD of each distinct component is assessed by the CompoSecReasoner-no composition operations are performed at this time-point and no component includes sub-components.
The SPD value for each of these sources is the SPD level of ULCL-80, 50, 30 . The changes trigger the SPD assessment for the node n 3 ( 80, 50, 30 -Definition 7).
In the same manner, the nodes n 1 and n 2 encrypt their local versions of PEP. The nodes' and sources' SPDs are calculated at 80, 50, 30 . Nodes have to execute the network and middleware attributes to enter the LAN. Operation op 1 enforces the relevant composition requirements, designating the subsequent execution of WiFi, IPsec, and PEP. The type of such compositions is the MEAN-operation (as discussed in Section 3.3).
Local networking is supported by the router. The LAN is a sub-component of the router. The composition requirements for this network are modelled by operation op 2 , denoting the subsequent performances WiFi and IPsec under an OR-operation composition.
Apart from the internal networking, the router offers external connection with Internet, modelled under op 3 . An OR-operation defines the composition between the router and the Internet.
The network net is incorporated to the router (op 2 ). The router's SPD restricts the SPDs of its sub-components (net and subsequently n 1 , n 2 , and n 3 ). Thereupon, router connects to Internet (op 2 ). After the system's composition, we can reason about the metrics that are eventually achieved. The total SPD of this system is estimated at 70, 50, 30 and is strongly influenced by n 3 's SPD.

Reactive Strategies & MTDs
We can utilize the metric-driven runtime administration features of the tool and dynamically adjust the 36 configurations of the system (combinations of 3 IPsec, 4 PDP, and 3 PEP configurations) based on our high-level SPD goals and the AI reactive plans that can be triggered the monitored events in real-time. The relevant SPD levels are illustrated in Figure 5 below (the individual S, P, and D, values indicate the percentage (%) of pore coverage, ranging from 0-100% for no to optimal protection, respectively). The operational status ranges from configurations for low energy consumption to settings for high SPD. The smart home can connect with other smart entities via Internet (op3), as it is depicted in Figure  6. Assume the scenario where the SPD agent of a neighboring smart home monitors a cyber-attack in its region. The agent alerts the overlay to warn the rest agents. The SPD agent of the house takes the decisions to adjust the system's configuration from low power consumption with moderate security, to high security and protection. The reactive strategy enforces the underlying components to deploy The smart home can connect with other smart entities via Internet (op 3 ), as it is depicted in Figure 6. Assume the scenario where the SPD agent of a neighboring smart home monitors a cyber-attack in its region. The agent alerts the overlay to warn the rest agents. The SPD agent of the house takes the decisions to adjust the system's configuration from low power consumption with moderate security, to high security and protection. The reactive strategy enforces the underlying components to deploy PBAC WS_Sec , PEP Enc_Auth , and IPsec 256 instead. The plan triggers various operations to set the new system state. The overall protection is enhanced and the new SPD level for the house is increased to 90, 80, 90 . The smart home can connect with other smart entities via Internet (op3), as it is depicted in Figure  6. Assume the scenario where the SPD agent of a neighboring smart home monitors a cyber-attack in its region. The agent alerts the overlay to warn the rest agents. The SPD agent of the house takes the decisions to adjust the system's configuration from low power consumption with moderate security, to high security and protection. The reactive strategy enforces the underlying components to deploy PBACWS_Sec, PEPEnc_Auth, and IPsec256 instead. The plan triggers various operations to set the new system state. The overall protection is enhanced and the new SPD level for the house is increased to 〈90,80,90〉.

Performance Assessment
CompoSecReasoner is evaluated under a testbed. The user administrates the system's SPD via an Android application in a smart phone (Android 5.0 KNOX OS, 16GB RAM, 2.5GHz quad-core CPU, 4G, Wi-Fi) which connects the home's LAN wirelessly with WiFi. PEP and the controlling software of the electric device are installed in the BeagleBones (Ubuntu Linux OS, 256MB RAM, 720MHz ARM Cortex-A8 processor, USD-WiFi). We use two BeagleBone devices that connect the LAN wirelessly with the USB-WiFi. The BeagleBones are also supplied with a weather cape-for the measurement of environmental parameters, like temperature, ambient light, and humidity; and a battery cape-for power supply. The BeagleBoard manages a surveillance USB-camera and is plugged to the home's power supply. CompoSecReasoner and PBAC run on a laptop (Windows 8.1 Pro OS, 8GB RAM, 2.1GHz Inter Core i-7 CPU, WiFi). The testbed and demo settings are depicted in Figure  7.

Performance Assessment
CompoSecReasoner is evaluated under a testbed. The user administrates the system's SPD via an Android application in a smart phone (Android 5.0 KNOX OS, 16GB RAM, 2.5GHz quad-core CPU, 4G, Wi-Fi) which connects the home's LAN wirelessly with WiFi. PEP and the controlling software of the electric device are installed in the BeagleBones (Ubuntu Linux OS, 256MB RAM, 720MHz ARM Cortex-A8 processor, USD-WiFi). We use two BeagleBone devices that connect the LAN wirelessly with the USB-WiFi. The BeagleBones are also supplied with a weather cape-for the measurement of environmental parameters, like temperature, ambient light, and humidity; and a battery cape-for power supply. The BeagleBoard manages a surveillance USB-camera and is plugged to the home's power supply. CompoSecReasoner and PBAC run on a laptop (Windows 8.1 Pro OS, 8GB RAM, 2.1GHz Inter Core i-7 CPU, WiFi). The testbed and demo settings are depicted in Figure 7. We utilize the smart phone application to run the benchmark where the user triggers SPD changes on the home equipment, such as the SPD configurations of PBAC and IPsec. We assess the changes' impact on the computational complexity of CompoSecReasoner as well as the overall system's responsiveness.
The RETE algorithm (one of the main and widely-utilized pattern matching algorithms for implementing rule-based systems) [Error! Reference source not found.] is utilized internally by JESS, achieving optimized speed and forming a quite efficient pattern-matching engine. The CompoSecReasoner's reasoning theory for the smart home application requires around 400 facts and 30 rules. The whole reasoning framework need on average 1.6 s, 45 MB RAM, and 1.87 MB for the We utilize the smart phone application to run the benchmark where the user triggers SPD changes on the home equipment, such as the SPD configurations of PBAC and IPsec. We assess the changes' impact on the computational complexity of CompoSecReasoner as well as the overall system's responsiveness.
The RETE algorithm (one of the main and widely-utilized pattern matching algorithms for implementing rule-based systems) [79] is utilized internally by JESS, achieving optimized speed and forming a quite efficient pattern-matching engine. The CompoSecReasoner's reasoning theory for the smart home application requires around 400 facts and 30 rules. The whole reasoning framework need on average 1.6 s, 45 MB RAM, and 1.87 MB for the code. Nevertheless, this is expected to be done once, when an agent is started. After that, when the rule engine is up and running, it takes around 0.002 s to process a theory with a few hundreds of facts [80]. Therefore, this is the actual real-time delay for applications. The code size is not affected while the additional RAM is minimal.
The most notable performance factor is the response time that the user experiences when he/she retrieves information or when SPD changes are happening. The overall delay of the concurrent benchmark requests is depicted in Figure 8. Spikes reflect the SPD changes (e.g., incoming SA requests, system configuration, and notification of the SA when a change is completed). Such changes produce considerable delay, however, in normal operation the system is set in a specific configuration for most of the time and changes are expected to be rare. Nonetheless, the framework exhibits acceptable delay, even for a real-time environment.
(C) Android smart phone device with the user's smart home application.
We utilize the smart phone application to run the benchmark where the user triggers SPD changes on the home equipment, such as the SPD configurations of PBAC and IPsec. We assess the changes' impact on the computational complexity of CompoSecReasoner as well as the overall system's responsiveness.
The RETE algorithm (one of the main and widely-utilized pattern matching algorithms for implementing rule-based systems) [Error! Reference source not found.] is utilized internally by JESS, achieving optimized speed and forming a quite efficient pattern-matching engine. The CompoSecReasoner's reasoning theory for the smart home application requires around 400 facts and 30 rules. The whole reasoning framework need on average 1.6 s, 45 MB RAM, and 1.87 MB for the code. Nevertheless, this is expected to be done once, when an agent is started. After that, when the rule engine is up and running, it takes around 0.002 s to process a theory with a few hundreds of facts [Error! Reference source not found.]. Therefore, this is the actual real-time delay for applications. The code size is not affected while the additional RAM is minimal.
The most notable performance factor is the response time that the user experiences when he/she retrieves information or when SPD changes are happening. The overall delay of the concurrent benchmark requests is depicted in Figure 8. Spikes reflect the SPD changes (e.g., incoming SA requests, system configuration, and notification of the SA when a change is completed). Such changes produce considerable delay, however, in normal operation the system is set in a specific configuration for most of the time and changes are expected to be rare. Nonetheless, the framework exhibits acceptable delay, even for a real-time environment. Regarding scalability, the reasoning complexity is affected by: (i) the number of rules (R), (ii) the number of facts (F) on the working memory, as well as, (iii) the average patterns per rule left-handside (P). The total complexity is linearly influenced by the size of the working memory and is of the order of O(RFP). In CompoSecReasoner, the number of the theory rules (R) is very low, i.e., around 30 rules the smart home scenario. Also, unique identifiers are assigned to every entity and the upcoming events influence specifically denoted parameters, thus, the pattern-matching ratio (P) is also low and in the magnitude of one to three. Actually, scalability is influenced mostly from the facts' amount (F). In this demo, each system component takes around 5-10 facts to be defined, Regarding scalability, the reasoning complexity is affected by: (i) the number of rules (R), (ii) the number of facts (F) on the working memory, as well as, (iii) the average patterns per rule left-hand-side (P). The total complexity is linearly influenced by the size of the working memory and is of the order of O(RFP). In CompoSecReasoner, the number of the theory rules (R) is very low, i.e., around 30 rules the smart home scenario. Also, unique identifiers are assigned to every entity and the upcoming events influence specifically denoted parameters, thus, the pattern-matching ratio (P) is also low and in the magnitude of one to three. Actually, scalability is influenced mostly from the facts' amount (F). In this demo, each system component takes around 5-10 facts to be defined, producing a low computational overhead (in the nanosecond range) and less than 40 extra bytes in RAM for the SPD agent.

Validation of the Derived SPD Values
Apart from the functional and operational aspects of the proposed framework, it is important to examine wherever the deduced information regarding the SPD aspects of an evaluated system are meaningful and truly reflect the actual protection level. Therefore, we also compare the results of the SPD assessment procedure with similar standardized or widely-used methodologies proposed by the National Institute of Standards and Technology (NIST) [81].
As we presented in the Section 3.1, our method starts with the analysis of the individual components and the estimation of their SPD status. For the evaluation of distinct system modules, software, hardware, or other assets, NIST has established a methodology called Common Vulnerability Scoring System (CVSS) [82]. The method takes into account known vulnerabilities for the examined component as well as the existence of mitigation mechanisms and tries to figure out their severity and likelihood to be exploited. The result is a score from 0 (low risk) to 10 (high attackability). NIST performs CVSS analyses for known vulnerabilities (e.g., in MySQL, Internet Explorer, Chrome, etc.) and maintains the results in a repository, which is publicly available [82].
Our SPD multi-metric follows a similar approach by assessing the attacker's effort and preference to exploit an existing vulnerability as well as its impact. We also take into account the potential attack vectors (called Threat Flows (TFs) in our methodology) and assess a list of known vulnerabilities (defined as limitations) that the deployed defense mechanisms (controls) may fail to mitigate. Moreover, the SPD levels are meant to be calculated in advance, as the CVSS scores, and be processed by CompoSecReasoner during the system's composition and operation.
We utilize CVSS v3.1 Calculator [83] to assess the security for the secure storage service at the device-end with the ULCL component of the smart home example. The derived CVSS base score is 2.7, reflecting low attackability and high security. This is in accordance with the SPD multi-metric assessment and the SPD level of 80, 50, 30 , where the security (S = 80) also reflects high protection and low exploitation possibility. Similar results were derived for the other individual evaluated components that are referred in the Section 6.5. This fact designates that our proposal successfully discloses the main security notion as it is acceptable by the cyber-security community. Moreover, we have extended the analysis to also cover privacy and dependability in a similar fashion.
Furthermore, the proposed methodology goes one step further from the distinct analysis of assets and estimates the overall protection status of the composed system.
NIST and the Health Insurance Portability and Accountability Act (HIPAA) [84] have developed the Security Risk Assessment (SRA) tool [85] to evaluate the overall security posture of healthcare organizations. Except from technical features, the tool takes also into account procedural aspects, threat detection and response operations, as well as the human factor. We utilize this tool to evaluate the demonstrated smart home composition and correlate the results with the outcomes of our methodology. We consider the same setting that is described in the Section 6.4, with the same devices and protected assets (e.g., PEP, PDP, etc.), the contingency and response functionality of the SPD agents, and a home owner with low to moderate security knowledge as the main actuator. Figure 9 depicts the fulfillment of the risk assessment questionnaires as well as the final report of the SRA tool for the smart home setting.
Appl. Sci. 2020, 10, x FOR PEER REVIEW 27 of 33 The analysis reveals that there is high risk in three of the 25 main security categories that are investigated. The technical safeguards and contingency policies are in place and the reported problems that exhibit high exploitation risk are related with the lack of security knowledge by the user (homeowner). This is also in accordance with the SPD evaluation of 〈90,80,90〉 that designates a high level of system protection. Our method is mainly assessing the technical and procedural aspects of a system, while the incorporation of metrics that capture the security awareness of its operator (e.g., [86]) could be considered as a future work. The analysis reveals that there is high risk in three of the 25 main security categories that are investigated. The technical safeguards and contingency policies are in place and the reported problems that exhibit high exploitation risk are related with the lack of security knowledge by the user (homeowner). This is also in accordance with the SPD evaluation of 90, 80, 90 that designates a high level of system protection. Our method is mainly assessing the technical and procedural aspects of a system, while the incorporation of metrics that capture the security awareness of its operator (e.g., [86]) could be considered as a future work.

Future Work
The assessment of the SPD aspects for a system is usable for figuring out if it meets the desired SPD requirements and mitigates attacks under a specific threat model, and comparing various configurations and reasoning which is the best.
Nevertheless, from the engineering and business points of view, it also becomes fruitful to deduce which of the settings that achieve the targeted SPD level is the most cost-effective/profitable. Therefore, CompoSecReasoner can be extended to assess the implementation cost of the examined settings. The SPD and cost measurements could be incorporated in business frameworks for cost-benefit analyzes and investment evaluation for IoT or other information systems.
In the long-term, technology ageing also raises as a significant parameter [87,88]. In the smart home environment, the deployed equipment (e.g., surveillance cameras, fridge, etc.) is in use for several years. The long lifetime influences protection, and after decades of technology evolution, the currently deployed and secure mechanisms could have become inadequate. In the cryptography domain for instance, the outdated cipher DES was replaced by the newer cipher AES some years ago, while now crypto-systems which are based on elliptic curves are considering as the substitution of the RSA ones. Thus, an adequate assessment methodology has to consider the ageing problem of the system as well. The proposed method can tackle several of these issues. The analysis which evaluates the provided defense of the deployed controls based on the known limitations could be periodically revisited to reflect the current situation. Thereupon, vendors could keep up-to-date the SPD of their products with the system operator (or the automated management framework) re-calculating a system's SPD, when changes are reported.

Conclusions
In this study, we demonstrate CompoSecReasoner-an event-based model checking framework for metric-driven management of dynamic embedded systems. We use Event Calculus (EC) to describe the changes of a system with the progress of time and decide if they result in a more or less secure system. We implement the CompoSecReasoner as a reasoning behavior for JADE agents and apply it in the multi-agent filed. Then, we embody the whole framework as an OSGi bundle in Knopflerfish. The agents verify dynamically the composition of their underlying systems based on their metric-driven policies. Moreover, they communicate security, privacy, and dependability (SPD) related information to build more secure systems and reach global SPD levels. We demonstrate the CompoSecReasoner in a real ambient intelligence scenario, where embedded devices control ambient parameters of two smart buildings. We use CompoSecReasoner to reason if the composition is feasible and figure out the total outcome for SPD metrics.

Conflicts of Interest:
The authors declare no conflict of interest. "The funders had no role in the design of the study; in the collection, analyses, or interpretation of data; in the writing of the manuscript, or in the decision to publish the results".

Appendix A
The appendix lists the interactive and passive controls that are evaluated under the SPD multi-metric approach.

Consent
Freely given, informed, and specific agreement of the personal identifiable information (PII) principal for processing the PII. PII should not be shared or disclosed to third parties without consent from the PII principal Opt-in Policy or procedures under which the PII principal consents for the explicit processing actions of the PII, prior to relevant consent

Indentifiability
The ability to infer the identity of the PII principal, directly or indirectly, by a given set of PII. It may subsume complete indentifiability, pseudonymization or anonymity. Notification Inform the PII principals whose data is being gathered regarding such collection

Survivability
Available degraded operations that are useful and acceptable to users when a failure occurs for a specified period Performability Operations that assures how well the system will perform in the presence of faults for a specified period Removal during use Mechanisms that record and remove faults via the maintenance cycle after the production stage Passive controls Security

Confidentiality
Assurance that a processed asset is not known outside the interacting entities Integrity Assurance that the interacting entities know when an asset has been modified Non-repudiation Obstructs the interacting entities for denying their role in an occurred interaction Alarm Notification that an interaction is happening or has happened Privacy Fairness PII should be collected, used or disclosed for appropriate and limited purposes Challenge compliance (accountability) PII principals should be able to hold PII processors accountable for complying with all privacy controls

Retention
Insurance that PII which is no longer required, is not retained in order to limit unauthorized collection, usage and disclosure Disposal Mechanisms for the disposal or destruction of PII Report Report that an interaction regarding PII is occurring or has occurred Break/incident response Procedure for managing a breach concerning PII

Tolerance
Insurance that the needed functionality will be delivered in the presence of faults Forecasting Prediction of possible faults so that they can be removed or their effects can be circumvented Prevention Obstructs faults from being integrated into a system. It is achieved by using good implementation techniques and development techniques Removal during development Verification of a system in order to detect and remove faults before the system is put into production