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

Talk Outline Motivation and Background. Policy Contexts. 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.

Background Role-Based Access Control Large-scale policy administration 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.

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.

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.

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: A A B 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.

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

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

Hierarchical Contexts (4) Wildcards are defined using parameterised symbols. For example subtree(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.

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.

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.

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)

OASIS policy rules OASIS has a particular structure for its policy rules: Privilege Authorisation: r, e1, … , ene H p Role Activation: r1, … , rnr, ac1, … , acnac, e1, … , ene H r 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.

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.

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.

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?