An approach based on Model-driven Engineering to

An approach based on Model-driven Engineering to define Security Policies using the access control model OrBAC Denisse Muñante

Laurent Gallon

Philippe Aniorté

LIUPPA LIUPPA LIUPPA University of Pau, France University of Pau, France University of Pau, France Email:[email protected] Email:[email protected] Email:[email protected]

Abstract—In the field of access control, many security breaches occur because of a lack of early means to evaluate if access control policies are adequate to satisfy privileges requested by subjects which try to perform actions on objects. This paper proposes an approach based on UMLsec, to tackle this problem. We propose to extend UMLsec, and to add OrBAC elements. In particular, we add the notions of context, inheritance and separation. We also propose a methodology for assessing the security policy modeled, based on the use of MotOrBAC. Keywords: assessment of access control policies, model-driven security, OrBAC, UMLsec

I. I NTRODUCTION Many security breaches occur in softwares because errors and misspecifications in analysis, design and implementation can bring vulnerabilities to the system. Attackers most often exploit vulnerabilities to compromise the system [16]. Millions of dollars in losses are the result of attacks on unsecured systems, which are easily exploitable by attackers. Despite the effort made to obtain secured systems, there is still a lack of means to detect defects (errors and misspecifications) early, in order to mitigate or avoid future considerable problems. Moreover, in the conception and elicitation stages, we can determine functional and non-functional requirements of the system. The first one is what the system should do, and the latter specifies under what constraints the system must satisfy, such as security, performance, re-usability, etc. These non-functional aspects can be early considered through the use of models based on the model-driven engineering (MDE) approach. The main advantage of this methodology is that we can take into account non-functional (security) aspects as soon as possible in the design of the system, in order to ensure (security) properties from the beginning of the system development. In this paper we focus on modelling access control mechanisms in an MDE approach. In a previous work [11], we made a first proposition in which we use a simple acces control

model. In this paper, we make a more complete proposition, using a more complex access control model, based on OrBAC. The main difficulty in this approach is the ability to model security (i.e. access control) concepts and mechanisms. We also need to evaluate if security properties are enforced or not by the model of the system, even (maybe primarily) at an abstract level of modelization. The Unified Modeling Language UML [24] is a language widely used in models, and so in MDE approaches. Several propositions have already been made to introduce access control principles in UML. The most relevant proposals are UMLsec [3], SecureUML [4] and the unified access control modeling language [5] (UACML). The two first mentioned modeling languages help designers to formalize access control requirements, by basing on RBAC access control model [15] principles, while UACML allows designers to combine several access control models (RBAC, TBAC, TMAC, . . . ) to formalize access control requirements. Notice that the main advantage of UMLsec with regards to SecureUML and UACML is that it proposes a simulation process to evaluate if the security policy modelled is enforced. The main advantage of SecureUML and UACML with regards to UMLsec is that they represent structurally the elements involved in an access control and include constraint notion in order to add conditions of activation of security rules. As these security languages are based on the RBAC model, they can not tackle the complete variety of issues involved in the field of access control, such as the use of contexts, inheritance, negative rules, mechanisms to avoid conflicts, and others. Despite the fact that UACML uses categories to represent several kinds of access control models, it cannot include all these mentioned issues. All these issues are taken into account in the Organization Based Access Control (OrBAC) model [2]. In this paper, our main contribution is the addition of OrBAC elements to UMLsec in order to allow security designers to define more expressive access control policies. Hence, the basis of our approach is the UMLsec proposal and several elements, inspired by SecureUML and UACML works, were also included into UMLsec. We also propose a methodology to explain how to use

this approach. This methodology is shown in figure 1. It is represented as a set of stages that security designers have to follow to take advantage of our proposition.

Fig. 1. Methodology of our proposition

More precisely, four different stagesare defines : (1) Design a system: designers will use an UML modeling tool to design the system. (2) Add an OrBAC security policy: For this stage, designers have to import our UML profile, and then, they can embed OrBAC security policies into the model of the system defined in the previous stage. Notice that, at this stage, the designer must have a good knowledge of OrBAC model and its principles, in order to correctly build the security policy in its system model. These two fisrt stages constitute the definition and modelization step of our approach. Next stages deal with the assessemnt of the security policy, based on the existing tool MotOrBAC [14]. (3) Generate the security policy for MotOrBAC: designers will use our prototype (explained above) to generate a security policy understood by MotOrBAC from the security policy defined in the previous stage. (4) Analyze and manage the generated security policy: designers will use MotOrBAC tool to evaluate, analyze and manage security policies generated in the previous stage. The remainder of this paper is organised as follows. Section 2 introduces OrBAC model. Section 3 introduces UMLsec and how it tackles the field of access control. Section 4 describes the extension of UMLsec to include OrBAC’s elements. An example of our proposition is detailed in Section 5. An implementation and an assessment mechanism are presented in section 6. Finally, Section 7 concludes this paper and gives future works.

