1 / 21

On Comparing the Expressing Power of Access Control Model Frameworks

Workshop on Logical Foundations of an Adaptive Security Infrastructure (WOLFASI) A sub-workshop of the LICS Foundations of Computer Security (FCS'04) Workshop, LICS '04. On Comparing the Expressing Power of Access Control Model Frameworks. July 12-13, 2004 Turku, Finland.

kurt
Download Presentation

On Comparing the Expressing Power of Access Control Model Frameworks

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Workshop on Logical Foundations of an Adaptive Security Infrastructure (WOLFASI) A sub-workshop of the LICS Foundations of Computer Security (FCS'04) Workshop, LICS '04 On Comparing the Expressing Power of Access Control Model Frameworks July 12-13, 2004 Turku, Finland Barbara Catania DISI Università degli Studi di Genova catania@disi.unige.it Elisa Bertino Purdue University bertino@cerias.purdue.edu Elena Ferrari DSCFM Università degli Studi dell’Insubria Elena.Ferrari@uninsubria.it Paolo Perlasca DICO Università degli Studi di Milano perlasca@dico.unimi.it

  2. Summary • ASI and policy framework • Frameworks comparison • Conclusions and future work

  3. ASI • Adaptive Security Infrastructure (ASI) • Collect information about security environments • Analyze the collected data • Perform efficient compensating actions according to security relevant detected events • ASI strictly depends on the underlying security policy

  4. Security Policy Issues • How formally representing the semantics of security policies ? • In distributed environments • Compensating actions • can involve different environments and • must agree with the respective underlying security policies

  5. Framework • Strategy: framework for representation, analysis, and usage of security policies • Useful in • Performing security analysis • Identifying strategies • Producing compensating actions • Representing in a uniform way the heterogeneity of the access control policies and formalisms • We focus on one of the most relevant classes of security policies: access control policies

  6. Access Control (AC) Policies • An access control policy determines the operations and rights that subjects can exercise on the protected objects • Access control policies can be specified through authorization rules • Rules able to establish for each subject s which actions such subject can perform on which object of the system

  7. Access Control Policy Access Control Policy Data1 Data2 Answer General Access Control System ACP ACP Access Request

  8. Which AC framework ? • A variety of access control frameworks have been so far defined • Each framework provides a formalism for specifying access control policies and a semantics for computing authorizations • Different frameworks support the representation of different sets of policies • No comparison of the expressive power of the proposed frameworks has been investigated

  9. LAMP • LAMP is based on the C-Datalog language • C-Datalog supports: • classical object-oriented concepts, such as classes, objects and inheritance (used to represent subjects, objects, privileges, sessions,…) • typical logic-based concepts, such as deductive rules (used to represent authorization and constraint rules) • Each instance of an ACM is a logical program composed of C-Datalog rules defined against a C-Datalog schema

  10. LAMP • An Access Control Model Schema (ACMS) defines the structural components upon which the model is based • Access Control Model Instance (ACMI) provides information concerning the component instances, that is, the “actual” subjects, objects, privileges and sessions, and the authorizations and constraint rules used to instantiate the model

  11. ACMI • DC • DSC • AC • PC • CC Domain Component InSubG(G1:X,G2:Y) ¬ SubG(G1:X,G2:Y) InSubG(G1:X,G2:Y) ¬ SubG(G1:X,G2:Z) , InSubG(G1:Z,G2:Y) Domain Structure Component g1 Authorization Component g2 g3 SubG(G1:g5,G2:g4) InSubG(G1: g4,G2: g1) ß InSubG(G1: g5,G2: g1) Propagation Component g4 Constraint Component g5 Object(self:#8,name:Salaries,access_class:Secret) ACMS object(self:object,name:string,access_class:string) group(self:group,name:string) SubG(G1:group,G2:group) Object(self:<value>,name:<value>,access_class:<value>)

  12. Jajodia et al. • Jajodia et al. framework represents access control models by stratified logic programs constructed over a given logical language • The basic elements used to represent an ACM are: • OTH, UGH, RH, A, Rel • Authorizations (o,s,<sign> a)

  13. Jajodia et al. • An AS is a set of stratified rules satisfying some syntactic restrictions • Authorizations are specified through predicates: • cando(o,s,<sign>a) • dercando(o,s,<sign>a) • do(o,s,<sign>a)

  14. RBAC • NIST RBAC is defined by four levels of increasing complexity • Roles are powerful and easy to use • SSD and DSD constraints • Policy free

  15. RBAC COMPONENT User-role Assignments O R1 U R2 R3 Permission-role Assignments P R4 Constraints (SSD, DSD)

  16. Result • All the ACMs that can be represented by the Jajodia et al. framework can be represented by the Lamp framework • All the ACMs that can be represented by the four NIST levels can be represented by the Lamp framework

  17. ACMS ACM • ACMI • DC • DSC • AC • PC • CC Auth Base Auth Base

  18. Result • The set of the ACMs that can be represented by LAMP is greater than the one representable by the Jajodia et al. framework • Locally stratified logic programs generates a unique set of authorizations vs more general formalism supporting the generation of more than one set of consistent authorizations

  19. Result • The set of the ACMs that can be represented by LAMP is greater than the one representable by the NIST framework • SSD and DSD constraints vs broader set of constraints (conditioned separation of duty depending on specific values of basic elements)

  20. Conclusions • Given a distributed system based on ASI our analysis will help in the selection of a specific ac framework for such environment

  21. Future work • Definition of new dimensions and comparison according to them • Mapping complexity • Spatial complexity • Temporal complexity • Development of a set of tools for specifying and analyzing ac policies using LAMP as a core system

More Related