ruleml2015: representing flexible role-based access control policies using objects and defeasible...

Representing Flexible Role-Based Access ControlPolicies Using Objects and Defeasible Reasoning

Reza Basseda 1 Tiantian Gao 1 Michael Kifer 1

Steven Greenspan 2 Charley Chell 2

1Stony Brook University

2CA, Inc.

August 3, 2015

Michael Kifer (Stony Brook University) RBAC Using Objects and Defeasibility RuleML 2015 1 / 17

The Problem

Flexible Access Control

CA, Inc. wanted a resilient, customizable, maintainable access controlpolicy for managing its worldwide information resources

Customization to be done by security people, not programmers orknowledge engineers

Rule systems are commonly used to specify access policies, but tomeet the requirements of customizability and maintainability weidentified three requirements:

Support for defeasible reasoningObject-oriented featuresHigher-order reasoning

Flora-2: satisfies all three requirements


Defeasible Reasoning

What is defeasible reasoning?

A type of non-monotonic reasoningPriorities over conclusions.Conclusions can be defeated by other conclusion.

Example of an access control policy:Typically, every student is authorized to use every deviceThose who have abused a device before lose access to that device.

John is a student and a printer is a device.John is authorized to use a printer.John has abused the printer.John is authorized to use a printer.

General non-monotonic reasoning frameworks:Circumscription.Default logic.Autoepistemic logic.Negation as failure (of different kinds)

Not designed for making changes modular.





Example of an access control policy:Typically, every student is authorized to use every deviceThose who have abused a device before lose access to that device.John is a student and a printer is a device.

John is authorized to use a printer.John has abused the printer.John is authorized to use a printer.







Example of an access control policy:Typically, every student is authorized to use every deviceThose who have abused a device before lose access to that device.John is a student and a printer is a device.John is authorized to use a printer.

John has abused the printer.John is authorized to use a printer.







Example of an access control policy:Typically, every student is authorized to use every deviceThose who have abused a device before lose access to that device.John is a student and a printer is a device.John is authorized to use a printer.John has abused the printer.

John is authorized to use a printer.







Example of an access control policy:Typically, every student is authorized to use every deviceThose who have abused a device before lose access to that device.John is a student and a printer is a device.John is authorized to use a printer.John has abused the printer.John is authorized to use a printer.





Logic Programming with Defaults and ArgumentationTheories (LPDA)

Suitable theories come from the family of Defeasible Logics (Nute)

There are many different kinds. We use Logic Programming withDefaults and Argumentation theories (LPDA).

Defaults, Exceptions with Prioritized rules, and ArgumentationTheories.Easily adapts to frequent changes.Itself is a family of logics that can be tailored to various needs.



LPDA

Strict Rules vs. Defeasible Rules

L : −Body . // strict@r L : −Body // defeasible

Special predicates:\opposes.

Indicates which conclusions are incompatible with each other.

\overrides.

Tells which rules have higher priorities.

Argumentation theory

Specifies the conditions under which incompatible conclusions defeateach other.



Example

@{id1} authorized(?Principal,?Dev) :-

device(?Dev), principal(?Principal).

@{id2} \neg authorized(?Principal,?Dev) :-

abused(?Principal,?Dev).

\overrides(id2,id1).

\opposes( authorized(?Principal,?Dev),

\neg authorized(?Principal,?Dev) ).

principal(Mary).

principal(John).

device(printer).

abuse(John,printer).


Policies with Objects and Defeasible Rules

Using Classes and Objects

Classes: Represent different resources and roles used by policies.

Semantic integrity constraints.Guide policy development.

Subclasses behavior overrides that of classes

Mechanism similar to defeasibility, but simpler and works at thestructural level.



Classes and ObjectsClass Signatures in Flora-2

Person[|

firstName => string,

lastName => string

|].

Employee::Person[|

employmentYear => integer,

department => Department,

profession => string,

rank => Rank,

loc(?) => Location

|].



Flexibility via PatchingDefeasible rules

Patching mechanism via defeasible reasoning:

Override default rules of a policy with new rules.

For instance, P might be a policy with a default rule

@r L :- Body.

Changing the policy by adding a more specific rule for certain cases:

@r ′ L′ : −Body ′.\overrides(r ′, r) : −Cond .\opposes(L, L′).

When Cond holds, rule r ′ is used instead of r .



Flexibility via PatchingDisable a rule

Another way: canceling a rule (instead of overriding).

\cancel(r) : −Cond2.

Patching is local, modular, does not require expertise in logic — canbe done though high-level interface



Policies using Monolithic Rules vs. Policies based onDefeasible Rules

Monolithic rules vs. Defeasible rules




Modifying old rules vs. Adding patch rules




More mangling the old rules vs. Patching modularly


Complex Example

More Complex Example

A policy that responds to queries of the form?- grantAccess(?E, ?R, ?T, ?D)where:

?E : Employee (Principal)?R: Resource?T : Time of Access?D: Date of Access


Complex Example


% Indicates that the employee ?E is allowed to access resource ?R

% at time ?T of day ?D.

@locAccess

grantAccess(?E,?R,?,?D) :-

?E:Employee[department-> ?DE],

?R:Resource[owner-> ?DE],

locRisk(?E,?D,?K), // estimates the risk (?K) of granting access to ?E on day ?D

?K < 3.


Complex Example


Required change: include the risk based on the time of access, if theemployee is away from the home department.

@{timeAccess}

\neg grantAccess(?E,?R,?T,?D) :-

?E:Employee,

?R:Resource,

?E.department.location != ?E.loc(?D),

?E[timeWorked(?D) -> ?T],

timeRisk(?T,?K),

?K > 5.

\overrides(timeAccess,locAccess).

timeRisk(?T,?TD) :- ?TD \is abs(?T - 13).


Complex Example


Another modification: Use employee’s local time rather than resource’s

// This rule says that the employee ?E can

// access resource ?R at time ?T on day ?D, if the access happens within

// the local normal working hours. Other than that, the conditions are the

// same as for rule locAccess.

@flexAccess

grantAccess(?E,?R,?T,?D) :-

?E[department-> ?DE],

?R[owner-> ?DE],

?E.loc(?D) != ?R.location,

timeRisk(?E,?T,?D,?TR), // assesses the risk (?TR) based on time of day

?TR < 5.

\overrides(flexAccess,timeAccess).


Conclusion

Conclusion

Defeasible reasoning can yield significant benefits in the area ofrole-based access control systems.

Complex modifications to access control policies can be naturally donein a logic programming framework with defeasible reasoning.Institutional hierarchies of policy makers and reflecting thosehierarchies in a policy — ditto.Higher-order rules can represent parameterized policies, reducing thenumber of rules (not discussed in the talk).

Future work:

Investigate more complex access control modelsDeeper use of object-oriented features, higher-orderness.


Conclusion

Thank you

Questions?


ruleml2015: representing flexible role-based access control policies using objects and defeasible...

Science

access policies

defeasibility ruleml

security people

tiantian gao

charley chell

steven greenspan