SoSPa: A System of Security Design Patterns forSystematically Engineering Secure Systems

Phu H. Nguyen§∗, Koen Yskout†, Thomas Heyman†, Jacques Klein∗, Riccardo Scandariato†‡, and Yves Le Traon∗§Simula Research Laboratory, Martin Linges vei 25, 1364 Fornebu, Norway

∗ SnT-University of Luxembourg, 4 rue Alphonse Weicker, L-2721 Luxembourg†iMinds-DistriNet, KU Leuven, 3001 Leuven, Belgium‡Chalmers & University of Gothenburg, Sweden

Abstract— Model-Driven Security (MDS) for secure systemsdevelopment still has limitations to be more applicable in practice.A recent systematic review of MDS shows that current MDSapproaches have not dealt with multiple security concerns system-atically. Besides, catalogs of security patterns which can addressmultiple security concerns have not been applied efficiently. Thispaper presents an MDS approach based on a unified Systemof Security design Patterns (SoSPa). In SoSPa, security designpatterns are collected, specified as reusable aspect models to forma coherent system of them that guides developers in systematicallyaddressing multiple security concerns. SoSPa consists of notonly interrelated security design patterns but also a refinementprocess towards their application. We applied SoSPa to designthe security of crisis management systems. The result shows thatmultiple security concerns in the case study have been addressedby systematically integrating different security solutions.

I. Introduction

Model-Driven Security (MDS) specialises Model-DrivenEngineering approach for secure systems development, butstill has limitations to be more applicable. Our recent system-atic review of MDS [11] shows that multiple security concernshave not been addressed systematically by existing MDSstudies. Indeed, the interrelations or dependencies amongsecurity solutions have not been considered systematically bycurrent MDS approaches. Developing modern secure systemsmust always address multiple security concerns to minimisedifferent security leaks and to make these systems resilientto different security attacks. A solution to address a specificsecurity concern often depends on other solutions address-ing other security concerns. For instance, most authorisationmechanisms depend on authentication mechanisms becausebefore an authorisation decision, the authorisation mechanismshould have known the identity of the requester. Authenticationmechanisms often rely on encryption mechanisms, especiallyfor distributed systems. Furthermore, there could be a lot ofdifferent variations of security solutions to address the samesecurity concern. All urge for an MDS approach that cansystematically address multiple security concerns, consideringinterrelations among security solutions and their variants.

Besides, from the security engineering’s point of view, oneof the best practices is the use of security patterns to guidesecurity at each stage of the development process [12]. Patternsare applied in the different architectural levels of the system

to realise security mechanisms. So far, catalogs of securitypatterns are the most accessible, well organised, documentedresources of different security solutions for different securityconcerns, e.g. [2, 12, 14]. But the results of a recent empiri-cal study [15] show that using existing catalogs of securitypatterns improves neither the productivity of the softwaredesigner, nor the security of the design. Indeed, securitypatterns could be applied at different levels of abstraction,e.g. architectural design rather than detailed design. Moreover,the levels of quality found in security patterns are varied,not equally well-defined like software design patterns [4].Particularly, many security patterns are too abstract or general,without a well-defined, applicable description. There is alsoa lack of some coherent specification of the interrelationsamong security patterns, and with other quality propertieslike performance, usability. In some catalogs, each securitypattern is described having its related patterns, and possibleimpacts on other quality properties mentioned, but without anymore practical or implementation details. To the best of ourknowledge, none of existing MDS approaches has proposeda System of Security design Patterns which provides not onlywell-defined security design patterns but also the interrelationsamong security patterns that can guide developers in system-atically dealing with multiple security concerns.

In this paper, we propose an MDS framework based ona System of Security design Patterns (SoSPa) that allowspractitioners to systematically address multiple security con-cerns in secure systems development. Our security patterns inSoSPa are theoretically based on well-known security designpatterns (e.g. in [2, 12, 14]). They are collected, specified asreusable aspect models (RAM) [6] to form a coherent systemof them. While not only specifying security patterns at theabstract level like in security patterns catalogs, SoSPa alsoprovides a refinement process supported by RAM to derive thedetailed security design patterns closer to implementation. Inother words, a software designer can reuse our security designpatterns that are specified at different abstraction levels asRAM models. By using SoSPa, an integrated security solutiondealing with multiple security concerns can be systematicallyengineered into a system. Not only the security design patternsbut also their interrelations are specified in SoSPa. Based onSoSPa, the conflicts and inconsistencies among the applied

978-1-4673-6908-4/15 c© 2015 IEEE MODELS 2015, Ottawa, ON, CanadaFoundations

Accepted for publication by IEEE. c© 2015 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses, in any current or future media, including reprinting/republishing this material for advertising or promotional purposes, creating new collective works, for resale or redistribution to servers or lists, or reuse of any copyrighted component of this work in other works.

52

246

security solutions in a system design can be detected, resolved,or eliminated systematically. This may help to improve thesecurity in a system design against different security threats.Because we propose an MDS development framework, SoSPais built on a meta-model, which is extended from RAM meta-model. Our MDS framework allows selecting, refining, com-posing security design patterns to systematically build securitysolution models, and then automatically integrating them intoa target system design. The contribution of this paper is threefold: 1) hierarchical RAM models with a refinement processfor specifying security design patterns from abstract level tilldetailed design level; 2) the explicitly specified interrelationsamong security design patterns for systematically dealing withmultiple security concerns; 3) an MDS framework supportingsecure systems development based on SoSPa.

In the remainder of this paper, Section II provides somefundamental concepts and motivational examples for our MDSapproach. Then, we present our MDS approach based onSoSPa in Section III, and some key security design patternsof SoSPa in Section IV. Section V shows how our approachhas been evaluated and discussed. Related work is given inSection VI. Finally, Section VII presents our conclusions andfuture work.

II. Background andMotivational Examples

A. System of Security Patterns

According to Schumacher et al. [12], a security patterndescribes a particular recurring security problem that arises inspecific contexts and presents a well-proven generic schemefor its solution. Security patterns typically do not exist in isola-tion because applying one solely can not make a system secureto different threats. Related patterns should be integrated forworking together to address more complex security problemsin the real world. A system of security design patterns is anintegrated collection of patterns for designing secure systems,together with guidelines for their implementation, combina-tion, and practical use in secure systems development. Somecatalogs of security patterns exist but might not be consideredas systems of security design patterns in which patterns arewell, concretely interconnected.

B. Reusable Aspect Models

