An Attribute Graph Based Approach to Map Local Access Control Policies to Credential Based Access Control Policies Janice Warner and Vijayalakshmi Atluri Rutgers University Ravi Mukkamala Old Dominion University ICISS December 2005

ICISS05-Warner, Atluri and Mukkamala 2 Objective Map local RBAC policies to credential requirements for collaborations. Project Manager Role Subjects Privilege Credential Attributes: -Project management certified -Project Team member -5+ years of experience

December 2005ICISS05-Warner, Atluri and Mukkamala 3 Why? Today’s collaborations among organizations are increasingly Short-lived Dynamic Ad-hoc Need access control that is dynamic and efficient for such an environment Our proposal allows users, external to the organization, access to resources if they possess certain attributes similar to those possessed by internal users.

December 2005ICISS05-Warner, Atluri and Mukkamala 4 Two Alternatives Translate all collaborators policies into a common model Difficult Not dynamic Requires centralized processing Make policies interpretable with distributed control – what we are striving for

December 2005ICISS05-Warner, Atluri and Mukkamala 5 Extracting Policies Has Other Applications Web Service Offers Grid Computing Privacy and Security Legislation Compliance Role Mining

December 2005ICISS05-Warner, Atluri and Mukkamala 6 Outline Collaborative Sharing Model Motivating Example Policy Transformation Steps Conclusions and Future Work

December 2005ICISS05-Warner, Atluri and Mukkamala 7 What is a collaboration or coalition? Group of independent entities that have resources they are willing to share under certain conditions. Dynamic and Ad-hoc – members may leave and new members may join. Examples: Natural Disaster: government agencies, non- government organizations and private organizations may share data about victims, supplies and logistics. Homeland Security: Information collected by various governmental agencies shared for comprehensive data mining Virtual Enterprises: Collaboration between companies B P V Y G P – Y P – V – B P – B – G

December 2005ICISS05-Warner, Atluri and Mukkamala 8 Dynamic Coalition-Based Access Control Model (DCBAC) Dynamic because: Employs a Coalition Service Registry (CSR) where shared resources and coalition level policies are publicized Agreements do not need to established between coalition partners beforehand Computes credentials needed by external user from local access control policies through Mapper layer. Coalition access control policy determined through transformation of local access control policy Any resource could be shared at any time as long as the external party has the right credentials.

December 2005ICISS05-Warner, Atluri and Mukkamala 9 Principals of DCBAC Existing access control mechanisms within each coalition entity remain intact. Access rights are granted to subjects only if they belong to an organization recognized by the coalition. Subjects of a coalition entity must have credentials with attribute values comparable to those of local subjects.

December 2005ICISS05-Warner, Atluri and Mukkamala 10 Network (e.g., Internet) DCBAC Architecture Local User Interface Local Access Control (LAC) Credential to LAC Mapper Credential Filter Local User Interface Local Access Control (LAC) Credential to LAC Mapper Credential Filter Coalition Level Local Services (shared and private) Local Services (shared and private) Coalition Service Registry (CSR) Coalition Access Point (CAP)

December 2005ICISS05-Warner, Atluri and Mukkamala 11 Motivating Example Consider HapSys, a software development company. They have parameterized roles allowing separation of permissions by client and/or project. One client, SkyCo would like to allow members from a third organization, Test-it-Sys, to review test results for project “Blue Skies”. HapSys allows this if a user from Test-it-Sys can provide appropriate credentials.

December 2005ICISS05-Warner, Atluri and Mukkamala 12 Motivating Example Reqts Analyst SW DeveloperSystem Tester Project Manager Client Manager Reqts Analyst- SkycoSW Developer - SkyCoSystem Tester-SkyCo Project Manager – Code RedProject Manager – Blue Skies Client Manager - SkyCo

December 2005ICISS05-Warner, Atluri and Mukkamala 13 Policies Set on Resource Types Project Data (res_id=700) Testing Methods (res_id=510) Code Red (res_id=730) …… … Technology Reports (res_id=500) HapSys Resource Hierarchy Lab Configuration (res_id= 514) … Blue Skies (res_id=710) (res_id = 517) Test Case Library ProjectPlan (res_id = 722) Test Results (res_id = 729) Market Data (res_id = 731) Requirements (res_id = 735)

