Status-Based Access Control: A Solution for Dynamic Access Management

Status-Based Access Control: A Solution for Dynamic Access Management

This model allows for distributed and versatile access policy information, making it ideal for situations where permissions frequently change. The permissions of requesting agents play a key role in determining whether or not access should be granted, and the access control checker intelligently monitors authorizations in real-time.

About Status-Based Access Control: A Solution for Dynamic Access Management

PowerPoint presentation about 'Status-Based Access Control: A Solution for Dynamic Access Management'. This presentation describes the topic on This model allows for distributed and versatile access policy information, making it ideal for situations where permissions frequently change. The permissions of requesting agents play a key role in determining whether or not access should be granted, and the access control checker intelligently monitors authorizations in real-time.. The key topics included in this slideshow are access control, dynamic access management, distributed access policy, permission-based access, authorization monitoring,. Download this presentation absolutely free.

Presentation Transcript

1. Status Based Access Control Venkata Marella

2. Introduction This model is applicable in situations where - access policy information may be distributed and independently maintained. -the permissions to access the resources change frequently. - of agents that request access to protected resources, are important in rendering a decision on allowing the requested access or not. - Access control checker can intelligently determine the authorization that hold at any instance of time

3. Challenge: Size, Complexity and dynamic nature of some distributed systems. Key feature of SBAC model is that a decision on an agents request to access is determined by considering the agents ascribed-status, the agents action status and any additional conditions of relevance in answering the access request. Ascribed Status+Action Status=Overall status

4. Ascribed Status an ascribed-status is associated with a collection of agents that is formed on the basis of some common criterion that the agents of the collection share. Particular role A categorization of agents as a reason of sharing common attributes Trustworthiness Discretionary assignment of agents to a group.

5. Action Status An agents action-status is determined from a history of the deliberative actions performed by the agent An agent is viewed as a rational entity that can, within certain constraints, choose the actions it performs. As access to resources is determined from an agents status level, it immediately follows that, in SBAC, an agent can determine its access to resources because the agent can choose the actions it performs and thus its action-status.

6. Example A human agent who is under eighteen years of age. The agents age is the basis for an ascribed-status of minor( not deliberate). Now, suppose that the agent performs the deliberative action of stealing a car and assume that no mitigating circumstances apply to excuse the act of stealing( deliberate). Then, the ascribed-status of minor together with the deliberative action of stealing a car (we assume that the action is not coerced)might give the agent an overall status of young offender

7. The status of young offender may be used as a basis for determining what actions an agent with young offender status can and cannot do. For example, agents with the status of young offender may be subject to a curfew order and, as a consequence, the agent may not be permitted to leave his/her registered address in the hours between 6 p.m. in the evening and 8 a.m. on the following day The ascribed-status and action-status of an agent u that requests to access a resource r is used to determine what actions u is authorized to perform on r.

8. Access control models, like SBAC, that take agent actions into account and that allow agents to manage, to some extent, their access to resources will be increasingly important in distributed applications, such as secure e-trading and e-contracting. Notions like job functions and roles are often of peripheral (or no) significance. Instead, criteria such as the quantity of units ordered by a customer agent via acts of purchasing may be used as the basis for determining access to resources

9. Example Customers ordering large volumes of merchandise may, from their history of purchases, be determined to have preferred status and, as a consequence, may be permitted to access special offers information that is not accessible to customers without preferred status. By addressing such requirements, the SBAC model contributes to work by the access control community that aims to increase the functionality and application of access control models.

10. Important Issues dealing with changing access control requirements that can be effected autonomously the identification of information resources in distributed systems that may be used for evaluating access requests

11. the composition of SBAC policies - we make use of the primitive notion of an event and we show how a finite and efficiently implementable axiomatization of an event-based, typed logical theory can be constructed for dealing with changing access control requirements. - we introduce Identification-based Logic Programs (IBLPs) - we define a number of algebras for flexibly composing SBAC policies (represented as IBLPs).

12. The SBAC model and SBAC policies are specified in a language that has a purely declarative semantics and that can be directly translated into an executable form for which efficient, sound, and complete operational semantics exist for access request evaluation. IBLP language is based on a nonmonotonic semantics that provides a basis for accommodating changing policy requirements and for defining an access control checker that is able to reflect upon its knowledge and to change an access control policy dynamically and autonomously in response to changes in its knowledge base.

13. Identification Based Logic Program Identification-based Logic Programs (IBLPs). IBLPs are an annotated form of logic programs that allow independently maintained and distributed information sources to be specified and referenced in the process of access request evaluation. IBLPs are based on a syntactic variant of normal logic programs.

