Control System Security

ABSTRACT Access control systems within an enterprise system are used to control the actions, functions, applications, and operations of legitimate users within an organization and to protect the integrity of the information stored within the system. Role-based access control (RBAC) is a relatively new access control system that maps to organizational-specific structures in a way that reduces administrative costs and improves security. Although role-based security models have existed for 20 years, their application has until recently been limited. We try to give a comparison between RBAC and traditional access control models and try to evaluate the different industries where these models can be utilized. We try to evaluate the NIST RBAC model as a standard for implementing RBAC and show the implementation by developing an application which uses RBAC for authentication and authorization for the computer system to be accessed.

This also involves a discussion for different variations of the Role Based Access Control models according to NIST. INTRODUCTION Access control is generally concerned with determining what users and groups of users can perform which operations on certain resources [10][1][11]. 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. For many organizations, the number of systems can be in the hundreds or even thousands, the number of users can range from hundreds to the hundreds of thousands, and the number of resources that must be protected can easily exceed a million. Organization’s large IT infrastructure is a mix of hugely complex and incompatible operating systems, applications and databases spread all over the world. The organizations these days have a huge number of employees which keep increasing or decreasing all the time according to the organization’s need. It also has a working interaction with contractors, business partners, and customers, all of whom require access to various parts of the infrastructure. Most of the companies rely on manual or semi-automated administration of users, controlling their access to privileges for various resources on a particular system. This will inevitably become very complex and completely unmanageable if the organization is huge and the number of users of the system is in thousands or more.

Often, different systems will have their own set of access requirements with different sets of administrators who will have overlapping skill-sets, leading to poor use of resources. This creates an enormous administrative overhead e.g. If there is a single administrator who needs to update even 25% of thousands of users everyday, it will almost be impossible for the system admin to do so. Furthermore, if multiple administrators are acquired for this job it could cause conflicts so the system becomes almost impossible to handle and maintain.

Also, it would cost much more than if you were to have a single administrator. As the complexity of the organization’s IT infrastructure increases, the demand for access control administration across the enterprise outgrows the capacity of manual administration across the distributed systems. Increased administrative complexity can also result in increased errors that, in turn, can lead to increased security risks. It is best suited to use the access control models to restrict unauthorized access and avoid any security risks. Access Control Models have long been used in enterprise systems and ERP’s so that the system is made secure and reliable, restricting access to sensitive and confidential information resources from unauthorised users [10]. Different access control models are suited for different business applications and industries depending upon the scale and complexity of the system being developed. This report will try to analyze the different types of access control models as discussed above, that may be suitable for a variety of businesses and industry applications, giving their features, benefits and classification. This document will be covering many issues related to access control and various access control models.

The critical analysis of each of the traditional access control model will be provided as well as the comparisons with each other identifying their advantages and drawbacks. The industry specific implementation of each of the model will also be discussed i.e. which model is suited for which kind of industry and what models should be selected depending on the scale of the system. Then the more recent access control model which is being widely utilized nowadays will be discussed in more detail and its different versions will be evaluated. Also role-based access control will be discussed in different environments i.e. in a centralized application environment and also in a distributed application environment. In the end, there will be an implementation of the appropriate access control model for a particular industry application called BOS (Back Office System) that is a travel agency. This application will support the day to day business operations of the organization.

The model used for this application will be Role-Based access control as the structure and requirements of the business will be supported using this RBAC. It does not require the ACLs of DAC and it does not need the high security of MAC because the access privileges can be interchangeable between the users of the system. BACKGROUND Access Control Models have long been used in enterprise systems and ERP’s so that the system is made secure and reliable, restricting access to sensitive and confidential information resources from unauthorised users. The basic need of access control is to protect the system and its contents from intentional and unintentional damage, theft and unauthorised disclosure. The access control models that have been used in the recent decades are traditional access control models which are Access Control Lists (ACL’s), Discretionary Access Control (DAC) and Mandatory Access Control. Role Based Access Control (RBAC) is a more recent access control model which provides an alternative for the traditional access control models. The most appropriate way to restrict access of resources from unauthorized users of the system is to use one of the traditional access control models as a means of implementing secure and reliable access for that system.

There are many access control models present in this age of time which cater to different needs and provide different type of security depending on the nature, scale and type of the application as well as the industry for which the application is being implemented for. Traditional access control models base access control on the discretion of the owner or administrator of the data. Under all traditional models, an end-user’s identity determines which access permissions are needed. This section gives a brief introduction to the predominant traditional access control models as well as some of the more recent models that have been utilized more recently. We discuss these models in more detail in the later sections: Access control lists (ACLs). Discretionary Access Control (DAC). Mandatory Access Control (MAC). Role-Based Access Control (RBAC). Access Control Lists ACL’s is one of the most common access control model being used for securing operating systems, applications, computer resources and networks. When ACL’s is selected as a model for implementing access control, each resource that needs to be secured has a list of users associated with them who are authorized to access the resource and even modify and make changes in it if they are allowed to. ACL’s as a model provides ease of access for the security administrator to see which users have access to which resource within the application or system. Also, modifying access to a piece of information is relatively simple; a security administrator can simply modify a user from the ACL list that is a user can be created, edited or even deleted easily. There is a corresponding ACL present for every data or application, but it is not necessary to have a corresponding list that gives the network administrator information on all of the pieces of information to which a particular user has access.

The only way for the security administrator to find out about any potential security violations on a particular data has to be checked by accessing each of the data individually. If the security administrator wants to revoke all the access privileges for a certain user, the administrator has to examine each list and then have to remove the user from each of the lists one by one. Responsibilities for a user in an organisation may change, in this kind of scenario this model becomes more complicated and hard to manage. Instead of removing the user from every ACL, the network administrator has to determine which permission needs to be removed, modified or added somewhere according to the new position of the user in the organisation. In some situations the user can be grouped together in the list making it easier to change the ACL by just modifying the group information rather than each of the users individually. In some other cases elaborate rules can be applied to ACLs to restrict access to particular resource. Discretionary Access Control Using Access Control Lists Discretionary Access Control The user who owns the data is the one who control access to that data in the discretionary access control model. ACL is a model which is derived from DAC. DAC is a means of restricting access to objects based on the identity of subjects and/or groups to which they belong.

The controls are discretionary in the sense that a user or process given discretionary access to information is capable of passing that information along to another subject [1]. Discretionary Access Control is used to stop the user from accessing the protected objects on the system. The user may also be restricted to a subset of the possible access types available for those protected objects. Access types are the operations which are performed on an object by a user, the operations include read, write and execute. Usually an object belongs to a user or a user is the owner of that object, this means that only the owner of the object has the authority to distribute and revoke access to that object.

The owner of the object may give and retain access to the objects they control based on the rules of the DAC. The identity of users and objects is the fundamental basis for controlling access in a system within this model i.e. DAC specifies which users have access to which part of the information. Mandatory Access Control Mandatory Access Control is different from other access control models in a way that the security it provides is based on hierarchy and assigns each subject and object a specific security level (e.g., classified, secret, top secret etc.). The rules that govern the access to a particular for this model are: No read up. No write down or (own level write only). Read down access gives users the ability to access any piece of information that is at or below their own security level. If a user has a secret security level, they are able to access secret and classified material but not top secret material. Write up access states that a subject’s clearance must be dominated by the security level of the data or information generated. For example, someone with a secret clearance can only write things that are secret or top secret. With these two access control principles, information can only flow across security levels or up security levels [1]. Mandatory Access Control Role Based Access Control In traditional access control models the approach for granting access to resources within a particular system or an application is to specify permission for each of the user within an organization. If the user is allowed to have access to multiple resources or information within a system, the user must be assigned permissions for each of the resource. This approach is tricky and not the most reliable way of implementing access control.

When users join, leave or change responsibilities within an organization, each of the users who changes status within the organization that user’s access privileges information must be updated for each of the permissions. Achieving the above requires a lot of resources, time and also is prone to errors as an organization can have hundreds of thousands of employees and updating each of the users information one by one is not an efficient way. RBAC get rids of this problem because it takes advantage of the user’s role as the key to access rather than the user’s identification. The basis for role-based model is the user-role and permission-role relationships. Each user in a role-based environment may be assigned to multiple roles, and each role may have multiple users as well. The roles that are assigned to a user depend on their job and responsibilities, and each role is assigned permissions according to role’s access privileges in the organization.

Permissions determine the data and applications that may be accessed by which are also assigned to a role and that role is assigned to a user or multiple users. User’s role can be in many forms e.g. jobs like (bank teller, bank manager), geographic locations (London, Newcastle) or individuals (shift supervisor, managers). The advantage of using this model is that users keep changing with in the organization whereas on the other hand roles or job responsibilities for a particular role remain the same. Therefore rather than implementing the security on the user’s manually, roles are created which are assigned to users and any addition in a job specification is changed in the role description which in turn changes the all the user with that role. RBAC is a technology that offers an alternative to traditional discretionary access control (DAC) and mandatory access control (MAC) policies. RBAC allows companies to specify and enforce security policies that map naturally to the organization’s structure. That is, the natural method for assigning access to information in a company is based on the individual’s need for the information, which is a function of his job, or role, within the organization. RBAC allows a security administrator to use the natural structure of the organization to implement and enforce security policy. This model decreases the cost of network administration while improving the enforcement of network security policies. RBAC is designed to centrally manage privileges by providing layers of abstractions that are mapped one-to-many to real users and real operations and real resources.

Managing permissions in terms of the abstractions reduces complexity and provides visualization and a context for implementing complex access control policies. Abstractions can be centrally managed resulting in real permissions on real systems. Role-Based Access Control Discretionary Access Control (DAC) In a computer system, access controls restrict subjects (users and/or processes) to performing only those operations on objects (e.g., files) for which they are authorized.

