Computer access control policy choices

Computers

& Security, 9 (1990) 699-714

Computer Access Control Policy Choices lngrid

M. Olson and Marshall

D. Abrams

7‘1~ MITRE Corporation, 7525 Co/shire Drive, McLean, VA 22102, U.S.A.

This paper provides a guide-a road map-for refining a highlevel information dissemination/control policy into an implecontrol policy. This process involves mentable access determining the appropriate set of policy-oriented limitations and can take place at many levels, from a top-level corporate decision to a hardware implementation choice. The paper discusses many of the choices that need to be made in the process and some of the implications of making each decision. A discussion of the Gcncralizcd Framework for Access Control (GFAC), an ongoing research effort, presents a framework and new perspective for describing access controls. Discretionary Access Control and Mandatory Access Control are described within the GFAC framework. and two examples are given showing how changing some of the policy choices can reprcsent a different policy which may meet a different set of access control requirements. bkywords: Access control work for Access Control,

policy, Authori~, Gcncralizcd Hierarchy control.

Framc-

of

1. Introduction

As

organizations have recognized the value of information stored in computers, they have also recognized the vulnerability to accidents and malevolent activity dircctcd towards thcsc computers. A common organizational approach is to d&e acccptablc and unacceptable human bchavior. Publication of policy dircctivcs that recognized the need to protect information in paper docu‘Point of mirre.org.

contact:

0167-4048/90/$3.50

Ingrid

Olson

(703)

883-7044,

iolson@

0 1990, Elsevier Science

Publishers

ments or to control before computerized

critical processes automation.

occurred

long

This paper focuses on control of access to information in computers. It also applies to proccsscs controlled by computers. Its fundamental concern is with the selection and implementation of policypolicy that governs who can access information within the computer and what they can do as a conscqucnce of such access. This focus is commonly known as “access control”. 1.l Policy Representation and Implementation

Policy directives written in a natural language arc intcndcd to be interprctcd by people to govern their activities. To govern computerized activities, the human-readable form must bc translated into computer-readable form. Thus, there arc scvcral representations of policy. This paper deals with more than one of these representations; therefore, we will present brief definitions. The following cxccrpt from Abrams 111, page 83, dcscribcs the terminology used in this paper. Figure 1 illustrates the policy representations. ‘One of the most important components of the security architecture is the security policy, the set of laws, rules, and practices that regulate how an organization manages, protects, and distributes sensitive information. In general, the security policy

Ltd.

699

I. M. Olson et a/./Computer

[Natural

Access Policy Choices

Security Policy Language-‘Informal”] 1

Security Policy Model [Mathematical Language--“Formal”] 1

Trusted

Implementation Computing Base (TCR)

Selecting Policy for Automation has been observed that the first stage of automating a manual process is to (attempt to) replicate the manual process in the computer [2]. The second stage is to implement additional capabilities that the computer can support but wcrc impractical or infeasible during manual operations. This paper concentrates on the first stage, the automation of existing policy. 1.2

It

Fig. 1. Policy representations.

will be written in a natural language such as English. While natural language is easy to understand in ageneral way, it is often susceptible to multiple interpretations on speci$c points. This ambiguity indicates the need for a precise formal language restatement in a formal security policy model. Formal language, in this context, means mathematical notation, an algorithmic computer programming language, or a computer language deskned for svecifcation. The imvlementation of theoform; seiuriiy policy model L known as thi trusted computing base (TCB). The TCB is the totality of protection mechanisms within a systemincluding hardware, jirmware, and software-the combination of which is responsiblefor enforcing the security policy. The TCB creates a basic protection environment and provides additional user services required for a trusted computer system. The ability of the TCB to enforce a security policy correctly depends solely on the mechanisms within the TCB and on the correct input by system administrative personnel ofparameters (e.g., a user’s clearance) relative to the security policy. One mqjor component of security policy is access control, which limits the rights or capabilities of a subject or principal to communicate with other subJ’ects or to use functions or services in a computer system or network. The latter part of this def;nition is often stated in terms of limiting access to objects, passive entities that contain or receive information. Access control is enforced by a reference monitor, still an abstract concept, which mediates all accesses to objects by subjects. The implementation of the reference monitor is the [security] kernel.”

700

