A Formal Model for Hierarchical Policy Contexts

1. A Formal Model for Hierarchical Policy Contexts Opera Group Meeting, May 11th, 2004

2. Talk Outline • Motivation and Background. • Role-Based Access Control. • RBAC Policy Representation. • Difficulties in large-scale policy administration. • Policy Contexts. • Where we were last year. • Overview of our hierachical context formal model. • Managing information flow. • OASIS RBAC policy components. • Access control to policies themselves. • Future Work. • Conclusion.

3. Background • Role-Based Access Control • Simplifies security management by introducing the role abstraction between principals and privileges. • Access control policy is authored via: • some static relations (simple). • rules which involve policy inferencing (more complex). • Large-scale policy administration • Real deployments of RBAC require large numbers of roles. • Role parameterisation can reduce explosive growth. • A student role parameterised by their ID, for example. • Not possible to perform centralised administration: • A commonly used example: UK National Health Service.

4. Policy Contexts • Policy Contexts were introduced last year at Policy. • Provide a labelling mechanism for RBAC components. • Operates in parallel with RBAC rule semantics. • Focuses on policy administration not system operation. • Our work used OASIS RBAC as its basis. • Open Architecture for Secure Interworking Services. • Rules, roles, and parameters are the main policy elements. • Contexts introduces Mandatory Access Control properties: • In particular information flow constraints. • We discussed how labelling also helps policy administration. • Extending our initial work: • We provide a formal model. • Define hierarchical context management.

5. Parallel context classification • Consider a parallel information flow example: • The left models the human hierarchy of an organisation. • The right models an aspect of implementation. • We wish to enforce both sets of constraints simultaneously. • We need some formal semantics to make sense of this.

6. Non-hierarchical Contexts • A non-hierarchical context is a finite set of labels. • Each label is a context element (CE). • We define an information flow relation: AAB • i.e. flow is permitted from context element A to element B. • Wildcard support is desirable for future-proofing: • Allow future rules to be included under existing restrictions. • Wildcards require scoping to avoid security problems. • We need to support parallel information flow specifications. • Grouping labels which themselves represent contexts provides a solution to the scoping problem. • Hence our introduction of hierarchical contexts.

7. Hierarchical Contexts (2) • Allow administration on numerous levels. • Contexts on at a given level become context-elements in the next level down the hierarchy.

8. Hierarchical Contexts (3) • Let C be the set of all hierarchical context elements. • First we define the parent relationship: • XC, context element X has at most one direct parent P. • We define Cparent as the relation: (P,X)  Cparent • We further require that CEs cannot be their own parent. • Thus (C,Cparent) forms a forest of rooted trees. • The Croot predicate evaluates ‘true’ for root CEs. • We require that labels are unique among siblings • This means that root CE labels must also be unique. • We introduce a path notation on CE labels: • For example: CompLab.OPERA.Middleware

9. Hierarchical Contexts (4) • Wildcards are defined using parameterised symbols. • For examplesubtree(X) indicates an information source or target for X and the entire sub-tree of which it is the root. • All parameterised symbols are belong to the set CE • At enforcement time, expand is the function used to generate all CE members from C given an element from CE • We also maintain E to mean all context elements. • Information flows are specified via two functions: • context_out : C  P(C  CE {E}) • context_in : C  P(C  CE {E,e}) • Here P represents a power-set. • Also e indicates an initial context element. • Initial CEs imply no information flow checks are done.

10. Information flow • The information flow graph will contain an edge between two context elements if both elements’ in and out restrictions are satisfied. • We need Ceval to generate a set of elements from expressions, e.g. with respect to our earlier figure:Ceval({CompLab.Security, subtree(CompLab.OPERA)})= {CompLab.Security, CompLab.OPERA, CompLab.OPERA.general, CompLab.OPERA.Trust, CompLab.OPERA.Policy, CompLab.OPERA.Middleware} • So we can define the relation: A A B (A=B) (BCeval(context_out(A)) ACeval(context_in(B))) • Also define A* as the transitive closure of direct edges.

11. Information flow in practice • For information to flow between a parent and a child both the child’s in and the parent’s out information flow restrictions must be considered (or vice versa). • Either explicit context element definitions are used, • or appropriate wild-card expressions can be employed. • Wild-cards are intended to assist future-proofing through use of abstractions instead of explicit labels. • Another consideration is that context elements in an information-flow cycle end up being equivalent. • This could lead to unintuitive results. • Such context elements may still be usefully kept separate for non-information flow context purposes however.

12. Policy management • Note that policy components are associated with contexts rather than context elements. • i.e. components may have multiple context element labels. • This increases the expressive power of context constraints. • We can encode multiple parallel constraint dimensions. • Information flow between contexts: A  P(C)  P(C) • Consider: a A b • Each context element in a must reach (via A*) one in b. • Almost the same applies for context elements in b all being reached (again via A*) by those in a except: • B in b might be initial (i.e. have e  context_in(B)). • Details are in the paper (see Definition 3.1)

13. OASIS policy rules • OASIS has a particular structure for its policy rules: • Privilege Authorisation: r, e1, … , eneHp • Role Activation: r1, … , rnr, ac1, … , acnac, e1, … , eneHr • All components may be annotated with contexts. • Also any rule component may have subcomponents which are classified into contexts: rule_comp[contextcomp](param1[context1],paramn[contextn]) • Parameterised attributes need context labelling when being handled by certain predicates. • They may have different sensitivities. • For example a patient identifier versus a simple date field. • External predicates facilitate information flow in and out of the access control software.

14. Managing access control to policies • Through labelling, contexts provide a means to view and categorise the policy rules themselves. • Encode structural groups. • Even without information flow this may help identify individual ward rules within a hospital policy. • Note that sub-components of a policy component must belong to the context of their parent however: • This simplifies administration and increases safety - this localises the effects of the context in and out functions, whilst not precluding expressive context flow mappings. • Provide a target for administrative privileges. • Visibility of policy rules to different principals. • Organisational versus functional roles. • Contexts can indicate role properties to policy designers.

15. Future work • Using contexts to manage audit granularity. • Certain contexts may indicate greater logging interest. • Classify remote credential sensitivity. • Certain credentials may need faster revocation checks. • Context support for dynamic constraints. • Grouping for cardinality constraints. • Dynamic separation of duties is an example. • Integration into other RBAC systems. • NIST RBAC schemes are simpler than OASIS • Need to consider interactions with role-hierachies however. • Ponder hierarchical management domains similar • Introduce explicit information flow restrictions.

16. Conclusion • We have introduced hierarchical policy contexts to facilitate enforcement of information flow constraints during policy specification. • Extended our earlier work with a formal model. • We applied our context research to the OASIS RBAC system, but it is intended to generalise cleanly. • We also discussed other useful context functions: • Management of access control to the policies themselves. • Contexts add another level to policy authoring. • We feel the benefits in large-scale policy systems will outweigh this extra complexity. • Any questions?