For each such operation, the access controls either allow or disallow that operation to be performed [3]. DAC model works on the basis that only the owner of a resource has the capability to authorize other users to have access to the same resource. This means that the users who do not have access to a particular resource and wants access to it, only the owner of that resource has the right to give access to them. In Discretionary Access Controls (DACs), each object has an owner who exercises primary control over the object. ACL is one of the mechanisms which can be used to implement DAC and is one of the most widely used implementation for DAC. The access of information in DAC is based on the user’s identity and the rules that specify the user’s ability to have access to a certain protected resource or information. On the other hand ACLs are lists that specify user’s access privileges for the protected objects. DAC consists of set of rules which specify a user’s ability to access restricted resource or information. When a user wants access to a particular resource or information, the server searches the rule which specifies the user’s ability to have access to the particular resource which it wants access to. If the rule is found and there is a match for the user to have access than the user is allowed access to the resource, if there no match then the access for the resource to the user is denied. For example, there may be a rule which states that users from a certain group is not allowed to have access to a certain piece of information. Discretionary access control (DAC model) works on the discretion of the identity of the user. In DAC access to any object (files, directories, devices, information etc.) is only allowed if the owner of that object is willing to give access.

Therefore, the basis of this model is creator-controlled sharing of information and identity of the owner plays an important role in the working of this method. The owners of objects can specify at their own discretion in what ways they want to share their objects to other users i.e. which other users can have what level of access to the objects they own. This can be implemented in a fairly simple way by using access control matrix which contains the names of users on the rows and the names of objects on the columns giving information of which users has access to which corresponding object. Regardless of how the matrix is represented in memory, whether by rows or by columns, the names of the users and objects must be used in the representation [1]. ACCESS CONTROL MATRIX The access control matrix is a combination of rows and columns with cells representing the permissions. In the matrix, the rows represent user/subjects and columns represent resources / objects. Regardless of how the matrix is represented in memory, whether by rows or by columns, the names of the users and objects must be used in the representation.

For example, in a row-based representation an entry might read the equivalent of “KIM can access KIMSFILE and DONSFILE”. In a column-based representation, one might find the equivalent of “DONSFILE can be accessed by DON, JOE and KIM” [1]. The entries in the matrix describe what type of access each user has to each object. This representation of rows and columns is dependent on the model or mechanism being selected for Discretionary Access Control. The table below exhibits a good example of an Access Control Matrix. ACCESS CONTROL MATRIX

The access control matrix such as the example above is a graphical view of a set of users and their access rights on particular set of protected objects. The access types mentioned in the table above are: r denotes read access. w denotes write access. c denotes control permission access. cp control passing ability. CHARACTERISTICS OF DAC MECHANISMS The complete implementation of DAC is based on the information which is stored in the form of an access control matrix. DACs are oldest and most widely used class of access controls, the access controls for both Windows and UNIX are DAC. The Unix DAC, for example, has the well known three primitive permissions read, write, and execute. When the initial implementation of DAC started, the five basic mechanisms that were used initially to represent information were: Capabilities Profiles Access Control Lists (ACLs) Protection Bits Passwords The first two mechanisms that are capabilities and profiles represent the access control matrix information by row, connecting the accessible objects to the user.

Whereas ACLs and protection bits represent the access control information by columns, connecting a list of users to an object. In the above five mechanism we will be mostly concentrating on the ACL model which is the most widely used model out of all of the mechanism present for DAC and also in this section a brief description of the other mechanisms will be provided [1]. Capabilities In a capability-based mechanism for DAC, access to objects which have restriction on them being accessed such as files is granted if the user who wants access to it has the capability for that object. The capability is a protected identifier that both identifies the object and specifies the access rights to be allowed to the accessor who possesses the capability [1]. The basic properties of capabilities are: The capability of one user can be passed onto another user. The user who possesses capability may not alter or fabricate capabilities without the interference of TCB (Trusted Computing Base). If a capability mechanism is used to implement DAC than the implementation should possess the facility to transfer capability from one user to other users. This ability of transferring capability from one user to another cannot be controlled and therefore capabilities has to be stored, determining all the users access for particular objects almost becomes impossible. Because of this reason implementing DAC using the capability mechanism becomes very difficult including the feature of revocation. A pure capability system includes the ability for users to pass the capability to other users. Because this ability is not controlled and capabilities can be stored, determining all the users who have access for a particular object generally is not possible.

This makes a complete DAC implementation, including revocation, very difficult. (Revocation may not be an issue, however, since a user who has access to an object can make a copy of the information in another object. Revoking the user’s access on the original object does not revoke access to the information contained in the user’s copy.

After revocation, however, changes can be made to the original object without the knowledge of revoked users.)[1]. Profiles This is another mechanism which can be used to implement DAC and have been used in some forms for several systems. When using Profiles

[1] to implement DAC, a list of protected objects is used to associate each user to the particular object. The object names are inconsistent and they don’t agree on being grouped together, also their size and number are difficult to reduce. If a user has access to a large number of protected objects, the profile can also become very large and it is very complex to manage such a profile. In profile mechanism all protected object names should be unique to but in reality multiple objects can have multiple names, because of this reason full pathnames should be used to identify the objects uniquely. One major drawback of this method is that when creating, modifying or deleting access to protected objects requires multiple operations because multiple users might have access to the same object therefore those user’s profile must be updated. Revoking access to an object in time for a user is very difficult unless the user’s profile is automatically checked each time that object is accessed.

Also if some object is deleted, it will require some method to check whether that object exists in each of the user’s profile or not, which is also an extra overhead. In general, with these two mechanisms i.e. Capabilities and Profiles it is very difficult to check whether which users have access to a particular protected object. This is a very important problem that needs to be addressed in secure system and there exists more feasible and more efficient mechanisms, the above two mentioned mechanisms are not the recommended implementations for DAC. ACCESS CONTROL LISTS (ACLs) Another approach to implement the DAC model for access control using the access matrix is by means of the access control lists (ACLs). When using ACLs, each object is related with an ACL, these ACL entries indicate the authorities a subject possesses which can be executed on that object. In the ACL mechanism the access control matrix is represented by columns. By looking at an object’s ACL it is easy to determine which modes of access subjects are currently authorized for that object. In other words, ACLs provide for convenient access review with respect to an object. It is also easy to revoke all accesses to an object by replacing the existing ACL with an empty one. On the other hand determining all the accesses that a subject has is difficult in an ACL-based system. It is necessary to examine the ACL of every object in the system to do access review with respect to a subject. Similarly if all accesses of a subject need to be revoked all ACLs must be visited one by one. (In practice revocation of all accesses of a subject is often done by deleting the user account corresponding to that subject. This is acceptable if a user is leaving an organization. However, if a user is reassigned within the organization it would be more convenient to retain the account and change its privileges to reflect the changed assignment of the user.) Several popular operating systems, such as UNIX and VMS, implement an abbreviated form of ACLs in which a small number, often only one or two, group names can occur in the ACL. Individual subject names are not allowed.

With t his approach the ACL has a small fixed size so it can be stored using a few bits associated with the file. At the other extreme there are a number of access control packages that allow complicated rules in ACLs to limit when an how the access can be invoked. These rules can be applied to individual users or to all users who match a pattern defined in terms of user names or other user attributes. Access control is required to achieve secrecy integrity, or availability objectives. ACLs have been a popular approach for implementing the access matrix model in computer operating systems. Some systems approximate ACLs by limiting the granularity of the ACL entries to one or two user groups. Other systems allow considerable sophistication. ACLs have disadvantages for access review and revocation on a per-subject basis, but on a per-object basis they are very good.

More flexible representation such as authorization tables provide for superior management of access rights, but are usually available only in database management systems. In a distributed system a combination of capabilities for coarse-grained control of access to servers, with ACLs or authorization tables for finer-grained controls within servers, is an attractive combination [10]. ACL MECHANISM WORKING ACLs allow any particular user to be allowed or disallowed access to a particular protected object. They implement the access control matrix by representing the columns as lists of users attached to the protected objects. The lists do not have to be excessively long if groups and wild cards (see below) are used. The use of groups raises the possibility of conflicts between group and individual user. As an example, the ACL entries “PAYROL rw” and “Jones.PAYROL r” appear to conflict, but can be resolved in the design of the DAC mechanism. The Apollo system has a multiple, hierarchical group mechanism.

The ACL entry has the form “user-id.group.organization .node.” As in Multics, if the ACL specifies access rights for the user by user-id then group access rights are ignored. This allows a particular user to be excluded or restricted in access rights [13]. In the Apollo, if a user is not on the ACL by user-id, but is a member of a group, those rights are used and organization and node memberships are not examined.

Multiple group mechanisms add more complexity and may facilitate administrative control of a system, but do not affect the utility of a DAC mechanism. Access to ACLs should be protected just as other objects are protected. The creation of groups must be controlled, since becoming a member of a group can change the objects accessible to any member. In many systems, e.g., Multics [14], a user must be a member of at least one group. One detriment of the group mechanism is that changing the members of a group results in changes to an unknown set of ACLs for protected objects. Allocation of groups could be a Systems Administrator function only, or it could be distributed to a Project Administrator type function.

