Handbook of Information Security Management:Application Program Security










Profit and
Value from Information Technology





Ecommerce & Extranets :
Client Systems :

Enterprise Applications :
Application Development









Search the site:   ITLibrary ITKnowledge EXPERT SEARCH Programming Languages Databases Security Web Services Network Services Middleware Components Operating Systems User Interfaces Groupware & Collaboration Content Management Productivity Applications Hardware Fun & Games EarthWeb sites Crossnodes Datamation Developer.com DICE EarthWeb.com EarthWeb Direct ERP Hub Gamelan GoCertify.com HTMLGoodies Intranet Journal IT Knowledge IT Library JavaGoodies JARS JavaScripts.com open source IT RoadCoders Y2K Info Previous Table of Contents Next Accountability and Separation of Duty However, if a resource owner no longer manages or knows about individual users, how are those users to be made individually accountable for what they do? How do we retain the advantage of not having to manage users at the resource server but still provide those users’ identities in audit trails at the server? The answer to these questions is to provide the server with a trusted audit identity value through external means. It is this value that will be blindly inserted into audit trail entries. Here is a specific example of how this is done using SESAME technology. In SESAME, a user authenticates and ultimately obtains a Privilege Attribute Certificate (PAC). The PAC contains attributes representing the access rights of the user. A role attribute is optionally one of these. The PAC is a cryptographically protected data structure that the user subsequently presents to resource servers as evidence of authorization for access. The server’s access control logic, receiving the PAC, extracts the role attribute that it now uses in its access control decisions. However, the PAC also contains other administrative information, including an audit identity field quite separate from the access control attributes. It is the value in this field that the server’s security functions insert into audit records for actions authorized on the basis of the PAC. Individual accountability is achieved at the server, but its resource controller does not need to manage or even know about individual identities. Whatever audit identity value is in the PAC is simply inserted into the audit trail entries. The PAC may also contain other access control attributes for use when RBAC is inappropriate or needs supplementing. One of these might be an identity for access control purposes — an access identity. SESAME maintains a clear separation between this value and the audit identity, permitting users to use other identities from an access control perspective (perhaps the other user is away on leave) but is still accountable as himself or herself through his or her audit identity. The question of separation of duty also arises.2 If access is by role, and individual identities are not used in access decisions, how do we ensure that the same individual cannot perform two duties that are required to be separate? One solution is to assign the different duties to different exclusive roles, thereby preventing any one user being granted two mutually exclusive roles. However, mistakes can be made if individuals can be granted multiple roles, and roles that appear to be different may actually be related hierarchically. Yet, when used with care, this approach can be made to work. This form of separation of duty is known as static separation of duty. 2First formally defined in computer terms in the seminal paper by D. D. Clark and D. R. Wilson. “A Comparison of Commercial and Military Computer Security Policies.” Proceedings of the IEEE Symposium on Security and Privacy. April 1987. Another solution is to use the audit ID as a record of the identity of the individual who performed an action (e.g., in relation to Duty 1), and to check that the audit identity of an individual requesting the right to perform the Duty 2 action is different. This does not require any management of the individuals in the server; just a blind comparison of audit identity values. Such a flexible implementation is known as dynamic separation of duty. However, the audit identity rather than the access identity should be used, because if a user is allowed to act for another user while the latter is on leave (a common requirement), that same user may be using a different access identity from his or her own and so may appear to be two different people. Roles in Context — The Access Control Cube Role is not the only dimension to organizational responsibility. Role primarily determines the functions that a user needs. For example, an invoicing clerk may need to examine delivery notes, raise invoices, issue reminders, and so on. The accounts department manager may need to be able to perform these functions along with such others as invoice cancellation or modification. Other job types specifically to do with the computer system itself will also commonly be relevant (e.g., security manager, audit manager, or system manager). However, a further dimension can be identified — organizational affiliation, which concerns the part of the organization within which the role is being exercised. Examples of affiliation might be that the user is a member of the London branch or the Las Vegas family. Previous Table of Contents Next Use of this site is subject certain Terms & Conditions. Copyright (c) 1996-1999 EarthWeb, Inc.. All rights reserved. Reproduction in whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Please read our privacy policy for details.