RAM [6] is an aspect-oriented multi-view modelling ap-proach with tool support for aspect-oriented design of complexsystems. In RAM, any concern or functionality that is reusablecan be modelled using class, sequence, and state diagrams inan aspect (RAM) model. A RAM model can be (re)used withinother models via its clearly defined usage and customisationinterfaces [1]. The usage interface of a RAM model consistsof all the public attributes and methods of the class diagramsin the model. The customisation interface of a RAM modelconsists of all the parameterised model elements (marked witha vertical bar |) of the partially defined classes and methodsin the model. A RAM model can be (re)used by composingthe parameterised model elements with the model elementsof other models. A RAM model can also reuse other RAM

aspect Session depends on (Map xor ZeroToMany)structural view

|Session|SessionID|Attribute

|AttributeType

Map instantiation|Data → |Session

|Key → |AttributeType|Value → |Attribute

Op: add → addAttributeOp: getValue → getAttribute

+ |SessionID getSessionID()+ addAttribute()+ getAttribute()

- |SessionID id|Session |SessionID

|Attribute

|AttributeType

Fig. 1. Aspect Session Pattern

create(Crisis, EmergencyLevel, MissionDetails)

 Mission

boolean isAvailable()available: boolean

CMSEmployee

createMission(SuperObserver, MissionKind, EmergencyLevel, MissionDetails)

 CrisisManager

addMission(Mission) 

Crisis

Crisis getCrisis() SuperObserver

10..*

0..* 0..1observedCrisis

c: Caller

createMission(su: SuperObserver,

kind: MissionKind, level:

EmergencyLevel, details:

MissionDetails)

: CrisisManager su: SuperObserver

m: Mission

currentCrisis := getCrisis()

create(currentCrisis, level, details)

Fig. 2. A Partial Design of CMS with createMission Function [7]

models in a hierarchical way. RAM weaver is used to flattenaspect hierarchies to create the composed design model.

We find that security patterns can be well specified byusing RAM approach. RAM’s multi-view modelling abilitymake it possible to capture even complex semantics of se-curity patterns. The hierarchical modelling support of RAMenables a refinement process in which security patterns canbe refined from abstract level till detailed design level. Fig.1 shows a RAM model of a Session pattern which reusesthe generic RAM model of Map (or ZeroToManyAssociationalternatively) [6]. The RAM model of Map [6] is composedof a generic data container |Data using a “Map” structureto store data in pairs of |Key and |Value. Session reusesMap by composing parameterised elements of Map with modelelements of Session as can be seen in the “Map instantiation”box. For example, the mapping |Value to |Attribute meansthat attributes in a session are stored as |Value objectsmanaged by the Map structure. The |Attribute elementitself is a parameter. Any object can be stored in a session bymapping it to the |Attribute parameter. The RAM modelof Session itself has the customisation interface comprises theparameterised classes |Session, |SessionID, |Attribute,and |AttributeType. For example, |SessionID is a param-eterised class which will be instantiated as a unique identityassociated with a session.

C. Motivational Examples

This section first recalls the case study of designing anddeveloping Crisis Management Systems (CMS) described in[7]. Next, CMS’s potential misuse cases related to multiplesecurity concerns are described. Then, we show why dealingwith multiple security concerns systematically is very hard,even by leveraging security patterns in existing catalogs.

Briefly mentioning, in CMS a crisis can be created, pro-cessed by executing the rescue missions defined by a superobserver, and then assigning internal and/or external resources.Fig. 2 shows a partial design of CMS, for creating a res-cue mission. CMS are also security-critical systems whosedifferent users must be authenticated, authorised to executedifferent tasks, sensitive data being communicated via different

247

networks must be protected, and responsibility of users mustbe clearly traced. In [7], only a simple use case for CMSuser authentication is provided. We show different securitythreats/misuse cases of CMS (informally, not exhaustively dueto space restrictions) as follows.

Misuse cases related to user accounts, access control:[MUC-A1] An attacker impersonates a CMSEmployee afterobtaining the user password by guess and try; [MUC-A2]A colleague of an authenticated user misuses the system onthe authenticated user’s working device while it is being leftunattended and accessible; [MUC-A3] A CMSEmployee gainsdisallowed access to the protected resources. CMSEmployeesmust only have access rights according to their assigned roles;[MUC-A4] A CMSEmployee has access rights to the systemas a FirstAidWorker but also a SuperObserver. Conflict-of-interest roles, e.g. FirstAidWorker and SuperObserver, cannotbe assigned to the same user.

Misuse cases related to accountability data: [MUC-B1] ACMSEmployee has received mission information concerninga car crash but ignores or overlooks some crucial informa-tion, and does not accept the mission. The rescue missionfails. When confronted, the CMSEmployee denies having re-ceived the mission information. [MUC-B2] A SuperObserverwrongly created a rescue mission which led to its failure. TheSuperObserver manages to delete the corresponding log entryof his wrong action, and denies it.

Misuse cases related to transmitted data: [MUC-C1] Anattacker intercepts usernames and passwords barely trans-mitted from client to server to impersonate a valid CM-SEmployee; [MUC-C2] An attacker intercepts the missioninformation about a crisis barely transmitted from the systemto CMSEmployee. Similarly, an attacker may intercept victim’sidentity and/or medical history information transmitted fromthe HospitalResourceSystem to the CMS and/or from the CMSto a FirstAidWorker. Advanced attacker even could modify thetransmitted victim’s medical history information.

For most security experts, not saying security novices,finding the best possible solutions addressing multiple se-curity concerns, e.g. described in the misuse cases, andintegrating them properly into the CMS would be a verybig challenge. Developing and integrating different securitysolutions addressing multiple security concerns into a systemis hard, making them work together consistently is harder.Leveraging security patterns seems to be a good approachfor practitioners because security patterns are fairly welldocumented to address different security concerns. Moreover,some security patterns also contain some informal inter-patternrelations, and constraints regarding other quality propertiessuch as performance to guide the patterns selection process.For tackling [MUC-A1], one may decide to use the patternsin [12], [2], e.g. to ensure the complexity of user passwords,make password reset frequently, combine user passwords withone-time-password (OTP). [MUC-A2] and [MUC-A3] can bemitigated by using the patterns of access control in [2, 12, 14].For tackling [MUC-B1] and [MUC-B2], the Audit Intercepterand/or Secure Logger patterns [14], or the Security Logger and

Auditor pattern [2] can be used. For tackling [MUC-C1] and[MUC-C2], one may decide to use the Secure Channel patternor Secure Pipe pattern [14], or the TLS pattern in [3].