Problems could result from allowing any user to create a group and then be “owner” of that group. If users were prohibited from listing the members of groups they are not in because of covert channels and privacy, it would be difficult to determine if a group was the correct one to use. System or Project Administrator control is a preferred mechanism. Wild Cards A wild card mechanism allows a string replacement where the wild card is specified. For example, in the Multics system “`PAYROL rw” gives read and write access to any user in the PAYROL group. “Smith.* r” gives Smith read access, no matter what group the user Smith belongs to. “*.*” gives any user access. The group and wild card mechanisms allow the ACL list to be kept to a reasonable size. The use of wild cards raises the possibility of conflicts if a user has multiple ACL entries for an object. In the above example, Smith has a possible conflict; as a member of any group he can read and as a member of the PAYROL group he can read and write.

The system must make a decision as to which one of the ACL entries it will apply when granting Smith access to the object. Various systems have different rules for resolving conflicts. One approach might be to have the system enforce an ordering of the ACLs. Another approach might be to allow ordering of the ACLs by the users. In any case, the users must understand the rules in order to create effective ACL entries. A wild card mechanism adds more complexity, but does not affect the utility of a DAC mechanism. An exclusion capability, which allows a group to be specified with certain members to be excluded, is also useful and is required at class B3 and above. Default ACLs There are many side issues in the implementation of access control lists. Default ACLs are usually necessary for the user friendliness of the DAC mechanism. At the very least, when an object is created by a user, the user should be placed on its ACL by default.

Some of the other possible default mechanisms include a system-wide default, a user-associated default or if the file structure is a tree, a default associated with the directory. A system-wide default could be used as the default in cases where no other default had been specified. A system-wide default might give access only to the creating user. A user-associated default might work well on a system with a flat file structure. When a user is first entered on the system, his default ACL would have to be specified. For file structures that are trees, a default(s) associated with the directory could be most efficient. If the user organizes the directory structure to represent project work or areas of interest, then the ACLs for all objects in a sub-tree would be similar. One default ACL in the directory would be for children that are files. For children that are directories either a separate sub-directory default ACL should be specified or the default ACLs should have to be stated explicitly by the user. Otherwise, unless care is taken, those with access to the root sections of the storage hierarchy could by automatic default get access to all of the storage hierarchy.

The overriding principle of least privilege implies that the use of defaults should not inadvertently give away more access than the user intended. In other words, to err on the conservative side is preferred. In all implementations some user(s) must have permission to change the ACLs after they have been set by default, and the ability to change the defaults is very useful. Defaults can be implemented in two ways: they can be copied to the ACL or they can be pointed to by the ACL. If they are copied, then changes to the default will not affect the ACL; Otherwise, changes in the default may cause changes in many ACLs. Named ACLs Another possible user friendly feature is “named” ACLs. One implementation of this feature uses a named ACL as a template. If a user often sets ACLs to the same list of Users, the setting user may want to create a named ACL as a template which, when used, copies that list into the ACL. When the named ACL is changed, there is no effect on the ACLs already in existence.

This use of named ACLs has no particular detriments and is of limited usefulness. The other implementation of named ACLs places a pointer in the real ACL to the named ACL. Now when the named ACL gets changed, all of the real ACLs that use it also get changed. This is very convenient for the user, but when a named ACL is changed the user has no way of determining all of the protected objects affected by the change. The named ACLs also have to be protected in the same way as the real ACLs. Most of the features of named ACLs can be replaced by some group and default mechanisms. 7.4 PROTECTION BITS Protection Bits is one of the column-based mechanisms to implement access control matrix.

This method is not appropriate as its implementation is not complete for the requirements of access control matrix. One such system which uses protection bits in its implementation is UNIX [15]. Instead of using list of users who may access an object, UNIX uses protection bits associated with objects. The implementation of protection bits in UNIX gives information about the access modes to the protected object which may be applied to either the object’s group or the owner of the object. The user who created the object is the owner, and the ownership of a certain object can only be changed through the superuser privileges. The protection bits can only be changed by the owner with the exception of a superuser. The trouble with Protection Bits is that there implementation for access control matrix model is not complete.

When a system is developed based on the mechanism of Protection Bits than it is not convenient for that system to easily grant or revoke access to a protected object on any single user basis. For this reason it is recommended that a group of user be set up so that instead of specifying a single user a combination of users can be specified. If the number of users is less that is very few users are comprised of a group than such a solution is not appropriate. Also for the administration of groups a full time administrator is required which will be able to provide full time administration for the management of the group. 7.5 PASSWORD DAC MECHANISMS Password protection of objects for DAC is implemented as a row-based access control matrix. In this mechanism each user possess a password for each object it wants access to, this password becomes a ticket to that object. This technique is very similar to capability system except that there are no dynamic domains being used in password protection.

Usually one password per object or one password per object per access mode exists. IBM’s MVS

[6] (Multiple Virtual Storage) and CDC’s NOS

[7] (Network Operating System) have utilized Password mechanism to implement security for protected objects. When using a password protected DAC system there seems to be a lot of problems with it. The usage of password stops the TCB (Trusted Computing Base) from domineering allocation of access permissions. There is no sharing of password allowed within the system, if sharing of password does happen than it has to happen outside the system. It is almost impossible for the user to remember the password for each of the protected objects and if the passwords are stored in the program itself than the system becomes susceptible to security threats or information leakage. To apply restriction to a combination of certain access modes, a password is required for those access modes, but in most system that uses password mechanism, access to a protected object is all or none. In the above mentioned systems, revoking an access privilege from a user requires revoking access from all the users who have the same access privileges and then assigning new passwords to those who are to retain access. This becomes impossible when passwords are stored in programs. To ensure security, passwords must be changed periodically, which is very difficult to achieve in password protected implementation of DAC systems. In MVS the default access to a file is unrestricted access i.e. when a file is created in the MVS environment it is accessible without any restriction. A file is only restricted for access when password protection is initiated for that file. Thus a new file is not protected until the password protection mechanism is activated [1]. If passwords are used as they are used in CDC NOS system

[7] it will give an additional advantage to the mechanism which is used in IBM’s MVS operating system. This advantage is that if each object is protected with a different password than Trojan horse threat can be limited to the extent i.e. each password that is presented to the Trojan horse is vulnerable other than that all objects should be secure. Generally, use of passwords for a complete implementation is always discouraged because there is no way to determine which user has access to which object and also because managing such a system is very difficult and complex. Limitation of DAC: The discretionary access control mechanism in the operating systems was not designed to take buggy software in mind.

Therefore the problem with Discretionary Access Control is that it cannot protect against Trojan horses, Malware, software bugs and malicious users. DAC allows information from an object which can be read to any other object which can be written by a subject i.e. DAC is unable to provide multi-level security. Suppose users of a system are trusted not to do this deliberately. It is still possible for Trojan Horses to copy information from one object to another. Global Policy An individual user can set an access control mechanism to allow or deny access to an object when using DAC. So the access to any object relies on the owner of the object rather than the policy of the DAC. Users can implement their own access control policies on the data they own, regardless of whether those policies are in conflict with the global policies.

Therefore, it is hard to enforce the consistency of the global policy for each of the protected data within the system. Information Flow Information contained in one object can be copied to another object, if the owner of the original object has mentioned in the access control policy that the access to information to the particular object is restricted than the copy which has been made must also satisfy the same. But this is not the case the copy may be accessible and hence therefore conflicts with the original access policy of the object. This has been a major flaw because of which military application does not use this mechanism for implementing security rather they prefer Mandatory Access Control. Malicious Software DAC policies can be easily changed by owner, so a malicious program (e.g., a downloaded untrustworthy program) running by the owner can change DAC policies on behalf of the owner. This basic principle of discretionary access control contains a fundamental flaw that makes it vulnerable to Trojan horses [8]. A Trojan horse does what a user expects it to do, but in addition exploits the user’s legitimate privileges to cause a security breach. On most systems, any program which runs on behalf of a user inherits the DAC access rights of that user [5]. An example of the workings of a Trojan horse will illustrate how most DAC mechanisms are vulnerable.

This example should exhibit to the reader that discretionary access control is only useful to contain the “honest” user in accessing other user’s files and preventing accidental disclosure or destruction of information. This issue can only be resolved by other means that is the malicious user cannot be stopped by using DAC mechanism and therefore another model needs to be used to ensure security with in the system, such as mandatory access control. Reference

[6] contains such an example, which is similar to the following: AN EXAMPLE OF A TROJAN HORSE

[1] Consider a system where an access control list mechanism as described in the earlier sections is used to implement discretionary access control. There are two users on this particular system: an honest user, DOE; and a dishonest user, DRAKE. DOE has a data file which contains highly sensitive data; this file is known as DOESFILE. He has diligently set the ACL to allow only himself to read the file. No other users are authorized to access the file. DOE is confident that no one but himself will be able to access his data file. DRAKE is determined to gain access to DOESFILE. He has legitimate access to the system which allows him to implement a useful utility program. In this utility DRAKE embeds a covert function to read DOESFILE and copy the `contents into a file in DRAKE’s address space called DRAKESFILE. DRAKESFILE has an ACL associated with it that allows processes executing on DOE’s behalf to write to it, while allowing DRAKE’s processes to read it. DRAKE induces DOE to execute his utility program by telling him how useful and efficient it is. DRAKE is careful not to tell DOE about the covert function (Trojan horse) that is resident in the utility program. DOE executes the corrupted program and it appears to perform perfectly. However, while it is operating on DOE’s behalf, it assumes his identity and thus his access rights to DOESFILE. At this time it copies the contents of DOESFILE to DRAKESFILE. This copying takes place completely within the constraints of the DAC mechanism, and DOE is unaware of what is happening. The example above should give a good idea about the danger of Trojan horse attacks and failure to protect against such attacks in most of the DAC mechanisms.

Therefore even a detailed DAC mechanism may provide deceptive security to subject/users who do not know the fact that the mechanism used to implement DAC is vulnerable to Trojan horse attacks. By implementing multiple domains or even a few dynamic domains for each process in the system, Trojan horse threats can be lowered to a certain degree. All of the user’s objects are available to the user’s process which is running on its behalf. For each of the process if creation of domains can be made dynamic with only the necessary objects available in that domain then the Trojan horse will be limited to accessing only those objects which are available in that domain. Least privilege principle can be useful in the above mentioned scenario. The Trojan horse threat can be reduced in systems that implement many domains or dynamic small domains for each process. In most systems today, with only user and supervisor domains, all of the user’s objects are available to a process running on that user’s behalf. If domains were created dynamically for each process, with only the necessary objects available in that domain (implementing the least privilege principle), then a Trojan horse would be limited to accessing only those objects within the domain. CUMBERSOME ADMINISTRATION DAC implementation makes the management of the user complex e.g. a user leaving the company or user being promoted to another function in the company are the scenarios in which the information has to updated manually and if the number of employees in a company is huge than this kind of administration can be hectic and time consuming.

Also because of the nature of the manual administration it can be prone to errors and mistakes which makes the system unreliable. IMPLEMENTATION OF DAC Discretionary Access Control has been used by most of the mainstream operating systems .For instance, DAC is implemented on multi-user operating system such as UNIX and Windows NT. Below is a brief description of the implementation of both the major operating systems that have used DAC to implement their security. Unix/POSIX Access Control Mechanism

[9] Traditional UNIX uses a restricted form of access control list on files. Peripheral devices are represented by special files. Every user is identified by an integer number (user ID). Every user also belongs to at least one group”, each of which is identified by an integer number (group ID). Processes started by a user inherit the user and group ID. Each file carries both an owner’s user ID and a single group ID. Each file carries nine permission bits. The first three specify whether read”, write”, and execute” access is granted if the process user ID matches the file owner ID. Otherwise, if one of the group IDs of the process matches the file group ID, the second bit triplet determines access. If this is also not the case, the final three bits are used. In the case of directories, the read” bits decide whether the names of the files in the directory can be listed and the execute” bits decide whether search” access is granted, that is whether any of the attributes and contents of the files in the directory can be accessed via the directory. The name of a file in a directory that grants execute/search access, but does not grant read access, can be used like a password, because the file can only be accessed by users who know its name.

