Faculty of Information and Communication Technologies
MDSE@R: Model-Driven
Security engineering at runtime
System Preparation for Adaptive Security Management
Abstract - New security threats arise frequently and impact on enterprise software security requirements. However, most existing security engineering approaches focus on capturing and enforcing security requirements at design time without paying attention to how a system should be adapted to cope with new unanticipated security requirements that arise at runtime. We describe a new approach - Model Driven Security Engineering at Runtime (MDSE@R) - enabling security engineers to frequently specify, build and enforce system security capabilities based on their current needs. Our approach uses domain-specific visual languages to model architectural characteristics and security requirements of an application. MDSE@R refines and merges these visual models and uses model-driven engineering to take the merged model and specify security controls to be enforced on system components. A combination of interceptors via generated configurations and injected code using aspect-oriented programming are used to realize the required security controls on a deployed application. We describe our approach, give an example of using it to secure an ERP system, describe its implementation and discuss an evaluation of our techniques.
Keywords – security engineering, model-driven engineering, domain-specific visual languages, aspect-oriented programming.
I. INTRODUCTION
The security engineering field [1] focuses on delivering secure applications that maintain their operations and achieve desired goals even if under attack. Unfortunately such goals and attacks are always changing over time. Thus security engineering is not a one-time process and software security should be revisited and updated whenever new security requirements and challenges arise. Most current security engineering processes are conducted side by side with the system engineering process [2]. This approach involves system engineers as key stakeholders in the system security engineering process. However, they often lack experience in identifying, and sometimes in protecting against, possible security issues. They may also lack knowledge about customers’ security needs as some potential customers may not even be known at design time. Thus the final software product will often be incomplete from a security perspective. It will usually have hardcoded security implemented within system code either as security controls [3, 4] or as security attributes that need to be enforced on the application’s operations [5]. In either case, unanticipated security requirements are not usually considered. Software maintenance is usually required to address emerging security issues and new security requirements raised by customers. Such maintenance may take much more time than can be accepted where discovered vulnerabilities can be exploited [6]. Moreover, sometimes the system vendor may no longer even exist. Thus post-deployment discovery of security issues or changed application environment security needs are hard to address using existing software security engineering approaches.
Most traditional security engineering approaches either incorporate security as a part of the overall software engineering process e.g. an aspect of requirements, design, implementation and testing [1], or security engineering is conducted as a concurrent activity [2, 7]. Much of the research effort on security engineering has focused on how to identify security requirements based on security goals/objectives and security risks. They also focus on how to meet such requirements in system designs and refine them into
security implementations in terms of security patterns, code and/or application configurations. These traditional security engineering approaches typically result in systems with fixed, built-in security, limited integration with third party security controls, and very limited flexibility in terms of adaptation and integration with a software application’s operational environment security management systems. As all security challenges cannot be fully anticipated at design time, engineering security into systems at runtime needs to be supported. Some approaches to run-time security engineering do exist e.g. using aspect-oriented programming [8], service-oriented architectures [9], and run-time adaptation approaches incorporating limited run-time security configuration of components [10]. Most are limited in expressiveness, flexibility and software engineering process and tool support.
We propose a new approach to this problem, Model Driven Security Engineering at Runtime (MDSE@R). MDSE@R uses a set of high-level to detailed-level system description models that specify a software system’s features, components, classes, behaviour, and deployment details. These models are at different abstraction levels and provide different perspectives of a system. Software engineers, application customers and the service provider’s security engineers specify various levels of cross-cutting security goals, objectives, and requirements that must be enforced on this target software system. They also specify the detailed architecture of the security services that will deliver the security levels specified. Using these system and security models we derive a detailed, merged system security model for the target software system. This merged system security model is then used to dynamically inject security extensions into the target system. The modelled security architectures and security controls are weaved with system code at runtime. The security and system models can be updated at run-time to reflect changing operational environment, customer security requirements and security threats, and run-time updates made to the target system to reflect these. We have developed a set of domain-specific visual languages supporting both system and security modelling for MDSE@R. We have developed a proof of concept support tool using Visual Studio 2010 and Patterns-and-Practice (PnP) aspect-oriented programming for C#. We have applied our approach on two significant applications including a third-party C#.NET application and conducted a preliminary user evaluation of our tools.
Section II begins with a motivating example for this research. Then we identify key challenges and requirements that should be satisfied by a security engineering approach. Section III reviews key related work in security engineering research. Section IV provides an overview of our MDSE@R approach. Section V describes a usage example of our MDSE@R framework and toolset. Section VI describes our framework architecture and implementation details. In Section VII we discuss an evaluation of our approach, its key strengths and weaknesses and areas for further research.
II. MOTIVATION
SWINSOFT, a software company, is going to build a large web-based Enterprise Resources Planning (ERP) system, called “Galactic”. This Galactic ERP system will provide customer management, order management, employee management and general manager modules. SWINSOFT would like to target different markets in different countries for this software application. However, these domains and likely customers have different regulations and information security standards that must be satisfied. Moreover, SWINSOFT found that customers' security requirements that Galactic must meet may change
overtime. Swinburne University wants to purchase a new ERP solution in order to improve its internal enterprise management processes. After investigation, Swinburne has decided to purchase the Galactic ERP solution. Swinburne has special security requirements because it is ISO27000 certified. Its enterprise architects conduct periodic risk assessment which requires reconfiguring systems security to block newly discovered threats. Swinburne also wants to have its ERP system security flexible enough as it is planning to integrate its ERP system with those of its existing and future partners. This implies that the Galactic application’s security must change over time after its deployment in Swinburne environment.
At the same time, another potential SWINSOFT customer, the University of Auckland, has decided to purchase Galactic. Auckland also has its own security requirements and operational environment that Galactic should satisfy, but these are quite different to Swinburne’s. Auckland expects the security solutions deployed in its application operational environment to change over time. Galactic must be able to be updated quickly to adjust to these, as well as any emergent security threats.
An analysis of this scenario identifies the following challenges:(i)security requirements differ from one customer to another; (ii) each customer’s security requirements may change over time based on the current operational environment security and their business objectives; (iii) Galactic system’s security must be integrated with each customer’s deployed application environment security controls in order to achieve coherent security solutions; and (iv) new security vulnerabilities may be discovered in Galactic system at any time. This requires SWINSOFT to conduct system maintenance in order to deliver system patches that help blocking such vulnerabilities and adapts system to new customer needs.
A security engineering approach that addresses these challenges should: (i) enable each customer to specify and enforce their security requirements based on their own security needs; (ii) security should be specified at any system entity. This means that we do not have to predefine security interception points at design time but the system should support interception at any applicable point; (iii) security specification should be supported at different levels of abstraction based on the customers’ experience, scale and security engineers’ capabilities; (iv) security integration should be supported at different abstraction levels of system description starting from the system as one unit down to system methods; (v) the security engineering approach should enable integration with third-party security controls; (vi) security and system specifications should be reconfigurable at runtime.
III. BACKGROUND
A. Security Engineering
Software security engineering aims to develop secure systems that remain dependable in the face of malice, errors, and attacks [1]. Security engineering includes: identifying security objectives/goals that systems should satisfy; identifying security risks that threaten system operation; elicitation of security requirements that should be enforced on the system to achieve the security levels expected; developing security architectures and designs that deliver the security requirements and integrates with the operational environment; and developing, deploying and enforcement of the developed or purchase security controls.
Goal and agent based security engineering approaches focus on the security requirements elicitation phases, and are based on analysing the potential stakeholders’ goals and obstacles to satisfy such goals. KAOS focuses on capturing stakeholders’ goals and refining such goals into sets of requirements. KAOS was extended to capture security requirements in terms of obstacles to stakeholder’s goals [11]. The obstacles are defined in terms of conditions that when satisfied will prevent certain goals from being achieved. Secure i* [12] identifies security requirements through analysing relationships between users, attackers, and agents of both parties. Secure Tropos [13] captures details about the security requirements and trust goals, introducing two categories of goals: hard goals that reflect system functional requirements and soft goals that reflects system non-functional requirements such as security.
Models-based security engineering approaches: typically focus on security engineering during system design phases. Misuse cases [14] capture the use cases that the system should not allow that may harm or threaten the system operation or security. UMLSec [3] extends UML with a new profile that provides stereotypes to be used in annotating design elements with security intentions and requirements. UMLSec provides a comprehensive UML profile but it was developed mainly for the design phase. SecureUML [15] provides a meta-model to design role based access control policies of the system.
Security engineering processes: include SQUARE [16], SREP [17] and Microsoft SDL [18]. Such processes specify steps to follow in capturing, modelling, coding system security requirements. Such processes are aligned with system development processes. Most security approaches and processes focus on engineering security at design time. Moreover, they make assumptions about the security of the environments in which an application will operate. It is often difficult to integrate a system’s security with the operational environment security as software systems use their built-in security controls and do not provide interfaces to plug-in third-party controls.
B. Aspect Oriented Programming
One of the main motivations behind the Aspect-Oriented Software Development (AOSD) was to handle problems caused by code scattering and tangling, as often happens with security implementation code [19]. AOSD is based on the concept of separation of concerns where system engineers can express different concerns in separate modules from functional features. Aspects can be specified at programming level – Aspect-oriented programming, or requirements and design - early aspects [20]. Such concerns are weaved (integrated) with the working system. Weaving of aspects, may occur at compilation time – static weaving, or at load/execution time – dynamic weaving. Java and C# have extensions that support AOP.
Mouelhi et al [7] introduce a model-driven security engineering approach to specify and enforce system access control security policies at design time based on AOP - static weaving. Fabien et al [24] introduce a framework based on AOP to implement dynamic web services security. This encapsulates security configurations into aspects that are weaved to a Stub at service load time based on user requirements of the current service request. Security is enforced at service-level using WS-Security standards but neither high-level security specifications nor fine-grained security enforcements are available.
C. Adaptive Application Security
Several research efforts try to enable a system to adapt its security capabilities at runtime. Elkhodary et al [21] survey adaptive security systems. Extensible Security Infrastructure [22] is a framework that enables systems to support adaptive authorization enforcement through updating in memory authorization policy objects with new low level C code policies. It requires developing wrappers for every system resource to catch calls to such resources and check authorization policies. Strata Security API [23] systems are hosted on a strata virtual machine (container) which enables interception of system execution at instruction level based on user security policies. The framework does not support securing distributed systems and it focuses on low level policies specified in C code. Serenity [5] enables provisioning of appropriate security and dependability mechanisms for Ambient Intelligence systems at runtime. Security attributes are specified on system components at design time and at runtime the framework links such Serenity-aware systems to the appropriate security and dependability patterns. Serenity does not support dynamic or runtime adaptation for new security requirements. Morin et al [10] propose a security-driven and model-based dynamic adaptation approach enabling adapting of applications based on a context-aware access control policy enforcement approach. Engineers develop security policies at runtime based on a predefined system context and whenever an update in the system context is available, the proposed approach enforces security policies and reconfigures the system architecture accordingly.
IV. OUR APPROACH
Our MDSE@R approach is based on two key concepts: (i) Model-driven Engineering (MDE) using domain-specific visual language models at different levels of abstraction to describe system and security properties; and (ii) aspect-oriented programming that enables dynamic runtime weaving of interceptors and code based on configuration files that specify the required security cut points in the system. All target application functions are potential join-points (a place where we can add security aspects). Figure 1 shows the main MDSE@R components.
Phase 1 – Develop System Description Model: a detailed System Description Model (1), a set of models developed by system provider software engineers, is developed to describe various details of the target software systems. System description models include: system features model, system architecture model, system classes’ model, system behaviour model, system deployment model, and system context model. We have selected these models as they cover all system perspectives required in order to specify system security. Use of many of these sub-models is optional in our approach. Use depends on how many of the system details the system provider would like to expose to their customers and how much details the customer security engineers will need in enforcing required security on the target system. Security engineers may be interested in specifying security on system entities (using system components and/or classes models), system states (using system behaviour model), system hosts (using system deployment model), or external system interactions (using system context model). Some application structural information may be reverse-engineered from the target system (2).
System Description Models Security Specification Models
Security Enforcement Point
System Engineer Security Engineer
Sy st e m C o n ta in e r S y st e m S e cu ri ty S e rv ic e s Develop
1
Develop3
4
Live System Interceptors Document Live Security Specification Document S e cu ri ty T e st in g7
2
5
6
8
Figure 1. (A) Overview of our MDSE@R approach to supporting dynamic application security.
Phase 2 – Develop Security Specification Model: A Security Specification Model is a set of models developed by security engineers (3) to specify the security needs that must be satisfied in the target system. The model includes a set of sub-models that capture the details required during the security engineering process. These include security goals and objectives, security risks and threats, security requirements, security architecture for the operational environment, and security controls to be enforced. These models deliver different levels of abstractions and enable for separation of concerns between customer stakeholders including business owners, security analysts, security architects and implementers. The mandatory model in the security specification set is the security controls model as it is needed to generate interceptors and security aspect code.
A many-to-many relationship between the system description models and security specification models is developed by security engineers (4). One or more security concepts (security objective, security requirement and/or security control) can be mapped to one or more system model entities (system-level, feature-level, component-level, and class-level and/or method-level entity). Mapping a security concept on a higher level system entity implies a delegation to the underlying levels. Whenever a security specification is mapped to a system feature, this implies that the same security specification is mapped on the feature related components, classes, and methods.
Phase3 – Security enforcement: Whenever a mapping is defined or updated between a security specification model and a system description model, the underlying MDSE@R framework propagates such changes to an underlying secure system model (5). It then reflects it on the enforced security controls for the target system (6). A Live System Interceptors Document defines the cut points where security controls should be weaved/integrated with the target software application. It is generated and updated based on the modelled security specifications and the corresponding system entities where security should be applied, as described in the merged secure system model. The Live Point Security Specification Document defines the security controls to be applied at every specified point-cut defined in the system interceptors’ document.
Phase 4 - System Security Testing: the security controls weaved within the system is assumed to be validated by the security controls providers. We need to make sure that the intended security has been enforced correctly on the target system at run-time. We use system interceptors and security specification documents to generate and fire security integration test cases (7) to verify that the specified security controls have been correctly integrated with system entities.
As shown in Figure 1, a set of supporting components manage the updating and enforcement of security controls on the target system. These include: a System Container which is responsible for injecting interceptors as defined in the system interceptors document into the target system at runtime. Any call to a method will be intercepted whenever it has a matching security definition pattern in the interceptors’ document. A Security Enforcement Point is a bridge between the system container that intercepts requests to system methods defined in the system interceptors’ document and the security services that deliver the security controls required. The security enforcement point uses the live security specification document to determine what security controls should be enforced when a call to a method is intercepted. Security Services (8) are a set of application deployment environment security controls that are integrated with the security enforcement point. This integration enables the security enforcement point to communicate with security services through a set of APIs. These are defined by each security service or are standardized in the security enforcement point using one of the existing security management standards. These services may be a library of security patterns developed by the system provider or a third-party. They may also be commercial products deployed in the system operational environments that are integrated with the system at runtime.
V. USAGEEXAMPLE
To demonstrate the capabilities of our new security engineering approach, we revisit our motivating example from section II, the ERP system “Galactic” developed by SWINSOFT and procured by Swinburne and Auckland. The two customers using the Galactic ERP system, Swinburne and Auckland, have their own distinct security requirements to be enforced on each of their Galactic ERP application instances. We have developed a support tool for MDSE@R using Visual Studio 2010. We illustrate this scenario using screen dumps from our prototype DSL tools. The details of the usage example are documented in a technical report1.
Phase 1- Model Galactic system description
This phase is done during or after the system is developed. SWINSOFT decides the level of application details it is going to provide to its customers in the Galactic system model. Figure 2 (a) shows that SWINSOFT provides its customers with description of system features, system architecture, system classes, system deployment, system behaviour, and system context models.
SWINSOFT analysts then model the features delivered and published by the Galactic ERP system and the relationships between such features, using a Feature Model, as shown in Figure 2 (b). This includes composition and referencing relationships between different Galactic features. In this example, analysts have identified key features including order, employee and customer management.
SWINSOFT system architects then model the Galactic architecture reflecting the main Galactic components and their relationships, as shown in Figure 2 (c). In this example web services, web pages and presentation layer abstractions are captured. To enable their customers to define security on a feature-by-feature basis, Galactic architects link system components to the corresponding system features it realizes, as shown in Figure 2 (c).
SWINSOFT designers model Galactic critical classes, producing one or more Galactic class models. They may choose to model classes for either for the full system or for different system components separately using separate models. An example of a Galactic class model is shown in Figure 2 (d). Our approach MDSE@R enables modelling system classes manually as well as reverse engineering system class models from the target system.
SWINSOFT system architects model the deployment details of Galactic components using a Galactic deployment model. They specify for each component deployment its path and configuration file, as shown in Figure 2 (e). This includes the various servers, networks and application components that make up Galactic application. Deployment information is used to locate target application components at runtime.
SWINSOFT architects then specify various system and component states and the actions that can trigger system transitions between states. This produces a Galactic behaviour model using a state chart metaphor to represent components and their states and transitions. SWINSOFT architects also model the systems that are expected to interact with Galactic including referenced services delivered by other parties.
Phase2 – Model Swinburne and Auckland security needs
This phase is conducted by each customer’s security engineers during the customer security management process (a repeating process). In our scenario, Swinburne security engineers, during their application security management process, document Swinburne security objectives that must be satisfied by the Galactic system in its operational environment. This is done using a high-level security objectives model, as shown in Figure 3 (a). In this example, a range of high-level security needs for Swinburne of Galactic ERP are specified. This high-level objectives model may be revisited at any time based on current Swinburne security objectives.
Swinburne security engineers then refine their security objectives in terms of security requirements that must be enforced on their new Galactic system, developing a security requirements model. Such a model specifies the traceability between the high level security objectives and the identified security requirements, as shown in Figure 3 (b). This example shows details about user authentication requirements and host security requirements to be enforced on Galactic. Such requirements can be revisited at any time.
Swinburne security engineers next develop detailed security architecture for Swinburne including other existing IT systems. This security architecture identifies the different security zones that cover Swinburne network and the allocation of systems, including Galactic, as either one unit or in terms of system components according to the Galactic deployment model. The security architecture also shows the security services, security mechanisms and standards that should be deployed, as shown in Figure 3 (c).
Swinburne security engineers finally specify the security controls (i.e. the real implementations) for the security services modelled in the security architecture model, as shown in Figure 3 (d). This includes a deployed Host Intrusion Prevention System, Forms-based Authentication and Antivirus. These are used to realize the security requirements and security architecture as previously specified. Each security
specification model maintains traceability information to parent models’ entities.
B E A D A C
Figure 2. Examples of the Galactic System Models.
Phase 3 – Security Enforcement
After developing the System Description Models and the Security Specification Models, the Swinburne security engineers map security attributes (in terms of objectives, requirement, and controls) to Galactic system specification details (in terms of features, components, classes). Figure 3 (e) shows a sample of the security objectives, requirements and controls mapped to classes and methods in Galactic system. In the example shown, the security engineer has specified that the AuthenticateUser security requirement should be enforced on the CustomerBLL class. Such a requirement is achieved using Windows-based authentication control. Moreover, they have specified Forms-based authentication on GetCustomers method. So a request to a method in CustomerBLL class will be authenticated by caller Windows identity but a request to GetCustomers method will be authenticated with Forms-based identity, as shown in Figure 4. The MDSE@R uses this security attributes mapped to system specification to generate a set of required operation interceptors and security configuration document, as shown in Figure 7.
Phase 4 - Galactic Security Testing
Once security controls have been enforced by generating required security interceptors, security engineers should make sure that the system is enforcing security as specified. Figure 4 shows an example of the running Galactic system after weaving Forms-based authentication control, required by Swinburne, with the system code. Our approach MDSE@R generates and fires the necessary security integration test cases. Swinburne security engineers check the security test cases execution log, as shown in Figure 5, to make sure that no errors were detected in integrating Galactic entities with the specified security controls.
D B
E C
A
Figure 3. An example of some of the Swinburne Security Specification Models.
Auckland security engineers go through the same process as Swinburne security engineers when specifying their security management requirements. However, Auckland has differing requirements, context, security controls, and other applications. Thus Auckland security engineers produce a different system context and deployment model, different security requirements and control models, and MDSE@R generates a different set of interceptors and security specification documents.
Both Swinburne and Auckland security engineers can modify the security specifications while their Galactic applications are in use. Our MDSE@R framework updates interceptors in the target systems and enforces changes to the security specification for each system as required. For example, the Swinburne Galactic security model can be updated with a Shibboleth single sign-on security authentication component. The updated interceptors and security specification are applied to the running
Galactic deployment, which then enforces this authentication protocol instead of the Forms approach as above.
Figure 4. An example of running the Galactic ERP system with injected Forms Authentication Control.
Figure 5. An example log of firing generated security test cases.
VI. ARCHITECTURE AND IMPLEMENTATION
The architecture of our proof of concept MDSE@R framework used to validate our approach is shown in Figure 6. It consists of a system description modelling tool (1), a security specification modelling tool (2), a repository for the system and security models (3), a library of registered security controls and extensible security patterns that can be used by security engineers in enforcing their security needs (4), a system container that manages system execution and intercepts requests and function calls for system entry points at runtime (5), and a security test case generator (6) that is used to test the configured application security controls.
Our System Description Modeller (1) tool was developed as a plug-in for Microsoft Visual Studio 2010 to enable system engineers modelling their systems’ details with different perspectives including system features, components, etc. The tool supports use of a set of domain-specific visual languages providing a set of system description models. Each model has a corresponding DSL. Parts of our MDSE@R approach can be realized using UML and UML profiles in the system and security modelling. However, security engineers are generally not familiar with UML models and their semantics, and UML profiles can get very complicated. In addition, validating the correctness of these extended models becomes challenging. Instead we decided to develop a set of purpose-designed Domain-Specific Visual Languages (DSVLs) to model system and security details in terms that are understood by security engineers.
The System Model DSL defines the main concepts used by system engineers in capturing their system description details, including system features model, system architecture model, system class model, system behaviour model, system deployment model, and system context model concepts. Use of some of these models is optional, based on the system provider decisions i.e. what details of their system they wish to expose. Security engineers may decide to specify security at a system level, so they map their
specified security concepts to the system model. The System Features DSL captures system features and the relationship between system features including composition and dependency relationships. The system feature concept uses compartments to capture security objectives, security requirements, and security controls that will be applied at the feature level. Any security specification defined on a system feature is delegated to the underlying system components, classes and methods.
Figure 6. MDSE@R architecture, tools and sequence of operation.
The System Architecture DSL captures specifications of system components, their relationships including composed-of and uses. The system architecture DSL captures the mapping between system components and system features (what feature(s) are realized by a component). Components, ports, and links are extended with compartments to capture security objectives, security requirements, and security controls to be applied on the component or to the communication between components. The System Deployment DSL captures the deployment details of the system components, nodes, and networks. Nodes and networks use compartments to capture security objectives, security requirements, and security controls to be applied on the system hosts and underlying network. The System Behaviour DSL is used to describe system states, transitions and actions that trigger such state transitions. Each state has security objectives, requirements and controls that should be enforced whenever the system moves to such state. The System Context DSL specifies systems existing in the operational environment with the target system and share interactions with it. Each link in the context model may have different security objectives, requirements and controls used when communicating with the corresponding system.
The Security Specification Modeller tool (2) is also a Visual Studio 2010 plug-in. It enables application customers, represented by their security engineers, to specify the security attributes and capabilities that must be enforced on the system and/or its operational environment. The security modeller delivers a set of security models that enable capturing different levels of security abstractions. The Security Objectives DSL captures customers’ security objectives and the relationships between these. Each objective has a criticality level and the defence strategy to be followed: preventive, detective or recovery. The Security requirements DSL captures customer’s security requirements and relationships between requirements
Component2 Component1 Component3 CLS CLS System Container
Security Enforcement Point
Security Controls
Authn
Authz Encrypt Class
level App. Level Comp. Level Method level System Description Modeller
I/p validation Logging Security Specification Modeller Models Repository
…
…
S y s te m R e q u e s ts1
2
7
5
8
9
3
4
Validated Request 10 S e c u r it y T e s t c a s e s G e n e r a t o r6
including composition and referencing relations. The Security Architecture DSL captures security architectures and designs of the customer operational environment in terms of security zones and security level for each zone; security objectives, requirements and controls to be enforced in each layer; components and systems to be hosted in each layer; security services, mechanisms and standards to be deployed in each layer or referenced by other layers. The Security Controls DSL captures details of security controls that are already registered and deployed in the customer environment and relationships between these.
Our Security Test Case Generator (6) uses the NUnit testing framework to partially automate security controls and system integration testing. We developed a test case generator library that generates a list of security test cases for authentication, authorization, and input validation for every enforcement point defined in the interceptors’ document. MDSE@R uses NUnit library to fire the generated test cases. MDSE@R notifies security engineers via test case execution result logs.
To implement our run-time security enforcement, we use a combined interceptor and AOP approach. Whenever a client or application component makes request to any system component method, this request is delegated to the system container, as shown in Figure 6 (7). The system container uses the Unity application block delivered by Microsoft Patterns and Practice team to intercept these calls. This is a .NET-based implementation of the interceptor and inversion of control design patterns. It supports dynamic runtime injection of interception points on methods, attributes and class constructors. Whenever a request for a system method is received, the system container checks for the requested method in the live interceptors’ document. If a matching found, the system delegates the request with the given parameters to the interception handler - security enforcement point (8). This implements an aspect-oriented solution to injecting security interceptors at a fine-grained level into the target application.
The Security Enforcement Point (9) is a class library that we developed to act as the default interception handler and the mediator between the system and the security control solutions. Whenever a request for a target application operation is received, it checks the system security specification document to enforce the particular system security controls required. It then invokes such security controls through APIs published in the security control database (4). The Security Controls Database is a library of available and registered security patterns and controls. It can be extended by the system providers or by a third party security provider. Security controls implement certain interfaces as defined by the security enforcement point in order to be able to integrate with target security control systems. Having a single enforcement point with a predefined interface for each security control category enables security providers to integrate with systems without having to redevelop adopters for every system. We adopted the OWASP Enterprise Security API (ESAPI) library as a part of MDSE@R security controls database2. The security enforcement point validates a request via the appropriate security control(s) configured and specified, e.g. imposes authentication, authorization, encryption or decryption of message contents. The validated request is then propagated to the target system method for execution (10). Post-processing of the returning response from the system is carried out and then control returns to the requesting application via the System Container.
2 https://www.owasp.org/index.php/ESAPI
Both modelling tools are based on VS 2010 Modelling SDK that enables developing DSVLs integrated with VS IDE. To develop each DSVL, we developed a meta-model for the DSL domain and specified the corresponding shapes that visualize each domain model concept. Then we specified the mapping between the domain concepts’ attributes and the shape compartments. Finally we developed code generation templates that generate the system live interceptors’ document and the security specification document from the system and security models. Our modelling tools use a repository to maintain models developed either by the system engineers or by the security engineers. It also maintains the system live interceptors’ document and security specification document. Examples of these documents are shown in Figure 7. This example shows: a sample of Galactic interceptors’ document generated from the specified security-system mapping. It informs the system container to intercept GetCustomers and GetCustomerByName methods (1); a sample of Swinburne security specification file defines the security controls to be enforced on every intercepted point (2); a sample of the security enforcement point API that injects the necessary security controls calls before and after application code (3).
Figure 7. Example system interceptors and security specification files.
VII. DISCUSSION
We have applied our approach to two .NET applications. The first one is our Galactic ERP prototype that we developed. The second is an open source application “PetShop” [25], an enterprise n-tier sample application. We integrated PetShop with our system container to enable managing its security at runtime
public IMethodReturn Invoke( IMethodInvocation input, GetNextHandlerDelegate getNext) { EntitySecurity entity = LoadMethodSecurityAttributes( …);
if (entity == null || entity.HasSecurityRequirements() == false) { return getNext().Invoke(input, getNext);
}
//logging Before Call
this.source.TraceInformation("Invoking {0}", input.Arguments[0].ToString()); //Check for Authentication
if (entity.GetAuthenticationMethod() != AuthenticationMethod.None) { . . .
}
//Check for Authorization
if ( entity.GetAuthorizationMethod() != AuthorizationMethod.None ) { . . . } } . . . <systemlevel> <Entitylevel>1</Entitylevel> . . . <componentlevel> <objectname> . . . <classlevel> <objectname> . . . <methodlevel> . . .
< ObjectName> GetCustomers</ObjectName>
<Authentication_Method>Forms</Authentication_Method> <Authorization_Method>RBAC</Authorization_Method> . . .
. . .
<extension type="Interception" />
<register type="PresentationLayer.CustomerBLL, PresentationLayer ">
. . . <interception> <policy name="PolicyCustomersBLL"> <matchingRule name="MatchingRuleCustomersBLL" type="MemberNameMatchingRule"> <constructor>
<param name="nameToMatch" value="GetCustomers" /> <param name="nameToMatch" value="GetCustomerByName" />
. . .
<callHandler name="callhandlerCustomersBLL"
type="SecurityKernel.SecurityCallHandler, SecurityKernel">
. . .
1
2
with MDSE@R. We mapped security capabilities to classes and methods in the Galactic ERP system and to system components in the PetShop system, as shown in the example in Figure 8.
Using our approach, we succeeded in modelling detailed system and security specifications for both systems using our MDSE@R DSVL-based tools. We used these models to generate interceptors for both applications and our framework enforces these security requirements at runtime. Updating the security specifications results in run-time update of the target application interceptors and security enforced. Updated security requirements are immediately reflected in the target application. This is a key issue in environments where multiple applications must enforce the same security requirements. Having one place to manage security reduces the probability of errors, delays, and inconsistencies. Moreover, automating the propagation of security changes to underlying systems simplifies the enterprise security management process. Currently supported security modelling and enforcement mechanisms in MDSE@R include authentication, authorization, cryptography, digital signature, and input validation. Where possible, we have made use of existing third party security APIs, patterns and applications to enforce security.
We have carried out an informal user evaluation of our tools and approach. We had three post-graduate researchers in our research group, not involved in the development of the tool, to use our proof of concept prototype and framework. We had them explore several MDSE@R system and security DSVL specifications of the PetShop application. They then modified the security requirements and updated the PetShop security specification at run-time. We surveyed these researchers to gain feedback on our DSVL models, modelling tools, and security enforcement framework. They successfully understood and updated security requirements for the target system. They were positive about the overall approach and the tool usability, and the capabilities in managing system security. They recommended using more expressive icons for system and security concepts and to enable transformation from UML models to our DSVLs.
Overall, our approach provides a model-driven security engineering methodology, a set of system and security specification domain-specific visual language models, a toolset that supports modelling with such models, and enforces the modelled security specifications on a system at runtime without the need for bespoke system customizations. It supports security engineering from design time to runtime. This allows security engineers to consider new security issues that arise during system operation and have not been seen during the design phase. Our approach works best for new systems with no security built into the system at design time. It allows software and security engineers to model software structure and security requirements initially separately and then merges these together into a detailed security specification. This is then run-time enforced via interceptor and AOP mechanisms.
For existing systems that we would like to extend their security capabilities we have two scenarios: we have the system specification models so we can use our approach to specify and enforce security. Alternatively we reverse engineer parts of system models and then use our approach. For existing systems with built-in security that is already modelled at design time and hard-coded into the system we can use our approach to add new security capabilities. Potentially we can modify and delete existing security by leaving out, using AOP, existing security methods.
Figure 8. Mapping security properties to PetShop Components Model.
One may argue that our approach will lead to open systems that are full of security issues because we may not have considered any security engineering during design time. Our argument is that at design time security engineering is often done by security non-experts and this is a leading reason why we still discover a lot of vulnerabilities in systems. Moreover, system providers can still go through security engineering processes during design time while enabling our approach to be applied at runtime by delivering their system’ security models. Some key issues in adopting our approach include the possibility that software companies may not want to publish their system specifications for intellectual property reasons. This can be handled through agreements with their consumers or by getting customers involved in security specification only and let the system provider models the required security-system mappings. Another challenge is how to keep the system specification models updated with evolving system changes in case of adaptive systems or design time changes in traditional system maintenance iterations.
We would like to apply our approach against java-based applications, especially leveraging Spring Inversion of Control, Spring AOP and AspectJ. We are exploring the possibility of automating the security model refinement process where security engineers specify security objectives and our MDSE@R can select appropriate security controls that best match required security level. We are investigating dynamic weaving of security models with a system based on a system threat model that identifies system weak points.
VIII. SUMMARY
MDSE@R is a new model-driven approach to dynamically engineering security for software applications at runtime. Our approach is based on a combination of multi-level system description models, developed by system providers, and a set of security specification models that capture customer security objectives, requirements and deployment environment security controls. MDSE@R then bridges the gap between these two specifications through merging of the system and security models into a joint system security model. Security specifications are loosely coupled with system specifications, enabling both to evolve and allowing sharing of security specification models among different systems. MDSE@R supports specification of dynamic security controls for systems based on current customer security objectives and system operational environment. Dynamic injection of security enforcement interceptors and code into the target system ensures integration of systems with existing
enterprise security architecture. We have developed a proof of concept set of modelling tools and framework. We have validated our approach by applying it to a web-based ERP system we developed and to a third party developed web-based application.
REFERENCES
[1] R. Anderson, "What is Security Engineering?," in Security Engineering: A Guide to Building Dependable Distributed Systems, 2nd ed. Indianapolis, Indiana: Wiley and Sons, 2001, pp. 3-12. [2] T. Phan, J. Han, et al., "SOABSE: An approach to realizing business-oriented security
requirements with Web Service security policies," in Proc. 2009 IEEE Int. Conf. on Service-Oriented Computing and Applications, Taipei, Taiwan, 2009, pp. 1-10.
[3] J. Jürjens, "Towards Development of Secure Systems Using UMLsec," in Proc. 4th Int. Conf. on Fundamental Approaches to Software Engineering, London, UK, 2001, pp. 187-200.
[4] H. Mouratidis, and J. Jurjens, "From goal-driven security requirements engineering to secure design," Int. Journal of Intelligent Systems, vol. 25, 2010, pp. 813-840.
[5] F. Sanchez-Cid, and A. Mana, "SERENITY Pattern-Based Software Development Life-Cycle," in Proc.19th Int. Workshop on Database and Expert Systems Application, Turin, Italy, 2008, pp. 305-309.
[6] J. Guo, J. Yuan, and R. Johnson, "Pre-patched software," in Proc. 4th USENIX Conf. on Hot topics in security, Canada, 2009. pp. 6-6.
[7] B. Morin, O. Barais, et al., "Taming Dynamically Adaptive Systems using models and aspects," in Proc.31st IEEE Int. Conf. on Software Engineering, Vancouver, BC, 2009, pp. 122-132. [8] T. Mouelhi, F. Fleurey, et al., "A Model-Based Framework for Security Policy Specification,
Deployment and Testing," in Proc. 11th Int. Conf. on Model Driven Engineering Languages and Systems, France, 2008, pp. 537-552.
[9] M. Hafner, M. Memon, et al., "SeAAS - A Reference Architecture for Security Services in SOA," Journal of Universal Computer Science, vol.15, 2009, pp. 2916-2936.
[10] B. Morin, T. Mouelhi, F. Fleurey, et al., "Security-driven model-based dynamic adaptation," in Proc. 25th IEEE/ACM Int. Conf. on Automated software engineering, Belgium, 2010, pp. 205-214.
[11] A. Lamsweerde, S. Brohez, et al., "System Goals to Intruder Anti-Goals: Attack Generation and Resolution for Security Requirements Engineering," in Proc. RE’03 Workshop on Requirements for High Assurance Systems, Monterey, 2003, pp. 49-56.
[12] L. Liu, S. Eric, et al., "Secure ¡*: Engineering Secure Software Systems through Social Analysis," Int. Journal of Software and Informatics, vol. Vol.3, pp. 89-120, 2009.
[13] H. Mouratidis, and P. Giorgini, "Secure Tropos: A security-oriented Extension of the Tropos Methodology," Int. Journal of Software Engineering and knowledge Engineering, vol. 17, 2007, pp 285-309.
[14] G. Sindre, and A. Opdahl, "Eliciting security requirements with misuse cases," Journal Requirements Engineering, vol. 10, 2005, pp. 34-44.
[15] T. Lodderstedt, D. Basin, et al.,, "SecureUML: A UML-Based Modeling Language for Model-Driven Security," in Proc. 5th Int. Conf. on The Unified Modeling Language, Dresden, Germany, 2002, pp. 426-441.
[16] N. Mead, T Stehney, "Security quality requirements engineering (SQUARE) methodology," in Proc. of 2005 workshop on Software engineering for secure systems - building trustworthy, Missouri, 2005, pp. 1-7.
[17] M. Daniel, F. Eduardo, et al., "Applying a Security Requirements Engineering Process," in Computer Security – ESORICS 2006. vol. 4189, ed: Springer Berlin / Heidelberg, 2006, pp. 192-206.
[18] Microsoft: Microsoft Security Development Lifecycle, 2010, Accessed March 2010, Available:
www.microsoft.com/security/sdl/ discover/default.aspx.
[19] T. Elrad, R. Filman, et al., "Theme Section on Aspect-Oriented Programming," Communications of ACM, 2001, Vol. 44, No. 10, pp. 28-32
[20] G. Kiczales, J. Lamping, et al., "Aspect-Oriented Programming," in Proc. 11th ECOOP Workshop, Finland, 1997, pp. 483-496.
[21] A. Elkhodary, and J. Whittle, "A Survey of Approaches to Adaptive Application Security," in 29th Int. Conf. on Software Engineering Workshops, Washington DC, 2007, pp. 1-16.
[22] B. Hashii, S. Malabarba, et al., "Supporting reconfigurable security policies for mobile programs," in Proc. 9th international World Wide Web conf. on Computer networks, Amsterdam, The Netherlands, 2000, pp. 77-93.
[23] K. Scott, N. Kumar, et al., "Retargetable and reconfigurable software dynamic translation," in Proc. 2003 Int. symp. on Code generation and optimization, San Francisco, California, 2003, pp. 36-47.
[24] F. Baligand, and V. Monfort, "A concrete solution for web services adaptability using policies and aspects," in Proc. 2nd Int. Conf. on Service oriented computing, New York, USA, 2004, pp. 134-142.
[25] Microsoft: Microsoft .NET Pet Shop 4.0, 2006, Accessed March 2010, Available:
Figure 1-a: Meta-model of the System model, architecture and features models
Appendix (A)
Snapshoot of the DSLs Meta-Models
model of the System model, architecture and features models model of the System model, architecture and features models
Figure 2-a: Meta
Figure 2-b: Meta-model of the security architecture, design and controls models a: Meta-model of the security objectives and requirements models
model of the security architecture, design and controls models model of the security objectives and requirements models
