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 ([email protected])Some Info about mePaper IntroductionAbout BPD-ACSSimilar WorkProcessing Steps in BPD-ACSBusiness Processes in HLIS (Step 1)Mapping Security Policies to HLIS (Step 2)Defining Access Control Model (Step 3)Definition of Access Decision Rules (Step 4)(Step 4) continued…Defining the Access Enforcement Mechanism (Step 5)Furthermore…Business Process Driven Framework Business Process Driven Framework for defining an Access Control Service for defining an Access Control Service based on Roles and Rulesbased on Roles and Rulesby Ramaswamy Chandramouliby Ramaswamy ChandramouliComputer Security Division, ITLComputer Security Division, ITLNIST, Gaithersburg, MD 20899NIST, Gaithersburg, MD 20899([email protected])([email protected])Presented by Brett Ford (Presented by Brett Ford ([email protected]@mail.gatech.edu))Some Info about meSome 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 IntroductionPaper 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-ACSAbout 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:1. Privileges – application level operations a designated user is entitled to perform based on his/her job or role.2. Access Decision Rules – Restrictions on privileges based on environmental/contextual variables (i.e. app state, time of access)Similar WorkSimilar 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-ACSProcessing Steps in BPD-ACS1. Identify business processes, as well as their supporting information objects and methods. Output: application operations2. Determine Access control requirements, driven by enterprise access control policies. Output: privileges and constraints3. 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.Business Processes in HLIS (Step 1)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 ResultsMapping Security Policies to HLIS (Step 2)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 regulationsDefining Access Control Model (Step 3)Defining Access Control Model (Step 3)•Using the RBAC, there are 3 broad entities to consider:1. 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.2. 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.3. 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 resultsDefinition of Access Decision Rules (Step 4)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)(Step 4) continued…(Step 4) continued…Defining the Access Enforcement Mechanism Defining the Access Enforcement Mechanism (Step 5)(Step 5)•Logical sequence of steps involved in arriving at an access decision for a given access request.Furthermore…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