/
Status Based Access Control Status Based Access Control

Status Based Access Control - PowerPoint Presentation

luanne-stotts
luanne-stotts . @luanne-stotts
Follow
388 views
Uploaded On 2017-03-19

Status Based Access Control - PPT Presentation

Venkata Marella 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 ID: 526486

status agent sbac access agent status access sbac set action time actions iblp logic control model event policy level based agents policies

Share:

Link:

Embed:

Download Presentation from below link

Download Presentation The PPT/PDF document "Status Based Access Control" is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.


Presentation Transcript

Slide1

Status Based Access Control

Venkata

MarellaSlide2

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 timeSlide3

Challenge: Size, Complexity and dynamic nature of some distributed systems.

Key feature of SBAC model is that a decision on an agent’s request to access is determined by considering the agent’s ascribed-status, the agent’s action status and any additional conditions of relevance in answering the access request.

Ascribed

Status+Action

Status=Overall statusSlide4

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.Slide5

Action Status

An agent’s 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 agent’s 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.Slide6

Example

A human agent who is under eighteen years of age. The agent’s 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 offenderSlide7

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.Slide8

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 resourcesSlide9

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.Slide10

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 requestsSlide11

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).Slide12

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.Slide13

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.Slide14

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.Slide15

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.Slide16

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

).Slide17

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.Slide18

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.Slide19

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.Slide20

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.Slide21

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.Slide22

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 rulesSlide23

Event Description in IBLPs

An agent’s 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).Slide24

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 umSlide25

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.Slide26

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 U’s 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 U’s assignment of the status level L to be terminated.Slide27

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.Slide28

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 bank’s loyalty scheme by a set date. These are useful in assigning temporary assignment of status.

Negative Promissory Actions

Positive Promissory ActionsSlide29

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 U’s (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).Slide30

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).Slide31

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

.Slide32

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.Slide33

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.Slide34

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. Slide35

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.Slide36

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, 706–734.

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, 335–364.

APT, K. R. AND BLAIR, H. 1990. Arithmetic classification of perfect models of stratified programs.

XIII, 1–17.

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, 492–540.

BARAL, C. AND GELFOND, M. 1994. Logic programming and knowledge representation.

JLP

19/20, 73–148.

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 (PEPM’04), 190–199.

BARKER, S., LEUSCHEL, M., AND VAREA, M. 2008. Efficient and flexible access control via Jones

optimality logic program

specialisation

.

Higher-Order Symbol.

Comput

. 21, 1–2, 5–35.