Business Process Driven Framework for defining an Access Control Service based on Roles and Rules by Ramaswamy Chandramouli Computer Security Division, ITL NIST, Gaithersburg, MD 20899 ([e-mail])

1
Business Process Driven Framework for defining an
Access Control Service based on Roles and
Rulesby Ramaswamy ChandramouliComputer Security
Division, ITLNIST, Gaithersburg, MD
20899(chandramouli_at_nist.gov)

• Presented by Brett Ford (gtg309v_at_mail.gatech.edu)

2
Some Info about me

• Name Brett Ford
• Major Computer Science (thats a shocker)
• Class 4th year senior
• Any other questions? Didnt think so.
• On to the paper

3
Paper Introduction

• Business Process Driven (BPD-ACS) framework used
  as the model for formulating access decision
  rules.
• BPD-ACS uses the Role Based Access Control (RBAC)
  model.
• Access Decision Rules formulated based on
  temporal business associations.
• Access control service defined for a
  multi-facility hospital application called
  Hospital-based Laboratory Information System
  (HLIS).

4
About BPD-ACS

• BPD-ACS defines service components through a
  top-down analysis of business processes of an
  application.
• Role Based Access Control (RBAC) chosen because
• Administrative convenience through concept of
  roles
• Support for RBAC available on many platforms
  (DBMSs and OSs)
• Two main facets of user-operation interactions
  governed by an Access Control Model
• Privileges application level operations a
  designated user is entitled to perform based on
  his/her job or role.
• Access Decision Rules Restrictions on
  privileges based on environmental/contextual
  variables (i.e. app state, time of access)

5
Similar Work

• Didriksen used a concept of fragments to define
  restrictions to accessing rows/columns in
  relational database tables.
• Limitation it can only be used for access
  control rules for data in relational database
  table.
• Guiri and Iglio proposed role templates with
  parameterized privileges.
• Limitation parameters in a role template are
  the same as those in each of the privileges they
  contain.
• The HP model used in HP Praesidium Authorization
  Server is more flexible by having rules defined
  independently of the roles.
• The Access Decision Rule approach discussed in
  the paper builds on the HP model.

6
Processing Steps in BPD-ACS

1. Identify business processes, as well as their
   supporting information objects and methods.
   Output application operations
2. Determine Access control requirements, driven by
   enterprise access control policies. Output
   privileges and constraints
3. Map the user-privilege associations using the
   RBAC model based on findings from Step 2.
4. Formulate set of Access Decision Rules using
   constraints. This data is housed in a Temporal
   Business Association Database.
5. Define Access Enforcement Mechanism based on the
   access service components from Step 3 and Step 4.

7
Business Processes in HLIS (Step 1)

• From analysis of commercial HLISs, business
  processes supported include
• Lab Order Entry, Lab Test Scheduling, Capture
  and Recording of Test Results, Quality Control
  checks on Test Results, Generation of Summary
  Reports, Retrieve/Access Test Results

8
Mapping Security Policies to HLIS (Step 2)

• Enterprise access control policy may be comprised
  of a combination of information categories.
• Enterprise best practices, threat model driven
  requirements, government regulations

9
Defining Access Control Model (Step 3)

• Using the RBAC, there are 3 broad entities to
  consider
• Privileges In the example of the Lab Order
  Entry business process there were a set of
  methods. If we decide user interactions with
  information objects will be through methods with
  no other lower level access, then methods
  themselves provide correct granularity for
  defining privileges.
• Roles Generally used to group privileges
  together based on job functions or business
  processes. A business process may require
  several privileges in itself, and so a business
  process may be used to define a role in such a
  case.
• User Entity generally used to group associated
  roles together with those categorized users of
  the application to which those roles pertain. In
  example, a User entity, say a Physician, may be
  associated with (a) examining patients (b)
  prescribing medicine (c) ordering clinical tests
  and analyzing the results

10
Definition of Access Decision Rules (Step 4)

• Access Decision Rules constrain the exercise of
  Privileges.
• Time/Day of Access Request (Time Constraints)
• History of previous accesses (Conflict of
  Interest Constraints)
• Trust Level of the User (Trust Constraints)
• Parameter Values Used in Access Request (Temporal
  Business Association Constraints)

11
(Step 4) continued
12
Defining the Access Enforcement Mechanism (Step 5)

• Logical sequence of steps involved in arriving at
  an access decision for a given access request.

13
Furthermore

• The Access Control Model itself can/may have
  constraints, i.e., the RBAC model could have
  constraints associated with user-role
  assignments, user-role activation, and
  privilege-role assignments.
• So, the overall concept is that these service
  component definitions should be based on a
  correct analysis of the business processes and
  their temporal business associations which are
  meant to be supported by the given application.
• Questions?