But there is still a big gap between the intention andpractical application of security patterns. Security patterns areoften too abstract with good intention but no clear semanticsthat make them difficult to be implemented and applied,especially together. One can see that in the existing catalogsof security patterns, e.g. [2, 12, 14], the interrelations amongpatterns and other constraints are only briefly mentioned butnot concretely specified to be applicable. All of these couldlead to inappropriate implementation and application of secu-rity patterns. For example, a not well-thought design decisioncould lead to a weak user passwords authentication solutionthat allows a FirstAidWorker to guess and successfully imper-sonate a SuperObserver. Improperly integrating authentication,user session, and authorisation solutions could lead to accessrights misused, and sensitive data leaked. Even worse, wronglyimplementing an encryption channel for data transmission andalso an auditing mechanism that intercepts and records thetransmitted data may result in encrypted log entries that areuseless for auditing purposes. Similarly, constructing a loggingsolution for accountability must be aware of an existingauthorisation solution in the same system to produce the logscorrectly. Depending on how these two work together, the logsmight contain nothing, or meaningless info, or different typesof info about successful executions of method calls, or failedauthentication/authorisation checks for the method calls, orsometimes also successful authentication/authorisation checks.A sound approach for systematically addressing multiple se-curity concerns in secure systems development is needed, buthas not existed yet at least in the MDS research area.

III. OurModel-Driven Security Approach based on SoSPaA. Overview of Our Approach

Our MDS approach is based on a System of Securitydesign Patterns (SoSPa). Fig. 3 displays our meta-model ofSoSPa (SoSPa-MM) that is an extension of RAM meta-model [6]. The core elements of SoSPa-MM are depictedin white. The rest are core elements of RAM meta-model.SoSPa aims at systematically addressing the globally acceptedsecurity concerns such as confidentiality, integrity, availability,accountability. Thus, SoSPa is composed of an extensibleset of security solution blocks, e.g. authentication, authori-sation, cryptography. Each security solution block consists ofinterrelated security design patterns. To support the selectionof security design patterns, we use feature modelling as insoftware product line engineering to capture the variabilityand interrelations of security patterns. Specified by a featuremodel (FM), each security solution block can be used toform a specific, customised security solution. Each securitydesign pattern in SoSPa contains all well-structured elementssuch as context, problem, consequences as can be seen inwell-documented security patterns of existing catalogs. Morethan that, inter-pattern relations are captured and explicitlyspecified at the conceptual level as well as model level by

248

Fig. 3. The Meta-model of the System of Security design Patterns (SoSPa-MM)

RAM models. Fig. 3 shows that each SecurityDesignPattern isassociated with ReusableAspect(s) that realised the pattern. Inother words, security design patterns are specified as reusableaspect models (RAM) to form a coherent system of them,i.e. SoSPa. The interrelations among security patterns arecategorised into five types as specified in RelationshipType.We capture the core relation types among security patterns,i.e. depends on, benefits from, alternative to, impairs, conflictswith. These relations can be transitive and/or symmetrical.

Five main security solution blocks of SoSPa are Authentica-tion, Authorisation, Cryptography, Auditing, and Monitoringas can be seen in Fig. 4. Derived from security require-ments, a customised security solution can be built up froma combination (OR relation) of these security solution blocks.Each feature (node) of the FM can be associated directlywith a RAM model. For example, Authentication feature isdirectly specified by a RAM model named Authentication.The features with underlined names are security patternswhich can be refined by composing the hierarchical RAMmodels realising them. For example, Security Session pattern isrealised by the RAM model SecuritySession, and also the otherrelevant RAM models like SessionManager, Session. Somelow-level features are not really security patterns but genericRAM models which help building security patterns, e.g. Map,ZeroToManyAssociation. Because in SoSPa, security patternsare built on hierarchical RAM models (see Section IV), theinterrelations among security patterns are actually specifiedat the model/design level. In other words, the interrelationsare specified based on the relations of RAM models that thesecurity patterns are built on. We elaborate more on this inSection III-C.

B. Pattern-Driven Secure Systems Development Process

This section presents the development process in three mainstages, especially emphasising the selection and compositionof security design patterns into a target system design.

[Security threats identification& analysis]: This is not thefocus of this paper. We assume that misuse cases are created inthis stage. Attack models might be created from risk analyses,e.g. using the CORAS framework as discussed in [3].

[Security design patterns selection and application]Step 1 - Constructing security solutions from the securitypatterns in SoSPa: For each security concern, the interrela-tions specified in the feature model (Fig. 4) are used to selectthe most appropriate security design patterns, i.e., the patternthat best matches with the context and the security problem,most satisfies the interrelations with the other already selectedsecurity design patterns, and maximises the positive impact onrelevant quality properties like usability, performance. All theRAM models of the selected security design patterns and otherrequired RAM models are woven into the RAM model of thetop most feature in the hierarchy corresponding to the securityconcern of the FM. This step derives a detailed RAM designof a customised security solution for the concern, including itscustomisation interface and usage interface. For example, toconstruct a customised authentication solution, all the selectedfeatures under Authentication feature are woven into it. Theoutput of this step is a complete RAM model, i.e. the wovenRAM model of the authentication solution. This woven RAMmodel of the authentication solution later can be integratedinto a base system model via its customisation interface. Moredetails can be find in the case study described in Section V.Step 2 - Defining mappings to integrate the newly builtsecurity solutions to a base system model: For each se-lected security pattern, use the customisation interface of thegenerated design to map the generic design elements to theapplication-specific context. This step generates the mappingsof the parameterised elements in the security design patternwith the target elements in the target system design. Anyconstraints/conflicts between mappings of all the selectedsecurity design patterns need to be resolved. Most constraintsare predefined by SoSPa for the obvious interrelations (e.g. L1

249

System of Security design Patterns

PasswordComplexity

Authentication

Authentication Means

HardwareToken

PasswordReset

DirectAuthentication

Third Party Authentication

SecuritySession

Biometrics

Password

SessionTimeout

SessionManager

SessionSecureSessionObject

ZeroToMany Map

optionalrequiredalternative (XOR)

or (OR)

Interceptor

TransferObject

AuthorisationEnforcer

PolicyRepository

PolicyBasedAccessControl

Authorisation Cryptography Auditing Monitoring

AccessControlList

ControlledAccessSessionRBAC

SecuritySession

LogManager

SecureLogStore

AuditInterceptorSecureLogger

LogFactory

SecureDataLogger

Load Balancer

LimitedAttempts

JAAS

SecurePipeSecureStore

UIDGenerator

Cipher

MessageDigestSignature

L1

L2

Traceable

Fig. 4. A Partial Feature Model of SoSPa

and L2 discussed in the case study). Some ad-hoc constraintsmight need to be provided by the designer in some rare caseswhen the RAM weaver gives warning about potential conflictswhile weaving RAM models [6].Step 3 - Weaving the security solutions into the base systemmodel: All the security solutions are automatically woven intothe target system design. The mappings from previous step arethe input for this weaving process.

[Verification&validation of security patterns application]:Analyse the woven secure system against the attack modelsobtained before. The attack models can be used for formalverification of security properties in the woven model, or canbe used for test cases generation like in a security testingapproach. This is part of future work.