14. Definition 1 . A normal clause is a formula of the form: A A1, . . . , Am, not Am+1, . ., not Am+n (m 0, n 0). A normal logic program is a set of normal clauses. The head A of the clause and each A i are atoms A1, . . . , Am are called positive literals, and not Am+1, . . . , not Am+n are negative literals; not denotes negation-as-failure. A clause with an empty body is a fact. Rule is a non empty body. The literals are also known as conditions of the clause. We denote variables in clauses by using symbols that start with a letter in the upper case; we denote constants by using symbols that start with a letter in the lower case.

15. Each atom in the body of a clause is annotated with the name of a uniquely identifiable module, which may be stored on any file server called Uniform Resource Identifiers (URI). Uniform resource identifiers (URIs) provide a unique global identity for referencing IBLPs.

16. Definition 2 : Let R be a finite set of URIs. An identification-based clause is a formula of the following form ( m 0, n 0): A A 1 v1, . . . , A m m, not A m+1 m+1, . . . , not A 1 A m+n m+n where the head A and each A i (1 i m+ n) are atoms, and each i (1 i m+ n) is a URI in R. An IBLP is a finite set of identification-based clauses. where is a mapping : R { P1, . . . , Pn}. Ai i is true (provable) iff Ai is true (provable) with respect to the IBLP ( i), and not Ai i is true (provable) iff Ai is not true with respect to ( i).

17. Definition 3: Let R be a finite set of URIs and P1, . . . , Pn be IBLPs. An IBLP configuration is a pair (R, ) where is a mapping : R { P1, . . . , Pn}. Definition 4 : Let (R, ) be an IBLP configuration, and let u i be a URI in R. i denotes the normal logic program obtained by replacing every occurrence of an atom of the form p(t1, . . . , t k ) in the IBLP ( i ) by the atom p:(t1, . . . , t k ), and every occurrence of an annotated atom of the form p(t1, . . . , t k ) in the IBLP ( i ) by the atom p:i(t1, . . . , t k ). Let R = {1, . . . , n }. The reduction of (R, ), written 1(R, ), is the normal logic program 1 1 1 n.

18. Definition 5: Let (R, ) be an IBLP configuration. M is an identification based (IB) stable model of (R, ) iff M is a stable model of the normal logic program (R, ). Definition 6: Although a reduction generates a normal logic program from an IBLP by translating all URI- annotated atoms to unannotated atoms, the IBLP syntax is not redundant: a p(t1, . . . , tk) i condition in an IBLP has an operational meaning as well as a logical meaning.

19. SBAC MODEL AND POLICIES SBAC model and SBAC policies - A countable set O of object identifiers. - A countable set A of named actions -A countable set L of status level identifiers -A countable set E of event identifiers. - A countable set U of agent identifiers. - A countable set T of time points.

20. An object is any thing that store information. an IBLP, a database, individual facts within a database. All objects have unique identity that is invariant; some object may have properties. The set A of named actions includes - the actions that may perform to change the status -the actions the agent can perform as a consequence of enjoying a particular status. A status level is a named position of an agent that is relative to other status levels of interest in a specific domain of discourse. Example: 1.) Preferred Customer 2.) Ordinary Customer.

21. Events are happenings at an instance of time. We adapt a one point discrete view of time, with a beginning and no endpoint. We assume that the time is bidirectional so that proactive and post active may be made to represent the access policy requirements and so that past, present and future times can be used in our model as a basis to make decisions. Preauthenticated agents may evaluate queries on information sources protected by SBAC policies expressed using IBLPs.

22. An authorization is a 4-tuple (u, a, r, i) where u U is an agent identifier, a A is an access privilege, r O is the resource u requests to retrieve, and i O is the IBLP from which u requests to retrieve r in i. - how a history of events, relating to individual agents, is represented as a set of facts. - we use IBLP rules to express the core logical axioms for our SBAC model - we describe the formulation of a set 8 of IBLP rules

23. Event Description in IBLPs An agents access to the information resources that are maintained by an organization will depend, in part, upon the transactions the requester agent engages in with . These transactions are expressed via a set of application-specific security event descriptions (SEDs) Definition: A security event description (SED) is a finite set of ground 2-place facts (atoms) that describe an event, uniquely identified by , i N, and which includes three necessary facts, and n non-necessary facts (n 0).

24. The three types of necessary facts in a SED and their intended meanings are as follows: MOD( --) = happens(e i , t i ) : the event e i happens at time t j . MOD(--) = act(e i , a l ) : the event e i involves an action al. MOD(--) = agent(e i , u m ) : the event e i involves the agent u m . The happens(e i , t i ) , act(e i , a l ) and agent(e i , u m ) facts in an SED are used to represent a happening e i at a time t i of act a l performed by an agent um

25. Example Consider the following SED: { happens(e1, 20060612), agent(e1, bob), act(e1, depositing), object(e1, a1), amount(e1, 1000)}. This SED describes an event e1 that happens on 12th June 2006, and involves the agent Bob depositing an amount of 1000 Euros into an object. bank account) denoted by a1. The amount(e1, 1000) fact and the object(e1, a1) fact are non-necessary facts.