II. T HE O RGANIZATION -BASED ACCESS C ONTROL (O R BAC) Security models [1], i.e. access control and flux control, are created to enforce (implement) confidentiality, integrity and non-repudiation of the information. Several access control models were proposed in the past (IBAC, RBAC, TBAC, VBAC, TMAC), but OrBAC is the most “expressive” one. The central entity in OrBAC [2] is the Organization, which can be seen as an organized group of subjects, playing some roles. In OrBAC, subject, action and object, which correspond to concrete entities, are respectively abstracted into role, activity and view, which correspond to abstract entities. A role is a set of subjects that carry out the same functions. Similarly, an activity regroups actions that partake of the same principles, and a view corresponds to a set of objects that satisfy a common property. A security policy is defined for and by an organization. This policy is a set of rules (permissions, prohibitions, obligations or dispensations). The rules only apply in a specific context. A context is a special condition between user, object and action that control activation of rules expressed in the access control policy. More precisely, five main types of context have been defined: temporal, spatial, user-declared, prerequisite and provisional. The reader will find more details on the definition of these contexts in [6]. One of the main advantages of OrBAC is that it can automatically derive concrete rules from abstract rules. For example, suppose that the organization hospital defines, in its security policy, the following abstract rule: “the role physician is allowed to perform the activity consult on the view medical record at context working-hours”. Suppose now that the subject John plays the role physician, the action select implements the activity consult, the object patient medicalRecord.doc is used in the view medical record, and the current context is working-hours for the hospital. Then the concrete rule which can be derived from the previous abstract rule is: John is allowed to select patient medicalRecord.doc file. OrBAC also supplies the inheritance concept [7] which provides a very efficient mean to structure the security policy specification, and the delegation concept [9] which is the process whereby users without any administrative prerogatives obtains the ability to grant some of their own authorizations. More details on OrBAC principles can be found in references given in this paper, and by consulting the web site [23]. As we mentioned in the introduction, we propose an approach based on MDE which includes OrBAC elements, in order to allow security designers to define more expressive access control policies. We base our proposition on UMLsec, which was build on RBAC principles. In the rest of this paper, we explain how to extend UMLsec in order to add OrBAC’s elements. III. UML SEC AND ACCESS CONTROL POLICY UMLSec [3] presents a methodology to specify requirements regarding confidentiality and integrity in models based on UML. This approach considers an UML extension which

Fig. 2. Example of access control policy using UMLsec

allows an application developer to embed security-related functionalities into the system design. Then, a security analysis can be performed on the model of the system to verify if some particular security requirements are enforced. In the field of access control, UMLsec is based on rolebased on access control (RBAC) principles. It implements the stereotype associated with tags protected, role and right for enforcing RBAC rules. Figure 2 shows an excerpt from the example proposed in [17] for the definition of the access control policy using UMLsec. This example corresponds to an order management online system. The activity diagram uses the stereotype rbac for the definition of the security policy. As we can note, the activity transfer money is defined as “protected resource” (row 2 of the table), the role accounting manager grants “rights” to this activity (row 3), and the actor Anton plays the “role” accounting manager (row 5); hence, the actor Anton is granted rights to the action transfer money. On the other hand, UMLsec uses a simulation process at the design stage to evaluate if each actor has the required rights to perform secured actions. Returning to the previous example, the UMLsec assessment will not encounter any problems when evaluating the rights of actor Anton on the activity transfer money. But if another actor Michael wants to gain the same privileges, UMLsec will warn of an absence of rights on this action, because Michael does not play the role accounting manager (row 4). This simulation process is the main advantage of UMLsec. But the disadvantage of this mechanism is its restriction to deal with the variety of issues involved in the field of access control, such as the use of contexts, hierarchies and others. In this paper, we propose to add OrBAC mechanisms to UMLsec, in order to be able to use (but not only) contexts and hierarchies. This addition is explained in next sections. IV. E XTENSION OF THE UML SEC PROFILE FOR INCLUDING O R BAC In this paper we propose an extension which adds OrBAC concepts to UMLsec metamodel. Approaches described in [5], [12], [13] propose modeling languages, which could take

