INSTITUTE FOR CYBER SECURITY 1 Access Control Prof. Ravi Sandhu Executive Director and Endowed Chair Institute for Cyber Security University of Texas at.

INSTITUTE FOR CYBER SECURITY

1

Access Control

Prof. Ravi SandhuExecutive Director and Endowed Chair

Institute for Cyber SecurityUniversity of Texas at San Antonio

May 2009

[email protected] www.profsandhu.com

© Ravi Sandhu

INSTITUTE FOR CYBER SECURITY Outline

Discretionary Access Control (DAC) Mandatory Access Control (MAC)

Equivalently Lattice-Based Access Control (LBAC) Role-Based Access Control (RBAC) Usage Control (UCON)

© Ravi Sandhu 2

INSTITUTE FOR CYBER SECURITY ACCESS MATRIX MODEL

U r wown

V

F

Subjects

Objects (and Subjects)

r wown

G

r

rights

© Ravi Sandhu 3

INSTITUTE FOR CYBER SECURITY ACCESS CONTROL LISTS (ACLs)

F

U:r

U:w

U:own

G

U:r

V:r

V:w

V:own

each column of the access matrix is stored with the object corresponding to

that column

each column of the access matrix is stored with the object corresponding to

that column

© Ravi Sandhu 4

INSTITUTE FOR CYBER SECURITY CAPABILITY LISTS

each row of the access matrix is stored with the subject corresponding to that

row

each row of the access matrix is stored with the subject corresponding to that

row

U F/r, F/w, F/own, G/r

V G/r, G/w, G/own

© Ravi Sandhu 5

INSTITUTE FOR CYBER SECURITY ACCESS CONTROL TRIPLES

Subject AccessObject

U r F

U w F

U own F

U r G

V r G

V w G

V own G

commonly used in relational database management systemscommonly used in relational

database management systems

© Ravi Sandhu 6

INSTITUTE FOR CYBER SECURITY TROJAN HORSE EXAMPLE

File FA:r

A:w

File GB:r

A:w

B cannot read file FB cannot read file F

ACL

© Ravi Sandhu 7

INSTITUTE FOR CYBER SECURITY TROJAN HORSE EXAMPLE

File FA:r

A:w

File GB:r

A:w

B can read contents of file F copied to file G

B can read contents of file F copied to file G

ACLA

Program Goodies

Trojan Horse

executes

read

write

© Ravi Sandhu 8

INSTITUTE FOR CYBER SECURITY DAC Summary

Traditional DAC does not prevent copies from being made and there is no control over copies Modern approaches to information sharing and

trusted computing seek to maintain control over copies (for example, our talk on Friday)

Traditional DAC is weak with respect to confidentiality but may have value with respect to integrity

© Ravi Sandhu 9

INSTITUTE FOR CYBER SECURITY LATTICE STRUCTURES

Unclassified

Confidential

Secret

Top Secret

can-flowdominance

© Ravi Sandhu 10

INSTITUTE FOR CYBER SECURITY BELL LAPADULA (BLP) MODEL

SIMPLE-SECURITYSubject S can read object O only if

• label(S) dominates label(O)

STAR-PROPERTY (LIBERAL)Subject S can write object O only if

• label(O) dominates label(S)

STAR-PROPERTY (STRICT)Subject S can write object O only if

• label(O) equals label(S)

© Ravi Sandhu 11

INSTITUTE FOR CYBER SECURITY LATTICE STRUCTURES

{ARMY, CRYPTO}Compartmentsand Categories

{ARMY } {CRYPTO}

{}

© Ravi Sandhu 12

INSTITUTE FOR CYBER SECURITY LATTICE STRUCTURES

HierarchicalClasses with

CompartmentsTS

S

{A,B}

{}

{A} {B}

product of 2 lattices is a latticeproduct of 2 lattices is a lattice

© Ravi Sandhu 13

INSTITUTE FOR CYBER SECURITY LATTICE STRUCTURES

HierarchicalClasses with

Compartments

S,

{A,B}

{}

{A} {B}S, S,

S,

TS,

{A,B}

{}

{A} {B}TS, TS,

TS,

© Ravi Sandhu 14

INSTITUTE FOR CYBER SECURITY SMITH'S LATTICESMITH'S LATTICE