Currently thcrc arc only a few security policy models in use. Each of these models was conceived to represent a specific security policy or a class of policies. The security models include the Bell-LaPadula Model [3-61 the Biba Integrity Model [7], the Clark-Wilson Integrity Model [8], Den&g’s Information Flow Model [9], the Message Flow Modulator [ lo], the Navy DBMS Security Model [ 111, the NRL Secure Military Message System [12], and the ACCAT Guard [ 131. For a more complete description and survey of formal security models see Landwehr [lb] and Millen [ 15, 161.

Rcccnt rcscarch on the Generalized Framework for Access Control (GFAC) (described briefly in Section 2) is an attempt to broaden the view of access control and the choices available. GFAC frees the security architect to choose or design a security policy model that most closely matches the informal natural language security policy.

1.3 Audience,

Objective,

and Scope

The main objective of this paper is to provide a guide-a road map-for refining a high-level information dissemination/control policy into an implementable access control policy. In meeting this objective, this paper will also stress the need for new, more flexible access control mechanisms to adequately support many organizations’ access control requirements. GFAC concepts and structure are used as the basis for much of this discussion. This paper is directed at the individuals within an organization who interpret and implement an

Computers and Security, Vol. 9, No. 8

organization’s high-level information dissemination/control policy. For example, the policy may information processed by the state U... sensitive resources shall be properly safeorganization’s guarded against accidental or malicious disclosure, alteration, destruction or delay”. In the government some of this information may be designated “sensitive unclassified”. National security related information is classified according to complex rules. Private organizations may identify information as sensitive, proprietary, personnel confidential, etc. The natural language security policy is often produced at the highest level of the organization so that it has the widest applicability. In order to implement this policy, several layers of interpretation and refinement are necessary. This paper is an attempt to focus on some of the decisions at different layers that need to be made in this refinement process. The motivation for this paper came from the GFAC research effort. In that effort there were continual difficulties in keeping the discussions of actual access control concepts. Traditional thinking on access control generally translates into Mandatory Access Control (MAC) and Discretionary Access Control (DAC) (as defined in [IT]), and in trying to describe gcncral access control concepts, it became very evident how firmly entrcnchcd the MAC and DAC concepts arc, and how limited they arc for some applications. This paper focuses on computer access control policy. It must bc kept in mind that in order to ensure the security of a system, the information security policy must cover other arcas such as audit, labeling, accountability, and integrity. In addition, the overall system security policy will include many other aspects as well, such as pcrsonncl security, physical security, communications security, and administrative security.

of the many policy decisions that must be made in refining a high-level information dissemination/ control policy into an implementable access control policy. DAC and MAC arc then used in Section 4 as example of the effects of some of these some of policy decisions, and shows how varyin the choices can provide for a different po Picy. 2. Summary of Generalized Access Control

Framework

for

GFAC provides a new, broad, more general approach to access control. The root concept of GFAC is the comparison of attributes associated with the subject to attributes associated with the object according to the rules that implement the access control policy. There are three principal components identified in GFAC. They represent dimensions of choice and constraints in the implementation of access controls. l Information: attributes (characteristics or properties) of subjects and objects, and context (additional information used in the access control decision making, such as time of day). l Rules: regulating principles access control policy by requests by subjects to objects.

that implement the adjudicating access

l Authority: the set of agents who determine the rules and specify and assign values to attributes and contexr, multiple authorities may exist and have diffcrcnt spans of control.

The access mediation process evaluates the subject’s requested mode of access relative to the relevant attributes of the subject and/or object according to the rules and makes a binary decision whether the access is pcrmittcd. Mode of access could include such activities as read, write, append, execute, copy, delete, and document mark-up.

1.4 Organization

Section 2 of this paper provides a brief summary of the GFAC rcscarch effort, which provided the motivation for this paper. Section 3 discusses some

One of the most important concepts in GFAC is that there is a very wide design space for access control policies. MAC and DAC are but two pos-

701

I. M. Olson et aLlComputer

Access Policy Choices

sible points in this design space. By making design decisions about each of the three main components and their combinations, alternative access control politics can bc implcmcnted. GFAC provides an improved framework for expressing and intcgrating multiple policy components. The GFAC effort hopes to lead to implcmcntations of access control politics used in the manual paper control cnvironmcnt, and also to dcvcloping new politics that wcrc not implcmcntcd in manual systems, but which appear to bc useful and practical in an automated system. SW Abrams et al. [18] for a more of GFAC (formerly called detailed description Unified Access Control).

3. Access

Control

Policy

Choices

The process of refining a high-level information dissemination/control policy into an implcmcntablc computer access control policy involves dctcrmining the appropriate set of policy-oricntcd limitations. This refinement process can take place at many lcvcls, from a top-level corporate decision to a hardware implcmentarion choice. This section discusses many of the choices and decisions that need to bc made in this process and dcscribcs some of the implications of making each decision. These choices may apply to one or more levels of the rcfincment process. Wood et al. [ 191 also discuss some of thcsc rcfinemcnts in a database context. Although this process of policy rcfincmcnt is crucial to understanding one’s access control the actual implementation of thcsc rcquircmcnts, rcquircmcnts may be limited by the availability of mechanisms. Most appropriate and adequate systems (at least off-the-shelf systems) provide traditional DAC or MAC mechanisms; these cxisting mechanisms arc inadequate to handle many access control rcquircmcnts that may be spccificd during this policy refincmcnt process. A brief discussion of why existing access control mechanisms arc inadcquatc for many of these policy choices is also included. Detailed discussions of the inadcquacy of existing mechanisms for some specific politics arc also available [8, 20, 2 11.

Sonic of thcsc policy decisions will be made for an organization by national or corporate policy, agency policy, or particular sponsor or project rcquircmcnts; orhcrs may bc based on implcmcntation restrictions or other limitations (e;?. political), and others will bc choices left to the user. A high-lcvcl policy decision requires mechanisms available to support that decision, and likewise, hardware limitations may restrict some high-level policy decisions. So while a top-down rcfincment process is the idcal, from a realistic, practical vicwpoint, both a top-down and bottom-up approach to policy definition arc necessary. 3.1 Confidentiality vs. Integrity vs. Availability One of the first choices is the balance among confidentiality, integrity, and availabiliry. Some politics arc highly polarized towards one of thcsc objcctivcs, while others strive for a balance. In some casts the written policy may mention, or cmphasizc, only one objective; yet operational facts indicate that other objcctivcs are important. Conflicts among the objcctivcs arc easily found; an intcrcsting gcncralization is found in Kccfe [22].

It is easy to improperly gcncralizc the priority ordering among thcsc objcctivcs in organization the Department of Dcfcnsc types. For cxamplc, (DOD) is often charactcrizcd as being primarily intcrcstcd in confidentiality. and the commercial sector primarily interested in integrity. Sonic form of prioritization and trade-off analysis needs to be pcrformcd for each application. The more difficult analysis occurs when objcctivcs conflict. 3.2

Maximized

Sharing

vs. Least Privilege

One example of a high-lcvcl policy choice, an almost philosophical decision about the intended purpose of the system, is that of maximized sharing VS.least privilege. The policy of least privilege, also known as need-to-know, means that users arc only given the minimum permissions or authorization to access information required to perform their functions. For class&cd information or any information subject to privacy legislation, this policy is a requirement.

Computers and Security, Vol. 9, No. 8

An alternative policy is that of maximized sharing; for instance, in a research environment researchers may be allowed maximal access to the information. It is possible that within a given system both of these policies may be applied, each to a welldefined set of information. Another option is that a combination of these policies such as maximal access within a given set of constraints for a particular set of information be applied. For example, within a research community, one might give everyone read access to the ongoing research, but not the privilege to modify research findings. Another example may be a public service agency which may allow the public read-only access to a wide variety of information about available services. 3.3 Granularity of Controls

A policy may affect few or many subjects and objects. Some policies, such as MAC, are intended to apply universally; others, such as DAC, apply to specific subjects or objects. The coarsest granularity is concerned with access to the entire computer system. If the user is author&d access to the system then (s)hc has access to cvcrything on the system. For single user systems or systems dcdicated to a specific task, this granularity of control may be sufficient. Howcvcr, for multiuser systems running several applications a finer granularity is probably required, such as access controls at the directory level, file lcvcl, or even data item lcvcl. Object size is a factor in that systems in which the access control policy can only be cxpresscd in terms of objects known to the TCB and those in which the TCB knows about very small objects may be equally flawed. Performance and overhead (e.‘q. storage) will bc important considerations in dctcrmining the appropriate level of granularity for applying access controls.

single point of failure and bottlneck. Decentralized co&oi, on the other hand, while technically and administratively more complex, puts the responsibility for many security functions in the hands of individuals, users who are probably most familiar with the particular rcquiremcnts of the information. An additional aspect of granularity is the flexibility of the policy (and of the supporting mechanism) to be tailored as needed on a subject/object basis. For example, DAC allows the access permissions to bc tailored to a specific subject/object; MAC dots not-the rules apply to all subject/object pairs. When DAC and MAC arc used together, DAC provides for a finer granularity of control within the overall constraints of the MAC policy. In many cases, a single policy with the strengths of both DAC and MAC ( i.e. the flexibility of DAC and the strength of MAC) would bc prefcrablc. 3.4 Access Control Information GFAC provides the perspective that the inputs to all access control decisions arc cithcr attributes associated with subjects and objects or with context (e.g. time of day, status). Each policy sclccts the relevant information in order to make the access control decision. In gcncral, the policy specifics a comparison of subject and object attributes and/or context, but some policies involve only one of thcsc sets. Some attributes may support many politics; some attributes have a one-to-one relationship with policy. The foll owing sections dcscribc some of the attributes more commonly used. They arc divided into five main catcgorics: subject charactcristics, object characteristics, cxtcrnal condition, data content ~3. context attributes, and integrity concerns. 3.4. I Subject Characteristics

Another aspect of granularity is the issue of ccntralized VS.decentralized control. With centralized control, a single authority controls all security aspects of the system, reducing the complexity of the security controls and the administrative demands on other users, while creating a potential

A number of user characteristics utes) arc commonly used in the ccss. Thcsc arc briefly Conceivably any attribute of the (eg. age, sex, rcsidcncc, place of by the appropriate policy.

(i.e. subject attribaccess control prodcscribcd below. user could bc used birth) as identified

703

I. M. Olson et al./Computer

Access Policy Choices

3.4.1.7 Hierarchical User Levels. In DOD, this attribute is based on national policy which requires the protection of sensitive national security related information based on a user clearance level and the information classification. Traditional MAC was developed to handle the DOD hierarchical clearance/classification scheme for handlin classified information (i.e. Top Secret, Secret, Con ! idential).

MAC could well be used to handle other hierarchical schemes. Arguments have been made and examples presented [23] for the applicability of hierarchical policy to non-national security information. There does not appear to be much problem in establishing information sensitivity; the problem is in developing a hierarchical set of clearances. Organizations with hierarchical job titles and position classifications may be able to map these to clearances. However, the lack of any welldefined, standardized scheme outside the DOD currently limits the use of MAC. 3.4.1.2 Need-to-Know. DOD policy also includes a need-to-know requirement for access to bc granted. The dctcrmination of need-to-know may bc based on a formal authorization or may be left to the discretion of the user ranting access. This access approval could be in f icatcd by attributes associated with the subject. These controls arc implcmcntcd to provide finer control over who has access to information within hierarchical sensitivity lcvcls; this includes the degcncratc case whcrc there is only one sensitivity lcvcl.

3.4.1.3 Role. The role of the individual (not the individual identity) could determine what information the user has access to. Role cxamplcs might include position titles, place in the organization, or function, such as security officer, data entry clerk, department manager. Typical rules using roles arc the following (I) A manager may view (mad) the salaries of anyone below him in the supervisory chain, (2) a payroll clerk may modify a salary below $X, and (3) the

704

payroll supervisor (where Y > X).

may modify

a salary below

$Y

3.4.1.4 Group Affinity. Group affinity may be used to determine access, using characteristics such as nationality, employer, or user organization. Examples of DOD policies using a nationality attribute include NOFORN (no foreign nationals) or NATO (which im pl.ies individuals from certain countries who have the appropriate need-toknow). Exceptions to either of these policies may also be specified in the form RELEASABLE TO. MAC does not have the flexibility to handle the exception cases, and in DAC, the access control information is not generally carried to any copies of the information. These restrictions are normally handled by administrative methods. Non-DOD organizations may need similar restrictions to comply with national information control laws.

NOCONTRACT (no contractor) is a DOD policy where access is granted to an individual identified as a government cmployce; COMPANY CONFIDENTIAL may bc assumed to implement a similar policy in the private sector. Today thcsc restrictions arc normally handled administratively. 3.4.2 Object Characteristics

Within the DOD, there is a well-defined structure for labeling objects. National/DOD policy requires the protection of sensitive national security related information based on information classification (Top Secret, Secret, Confidential, and Unclassified) and user clearance. In addition, within the DOD/ intclligencc community, there are numerous compartments, categories, handling restrictions, and other markings that are used to further restrict access to the information [24]. Some of these actually require a special, formal authorization from the responsible Office of Primary Interest for users needing access to the information (e.g. Sensitivc Compartmented Information (SCI)). Others simply indicate a specific group of users who may (or may not) have access to the information, either by naming individuals or groups or by indicating some characteristics of the users who may access

Computers and Security, Vol. 9, No. 8

the information tion), ORCON ONLY, PROPIN

(e.g. LIMDIS (Limited Distribu(Originator Controlled), EYES (Proprietary Information)).

Another policy might allow a user to be able to specify who has access to some particular information according to whatever criteria he chooses, e.g. “who do I like” or need-to-know. Having a list of authorized users/groups (e.g. Access Control List (ACL), an object attribute) is one possible way to do this, and most systems today do provide an ACL capability. A Guide to Understanding Discretionary Access Control in Trusted Systems [25] states that ACLs are the most flexible and usable DAC mechanism available with current technology. However, a potential limitation with this approach is that in most implementations, the ACL does not propagate to any copies made of the object, thereby limiting the strength of the mechanism. This approach is also more susceptible to Trojan Horse attack (e.g. illegal write down).

3.4.3 External Condition Some possible external conditions (i.e. context) on which to base the access control decisions are location, time and status. In addition, we had previously assumed that the attributes used in the access control decision were relatively static. Some policy decisions may be based on data which is expected to change. (1) Location: access may be based on location (e.g. only a user from the main office is allowed access). DOD policy sometimes differentiates whether the location in within the contiguous 48 states (CONUS) or not (OCONUS).

(2) Time: access to the information (i.e. sensitivity of the information) may vary with time (e.g. the Department of Labor Statistics’ information on last month’s unemployment rate is sensitive until 9:00 a.m. on Tuesday morning when it is made public). (3) Status: the access control restrictions depend on a status variable that is officially changed to reflect

some condition in the real world (e.g. crisis or cxercise status). 3.4.4 Data Content and Context Some access control policies may depend on the value of data. For example, user X may not be allowed to see the personnel file of anyone earning more than $20,000. More complex policy may depend on contexr, i.e. the identity of other data fields. The use of static labels is a carryover from manual methods of determining the sensitivity of information. The dynamic determination of access based on content and context has been rccognizcd as a potential replacement for static labels, and is currently a topic of research particularly in the database area [26]. The rules for such dynamic real-time evaluation of content and context arc very complex, and probably not well understood in the manual world. 3.5 Integrity Policies

Computer security and access control today usually focus first on secrecy policies that prevent unauthorized disclosure of information. Another important set of policies is concerned with prcventing unauthorized modification. Although GFAC does not distinguish policy objectives, it is convenient to discuss integrity policies separately. The two best known integrity models arc Biba [7] and Clark-Wilson [8]. The Biba integrity model is a dual of the Bell-LaPadula secrecy model. It was conceived independently of an application environment. It employs integrity labels that arc obvious candidates for implcmcntation within the GFAC framework. The Clark-Wilson model is based on commercial data processing practices. Many of thcsc practices arc inhcritcd from generally accepted accounting practice. Moffctt and Sloman [27] argue that y...acccss control systems for a company’s computers should mirror the organization’s internal control systems, based on the delegation of authority”. Unlike DOD, where policy is crcatcd by a hierarchical organization, the business integrity policies have to be accepted by a social process. The process is ongoing; there is no policy that can be

705

I. M. Olson et al.lComputer

idcntificd as having been accepted the needs of the community.

Access Policy Choices

as representing

Clark-Wilson access controls focus on two main concepts: the well-formed transaction and scparation of duty. These can be implemented as GFAC rules making access decisions based on attributes. For example, subject attributes could include a list of programs that the subject is allowed to run (to enforce separation of duty); object attributes could include a list of programs allowed to access that object and their associated access permissions (to enforce the well-formed transaction). 3.6

Precedence

In setting up access control policies and the rules to implement these policies, it is likely that some rules or portions of the decision-making process will be in conflict with each other. Therefore it is also very important to ensure that a method for determining the precedence of rules or a prioritization is established. The following points highlight some potential areas of conflict. (1) Individual

authorizations VS. group member authorizations: the potential for conflict exists between the authorizations granted to an individual and the authorizations granted to an individual as a member of a group. There are a number of possible ways to deal with this conflict. A fully specified order can bc detailed to deal with all potential conflicts. Lunt [28] outlines two other possible rules: the most-specific rule or the dcnialstake-prccedcncc rule. In the most-specific rule, if an individual user is specifically granted or denied authorization for an object, this takes prccedcncc over any authorizations for the object that are granted or dcnicd to groups to which the user belongs. As an example, in Multics, if the ACL specifics access rights (including denial of access) for an individual user, then the group access rights arc ignored. In the denials-take-precedence rule, a user or group’s denial of authorization for an object takes precedence over any authorizations that the user or group may have been granted for the object. Other options for dealing with individual VS. group authorization conflicts also exist.

706

Exceptions: a rule may grant a specific cxccption to a more general rule (eg. NOFORN and other release markings may have explicit cxccption lists associated with them which can be granted by the originator of the data). A method for dealing with such exceptions must exist, where the exccption condition is given precedence over the more generally stated access rule. (2)

3.7

Privileges

Part of the access control decision process involves determining with what privileges or access permissions the user may access the information (i.e. authorization). The access control process may consist of a simple binary decision: the user is granted no access or unrestricted access. Additionally, the access control process can decide, if access is allowed, what privileges the subject has with respect to the requested object. Examples of privileges or access permissions include read, write, cxccutc, delete, append (write without read), documcnt mark-up, grant access, rescind access. There are two parts to this factor: (1) determining default privileges and (2) controlling the ability to change the privileges. (1) Default

privilcgcs: The manual paper world gcncrally defaults to read-only access, but this is not the default in many automated systems. For cxamplc, MAC dots not distinguish user privilcgcs at all; it is used only to dctcrmine if any access is allowed. When DAC is used together with MAC to control privilcgcs, the default in many systems is rcad/writc. In some systems (e.g. UNIX’), read pcrmission implies the right to copy the object. This can result in a proliferation of copies and perhaps the ability to make changes to these topics. In addition, the ability to change privilcgcs must be carcfully controlled. (2) Granting/rescinding privileges: the authority to grant and rescind privilcgcs must be explicitly

‘UNIX is a registered trademark of AT&T.

Computers and Security, Vol. 9, No. 8

d&cd. As previously mcntioncd in (l), the ability to grant or rescind privileges is part of the key to the strength of the access control mechanism. Careful planning in setting up a user’s privilcgcs to a given object is pointless if any user can arbitrarily change thcsc privileges. Some examples arc as follows: the information owner can specify who may read and/or write his files; the security administrator can specify privileges for any files; and the projcct lcadcr can specify privilcgcs for project f&s. Thcsc arc only examples. A careful examination of the access control requirements and of the system’s implementation of the various access permissions is ncccssary. 3.8 Authority

The strength, scope, and span of access controls dcpcnds, at least in part, on the authority of the person or organization who makes the rules and who cntcrs/modifics the access control information used in the access control decision in the system. The security policy can provide for delegation of authority by d&ring who has subscqucnt authority to grant other users specific access to append, modify, or dclctc subject/object attributes (e.g. who can change a user clearance or file classification, who can change an object ACL, who can change the status). Traditionally, in MAC and DAC, the security administrator has been implcmentcd as a trusted process. These trusted subjects and processes have been treated as cxccptions to the security policy, and endowed with special exemptions from some or all of the policy cnforccmcnt by the refcrcncc validation mechanism or other parts of the TCB. Thcsc cxcmptions wcrc necessary in order for the security administrators to perform their intended functions. Within the GFAC framework the diffcrent lcvcls of authority and privileges associated with each level must bc explicitly dcfincd. By directly addressing the policies associated with the security administrator no exemptions or special cases arc ncccssary. 3.8.1

Hierarchy

of Controls

Defining the hierarchy of controls is part of dctcr-

mining authority. Typically, diffcrcnt lcvcls of authority span the hierarchy of controls within a computer. Gcncrally speaking, thcrc arc three lcvcls of hierarchy for access controls within a computer, although depending on the particular policy or on practical limitations, one could envision more or fcwcr lcvcls. l Level 1 (Access): controlling objects.

access of subjects to

l Level 2 (Attribute): controlling access to the information used to dctcrminc the access of subjects to objects (eg. controlling who may modify a user clearance or object classification, who may change the ACL). l Level 3 (Permission): controlling access to the information about who may access the information used to determine the access of subjects to objects (e.g. controlling who may modify who is allowed to change an object classification).

Controlling access at all lcvcls to the information used as the basis of the access control decision is the key to the strength of the access control mechanism. For example, in MAC, Levels 2 and 3 of this hierarchy arc restricted to the person having opcrational responsibility for computer system security (i.e. the security administrator). In DAC, by way of contrast, the owner of the information has the authority to change the ACL (Level 2). Clearly there arc additional lcvcls outside the boundaries of the computer; for instance, the Prcsident and national policy or the Chairman of the Board both dictate additional lcvcls of authority, but at some point WC reach the boundary bctwccn the administrative controls among pcoplc and the technical controls within the computer. Not all the policy decisions or rcfincments to bc discussed in this section apply to all lcvcls of the hierarchy, and where a particular decision does apply at all levels, diffcrcnt factors may be appropriate to each lcvcl. Howcvcr, it is important to keep this hierarchy in mind to ensure that ail lcvcls arc adequately

707

I. M. Olson et al. /Computer

covered in developing an implementable control policy for a particular computer. 3.8.2

Access Polk y Choices

access

User Roles

part of defining lcvcls of authority in a system, the security policy should clearly define the diffcrcnt types of roles on the system and the rcsponsibilitics and authority of each. In addition, many systems support the concept of groups, and additional considerations come into play when dealing with groups. Examples of different types of user roles and their respective responsibilities follow. A discussion of groups is in the next section. As

(1) User: one who has authorized access to information on a computer. Authorizations may include the ability to read, write, dclctc, append, execute, or grant or rescind permissions to some objects. Authorizations may vary from object to object. For example, the user may be granted all permissions for his own working files, read only access to project files, and no access to any system f&s. For some information, the user may be the owner or custodian. (2) Owner: that individual manager or rcprescntativc of management who has the responsibility for making and communicating judgments and decisions on behalf of the organization with regard to the USC,identification, classification, and protccrion of a specific information asset. For cxamplc. the owner of the information may bc the only one authorized to grant or rescind user privilcgcs to the information, or be able to specify who may grant privileges (Level 3 in the hierarchy of access controls). (3) Custodian: one having authorized possession of the information and entrusted by the owner to provide proper protection in an ongoing, opcrational environment. (4) Security administrator: the person responsible for the security of a system (also known as the System Security Officer (SSO)). Functions that the administrator is expected to perform security

708

include auditing and initializing and maintaining the security parameters of the system. The security administrator may also bc authorized to cntcr or modify the security attributes of cithcr or both subjects and objects. 3.8.3

Groups

The creation of groups of users can bc a useful mechanism in many cases, whcrc scvcral users, for cxamplc, all belong to a particular project, arc in the same department, or have a similar nccd-toknow. In thcsc casts, access to a particular object can then bc d&cd for the group rather than for individuals, which saves some of the “book kccping” rcquircd for the system to implcmcnt access controls. In thcsc casts, howcvcr, the user may still need to bc individually identified to the system, and all actions would then still need to bc accountable to the individual and not just to the group. Howcvcr, there may bc situations whcrc individual identification is not necessary or practical, and whcrc group identification at login (and also for audit purposes) is suffcicnt. For cxamplc, a long running process (associated with a subject) cannot bc intcrruptcd cvcn though the user from whom it inherits some attributes changes. On some systems, this is handled by a “logovcr” function, whcrc the subject associated with the long running process changes as the subjects logon and logoff. Another way to handle this process would bc through the USC of roles (e,q. operator), whcrc the process is associated with a role (not a subject) and diffcrcnt users arc associated with the role at different times. Some issues relating to the USC of groups that the policy should rcsolvc include determining mcmbcrship in a group, when the USC of groups is appropriate, if a user can belong to more than one group, the rcquircmcnts for individual accountability within the USC of groups, and how to rcsolvc conflicts bcrwecn individual user and group privilcgcs. In addition, the maintenance of the group mechanism presents some issues: who maintains the list of names belonging to a group, who is authorized to change the mcmbcrship of a group (part of dctcrmining levels of authority), and

Computers

whcthcr users can list the mcmbcrs of groups they arc not in (possible covert channel or privacy issues). The creation and USC of groups, although a potentially useful tool, must bc a carefully controlled action since adding or changing mcmbcrs of a group can affect the objects acccssiblc to a mcmbcr of the group, and may have unforsccn cffccts on other objects acccssiblc to the group.

3.9

Inheritance

Policy

The inhcritancc policy (or strength or pcrmancncc of the binding bctwccn an object and its access control information) needs to bc clearly addrcsscd by the security policy. This issue-the fact that the access control information (eg. ACL) associated with an object dots not usually stay with topics or dcrivativcs of that object-is one of the major criticisms of DAC mechanisms; in other words, the definition of DAC is silent with respect to an inhcritancc policy. Howcvcr, the common undcrstanding appears to bc that when a new object is dcrivcd the access control information is not propagated. The access control information for objects used by mandatory access controls, on the other hand, propagates to any topics of that object; in other words, the binding of the access control information to the object is strong. The GFAC innovation of associating strong pcrmancnt binding with identity-based access controls opens up many possibilities for enforcing additional politics. The seeds of tightly bound identity-based access control have always cxistcd (e.g. the role of the security administrator). 4. Access

Control

Policy

Examples

Section 3 dcscribcd some of the choices and dccisions that need to bc made in refining a high-level information control policy into an implcmentablc access control policy. This section will discuss traditional MAC and DAC in terms of thcsc choices, and then show how chariging some of these policy choices can provide variations on thcsc access control politics that may be useful in certain cnvironmcnts.

and Security,

4.1 Traditional

Vol. 9, No. 8

DAC and MAC

The Trusted Computer System Evaluation Criteria (TCSEC) [ 171 d c fmcs DAC and MAC as follows: ‘Discretionary Access Control-.l means of restrictaccess to objects based on tlrc identity oj‘nrhjects and/or~~ror4psto wldr they belong. Tlrr controls are discretionary in the sense that a iuhject wit/i a certain access permission is capable cfpassing tht permission (perhaps indirectly) on to any otlrer subiect (tin 1ess restrained by mandatory access c^o&ol). ing

Mandatory Access Control-A means cf‘restrictinq access to objects based on tire sensitivity (as represented by a label) oj tlie inf ormation contained in the objects and the formal authorization (i.e. clearance) of subjects to access information ofs14ch sensitivity. ” In terms of the policy choices outlined in Section 3, traditional DAC and MAC gcncrally provide for confidentiality, i.e. protection against unauthorized disclosure. DAC is also used to implcmcnt the policy of least privilcgc. The access control attributes rcquircd by MAC arc user clcarancc for the subject attribute, and information classification for the object attribute. DAC generally USC’Sthe user ID (or group ID) as the subject attribute. The TCSEC unfortunately couples identity-based access control with discretionary (non-mandatory) access control. Thcrc has been little previous discussion of the association of other access control attributes with MAC or DAC type controls. The GFAC framework provides the capability to cxprcss the access control rules in terms of any attributes associated with the subjects and/or objects. Another important point in defining and distinguishing DAC and MAC is that whcncvcr a new object is crcatcd under MAC it must bc labclcd. A new object dcrivcs its label from the label of the subject creating it. DAC, in contrast, cxprcsscs no requircmcnts for propagation of access control information. This is the source of the “fundamental dcfcct” of DAC [25]. This rcflccts the strength or

709

I. IV. Olson et al.lComputer

permanence of the binding cussed in Section 3.9.

Access Policy Choices

of information

dis-

In addition to the TCSEC, more rcccnt NCSC publications such as the Tnrsted Network Interpretato Understanding Dislion (TNI) [29] and A Guide cretionary Access Control in Trusted System [E] also discuss DAC and MAC. The TN1 definition of DAC contains the following explanation of discrctionary: “Tl1e controls are discretionary in the sense that: (a) A subject with a certain access permission is capable ofpassing that permission (perhaps indirectly) on to any other subject; (b) DAC is often employed to enjhw need-to-know; (c) Access control may be cl1anged by an autllorized individual.” 4.7.1 MAC and DAC in GFAC Terms GFAC addrcsscs (a) and (c) above by explicitly identifying, and providing controls for, the privilcgcs and authority discussed. Point (b) is further claboratcd in [25] in the following discussion of the relationship bctwccn DAC and MAC.

“Discretionary control is the nrost C~VIVW~I type (If access control meclranisrn inlpleniented in corrzputer Jystenls today. Tire basis of tl1is kind of secrrrity is t/rat an irdividual user, orprogram operating on tlie user’s heIra% is allowed to specify, explictly tire typm cfaccess otlrer users (or proxranrs executing on their be11alfl may l1ave to injhnation under tllc user? con&l. Discretionary security di&s from maildatory security in that it implements tlie access control decisions of the user. Mandatory controls are driven by tire Lstrlts ($ a comparison between tire lrser? tr14st level or clearance and the sensitivity &@ation oftlie information. Discretionary controls are not a replacenrent jhr mandatory controls. In any environwlent in which infimiation is protected discretionary security provt’flesfor a jher granularity of control within tl1e overall constraints oftlre nfamfatorypolicy.. ”

710

In GFAC terms, DAC cxprcsscs a user’s decisions while MAC implements an access control policy established by higher authority rcprcscnted in the computer system by the security administrator. Certain design and implementation details have inadvcrtcntly been incorporated into the dcfinitions. GFAC has hclpcd identify these details and provided a vocabulary to factor them out from the fundamental definitions. Using the GFAC framework, it appears that the salient points of difference bctwccn DAC and MAC are in the control hierarchy as discussed in Section 3.8.1. For example, in MAC, the security administrator generally has authority to set up the and default parameters. The security system administrator and some classification authority arc assumed by virtue of their training and the trust vested in them to correctly enforce national policy. The MAC policy defines the relationship bctwccn subjects and objects, which is not changeable by the object owner. Mandatory access controls implcmcnt a policy created by a higher authority. The person administering mandatory controls cxcrciscs no judgcment concerning the policy. Hc or she may cxcrcisc limited judgemcnt in applying classification criteria to information in order to dccidc the proper sensitivity label to apply. Dclcgation of authority to implement mandatory access control is limited. Separation of duties is an important concept in the distinction bctwecn authority in mandatory and discretionary access controls. In the mandatory cast, the user’s trustworthiness is established by a manual proccdurc conducted by an organization cxtcrnal to the computer organization, the results of which arc communicated to the security administrator through official channels. Similarly, the sensitivity of information is determined by a classification authority and communicated to the security administrator. With rcspcct to MAC, the security administrator and classification authority arc clearly defined roles with specific duties. In comparison, decisions and application of DAC arc nominally vcstcd in one individual. That is, MAC

Computers and Security, Vol. 9, No. 8

implements separation of responsibility while DAC does not. The DAC policy, which also dcfincs a relationship between subjects and objects, is tailorable by an authorized subject. This individual interprets the applicable policy, such as necd-toknow, and implements his or her decision in the computer. Even when a “well-known” security policy such as design decisions remain MAC is implcmentcd, concerning the expansion of the policy at the next level of detail. The TCSEC does not mandate all the details of the MAC policy, some arc left to the system architect. The design of American Telephone and Telegraph (AT&T) System V/MLS access controls is a good example. System V/MLS is evaluated at the Bl level by the National Computer Security Center (NCSC) [30]. Design decisions wcrc made for a number of operations based on the dominance of subject rclativc to object. The sclection of MAC policy elements for AT&T System V/MLS is discussed in rcf [3 I]. 4.2

Policy Variations

Other rcscarch efforts have proposed new access control mechanisms to handle various access control requirements. For example, Graubart [20] proposes a form of access control called “Propagated Access Control” to handle the case of ORCON. McCollum et al. [2l] also introduce a privilegeaccess control called “Owner-Retained based Access Control” to handle some of the special dissemination controls used in the DOD/intelligence community. The GFAC approach provides a structure for analyzing these various efforts by clearly identifying the attributes, rules, and authority. This section provides an example of how changing decisions in the policy refinement process can provide slightly different policies that may reflect certain organization’s access control requirements. In other words, MAC and DAC do not provide the controls conforming to the organization’s policy, but variations on MAC and DAC can provide the policy enforcement mechanisms desired. There has been considerable discussion about whether such

variations arc MAC or DAC and what actually constitutes MAC and DAC. WC suggest that such discussions are non-productive. GFAC has providcd an enriched framework to express such variations and to discuss access control in gcncral. Variation 1: A simple variation of DAC is nonread/copy-only access. Under this propagating policy, the owner (creator) of an object makes a binding decision as to who may read the object. In a single computer system, read may be accomplished without copy, but in a network copy may be required. For generality, copy will bc included. The copy policy, expressed by suitable constraints, is that all copies of an object must have associated with them an ACL identical to the one crcatcd by the owner. This refers to the strong binding as discussed in Section 3.9 with respect to MAC, the access control information (i.e. ACL) associated with the object stays with all topics or derivatives of that object. The binding for traditional DAC is weak. In this paper, a person having a copy of the information is referred to as a “holder”. The holder does not have the ability to pass the information to anyone not identified by the owner in the ACL, nor may (s)hc change the ACL. In contrast, with traditional DAC, a holder can generally change the ACL on his copy of the object as hc wishes. The security administrator, in most systems, is generally vicwcd as the ultimate authority for the system. Therefore, by default, the security administrator has privileges at all levels of the control hierarchy. Variation 2: Another policy which we will call “ORGANIZATION CONTROLLED” is introduced. The characteristics of this policy are the following: l The originator is an organization, represented by one or more individuals acting in a role WC will call “originating organization representative”, and abbreviated o-org-rep.

l

Information copying).

flow is prohibited

(i.e. no authorized

711

I. M. Olson et aLlComputer

l An ACL, associated rccipicnt organizations.

with

the object,

Access Policy Choices

There is an element of indirect addressing and separation of duties in that the originating organization representative will probably not have attributeor permission-level access to the ACLs specifying the various organization’s hcadquartcrs.

designates

l Dissemination within the recipient organizations is limited to the headquarters of that organization.

l

within organizational headDissemination quarters is controlled by another ACL identifying official roles, controlled by the “headquarters representative’! (HQ-rep). l Advance approval by the originating organization reprcsentativc is rcquircd for inclusion of extracts of the object in new objects.

l Dissemination of extracted information, permittcd by the originating organization rcprcscntativc, is achicvcd by creating a new object controlled by a different policy from organization controlled (such as PERSONAL FOR).

There arc several characteristics of ORGANIZATION CONTROLLED worth noting. It employs roles rather than individual idcntitics as part of the access control adjudication. The roles can bc assigned to diffcrcnt individuals to accommodate change of shift or cmploycc turnover; this assignmcnt can bc automatically pcrformcd by a timcdriven process under appropriate authorization.

TABLE

I

One can easily see how other slight variations could lead to different policies. For cxamplc, by adding “holder” (with append privilege) to the attribute level in the policy previously described as read/copy, the strong binding would bc rctaincd, but a holder would be allowed to add users to the object ACL, and not remove any of the users on the ACL associated with the original object. This would cnsurc that the owner and other users on the ACL of the original object would still have access to any copies or derivatives of that object, but allow the holder some latitude in increasing the accessibility of the object. Still other policies arc easily dcscribcd. These politics require further expansion and variation of the dimensions of control rcprcsented in Table 1. Examples include the following:

Policy variations

Sclccts markings Access lcvcl control Attribure lcvel control

Owner Owner, Owner.

PcrnGsion

Owner, holder security adminisrrator weak Read, Write Exccutc. Append,’

lcvcl control

Binding rules User permissions

,‘DAC controls rcprcscntativc.

712

Table I summarizes the control hierarchy and binding rules for DAC, MAC, and the two variations dcscribcd. The variations can be seen as combining some of the strengths of both DAC (flexibility and object owner decisions) and MAC (strength of binding).

arc usually

provided

Sccuriry adtninistraror Srcuritv administraror Sccuriry adrninisrraror. classificariotl aurhoricy Security administraror

holder holder

by the opcraring

Srrons All

system.

Diffcrcnr

opcraring

sysrcms

OWWX Owner Owner, security administrator Owner, security administrator Strong Read. Copy

provide

different

controls.

0-Org-llcp HQ-rep HQ-rep, security administrator HQ-rep, security administrator Strong Read only

These arc tnercly

Computers and Security, Vol. 9, No. 8

l A “TIME LOCK” policy may be applied to information to be protected until a certain date and time, after which the information is to be widely disseminated. This policy has wide applicability to government and corporate statistical and performance reports. l An “ELECTRONIC MARK-UP” policy would permit automation of the editorial review of documents by permitting authorized parties to indicate suggested changes to a document without having the ability to actually change the source. These suggestions would be annotated with the identity of the reviewer. l A “SELECTIVE RELEASE” policy would require specific authorization to release information dependent upon some characteristic of the recipient. Typical characteristics include employer and nationality. The release authority could be empowered to apply selective sanitization editing to the information prior to release.

5. Summary This paper has reviewed some of the policy decisions necessary in order to refine a high-level information dissemination/control policy into an implementable access control policy. As such, this paper can serve as a useful tool to an organization in developing a sound, implementable access control policy. While DAC and MAC have and will continue to serve as useful access control mechanisms, this paper presents GFAC as a framework for new, better, more flexible access control mechanisms to handle the varied and complex requirements of many organizations.

References [1] M. D. Abrams and H. J. Podell, Tutorial: Compufer and Network Security, IEEE Computer Society Press, 1987. [2] M. D. Zisman, Office automation: revolution or evolution, Sloan Manag. Rev., Spring 1978, pp. 1- 16. [3] D. E. Bell and L. J. LaPadula, Secure Cornpurer Systems: Mathematical Foundations, ESD-TR-73-278, Vol. I, The MITRE Corporation, March 1973.

PI

D. E. Bell and L. J. LaPadula, Secure Computer Systems: A Mafhematical Model, ESD-T&73-278, Vol. II, The MITRE Corporation, May 1973. Fl D. E. Bell and L. J. LaPadula, Secure Computer Sysfems: A Rt$nemenf of the Mathematical Model, ESD-TR-73-278, Vol. III, The MITKE Corporation, December 1973. (Vols. I-III are also available through National Technical Information Service, Springfield, VA, NTIS AD-780528.) D. E. Bell and L. J. LaPadula, Secure Computer Systems: Un$ed Exposition and Multics Interpretation, ESD-TK-75306, The MITRE Corporation, July 1975. (Aho available though National Technical Information Service, Springfield, Vh NTIS AD-A023588.) K. J. Biba, Integrity Considerations for Secure Computer Systems, Mm-3 153, The MITKE Corporation, June 1975. PI D. D. Clark and D. R. Wilson, A comparison of commercial and military computer security policies, Pror. 1987 Symp. on Security and Privacy, Oakland, CA, LEEE Computer Society Press, 1987, pp. 1a4- 194. PI D. Denmng, Lattice model of secure information flow, Commun. ACM, 19 (5) (1976) 236-243. I’01 D. 1. Good, A. E. Slebert and L. M. Smith, Message Flow Modulator Final Report, Institute for Computing Science, TR-34, University of Texas, December 1982. 11‘I K. D. Graubart and J. P. L. Woodward, A Preliminary Naval Surveillance DBMSSecurity Model, MTR-8475, The MITRE Corporation, May 1982. 1’21C. E. Landwehr, C. Heitmeyer and J. McLean, A security model for military message systems, ACM Trans. Computer Systems, 2 (3) (1984) 198-222. Applications for multilevel secure 1’31 J. P. L. Woodward, operating systems, Proc. NCC, Vol. 48, AFIPS Press, 1979, pp. 319-328. Formal models for computer security, I’41 C. E. Landwehr, Comput. SW., 13 (3) (1981) 247-277. I’ J. K. Millen and C. M. Cerniglia, Computer Security Models, MT%9531, The MITKE Corporation, September 1984. (Also available through National Technical Information Service, Springfield, VA., NTIS AD-A 166920.) 1’61 J. K. Millen, ModeL of M&/eve/ Computer Security, MTK10537, The MITBE Corporation, January 1989. Security Center (NCSC), Department 1’71 National Computer ofDefense Trusted Computer System Evaluation Criteria, DOD 5200.2%STD, December 1985. 1’81 M. D. Abrams, A. B. Jeng and I. M. Olson, Unijed Access Contra!: An Infirmal Description, MTR-89W 00230, The MITKE Corporation, September 1989. (Also available through National Technical Information Service, Springfield, VA, Publ. No. PB90 161977/AS). I’91 C. Wood, E. B. Fernandez and K. C. Summers, Database security: requirements, policies, and models, IBM Syst. /., 19 (2) (1980) 229-252. PI R. D. Graubart, On the need for a third form of access control, Proc. 12th National Computer Security Cont. NIST/ NCSC, Baltimore, MD, lo- 13 October 1989, pp. 296-304.

PI

PI

51

713

I. M. Olson et al. /Computer

Access Policy Choices

[ZI] C. J. McCollum, J. R. Messing and L. Notargiacomo, Beyond the pale of MAC and DAC-defining new forms of access control, Proc. 1990 IEEE Symp. on Research in Security and Privacy, Oakland, CA, April 1990, IEEJZ Computer Society Press, pp. 190-200. 1221 T. F. Keefe, D. J. Thomsen, W. T. Tsai and M. R. Hansch, Multi-party update conflict: the problem and its solution, Proc. 5th Annual Computer Security Applicabons Con& Tucson, AZ, December 1989, IEEE Computer Society Press, pp. 222-231. [23] S. B. Lipner, Non-discretionary controls for commercial applications, Proc. 1982 IEEE Symp. of Security and Privacy, Oakland, CA, 26-28 April 1982, IEEE Computer Society Press, pp. 143- 15 1. [24] J. C. Williams and M. L. Day, Sensitivity labels and security profiles, Proc. 11th National Computer Security Con& NBYNCSC, Baltimore, MD, 17-20 October 1988, pp. 257-266. NCSC, A Guide to UnderstandingDiscretionary Access Control in Trusted Systems, NCSC-TG-003, Version-l, 30 September 1987.

Ingrid M. Olson is a Member

of the Technical Staff at the MITRE Corporation in McLean, Virginia. As part of the Security Technical Center, she is involved in a project supporting the guidelines and standards development for the National Computer Security Center. In addition, she is actively involved in an internal research project developing a generalized frame&k-for access controls. Ms. Olson has a BA in mathematics and music from Hood College, and an MS in computer science from George Washington University.

714

[26] G. W. Smith, Identifying and representing the security semantics of an application, I’roc. 4111.4erospace Computer Security Applications Con& Orlando, FL, December 1988, IEEE Computer Society Press, pp. 125- 130. 1271 J. D. Moffett and M. S. Sloman, The source of authority for commercial access conrrol, Computer. February 1988, pp. 59-69. 1281 T. F. Lunt. Access control policies: some unanswered questions, Compuf. Secur., 8 (1989)43-54. 1291 NCSC, Trusted Network Inferprelafion o/the Tncrred Compuler Syslem Evaluation Criteria, NCSC-TG-005, Version- 1, July 1987. [30] NCSC, Final Eua/uationReport of American Telephone and Telegraph System V/ML.S Release I. 1.2 Running on UNLX System V Release 3.1. I, CSC-EPL-89/003, October 1989. 1311 C. W. Flink and J. D. Weiss, System V/MLS labeling and mandatory policy alternatives, AT&T Tech. /., May/June 1988, pp. 53-64.

Marshall D. Abrams is a Principal Scientist at the MITRE Corpora&n, McLean, Virginia, where he leads a project supporting the National Computer Security Center development of criteria and guidelines. He was a member of the working group that produced the Trusted Nettuork Inrelpretarion, serving as editor. He is principal investigator of a research project that is developing a generalized framework unifying access control concepts. He has held positions at the National Bureau of Standards and the University of Maryland. Dr. Abrams teaches international professional development continuing education seminars in Information Security. He holds the IEEE Computer Society Meritorious Service Certificate, the National Bureau of Standards Applied Research Award, and the Department of Commerce Silver Medal Award. He earned the BSEE from the Carnegie Institute of Technology and the MSEE and Ph.D. from the University of Pittsburgh.