C. The Interrelations of Security Patterns in SoSPa

This section shows how five interrelations among securitypatterns at conceptual level can be realised at detailed design(model) level in SoSPa.

1) Depend-on Relation: Security pattern X depends onsecurity pattern Y means that X will not function correctlywithout Y. This relation is not symmetrical, but transitive. InSoSPa, this relation is specified as the mandatory “required”relation among RAM models that realise the security patterns.Let security pattern X be realised by RAM model A; letsecurity pattern Y be realised by RAM model B. X dependson Y means that model A (directly or indirectly) depends on(requires) model B. Thus, model A realising security patternX can only be applicable to any base system if all the RAMmodels that A depends on, such as model B, have been woveninto A. In Fig. 4, the patterns of Authorisation and Auditingdepends on the patterns of Authentication. That means securitysolution of Authorisation must be completed by a securitysolution of Authentication.

2) Benefit-from Relation: Security pattern X benefits fromsecurity pattern Y means that implementing Y will add to thevalue already provided by implementing X. At design level,X benefits from Y if RAM model A realising X optionallydepends on RAM model B realising Y. For example, Authen-tication patterns can benefit from SecuritySession pattern. But

it is up to designers to decide if the chosen Authenticationpattern needs to use SecuritySession.

3) Alternative-to Relation: Security pattern X is alternativeto security pattern Y means that X provides a similar securitysolution like Y’s. The designer can choose either X or Y foraddressing the same security problem. For instance, DirectAu-thentication pattern is alternative to ThirdPartyAuthentication.

4) Impair-with Relation: Security pattern X impairs withsecurity pattern Y means that X and Y are not recommendedtogether. In case X and Y are both selected for working to-gether, they may result in inconsistencies. A conflict resolutioncould be provided to make them working consistently together.For example, Load Balancer pattern impairs with SecuritySession pattern. If no conflict resolution can be found, wesay that X conflicts with Y.

5) Conflict-with Relation: Security pattern X conflicts withsecurity pattern Y means that implementing Y in a systemthat contains X will result in inconsistencies. An exampleis that the Audit Interceptor pattern could conflict with theSecureChannel pattern.

IV. Security Design Patterns in SoSPa

Due to space restrictions, this section only presents somekey security design patterns of SoSPa. We show how hierar-chical RAM models are used to specify security patterns fromabstract level till detailed design level. Besides, each securitypattern is presented with its interrelations to the others.

A. Authentication Patterns

The Authentication feature is specified by a RAM modelwith the most basic authentication logic (Fig. 5). For ev-ery call to any protected method |m of any protected class|ProtectedClass, the caller must be already authenticatedbefore method |m is executed. The underlying authenticationmechanisms are abstract and to be refined by composingthe model elements |Authentication, |authenticate, and|check with the parameterised elements of the selected RAMmodels, e.g. SecuritySession, DirectAuthentication that Au-thentication depends on. The FM shows that designer couldchoose different alternatives below the Authentication feature

250

aspect Authentication depends on (optional LimitedAttempts, optional SecuritySession), (DirectAuthentication xor JAASAuthentication xor ThirdPartyAuthentication)

structural view

|ProtectedClass

+ boolean authenticate()- boolean check()+ boolean isAuthenticated()

 Authentication

c: Caller

authenticate()

message view authenticate Pointcut Advice

target: |Authentication

c: Callerauthenticate()

target: Authentication

SecuritySession instantiation|CheckPoint → Authentication

Op: |login → authenticateOp: |check → check

Op: |isLoggedIn → isAuthenticated

DirectAuthentication instantiation|DirectAuthentication → Authentication

Op: |login → authenticateOp: |check → check

ThirdPartyAuthentication instantiation|Authenticator → Authentication

Op: |login → authenticateOp: |check → check

Binding c → *

Caller → *

*check()

+ * |m(…) |ProtectedClass

message view method |m with authentication required

c: Caller

|m()

target: |ProtectedClass

Pointcut

Advice

alt [r ≠ false] *throw new NotAuthenticatedException()

c: Caller|m()

target: |ProtectedClass

s: Authenticationr := isAuthenticated()

LimitedAttempts instantiation|LimitedAttempts → Authentication

Op: |m → authenticateOp: |check → check

*

|m

Fig. 5. Aspect Authentication

aspect DirectAuthentication depends on Map, Passwordstructural view

+ boolean |login()- |check()- Credential getCredential(Principal id)+ void addCredential(Principal id, Credential cre)

 |DirectAuthentication

Pointcut

s: |DirectAuthentication

Advicemessage view |login s: |DirectAuthentication

message view getCredential is Map.getValue

message view addCredential is Map.add

vc: Credential

vc := getCredential(p)

r := validate(cre)

+ boolean validate(Credential c) 

Credential

Principal

Map instantiation|Data → |DirectAuthenticationOp: getValue → getCredential

Op: add → addCredential|Key → Principal

|Value → Credential

+ Principal getInputPrincipal()+ Credential getInputCredential()

 RequestContext

rc : RequestContext

p := getInputPrincipal()

cre := getInputCredential()

Password instantiationPasswordManager → |DirectAuthentication

Password → CredentialUserID → Principal

Op: comparePassword → validate

c: Caller|login()

c: Caller |login()

Binding c → *

Caller → *

*

|check()

|check()*

r

|DirectAuthentication

|login|check

* *

Fig. 6. Aspect DirectAuthentication

for designing a customised authentication solution, e.g. Direc-tAuthentication, ThirdPartyAuthentication∗1, or JAASAuthenti-cation∗ [14].

Fig. 6 shows the RAM model of DirectAuthenticationpattern which is based on the Authentication Enforcer patternin [14] and the Authenticator pattern in [2]. RequestContextcontains the user’s principal and credential extracted fromthe protocol-specific request mechanism. An instance of Re-questContext is often provided by a specific implementationframework. We do not discuss this RequestContext class indetails. By using the input Principal, the DirectAuthenticationretrieves the corresponding Credential from an identity storethat it manages using a Map aspect. The input Credentialis checked against the retrieved Credential. Using DirectAu-thentication requires designer to decide on what kinds ofshared secrets to be used for authentication. The abstractaspect AuthenticationMeans shows that share secrets couldbe user password, biometrics, or one time password (OTP).These features could be used together, e.g. user password with

1Due to space restrictions, patterns marked with a star ∗ are not presented.

OTP. If using user password for authentication, the Password∗

pattern will be woven into the DirectAuthentication aspect.Third-party authentication provider (ThirdPartyAuthentica-

tion∗) can also be used to validate client’s credentials. Themain idea of this pattern is to map the authentication processto a proxy to call the authentication method provided bya third-party authentication provider. Shared secrets amongthe third-party provider and their clients are invisible to theauthentication solution being constructed.