advantage of OrBAC, but none of them have accomplished to integrate OrBAC completely. Regarding the evaluation process, [10] approach gives a processing model describing how to evaluate authorization requests according to the rules of access control policies defined in XACML 1 in an implementation level. Our proposal focuses on the assessment of access control policies as soon as possible, i.e. at an abstract level of modelization. So,we do not have to wait until the implementation stage in order to obtain a first assessment of the security policy. Although our work is based on UMLsec, we have used other modeling languages to enrich our idea. Specifically, we inspired from SecureUML [4] and the unified access control modeling language [5] (UACML). These two proposals give us means to represent structurally the elements involved in an access control definition. We also use the definition of dynamic properties and restrictions through a class named Authorization Constraint, to allow for example an operation only during weekdays. Of course, this kind of property can only be evaluated at a concrete level (because it depends on the state of the system, as the date for example). In the next section, we will focus on the UML design diagrams –use case, class and sequence diagrams– in which we propose to include OrBAC elements. Fisrt, we explain how to add OrBAC entities in UML diagrams. Then, we give some clues on the addition of OrBAC security predicates. Finaly, we discuss about some other additional OrBAC mechanisms. A. OrBAC entities The main entity of OrBAC is the organization. Moreover, OrBAC allows the policy designer to define a security policy independently of the implementation: the abstract level consists of roles, activities and views and the concrete level consists of subjects, actions and objects. We propose to include OrBAC entities as follows. The notion of Organization is added in Use Case Diagrams. Abstract and concrete entities are added in Class Diagrams. Finally, relevant entities are given in Sequence Diagrams. We will now detailled these different elements in next sections. 1) Use Case Diagrams: In use case diagrams, we can cluster use cases according to their goals. For example, in a medical system, a hospital offers different services such as patient consultation, surgical treatment, pharmaceutical service, administrative service or others. Each service has its own goal which is achieved by a particular staff, resources and activities. We argue that a set of use cases which can be grouped according to their goals corresponds to the notion of organization for OrBAC. For example, surgical treatment will be defined as an organization in OrBAC. Therefore, we create the stereotype to represent this notion in UMLsec. This 1 XACML defines a declarative access control policy language implemented in XML

stereotype is an extension of the package element of UML as we can see in figure 3 . 2) Class Diagrams: In class diagrams, we can use UML classes to represent roles and views. We can also use UML operations of a view class to represent activities. As done in SecureUML for actions, in our approach, these activity operations must be defined through a class with the stereotype activityClass, to be able to add information (attributes) and to take advantage of UML classes properties. All these elements correspond to the “abstract entities” of OrBAC. As example, in the previously mentioned medical system, we can define a role class physician, a view class medical record. Activities (operations) of the class medical record could be consult, add, create. Moreover, thanks to the concept of abstraction of UML, we can naturally use UML instance specifications to represent subjects, actions and objects as the “concrete entities” of OrBAC. In our example, using abstract classes physician and medical record, we can instantiate the concrete entities of the system. For example, John could be an instance of the role physician and JohnMedRecord.doc could be an instance of the view medical record. The principle of the definition of abstract and concrete entities is depicted in figure 4. 3) Sequence Diagrams: A saquence diagram describesthe interactions between classes to implement a use case. Notice that if a sequence diagram is associated with a use case, and the use case is also a part of an organization, then the sequence diagram is a part of the organization. Therefore, all elements of the sequence diagram (lifelines and messages) will be a part of the mentioned organization; moreover, these elements are active representations of elements (classes and operations of UML) of class diagrams, where we have defined the abstract entities. In other words, the roles, views and activities of a class diagram are represented by elements of a sequence diagram belonging to the organization. Hence, we can conclude that these elements of the sequence diagram correspond to the

Fig. 4. Class diagram for a general system

Fig. 5. Sequence diagram for a general system

