Fig. 4.1 shows two different MDS approaches in the MDS-MoRe framework: one on the left hand side for dealing with a specific, complex security concern with extensive semantic, and another one on the right hand side for dealing with multiple security concerns systematically. The whole framework can roughly be divided into the following phases:
• Modelling: The task of this phase is to specify security concern(s) by using either domain-specific models or UML models. One important aspect of this phase is to really enforce separation of concerns between the security concerns and the core business logic of systems. Security concerns are modelled separately into security-oriented models. In the later phases, the security-oriented models will be integrated into the base model containing the business logic of the system to make the system secure.
• Composing: It is the process of transforming, weaving the security-oriented mod-els into the base system model. The output of this phase is the composed model called security-enforced model.
• Testing: In this phase, test cases can be generated to evaluate the validation of the generated secure code. Testing techniques such as mutation analysis can be leveraged to improve the set of test cases.
• Code Generation/Implementation: From the security-enforced model, (par-tial) code generation can be performed to generate (the skeleton of) secure code.
Each MDS approach is presented separately according to these phases in the following sections.
4.3 MDS with Modularity
On the left hand side of Fig. 4.1, an MDS approach with modularity is presented. The framework is for dealing with a specific but complex security concern, i.e. delegation in access control management. Thus, a DSL for modelling delegation has been developed for capturing the complex semantics of delegation in access control management. The delegation models, access control models, and business logic models of a system can be specified separately. In fact, the target systems of this work are adaptive component-based systems in which leveraging modularity would enable the secure systems to evolve at runtime. On the other hand, mutation testing is employed for validating the im-plementation of delegation in access control management of the resulting system. The details of this MDS approach are presented in Chapter5. The main ideas in each phase are described as follows, from modelling till testing and code generation.
4.3.1 Domain-Specific Modelling of Security Concerns
Access control is a popular security concern that has been focused in a majority of MDS studies as indicated in Chapter 3. So far, MDS studies mainly focus on static definitions of access control policies, without taking into account the more complex, but essential, delegation of rights mechanism. Delegation is a meta-level mechanism for administrating access rights, which allows a user without any specific administrative privileges to delegate his/her access rights to another user. As can be seen in Fig.
4.1, three DSLs have been developed for specifying access control, delegation and the business logic as separate concerns. A specific DSL is developed for capturing the
Modelling
complex semantics of delegation in access control management. This DSL is an extension of another DSL which can be used to specify a Role-Based Access Control (RBAC) policy. Besides, the business logic of a target system is modelled by using the third DSL capturing component-based architecture. The output of this phase is the delegation policy model, the access control policy model, and the component-based architecture system model.
4.3.2 Transforming and Composing Models
Because of its complexity and relation to access control, delegation can be seen as a
“meta-level” mechanism which impacts the existing access control policies similarly as an aspect can impact a base program. An ad-hoc MMT has been developed to trans-form the access control policy model according to the delegation rules specified in the delegation policy model. The result of this step is an active access control policy model reflecting both delegation rules and active access control rules. Then, the active access control policy model is transformed into a three-layer component based architecture model. This model is integrated into the architecture model of the base system for enforcing the security policy at the model level.
4.3.3 Testing
The meta-level characteristic together with the complexity of delegation itself make it crucial to ensure the correct enforcement and management of delegation policy in a system via testing. To this end, we adopt mutation analysis for delegation policies.
In order to achieve this, a set of mutation operators specially designed for introducing mutants into the key components (features) of delegation is proposed. Test cases are derived from the security policy (see Fig. 4.1). The mutation operators are used to mutate the delegation policy and its enforcement which result in mutated code. The mutated code is then used to evaluate and improve the quality of the set of test cases.
4.3.4 Code Generation
Last but not least, (partial) code generation is another automated step to ensure the productivity of MDS in the secure systems development. From the security-enforced architecture model, the (partial) source code of the secure system in the target im-plementation platform can be generated. In fact, the DSLs are platform-independent.
Because our target secure systems are of type component-based architecture, we show that the security-enforced architecture model can be used to generate components for two different adaptive execution platforms, i.e. Kevoree and OSGi. More details can be found in Chapter 5.
4.4 MDS with Reusability
On the right hand side of Fig. 4.1, another MDS approach promoting not only modu-larity but also reusability based on AOM is presented. The approach is for addressing
multiple security concerns systematically. The catalogs of security patterns are the most accessible, well organised, documented resources of different security solutions for dif-ferent security concerns, e.g. [72, 211, 220]. In our approach, we develop a unified System of Security design Patterns (SoSPa) based on RAM. Our SoSPa metamodel is an extension of RAM metamodel (see Fig. 4.1). The security pattern models, the supporting RAM models, and the base system model are specified at the modelling phase. At the composing phase, by using RAM weaver and a pattern refinement pro-cess, security solution models are constructed and woven into the base system model.
The source code (skeleton) of the target system can be generated from the resulting model (security-enforced model). Chapter6presents the details of this MDS approach.
The main ideas in each phase are described as follows.
4.4.1 Aspect-Oriented Modelling of Security Concerns
In SoSPa, security design patterns are collected, specified as reusable aspect models to form a coherent system of them that guides developers in systematically addressing mul-tiple security concerns. More precisely, our MDS framework allows selecting, refining, composing security design patterns to systematically build security solution models, and then automatically integrating them into a target system design. Other RAM models and base system model are also specified in this phase.
4.4.2 Mapping and Weaving Models
In this phase, the mappings to integrate the newly built security solutions to a base system model are defined. Once all the necessary mappings and constraints are resolved, RAM weaver can execute the composition of the security solutions to a base system model to obtain the security-enforced system model.
4.4.3 Testing
We have some inspiration from the approach proposed by Kobashi et al. [133] where test templates could be introduced into the security design patterns for later validation of their application. This idea has not been realised yet in the work presented in this thesis. However, this is indeed a good point for future work.
4.4.4 Code Generation
The (skeleton) of source code can be generated automatically from the security-enforced model. This step is also supported by the RAM tool.