MDSE@R: Model-Driven Security Engineering at Runtime

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. Many do not address 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 dynamically specify and enforce system security requirements based on current needs. We introduce a new domain-specific visual language to model customer security requirements in a given application. Moreover, we introduce a new UML profile to help capturing system architectural characteristics along with security specifications mapped to system entities. Our MDSE@R toolset supports refinement and merger of these visual models and uses model-driven engineering to take the merged model and specify security controls to be enforced on the target system components. A combination of interceptors (via generated configurations) and injected code (using aspect-oriented programming) are used to integrate the specified security controls within the target system. We describe MDSE@R, give an example of using it in securing an ERP system, describe its implementation, and discuss an evaluation of applying MDSE@R on a set of open source applications. Springer.needs as some potential customers may not even be known at design time. Thus the final product will often be incomplete from a security perspective. Moreover, such systems usually have security hardcoded in their source code either as security realization functions [3,4] or as security annotation attributes that are translated at runtime into security controls delivered by an underlying security platform [5]. In either case, unanticipated security requirements are not usually considered. Software maintenance is usually required to address such emerging security vulnerabilities and new security requirements raised by customers. Maintenance may take much more time than acceptable where discovered vulnerabilities can be exploited [6,17]. Moreover, sometimes the system vendor may no longer even exist. Thus postdeployment discovery of security issues or changed application environment security needs are hard to address using existing software security engineering approaches.Existing security engineering efforts focus on how to identify, capture, and model security objectives and requirements and then how to map such requirements to system entities at design time, for example KAOS, UMLSec, secureUML [3,11,12,13,15]. These security engineering approaches typically result in systems with fixed and built-in security, limited integration with third party security controls, and very limited flexibility in terms of adaptation and integration with the software operational environment security management systems. Component-based (CBSE) and serviceoriented (SOA) security engineering approaches generate security code, using Aspectoriente...

Data-Driven Software Architecture for Analyzing Confidentiality

“…During runtime, enforcement of policies such as described by MDSE@R [22] becomes important. Although runtime is not in the scope of this work, we can exploit our iObserve approach [23] in order to update design time models by observations during runtime to make use of the analysis proposed in this paper based on architectural runtime models.…”

Adaptive security for Cloud data warehouse as a service

“…In addition, they don't treat the problem of the encryption of the association between multidimensional concepts. References [7,8] presented an adaptable security and model-based security, but authors don't deal with the problem of how to secure a CDW. In addition, the problem of how to adapt the security solution of CDW when the cloud server provider is changed is not treated.…”

“…Similar to our approach, in [7,8], the authors presented a model-driven security engineering approach for multi-tenant SaaS applications. This approach is based on externalizing security from the underlying SaaS application, which allows both service and security to evolve at runtime.…”