## 6 Evaluation of Existing SRE Approaches
### Evaluation Iteration 2--STS Modelling and Feedback Discussion  
From our initial analyses, we highlighted that STS provides no support to describe separation of concerns. In this experiment, we investigate the integration of SABSA layered approach to STS modelling in order to improve the separation of concerns. SABSA [9] (Sherwood Applied Business Security Architecture) is a methodology framework for enterprise security architecture and service management. The main intention of this framework is to guide security architects in their task. It defines a six-layered architecture model; each layer reflecting the respective stakeholder view in the process (Figure 10). The Business view and Architect's view together correspond to the strategy and planning phases of the system engineering process. The Business view deals with the elicitation of high-level security objectives and constraints that are important to do business. It is essential to analyze the context of the business before building a secure system. This view facilitates the specification of the business security needs (e.g., reputation), operational goals and risk impacts (e.g., monetary loss) that drive the necessity of a secure system. The Architect's view concerns the integration of protection objectives (e.g., application security services, network security services, data security services, etc.) that are necessary to secure the business security needs. The Designer's view and builder's view together, correspond to the designing phases of the system security engineering process. The Designer's view deals with the specification of the security services (e.g., network entity authentication, data integrity protection, etc.) that are necessary to satisfy the control objectives. The builder's view deals with the mapping of the technical security mechanisms (e.g., firewalls, hashing, etc.) to the logical security services. Finally, tradesman view (LV5) corresponds to the final implementation phase of the system security engineering process. The latest view called operational manager's view corresponds to the maintenance management of the system security engineering process after the deployment. SABSA is not strictly a security requirement engineering approach. This method provides a broad picture to understand the conventional security requirements engineering process starting from the perspective of the business system security architecture. The SABSA also includes a matrix that describes a wide variety of aspects that a modeler  
Figure 10: The SABSA layers. Figure 9: Second scenario. should be able to express (Cf. Figure 11) with the help of six interrogative questionnaires (what/why/how/who/where/when). This matrix guides the security architect in asking the right questions at the right time. Thus, it structures the security engineering process. In SABSA, network security requirement analysis (e.g., related to security zoning) starts from the designer's view (i.e., LV3). Since we demonstrated in the first iteration of evaluation that STS does not support to derive network security zoning; therefore, we confine this second experiment to the first two views of SABSA only (i.e., Business view and Architect's view). This implied that any discussion related to network security requirement analysis has been purposefully discarded. This strict confinement to the high-level abstraction improved the elicitation activity by provoking a long discussion. Indeed, this strict confinement to the SABSA abstraction has helped the team in focusing more on \"WHAT\" perspectives of security needs rather than \"HOW\" perspective of security needs. During this experimentation, we observed that the elicitation part of the scenario seemed clear and provoked a useful discussion. Initially, the description of this scenario fits in just few lines. However, during the process of SRE modelling, the provoked discussion has developed the scenario details which resulted in an STS social model.