Efficiency of RBAC Systems: Database Security Group | CS 4235, Papers of Computer Science

Download Efficiency of RBAC Systems: Database Security Group | CS 4235 and more Papers Computer Science in PDF only on Docsity! Efficiency of RBAC Systems Database Security Group Sandhya Balakrishnan Joshua Chini Daniel Combiths Jamie Hobbs Introduction This paper presents the current topics of access control in a database system and demonstrates why Role Based Access Control is now the method of choice for database security in relation to the database’s users. Background of Access Control Access control policy relates to authority, that is, power which has been legitimately obtained, and how that authority is delegated. Access control is concerned with ensuring that objects and processes in a computer system gain access to computer- based resources in a controlled and authorized manner. Resources such as files must be protected from unauthorized access and access permission must be assigned only by subjects or managers with authority to do so. Access control technology has evolved from research and development efforts supported by the Department of Defense (DOD). This research has resulted in two fundamental types of access control: Discretionary Access Control (DAC) and Mandatory Access Control (MAC). While initial research and applications addressed preventing the unauthorized access to classified information, recent applications have applied these policies to commercial processing environments. (NIST/ITL Bulletin, December, 1995) Discretionary Access Control (DAC) DAC permits the granting and revoking of access control privileges to be left to the discretion of the individual users. A DAC mechanism allows users to grant or revoke access to any of the objects under their control. As such, users are said to be the owners of the objects under their control. However, for many organizations, the end users do not own the information for which they are allowed access. For these organizations, the Access Control List Another control mechanism is ACL (Access Control List), which is an object that is associated with a file and contains entries specifying the access that individual users or groups of users have to the file. Access control lists provide a straightforward way of granting or denying access for a specified user or groups of users. Role Based Access Control: Definition The previous access control techniques have several weaknesses that create an amount of inefficiency in the handling of data and risk in the data a user has access to from the database. The solution to the problem of inefficiency is another method called Role Based Access Control (RBAC). RBAC is a method of creating “roles” based on job functions and assigning the data fragments within a database to those roles according to the type of data required by that role. The permission to access data is now defined based on an individual’s job authority and responsibilities. Each user of the database is then assigned to a role and that role is what the database is concerned with, not each individual user. This helps to decrease the work load of the DBA dramatically by limiting the access of data to certain roles versus limiting the data to each individual user of the database which is especially useful for a company that has many database users. This said, the principle role of RBAC is to simplify administration. RBAC administration can be condensed down to three major functions – assigning users to roles, assigning permissions to roles, and assigning roles to roles in order to create a role hierarchy (Sandhu 318). The job function of each user can sometimes change frequently but the roles do not. This helps to simplify the security process by limiting the number of variables for a secure database system to that of the roles and not every user. RBAC also helps to increase the flexibility and cost efficiency or a security policy by limiting access rights to roles versus rights to individuals. Roles Each role is given a certain amount of privileges to access data and that access is based on a least privileged principle. Each role contains the minimum amount of permissions in order to instantiate that role. Then, no single user has more privileges than another in the same role. Once the permissions to a specific role have been set then users can be added and removed from that role easily. RBAC Components Each role within a RBAC is composed of 7 main items. 1. Users-people that use the database. 2. Roles-organization’s job functions. 3. Operations-program specific function executions. 4. Objects-a component of the RBAC that contains system resources. 5. User Assignments-each use is assigned to one or more roles. 6. Permissions-access to perform operations on certain objects of a database. 7. Sessions-requested access to objects that are invoked by the user. 8. Role Hierarchies-a system of organizing the lines of authority within a network. 9. Separation of Duties-a method of preventing individual users from exceeding their level of access to the resources. All of these components are then managed by the DBA in cooperation with other authorities in the same organization by creating, editing, and deleting the elements and relations of the roles (Alvarez). There are two main parts that make up the RBAC scope – RBAC Reference Model and RBAC Administrative Duties. RBAC Reference Model There are two main purposes of the RBAC Reference Model. First, the reference model defines the scope of the RBAC features such as the roles, relations among the roles, and the constraints among those relations. The second purpose of the RBAC Reference Model is to provide a language composed of the elements and functions of the RBAC system. The RBAC reference model is defined by 4 components 1. Core RBAC-minimum set of elements, sets, and relations needed in order to define a RBAC system. As seen in figure one the core components are the users, roles, objects (OBS), operations (OPS), and permissions (PRMS). According to this model users and permissions are being assigned to roles. The sessions are a relation between the user and the roles. Both the user and the role are what comprise a session. 2. Hierarchical RBAC-a method of defining seniority relations between roles. Role hierarchies provide the ability to inherit permission from two or more roles. As seen in figure 1 the hierarchical model is applied to the roles and not the users. 3. Static Separation of Duty Relations-adds exclusivity relations among roles with respect to user assignments. If there exists a conflict in the assigning of a user to two roles then a static separation of duties is applied in order to enforce a constraint on the assignment of users to roles. One example is that if a user is assigned to one role, he is prohibited from being assigned to another role. to the network, as the system will adjust itself based on the need. Time is saved, and time is money. Government Contributions The National Institute for Standards & Technology (NIST) has sought to further the research and development (R&D) of the RBAC technology. As mentioned in a NIST planning report from March 2002 entitled The Economic Impact of Role-Based Access Control, the organization believes that RBAC can increase productivity in the workplace, and reduce both administrative processing time and the frequency and severity of security violations. To this end NIST has contributed time, personnel, and money to RBAC R&D and claims that their aid will lower the cost of overall R&D, lower implementation costs, and “accelerate the realization of benefits” with regard to this new technology. NIST published the first comprehensive RBAC model in 1992, and has pushed the system ever since. According to the report, “NIST’s contributions range from developing and formalizing the fundamental concepts of RBAC models to demonstrating their capabilities and providing implementation tools to industry” (Gallaher 1-3). Further contributions to research have produced two patents and, as of the publication of this report, there are applications pending for two more. The report continues on to claim that, while NIST’s contributions probably will not improve the quality of RBAC products overall, they will lower development costs by 5.8% and expedite the availability of the products commercially, meaning a one year acceleration in product diffusion. Economics of RBAC Based on an extrapolation performed by NIST that measures the expected economic improvement due to RBAC integration, the annual end-user benefits are $43.57 per employee by the year 2006. These results assume a couple of things: employees are first managed by RBAC systems starting in 2001, and funds spent in RBAC R&D remain a constant $5.5 million over the time period in question. Firms having 500+ employees were targeted for this particular case study. With or without the assistance of NIST, the study shows that the net benefits of implementing RBAC technology are expected to show a positive return, and in fact surpass the amount spent on R&D by 2004. NIST’s assistance moves that up one year to 2003 (note that this report was written in March 2002). Overall industry net benefits in the projection year of 2006 are expected to be over $376 million. While all of this could be taken as a government agency’s idle claims, a return was seen as early as August 2002. According to the News Briefs section of the Journal of Research of the NIST, government research into RBAC cost taxpayers $2.3 million, but saved the U.S. industry $295 million in R&D. These figures come from an economic impact study performed by the Research Triangle Institute (RTI). Additionally, the RTI study professed that RBAC technology in general saved the U.S. industry $671 million. RBAC Enterprise Products The final section of this paper will discuss the following enterprise products and how they use RBAC in their database systems. Oracle 9i Enterprise Edition Every Oracle 9i database server comes with a pre-defined role called DBA. Each user who is assigned this role is considered as an administrator to the database and has the privilege to create users. Any user can create a role, provided he has been given that privilege by the Administrator. In Oracle, two types of privileges can be tied to a role: System and Object. System privileges are like ‘sysdba’, ‘sysoper’, ‘create session’, ‘create table’ etc which basically dictates what a user can do with the database. Object privileges give authority to the owner of the data regarding what can be done to his data by others. Different object and system privileges can be assigned to a role and the role in turn can be granted to the database users. The ‘admin option’ helps the Administrator to delegate the task of managing system privileges to others users. The ‘grant option’ allows the role grantee to in turn grant roles to others. If a certain privilege should be granted to all users by default, it can be accomplished by using the ‘public’ keyword (Oracle 9i Database Online Documentation). Oracle also supports another RBAC feature called role hierarchy, where a role can be assigned to another role. Roles can be created with or without a password. If a role is created with a password and the user accesses a part of the application which needs this role to be used, the application will prompt for the password. Thus this feature provides additional security. Multiple roles can be assigned to a user at one time. However an initialization parameter (MAX_ENABLED_ROLES) can restrict the total number of roles assigned at any time. Default role(s) can be assigned at login time (Oracle 9i Database Online Documentation). Sybase Adaptive Server Enterprise release 11.5 Sybase Architecture also supports several RBAC features. It comes with three roles: System Administrator (s_role), System Security Officer (sso_role) and Operator(oper_role). Only the System Security Officer (SSO) has the system-wide authority to create users, set the ‘max roles enabled per user’ parameter, create roles etc. work required by the database administrator. RBAC presents a new method of creating roles assigning certain permissions and users to those roles based on the level of authority that particular role has. This method is very cost efficient and saves the administrator time by decreasing the amount of work needed to be done in managing the users of a database. Not only is this method cost efficient but it also provides a more direct approach to the highest security vulnerability which is the user. RBAC focuses mainly on ensuring that each user of the database is governed by a certain role and by managing that role effectively the database system is in a much more secure position. The current problem with RBAC isn’t so much the technology but, just like any other new technology, the main focus seems to be on encouraging corporations and research institutions to begin integrating this new method of database security into their current database system. It is also hard to find organizations that will support the ongoing research and development required to make this technology more of the standard for database security. Work Cited “Role Based Access Control”. American National Standard for Information Technology. 4 April 2003 Alvarez Wilfredo. “Role Based Access Control”. Oct. 29, 2003 <http://csrc.nist.gov/rbac/alvarez.ppt>. Ravi, Sandhu and Bhamidipati, Venkata. “Role Based Administration of User Role Assignment”. Journal of Computer Security 1999. 318. Gallaher, Michael P., Ph.D. (et al). The Economic Impact of Role-Based Access Control. Report. http://www.nist.gov/director/prog-ofc/report02-1.pdf. March 2002. Journal of Research of the National Institute of Standards and Technology. Vol 107, #4. http://nvl.nist.gov/pub/nistpubs/jres/107/4/j74nbr.pdf. July-August 2002. “Oracle9i Security Overview.” Oracle 9i Database Online Documentation. 2002 <http://download- west.oracle.com/docs/cd/B10501_01/network.920/a96582/toc.htm> Sybase Security Features User’s Guide Release 11.5. 2003 <http://manuals.sybase.com/onlinebooks/group- asarc/asg1150e/ sfug/@Generic__BookView> IBM Informix Database Design and Implementation Guide. March 2003 <http://www.informix.com.ua/doc/9.40/ct1stna.pdf> Chandramouli Ramaswamy, and Ravi Sandhu. “Role-Based Access Control Features in Commercial Database Mangement Systems”. 29 Sept. 2003 <http://csrc.nist.gov/nissc/1998/proceedings/paperF18.pdf>. Department of Defense; “Department of Defense Trusted Computer System Evaluation Criteria DoD”, 5200-28-STD. December 1985 NIST/ITL Bulletin, December, 1995, http://csrc.nist.gov/rbac/NIST-ITL-RBAC- bulletin.html D.E Denning and P.J. Denning; “Communications of the ACM”; July, 1977