TS-W

S-W

TS

S

C

U

S-L

S-LW

S-A

TS-X

TS-L TS-K TS-Y TS-Q TS-Z TS-X

TS-KL

TS-KLXTS-KY TS-KQZ

TS-AKLQWXYZ

© Ravi Sandhu 15

INSTITUTE FOR CYBER SECURITY EQUIVALENCE OF BLP AND BIBA

HI (High Integrity)

LI (Low Integrity)

BIBA LATTICEBIBA LATTICE EQUIVALENT BLP LATTICEEQUIVALENT BLP LATTICE

LI (Low Integrity)

HI (High Integrity)

© Ravi Sandhu 16

INSTITUTE FOR CYBER SECURITY EQUIVALENCE OF BLP AND BIBA

HS (High Secrecy)

LS (Low Secrecy)

BLP LATTICEBLP LATTICE EQUIVALENT BIBA LATTICEEQUIVALENT BIBA LATTICE

LS (Low Secrecy)

HS (High Secrecy)

© Ravi Sandhu 17

INSTITUTE FOR CYBER SECURITY COMBINATION OF DISTINCT LATTICES

HS

LS

HI

LI

GIVENGIVEN

BLP BIBA

HS, LI

HS, HI LS, LI

LS, HI

EQUIVALENT BLP LATTICEEQUIVALENT BLP LATTICE

© Ravi Sandhu 18

INSTITUTE FOR CYBER SECURITY LIPNER'S LATTICE

LIPNER'S LATTICE

S: RepairS: Production UsersO: Production Data

S: Application Programmers

O: Development Code and Data

S: System Programmers

O: System Code in Development

O: Repair Code

O: System Programs

O: Production Code O: Tools

S: System ManagersO: Audit Trail

S: System Control

LEGEND

S: SubjectsO: Objects

LEGEND

S: SubjectsO: Objects

© Ravi Sandhu 19

INSTITUTE FOR CYBER SECURITY CHINESE WALL EXAMPLE

BANKS OIL COMPANIES

A B X Y

© Ravi Sandhu 20

INSTITUTE FOR CYBER SECURITY CHINESE WALL LATTICE

A, - B, --, X -, Y

A, X A, Y B, X B, Y

SYSHIGH

SYSLOW

© Ravi Sandhu 21

INSTITUTE FOR CYBER SECURITY COVERT CHANNELS

Low User

High Trojan HorseInfected Subject

High User

Low Trojan HorseInfected Subject

COVERTCHANNEL

Information is leaked unknown to the high user

Information is leaked unknown to the high user

© Ravi Sandhu 22

INSTITUTE FOR CYBER SECURITY MAC/LBAC Summary

LBAC fails to control covert channels LBAC fails to control inference and aggregation It is too rigid for most commercial applications It has strong mathematical foundations

© Ravi Sandhu 23

INSTITUTE FOR CYBER SECURITY RBAC: Role-Based Access Control

Access is determined by roles A user’s roles are assigned by security

administrators A role’s permissions are assigned by

security administrators

First emerged: mid 1970sFirst models: mid 1990s

Is RBAC MAC or DAC or neither?

© Ravi Sandhu 24

INSTITUTE FOR CYBER SECURITY Fundamental Theorem of RBAC

RBAC can be configured to do MAC

RBAC can be configured to do DAC

RBAC is policy neutral

RBAC is neither MAC nor DAC!

© Ravi Sandhu 25

INSTITUTE FOR CYBER SECURITY RBAC96 Model

ROLES

USER-ROLEASSIGNMENT

PERMISSIONS-ROLEASSIGNMENT

USERS PERMISSIONS

... SESSIONS

ROLE HIERARCHIES

CONSTRAINTS

© Ravi Sandhu 26

INSTITUTE FOR CYBER SECURITY

Example Role Hierarchy

Engineering Department (ED)

Project Lead 1(PL1)

Engineer 1(E1)

Production 1(P1)

Quality 1(Q1)

Director (DIR)

Project Lead 2(PL2)

Engineer 2(E2)

Production 2(P2)

Quality 2(Q2)

Employee (E)

Inheritance hierarchy

© Ravi Sandhu 27

INSTITUTE FOR CYBER SECURITY

Example Role Hierarchy

