## 3 MBSEsec Method  
This section introduces the MBSEsec method, which covers activities and guidelines for creating secure systems with the SysML security profile. Figure 3 shows the phases and underlying security techniques of the MBSEsec method. Some of the activities that are suggested in the MBSEsec method directly match the name and definition of the security technique from the analysis part (e.g., Misuse Cases, SysML Requirements Diagram); some of them are derived (e.g., Asset Structure Definition, Threat and Risk Definition). The third part of the techniques falls into the MBSE features category (e.g., verification rules, activity simulation, allocation matrix). In order to apply these techniques, we regrouped and expanded the SysML Security profile (see Figure 4), which originally was introduced in [12]. Phase 1--Identify Security Requirements. The starting point of the MBSEsec method is to identify the security requirements as an additional part of the functional and non-functional requirements that are usually captured at an early stage of SE model creation. We have expanded the initial security profile with the \"Security Requirement\" stereotype, which is a subtype of the SysML Requirement (see Figure 4). We recommend using the standard SysML Requirements diagram or Requirements table for capturing security requirements. The further security requirement refinement can be additionally done with the SysML/UML Use Case diagram. Phase 2--Capture and Allocate Assets. The second phase is dedicated to defining the objects that the organization should secure and allocate them to the system's parts. The SysML language has two concepts for defining system structural elements: Blocks that define types, and Parts that represent the usage of these blocks in a specific context. Similarly, the assets definition can be performed in both ways; however, the goal of this phase is to represent the structure, not the usage or internal connections. As a result, we recommend using a new diagram type of Asset Structure Definition, which should be an extension of the Block Definition Diagram. After the identification of the assets, Systems Blocks and Assets should be linked with the SysML Allocation relationship. This would allow us to create expressions based on Object Constraint Language (OCL) or other programming languages for running quantitative model verification, i.e., finding all the system blocks that are not allocated to any asset element. Phase 3--Model Threats and Risks. This phase consists of two parts: behavioral and structural security specification. For the behavioral risk and threat definition, we recommend the extended Use Case diagram for identifying Misuse Cases and the UML Activity diagram for modeling Attack Scenarios. The Dolev-Yao attacker model was mentioned in the literature analysis; however, this technique is too detailed for an early phase, and we do not include it in the MBSEsec method. The Dolev-Yao attacker model can be applied in the later phases or when formal verification is needed. Figure 3: The phases of the Model-Based System Engineering (MBSE) sec method. For the structural risk definition, we recommend the new Threat and Risk Definition diagram, which should be based on the UML Class diagram. In this diagram, the following elements should be created and linked: Risk; Risk Treatment; Risk Impact; Threat; and Vulnerability. Alternatively, a HAZOP style table can be used to summarize risk-related information. Phase 4--Decide Objectives and Controls. The final phase helps us to define security control objectives and controls. We recommend using a new Security Objectives and Controls Structure diagram (an extension of the UML Class diagram) for defining elements of security objectives and controls. The standard UML Activity Diagram could be used for identifying workflow or algorithm for security control. We recommend modeling security workflow by following fML1.1. standard; this would allow security engineers to simulate and verify security controls. Figure 4: The MBSESec profile.