Write access to a directory is sufficient to remove any file and empty subdirectory in it, independent of the access permissions for what is removed. Berkeley Unix added a tenth access control bit: the sticky bit”. If it is set for a directory, then only the owner of a file in it can move or remove it, even if others have write access to the directory. Many UNIX programs require installation with set-user-ID root, because the capabilities to access many important system functions cannot be granted individually. Only root can perform actions such as: Changing system databases (users, groups, routing tables, etc.) opening standard network port numbers < 1024 interacting directly with peripheral hardware overriding scheduling and memory management mechanisms Applications that need a single of these capabilities have to be granted all of them. If there is security vulnerability in any of these programs, malicious users can often exploit them to gain full superuser privileges as a result. Windows NT/2000/XP Access Control

[9] Microsoft’s NT is an example for considerably more complex access control architecture. All accesses are controlled by a Security Reference Monitor.

Access control is applied to many different object types (files, directories, registry keys, printers, processes, user accounts, etc.). Each object type has its own list of permissions. Files and directories on an NTFS formatted hard disk; for instance, distinguish permissions for the following access operations: Traverse Folder/Execute File, List Folder/Read Data, Read Attributes, Read Extended Attributes, Create Files/Write Data, Create Folders/ Append Data, Write Attributes, Write Extended Attributes, Delete Subfolders and Files, Delete, Read Permissions, Change Permissions, Take Ownership Note how the permissions for files and directories have been arranged for POSIX compatibility. As this long list of permissions is too confusing in practice, a list of common permission options (subsets of the above) has been defined: Read, Read & Execute, Write, Modify, Full Control Every user or group is identified by a security identification number (SID), the NT equivalent of the UNIX user ID. Every object carries a security descriptor (the NT equivalent of the access control information in a UNIX i-node) with SID of the object’s owner SID of the object’s group (only for POSIX compatibility) Access Control List, a list of Access Control Entries (ACEs) Each ACE carries a type (AccessDenied, AccessAllowed, SystemAudit), a SID (representing a user or group), an access permission mask, and an inheritance attribute (specifies whether the ACE refers to the object, its children, or both). Requesting processes provide a desired access mask. With no ACL present, any requested access is granted. With an empty ACL, no access is granted.

All ACEs with matching SID are checked in sequence, until either all requested types of access have been granted by AccessAllowed entries or one has been denied in an AccessDenied entry. GUI interfaces with allow/deny buttons usually place all AccessDenied ACEs before all AccessAllowed ACEs in the ACL, thereby giving them priority. SystemAudit ACEs can be added to an object’s security descriptor to specify which access requests (granted or denied) are audited. Users can also have capabilities that are not tied to specific objects (e.g., bypass traverse checking). Default installations of Windows NT use no access control lists for application software, and every user and any application can modify most programs and operating system components (virus risk). Windows NT has no support for giving elevated privileges to application programs. There is no equivalent to the UNIX set-user-ID bit. A service is an NT program that normally runs continuously from when the machine is booted to its shutdown. A service runs independent of any user and has its own SID. Client programs started by a user can contact a service via a communication pipe, and the service can not only receive commands and data via this pipe, but can also use it to acquire the client’s access permissions temporarily. Detailed practical NT security administration guidelines: https://nsa1.www.conxion.com/ SUMMARY OF DAC MECHANISMS Access control lists are the most appropriate and feasible way of implementing DAC and it satisfies the entire requirement for DAC if implemented properly. Protection bits lack the ability to conveniently control access to each object to the granularity of a single user [1]. Row-based methods, such as capabilities and profiles, may occur with problems such as revocation of access and group access to objects. Passwords should not be used as a primary mechanism to implement DAC. It can provide supplementary functionality and help in avoiding Trojan horse vulnerability when implementing DAC. Its implementation alone as DAC is not recommended. The preferred DAC mechanism within the current state-of-the art is the access control list.

The deletion of the subjects and objects is a potential problem for any DAC mechanism, including ACLs. Regardless of whether a subject or object is deleted the mechanism should handle the deletion efficiently, making sure that any dangling references do not grant unintended access after the deletion. An asset of ACLs is their design, which represents the access control matrix by column. An object’s ACLs are automatically purged when the object is deleted. Unlike row-based mechanisms, ACLs do not require searching the profiles of all the subjects to determine who has access to he deleted object. However, when subjects are removed from the ADP system, ACLs pose the same problem; all system objects must be searched to purge that subject from all ACLs. Since objects are much more volatile than subjects, ACLs are more efficient than profiles [1]. Another improved version of ACLs which is known as Rule-based DAC tries to improve some of the security deficiencies in ACLs but it is still prone to human errors and therefore may still cause security breaches. When a user gets access to a resource in DAC environment then there are no restrictions on data access for that particular user.

Once users can access data, they can change or pass that information onto any other user without the security administrator’s knowledge [10]. Discretionary Access Control cannot deter hostile attempts to access sensitive information. DAC mechanisms can be designed to eliminate casual browsing through the storage system, to prevent accidental disclosure, modification, and destruction of data, and to provide for the sharing of data between users. A mandatory security policy must also be implemented to provide adequate protection if users are not allowed to share all data on the system. An effective audit trail mechanism is also necessary in order to detect hostile attacks on the DAC mechanism [1]. MANDATORY ACCESS CONTROL (MAC) In DAC model access to a particular resource is based on the discretion of the owner of that resource. DAC has had a few problems and one of the problems was when a user gets access to a resource that user has full access privileges to exercise over that object or resource i.e. there is no multi-level security present in DAC. Also the inconsistency of the access control policies in DAC made the system less trustworthy as the priority to allow users to access an object was given to the owners of the objects rather than the system administrator or system policies. As DAC did not fulfil the requirement for very secure and multilevel security for military and intelligence organizations, there was a need of another access control model which could satisfy the needs of such an application which possesses very sensitive and critical information which may be highly confidential. Mandatory access control is another model which can be used to implement access control. It is much more secure and reliable than DAC model but in some cases it is difficult to implement and very complicated for the system administrator to manage it as the policies can be very strict and requires a lot of management from not only one but sometimes multiple system administrator. This is because of the strictness of the model and that it provides high level security for the system which is being implemented. In Mandatory Access Control model the access to objects is based on a system-wide policy and is completed controlled and monitored by that policy, for example to prevent certain flows of information. Using the system-wide policy MAC can deny users full control over the access to resources that they create. The system security policy (as set by the administrator) entirely determines the access rights granted. In some forms, the system maintains security labels for both objects (resources, information) and subjects (processes, users), based on which access is granted or denied. Labels can change as the result of an access.

Security policies are enforced without the cooperation of users or application programs [9]. When using MAC as the access control model, restrictions to allowed information flows are not decided at the user’s discretion (as with UNIX chmod which uses DACs implementation), but instead enforced by system policies. A system-wide policy judges who is allowed to have access; individual user are not allowed to make modifications in that access. Mandatory access control mechanisms particularly aims towards avoiding system-wide policy violations by untrustworthy application software, which have at least the same access privileges as the invoking user.

These policy based restrictions eliminate the possibility of Trojan horse problem that was present in Discretionary Access Control models. The access of resources/objects relies on the system when MAC is used to implement access control within a system because granting or invoking access is controlled by the system policies rather than the owner of the resource itself. A real life example of the MAC model can be as follows: The law states that a court can have access to driving records without the permission of the owner of those records. In this case law can be seen as the system policy which states that a court can have access to driving records of a person without that person’s permission. The person whose driving records are being checked can be taken as the owner of the resource and the resource or object in this scenario are the driving records itself. The court can be seen as the subject who wants access to the driving records. Traditional MAC mechanism have been tightly coupled to a very few models and there use was limited to special purpose military applications only.

Usable MAC systems are not readily available i.e. implementation Mandatory Access Control security is only achieved through proper policy configuration, which is extremely difficult to do even for the security experts. Recently, systems supporting flexible security models started to appear and operating systems like SELinux (Security Enhanced Linux), Trusted Solaris, TrustedBSD etc. have used MAC model to enhance the security of these operating systems. Initial implementation of MAC used Bell-LaPadula Security Policy Model, which was used to implement time-sharing mainframe systems of U.S. Airforce when concerns were shown over the systems security. MAC MECHANISMS Security Policy Model A security policy model is a succinct statement of the protection properties that a system, or generic type of system, must have. Multi-Level Security (MLS) The capability of a computer system to carry information with different level of sensitivities (i.e. classified information at different security levels), permit simultaneous access by users with different security clearances and needs-to-know, and prevent users from obtaining access to information for which they lack authorization. People and information are classified into different levels of trust and sensitivity. These levels represent the well-known security classifications: Unclassified, Confidential, Secret, Top Secret.

Typically MAC uses this mechanism to be used in the implementation of different systems. The primary goal of this mechanism is to achieve confidentiality among users of the system and restricting unauthorised access of sensitive and critical information. The security classifications levels mentioned above can be represented in the figure mentioned below: Clearance Level Clearance Level indicates the level of trust given to a person with a security clearance, or a computer that processes classified information, or an area that has been physically secured for storing classified information. The level indicates the highest level of classified information to be stored or handled by the person, device, or location. Classification Level Classification level indicates the level of sensitivity associated with some information, like that in a document or a computer file.

The level is supposed to indicate the degree of damage the country could suffer if the information is disclosed to an enemy. [A Multi-Purpose Implementation of Mandatory Access Control in Relational Database Management Systems ] WORKING OF MAC Mandatory Access Control (MAC) is a means of restricting access to objects based on the sensitivity (as represented by a label) of the information contained in the objects and the formal authorization (i.e., clearance) of subjects to access information of such sensitivity [12]. A well-known implementation of MAC is Multilevel Security (MLS), which, traditionally, has been available mainly on computer and software systems deployed at highly sensitive government organizations such as the intelligence community or the U.S. Department of Defence. The Basic model of MLS was first introduced by Bell and LaPadula [13]. The Bell-LaPadula Security Policy Model This model is the most widely recognized MLS model and has been in use for the implementation of multi-level security in different application areas. Bell-LaPadula model deals with the confidentiality of the system being implemented. It was proposed by David Bell and Len LaPadula in 1973, it was built to remove the security deficiencies which were mentioned by the U.S. Airforce in the time-sharing mainframe systems. Bell-LaPadula [15] is a formal policy model for mandatory access control in a military multilevel security environment. In this model the system policy automatically prevents the flow of information from high-level objects to lower levels. A process that reads top secret data becomes tagged as top secret by the operating system, as will be all files into which it writes afterwards. The model consists of objects and subjects. An object is a passive entity such as a data file, a record, or a field within a record. A subject is an active process that can request access to objects.

