140 likes | 389 Views
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 (chandramouli@nist.gov). Presented by Brett Ford ( gtg309v@mail.gatech.edu ). Some Info about me.
E N D
Business Process Driven Framework for defining an Access Control Service based on Roles and Rulesby Ramaswamy ChandramouliComputer Security Division, ITLNIST, Gaithersburg, MD 20899(chandramouli@nist.gov) Presented by Brett Ford (gtg309v@mail.gatech.edu)
Some Info about me • Name: Brett Ford • Major: Computer Science (that’s a shocker) • Class: 4th year senior • Any other questions? Didn’t think so. • On to the paper…
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).
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)
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.
Processing Steps in BPD-ACS • Identify business processes, as well as their supporting information objects and methods. Output: application operations • Determine Access control requirements, driven by enterprise access control policies. Output: privileges and constraints • Map the user-privilege associations using the RBAC model based on findings from Step 2. • Formulate set of Access Decision Rules using constraints. This data is housed in a Temporal Business Association Database. • Define Access Enforcement Mechanism based on the access service components from Step 3 and Step 4.
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
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
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
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)
Defining the Access Enforcement Mechanism (Step 5) • Logical sequence of steps involved in arriving at an access decision for a given access request.
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?