December 2005ICISS05-Warner, Atluri and Mukkamala 14 User Attributes (A) Assume each user is associated with a set of attributes Identifier Attributes (IA) – one to one correspondence between the attribute value and a user (e.g., address) General Attribute (GA) – one to many correspondence between the attribute value and a set of users (e.g., academic degree) Local Attribute (LA) – any general attribute for which values are valid only within an organization (e.g., department) A = IA  LA  GA

December 2005ICISS05-Warner, Atluri and Mukkamala 15 Policy Transformation Steps 1.Identify potential required attributes to obtain privilege. 2.Apply selection strategies to select a subset of the identified attributes. 3.Transform LA and IA (if they were selected) into comparable credential attributes.

December 2005ICISS05-Warner, Atluri and Mukkamala 16 Step 1 – Build Attribute Graph Used to determine sets of user attributes (and values) that might be associated with a privilege Assumes specific order among attributes GA > LA > IA Graph may be a forest Stores attributes as nodes, number of users as weights, and attribute values as node labels.

December 2005ICISS05-Warner, Atluri and Mukkamala 17 Step 2 – Attribute Selection Conservative Strategy: Require full collection of attributes held by all users assigned to role r with privilege p. Greater requirement than any single internal user and would likely result in no external user gaining access.

December 2005ICISS05-Warner, Atluri and Mukkamala 18 Step 2 – Attribute Selection Largest Attribute Group Strategy: Uses attribute graph – Each path from root to leaf in any tree T  AG represents the full set of attributes of one or more users in U. Longest path would have the next most conservative attribute requirement that is actually held by one or more users. But the longest path might be an exception – so may not be the best choice.

December 2005ICISS05-Warner, Atluri and Mukkamala 19 Step 2 – Attribute Selection Typical Profile Strategy: Uses weights of attribute graph. Attributes chosen based on perceived importance of a user attribute. Attributes are considered critical if the weight of the attribute is greater than , a settable parameters. If more than one path in AG has nodes with weights greater or equal to , the sets of attributes in each path can be considered as a set of alternative attribute requirements.

December 2005ICISS05-Warner, Atluri and Mukkamala 20 Example Attribute Selection Suppose SkyCo asks Ellen Jones of Test-it-Sys to review the test results for project Blue Skies (red_id = 729) Attributes selected if largest attribute group strategy used Attributes selected if typical profile strategy used with  =.5 x U p = 5.

December 2005ICISS05-Warner, Atluri and Mukkamala 21 Step 3 – Transformation of Attributes General attributes are attributes that can be held by any individual (inside or outside the organization) No transformation may be necessary But, may have problem of semantics Translation could be done using a terminological ontology. Attribute Ontology Credential Attribute Base Internal Attribute Base

December 2005ICISS05-Warner, Atluri and Mukkamala 22 Step 3 – Transformation of Attributes Three options exist for transforming identity and local attributes into general attributes: 1.Require attribute – External users may be required to present an id or group attribute of the correct form, but with no particular values. Any value in a valid credential would be accepted and stored (for audit or to build up an ontology). 2.Modify attribute – External users would be required to present an identity attribute for someone or something else, such as the person who delegated rights to them or the organization to which they belong. 3.Ignore attribute – Make privilege decision only on the basis of other attributes in selected set.

December 2005ICISS05-Warner, Atluri and Mukkamala 23 Conclusions Proposed an attribute graph based approach to enable secure sharing of information in a collaboration. Ensures that internal security policies are adhered to when providing access to users of external organizations. External users are provided access to resources if they possess attributes that are in some sense similar to those possessed by internal users.

December 2005ICISS05-Warner, Atluri and Mukkamala 24 Ongoing Work Data mining of logs, local policies, and other security related data to obtain: Groupings of users with similar data requirements and attributes Groupings of resources From these groupings, collaborative properties may be derived. Resolving semantic heterogeneity between policies and credential attributes using ontologies.