Every object is assigned a classification, and every subject a clearance. Classifications and clearances are collectively referred to as labels. A label is a piece of information that consists of two components: A hierarchical component and a set of unordered compartments.

The hierarchical component specifies the sensitivity of the data. For example, a military organization might define levels Top Secret, Secret, Confidential and Unclassified. The compartments component is non-hierarchical. Compartments are used to identify areas that describe the sensitivity or category of the labelled data.

For example, a military organization might define compartments NATO, Nuclear and Army. Labels are partially ordered in a lattice as follows: Given two labels L1 and L2, L1 >= L2 if and only if the hierarchical component of L1 is greater than or equal to that of L2, and the compartment component of L1 includes the compartment component of L2. L1 is said to dominate L2. MLS imposes the following two restrictions on all data accesses: The Simple Security Property or No Read Up: A subject is allowed a read access to an object if and only if the subject’s label dominates the object’s label. The *-Property (pronounced the star property) or No Write Down: The *-property was Bell and LaPadula’s vital innovation to the security flaws such as Trojan horse programs and software deficiency which can lead to the copying of classified information to a unclassified area where the attackers are able to access that information. By applying this property a subject is allowed a write access to an object if and only if the object’s label dominates the subject’s label. The Biba Model In 1977, Kenneth J. Biba developed the Biba Model or Biba Integrity Model, in which the nature of the integrity of systems was studied. This security model is more concerned with data integrity rather than confidentiality which is the basis in the Bell-LaPadula model. Biba model imposes the two restrictions “no write up and no read down” which are opposite to the Bell-LaPadula model. Biba model deals with integrity only and completely ignores confidentiality; this model covers integrity levels, which are analogous to sensitivity levels in Bell-LaPadula.

Integrity levels cover inappropriate modification of data and prevent unauthorized users from making modifications. The two properties of Biba model are: Simple Integrity Property or No Write Up: A low integrity subject will not write or modify high integrity data. *-Property or No Read Down: The high integrity subject will not read low integrity data. Read Up, Write Down – Subjects cannot read objects of lesser integrity, subjects cannot write to objects of higher integrity. MAC IMPLEMENTATIONS – Security Enhanced Linux (SELinux) Overview SELinux provides a flexible Mandatory Access Control (MAC) system built into the Linux kernel. Under standard Linux Discretionary Access Control (DAC), an application or process running as a user (UID or SUID) has the user’s permissions to objects such as files, sockets, and other processes. Running a MAC kernel protects the system from malicious or flawed applications that can damage or destroy the system. SELinux defines the access and transition rights of every user, application, process, and file on the system. SELinux then governs the interactions of these entities using a security policy that specifies how strict or lenient a given Red Hat Enterprise Linux installation should be. On a day-to-day basis, system users will be largely unaware of SELinux.

Only system administrators need to consider how strict a policy to implement for their server environment. The policy can be as strict or as lenient as needed, and is very finely detailed. This detail gives the SELinux kernel complete, granular control over the entire system. The Decision Making Process When a subject, (for example, an application), attempts to access an object (for example, a file), the policy enforcement server in the kernel checks an access vector cache (AVC), where subject and object permissions are cached. If a decision cannot be made based on data in the AVC, the request continues to the security server, which looks up the security context of the application and the file in a matrix. Permission is then granted or denied, with an avc: denied message detailed in /var/log/messages if permission is denied. The security context of subjects and objects is applied from the installed policy, which also provides the information to populate the security server’s matrix.

Refer to the following diagram for SELinux decision process: SELinux Decision Process Operating Modes Instead of running in enforcing mode, SELinux can run in permissive mode, where the AVC is checked and denials are logged, but SELinux does not enforce the policy. This can be useful for troubleshooting and for developing or fine-tuning SELinux policy. MANDATORY ACCESS CONTROL VS DISCRETIONARY ACCESS CONTROL A reference monitor which implements a mandatory security policy which includes the *-property would provide robust protection against Trojan horse attacks.

The mandatory access control implementation would prevent the Trojan horse from disclosing the information to a user who is not permitted access to the information under the mandatory access rules. Assume the same scenario as was described previously with the following changes. The computer system now implements a mandatory security policy with two hierarchical sensitivity levels. For the sake of simplicity, the levels are called sensitive and non-sensitive. DOE operates at the sensitive level, and DOESFILE is sensitive. DRAKE is not authorized to access sensitive data, so he operates at the non-sensitive level. DRAKE is only allowed to read non-sensitive files, so DRAKESFILE is non-sensitive. As before, DRAKE’s Trojan horse program is executed by DOE. The program takes on the sensitivity level and the identity of DOE. Within the constraints of the mandatory and the discretionary security policies, the program reads DOESFILE. However, when the Trojan horse tries to write the sensitive data to DRAKESFILE, the reference monitor disallows the operation.

Since the Trojan horse is now executing at the sensitive level, the program cannot be allowed to write to a non-sensitive file. That would be a violation of the *-property [1]. This example should show the reader that discretionary access control is only effective to restrict the “honest” user in browsing through other users’ files and preventing accidental disclosure or destruction of information. The malicious user who is determined to gain unauthorized access to data on the computer system must be restricted by other means, such as mandatory access controls. ROLE-BASED ACCESS CONTROL RBAC has emerged as a viable alternative to traditional access control policies, such as DAC and MAC, because it is based on an enterprise’s organizational structure. As such, systems, data, and applications administrators and owners can more effectively manage and maintain information resources in a manner consistent with enterprise-wide security policies. RBAC has the further benefit of facilitating systems administration by assigning roles to manage users as opposed to using each individual user’s identity to manage users. Although role-based security models have existed for 20 years, their application has until recently been limited. To date, most systems have based access control on the discretion of the owner or administrator of the data as opposed to basing access on organizational or policy needs as is done with RBAC. These owner-controlled systems worked adequately for small local area networks (LAN) but have become cumbersome to manage and errors prone as networking capabilities have increased. The explosion of electronic data exchange and interconnection of information systems led to significant productivity gains in the 1990s. However, these same factors have also increased electronic security and integrity concerns. Confidentiality restriction and regulatory requirements have caused organizations to look for improved approaches to manage the types of users that may have access to which data and to which applications.

The result is a renewed and growing interest in role-based security models. Several organizations, including NIST, have been working since the early 1990s to define a common standard for RBAC and to spur its implementation by providing research and development support to this emerging technology. Although relatively few software companies currently market RBAC and RBAC-enabled products, the market for these products is expected to grow rapidly in the near future. This section This section provides background information needed to understand RBAC in the context of the marketplace, including RBAC’s benefits and the barriers to its adoption. The following issues are discussed: technical characteristics and underlying concepts of RBAC, including a comparison of RBAC to defender access control models; benefits of RBAC, particularly those related to administering computer networks, both within an organization and its extranet; RBAC industry supply chain, including information on the software developers who supply RBAC-enabled software and the characteristics of end users who purchase this software; barriers software developers face when developing and integrating RBAC models into their products; barriers software end users face in implementing RBAC; NIST’s contribution to the development and deployment of RBAC and the mitigation of market barriers. RBAC Technical Characteristics Access control is generally concerned with determining what users and groups of users can perform what operations on what resources.

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. For many organizations, the number of systems can be in the hundreds or even thousands, the number of users can range from the hundreds to the hundreds of thousands, and the number of resources that must be protected can easily exceed a million. RBAC is designed to centrally manage privileges by providing layers of abstractions that are mapped one-to-many to real users and real operations and real resources.Managing permissions in terms of the abstractions reduces complexity and provides visualization and a context for implementing complex access control policies. Abstractions can be centrally managed resulting in real permissions on real systems. In taking advantage of these abstractions RBAC offers greater administrative efficiency as well as the ability to intuitively administer and enforce a wide range of access control policies. In RBAC, permissions are associated with roles, and users are made members of roles, thereby acquiring the role’s permissions. The implementation of this basic concept has been shown to greatly simplify access control management. Roles are centrally created for the various job functions in an organization, and users are assigned roles based on their responsibilities and qualifications. As such, users can be easily reassigned from one role to another.

Users can be granted new permissions as new applications and systems are incorporated, and permissions can be revoked from roles as needed. For example, if a user moves to a new function within the organization, the user can simply be assigned to the new role and removed from the old one, whereas in the absence of RBAC, the user’s old privileges would have to be individually located, revoked, and new privileges would have to be granted. To provide further administrative efficiency, RBAC allows roles to inherit other roles and as such form role hierarchies.

For example, the role cardiologist is hierarchically superior to the role doctor, if the cardiologist has (inherits) all of the privileges of the doctor, and the users that are authorized for the cardiologist role are also authorized for the doctor role. RBAC provides the capability to visualize and manage user privileges across heterogonous platforms and applications. By centrally storing and managing roles as both collections of users and collections of privileges, RBAC is able to define, constrain, review, and enforce access control policies as user/role, role/role, or role/privilege relations. RBAC is considered to be policy-neutral in the sense that, by using role hierarchies and constraints, a wide range of security policies can be expressed to include traditional DAC as well as a variety of nondiscretionary separation of duty (SOD) policies through the definition of constraints. This remainder of section provides more details on the interaction among roles, users, and permissions. It also discusses the RBAC models that have been developed and compares them to alternative access control models, such as access control lists and MAC. Users, Roles, and Permissions Traditionally, the prevalent approach to granting access to information within a particular database or access to a particular application is to establish specific permissions for each user within an organization. If the user must have access to multiple applications and databases, the user must be assigned permissions for each resource. This approach is problematic for several reasons. When users enter, leave, or change responsibilities within an organization, updating the permissions of each user is difficult, time consuming, and possibly error-prone (Barkley and Cincotta, 1998). In addition, this approach leads to potential violations of information and system security. RBAC avoids these problems because it uses the user’s role as the key to access rather than the user’s identification. In a role-based model, each user may be assigned to multiple roles, and each role may have multiple users. The roles that users are assigned depend on their job responsibilities, and each role is assigned permissions.