“relevant entities” defined by OrBAC through its predicates. In figure 5, we can see the use of these relevant entities through a general system. Notice that, in OrBAC, the notion of relevant entity is defined through the use of relevant entity predicates. In our approaches, we define these relevant entitites as stereotypes. More details are given in section B.1: Relevant entity prediactes. B. OrBAC predicates In order to understand OrBAC rules, we have to explain OrBAC predicates. Predicates are inspired by propositional logic. A predicate is seen as a property that a subject has or is characterized by. Hence, it is an expression that can be true or false. OrBAC uses predicates to evaluate the properties of its entities. In next sections, we explain how to include these prediactes in UMLSec. 1) Relevant entity predicates In OrBAC, these predicates are used to indicate if an abstract entity (role, view, activity) is a relevant element for an organization. As explained before, we create three stereotypes , >, >, which have the domain {organization * abstract entity} of OrBAC as we can see in figure 6. These stereotypes will be used in sequence diagrams.

Fig. 3. Use case for a general system

class diagrams can have a set of UML properties (attributes). We propose to use these attributes to define the application dependent or declared context. Then, we add the stereotype context into class diagrams, i.e. we create contexts which can be used by none or several organizations. We add the tag {hold} for our stereotype to indicate a set of contexts used by the organization. Figure 8 shows the relationship between the mentioned entities for our proposition. Fig. 6. Relevant entity predicates

2) Abstraction predicates In OrBAC, these predicates (empower, use, consider) are used to assign a concrete entity to an abstract entity within an organization. In UMLsec, the tag {role} of the stereotype is used to assign users (subjects) to roles. We use the same idea for our stereotype , and so, we add the tag {empower} to assign subjects to roles, the tag {consider} to assign actions to activities, and the tag {use} to assign objects to views. Each tag has the structure {concrete entity, relevant abstract entity} according to the OrBAC domain {organization * concrete entity * abstract entity} as we can see in figure 7. 3) Context predicate In OrBAC, the predicate Hold is used to indicate that a context is defined for a subject, an action and an object within an organization. In SecureUML and UACML, contexts are implemented by the authorization constraint class. We use the same idea for our metamodel, and we add the stereotype derived from UML constraints. As we mentioned, in OrBAC, a context is defined for concrete entities within an organization. For us, contexts can be expressed only at the abstract level. The abstract entities in

Fig. 7. Abstraction predicates

Fig. 8. Context predicate

In order to define the temporal and spatial contexts, OrBAC uses a global clock and an architecture of hardware and software of systems. As we mentioned, we use UML constraints to represent contexts. UML constraints use Object Constraint Language (OCL). OCL is a declarative language to describe rules that apply to UML models. Hence, we propose to use OCL to declare temporal and spatial contexts literally; for example, we will define “h > 9 & h < 18” to indicate a working-hours context. OCL is able to express not only temporal and spatial contexts but also user-declared and composed contexts. The provisional and prerequisite contexts are not considered in this paper because they need extra elements for their definition, as it is more complex to model, they could be part of a future work. 4) Abstract privilege predicates In OrBAC, these predicates define the abstract rules of the security policy of an organization. In UMLsec, the tag {right} of the stereotype is used to define the rights of roles on secured resources. We use the same idea for our stereotype , and so, we add the tag {permission} (resp. {prohibition} and {obligation}) to define the permission (resp. prohibition and obligation) of a role to perform an activity on a view. {permission} and {prohibition} tags have the structure {relevant role, relevant activity, relevant view, context} according to the OrBAC domain {organization * role * activity * view * context}. Moreover, {obligation} tag has the structure {relevant role, relevant activity, relevant view, context, violationContext} according to the OrBAC domain {organization * role * activity * view * context *

violationContext}. We did not define the dispensation rule because we did not have the case and means to test it. Notice that its addition to our proposition seems to be quite easy, because we only have to add a tag dispensation to the stereotype with the same structure of {permission} or {prohibition} tags. Of course, this assumption must be verified. These predicates are depicted in figure 9. Notice, as we indicated, the {obligation} predicate adds the {violationCtx} element which is not included for the others predicates.

Fig. 11. Use case diagram for a medical system

TABLE I S ECURITY POLICY FOR THE ORGANIZATION patient consultation Tag empower empower empower use consider permission

Fig. 9. Abstract privilege predicates

Finally, we summerize all the prediactes added in our approach in figure 10, unless the context predicate to avoid to complicate this scheme. C. OrBAC additional mechanisms OrBAC offers the mechanisms of delegation and inheritance to make the definition of security policies easier. The delegation mechanism is beyond the scope of this paper because this mechanism is closer to an administrative work, and it is

