2010 CRC PhD Student Conference




    Merging Verifiable and Evolving Access Control Properties
                         ...
2010 CRC PhD Student Conference




2.1    Extending the UMLsec specification of RBAC
   UMLsec includes a set of propertie...
2010 CRC PhD Student Conference




                          Figure 1: Merging access control properties


constraints an...
Upcoming SlideShare
Loading in …5
×

Montrieux

463 views
449 views

Published on

Published in: Business, Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
463
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Montrieux

  1. 1. 2010 CRC PhD Student Conference Merging Verifiable and Evolving Access Control Properties Lionel Montrieux L.M.C.Montrieux@open.ac.uk Supervisors Dr Charles B. Haley, C.B.Haley@open.ac.uk Dr Yijun Yu, Y.Yu@open.ac.uk Department Computing Status Full-time Probation viva not passed Starting date October 2009 1 Introduction Recent years have seen a strong advance in formal methods for security [J¨r05]. Many success u have been obtained: many security protocols have been proved to be flawed, and many others to be correct in a precise sense delimiting exactly their applicability. UMLsec is an extension of UML that allows developers to waive security aspects into a standard UML model. The UMLsec tool [J¨r04] allows them to check that their models satisfy the security u properties they want to enforce. Yet, the growing demand to evolve systems continuously raises new questions and new research opportunities. Not only is it necessary to make sure that a system meets security requirements, but it is also crucial to make sure that those requirements are still met by the system on each step of its constant evolution. Hence, it is necessary to develop processes and tools that help the developers ensuring lifelong compliance to security, privacy or dependability requirements. Specifically, access control plays an important role in protecting assets from unauthorised access. Several access control models, like Role-Based Access Control (RBAC) [SFK00] or Organization- Based Access Control (OrBAC) [ABB+ 03] have been defined to help administrators grant permis- sions to users in an easy and scalable way, while allowing permission changes to be easily made. With complex software, maintaining a sound access control infrastructure and ensuring properties like separation of duty can become a challenge. Processes and tools that can verify such properties against a given model as well as all of its evolutions are necessary to increase confidence in one’s access control infrastructure. 2 Verification of Access Control properties in UMLsec The verification process we propose is made of three different parts: first, we want to extend the existing RBAC specification in UMLsec to allow one to specify more complex access control properties. Then, we want to verify that a given model actually enforces the UMLsec access control specification. Finally, we generate code that conforms to the access control property that has previously been defined and verified. Page 55 of 125
  2. 2. 2010 CRC PhD Student Conference 2.1 Extending the UMLsec specification of RBAC UMLsec includes a set of properties to specify RBAC permissions, using the RBAC stereotype on an Activity diagram [J¨r05]. However, it supports only a limited subset of the RBAC standard. u We want to develop it to include other levels of RBAC standard compliance, as well as other similar access control models, like OrBAC. We also want to model authentication procedures using UMLsec, and to allow one to automatically integrate the UMLsec property into other diagrams, like class diagrams and sequence diagrams, once the initial property has been defined on one or several activity diagrams. Other approaches have been proposed to model RBAC permissions on UML models, like Se- cureUML [LBD02]. SecureUML differs from UMLsec as it focuses on RBAC only. The way RBAC properties are represented is also different: instead of using stereotypes and tagged values to an- notate the model, the SecureUML approach adds classes to a class diagram to describe users, roles and permissions, and uses OCL [OMG10] to describe additional constraints. access control directives, like EJB configuration files, can also be generated from a SecureUML model. 2.2 Verifying a UMLsec property Once the UMLsec property has been defined, we want to make sure that the model actually enforces it. Not only do we want to make sure that the model doesn’t allow a user to perform an operation s/he’s not authorised to perform, but we also want to make sure that rules like Separation of Duty are actually enforced. Verification of the enforcement of the access control definition by the model already exists for the current UMLsec RBAC property, but is limited to activity diagrams. With the extended access control model that we propose come new challenges to verify the suitability of the model. Not only will we have to verify new properties on the activity diagram, but we will also have to verify the other diagrams of the model that may contain access control rules: class diagrams, sequence diagrams, . . . Since the access control definition might be spread over several diagrams, we will also have to verify that it doesn’t contain any contradiction. 2.3 Code generation from a UMLsec specification Once access control permissions have been defined for a model using UMLsec, we want to generate code that actually enforces those. We compared two different code generation approaches from the existing RBAC UMLsec property. The first one produces Object-Oriented code, while the second one produces Aspect-Oriented code [IKL+ 97] to enforce the access control permissions, together with Object-Oriented code for the functional code. It seems that the second solution provides a better implementation, since the access control enforcement code is clearly separated from the functional code. It also makes further changes to the code easier to perform, and makes the traceability between the code and the UMLsec access control property easier to maintain. Moreover, the current implementation only generates code for the JAAS framework [jaa01]. We would like to offer the possibility to generate code for other frameworks as well. 3 Merging conflicting access control properties An interesting case of evolution of a software system is merging conflicting access control prop- erties. A example might be two companies merging, each running its own software with its own access control properties. Rationalising the new company’s information system will imply using only one system, with only one access control property. We want to propose a framework, based on UMLsec, to allow one to merge several access control properties on a given model. Conflicting definition of roles are likely to arise, as well as conflicting Page 56 of 125
  3. 3. 2010 CRC PhD Student Conference Figure 1: Merging access control properties constraints and assignations. We want to give developers the opportunity to identify possible conflicts. Assuming that we have two different access control properties defined using UMLsec on the same model. If we can verify that the model enforces both definitions individually, then we want to merge those two definitions, raise possible conflicts to the user, and, once those conflicts have been resolved, the resulting access control will also be enforced by the model. This process is described in figure 1. References [ABB+ 03] A. Abou El Kalam, R. El Baida, P. Balbiani, S. Benferhat, F. Cuppens, Y. Deswarte, A. Mi`ge, C. Saurel, and G. Trouessin. Organization Based Access Control, June 2003. e [IKL+ 97] John Irwin, Gregor Kiczales, John Lamping, Jean-Marc Loingtier, Chris Maeda, Anurag Mendhekar, and Cristina Videira Lopes. Aspect-oriented programming. pro- ceedings of the European Conference on Object-Oriented Programming (ECOOP), June 1997. [jaa01] Jaas tutorials, 2001. http://java.sun.com/j2se/1.5.0/docs/guide/security/jaas/ tutori- als/index.html (Last accessed September 2009). [J¨r04] u Jan J¨rjens. u Umlsec tool, 2004. Published at http://mcs.open.ac.uk/jj2924/umlsectool/index.html (Accessed Sept. 2008). [J¨r05] u Jan J¨rjens. Secure Systems Development with UML. Springer-Verlag, 2005. u [LBD02] Torsten Lodderstedt, David Basin, and J¨rgen Doser. Secureuml: A uml-based mod- u eling language for model-driven security, 2002. [OMG10] OMG. Object constraint language (ocl) 2.2, February 2010. http://www.omg.org/spec/OCL/2.2/ (last accessed May 2010). [SFK00] R. Sandhu, D. Ferraiolo, and R. Kuhn. The NIST model for role-based access control: towards a unified standard. In Proceedings of the fifth ACM workshop on Role-based access control, pages 47–63, 2000. Page 57 of 125

×