On the other hand, session can bring more benefits to anauthentication solution, e.g. for maintaining an authenticatedstatus. We describe security session patterns in the next sec-tion. The SecuritySession pattern is optional to Authentication.

Note that the order of dependencies specified on the topof each RAM model is important to make the patterns workconsistently together. For example, the order of weavingdependencies into Authentication must be from left-to-right,and then top-down, i.e. LimitedAttempts, SecuritySession,DirectAuthentication. The orders of weaving are also partof SoSPa to provide for designers. The RAM weaver canexecute the orders of weaving dependencies automatically. Weelaborate more on this in the case study given in Section V.

B. Security Session Patterns

The FM in Fig. 4 also shows how the aspects relatedto security session are organised. The patterns for secu-rity session are based on the Security Session pattern in[12], the Controlled Access Session pattern in [2], and theAuthentication Enforcer, Secure Session Object patterns in[14]. In SoSPa, the SecuritySession pattern depends on theSessionManager∗ aspect for managing sessions. The designercan choose between a generic Session pattern showed in Fig.1 or the SecureSessionObject∗ pattern [14]. SecuritySessionpresented in Fig. 7 specifies how a SecuritySession object iscreated and used for maintaining the authenticated status of asubject. Logically, if the validation process in authenticationreturned by the |check method is successful, a new sessionobject is created. Then, any security-related information canbe stored in this object, e.g. the validated Principal. Theauthenticated status is associated with the session as long asthe session is active. The SessionTimeout∗ pattern providesa timing mechanism that requests authenticating again if thecorresponding session is expired.

C. Authorisation Patterns

Fig. 8 shows the corresponding Authorisation RAM model.Authorisation can be employed together with Authenticationif the optional AuthenticationDependence aspect is selected(see Fig. 4). AuthenticationDependence presented in Fig. 9shows that authentication must be done before the method|m called. The Authorisation RAM model itself containsthe Authorisation class with evaluateReq function toevaluate any request AccessRequest to method |m of aprotected resource |ProtectedClass. The AccessRequestis created with all necessary elements of a method call such

251

aspect SecuritySession depends on (optional SessionTimeOut), SessionManagerstructural view

|CheckPoint|Principal

|Credential

message view login

SessionManager instantiation|SessionManger → |SessionManger

|Session → |SecuritySession

cp: |CheckPoint

Pointcut Advice

SecuritySession+ login()- boolean check()+ boolean isLoggedIn(SessionID sid)+ logoff()

|CheckPoint|Principal

|Credential

SessionID + SessionID getSessionId()

RequestContext

c: Caller

login()opt [ses=null]

opt [r = true]

cp: |CheckPoint

m: SessionManager

ses := createSession()ses: SecuritySession

add(…)

rc: RequestContext

sid := getSessionId()ses := lookupSession(sid)

c: Callerlogin()

return sessionID ≠ null

r

*

check()

r := check()Binding

caller → *Caller → *

SessionManager

message views isLoggedIn, logoff is not presented here

Fig. 7. Aspect SecuritySession

structural view

aspect Authorisation depends on Traceable, AuthorisationEnforcer, (optional AuthenticationDependence)

|ProtectedClass

+ boolean evaluateReq(Subject sbj, AccessRequest request) 

Authorisationstructural view

AccessRequest

message view protected method |m depends on AuthorisationEnforcer.|requestAccess

Pointcut

caller: Caller t: |ProtectedClass

|m(…)

Binding caller → * Caller → *

Advice

alt [r=TRUE]

caller: Caller

t: |ProtectedClass

a: Authorisation

else

AuthorisationEnforcer instantiation

|AuthorisationEnforcer → Authorisation

Op: |requestAccess → evaluateReq

rc: RequestContext

subj:= getSubject()

Subject

+ * |m(…)+ AccessRequest createRequest(Method)

 |ProtectedClass

+ Subject getSubject()

RequestContext

AuthenticationDependence instantiation|ProtectedClass → |ProtectedClass

Op: |m → |m

throw new NotAuthorisedException()

*

|m

Traceable instantiation|Traceable → |ProtectedClass

Op: |m → |mOp: createTrace → createRequest

|Trace → AccessRequest

req := createRequest(|m)

r := evaluateReq(subj, req)

|m(…)

Fig. 8. Aspect Authorisation

structural view

aspect AuthenticationDependence depends on Authentication |ProtectedClassstructural view

message view protected method |mPointcut

caller: Caller t: |ProtectedClass

|m(…)Binding

caller → * Caller → *

Advice

caller: Caller

t: |ProtectedClass

+ * |m(…) |ProtectedClass

Authentication instantiation|ProtectedClass → |ProtectedClass

Op: |m → |mAuthentication → AuthenticationOp: authenticate → authenticate

Op: isAuthenticated → isAuthenticated

a: Authenticationauthenticate()

+ authenticate()+ boolean isAuthenticated()

Authentication

|m

|m(…)

r := isAuthenticated()

Fig. 9. Aspect AuthenticationDependence (renamed to L1 in Fig. 4)

as Method, AccessKind. Fig. 8 shows that the generic Trace-able∗ aspect of RAM [6] is reused in Authorisation to createan AccessRequest. The Subject requesting access is alsoobtained from the RequestContext. The Subject and theAccessRequest objects are used for the access decision pro-cess managed by the Authorisation. If the request is granted,the protected method |m will be executed. Otherwise, anauthorisation exception will be returned. The requestAccessmethod is refined further by the AuthorisationEnforcer pattern.

The AuthorisationEnforcer pattern in Fig. 10 contains the

structural view

aspect AuthorisationEnforcer depends on (PolicyBasedAC xor ControlledAccessSession) |AuthorisationEnforcer

+ boolean |requestAccess(Subject sbj, AccessRequest request) 

|AuthorisationEnforcer Subjectstructural view

message view |requestAccess is skipped for space reasons

+ boolean decideAccess(Subject sbj, AccessRequest request)- boolean combineDecisions(PermissionsCollection rights)

 AuthorisationProvider

PermissionsCollection+ PermissionCollection getPermissions(…)

PermissionsManager AccessRequest

PolicyBasedAC instantiation|PEP → |AuthorisationEnforcer|PDP → AuthorisationProvider

|PolicyRepository → PermissionsManagerOp: |lookup → getPermissons

|requestAccess

Fig. 10. Aspect AuthorisationEnforcer

AuthorizationEnforcer class that processes any request accessbased on other RAM models such as PolicyBasedAC∗, Con-trolledAccessSession∗.

D. Auditing (Accountability)

