Access control by amin

Editor's Notes

1. This chapter deals with a narrower, more specific concept of access control which implements a security policy that specifies who or what may have access to each specific system resource and the type of access that is permitted in each instance. Figure 4.1 from the text shows the broader context of access control. In addition to access control, this broader context involves the following entities and functions: • Authentication: The verification an identity claimed by or for a system entity. • Authorization: The granting of a right or permission to a system entity to access a system resource. This function determines who is trusted for a given purpose. • Audit: An independent review and examination of system records and activities in order to test for adequacy of system controls, to ensure compliance with established policy and operational procedures, to detect breaches in security, and to recommend any indicated changes in control, policy and procedures. An access control mechanism mediates between a user (or a process executing on behalf of a user) and system resources, such as files and database. The system must first authenticate a user seeking access. Then, the access control function determines if the specific requested access by this user is permitted. A security administrator maintains an authorization database that specifies what type of access to which resources is allowed for this user. The access control function consults this database to determine whether to grant access. An auditing function monitors and keeps a record of user accesses to system resources. All operating systems have at least a rudimentary, and in many cases a quite robust, access control component. Particular applications or utilities, such as a database management system, also incorporate access control functions.
2. An access control policy, which is embodied in an authorization database, dictates what types of access are permitted, under what circumstances, and by whom. Access control policies are generally grouped into the following access control categories: • Discretionary access control (DAC): based on the identity of the requestor and on access rules (authorizations) stating what requestors are (or are not) allowed to do. This policy is termed discretionary because an entity might have access rights that permit the entity, by its own volition, to enable another entity to access some resource. • Mandatory access control (MAC): based on comparing security labels (which indicate how sensitive or critical system resources are) with security clearances (which indicate system entities are eligible to access certain resources). This policy is termed mandatory because an entity that has clearance to access a resource may not, just by its own volition, enable another entity to access that resource. • Role-based access control (RBAC): based on the roles that users have within the system and on rules stating what accesses are allowed to users in given roles. DAC is the traditional method of implementing access control. MAC is a concept that evolved out of requirements for military information security and is best covered in the context of trusted systems. RBAC has become increasingly popular. These three policies are not mutually exclusive as shown in Figure Can employ two or even all three of these policies to cover different classes of system resources.
3. The basic elements of access control are: subject, object, and access right. A subject is an entity capable of accessing objects, usually a process. Any user or application actually gains access to an object by means of a process that represents it. A subject is typically held accountable for the actions they have initiated, and an audit trail may be used to associate with a subject and security-relevant actions performed on an object. Basis access control systems typically define three classes of subject: • Owner: This may be the creator of a resource, such as a file. For system resources, ownership may belong to a system administrator. For project resources, a project administrator or leader my be assigned ownership. • Group: In addition to the privileges assigned to an owner, a named group of users may also be granted access rights, such that membership in the group is sufficient to exercise these access rights. • World: The least amount of access is granted to users who are able to access the system but are not included in the categories owner and group for this resource. An object is any resource to which access is controlled. In general, and object is an entity used to contain and/or receive information. Examples include records, blocks, pages, segments, files, portions of files, directories, directory trees, mailboxes, messages, and programs. The number and types of objects to be protected by an access control system depends on the environment in which access control. An access right describes the way in which a subject may access an object. Access rights could include the following: read, write, execute, delete, create, search.
4. For discretionary access control, a general approach to access control as exercised by an operating system or a database management system is that of an access matrix. One dimension of the matrix consists of identified subjects that may attempt data access. Typically, this list will consist of individual users or user groups, although access could be controlled for terminals, hosts, or applications instead of or in addition to users. The other dimension lists the objects that may be accessed. At the greatest level of detail, objects may be individual data fields. More aggregate groupings, such as records, files, or even the entire database, may also be objects in the matrix. Each entry in the matrix indicates the access rights of that subject for that object. In practice, an access matrix is usually sparse and is implemented by decomposition in one of two ways, as we show on the next slide.
5. From a logical or functional point of view, a separate access control module is associated with each type of object, as shown in Figure 4.5. The module evaluates each request by a subject to an object to determine if the access right exists. An access attempt triggers the following steps: A subject S0 issues a request of type  for object X. The request causes the system (operating system or an access control interface module) to generate a message of the form (S0, , X) to the controller for X The controller interrogates the access matrix A to determine if  is in A[S0, X]. If so, the access is allowed, if not the access is denied and a protection violation occurs. Figure 4.5 suggests that every access by a subject to an object is mediated by the controller for that object, and that the controller's decision is based on the current contents of the matrix. In addition, certain subjects have the authority to make specific changes to the access matrix. A request to modify the access matrix is treated as an access to the matrix, with the individual entries in the matrix treated as objects. Such accesses are mediated by an access matrix controller, which controls updates to the matrix. The model also includes a set of rules that govern modifications to the access matrix, such as those shown in Table 4.2 in the text. These include means of accessing, transferring, granting, and deleting access rights; and with who can create and delete subjects and objects. The ability of one subject to create another subject and to have 'owner' access right to that subject can be used to define a hierarchy of subjects. For example, in Figure 4.4 on the previous slide, S1 owns S2 and S3, so that S2 and S3 are subordinate to S1.
6. Traditional DAC systems define the access rights of individual users and groups of users. In contrast, RBAC is based on the roles that users assume in a system rather than the user's identity. Typically, RBAC models define a role as a job function within an organization. RBAC systems assign access rights to roles instead of individual users. In turn, users are assigned to different roles, either statically or dynamically, according to their responsibilities. RBAC now enjoys widespread commercial use and remains an area of active research. The relationship of users to roles is many to many, as is the relationship of roles to resources, or system objects, as shown here in Figure 4.7 from the text. The set of users changes, in some environments frequently and the assignment of a user to one or more roles may also be dynamic. The set of roles in the system in most environments is likely to be static, with only occasional additions or deletions. Each role will have specific access rights to one or more resources. The set of resources and the specific access rights associated with a particular role are also likely to change only infrequently.
7. The Dresdner Bank has implemented an RBAC system which is system wide and in which the determination of access rights is compartmentalized into three different administrative units for greater security. Roles within the organization are defined by a combination of official position and job function, and form a role hierarchy in which one role is superior to another if its position is superior and their functions are identical. This makes it possible to economize on access rights definitions. When a user invokes an application, the application grants access on the basis of a centrally provided security profile. A separate authorization administration associated access rights with roles and creates the security profile for a use on the basis of the user's role. A user is statically assigned to up to 4 roles, and selects a given role for use in invoking a particular application. The user/role information is provided to the Authorization Administration, which creates a security profile for each user that associates the User ID and role with a set of access rights. A role may be used to access several applications. Thus, the set of access rights associated with a role may include access rights that are not associated with one of the applications the user invokes. All of these ingredients are depicted here in Figure 4.12. Some figures about this system are of interest. Within the bank, there are 65 official positions. These positions are combined with 368 different job functions provided by the human resources database. Potentially, there are 23,920 different roles, but the number of roles in current use is about 1300. This is in line with the experience other RBAC implementations. On average, 42,000 security profiles are distributed to applications each day by the Authorization Administration module.
8. Chapter 4 summary.