Overview. Evolution of Access Control in Commercial Products. Access Control is Different from other Mechanisms. Security Policies

Transcription

1 Overview Evolution of Access Control in Commercial Products Policies, Models and Techniques David Ferraiolo National Institute of Standards and Technology Practical View of Evolution of Access Control Features Outline Era of Trusted Computer Security Evaluation Criteria The good and bad Emergence of RBAC A practical response to authorization management problems Enterprise Management Systems The Role Control Center A reference implementation of enterprise-wide RBAC features User Authorization In a computer system the access of users to data must be controlled in order to maintain the security of the enterprise or organization using the computer system Access control is performed by using access rights, that define whether and how a user may access data in the computer system Access control is performed by an access control mechanism, which is integrated in or added to the operating system of the computer system Access Control is Different from other Mechanisms Virtually every product and application includes access control features Although described in terms of constraints, access control facilitates sharing of information Need not be justified on perceived threats alone Strong economic arguments for better mechanisms Insider crime are the most costly Of all security features, authorization management is the most costly to administer Security Policies Policies deal with defining what is authorized and who can grant authorizations Adopted security policies are derived from an organization s business practices, such as legal requirements, regulatory requirements, user needs Policies are implemented by configuring access control data of an access control mechanism. Policies are enforced by the context offered by the access control mechanism Characterizing Access Control Mechanisms Defined by Policy Support, Scope of Control, and Attributes Single Policy, Class of Policies, Policy Neutral Discretionary and Non-discretionary controls Single Platform, Single Environment/Multiplatform, Fully Distributed Rules, Access Control Lists, Roles and Capabilities 1

2 Driving Forces Standards and Evaluation Criteria Availability of Access Control Models Architectural Changes Mainframe Client-Server Virtual Enterprise Economics Administrator Cost User Productivity Insider Crime The Era of The Trusted Computer Security Evaluation Criteria Late 60s & early 70s Two independent projects became one MAC Project Massachusetts Institute of Technology (MIT) Feasibility of security concepts Policy dictated by Department of Defense Security Criteria (metric to measure trust) MITRE contracted by NBS now NIST Late 60s & early 70s MITRE, MIT, Bell Labs and General Electric, Honeywell Multics Operating System Trusted Computer System Evaluation Criteria (TCSEC) Policy formalized by Bell-LaPadula Model TCSEC was finally published in 1983 Lampson s access-matrix model (1971) influenced mechanism The Anderson Report - underlying protection theory TCSEC Defines six levels of trust in terms of increasing security features and assurances Designed to protect classified information within a standalone Operating System environment Two types of access control: Discretionary and Mandatory Access Control (DAC & MAC) Later Interpreted for Networks (TNI) and DBMS (TDI) late 80s and early 90s Reference Monitor Abstraction that allows active entities called subjects to make reference to passive entities call objects, based on a set of current access authorizations Subject Reference Monitor object Auth. database 2

3 Strategy for Assurance Implementation Principles: Completeness: The RM must always be invoked and impossible to bypass considers types of objects Isolation: It must be tamper-proof security kernel, hardware support Verifiable: It must be shown to be properly implemented small and analyzable Policy Independent Mandatory Access Control Comparison of a subject s (process acting on user s behalf) security level and an object s (e.g., files) security level Comparison was based on the rules of the Bell & LaPadula security model Starting in the early 80s a number of operating systems were evaluated for compliance to MAC requirements None enjoyed much market success Information flow policies Addressed confidentiality requirements Assumes a lattice of security labels Every subject and object is assigned a security label using a security function λ Information can flow from an entity x to an entity y if λ(x) λ(y) Read and write access rights are defined in terms of information flow principles Read Access Information flow from an object o to a subject s Read access is granted if λ(o) λ(s) This condition is known as no read up and the simple security (ss) property in BLP terms Write Access Information flow from a subject s to an object o Write access is granted if λ(s) λ(o) This condition is known as no write down and the *-property in BLP terms No read-up and no write-down properties are mandatory access control properties of BLP Discretionary Security Policy Discretionary Security Property (ds-property) Access must be permitted by the access control matrix M so. 3