Fig. 10. OrBAC predicats

Tagged Value (John , physician) (Marie , assistant) (Peter , assistant) (row23444DB , appointment) (selectDBAppointment , consultApp) (assistant , consultApp , appointment, workingHoursnotHolidays)

difficult to model at an abstract model. In contrast, we add the stereotype derived from UML generalization associations to define the inheritance of roles, activities and views (it is similar to the inheritance of UML classes), while the inheritance of organizations is realised through the tag {nameOrg} for our stereotype . This tag is used to indicate generic organizations. On the one hand, the inheritance of roles is similar to the hierarchical level of an enterprise or an organization, i.e. a specialized role inherits all permissions of its generic role, but not its prohibitions. For instance, if the role manager specializes the role consultant, then the manager will inherit all permissions of the consultant, but not its prohibitions. On the other hand, the inheritance of views, organizations and activities are similar to the hierarchy of classes, i.e. a specialized view (resp. organization and activity) inherits all permissions and prohibitions of its generic view. For instance, if the view medical record specializes the view record, then the medical record inherits all permissions and prohibitions of the record. The introduction of negative rules can generate conflicts in the security policy. A conflict occurs when a subject is allowed and prohibited to perform the same action on the same object at the same time. OrBAC uses two mechanisms to avoid conflicts. The first one is the separation of entities [8]. The second one is the rule priorities [8]. In our proposal, we add the stereotype derived from UML associations to avoid the case of a subject which plays two roles (res. views and activities), which could originate conflicts (for example the roles clerk and manager). Rule priorities are not described in this paper. We are currently studying this mechanism.

V. A N EXAMPLE THAT ILLUSTRATES OUR PROPOSITION In this section, we detailled the example presented in section IV. This medical system offers the service of patient consultation, in order to assure medical care for patients of a hospital. Figure 11 shows the corresponding use case diagram with its main functionalities and actors involved. In this figure, we have added one package with the stereotype , which corresponds to the service mentioned. This organization is named patient consultation. Two use cases are defines: caring for a patient and booking an appointment. These two use cases involve three roles: Physician, Patient and Assistant. Each organization package has the tags {empower}, {consider}, {use}, {hold}, {permission}, {prohibition} and {obligation} which are used to define the security policy. Table I define the security policy in our example, by giving a set of {tag, tagged value} entries. For example, the tagged value (John, physician) of the tag {empower} means that John plays the role physician (row 1). The tagged value (assistant, consultApp, appointment, workingHours-notHolidays) of the tag {permission} means that the role assistant is allowed to perform the activity consultApp on the view appointment at workingHours-notHolidays context (row 6). Figure 12 (a) shows a class diagram whose classes are extracted from the previous use case diagram. In this diagram, we identify the abstract entities of the whole system: physician, surgeon and assistant as role entities; MedicalRecord and appointment as view entities. Remember that only classes with the stereotype can have operations with the stereotype (ConsultApp() in Appointment view for example). Each activity is associated with a class belonging from the stereotype ActivityClass, in order to define the attributes, inheritance, . . . of this activity (the class has the same name than the corresponding activity). For example, class ConsultApp define two attributes of the corresponding activity ConsultApp(): nameRepository and typeRepository. For clarity reason, we don’t show all these classes in figure 12 (a). In the classical definition of UMLsec, it is impossible to use views and activities to abstract objects and actions. Moreover, the use of roles by UMLsec is only through the tag {rol}. We think that it is not sufficient, since roles, views and activities can have particular attributes, which are important to define contexts. For example, in Fig. 12 (a) the context notHolidays means that the assistant should not be on holidays. For instance, we consider that Marie is on holidays, while Peter is not. We also define the context workingHours which means that the workingHours are from 9:00 a.m. to 6:00 p.m on a week day. In brief, we use classes and operations to define abstract entities, their instances to define concrete entities and constrains to define contexts. As mentioned, the inheritance and separation between abstract entities are possible in our approach. This makes the definition of security policies easier and avoids conflicts. For example, in Fig. 12 (a) the role surgeon inherits the role

