Title: ISA 562 Information Security Theory and Practice
1ISA 562 Information SecurityTheory and Practice
- Role-based Access Control
2References
- NIST documents at http//csrc.nist.gov/rbac/
- D. Ferraiolo, R. Sandhu, S. Gavrila, D.R. Kuhn,
R. Chandramouli, "A Proposed Standard for Role
Based Access Control (PDF)," ACM Transactions on
Information and System Security , vol. 4, no. 3
(August, 2001) - draft of a consensus standard
for RBAC. - The ARBAC97 model for role-based administration
of roles (1999)
3Discretionary AC
- Restricts access to objects based solely on the
identity of users who are trying to access them.
Application Access List
Legacy Apps
Name Access Tom Yes John No Cindy Yes
4Mandatory AC
- MAC mechanisms assign a security level to all
information, assign a security clearance to each
user, and ensure that all users only have access
to that data for which they have a clearance.
Principle Read Down Access
equal or less Clearance Write Up
Access equal or higher
Clearance
5Mandatory AC (cont)
Users
Resources
Server 1 Top Secret
Server 2 Secret
Server 3 Classified
6Role-Based AC
Individuals
Roles
Resources
Server 1
Server 2
Server 3
Users change frequently, Roles dont
7Role-Based AC
- A user has access to an object based on the
assigned role. - Roles are defined based on job functions.
- Permissions are defined based on authorities and
responsibilities of a job. - Operations on an object are invocated based on
the permissions.
8Role-Based AC Framework
- Core Components
- Constraining Components
- Hierarchical RBAC
- General
- Limited
- Separation of Duty Relations
- Static
- Dynamic
9Core Components
- Defines
- USERS
- ROLES
- OPERATIONS (ops)
- OBJECTS (obs)
- Permissions (operation, object) pairs
- User-to-Role Assignments (ua)
- assigned_users
- Sessions
10RBAC Core
11USERS
Process
- Processes
- Intelligent Agent
- mailer daemon
- A mal-ware process
12OBS (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.
13ROLES
An organizational job function with a clear
definition of inherent responsibility and
authority (permissions).
Director
Developer
Budget Manager
Many-to-many relation between Users Permissions
Help Desk Representative
14OPS (operations)
An execution of an a program specific function
thats invocated by a user.
- Examples
- Object Operations .
- Database Update Insert Append Delete
- Locks Open Close
- Reports Create View Print
- Applications - Read Write Execute
SQL
15PRMS (permissions)
The set of permissions that each grant the
approval to perform an operation on a protected
object.
Perms ? 2 OBJ x ACTIONS
16Some Notation Four Predicates
- UA(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.
17Constraint Components - 1
- Role Hierarchies
- Based on role inheritance.
- R1 is a senior to R2 (written R1 gt R2 ) iff
- All permissions assigned to R2 are available to
R1. - gt is a partial order on the set of roles
18Some Consequences
- UA(u,r1) and r1 gt r2 ? UA(u,r2)
- PA(r2,(ob,op)) and r1 gt r2 ? PA(r2,(ob,op))
- session-role(s,r1) and r1 gt r2 ?
session-role(s,r1)
19Role Hierarchy Constraints
20Separation of Duty Constraints
- Two kinds
- Static separation of duty
- Determined when users are assigned to roles
- Affects the UA(user,role) predicate
- Dynamic separation of duty
- Constraints the roles invoke-able by a user
- Affects the session-role(session,role) predicate
directly, and consequently the permissions
available to a user.
21Specifying Constraints
- staticConflict(r1,r2) says that roles r1 and r2
have a static conflict - Implying that they should not be assigned to the
same user - dynamicConflict(r1,r2) says that roles r1 and r2
have a dynamic conflict - Implying that they should not be invoked in the
same session by the same user - The same user may invoke roles r1 and r2 in
different sessions!
22A Hierarchy of RBAC Models
Least Privileged Separation of Duties
Models Hierarchies Constraints
RBAC0 No No
RBAC1 Yes No
RBAC2 No Yes
RBAC3 Yes Yes
Most Complex
RBAC3
Effort
RBAC Model
23RBAC System and Administrative Functional
Specification
- Administrative Operations
- Create, Delete, Modify and Maintain elements and
relations of the RBAC model - Administrative Reviews
- Query operations
- System Level Dynamic Functions
- Creation of user sessions
- Role activation/deactivation
- Constraint enforcement
- Computing Access Decisions
24UA (user assignment)
USERS set
ROLES set
A user can be assigned to one or more roles
Developer
A role can be assigned to one or more users
Help Desk Rep
UA ? Users X Roles Example UA(Alice,
Developer), UA(Bob, Help Desk Rep)
25UA (user assignment)
Mapping of role r onto a set of users
ROLES set
USERS set
User.F1 User.F2 User.F3
- User.DB1
- View
- Update
- Append
User.DB1
permissions
object
assigned_user(r) gives the set of users assigned
to the role r assigned_user(r)uUA(u,r) assigne
d_user ROLES ? 2USERS
User.DB1
26PA (perms assignment)
ROLES set
PRMS set
A perms can be assigned to one or more roles
Create Delete Drop
Admin.DB1
View Update Append
A role can be assigned to one or more perms
User.DB1
PA ? USERS x Permissions
27PA (perms assignment)
Mapping of role r onto a set of permissions
PRMS set
ROLES set
- Read
- Write
- Execute
- View
- Update
- Append
- Create
- Drop
SQL
User.F1 User.F2 User.F3 Admin.DB1
assigned_permissions(r) gives the set of
permissions assigned to role r assigned_permission
s(r) p PA(r,p) assigned_permissions ROLES
? 2 PERMS
28PA (perms assignment)
Mapping of operations to permissions
PRMS set
OPS set
- public int read(byteBuffer dst)
- throws IOException
- Inherited methods from java.nio.channls
- close()
- isOpen()
Gives the set of operations associated with the
permission. Namely, those that have the
permission!
op(p PERMS) ? op? OPERATION p(obj,op)
29PA (perms assignment)
Mapping of permissions to objects
Objects
PRMS set
- Open
- Close
- View
- Update
- Append
- Create
- Drop
BLD1.door2
SQL
DB1.table1
Gives the set of objects with the permission
ob(p PERMS) ? ob? OBJECT p(obj,op)
30SESSIONS
The set of sessions that each user invokes.
SESSION
USER
FIN1.report1
SQL
DB1.table1
APP1.desktop
31SESSIONS
The mapping of user u onto a set of sessions.
USERS
SESSION
User2.FIN1.report1.session
USER1
SQL
User2.DB1.table1.session
USER2
User2.APP1.desktop.session
user_sessions(u USERS) ? 2SESSIONS
32SESSIONS
The mapping of session s onto a set of roles
SESSION
ROLES
SQL
DB1.table1.session
session_roles(sSESSION)?2ROLE session_role(s)
r?ROLE session_user(s)?UA
33SESSIONS
Permissions available to a user in a session.
PRMS
ROLE
SESSION
- View
- Update
- Append
- Create
- Drop
avail_session_perms(s) gives the set of
permissions available to a user within a
session avail_session_perms(s) ?
assigened_perms(r) r ?session_roles(s)
34(RH) Role Hierarchy
(UA) User Assignment
(PA) Permission Assignment
USERS
OBS
OPS
ROLES
PRMS
user_sessions
session_roles
SESSIONS
Hierarchal RBAC
35Tree Hierarchies
Tree
Inverted Tree
36Lattice Hierarchy
37RH (Role Hierarchies)
- Natural means of structuring roles to reflect
organizational lines of authority and
responsibilities - General and Limited
- Define the inheritance relation among roles
- i.e. r1 inherits r2
Guest -r-
User r-w-h
x
lt ? ROLES x ROLES
38Authorized Users
Mapping of a role onto a set of users in the
presence of a role hierarchy
First Tier USERS set
ROLE set
Admin.DB1 User.DB2 User.DB3
objects
User.DB1
- User.DB1
- View
- Update
- Append
User.DB2
permissions
authorized_users(r) u?USRES rgtr and (u,r)
?UA
39Authorized Permissions
Mapping of a role onto a set of permissions in
the presence of a role hierarchy
PRMS set
ROLES set
- View
- Update
- Append
- Create
- Drop
SQL
User.DB1 User.DB2 User.DB3 Admin.DB1
authorized_permissions ROLE ? 2
PERMS authorized_permissions(r)p?PERMS rgtr
and (p,r) ?PA
40General RH
Guest Role Set
Support Multiple Inheritance
User Role Set
Power User Role Set
Admin Role Set
Only if all permissions of r1 are also
permissions of r2
i.e. r1 gt r2
Only if all users of r1 are also users of r2
User r-w-x
Guest -r-
r1 gt r2 ? authorized_users(r2) ?
authorized_users(r1) r1 gt r2 ?
authorized_permissions(r2) ?
authorized_permissions(r1)
41Limiting Inheritance
Places restrictions on the immediate descendants
of roles in a role hierarchy Example No role
can inherit from Role 1 and Role 2
Role 1
Role 2 may inherits from Role 1
Role 3 does not inherit from Role1 and Role 2
Role 2
Role 3
? ? r ? ROLES r lt r1 and r lt r2
42Limiting the Role Hierarchy
Accounting Role
Frank has two roles Billing and Cashier This
requires the union of two distinct roles and
prevents Frank from being a node to others
43Constrained RBAC
44Separation of Duties
- Enforces conflict of interest policies employed
to prevent users from exceeding a reasonable
level of authority for their position. - Ensures that failures of omission or commission
within an organization can be caused only as a
result of collusion among individuals. - Two Types
- Static Separation of Duties (SSoD)
- Dynamic Separation of Duties (DSoD)
45SSoD Static Separation of Duty
- SSoD places restrictions on the set of roles and
in particular on their ability to form UA
relations. - No user is assigned to n or more roles from the
same role set, where n or more roles conflict
with each other. - A user may be in one role, but not in
anothermutually exclusive. - Example Prevents a person from submitting and
approving their own request for a pay hike. - Specification SSoD(rSet 2ROLES,nInteger)
satisfying the condition - nr?rSet and r gt n ? authorized_users(r)Ø
46Properties of SSoD
- A constraint on authorized users of the roles
that have an SSD relation. - Based on authorized users rather than assigned
users. - Ensures that inheritance does not undermine SSD
policies. - Reduce the number of potential permissions that
can be made available to a user by placing
constraints on the users that can be assigned to
a set of roles.
47DSoD Dynamic Separation of Duty
- Places constraints on the users that can be
assigned to a set of roles, thereby reducing the
number of potential permissions that can be made
available to a user at any given time. - Constraints can be across or within a users
session. - No user may activate n or more roles from the
roles set in each user session. - Note timely revocation of role assignment will
ensures that permissions do not persist beyond
the time that they are required for performance
of duty.
48Formalizing DSoD
- DSoD(rSet 2ROLE,nInteger)
- ? rSet ? ROLE ?n?Integer ?s ? Session ? rS ? ROLE
- n gt 2 and DSoD(rSet,n), rS ? rSet, rS ?
session_role(s) ? rS lt n - Says that every subset rS of the set of active
roles in session s must have size lt n. - Specifies session specific DSoD
49DSoD
Reduce COI
50Role-Based Access Control
51Specifying Pre and Post-Conditions
- Consider an RBAC system with the following
operations - invokeRole(uUSER, sSession, rROLE)
- rescendRole(uUSER, sSession, rROLE)
- Maintain Tables (Predicates)
- Users, Roles, Permissions, UA, PA, US, SR
52Specifying Pre and Post-Conditions
- Operations
- invokeRole(uUSER, sSession, rROLE)
- rescendRole(uUSER, sSession, rROLE)
- Maintain Tables (Predicates)
- User(u), Roles(r), Perms(p), Session(s)
- UA(uUSER, rROLE), PA(rROLE,pPerms)
- US(uUSER, sSession), SR(sSession,rROLE)
- SSoD(rs2ROLE,nInt), DSoD(rs2ROLE,nInt)
53Pre-Conditions for invokeRole
- invokeRole(uUSER, sSession, rROLE)
- Steps
- Check if u, s, and r already exists u?USER /\ s ?
SESSION /\ r?ROLE - Check if US(u,s) US(u,s)
- Check static conditions
- UA(u,r) exists UA(u,r)
- Check if invoking r would violate DSoD
- DSoD(rSet,n), rS ? rSet, rS ?session_role(s)
? rS lt n
54Post-Conditions for invokeRole
- invokeRole(uUSER, sSession, rROLE)
- Steps
- Update US, SR
- SR SR U (s,r)