4 Access Control Matrix S set of subjects O set of objects A set of access operations Access control matrix: M = (M so ) s S,o O, M so A; M so specifies the operations subject s may perform on object o. Alice Bob bill.doc - {read,write} edit.exe {exec} {exec} fun.com {exec,read} {exec,read,write} Access Control Matrix ctd. The access control matrix is an abstract concept not very suitable for direct implementation The matrix is likely to be extremely sparse and therefore implementation is inefficient Capabilities Focus on the subject access rights are stored with the subject capabilities rows of the access control matrix Alice edit.exe: {exec} fun.com: {exec,read} Problems of capabilities How to check who may access a specific object? How to revoke a capability? Access Control Lists (ACLs) Focus on the object access rights are stored with the object ACLs columns of the access control matrix fun.com Alice: {exec} Bill: {exec,read,write} Access rights are often defined for groups of users because for individual subjects may create a huge list Problem: How to check and revoke access rights of a specific subject? Groups & Negative Permissions Groups are an intermediate layer between users and objects. users groups objects To deal with special cases, negative permissions withdraw rights users groups objects Discretionary Access Control The TCSEC C2 Class with DAC became the standard of Due Care among Banking and Financial Institutions From the Mid 80s through the Mid 90s virtually every major computer vendor had a product evaluated at the C2 level of the TCSEC Access Control Lists (ACLs) were endorsed became the most common mechanism for enforcing DAC and its need-to-know policy 4

5 Example DAC Products Access Control Lists VAX/VMS - Digital Equipment Corporation UTX/32S - Guild, Inc., Computer Systems Div. MCP/AS - UNISYS Corporation acf2/vm with IBM s VM/SP - Computer Associates VMS/XA with RACF - IBM Primos - Prime Computer MPE V/E - Hewlett Packard AOS/VS running on MV/ECLIPSE - Data General RACF with VMS - IBM ACF2 with VMS - Computer Associates Top Secret with IBM s VMS - CGA S/W Products Group Access Control List (ACL) are still the most common lower level access control mechanism in use today For each protected object (e.g., file) there is a specified list of users or groups of users along with an approved mode of access (e.g., read, write, control) End-users are viewed as owners of enterprise resources Resource Oriented: powerful in expressing discretionary need-toknow policies Operating System dependent ACL Administration System Administrator Object owners U14, U79, U63 G3 G12... G6 Obj1: G3,r; G12r,x; 4:c Obj4: G5:r; u79:r,w; u63:c... Obj1005: G12:r... The Emergence of Role-Based Access Control Computer System NIST Study 1990 Interviewed 30 large organizations Each organization had its own access control policies Most policies are non-discretionary These policies did not map to MAC mechanisms Most organizations define policy based on the functions performed by their users Organizations view themselves as owners of their information Least privilege is considered important although the practice of cloning is wide spread Administrative Challenges of the late 80s and 90s Tens if not hundreds of thousands of users, and > million privileges within a single virtual enterprise Distribution of Privileges e.g., when a user joins, changes job or responsibility, how is access set up? how does the user obtain access to resources and applications? Revocation of Privileges e,g., when a user leaves, changes jobs or responsibility, how is access changed? how does the user loose access to resources and applications Review of Privileges e.g., what are the resources and applications this user can access End-users should not administer access to enterprise resources and applications 5

6 Accurate Configuration Control Over User Privileges Who are the valid users? What are they entitled to access? How do you keep access rights up-to-date? How do you specify and enforce policy? Maintaining Access Configurations is Labor-Intensive Adding IT Staff Scales Linearly Provisioning Activity Scales Non-Linearly Symptoms of the problem Unused accounts proliferate Turn-on time rises for user privilege creation Privilege review is impractical Security audits fail - User down-time increases Security admin requests staff increases Help desk requests staff increases 1,200 1, Year Source: IDC, 2001 Privileges almost double yearly growing from less than 200k to over 1M in 2004 Users (100's of) Resources 2002 Privileges (1,000's of) 2003 Estimated Privilege distribution Activity in Typical Companies Role-Based Access Control To address these problems, RBAC models began to appear in the early and mid 90s Ferraiolo & Kuhn 92 Nyanchama & Osborn 94 Ferraiolo, Cugini, and Kuhn 95 Sandhu 96 Influenced by, NIST Study, Clark-Wilson s SoD policies, and Baldwin s privilege groupings and hierarchies RBAC Economic Incentives Increase administrative productivity Reduced confusion and errors Increase user productivity wider access to enterprise data and applications reduced user down time between administrative events Reduced insider computer crime (80% of all security related losses) Increased Operational Assurance Role-Based Access Control A Strategy for Security Policy Management Centrally administer access control data in terms of roles and role relations that are mapped one-to-many onto local user accounts, groups, operations, and resources. This reduces complexity, provides visualization and a context for implementing and reviewing complex access control policies Manages access control information across the virtual enterprise Employees Suppliers Consultants Customers Based on the observation that roles are global and persistent USERS (UA) User Assignment Roles and Role Relations Enterprise Level Role Hierarchy ROLES (PA) Permission Assignment Platform Level DBMS (one environment) OPERA TIONS privileges Many-to-many relationship among individual users and privileges User/role and role/role relationships are global Privilege specification is system/application dependent Privileges are the most atomic unit of work discernable in a system As arbitrary collections of privileges, roles can represent functions, duties, tasks or any other abstraction of work As collections of users, roles can represent job positions, authority, competencies, qualifications, or any other user characterization OBJECTS 6