In critical systems, the ability to keeping tracks of who didwhat and when is very important. Security patterns for auditingcan solve this accountability concern. The RAM models forauditing and their interrelations specified in Fig. 4 are basedon the Secure Logger, Audit Interceptor patterns [14], andthe Security Logger and Auditor pattern [2]. Two commonpatterns for auditing are SecureLogger and AuditInterceptor∗

in which the latter depends on the former. Fig. 11 showsthe structural view and message view of the SecureLoggerpattern. The classes and methods being traced are mappedto the parameterised Traced class and method |m. Once theTrace object and the identity of caller are created, they aresent to the SecureLogger for being logged. How a Traceobject can be created is specified by the generic Traceable∗

aspect mentioned before. The LogManager is responsible forthe actual serialisation of the log (using LogFactory∗ aspect)to a secure storage (either using SecureLogStore∗ pattern orSecureDataLogger∗ pattern [14]).

SecureLogger in Fig. 11 is a generic logger that just simplylogs a trace whenever the method |m is called. There isno specification on whether |m has been successfully au-thenticated and/or authorised, or actually executed. Differentvariations of when and how a trace is logged are providedin different logging strategy aspects. For example, aspectAuthorisationDependence in Fig. 12 specifies that a traceis logged only if the caller to |m has been authorisedsuccessfully and |m has been executed.

To summarise, we have presented some key security patternsof SoSPa and their dependencies to each others, and to otherRAM models. Note that the order of dependencies on topof each RAM model matters to the order of weaving. Howdependencies are woven into a RAM model are specified byinstantiation mappings.

V. Evaluation and Discussion

A. Case Study and Results

By using SoSPa with the patterns selection and applicationprocess described in Section III-B, multiple security concern-s/misuse cases of CMS can be addressed/mitigated properly.We demonstrate the three main steps of the patterns selectionand application process as follows.

252

structural view

aspect SecureLogger depends on Traceable, LogManager, (optional AuthorisationDependence, …)|Traced

+ void log(Subject id, Trace action)- LogMessage process(LogEntry aLog)

 SecureLogger

structural view

+ void log(LogMessage msg)

LogManager

message view |m affected by |Traceable.createTrace, |LogManager.|log

Pointcut

caller: Caller target: |Traced

|m(…) Binding caller → * Caller → *

Advice

caller: |Caller

logger: SecureLogger

log(id, trace)

target: |Traced

rc: RequestContext

id:= getSubject()

aLog: LogEntry

create()

set(…)

Traceable instantiation|Traceable → |Traced

Op: |m → |m

+ * |m<AccessKind>(…)- logTrace()

|Traced

Subject

+ set(…)

- Subject id- Trace action- DateTime time

LogEntryLogMessage

|m(…)

trace := createTrace(|m)

msg := process(aLog)

logMan: LogManager

log(msg)

LogManager instantiation|LogManager → LogManager

|SecureLogger → SecureLoggerOp: |log → log

+ Subject getSubject()

RequestContext

|m

logTrace()

AutthorisationDependence instantiation|ProtectedClass → |Traced

Op: |m → |mOp: |logTrace → logTrace

*

Fig. 11. Aspect SecureLogger

structural view

aspect AuthorisationDependence depends on Authorisation |ProtectedClassstructural view

message view |m affected by Authorisation.evaluateReq Pointcut

caller: Caller target: |Traced|m(…)

Binding caller → * Caller → *

Advice

opt [r=TRUE]

caller: |Callertarget: |Traced

+ * |m(…)- |logTrace()

|ProtectedClass

|m(…)

|m|logTrace

Authorisation instantiationAuthorisation → Authorisation

Op: evaluateReq → isAuthorised|ProtectedClass → |ProtectedClass

Op: |m → |m

a: |Authorisation

r := isAuthorised()

*

+ boolean isAuthorised(…) 

Authorisation

|logTrace()*

*

|logTrace()

Fig. 12. Aspect AuthorisationDependence (renamed to L2 in Fig. 4)

Step 1 - Constructing security solutions for CMS from thesecurity patterns in SoSPa: First, authenticating CMS usersis the most fundamental security requirement of CMS as de-scribed in [7]. Fig. 4 shows that after selecting the Authentica-tion feature, the designer can choose to employ DirectAuthenti-cation or JAASAuthentication. ThirdPartyAuthentication is nota solution because CMS must use its own identity store forauthenticating CMS users. Besides, LimitedAttempts∗, whichspecifies that an authentication request is blocked after someconsecutive unsuccessful authentication attempts, could bealready selected to partially mitigate [MUC-A1]. Assuming thedesigner selected DirectAuthentication, now he selects Pass-word because using user password is a concrete requirementof CMS. Moreover, a strong user password solution must beemployed to better mitigate [MUC-A1]. PasswordComplexity∗,PasswordReset∗ can be used together with Password pattern.One of the best solutions to mitigate [MUC-A1] is to usePassword in combination with HardwareToken∗ (OTP). Tomitigate [MUC-A2], SecuritySession and also SessionTimeout∗

need to be employed in the authentication solution. WhenSecuritySession is selected, it means all the aspects that itdepends on, e.g. mandatory SessionManager, are also selectedand composed into it. Due to space reasons, we do not discuss

about the features below SecuritySession. This hierarchicalaspects composition is applied to every feature in the featuremodel. Thus, all the selected features below Authenticationare automatically woven into it, according to the order ofdependencies specified on top of Authentication, and the modelelements mappings defined in the corresponding RAM models.For example, once LimitedAttempts is selected, it is woveninto Authentication first. In this way, a concrete authenticationsolution, namely wovenAuthentication RAM model has beenbuilt and ready to be integrated into CMS base design to fulfilits user authentication requirements and mitigate its potentialmisuse cases.

Similarly, a concrete authorisation solution can be builtto mitigate the misuse cases [MUC-A3] and [MUC-A4].Assuming AuthorisatonEnforcer with PolicyBasedAccessCon-trol∗ and Role-Based Access Control (RBAC)∗ have beenselected. All the selected RAM models for the authorisationsolution such as AuthorisatonEnforcer, PolicyBasedAccess-Control∗ are woven into the Authorisation RAM model tocreate a wovenAuthorisation RAM model.

And so on, misuse cases [MUC-B1] can be mitigated byconstructing a suitable Auditing solution, e.g. using SecureL-ogger. [MUC-B2] is also mitigated by using SecureLoggerbecause either SecureLogStore∗ or SecureDataLogger∗ is em-ployed to protect the logged data from being tampered. Allthe selected RAM models for SecureLogger are woven intothe SecureLogger RAM model, resulting in a wovenAuditingRAM model.