genPhysician, i.e. a surgeon will inherit all permissions of a general physician, but not its prohibitions. Moreover, the role surgeon is separated from the role assistant, i.e. a subject is not allowed to perform the roles surgeon and assistant in a same time. These mechanisms are not considered in the classical definition of UMLsec. Finally, figure 12 (b) shows a sequence diagram corresponding to the use case Caring for a patient. As we mentioned, in this diagram we identify the relevant entities. For example, the lifeline assistant is a relevant role, the lifeline appointment is a relevant view, and the messages of appointment, such as consultApp, are relevant activities in the organization patient consultation. VI. I MPLEMENTATION AND ASSESSMENT MECHANISM In previous sections, we conceptually introduced a metamodel as an extension of UMLsec in order to add security policies based on OrBAC into system’s models. In this section, we give an explanation about the implementation of this metamodel and the development of an assessment mechanism to evaluate the security policy. On the one hand, our metamodel was implemented on the Eclipse platform. We used Topcased [22] to build an UML profile which defines all elements of our metamodel. Despite the fact that this profile was built on Topcased, designers can use any other modeling tool to define their system. They just need to import our OrBAC profile in their tool to embed a security policy based on OrBAC. On the other hand, we know that it is important to give an assessment mechanism to guarantee security policies are wellformed, to analyse potential conflicts between their rules, and to allow designers to simulate a real situation using concrete elements. These features are very important to evaluate if the model is correct or not from a security point of view. MotOrBAC [21] [14] is a very famous tool, already used in OrBAC assessment, which includes an editor, simulator and analyzer of OrBAC security policies. It provides the following features: (1) policy specification based on the OrBAC model, (2) potential and effective conflict detection, (3) policy simulation and (4) administration policy specification. As we can see, all the mechanisms needed in our appproach are aleready implemented in MotOrBAC. So, the main idea of our assessment mechanism is to derive from security policies defined on our metamodel (using the mentioned UML profile) the security policies structured for MotOrBAC tool. In the field of MDE, when we need to transform a model into another one, we clasically use a model to model transformation process (M2M) [20]. Moreover, ATL [19] is a model transformation language and toolkit of Eclipse. Our contribution is the development of a transformation process using ATL to derive security policies defined on our metamodel to obtain security policies based on an ontology (OrBAC’s vocabulary) understood by MotOrBAC. That is to say, this transformation process will produce a file defined on the OrBAC’s vocabulary which will be understood by MotOrBAC and, so we can take

Fig. 12. (a) Class diagram for a medical system. (b)Sequence diagram for the use case Caring for a patient

Fig. 13. Security policy derived automatically for MotOrBAC