7 Types of Hierarchies Jill Static Separation of Duty Role Hierarchy p r i v i l e g e Dermatologist Specialist contains Doctor contains contains Employee Cardiologist contains Limited Hierarchies m e m b e r s h i p Comp Security Division MEL Secretary CSD Secretary ITL Secretary NIST Secretary Added Advantages: Users can be included on edges of graph Roles can be defined from the privileges of two or more subordinate roles Privileges of a role can be shared by higher roles General Hierarchies USERS (UA) User Assignment ROLES. Mutual exclusivity Cardinality (PA) Permission Assignment OPERA TIONS. Mutual exclusivity privileges SoD policies deter fraud by placing constrains on administrative actions and thereby restricting combinations of privileges that are made available to users E.g., no user can be a member of both Cashier and AR Clerk roles in AR Department OBJECTS USERS user_sessions Dynamic Separation of Duty User Assignment SES- SIONS Role Hierarchy ROLES session_roles Permission Assignment Dynamic Separation of Duty OPERA TIONS privileges OBJECTS DSoD policies deter fraud by placing constrains on the roles that can be activated in any given session thereby restricting combinations of privileges that are made available to users E.g., No user can active both cashier and cashier supervisor role although a user maybe assigned to both Valuable in the enforcement of least privilege RBAC Constraint Specification Although RBAC models include basic constraints in support of Separation of Duty requirements, during the late 90s several new new policies were specified, e.g., (1) R. Simon and M. Zurko, 1997, (2) V.D. Gligor, S. I. Gavrila, D. F. Ferraiolo, 1998, (3) T. Jaeger and J. Tidswell, 2000, and others Collectively Identified 10s of Static, Dynamic and History based SoD policies SoD Principles SoD aims at reducing the risk of fraud by not allowing any individual to have sufficient authority within a system to perpetrate a fraud on his own SoD principles are very common: Opening a safe may require two keys, held by different individuals; approving a trip may require permission by a manager as well as by an accountant; a paper submitted to a conference often requires three reviews Sample RBAC Constraint Specifications (Simon and Zurko, Nyanchama and Osborn, Bertino et el.) User-user conflicts, a pair of users should not be assigned to the same role Privilege-privilege conflicts, a pair of privileges should not be assigned to the same role Static SoD, two role should never be assigned to the same person Operational SoD, breaks a business task into a series of stages and ensures no single person can perform all stages Simple dynamic SoD, disallows two particular roles from being activated by the same person Object-based SoD, once a user performs action 1 on an object the same user cannot perform action 2 on the same object Order-dependent history constraints, restrict operations on business task based on a predefined order in which actions may be taken Order-independent history constraints, restrict operations on business tasks requiring two distinct actions (two signatures) where there is no ordering required. 7

8 RBAC in DBMSs DBMS Vendors were the first to implement RBAC in the mid 90s Distributed heterogeneous computing environment from a hardware perspective Single information management scheme Sybase, Oracle, and Informix Subject Database RBAC Still one authorization management scheme RBAC imposes rules on the authorization data Includes role hierarchies, and static and dynamic SoD Reference Monitor Auth. database object The Enterprise Wide Authorization Problem Enterprise Access Control Management Systems The fundamental problem is that each system and application for which access control is enforced has a proprietary method for creating and managing users, groups, and a system specific meaning of operations and objects. The number of systems can be in the tens, hundreds or even thousands, users can range from the hundreds to the hundreds of thousands and the number of resources can exceed a million Access Control List (ACL) are the most common access control mechanism for non-dbms products Islands of Administration RBAC in Heterogeneous Authorization Management Systems System 1 System 2... System n Each system is treated as an independent administrative domain Little or no consistency in naming and defining groups Difficult to administer over arching security policies Distributed access control management products began appearing in the mid and late 90s Multiple heterogeneous security management systems Single RBAC model Centrally maintained user/role, role/role relationships Distributed role/privilege relationships 8

