ISA 562 Information Security Theory and Practice - PowerPoint PPT Presentation

About This Presentation
Title:

ISA 562 Information Security Theory and Practice

Description:

ISA 562 Information Security Theory and Practice Role-based Access Control Hierarchal RBAC user_sessions (RH) Role Hierarchy session_roles (UA) User Assignment (PA ... – PowerPoint PPT presentation

Number of Views:167
Avg rating:3.0/5.0
Slides: 55
Provided by: Wilfredo7
Learn more at: https://cs.gmu.edu
Category:

less

Transcript and Presenter's Notes

Title: ISA 562 Information Security Theory and Practice


1
ISA 562 Information SecurityTheory and Practice
  • Role-based Access Control

2
References
  1. NIST documents at http//csrc.nist.gov/rbac/
  2. 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.
  3. The ARBAC97 model for role-based administration
    of roles (1999)

3
Discretionary 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
4
Mandatory 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
5
Mandatory AC (cont)
Users
Resources
Server 1 Top Secret
Server 2 Secret
Server 3 Classified
6
Role-Based AC
Individuals
Roles
Resources
Server 1
Server 2
Server 3
Users change frequently, Roles dont
7
Role-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.

8
Role-Based AC Framework
  • Core Components
  • Constraining Components
  • Hierarchical RBAC
  • General
  • Limited
  • Separation of Duty Relations
  • Static
  • Dynamic

9
Core Components
  • Defines
  • USERS
  • ROLES
  • OPERATIONS (ops)
  • OBJECTS (obs)
  • Permissions (operation, object) pairs
  • User-to-Role Assignments (ua)
  • assigned_users
  • Sessions

10
RBAC Core
11
USERS
Process
  • People
  • Alice
  • Bob
  • Cindy
  • Processes
  • Intelligent Agent
  • mailer daemon
  • A mal-ware process

12
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.
13
ROLES
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
14
OPS (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
15
PRMS (permissions)
The set of permissions that each grant the
approval to perform an operation on a protected
object.
Perms ? 2 OBJ x ACTIONS
16
Some 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.

17
Constraint 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

18
Some 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)

19
Role Hierarchy Constraints
20
Separation 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.

21
Specifying 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!

22
A 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
23
RBAC 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

24
UA (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)
25
UA (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
26
PA (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
27
PA (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
28
PA (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()
  • READ

Gives the set of operations associated with the
permission. Namely, those that have the
permission!
op(p PERMS) ? op? OPERATION p(obj,op)
29
PA (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)
30
SESSIONS
The set of sessions that each user invokes.
SESSION
USER
FIN1.report1
SQL
DB1.table1
APP1.desktop
31
SESSIONS
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
32
SESSIONS
The mapping of session s onto a set of roles
SESSION
ROLES
SQL
  • Admin
  • User
  • Guest

DB1.table1.session
session_roles(sSESSION)?2ROLE session_role(s)
r?ROLE session_user(s)?UA
33
SESSIONS
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
35
Tree Hierarchies
Tree
Inverted Tree
36
Lattice Hierarchy
37
RH (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
38
Authorized 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
39
Authorized 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
40
General 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)
41
Limiting 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
42
Limiting 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
43
Constrained RBAC
44
Separation 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)

45
SSoD 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)Ø

46
Properties 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.

47
DSoD 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.

48
Formalizing 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

49
DSoD
Reduce COI
50
Role-Based Access Control
51
Specifying 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

52
Specifying 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)

53
Pre-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

54
Post-Conditions for invokeRole
  • invokeRole(uUSER, sSession, rROLE)
  • Steps
  • Update US, SR
  • SR SR U (s,r)
Write a Comment
User Comments (0)
About PowerShow.com