Engineering Department (ED)

Project Lead 1(PL1)

Engineer 1(E1)

Production 1(P1)

Quality 1(Q1)

Director (DIR)

Project Lead 2(PL2)

Engineer 2(E2)

Production 2(P2)

Quality 2(Q2)

Employee (E)

Inheritanceand activation hierarchy

© Ravi Sandhu 28

INSTITUTE FOR CYBER SECURITYNIST/ANSI RBAC Standard Model 2004

ROLES

USER-ROLEASSIGNMENT

PERMISSIONS-ROLEASSIGNMENT

USERS PERMISSIONS

... SESSIONS

ROLE HIERARCHIES

CONSTRAINTS

Permission-role review is advanced requirement

Limited to separation of dutiesOverall formal

model is more complete

© Ravi Sandhu 29

INSTITUTE FOR CYBER SECURITY The RBAC Story

© Ravi Sandhu 30

2nd expansion phase1st expansion phase

1995 2000 2005 2008

Amount ofPublications

Year of Publication

28 30 30 35 40 48 53 88 85 88 112 103 111 866

1992

3 2 7 3

80

60

40

20

0

Pre-RBAC Early RBAC

100

RBAC96paper

ProposedStandard

StandardAdopted

INSTITUTE FOR CYBER SECURITY

Founding Principles of RBAC96

Abstraction of PrivilegesCredit is different from Debit even

though both require read and write Separation of Administrative Functions

Separation of user-role assignment from role-permission assignment

Least PrivilegeRight-size the rolesDon’t activate all roles all the time

Separation of DutyStatic separation: purchasing manager

versus accounts payable managerDynamic separation: cash-register clerk

versus cash-register manager

© Ravi Sandhu 31

INSTITUTE FOR CYBER SECURITY

ASCAA Principles for Future RBAC

Abstraction of PrivilegesCredit vs debitPersonalized permissions

Separation of Administrative Functions Containment

Least PrivilegeSeparation of DutiesUsage Limits

AutomationRevocationAssignment: (i) Self-assignment, (ii) Attribute-

based Context and environment adjustment

AccountabilityRe-authentication/Escalated authenticationClick-through obligationsNotification and alerts

© Ravi Sandhu 32

INSTITUTE FOR CYBER SECURITY Access Control Models

Discretionary Access Control (DAC) Owner controls access but only to the original, not to

copies Mandatory Access Control (MAC)

Access based on security labels Labels propagate to copies

Role-Based Access Control (RBAC) Access based on roles Can be configured to do DAC or MAC

Attribute-Based Access Control (ABAC) Access based on attributes, to possibly include roles,

security labels and whatever

© Ravi Sandhu 33

INSTITUTE FOR CYBER SECURITY Security Objectives

34

INTEGRITYmodification

AVAILABILITYaccess

CONFIDENTIALITYdisclosure

USAGEpurpose

USAGE

© Ravi Sandhu

INSTITUTE FOR CYBER SECURITY Usage Control Scope

© Ravi Sandhu 35

Server-sideReference Monitor

(SRM)

Client-sideReference Monitor

(CRM)

TraditionalAccessControl

TrustManagement

Usage ControlSensitive

InformationProtection

IntellectualProperty Rights

Protection

PrivacyProtection

DRM

SRM & CRM

SecurityObjectives

Security Architectures

INSTITUTE FOR CYBER SECURITY Usage Control Model (UCON)

© Ravi Sandhu 36

Rights(R)

Authorizations

(A)

Subjects(S)

Objects(O)

Subject Attributes (SA) Object Attributes (OA)

Obligations(B)

Conditions(C)

UsageDecisions

before-usage ongoing-Usage after-usage

Continuity ofDecisions

pre-decision ongoing-decision

pre-update ongoing-update post-update

Mutability ofAttributes

• unified model integrating• authorization• obligation• conditions

• and incorporating• continuity of decisions• mutability of attributes

INSTITUTE FOR CYBER SECURITY Conclusion

Discretionary Access Control (DAC) Mandatory Access Control (MAC)

Equivalently Lattice-Based Access Control (LBAC) Role-Based Access Control (RBAC) Usage Control (UCON)

© Ravi Sandhu 37

Models are all importantA Policy Language is not a substitute for a good model