Permissions determine the data and applications that may be accessed and each role is assigned the set of permissions that are necessary for the user to perform his required tasks. Users’ roles can pertain to specific jobs (bank teller, bank manager), geographic locations (New York, Chicago), or individual descriptors (trainee, shift supervisor). In most situations, users within the organization change more frequently than the roles or job functions within the organization. By associating roles with permissions and changing the users within the roles, administrative expenses decrease. If an organization experiences a significant amount of worker turnover relative to role turnover, RBAC can provide significant cost savings (Ferraiolo and Kuhn, 1992). Least Privilege Roles improve security within a network by using the principle of least privilege. When a role is created within an organization, the user’s level of access to information needs to be determined. Least privilege means that once access requirements are determined, that role should only be given permissions to accomplish the required tasks; no additional permissions should be given. In networks without role-based policies, users often have access permissions exceeding what is necessary. Where job responsibilities overlap job categories, administrators may be unable to limit access to sensitive information. RBAC improves security within the network because it prevents users from having access to information outside of their roles.

This denial of access prevents users from circumventing the security policy within the network. Separation of Duties Within a larger task that the organization must accomplish, several subtasks may need to be performed. Because the subtasks may be separated into different roles, it is extremely difficult for a single individual to engage in fraud against the organization. The most common example of separation of duties is the separate subtasks involved in authorizing a payment for a particular transaction. By separating submission for payment and authorization for payment into separate roles, no individual can accomplish both tasks. This mutually exclusive separation reduces the possibility of fraud within the organization.

The specific separation of duties depends on the nature of the tasks and subtasks that the firm must accomplish. In some cases, the complete separation of tasks (submission and authorization) may be too difficult. Thus, the security advantage is outweighed by the additional transactions cost of accomplishing the task. In these cases, a more dynamic separation of duties could occur where the permissions within the role allow for submission and authorization. However, the same user cannot submit and authorize the same payment. A crosscheck of user and role within the same task could be added to the system to accomplish the desired task (Ferraiolo and Kuhn, 1992). 2.1.2 RBAC Models and Evolution The benefit of using roles to manage permissions is not a new concept, but the actual use of roles in network administration policy is new. A consensus has yet to emerge within the computer network and security community on what RBAC means, although role-based security models have been in existence for nearly 20 years. As a result, the spectrum of RBAC definitions includes models that range from the simple to the sophisticated. Sandhu (1998) and Sandhu et al. (1997) analyze the various definitions of RBAC. They define the basic RBAC model, referred to as RBAC0, as including least privileges and separation of duties. Subsequent RBAC models build on this basic model, introducing new concepts of hierarchies and constraints that enhance administrative and security benefits (see Figure 2-2). RBAC0 (Flat RBAC) The base model RBAC0 consists of that part of Figure 1(b) not identified with one of the three advanced models.

There are three sets of entities called users (U), roles (R), and permissions (P). The diagram also shows a collection of sessions (S). A user in this model is a human being. The concept of a user can be generalized to include intelligent autonomous agents such as robots, immobile computers, or even networks of computers.

For simplicity, we focus on a user as a human being. A role is a job function or job title within the organization with some associated semantics regarding the authority and responsibility conferred on a member of the role. RBAC1 (Hierarchical RBAC) RBAC1 is based on RBAC0 and introduces the concept of role hierarchies. Role hierarchies are a natural extension of the authority and responsibility roles that exist within an organization. For example, an organization may have junior and senior roles. When role hierarchies are introduced, the senior role (e.g., bank president) has access to all of the information that the junior role (e.g., bank teller) has access to, but not vice versa. This approach can increase the administrative efficiency of the network.

Rather than respecifying all of the permissions of the junior role for the senior role, the junior role is specified as a permission of the senior role. As the levels of the organization or the numbers of permissions increase, the greater the benefit from establishing role hierarchies. RBAC2 (Constrained RBAC) RBAC2 is also based on the original RBAC0 model but introduces the concept of constraints. The most frequent use of constraints is to achieve separation of duties within an organization. For example, a constraint can state that if a user has a particular role, that user cannot be assigned a separate role. However, constraints can also be used in many other situations. Constraints can be used to establish membership to a particular role. If an organization wants to have only one department head, then it can impose a particular constraint stating that if someone is in a particular role, then no one else can be admitted to that role.

This concept has been referred to as cardinality. Constraints can also be used as prerequisites for entry into roles. For example, the only way that role x can be assigned to a user is if the user is already in role y. RBAC3 (Symmetric RBAC) The NIST RBAC model is RBAC3. It is the most complex RBAC model, including both role hierarchies and constraints. In RBAC3, constraints can be imposed on the hierarchical roles within an organization. For example, junior roles can be constrained to have a maximum number of senior roles, multiple junior roles can be constrained to have different senior roles, or constraints can be imposed on users to limit the number of senior roles to which they can be assigned.

The sensitive interactions that occur between role hierarchies and constraints in RBAC3 make it the most sophisticated and complex RBAC model. BENEFITS OF RBAC Using roles to determine and manage access permissions allows system administrators to better incorporate least privilege and separation of duties into administrative policies. As discussed, RBAC exists in many forms, but even its simplest form is an improvement over alternative methods. RBAC features such as policy neutrality, principle of least privilege, and ease of management make [RBAC models] especially suitable candidates…Such models can express both DAC and MAC policies, as well as user-specific policies. In essence, RBAC models can provide generic framework for expressing diverse security requirements (Joshi et al., 2001a). In this section, we discuss the types of benefits associated with using RBAC rather than another method. Key benefits are: Simplified systems administration Enhanced organizational productivity Reduction in new employee downtime Enhanced systems security and integrity Simplified regulatory compliance. Simplified Systems Administration Once an RBAC system is established, the costs associated with administering and monitoring the network are less than those associated with alternative access control models. Several factors influence the magnitude of the cost decrease. First, the greater employee turnover, and in turn the number of people changing roles, the greater the cost savings of RBAC relative to other access control systems. Second, some firms or organizations are very dynamic, and user roles and permissions change quickly. In these environments, RBAC is more efficient in moving users in and out of given roles and changing the permissions of given roles than competing access control systems.

This improved efficiency is observable in the decrease in labour hours that the computer network support team spends on administrative tasks. In addition to reducing system administration costs, the automated access control systems supported by RBAC reduce the burden on upper management. In alternative access control systems, upper management is integrally involved in determining individual privileges and authorizing access for each new employee. RBAC’s organizational structure supports the automation of this process. Several issues must be weighed when granting access permissions. Security administrators need to balance the Complexity of the position being assigned privileges Complexity of the organization Security level required Data and application needs of the position Organizational issues By assigning a predetermined role to the user, the labor expense of assigning permissions is significantly reduced, thus freeing labor resources for other tasks. RBAC is a scalable model, meaning that the model can work as well in large environments covering several offices and classes of users as it can in one-office environments.

Roles matching job positions may be determined in a central office, but the actual assigning of roles to or changing of roles for new employees can occur at each branch office by an administrator. This concept, frequently referred to as delegated administration, can be of particular benefit to organizations with several branch, subsidiary, or contractor locations, such as health care plans, insurance companies, banks, and similar organizations (see Figure 2-4). Enhanced Organizational Productivity RBAC also has the potential to enhance the system by which firms and organizations structure their information systems. Because of the greater flexibility and breadth of network design associated with RBAC, the model can be adapted to mirror the organizational structure. This creates the potential for new and innovative ways of structuring the organization, altering the routing of information, or changing the organization’s production processes.

Organizations can benefit from the consistency in infrastructure across divisions or units within the same entity. Additionally, improved business standards may result in cost savings. The synergistic improvements that may occur within a company could have potentially large impacts on employee productivity. Reduction in New Employee Downtime RBAC accelerates bringing new employees to full productivity. New employees are employees that are new to the organization or are existing employees that are placed in a new position within the company. During this time period, new employees may only be marginally or partially productive. RBAC can reduce the time for establishing access, and the RBAC structure enables the automation of establishing and verifying access. Enhanced Systems Security and Integrity Role-based access models offer improved security and audit trails over alternative methods. RBAC is able to reduce the impact from security violations in two ways.

First, RBAC can decrease the likelihood that a security violation occurs. Second, if a security violation occurs, RBAC can limit the damage from the violation. Roles limit the possibility of internal security breaches from individuals who should not have access to the data and applications associated with each function. Furthermore, because privileges are not assigned manually, it is less likely that the security administrator will make an error and inadvertently grant a user access to information or applications to which he or she would otherwise be prohibited. Additionally, productivity may increase from RBAC’s improved security of network resources and increased information access. As a result, companies may increase their confidence in their computer systems and be able to increase the sharing of resources, being less concerned about potential security violations. Simplified Regulatory Compliance In an age of increasing electronic integration, data security and integrity have become political and economic issues.