9 Distributed Reference Monitor NIST s Role Control Center sub rm obj sub rm obj sub rm obj... RCC Security Management Features RBAC+, Implemented as a W2K application Centralized User Account Management Automatic creation and deletion Centralized Group Management Automatic group creation, population and deletion Centralized User and Role Permission Management Automatic ACL creation and deletion Centralized User and Role Permission Review RCC Client... Three Tier System RCC Server RCC Server Directory Service RCC Client... RCC Agent RCC Agent Presentation layer Application logic Data layer... Agent Software ERBAC Model and Mappings Role Control Center Enterprise Level Users Roles Abstract Permissions RCC Agent RCC Agent RCC Agent Target System RCC Agent API Library ACL Mech. Operating System Target System Level Accts Groups Access Control Entries 9

10 Example Role Graph Client Interface Hierarchy Properties Graph Navigation up-projection and down projection Roles represent: Job positions, Units of work such as functions, tasks, and duties, OUs and OU structure such as depts., divisions groups, and regions, OO like management of permissions - Higher order roles are composed of lower order roles which can each be re-used in the construction of higher order roles. Hybrid roles (e.g., East Coast Sales, Secretary in Security Division Note 1: user-role assignment and inheritance are the same relation. Note 2: RBAC does not include user-permission assignments, RCC does Bottom role connects Graph Example Role Hierarchy Anchor Payroll Super with two levels of projection Instantiation Views For Delegation and Instantiation A role view defined by a set of roles {r1,,rn}is a sub-graph of the of the overall role graph with the following properties: 1. Instantiate view {payrollclerk, Auditing} On Target system pier. the view contains r1,,rn as nodes; 2. if the view contains a role r, then it contains any user or role q such that q r; 3. the view contains no other nodes except those included by rules 1, 2; 4. the view contains an arc q r iff q and r are included in the view and q r is an arc in the original graph. RCC creates user accounts for Ross, Laura, Gray, Jim, Sheila, and David, groups for Auditing, PayrollClerk, and PayrollSuper, and populates these groups as follows: Example Hierarchy View defined by Auditing & PayrollClerk - group PayrollSuper has Sheila, David as members; - group PayrollClerk has Laura, Gray, Jim, Sheila, David as members; - group Auditing has Ross as member. Any change to the RCC graph results in corresponding changes to user accounts, groups, group memberships, and acls. 10

11 Separation of Duty SSoD is enforced across administrative boundaries RCC s exceptions reporting can be used to test a large variety of separation policies ( before the fact auditing ) RCC s permission mappings allow for the extension of other SSoD policies Abstract Permissions and Administration Admin roles and user roles are in the same graph. In theory all user and all roles on the planet can be included in one graph. Admin operations are abstract (e.g., create/delete users, roles relations) Admin objects are abstract (e.g., RCC users, roles, relations ) Admin abstract operations and objects are mapped to real objects and operations (e.g., AD elements and attributes with read/write and ACL protections) Delegation Based on Views (defines abstract objects: users, roles, inheritance relations) A more powerful admin can delegate permissions to a less powerful admin starting with super admin. Any type of admin can be created down to the granularity if a single RCC operation on a single abstract object. Delegation is an RCC operation and as such can be delegated Distributed Administrative Services Enterprise Administrators: Centrally create, maintain, and navigate role graph, and display role properties. (E.g., assign users to roles, delete user/role relations ) Target System Administrators: Navigate role graph, select role view for the creation of local groups and user accounts and populating local groups with respect to the role view Object Owners: Specify privilege with respect to mapped groups and user accounts RBAC Enterprise Access Control Administration Products and Systems Vendors: Tivoli, Beta Systems, Siemens, Computer Associate, BMC, and Microsoft Centralized database services (e.g., X.500 services) Role Hierarchies Simple SoD Remaining Issues Role Engineering Many important policies can not be implemented Non single, overarching model Reliance on Agent Software Incompatibility between administrative products 11

12 Conclusion Access control models and techniques were founded on a solid foundation of research Access control approaches have evolved based on architectural changes, the policy needs of corporations and government agencies, and economic factors Problems still exist, and access control remains a fruitful area of research Thank You! 12