26. Logical Axioms in IBLPs An agent U is currently assigned the status level L if an event E happened at a time Ts, which is earlier than the current time T, and resulted in the initiation of Us assignment to L, and this assignment has not been ended before T as a consequence of an event E happening at a time T between Ts and T that causes Us assignment of the status level L to be terminated.

27. Proper Axioms A set of rules (AUX) that define the auxiliary predicates that appear in the axioms A set of rules that specify permission-level assignments (PLA); A set of rules that define denial-level assignments (DLA); A set of rules (ACC) that are meta-level policy rules A (singleton) set of rules (AUT H) that specifies the authorizations defined by a policy.

28. Extended SBAC In extended SBAC, we consider promissory actions and hypothetical actions. A promissory action is a promise by an agent to perform an action at some future time, that is, an agent may promise to join a banks loyalty scheme by a set date. These are useful in assigning temporary assignment of status. Negative Promissory Actions Positive Promissory Actions

29. Positive Promissory Actions : A positive promissory action is an action of promising that an agent U makes at time T1 that by some future time point T2 an action A will be performed by U. The following variant of the axiom may be used to assign an agent U to a status level L1 on the basis of Us (positive) promissory action: sla(U, L1) current time(T), happens(E1, T1), agent(E1,U), pp act(E1, A), T1 T, sla init(E1,U, A, L1, T1), not ended sla(U, L1, T1, T), not expired sla(E1, T).

30. Negative Promissory Actions: A negative promissory action is an action of promising that an agent U makes at time T1 that until some future time point T2 an action A will not be performed by U. sla(U, L1) current time(T), happens(E1, T1), agent(E1,U), h act(E1, A), T1 T, sla init(E1,U, A, L1, T1), not ended sla(U, L1, T1, T).

31. Practical Considerations On general complexity issues, we note that the key decision problem of interest in the context of SBAC policies is the problem of deciding whether a particular instance of authorized is true in the IB-stable model for an IBLP configuration. Four test for practical implementation Test 1. Query evaluation on a database db stored on a single machine without an SBAC policy used to protect db. Test 2. Query evaluation on a database db protected by an implementation of an SBAC policy and stored on the same machine as db .

32. Test 3. Status level computations using an SBAC policy that accesses information from multiple distributed sites. Test 4. Remote access to a file of facts. Two key observations emerge from our analysis of the results generated from the testing: - Using SBAC policies to protect information sources imposes negligible extra overheads. - Although communication costs dominate CPU costs dominate CPU costs, the evaluation of realistic distributed computations can be performed with adequate efficiency for realistic SBAC policies.

33. SBAC Vs RBAC SBAC Model generalizes some RBAC Models. In RBAC, agents are assigned to one specific type of ascribed status( i.e. role); once the role assignment is made to the agent this persists as long as the security administrator. SBAC allows any number of deliberate actions to be performed by the agent to be performed by requester agent.

34. In constrained RBAC, contraints may be used to express higher-level policy requirements that agent-role and permission-role assignments. In SBAC, ACC is used for meta-policy specification, and constraints, such as separation of status, can be naturally accommodated. In contrast, in our approach, security administrators define access control policies using predicates of their own choosing , and test for stratifiability of policy specifications.

35. Conclusion SBAC policies are appropriate to use in dynamically changing, distributed computing contexts in which, for instance, the notion of a job function does not necessarily apply and where it is important to accommodate rational agents that can pursue individual goals rather than performing a particular function within a particular organizational structure.

36. References ABADI, M., BURROWS, M., LAMPSON, B. W., AND PLOTKIN, G. D. 1993. A calculus for access control in distributed systems. ACM Trans. Program. Lang. Syst., 15, 4, 706734. ANTONIOU, G. AND VAN HARMELEN, F. 2004. A Semantic Web Primer. MIT Press. APT, K. 1997. From Logic Programming to Prolog. Prentice Hall. APT, K. AND BEZEM, M. 1991. Acyclic programs. New Generation Comput., 9, 3/4, 335364. APT, K. R. AND BLAIR, H. 1990. Arithmetic classification of perfect models of stratified programs. XIII, 117. BACON, J., MOODY, K., AND YAO, W. 2002. A model of OASIS RBAC and its support for active security. ACM Trans. Inf. Syst. Secur., 5, 4, 492540. BARAL, C. AND GELFOND, M. 1994. Logic programming and knowledge representation. JLP 19/20, 73148. BARKER, S., LEUSCHEL, M., AND VAREA, M. 2004. Efficient and flexible access control via logic program specialisation. In Proceedings of the ACM/SIGPLAN Workshop on Partial Evaluation and Semantics-Based Program Manipulation (PEPM04), 190199. BARKER, S., LEUSCHEL, M., AND VAREA, M. 2008. Efficient and flexible access control via Jones optimality logic program specialisation. Higher-Order Symbol. Comput. 21, 12, 535.