advantage of its mentioned features. Then, MotOrBAC will be the testing tool for security policies defined on our metamodel. More precisely, our ATL transformation scripts (which we called MoDELO starts from the system model and the embedded OrBAC security policy. Then, the ATL transformations translate these source models into a Resource Description Framework (RDF) model 2 which is understood by MotOrBAC. Finally, this last model will be opened on MotOrBAC, as we show in figure 13, and then, we can test the security policy embedded using MotOrBAC. Notice, figure 13 shows the security policy derived from the medical system defined on An example that illustrates our proposition section. We build our prototype on the OpenEmbeDD [18] platform. OpenEmbeDD is an Eclipse-based Model Driven Engineering platform dedicated to Embedded and Real-Time systems (E/RT). In the OpenEmbeDD, we used the MDE tools chain described in figure 14.

Fig. 14. Tools used to implement our proposition

The tools used are: (1) Topcased generator , as explained before, to build the 2 RDF

is a formal model to describe meta data.

OrBAC profile and the model of the system (Topcased can be replaced by any other UML modeling tool) (2) the EMF (Ecore) standard for manipulation of metamodels. We used Ecore to define a metamodel with the OrBAC’s vocabulary. This metamodel is used by our prototype. (3) ATL transformation language for wrappers between metamodels, we used the ATL toolkit to build the transformation process which is part of our prototype (MoDELO). This transformation process produces an RDF document with an OrBAC security policy understood by MotOrBAC. VII. C ONCLUSIONS In this paper we propose an extension of UMLsec, which allows security designers to take advantage of OrBAC characteristics in the early stages of the lifecycle of software development. In particular, we introduce several new elements added to UMLsec metamodel: organization, abstract entities, abstract relevant entities, concrete entities, security rules, and inheritance and separation of abstract entities. The main benefits of this work are: • allowing to define objects, actions, views and activities not considered in UMLsec, • more precision of the abstract entities (roles, views and activities), thanks to the use of classes and their operations, • definition of contexts using attributes of the abstract entities, • the use of inheritance and separation to make easier the definition of security policies, • an assessment mechanism to allow to use MotOrBAC from our metamodel, and so to be able to assess the security policy. As perspectives, several points must be studied in future works :

•

• •

in the field of rule conflict avoidance, we need to implement rules priorities at the abstract level (i.e. in the model of the system). security rules must be completed by taking into account dispensiation rules finaly, some contexts are not implemented in our proposition, and me be studied shortly R EFERENCES

[1] L. Mé and Y. Deswarte: Sécurité des systèmes d’information, LAVOISIER, ISBNN 2-7462-1259-5, Paris, France, 2006. [2] A. Miége: Definition of a formal framework for specifying security policies. The Or-BAC model and extensions, PhD Thesis to Ecole Nationale Supérieure des Télécommunications, 2005 [3] J. Jurjens: UMLsec: extending UML for secure systems development. The Unified Modeling Language, Model Engineering, Languages Concepts and Tools, Fifth International Conference, 2002 [4] T. Lodderstedt and D. Basin and J. Doser: SecureUML: A UML-Based Modeling Language for Model-Driven Security. The Unified Modeling Language, Model Engineering, Languages Concepts and Tools, Fifth International Conference, 2002 [5] N. Slimani and H. Khambhammettu and K. Adi and L. Logrippo: UACML: Unified Access Control Modeling Language. NTMS, 4th IFIP International Conference, February 2011 [6] F. Cuppens and A. Miège: Modelling contexts in the Or-BAC model. 19th Annual Computer Security Applications Conference, December 2003 [7] F. Cuppens and N. Cuppens-Boulahia and A. Miège: Inheritance hierarchies in the Or-BAC model and application in a network environment. Second Foundations of Computer Security Workshop (FCS’04), 2004 [8] F. Cuppens and N. Cuppens-Boulahia and M. Ben Ghorbel: High level conflict management strategies in advanced access control models. Electronic Notes in Theoretical Computer Science (ENTCS), vol 186, pages 3-26, June 2007 [9] M. Ben Ghorbel and F. Cuppens and N. Cuppens-Boulahia and A. Bouhoula: Managing Delegation in Access Control Models. Managing Delegation in Access Control Models CoRR, 2010 [10] D. Abi Haidar and N. Cuppens-Boulahia and F. Cuppens and H. Debar: An Extended RBAC Profile of XACML. Proceedings of the 3rd ACM workshop on Secure web services (SWS’06), 2006 [11] D. Muñante and P. Aniorté: A Proposal for Handling Non-Functional Aspects with a Model-Driven Engineering Approach. Journal of School Mines of the University National of Colombia, DYNA , vol 79, nb 173-I, pages 43-52, 2012 [12] M. Graa and N. Cuppens-Boulahia and F. Autrel and H. Azkia and F. Cuppens and G. Coatrieux and A. Cavalli and A. Mammar: Using Requirements Engineering in an Automatic Security Policy Derivation Process. 4th SETOP International Workshop on Autonomous and Spontaneous Security, 2011 [13] T. Mouelhi and F. Fleurey and B. Baudry and Y. Le Traon: A ModelBased Framework for Security Policy Specification, Deployment and Testing. 10th MODELS International Conference on MDE Languages and Systems, 2008 [14] F. Autrel, F. Cuppens, N. Cuppens-Boulahia, C. Coma: MotOrBAC 2: a security policy tool. Third Joint Conference on Security in Networks Architectures and Security of Information Systems (SARSSI’08), 2008 [15] JR. Sandhu and EJ. Coyne and HJ. Feinstein and CE. Youman: RoleBased Access Control Models. IEEE Computer, vol 29, nb 2, pages 38-47, 1996 [16] R. Anderson: Security Engineering: a Guide to Building Dependable Distributed Systems. John Wiley and Sons, 2001 [17] J. Jurjens and Team of UMLsec: UML Analysis Tools. OMG, http://www-jj.cs.tu-dortmund.de/jj/umlsectool/index.html [18] OpenEmbeDD, http://openembedd.org [19] ATL: a model transformation technology, http://www.eclipse.org/atl/ [20] Model-to-model Transformation with ATL, http://www.eclipsecon.org/2008/ [21] MotORBAC, http://motorbac.sourceforge.net [22] Topcased, http://www.topcased.org/ [23] ORBAC, http://orbac.org [24] UML : the Unified Modeling Language, http://www.uml.org