ISA 562 Information Security Theory and Practice Role-based Access Control.

54
ISA 562 ISA 562 Information Security Information Security Theory and Practice Theory and Practice Role-based Access Control Role-based Access Control

Transcript of ISA 562 Information Security Theory and Practice Role-based Access Control.

ISA 562 ISA 562 Information SecurityInformation SecurityTheory and PracticeTheory and Practice

Role-based Access ControlRole-based Access Control

ReferencesReferences1.1. NIST documents at NIST documents at http://csrc.nist.gov/rbac/

2.2. D. Ferraiolo, R. Sandhu, S. Gavrila, D.R. Kuhn, R. D. Ferraiolo, R. Sandhu, S. Gavrila, D.R. Kuhn, R. Chandramouli, "A Proposed Standard for Role Based Chandramouli, "A Proposed Standard for Role Based Access Control (Access Control (PDF)," )," ACM Transactions on ACM Transactions on Information and System SecurityInformation and System Security , vol. 4, no. 3 , vol. 4, no. 3 (August, 2001) - draft of a consensus standard for (August, 2001) - draft of a consensus standard for RBAC.RBAC.

3.3. The ARBAC97 model for role-based administration of The ARBAC97 model for role-based administration of

roles (1999)roles (1999)

Discretionary ACDiscretionary AC

Name AccessTom YesJohn NoCindy Yes

ApplicationAccess List

Restricts access to objects based solely on Restricts access to objects based solely on the identity of users who are trying to access the identity of users who are trying to access them.them.

Individuals Resources

Server 1

Server 3

Server 2Legacy Apps

Mandatory ACMandatory AC

MAC mechanisms assign a security level MAC mechanisms assign a security level to all information, assign a security to all information, assign a security clearance to each user, and ensure that all clearance to each user, and ensure that all users only have users only have accessaccess to that data for to that data for which they have a clearance. which they have a clearance.

Principle: Read Down Access equal or less Clearance Write Up Access

equal or higher Clearance

Mandatory AC (cont)Mandatory AC (cont)

Users Resources

Server 1“Top Secret”

Server 3“Classified”

Server 2“Secret”

Role-Based ACRole-Based AC

Individuals Roles Resources

Role 1

Role 2

Role 3

Server 1

Server 3

Server 2

User’s change frequently, Roles don’t

Role-Based ACRole-Based AC

A user has access to an object A user has access to an object based on the based on the assigned role. assigned role.

Roles are defined based on Roles are defined based on job functionsjob functions.. Permissions are defined based on Permissions are defined based on authorities authorities

and responsibilities of a joband responsibilities of a job.. Operations on an object are invocated based on Operations on an object are invocated based on

the permissions.the permissions.

Role-Based AC FrameworkRole-Based AC Framework

Core ComponentsCore ComponentsConstraining ComponentsConstraining Components

Hierarchical RBACHierarchical RBACGeneralGeneralLimitedLimited

Separation of Duty RelationsSeparation of Duty RelationsStaticStaticDynamicDynamic

Core ComponentsCore Components

Defines:Defines:USERS USERS ROLES ROLES OPERATIONS (OPERATIONS (opsops))OBJECTS (OBJECTS (obsobs))Permissions: (operation, object) pairsPermissions: (operation, object) pairsUser-to-Role Assignments (User-to-Role Assignments (uaua))

assigned_usersassigned_usersSessionsSessions

RBAC CoreRBAC Core

user_sessions session_roles

(UA)User Assign-

ment

(PA)PermissionAssignment

USERS OBSOPS

SESSIONS

ROLES

PRMS

USERSUSERS

Process

Process

People:•Alice•Bob•Cindy

Processes:•Intelligent Agent• mailer daemon• A mal-ware process

OBS (objects)OBS (objects)

An entity that contains or receives information, or has exhaustible system resources.

Examples:•OS Files or Directories•DB Columns, Rows, Tables, or Views•Printer•Disk Space•Lock Mechanisms

RBAC will deal with all the objects listed in the permissions assigned to roles.

ROLESROLES

Developer Budget Manager

Help Desk Representative

An organizational job function with a clear definition of inherent responsibility and authority (permissions).

Director

Many-to-many relation betweenUsers & Permissions

OPS (operations)OPS (operations)

An execution of an a program specific function that’s invocated by a user.

Examples:Object – Operations ….•Database – Update Insert Append Delete •Locks – Open Close•Reports – Create View Print•Applications - Read Write Execute

SQL

PRMS (permissions)PRMS (permissions)The set of permissions that each grant the approval to perform an operation on a protected object.

User.DB1•View•Update•Append

permissions object

User.F1•Read•Write•Execute

permissions object

Perms ⊆ 2 OBJ x ACTIONS

Some Notation: Four PredicatesUA(u,r): says that user u is assigned to

role r.PA(r,(op,ob)): says that role r is permitted

to execute operation op on object ob.user-session(u,s): says that user u has

opened session s.session-role(s,r): iff says that some user

has invoked the role r within session s.

Constraint Components - 1Constraint Components - 1

Role HierarchiesRole HierarchiesBased on role inheritance.Based on role inheritance.RR11 is a senior to R is a senior to R22 (written R (written R1 1 >> R R22 ) iff ) iff

All permissions assigned to RAll permissions assigned to R22 are available to are available to

RR11..

>> is a partial order on the set of roles is a partial order on the set of roles

Some Consequences

UA(u,r1) and r1 > r2 UA(u,r2)

PA(r2,(ob,op)) and r1 > r2 PA(r2,(ob,op))

session-role(s,r1) and r1 > r2 session-role(s,r1)

Role Hierarchy & ConstraintsRole Hierarchy & Constraints

user_sessions

(RH)Role Hierarchy

session_roles

(UA)User Assign-

ment

(PA)PermissionAssignment

USERS OBSOPS

SESSIONS

ROLES

PRMS

SSD

DSD

Separation of Duty Constraints

Two kinds:Static separation of dutyStatic separation of duty

Determined when users are assigned to rolesAffects the UA(user,role) predicate

Dynamic separation of dutyDynamic separation of dutyConstraints the roles invoke-able by a userAffects the session-role(session,role)

predicate directly, and consequently the permissions available to a user.

Specifying ConstraintsstaticConflict(r1,r2): says that roles r1 and r2

have a staticstatic conflictconflict Implying that they should not be assigned

to the same userdynamicConflict(r1,r2): says that roles r1

and r2 have a dynamicdynamic conflictconflict Implying that they should not be invoked in

the same session by the same userThe same user may invoke roles r1 and r2 in

different sessions!

A Hierarchy of RBAC Models A Hierarchy of RBAC Models

ModelsModels HierarchiesHierarchies ConstraintsConstraints

RBACRBAC00 NoNo NoNo

RBACRBAC11 YesYes NoNo

RBACRBAC22 NoNo YesYes

RBACRBAC33 YesYes YesYesMost

Complex

Least PrivilegedSeparation of

Duties

RBAC Model

Effort

RBAC3

RBAC System and Administrative RBAC System and Administrative Functional SpecificationFunctional Specification

Administrative OperationsAdministrative Operations Create, Delete, Modify and Maintain elements and Create, Delete, Modify and Maintain elements and

relations of the RBAC modelrelations of the RBAC model Administrative ReviewsAdministrative Reviews

Query operationsQuery operations System Level Dynamic FunctionsSystem Level Dynamic Functions

Creation of user sessionsCreation of user sessions Role activation/deactivationRole activation/deactivation Constraint enforcementConstraint enforcement Computing Access DecisionsComputing Access Decisions

UA (user assignment)UA (user assignment)

A user can be assigned to one or more roles

Developer

USERS set ROLES set

Help Desk RepA role can be assigned to one or more users

UA UA ⊆ Users X Roles:⊆ Users X Roles:Example:Example: UA(Alice, Developer), UA(Bob, Help Desk Rep)

UA (user assignment)UA (user assignment)

SUSERSxROLEUA

}),(|{)(_ UAruUSERSuruserassigned

Mapping of role r onto a set of users

User.DB1•View•Update•Append

USERS setROLES set

User.DB1

User.DB1permissions

object

User.F1User.F2User.F3

assigned_user(r) gives the set of users assigned to the role rassigned_user(r)={u:UA(u,r)}assigned_user: ROLES 2USERS

PA (perms assignment)PA (perms assignment)

A perms can be assigned to one or more roles

Admin.DB1

PRMS set ROLES set

A role can be assigned to one or more perms

User.DB1

ViewUpdateAppend

CreateDeleteDrop

PA ⊆ USERS x Permissions

PA (perms assignment)PA (perms assignment)

SUSERSxROLEUA

PRMS setROLES set

User.F1User.F2User.F3Admin.DB1

Mapping of role r onto a set of permissions

•Read•Write•Execute

•View •Update•Append•Create•Drop

SQL

assigned_permissions(r) gives the set of permissions assigned to role rassigned_permissions(r) = {p : PA(r,p)}assigned_permissions: ROLES 2 PERMS

PA (perms assignment)PA (perms assignment)

SUSERSxROLEUA

PRMS setOPS set

Mapping of operations to permissions

public int read(byteBuffer dst) throws IOException

Inherited methods from java.nio.channlsclose()isOpen()

READ

Gives the set of operations associated with the permission. Namely, those that have the permission!

op(p: PERMS) {op∈ OPERATION: p=(obj,op)}

PA (perms assignment)PA (perms assignment)Mapping of permissions to objects

PRMS set

•Open•Close

•View •Update•Append•Create•Drop

SQL

DB1.table1

Objects

BLD1.door2

Gives the set of objects with the permission

ob(p: PERMS) {ob∈ OBJECT: p=(obj,op)}

SESSIONSSESSIONSThe set of sessions that each user invokes.

USER guest

user

admin

invokes

SQL

DB1.table1

FIN1.report1

APP1.desktop

SESSION

SESSIONSSESSIONS

)),(_(|{)(_

2):(_

UArsuserssessionROLESrsrolessession

SESSIONSsrolessession

ii

ROLES

The mapping of user u onto a set of sessions.

USERS

guest

user

admin

invokes SQL

User2.DB1.table1.session

User2.FIN1.report1.session

User2.APP1.desktop.session

SESSION

USER2

USER1

user_sessions(u: USERS) 2SESSIONS

SESSIONSSESSIONS

PRMSSESSIONSspersmsessionavail 2):(__

)),(_(|{)(_

2):(_

UArsuserssessionROLESrsrolessession

SESSIONSsrolessession

ii

ROLES

The mapping of session s onto a set of roles

SESSION ROLES

•Admin•User•Guest

SQL

DB1.table1.session

session_roles(s:SESSION)2ROLE

session_role(s) ={ r ROLE: session_user(s) UA}∈ ∈

SESSIONSSESSIONS

Permissions available to a user in a session.

DB1.ADMIN

•View •Update•Append•Create•Drop

SQL

DB1.table1.session

PRMSROLE SESSION

avail_session_perms(s) gives the set of permissions available to a user within a sessionavail_session_perms(s) = ⋃ {assigened_perms(r) :

r ∈session_roles(s)}

Hierarchal RBACHierarchal RBAC

user_sessions

(RH)Role Hierarchy

session_roles

(UA)User Assignment

(PA)PermissionAssignment

USERS OBSOPS

SESSIONS

ROLES

PRMS

Tree HierarchiesTree Hierarchies

ProductionEngineer 1

Engineer 1

Quality Engineer 1

Engineering Dept

ProductionEngineer 2

Engineer 2

Quality Engineer 2

ProductionEngineer 1

Project Lead 1

Quality Engineer 1

Director

ProductionEngineer 2

Project Lead 2

Quality Engineer 2

Lattice HierarchyLattice Hierarchy

ProductionEngineer 1

Engineer 1

Quality Engineer 1

Engineering Dept

ProductionEngineer 2

Engineer 2

Quality Engineer 2

Project Lead 1

Director

Project Lead 2

RH (Role Hierarchies)RH (Role Hierarchies) Natural means of structuring roles to reflect Natural means of structuring roles to reflect

organizational lines of authority and organizational lines of authority and responsibilitiesresponsibilities

General and Limited General and Limited Define the inheritance relation among rolesDefine the inheritance relation among roles

i.e. ri.e. r11 inheritsinherits rr22

Userr-w-h

Guest-r-

< ⊆ ROLES x ROLES

Authorized UsersAuthorized UsersMapping of a role onto a set of users in the presence of a role hierarchy

}),(|{)(_ UAruUSERSuruserassigned

User.DB1•View•Update•Append

First Tier USERS setROLE set

User.DB2

User.DB1

permissions

objectsAdmin.DB1User.DB2User.DB3

authorized_users(r)= {u∈USRES : r’>r and (u,r’) UA}∈

Authorized PermissionsAuthorized PermissionsMapping of a role onto a set of permissions in the presence of a role hierarchy

SUSERSxROLEUA

PRMS setROLES set

User.DB1User.DB2User.DB3Admin.DB1

•View•Update•Append

•Create•Drop

SQL

authorized_permissions: ROLE 2 PERMS

authorized_permissions(r)={p∈PERMS: r’>r and (p,r) PA}∈

General RHGeneral RH

Userr-w-x

Guest-r-

Only if all permissions of r1 are also

permissions of r2

Only if all users of r1 are also users of r2

i.e. r1 > r2

Guest Role Set

Power User Role Set

User Role Set

Admin Role Set

Support Multiple Inheritance

r1 > r2 authorized_users(r2) ⊆ authorized_users(r1) r1 > r2 authorized_permissions(r2)

⊆ authorized_permissions(r1)

Limiting InheritanceLimiting InheritancePlaces restrictions on the immediate descendants of roles in a role hierarchy: Example: No role can inherit from Role 1 and Role 2

Role 3

Role 1

Role 2

Role 2 may inherits from Role 1Role 3 does not inherit from Role1 and Role 2

┓[ ∃ r ∈ ROLES r’ < r1 and r < r2 ]

Limiting the Role HierarchyLimiting the Role Hierarchy

Tom

AcctRec

AcctRecSpv

Accounting

Tammy

Cashier

CashierSpv

Fred

Sally

Auditing

Joe Frank

Billing

BillingSpv

Curt Tuan

Accounting Role

Frank has two roles: Billing and CashierThis requires the union of two distinct roles and prevents Frank from being a node to others

Constrained RBACConstrained RBAC

user_sessions

(RH)Role Hierarchy

session_roles

(UA)User Assign-

ment

(PA)PermissionAssignment

USERS OBSOPS

SESSIONS

ROLES

PRMS

SSD

DSD

Separation of DutiesSeparation of Duties

Enforces conflict of interest policies employed to Enforces conflict of interest policies employed to prevent users from exceeding a reasonable level prevent users from exceeding a reasonable level of authority for their position.of authority for their position.

Ensures that failures of omission or commission Ensures that failures of omission or commission within an organization can be caused only as a within an organization can be caused only as a result of collusion among individuals.result of collusion among individuals.

Two TypesTwo Types:: Static Separation of Duties (Static Separation of Duties (SSoDSSoD)) Dynamic Separation of Duties (Dynamic Separation of Duties (DSoDDSoD))

SSoD: Static Separation of DutySSoD: Static Separation of Duty SSoD places restrictions on the set of roles and in SSoD places restrictions on the set of roles and in

particular on their ability to form particular on their ability to form UAUA relations. relations. No user is assigned to No user is assigned to nn or more roles from the or more roles from the

same role set, where same role set, where nn or more roles conflict with or more roles conflict with each other.each other.

A user may be in one role, but not in another—A user may be in one role, but not in another—mutually exclusive.mutually exclusive.

Example: Prevents a person from submitting and Prevents a person from submitting and approving their own request for a pay hike.approving their own request for a pay hike.

Specification: SSoD(rSet: 2SSoD(rSet: 2ROLESROLES,n:Integer) ,n:Integer) satisfying the conditionsatisfying the condition ∩∩{r⊆rSet and |r| > n} {r⊆rSet and |r| > n} authorized_users(r)=Øauthorized_users(r)=Ø

Properties of SSoDProperties of SSoD

A constraint on authorized users of the roles that A constraint on authorized users of the roles that have an SSD relation.have an SSD relation.

Based on Based on authorized users rather than assigned authorized users rather than assigned usersusers..

Ensures that inheritance does not undermine SSD Ensures that inheritance does not undermine SSD policies.policies.

Reduce the number of potential permissions that Reduce the number of potential permissions that can be made available to a user by placing can be made available to a user by placing constraints on the users that can be assigned to a constraints on the users that can be assigned to a set of roles.set of roles.

DSoD: Dynamic Separation of DutyDSoD: Dynamic Separation of Duty Places constraints on the users that can be assigned to Places constraints on the users that can be assigned to

a set of roles, thereby reducing the number of potential a set of roles, thereby reducing the number of potential permissions permissions that can be made available to a user at any that can be made available to a user at any given timegiven time..

Constraints can be Constraints can be across or within a user’s sessionacross or within a user’s session. . No user may activate No user may activate nn or more roles or more roles from the roles set from the roles set

in each user sessionin each user session.. Note:Note: timely revocation timely revocation of role assignment will ensures of role assignment will ensures

that permissions do not persist beyond the time that that permissions do not persist beyond the time that they are required for performance of duty.they are required for performance of duty.

Formalizing DSoDFormalizing DSoD DSoD(rSet: 2DSoD(rSet: 2ROLEROLE,n:Integer),n:Integer) ∀ rSet ⊆ ROLE n∀ ∈Integer s Session rS ∀ ∈ ∀ ⊆

ROLE

n > 2 and DSoD(rSet,n), rS rSet, rS ⊆ ⊆session_role(s) |rS| < n

Says that every subset rS of the set of active roles in session s must have size < n.

Specifies session specific DSoD

DSoDDSoD

Supervisor

Roles

inherits

Cashier

CashierCorrect Error

Supervisor

Closes Cashier Role sessionClose Cash Drawer

Opens Supervisory Role sessionOpen Cash Drawer

Accounting Error

ReduceCOI

Role-Based Access ControlRole-Based Access Control

user_sessions

(RH)Role Hierarchy

session_roles

(UA)User Assign-

ment

(PA)PermissionAssignment

USERS OBSOPS

SESSIONS

ROLES

PRMS

SSD

DSD

Specifying Pre and Post-Conditions

Consider an RBAC system with the following operations:

invokeRole(u:USER, s:Session, r:ROLE)rescendRole(u:USER, s:Session, r:ROLE)

Maintain Tables (Predicates)

Users, Roles, Permissions, UA, PA, US, SR

Specifying Pre and Post-Conditions

Operations: invokeRole(u:USER, s:Session, r:ROLE) rescendRole(u:USER, s:Session, r:ROLE)

Maintain Tables (Predicates): User(u), Roles(r), Perms(p), Session(s) UA(u:USER, r:ROLE), PA(r:ROLE,p:Perms) US(u:USER, s:Session), SR(s:Session,r:ROLE) SSoD(rs:2ROLE,n:Int), DSoD(rs:2ROLE,n:Int)

Pre-Conditions for invokeRoleinvokeRole(u:USER, s:Session, r:ROLE) Steps:1. Check if u, s, and r already exists u USER /\ s ∈ ∈USER /\ s ∈ ∈

SESSION /\ r ROLE∈SESSION /\ r ROLE∈2. Check if US(u,s): US(u,s)

3. Check static conditions:

1. UA(u,r) exists: UA(u,r)

4. Check if invoking r would violate DSoD

DSoD(rSet,n), rS rSet, rS session_role(s) ⊆ ⊆DSoD(rSet,n), rS rSet, rS session_role(s) ⊆ ⊆ |rS| < n |rS| < n

Post-Conditions for invokeRole

invokeRole(u:USER, s:Session, r:ROLE) Steps:

1. Update US, SR:

SR’ = SR U {(s,r)}