To mitigate misuse cases [MUC-C1] and [MUC-C2], Se-cureChannel pattern [14], or TLS pattern as presented by [3],can be employed to secure transmitted data. We do not discussmore details about this due to space restrictions.

Step 2 - Mapping the security solutions to the CMS basedesign: For each security solution built in the previous step,its parameterised model elements can be mapped to the targetelements in the CMS design to integrate the security solutioninto CMS. Note that the customisation interface of thetop-most RAM model (e.g. Authentication) in the hierarchyof a security solution is also the customisation interface ofthat security solution (wovenAuthentication). Let us make thecreateMission function of CMS secure and its executionlogged. We would come up with the following mappings:wovenAuthentication.|ProtectedClass→CrisisManager

wovenAuthentication.|m→createMission

wovenAuthorisation.|ProtectedClass→CrisisManager

wovenAuthorisation.|m→createMission

wovenAuditing.|Traced→CrisisManager

wovenAuditing.|m→createMission

As we see, the constraints among the mappingshave to be resolved. From the security requirementsof CMS, the authorisation solution has to work withthe existing (already built) authentication solution. Thus,the AuthenticationDependence feature (or L1 in Fig. 4)must also be selected for the authorisation solutionwovenAuthorisation. That means wovenAuthenticationis woven into AuthenticationDependence, and their woven

253

alt [r=TRUE]

create(Crisis, EmergencyLevel, MissionDetails)

 Mission

boolean isAvailable()available: boolean

CMSEmployee

createMission(SuperObserver, MissionKind, EmergencyLevel, MissionDetails)+ AccessRequest createRequest(Method)+ Trace createTrace(Method)

 CrisisManager

addMission(Mission) 

Crisis

Crisis getCrisis() SuperObserver

10..*

0..* 0..1observedCrisis

c: Caller

createMission()

: CrisisManager

su: SuperObserver

m: Mission

currentCrisis := getCrisis()

create(currentCrisis, level, details)

+ boolean authenticate()+ boolean isAuthenticated()

 Authentication

logger: SecureLogger

log(id, trace)

id:= getSubject()

trace := createTrace(createMission)

logTrace()rc: RequestContext

*The remaining of wovenAuditing with SecureLogger pattern, etc.

*

The remaining of the createMission function

a: Authorisation

else

rc: RequestContext

subj:= getSubject()

throw new NotAuthorisedException()

req := createRequest(|m)r := evaluateReq(subj, req)

alt [r ≠ false]

throw new NotAuthenticatedException()

s: Authentication

r := isAuthenticated()

authenticate()

* The remaining of the wovenAuthentication design

*The remaining of the

wovenAuthorisation design

else

+ boolean evaluateReq(Subject sbj, AccessRequest request) 

Authorisation

AccessRequest

+ boolean decideAccess(Subject sbj, AccessRequest request)- boolean combineDecisions(PermissionsCollection rights)

 AuthorisationProvider

+ void log(Subject id, Trace action)- LogMessage process(LogEntry aLog)

 SecureLogger

+ void log(LogMessage msg)

LogManager

wovenAuditing

wovenAuthorisation

wovenAuthentication

createM

ission

Fig. 13. Automatically Woven Secure CMS Model

RAM model is then woven into wovenAuthorisation tocreate a wovenAuthenticationAuthorisation. By do-ing so, the constraints among wovenAuthentication andwovenAuthorisation have been resolved. Similarly, to loga wrongly created rescue mission action of a SuperObserverin CMS as described in [MUC-B2], the AuthorisationDepen-dence feature (or L2 in Fig. 4) is needed for wovenAuditing.By weaving wovenAuthenticationAuthorisation withAuthorisationDependence and then into wovenAuditing tocreate a wovenAllSolutions model, all the constraints havebeen resolved. After that, the instantiation directives for inte-grating all the security solutions into the CMS base design arestraight forward:wovenAllSolutions.|Traced → CrisisManager

wovenAllSolutions.|m → createMission

Step 3 - Weaving the security solutions into the CMS basedesign: This step can be automatically done by the RAMweaver once all the mappings and constraints have beenspecified in the previous step. Fig. 13 shows final wovenmodel. For space reasons, we only display the key partsof the customised authentication, authorisation, and auditingsolutions woven into the base model. The woven model showsthat the createMission action now can only be executed byan authenticated user that is authorised to execute this task,and a trace of this action is securely logged. Of course, aformal analysis of the woven model against attack modelscould show a formal proof that the woven model is resilientto different attacks. Constructing attack models in a similarway as security solution models and then employing formalanalysis techniques could be a good direction for future work.

B. Discussion

Our work raises an important question related to the abstrac-tion level proposed by SoSPa. More specifically, the question

is how can we guarantee that the level of details is sufficient?Or how to guarantee that there is no need to develop newRAM models or security patterns? Our answer is that therequired level of details strongly depends on the expecteduse of SoSPa. Obviously, if SoSPa was used to generatecode that can run, the low-level details of a design wouldhave to be provided. If the goal was to generate the codeskeleton of a secure system and test cases, the low-level detailscould be omitted. The level of details of RAM models inSoSPa is not enough for full code generation, but enough forspecifying all the important semantics of security patterns andtheir interrelations. That means the code skeleton of a securesystem can be generated that preserves the important semanticsof the employed security patterns and their interrelations.

Each security design pattern can also be associated withthe side effects of its adoption on other quality properties, e.g.performance, usability. An impact model of the security designpatterns for each quality property can be built as discussedin [1]. Impact models are useful for analysis of the trade-off

among alternatives which leads to a thoughtful decision onsystematically selecting the right security design patterns forthe job. On the other hand, attack models can also be specifiedusing SoSPa-MM. These attack models are associated to thesecurity concerns, and can be woven into the system modelto generate misuse models for formal analysis of security, orgenerate test cases for testing. In this paper, we only focus onthe interrelations among security patterns, not yet consideringthe relations to other quality properties and attack models. Thetypes of interrelations in this paper are aligned with the fivetypes of inter-pattern relations presented in [16].

A second question is related to the completeness and exten-sibility of SoSPa. As previously discussed, the set of securitypatterns mentioned in this paper is not complete, mainlydue to space constraints. We have nonetheless considered themost illustrative for the purpose of our work. However, aninteresting feature of SoSPa is that it is fully extensible. Asa result, if a user realises that some details or some securitypatterns are missing, he can extend it. This is eased by the useof RAM and the explicitness of the relationships among thesecurity patterns.

In a final note, we recall that to the best of our knowledge,SoSPa is the first attempt to provide an extensive set of con-crete design models of security patterns that can be integratedsystematically. We provide RAM models that users can exploreaccording to several dimensions: not only from high to lowlevel of details, but also in the variability perspective traversinga large number of possible security solutions.

VI. RelatedWork

