## 4 Verification and Validation
### Implementation of the Proposed Model in a Construction Example  
This section illustrates the practical implementation of the proposed sequential game-theoretical model in the context of a construction project. Showing the implementation and presenting different scenarios are crucial for contextualizing the theory presented in Sections 4 and 5. The proposed models involve an insider with a parameter directly  
Figure 8: \(1-\eta^{*}\) versus \(C_{\text{cylb}}\). related to its characteristics: the probability that an insider is malicious (\(\delta\)). The other party involved in the game-theoretic models is the data defender. Considering that the data defender manages the access control using a role-based method, the role of the insider in the project mainly defines the initial \(\delta\) value. Therefore, understanding different possible roles in a construction project is essential before showing the proposed models' implementation. A high-level list of roles in a construction project using BIM is presented in Table 2. Most roles shown below were taken from [PERSON] and [PERSON] [42], and BIM- and IT-related roles were added to the list to make it up-to-date and more relevant to this study. Moreover, a procurement method with separate design and construction responsibilities was assumed. Only the roles that were assumed to have access to the project IT network were included. The list of roles in Table 2 can be extended or reduced depending on project characteristics. However, it is clear that not all roles have the same initial probability of being a malicious insider \(\delta_{\text{initial}}\) in a project. For example, the initial probability of a client being malicious should not be assumed to be the same as the initial probability of a sub-contractor \begin{table}
\begin{tabular}{l l l} \hline \hline
**Categories** & **Sub-Categories** & **Sample Roles** \\ \hline Client & (i) Client & Client \\  & (ii) Client’s representative & Client project manager \\  & & Client liaison officer \\  & & Project manager \\  & & Construction manager \\  & & Design coordinator \\ Advisor/Consultant & (i) Management & Design manager \\  & & BIM coordinator \\  & & BIM manager \\  & & Architectural designer \\  & & Civil and structural engineer \\  & (ii) Design & Geotechnical engineer \\  & & Mechanical and electrical engineer \\  & & Fire engineer \\  & & Cost consultant \\  & (iii) Financial & Cost planner \\  & & Quantitative surveyor \\  & & Project manager \\  & & Construction manager \\  & & Construction scheduler \\  & & Construction cost estimator \\  & & Contract manager \\  & & Site manager \\  & & Site engineer \\  & & Quantitative surveyor \\  & & BIM manager \\  & & BIM coordinator \\  & & BIM specialist \\  & & IT manager \\  & & IT specialist \\  & & Business manager \\  & & Human resource manager \\  & & Administrator \\  & & (ii) Partial responsibility & Sub-contractor \\ \hline \hline \end{tabular}
\end{table} 
Table 2: Different categories and roles. being malicious. Therefore, while implementing the proposed model, different \(\delta_{\text{initial}}\) values should be considered for different roles. However, \(\delta\) values of each user in the network should be dynamic throughout the project and change based on feedback from the IDS. In this paper, the probability of an insider being malicious at any given time is annotated as \(\delta_{\text{current}}\). For example, if a user with a low \(\delta_{\text{initial}}\) value starts having suspicious activity (e.g., unexpected traffic from its devices), its \(\delta_{\text{current}}\) value is revised and relatively increased. The access control manages the access requests of subjects to different objects in the network. While the subjects refer to project participants with various roles, the object can be a file or device. In this paper, the object is assumed to be a digital file stored in the centralized repository (i.e., CDE).