## 3 Materials and Methods
### SPD Multi-Metric  
#### 3.1.1 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 \begin{table}
\begin{tabular}{c c c c c c c c c c c c c} \hline \hline
**Feature** & **A** & **B** & **C** & **D** & **E** & **F** & **G** & **H** & **I** & **J** & **K** \\ \hline \multicolumn{10}{c}{_System composition_} \\ \hline Dynamicity & **Y** & N & Y & Y & Y & Y & Y & Y & Y & N & N \\ Expressiveness generality & **Y** & Y & Y & Y & N & Y & Y & N & Y & N & N \\ \hline \multicolumn{10}{c}{_Validation_} \\ \hline Pre-composition & **Y** & Y & Y & Y & N & Y & Y & Y & Y & Y & N & N \\ Post-composition & **Y** & N & N & N & Y & Y & Y & N & N & N & N \\ \hline \multicolumn{10}{c}{_Evaluated Properties_} \\ \hline Security & **Y** & N & N & N & N & N & N & N & Y & Y & Y & Y \\ Privacy & **Y** & N & N & N & N & N & N & N & N & N & N & N \\ Dependability & **Y** & P & P & P & Y & Y & Y & P & P & N & P \\ \hline \multicolumn{10}{c}{_Artificial Intelligence_} \\ \hline Distributed reasoning/processing & **Y** & N & N & Y & Y & Y & Y & N & Y & N & Y \\ Conflict resolution & **Y** & N & N & N & N & N & N & N & N & N & N \\ MTD & **Y** & N & N & N & N & N & Y & N & N & Y & Y \\ \hline \hline \end{tabular}
\end{table} 
Table 1: System composition and security validation features: (A) CompoSecReasoner [**this paper**], (B) IFML [21], (C) SMoLES [30], (D) Dracena [31], (E) MSC [32], (F) BLES [34], (G) IoT Composer [35], (H) SMoLES-SEC [36], (I) SDT [37], (J) Attack Surface MTD [56], (K) Multi-metric-driven MTD [57]. The following notations are used: Y(es), N(o), Par(rial)a more precise analysis and better design. Figure 1 illustrates the main SPD multi-metric concepts, which are detailed below. 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.