isa 562 information security theory and practice role-based access control
TRANSCRIPT
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