CECS694 Injecting RoleBased Access Control RBAC to secure a Webbased CSULB Workflow System Final Pre

1
CECS-694 Injecting Role-Based Access Control
(RBAC) to secure a Web-based CSULB Workflow
System(Final Presentation)
CSULB Fall 2009

• Arthur Melnikov

2
Current CSULB Security WEB Design
Is it possible for attacker retrieve the list of
PWs and USERs info from Application
Databases? Answer YES
Hacker Attack
gt then 40 thousand users in CSULB
3
New CSULB Security WEB Design
Is it possible for attacker retrieve the list of
PWs and USERs info from Application
Database? Answer only for NONE CSULB users
Hacker Attack
4
Domain Organizational Units
I counted 123 departments in CSULB
5
Role-Based Access Control
User Role - Permission relationship assignments
can be organized by two Boolean matrices UR
(USERS X ROLES) PR (PERMISSIONS X ROLES)
defined as ?UR u, r true ? u ? r ? ?PR p,
r true ? p ? r
6
RBAC Privilege

• Roles are built based on principle of least
  privileged
• Role contains the minimum amount of permissions
  to instantiate a domain
• User is assigned to a role that allows to
  perform only whats required for that role
• No single role is given more permission than
  the same role for another user

7
Role Organizational Units
CSULB Users (around 50000)
Roles (around 100)
Resources ( will grow)
Users can change frequently, Roles usually dont
8
Role-Based Administration
In RBAC the concept of a session refers to the
mapping between a user and an activated subset of
roles that are assigned to the user. Each user
can be associated with one or more sessions at a
time.
9
SESSION ALGORITHMS
This algorithm let to create a new session with a
given user as owner and an active role set. The
algorithm is valid if and only if - user is a
member of the USERS data set. - active role set
is a subset of the roles assigned to that user.
10
SESSION ALGORITHMS (cont.)

• This algorithm let to delete a given session with
  a given owner user. The algorithm is valid if and
  only if
• session identifier is a member of the SESSIONS
  data set.
• user is a member of the USERS data set.
• session is owned by the given user.

11
Functional Role Hierarchy
Defined as RH ? ROLES X ROLES is inheritance
relation (?) where r1 ? r2 only if all privileges
of r2 are also permissions of r1, and all users
of r1 are also users of r2 r1 ? r2 ?
authorized_permissions(r2) ? authorized_permission
s(r1) ? authorized_users(r1) ? authorized_users(r2
)
12
Functional Role Hierarchy (cont.)
If a role A inherits role B, it means that all of
B permissions are available via role A.
13
Constraints
Conflict of interest in RBAC mechanism may
appear as a result of a user gaining
authorization for permissions associated with
conflicting roles. I am going to prevent this
form of conflict of interest is through Static
Separation of Duty (SSD) or Dynamic Separation of
Duty (FSD), that enforce constraints on the
assignment of users to roles or sessions to
roles.
14
Why Using Constraints?

• For laying out higher level organization policy
• A good tool for convenience and error checking
  when administration is centralized
• A good tool to enforce high-level policies when
  administration is decentralized

15
Separation of Duties

• Enforces conflict of interest policies to prevent
  users from exceeding a reasonable level of
  authority for their position.
• Ensures that failures within university can be
  caused only as a result of collusion among
  individuals.
• Reduces chances of fraud
• Spreads critical duties across roles and in turn
  users
• Two Types
• Static Separation of Duties (SSD)
• Dynamic Separation of Duties (DSD)

16
Conflict of Interest

• Static Separation of Duty user cannot be
  authorized for both roles, e.g., Student and
  Department Chair
• SSD policies placing constrains on administrative
  actions and thereby restricting combinations of
  privileges that are made available to users.
• Dynamic Separation of Duty user cannot act
  simultaneously in both roles, e.g., Graduate
  Advisor and Professor
• DSD policies placing constrains on the roles that
  can be activated in any given session thereby
  restricting combinations of privileges that are
  made available to user

17
Static Separation of Duty

• Responsibilities split to prevent collusion
• Group of roles are mutually exclusive of one
  another with regard to authorization
• User may only be authorized to one

18
Static Separation of Duty (cont.)

• SSD places restrictions on the set of roles and
  in particular on their ability to form UA
  relations.

19
Static Separation of Duty (cont.)

• 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 another -
  mutually exclusive.
• Prevents a person from submitting and approving
  their own request.

Formal definition If static separation is
required for any pair of roles r1 and r2, then r1
and r2 can have no common assigned users.
20
SSD in Presence of RH

• A constraint on the authorized users of the roles
  that have an SSD relation.
• Based on the 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.

21
Separation of Duty Hierarchical Consistency

• Separation of duty relationship cannot exist
  between roles that have a containment relation
  between them or are contained by another role in
  common.

C

• ltA,Bgt is a member of SSD
• But since C inherits both A and B, ltA,Bgt is no
  longer a member of SSD

A
B
22
Separation of Duty Hierarchical Inheritance

• If one role contains another role that has an
  Separation of Duty relationship with a third
  role, then the containing role also has an SD
  relationship with the third role

A
If ltB,Cgt is a member of SSD, and A inherits B,
then ltA,Cgt is also a member of SSD
C
B
23
Dynamic Separation of Duty

• DSD relations place constraints on the roles
  that can be activated in a users session. If one
  role that takes part in a DSD relation is
  activated, the user cannot activate the related
  (conflicting) role in the same session

24
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.
• No user may activate n or more roles from the
  roles set in each user session.
• Timely revocation of Trust ensures that prms do
  not persist beyond the time that they are
  required for performance of duty.
• Constraints are across or within a users
  session.

25
Dynamic Separation of Duty (cont.)
Formal definition If dynamic separation is
required for any pair of roles r1 and r2, then r1
and r2 can have no common authorized users.
No user can belong to two particular roles during
the same session. E.g. a user could never be both
a Professor and a Department Chair at the same
time.
26
DSD example

• A user may be authorized for both the roles of
  Professor and Department Chair, where the
  Department Chair is allowed to acknowledge
  corrections to a Professors extended students to
  class.
• If the individual acting in the role Professor
  attempted to switch to the role Department Chair,
  RBAC would require the user to drop the Professor
  role, and thereby force the closure of the
  extended student enrollment before assuming the
  role Department Chair.
• As long as the same user is not allowed to
  assume both of these roles at the same time, a
  conflict of interest situation will NOT arise.
  This can be achieved through the establishment of
  a static separation of duty (SSD) relationship,
  but DSD relationships generally provide the
  enterprise with greater operational flexibility.

27
DSD example (cont.)
Roles
inherits
Reduce Issues
Professor
Department Chair
Closes Professor Role session Close Extended
Student Enrollment Opens Department Chair Role
session Open Extended Student Enrollment
Department Chair
Professor
Professor makes error that Department Chair must
correct
28
RBAC Transition
Least Privileged Separation of Duties
Most Complex
29
RBAC Administration Tool
Resources
30
Implementation Example
User admin_at_csulb.edu has the System Admin
privileges only for Child Development Family
Studies department domain http//cdfs.csulb.edu
31
Conclusion

• RBAC is a great defense in depth model
• RBAC requires policy to be clearly defined before
  implementation
• RBAC does reduce system administration duties
  once implemented
• RBAC improves workflow system auditing and
  facilitates separation of duties
• An implementation standard is required before
  RBAC can fully realize its potential as a
  approach to defense-in-depth

32
Thank you!Questions?