Different MDS approaches can be found in [11]. Thissection briefly presents the closest related work only. Aspect-oriented modelling: Georg et al. [3] propose a methodologythat allows not only security mechanisms but also attacks tobe modelled as aspect models. The attacks models can becomposed with the primary model of the application to obtainthe misuse model. The authors then use the Alloy Analyser

254

to reason about the misuse model and the security-treatedmodel. Mouheb et al. [9] develop a UML profile that allowsspecifying security mechanisms as aspect models. The aspectmodels often go together with their integration specification tobe woven automatically into UML design models. Recently,Horcas et al. [5] propose a hybrid AOSD and MDE approachfor automatically weaving a customised security model intothe base application model. By using the Common VariabilityLanguage (CVL) and atl, different security concerns canbe woven into the base application in an aspect-orientedway, according to weaving patterns. However, dependenciesbetween the security aspects and their application orders havenot been taken into account. In general, all these approacheshave not considered security aspects as a coherent systemcapturing their interrelations and constraints. Patterns-based:Three main catalogs of security patterns are presented in [2,12, 14]. These catalogs only contain abstract security pat-terns without any refinement process towards their applicationand any MDS framework. Shiroma et al. [13] propose anapproach to leverage model transformations for specifyingand implementing application procedures of security patterns,including inter-pattern dependencies. The inter-pattern depen-dencies here mean the order of consecutive applications ofsecurity patterns by performing consecutive transformations.In fact, the approach only presents the dependencies in termsof the order of application of security patterns. There are manyother important interrelations that one must consider such asconflicts, benefits, and alternatives among security patterns.Their approach is only able to deal with 8 per 27 securitypatterns in [12] because the other 19 patterns do not havestructures described. With our extensive, extensible SoSPa, allkey interrelations among security patterns are considered, notonly the order of patterns application.

Our MDS approach based on SoSPa initially explored inthe position paper [10] is inspired by [1]. Alam et al. [1]propose an approach based on RAM for designing softwarewith concern as the main unit of reuse. They show how theirideas can be realised by using an example of low-level designconcern, i.e. the Association concern. The adoption of theirapproach to high-level concerns like security has not beendealt with yet. In this paper, we realised the ideas in [10]by developing a system of RAM models specifying multiplesecurity patterns and their interrelations to form SoSPa. Weextend the concept of using variation interface in [1] forspecifying the interrelations among security patterns. WithSoSPa, abstract security patterns can be specified, refined asdetailed designs with concrete semantics. Additionally, theinterrelations among patterns can be concretely specified inthe variation interfaces and in the detailed designs, thanks toRAM. We also plan to extend the idea of using impact modelin [1] for specifying the constraints of security patterns withother quality properties like performance, usability.

VII. Conclusions and FutureWork

This paper has presented an MDS approach based on aSystem of Security design Patterns (SoSPa) to systematically

guide and automate the application of multiple security pat-terns in secure systems development. Our SoSPa is specifiedby using an extended meta-model of RAM, namely SoSPa-MM. Based on SoSPa-MM, security patterns are collected,specified as reusable aspect models to form a coherent systemof them. Our MDS framework allows systematically selectingsecurity design patterns, constructing security solutions, andautomatically composing them with a target system design. Weevaluated our approach by leveraging the System of Securitydesign Patterns to design the security of crisis managementsystems. The result shows that multiple security concernsof the case study have been addressed. More importantly,the different security solutions are thoughtfully selected andsystematically integrated. Our work on SoSPa opens threepoints for future work: 1) extending the impact models in [1]for specifying the side-effects of security patterns regardingother quality properties like performance, usability; 2) incorpo-rating the attack models to generate misuse models for formalanalysis of security [3]; 3) using test templates embedded intothe security patterns for testing their application [8].

Acknowledgments

Supported by the Fonds National de la Recherche (FNR),Luxembourg, under the MITER project C10/IS/783852.

References[1] O. Alam, J. Kienzle, and G. Mussbacher. “Concern-Oriented Software

Design”. In: Model-Driven Engineering Languages and Systems. 2013.[2] E. Fernandez-Buglioni. Security Patterns in Practice: Designing Se-

cure Architectures Using Software Patterns. John Wiley & Sons, 2013.[3] G. Georg et al. “An Aspect-Oriented Methodology for Designing

Secure Applications”. In: Information and Software Technology (2009).[4] T. Heyman et al. “An Analysis of the Security Patterns Landscape”.

In: Software Engineering for Secure Systems (SESS). 2007.[5] J.-M. Horcas, M. Pinto, and L. Fuentes. “An Aspect-Oriented Model

Transformation to Weave Security using CVL”. In: MODELSWARD.IEEE. 2014, pp. 138–150.

[6] J. Kienzle et al. “Aspect-Oriented Design with Reusable AspectModels”. In: TAOSD VII. Springer, 2010, pp. 272–320.

[7] J. Kienzle, N. Guelfi, and S. Mustafiz. “Crisis Management Systems:A Case Study for Aspect-Oriented Modeling”. In: Transactions onaspect-oriented software development (TAOSD) VII. 2010, pp. 1–22.

[8] T. Kobashi et al. “Validating Security Design Patterns ApplicationUsing Model Testing”. In: Availability, Reliability and Security (ARES),2013 Eighth International Conference on. IEEE. 2013, pp. 62–71.

[9] D. Mouheb et al. “Aspect-Oriented Modeling for Representing andIntegrating Security Concerns in UML”. In: Software EngineeringResearch, Management and Applications 2010. Springer Berlin Hei-delberg, 2010, pp. 197–213.

[10] P. H. Nguyen, J. Klein, and Y. Le Traon. “Model-Driven Securitywith A System of Aspect-Oriented Security Design Patterns”. In:VAO@STAF. VAO ’14. ACM, 2014, 51:51–51:54.

[11] P. H. Nguyen et al. “A Systematic Review of Model Driven Security”.In: The 20th Asia-Pacific Software Engineering Conference. 2013.

[12] M. Schumacher et al. Security Patterns: Integrating security andsystems engineering. John Wiley & Sons, 2013.

[13] Y. Shiroma et al. “Model-Driven Security Patterns Application Basedon Dependences among Patterns”. In: Availability, Reliability, andSecurity (ARES). 2010, pp. 555–559.

[14] C. Steel and R. Nagappan. Core Security Patterns: Best Practices andStrategies for J2EE, Web Services, and Identity Management. 2006.

[15] K. Yskout, R. Scandariato, and W. Joosen. “Do Security PatternsReally help Designers?” In: Software Engineering (ICSE), 2015 37thInternational Conference on. IEEE. 2015.

[16] K. Yskout et al. A system of security patterns. Technical report, KULeuven. 2006.

255