Incidences of breaches in data security are well documented, as is the sharing of personal information among companies trying to find a stronger foothold in today’s highly competitive markets. To protect the confidentiality of both individuals and their personally identifiable information, recent federal laws have included provisions that dictate the type and the extent to which individuals’ information can be shared both within an organization and with others. These laws, including the Health Insurance Portability and Accountability Act (HIPAA) and the Gramm-Leach-Bliley Act (GLBA) of 1999, require data managers to securely maintain and limit the distribution of data. To comply, companies are required to use access control policies that will safeguard data. RBAC is one such policy that may be best suited for this purpose. This section discusses recent Acts and the way RBAC supports compliance. The Health Insurance Portability and Accountability Act HIPAA is a health care reform initiative enacted in 1996 to add a dimension of portability to workers’ health insurance as they transition between states of employment. HIPAA also contains privacy provisions that apply to health information created or maintained by health care providers who engage in certain electronic transactions, such as health plans, and health care clearinghouses. To meet privacy compliance obligations, entities must maintain secure information systems that have the functionality to prevent the willful or unintentional disclosure of any individual’s health records and or personal information to unauthorized parties. RBAC facilitates HIPAA compliance by providing an access control structure that permits only people in certain roles to access certain types of information, such as patients’ medical records. For example, a health care provider may assign a contracting physician a certain role that allows the doctor access to medical records, but office staff in charge of billing and administrative tasks may be assigned another role that permits access to claims information but not medical records. Although HIPAA does not explicitly mention any given access control model in the final rule, its implementer, the Department of Health and Human Services (DHHS), specifically espouses RBAC as a security model to safeguard health data. In fact, DHHS’s Health Care Financing Administration (HCFA) refers queries about role-based access to NIST publications and the NIST web site in its General Questions section about HIPAA. Responding to one question about role-based access, HCFA writes please review Chapter 17’Logical Access Control’ of NIST SP 800-12, ‘An Introduction to Computer Security: The NIST Handbook’ (HCFA, 2001). Figure 2-5 is a simplified example of how RBAC can be used to comply with HIPPA from the perspective of the health care organization (HCO). Using an RBAC system, the HCO can limit which users can access which types of data. For example, a billing clerk at a doctor’s office may access a patient’s contact and billing information but not her medical history. A doctor, on the other hand, has full access to the patient’s medical history. Figure 2-5. Heath Care Industry Example of Using RBAC to Control Access to Sensitive Information Organizations in the health care industry can leverage RBAC to meet HIPAA requirements by allowing only users in select roles to access particular data. Other Acts In addition to HIPAA, several other Acts were enacted in the late 1990s that include extensive provisions concerning the privacy of consumers’ personal information.

These include the GLBA of 1999 and the Telecommunications Act (Telecom Act) of 1996. The GLBA eliminates the barriers between banking, investment banking, and insurance activities and companies dating from the Depressionera Glass-Steagall Act. Similarly, the Telecom Act, intended to increase and allow competition in telecommunications, allows communications business to enter any market and to compete against each other. Although the main goal of both the GLBA and the Telecom Act is to increase competition in previously tightly regulated markets, the new provisions for the protection of consumer information generated some of the most interest (Ledig, 2000). Both Acts specify the manner in which personal data can be exchanged among companies and among divisions of companies. They also lay out which information must be held in confidence and which may be distributed in aggregate form, if at all.

The GLBA goes further than the Telecom Act by giving consumers the authority to block the exchange of any information concerning themselves or their accounts among or within companies except as concerns the maintenance of their accounts. Although neither Act indicates or explicitly requires an access control method, RBAC is one way through which companies can restrict which classes of information may be viewed by certain types of users. 2.3 RBAC-ENABLED PRODUCT SUPPLY CHAIN Several software companies produce RBAC and RBAC-enabled software. These products range from commercially available offthe-shelf to custom-designed software. The majority of commercially available products are designed to manage access permissions to information resources within an enterprise’s networked environments, such as local-area or wide-area networks, referred to collectively as the intranet environment.

However, a significant growth area in the near future will be for RBAC products managing Internet-accessible systems, also referred to as extranets. Most of the examples in this report approach RBAC from the perspective of its use in the intranet environment. However, neither RBAC’s application and technical characteristics nor its benefits or costs differ by environment. There is little difference in the technology or methodology of defining and creating roles and incorporating applications between the intranet and the Internet environments. RBAC via the Internet supports and enhances business activities by more efficiently connecting end users to Internet-based applications. Although Internet-based applications would have existed with or without RBAC, RBAC decreases the administration and maintenance costs of these applications and enhances their security (Joshi et al., 2001b). To deliver these applications over the Internet, different classes of end users, such as customers or contractors, may be assigned roles to maintain or verify their own accounts, reducing the administrative load on the firm. Once these end users have enrolled, they may be able to register and maintain account information, alter their product or service packages, submit requests or questions, and settle payments. In such a large computing environment, it may be desirable to have users register and maintain their own accounts. It should be stated here that RBAC’s application is not limited to managing permissions in networked environments.

Individual databases or applications may also have an RBAC system. Although the economic benefits of RBAC are hypothesized to be concentrated in RBAC’s use in networked environments, RBAC will also be used to manage access to any form of information resource, including data sets, applications, or other systems. An enterprise does not need to have an RBAC policy mapped to its organizational structure in these instances, but a policy that is naturally mapped against that particular resource’s user structure. Even in such a focused application, the owner of that resource accrues both the benefits and costs of RBAC. 2.3.1 Software Developers Software developers design, program, and market systems and applications software to manage user access. These software packages may or may not have the ability to control user access using roles.

Those that do are said to be RBAC-enabled or have RBAC functionality. Software that is RBAC-enabled has a module or administrative tool feature that allows an administrator to create and restrict access to roles. Some software vendors offer an optional RBAC module that can be integrated with their customers’ software suites. Presently, most software systems with RBAC functionality are systems software. At the time this study was completed, relatively few software developers had RBAC-enabled products commercially available. However, software developers forecast that the market for such products will increase significantly, driven by information security and privacy concerns.

Table 2-1 lists some firms that currently market RBAC and RBAC-enabled software. These firms’ software products fall into several categories, including security management, electronic commerce infrastructure and platforms, operating systems, and access control, with most products belonging to more than one category. Table 2-1. Sampling of Software Developers Currently Offering RBAC and RBAC-Enabled Products Several software developers currently offer RBAC and RBAC-enabled products.

The list below is representative of firms that offer package solutions. It should be noted that other types of firms not listed here, including computer consulting firms, may offer custom-designed solutions. Some end users also design RBAC systems in-house. Access360, Inc. Adexa, Inc. BEA Systems, Inc. Cisco Systems, Inc. Entrust, Inc. Entrust Information Security Corp. International Business Machines Corp. Internet Security Systems, Inc. iPlanet E-Commerce Solutions Microsoft Corp. Network Associates, Inc. OpenNetwork Technologies, Inc. Oracle Corp. PGP Security, Inc Protegrity, Inc. RSA Security, Inc. Secure Computing Corp. Siemens AG SETA Corp. Sun Microsytems, Inc. Sybase, Inc. Symantec Corp. Systor AG Tivoli Systems, Inc. Vignette Corp. Baltimore Technologies, Inc. BMC Software, Inc. Novell Corp. Radiant Logic, Inc. 2.3.2 End Users RBAC can be used in almost any sector that uses a computer network to limit user access to particular pieces of information. But RBAC is most likely to be of significant benefit to organizations with many employees and/or multiple locations. The following sectors are likely to have the highest RBAC adoption rates: Banking Health care Government agencies, Telecommunications Computer Applications security Military A recent report by SETA Corporation (1996) for NIST points out that certain characteristics within specific firms or sectors magnify the benefits from RBAC. These characteristics include, but are not limited to: User Characteristics A large number of users Few security administrators High turnover rate Large number of data objects Data Characteristics Stable set of applications Little change of roles within firm Job-dependent access to information Stable organiational structure Organizational Characteristics The organization owns the data and applications The organization controls data and application access User accountability is required within the organization Reassessment of the access control policy occurs within the organization Barriers to RBAC Development and Implementation and NIST’s Contributions Two general categories of market failures affect RBAC: barriers to the technological development and integration of RBAC into software products, and barriers to adoption and implementation of RBAC-enabled products by end users. We address the first set of barriers, which primarily affect software developers (and in-house developers) of RBAC-enabled products and are in large part due to RBAC’s generic technology attributes. We discuss RBAC’s infratechnology-related market barriers that primarily affect adoption and implementation by end users.

The section concludes with an overview of NIST’s response to these market failures through its RBAC project. 3.1 BARRIERS TO TECHNOLOGY DEVELOPMENT AND INTEGRATION OF RBAC MODELS INTO SOFTWARE PRODUCTS The barriers to private-sector development and integration of RBAC into software products stem from the uncertainty about the success and costs of the applied research and product development and the difficulties in appropriating returns to their R&D investments. These barriers are rooted in the concept of generic technologies, which have many of the characteristics of public goods. Generic implies that once a base model has been developed it may be easily applied in numerous other commercial settings, including other companies appropriating the model for use in competing products.1 RBAC is a generic technology for this very reason. The development of generic technologies is generally slow because they can be applied in numerous settings, industries, or firms. Additionally, because once the knowledge is generated and the standardization of a technique occurs, appropriating the benefits to the innovating entity is difficult. Generic technologies are similar to public goods in that they have the characteristics of nonrivalry and nonexcludability.2 RBAC is nonrival because one firm’s use of RBAC does not affect another firm’s use. RBAC is also nonexcludable because one firm cannot prevent another firm from using the fundamental concepts of roles as the basic technology is advanced.

Public goods are typically underprovided by private markets as compared to their socially optimal levels of provision (Stiglitz, 1988). This section discusses the barriers to developing and integrating RBAC models in commercial software products that result from RBAC’s generic technology characteristics. These barriers include the Need for technical expertise outside the software industry’s domain. lack of a consistent definition for RBAC, and Difficulty in appropriating returns to investment. The first two factors lead to uncertainty in the success and costs of RBAC R&D. The third factor leads to uncertainty in the company’s ability to appropriate returns from its RBAC investments. All of these factors can delay the availability of RBAC-enabled products. When appropriate, we discuss NIST’s role in addressing these market failures. A more detailed discussion of NIST’s specific activities and expenditures is included in Section 3.3. Access Control Introduction Access control is the traditional center of gravity of computer security. It is where security engineering meets computer science.

Its function is to control which principals (persons, processes, machines, . . .) have access to which resources in the system which files they can read, which programs they can execute, how they share data with other principals, and so on. Access control works at a number of levels, as shown in Figure 4.1, and described in the following: As we work up from the hardware through the operating system and middleware to the application layer, the controls become progressively more complex and less reliable. Most actual computer frauds involve staff accidentally discovering features of the application code that they can exploit in an opportunistic way, or just abusing features of the application that they were trusted not to. Groups and Roles Access control matrices (whether in two or three dimensions) can be used to implement protection mechanisms, as well as just model them. But they do not scale well. For instance, a bank with 50,000 staff and 300 applications would have an access control matrix of 15 million entries. This is inconveniently large. It might not only impose a performance problem but also be vulnerable to administrators’ mistakes. We will usually need a more compact way of storing and managing this information. The two main ways of doing this are to use groups or roles to manage the privileges of large sets of users simultaneously, or to store the access control matrix either by columns (access control lists) or rows (capabilities, sometimes known as tickets) or certificates [662, 804]. When we look at large organizations, we usually find that most staff fit into one or other of a small number of categories. A bank might have 40 or 50 such categories: teller, chief teller, branch accountant, branch manager, and so on. The remainder (such as the security manager, and chief foreign exchange dealer,…), who need to have their access rights defined individually, may amount to only a few dozen people. So we want a small number of predefined groups, or functional roles, to which staff can be assigned. Some people use the words group and role interchangeably, and with many systems they are; but the more careful definition is that a group is a list of principals, while a role is a fixed set of access permissions that one or more principals may assume for a period of time using some defined procedure.

