PolicyMorph: Interactive Policy Model Transformations for a Logical ABAC Framework

Michael LeMay

Omid Fatemieh

Carl A. Gunter

Outline

• Motivation

• Introduction

• Logical Attribute-Based Policies

• Logical Constraints

• Access Control Models

• Model Transformations

• Prototype Implementation and Test Case

• Conclusion

2

Motivation

• Difficult or impossible for policy administrator to formally encode all desired policy constraints:

All Possible Policy Models

Models Accepted byFormal Constraints

ModelsDesired

byAdministrator

3

Motivation: Example

• Consider: Access control policy for Personally-Identifiable Information (PII) contained in online retailer’s database– Regulated by retailer’s privacy policy: “maintain

confidentiality of customer information from third party partners and marketing”

• Assume some employees employed in both information systems support and marketing departments– Such an employee could be responsible for

customer email list– Privacy policy prohibits this separation of duty

violation, and constraint checker detects violation.

4

Motivation: Example (cont.)

• Task must be assigned to some other employee

• Constraint checker unaware of external considerations essential to task reassignment, such as existing workloads of employees, relevant skills, etc.

• Policy model administration tool presents administrator a list of possible employees to which task could be reassigned, and administrator selects most suitable option.

5

Introduction

• Model transformation tool for logical attribute-based policies

• Uses first-order logical constraints to detect bad model configurations

• Suggests possible model transformations to bring model into conformance

• Evaluates effects of transformations

6

Access Control Architecture

Logical Attribute-Based Access Control (ABAC) Policy

Access Control Model

Subjects

Objects

AttributesAttributeAssn.Actions

Context

7

Logical Attribute-Based Policies

• Order-sorted first-order logic:– S: subjects (σ)– O: objects (δ)– Entities: supersort of S and O (ε)– Actions: performed by subjects upon objects (η)– Contexts: runtime information incorporated into

decisions (γ)– Justifications: compound terms specifying every

reason a positive access decision was made (κ)

8

Policy Models

• 5-tuple:– A: sort containing attributes– : reflexive, transitive, anti-

symmetric relation defining attribute hierarchy:• :

– : associates attributes with entities

9

Major Concepts

• Policies:

• Contexts:

• Justifications:

– Set of Reasons:

– Set of rule names

10

Sample Justification Reasons

11

Amber CurtissTA(CS423)

RAPossible reasons in justifications:

HasAttr(TA(CS423))HasSubAttr(TA)IsNamed(Amber)

HasAttr(RA)NotHasSubAttr(TA)IsNamed(Curtiss)NotIsNamed(Amber)

Logical Constraints

• Signature:– f: any first-order formula– κ: justification specifying why constraint has

been violated

12

Model Transformations

• Generated from constraint justifications to bring model into conformance:

13

Transformation Animations

14

Amber CurtissTA(CS423) RA

EliminationIntroductionEgress TransferIngress Transfer

Transformation Suggestions

• Framework “suggests” possible transformations based on reasons in justifications from constraints:

15

Transformation Suggestions (cont.)

16

Sample Suggestions

17

CurtissRA

Possible suggestions for reasons:HasAttr(Curtiss, RA) => Eliminate(Curtiss, RA)NotHasSubAttr(TA) => Introduce(Curtiss, TA(CS423))

Prototype Implementation

• SWI-Prolog access control engine

• Text-mode interactive model validation and transformation tool

18

Model Validation Tool

19

Test Case Scenario #1

• TA separation of duty enforcement

• Constraint: It should never be true that any TA shares a TA room with another TA from one of the courses in which the first TA is enrolled.

• Model:– 408 subjects– 172 objects– Similar to CS department at UIUC

20

Constraint Encoding

21

Constraint Violations

• Sample:

• Curtiss and Amber are assigned to the same TA room, and Amber is Curtiss’ TA!

22

Scenario

CurtissAmber

Course: CS523Course: CS461Room 4023

TATA Student

TA roomTA room

23

Suggested Solutions

• remove ta(cs461) from the subject curtiss• transfer ta(cs461) to amber• transfer ta(cs461) to corwin• transfer ta(cs461) to alice• ...• remove student(cs523) from the subject curtiss• transfer student(cs523) to alice• ...• remove ta(cs523) from the subject amber• transfer ta(cs523) to curtiss• transfer ta(cs523) to corwin• transfer ta(cs523) to alice• …• remove ta_room(cs523) from the object room(rm4023)• transfer ta_room(cs523) to room(rm4001)• transfer ta_room(cs523) to room(rm4002)• ...• remove ta_room(cs461) from the object room(rm4023)• transfer ta_room(cs461) to room(rm4001)• transfer ta_room(cs461) to room(rm4002)• ...

24

Scenario

CurtissAmber

Course: CS523Course: CS461Room 4023

TATA Student

TA roomTA room

Room 4001

TA room

25

Selected Related Works

• Fisler, K., Krishnamurthi, S., Meyerovich, L. A., and Tschantz, M. C. 2005. Verification and change-impact analysis of access-control policies. In Proceedings of the 27th international Conference on Software Engineering (ICSE ‘05).

28

Conclusion

• PolicyMorph leverages an administrator’s human knowledge to select a desirable policy model from among all those that satisfy a set of constraints

30

Questions?

• Contact info: mdlemay2@cs.uiuc.edu

• Project webpage: http://seclab.uiuc.edu/policymorph

• Thank you!

31