## 5 Discussion and Limitations  
The previous section presented the implementation of the proposed game-theoretical models using two scenarios for constructing a smart hospital building. The scenarios differed from each other based on the assumed project security level. In both scenarios, two types of files were considered for the implementation: cost and schedule forecast and structural design files. While the confidentiality of the first file type was assumed to be \"high\", it was considered \"medium\" for the second file type due to the nature of the project. If the scenario included a project with high design sensitivity, the second file type's confidentiality would also be \"high\". For example, if the project were a military base, embassy, or intelligence agency building, the confidentiality of all design files, including the structural ones, would be \"critical\". Moreover, if the malicious insider's motivation was espionage, the value of the design files of such projects to the malicious insider (see Tables 6 and 7, column \"value of the file to malicious insider\") would be \"critical\". If the project type was a residential building, the confidentiality of the design files could be considered even lower than the hospital construction scenario since the design would not have the same criticality level. Therefore, different file types would have different \"cybersecurity attribute\" (see Tables 6 and 7) values for different project types based on the characteristics of the projects. While this study presented the implementation of the proposed models in a theoretical scenario, the real-life application might have several constraints and difficulties. The first difficulty in a real-life scenario would be assigning confidentiality, integrity, and availability values for all types of files in the project. Since they have qualitative values, they might change based on the person assigning them. The problem regarding the subjectivity of the values also applies to the other qualitative values in Tables 6 and 7, such as \"value of the file to malicious insider\" and \"malicious insider's expertise level\". Another challenge would be identifying the security level of the project. This would require the project to perform security risk assessments regularly. However, even with regular risk assessments, choosing one of the five values for the security level in Table 3 reduces accuracy. The constraints of simplification and reduced accuracy in values also apply to the \"malicious insider expertise level\" and \"file accessibility level\". Identifying these values and making them realistic is one of the considerable real-life challenges of this study. This study also simplified the motivation of the malicious insider. The insider might have several motivations, some not given in this study. Therefore, assigning values for the \"Value of the File to Malicious Insider\" would be more difficult and complex. Moreover, in this study, the expertise level of the attacker did not affect the values of \"the probability of being a malicious insider at the time of the access request (\(\delta_{\text{current}}\))\", \"the probability that the malicious insider who launches authentication is detected \((p_{1})\)\", and \"the probability that the malicious insider who launches a cyberattack is detected \((p_{2})\)\". However, if the attacker is stealthy enough, the IDS might not be able to detect unusual traffic from the insider. Thus, the \(\delta_{\text{current}}\) value would stay low, affecting the best strategy for the defender. Similarly, the stealthiness would significantly affect the probability of being detected, corresponding to the \(p_{1}\) and \(p_{2}\) values in this study. The evaluation of the proposed model was made by only two experts from a construction company, which can be considered another limitation of this study. Receiving the feedback of more experts would help improve the study further.