The classic example of a role is the officer of the watch on a ship. There is exactly one watchkeeper at any one time, and there is a formal procedure whereby one officer relieves another when the watch changes. In fact, in most military applications, it’s the role that matters rather than the individual. RBAC RBAC is a technology that offers an alternative to traditional discretionary access control (DAC) and mandatory access control (MAC) policies. RBAC allows companies to specify and enforce security policies that map naturally to the organization’s structure.

That is, the natural method for assigning access to information in a company is based on the individual’s need for the information, which is a function of his job, or role, within the organization. RBAC allows a security administrator to use the natural structure of the organization to implement and enforce security policy. This model decreases the cost of network administration while improving the enforcement of network security policies. DYNAMIC EVENT BASED RBAC The features of RBAC that make it suitable for use in the centralized case are not necessarily so relevant in certain distributed computing contexts. In certain distributed environments, entities that request access to resources may not be known to enterprises with resources to protect (i.e., users may be stranger agents), open access policies are natural to adopt [8], as well as closed policies, decisions on access are more likely to need to be delegated to third-parties (e.g., in the case where the information about the identity or attributes of requesters may be required), the qualifications and responsibilities of requesters do not necessarily have any significance, in terms of access control, and the notion of a job function may not apply (as requesters for access to an enterprise’s resources may have no connection with the enterprise). Although the features of RBAC naturally map to organizational structures, for many distributed applications the concept of an organizational structure may be irrelevant. The size, complexity and dynamic nature of some distributed systems present particular challenges that demand that changes to access policies be made frequently (e.g., in response to sales patterns and volumes) and by autonomous means (rather than by human security administrators manually modifying policy specifications). In the decentralized case, modifications to access policies for protecting an organization’s assets may need to be made in response to events in external environments over which a policy administrator has no control, and about which administrators may not have complete information. Moreover, the high complexity of access control policies in the decentralized case demands not only that rich forms of language be used to represent these requirements but also that effective proof methods be employed to guarantee satisfaction of properties of policies. To address the requirements for formal access policy representation for dynamic, distributed information systems, we propose an event-based distributed access control model, we demonstrate how and why access control policies, defined in terms of our model, should be considered as term rewrite systems [16, 23, 4], and we introduce distributed term rewriting systems.

The model that we propose, and its representation using term rewriting, contributes to the literature on formal access control models by demonstrating how access control models may be defined that enable the autonomous changing of access control policies, the proving of properties of policies, and the efficient evaluation of access requests when the sources of access control and user requested information may be widely dispersed. We call the access control model that we introduce the Dynamic Event- Based Access Control (DEBAC) model. The DEBAC model addresses a number of limitations of RBAC when the latter is applied in distributed computational contexts: that in certain distributed environments, entities that request access to resources may not be known (so it is not possible to authorize access on the basis of a job function/role); that user authorizations may change dynamically on the basis of the occurrence of a wider range of events than the role and permission assignments used in RBAC; and that the information that is used to decide on granting/denying a user’s request may be distributed across several sites (rather than being centrally located). We also demonstrate that the expressiveness of the DEBAC model and the representation of DEBAC policies, as term rewrite systems, permit a range of properties to be proven of DEBAC policies; these proofs guarantee that security goals are satisfied by a policy specification and by the operational methods used to evaluate access requests. Approaches that provide for provably correct security have always been and remain of high interest in the security community. Represented as term rewrite systems, DEBAC policies are specified as a set of rules and access requests are specified as terms. Access request evaluation is effected by reducing terms to a normal form (see below). Term rewriting techniques have been successfully applied, and have had deep influence, in the development of computational models, programming and specification languages, theorem provers, and proof assistants. More recently, rewriting techniques have also been fruitfully exploited in the context of security protocols (see, for instance, [9]), and security policies for controlling information leakage (see, for example, [18]). As we will see, representing DEBAC policies as term rewriting systems enables complex and changing access control requirements to be succinctly specified in a declarative language that is formally well defined.

The formal foundations on which our approach is based make it possible to apply the extensive theory of rewriting to access control; in particular, standard rewriting techniques can be used to show that access control policies satisfy essential properties (such as consistency and completeness) and can be used to study combinations of policy specifications. Another important reason to use rewrite-based languages to specify access control policies is that tools, such as ELAN [14, 22] and MAUDE [15], can be used to test, compare and experiment with access request evaluation strategies, to automate equational reasoning, and for the rapid prototyping of access control policies. Distributed term rewriting systems An important aspect of the DEBAC model is the capability of representing systems where resources may be distributed across different sites, and the information needed to decide whether a user request is granted or denied may also be distributed. To address this issue, we will define access control policies as modular term rewriting systems, where modules may be independently maintained at different sites, and information sources may be explicitly specified. In other words, policy designers may directly define the sites (locations) to be used in access request evaluation. For the approach to distributed access control that we propose, we introduce distributed term rewriting systems (DTRSs); DTRSs are term rewriting systems where rules are partitioned into modules, each associated with a site, and function symbols are annotated with site identifiers. We assume that each site has a unique identifier (we use Greek letters μ, _, . . . to denote site identifiers). Comparison of DRM and AC We compare the generic decision process that DRM and access control models employ. An authorisation policy forms the basis of the decision process. To reach an authorisation decision, the credentials (identity, certificate, digital cash) of a user and the attributes (permissions, sensitivity, retail price) of the requested resource, together with any critical information (history, importance, any context) are evaluated against the governing policy. A critical difference between DRM and AC is that the latter bases its security associations on trust relationships whereas the former usually bases them on money (credit, token), backed by legal enforcement. Both ask the question: should I give Alice permission to read the file? AC will answer: Yes, if you trust her. DRM will answer: Yes, if she pays you and agrees to certain conditions on further transfer. If we substitute trust with money it becomes evident that the generic requirements that both aim to express and enforce are of a similar nature. However, as we will see, this difference has a significant impact on how these two mechanisms are implemented. REFERENCES Di Carole S. Jordan, Dr. Deborah Downs, Grant Wagner and Steve LaFountain, A Guide to Understanding Discretionary Access Control In Trusted Systems, National Computer Security Centre (NCSC), 1987. Ferraiolo, David F., Ravi Sandhu, Serban Gavrila, D. Richard Kuhn, and Ramaswamy Chandramouli. 2001. Proposed NIST Standard for Role-Based Access Control. ACMTransactions, p. 17-47. Stephan Dranger, Robert H. Sloan and Jon A. Solworth, The Complexity of Discretionary Access Control, University of Illinois at Chicago, —-. Michael P. Gallaher, Alan C. O’Connor and Brian Kropp, The Economic Impact of Role-Based Access Control, National Institute of Standards & Technology (NIST), 2002. 1. Department of Defense Trusted Computer System Evaluation Criteria, DoD, DoD 5200.28-STD, 1985. 2. Schell, R. R., “Security Kernels: A Methodical Design of System Security,” in Technical Papers, USE Inc., Spring Conference, 5-9 March 1979, pp. 245-250. 3. Schroeder, M.D., Cooperation of Mutually Suspicious Subsystems, PhD dissertation, M.I.T., 1972. 4. Boebert, W.E., and Ferguson, C.T., “A Partial Solution to the Discretionary Trojan Horse Problem,” 9th Security Conference, DoD/NBS, September 1985, pp 141-144. 5. Downs, D, “Discretionary Access Control Guideline,” Aerospace Report, The Aerospace Corporation, September 1985. 6. Boebert, W.E., Kain, R.Y. and Young, W.D., “Secure Computing: The Secure Ada Target Approach,” Scientific Honeyweller, Vol. 6, No. 2 July 1985, pp 1-17. 7. Saltzer, Jerome H., “Protection and the Control of Information in Multics,” Communications of the ACM, Vol. 17, No. 7, July 1974, pp. 388-402. 8. Fabry, R.S., “Capability-Based Addressing,” Communications of the ACM, Vol. 17, No. 7, July 1974, pp. 403-411. 9. Redell, D.D., “Naming and Protection in Extensible Operating Systems,” AD-A001 721, published by M.I.T., Cambridge MA, November 1974. 10. Karger, P.A. and Herbert, A.J., “Lattice Security and Traceability of Access,” Symposium on Security and Privacy, IEEE, April 1984, pp. 13-23. 11. Gligor, V., Huskamp, J., Welke, S., Linn, C., and Mayfield, W., “Traditional Capability-Based Systems: An Analysis of Their Ability to Meet the Trusted Computer Security Evaluation Criteria,” IDA Paper Pl 935, October 1986. 12. Computer Associates, CA-SENTINEL Reference Guide, 1983. 13. Saltzer, Jerome H. and Schroeder, Michael D., “The Protection of Information in Computer Systems,” Proceedings of the IEEE, Vol. 63, No. 9, September 1975, pp. 1278- 1308. 14. Honeywell Informations Systems, Inc., Multics Programmer’s Manual-Reference Guide, 7 ed., AG91. 15. UC Berkeley, UNIX Programmer’s Manual, 7 ed., 1981. 16. IBM, Access Method Services, 1983. 17. Control Data Corporation, NOS Version 2 Reference Set, 3 ed., 1983. 18. APOLLO Computer Inc., The DOMAIN System Administrator’s Guide, 3 ed., 1983. 19. Bell, D.E. and LaPadula, L.J., “Secure Computer Systems: Unified Exposition and Multics Interpretation’,” Tech. report MTR-2997 Rev. 1, MITRE Corp., March 1976. 20. Benzel Vickers, T., “Overview of the SCOMP Architecture and Security Mechanisms,” Tech. report MTR-9071, MITRE Corp., September 1983.

Cite this page