A GUIDE TO WRITING THE SECURITY FEATURES USERS GUIDE FOR TRUSTED SYSTEMS
NCSC-TG-026
Library No. 5-237,294
Version t
FOREWORD
The National Computer Security Center is publishing A Guide to Writing the Security Features User's Guide for Trusted Systems as part of the "Rainbow Series" of documents our Technical Guidelines Program produces. In the Rainbow Series, we discuss in detail the features of the Department of Defense Trusted Computer System Evaluation Criteria (DoD 5200.28-STD) and provide guidance for meeting each requirement. The National Computer Security Center, through its Trusted Product Evaluation Program, evaluates the security features of commercially-produced computer systems. Together, these programs ensure that organizations are capable of protecting their important data with trusted computer systems.
A Guide to Writing the Security Features User's Guide for Trusted Systems expands on the Trusted Computer System Evaluation Criteria requirement for a Security Features User's Guide by discussing the intent behind the requirement and the relationship it has to other requirements in the Trusted Computer System Evaluation Criteria. The guide's target audience is the author of the Security Features User's Guide for a specific trusted system undergoing evaluation as a trusted product; however, many of the recommendations apply to any system that must satisfy the Trusted Computer System Evaluation Criteria requirements.
As the Director, National Computer Security Center, 1 invite your recommendations for revision to this technical guideline. We plan to review and update this document periodically in response to the needs of the community.
Please address any proposals for revision through appropriate channels to:
 | National Computer Security Center
| 9800 Savage Road
| |
Ft. George G. Meade, MD 20755-6000
Attention: Chief, Standards, Criteria, and Guidelines Division
| Patrick R. Gallagher, September 1991
| Director
| National Computer Security Center
| |
INTRODUCTION
1.1 PURPOSE
This guideline explains the motivation and meaning of the Department of Defense Trusted Computer System Evaluation Criteria (TCSEC) requirement for a Security Features Users Guide (SFUG), which reads as follows:
"A single summary, chapter, or manual in user documentation shall describe the protection mechanisms provided by the TCB, guidelines on their use, and how they interact with one another." [TCSEC; x.x.4.1]
The reader is assumed to be the potential author of a SFUG; to be familiar with the basic principles of technical writing, computer science, and trusted systems; and to have a detailed understanding of the specific trusted system that will be described in the SFUG.
1.2 SCOPE
This guideline identifies and discusses the considerations that influence the development and evaluation of a SFUG, such as its audience, content, and organization. It is intentionally descriptive, as opposed to prescriptive, in its discussion of the SFUG requirement. That is, it describes the various approaches to writing a SFUG that have been accepted by trusted product evaluators in the past, without making judgments about the "correct" ones to choose - although preferred approaches may be noted.
Throughout this guideline there will be statements made that are not included in the TCSEC as requirements. These statements will fall into three categories. First, some describe a strongly recommended course of action: these statements will be prefaced by the word "should." Second, others describe one of several equally appropriate recommended courses of action: these statements will be prefaced by the word "could." Finally, a few suggest an optional course of action: these statements will be prefaced by the word "can."
1.3 ORGANIZATION
The remainder of this guideline presents information that may be useful to a writer developing a SFUG. Chapter 2 discusses the developmental aspects of writing the SFUG, including the audience and possible packaging options, presentation styles, and the security topics that should be addressed in the SFUG (as derived from TCSEC feature requirements). Chapter 3 contains two example annotated outlines of SFUGs to illustrate some of the topics discussed in the body of the guideline and provide a starting point for the reader to develop a SFUG. The bibliography includes a list of the documents accepted as SFUGs for all products on the Evaluated Product List (EPL) at the time the guideline was published.
2. DEVELOPING THE SECURITY FEATURES USER'S GUIDE
The primary purpose of a SFUG is to explain how the security mechanisms in a specific system work, so that users are able to consistently and effectively protect their information. To properly communicate this information, the SFUG author must identify the audience for the SFUG and the information that audience needs to use the security mechanisms in the system and then select an appropriate way to present the information.
2.1 AUDIENCE AND PACKAGING
The SFUG requirement starts with "A single summary, chapter, or manual in user documentation . . .,, "User" in this context refers to a person who uses the system, but has no special privileges to affect the configuration of the system. The user for most general purpose trusted systems is often assumed to be a person with little or no computer experience, but this is not always the case. For example, the users of the UNIX™ system have traditionally been considered programmers or computer professionals with fairly extensive knowledge of computer concepts. In any system, the users are the audience for the SFUG and the SFUG author will have to characterize them to determine both the format and the level of discourse for the material presented in the SFUG.
In many cases, the SFUG requirement is satisfied by changing an existing document, which is one of the reasons that the SFUG requirement is so general.
As stated in the requirement, the SFUG could be:
| · A summary of the security features and user responsibilities,
| · A chapter devoted to these issues, or
| · A whole manual devoted to security.
| |
Some presentation schemes that previous participants in the Trusted Product Evaluation Program have used include:
A separate manual devoted to the general user of the system that covers the security features and responsibilities pertaining to users. This is usually the best choice when a document of this sort is already in place and the security functions have always been present in the system in some form anyway. For a system in which user services are provided by individual subsystems, one of which provides all the security functionality, and the user guide is the collection of user guides `for the individual subsystems, the SFUG would most likely be a stand-alone manual addressing only the security issues.
| · A subsection of the manual produced to satisfy the
Trusted Facility Manual (TFM) requirement of the TCSEC. From a
security standpoint, this is considered unwise, since it tends
to make the system configuration and vulnerability information
available to anyone looking for information on how to use the
security features of the system. From a documentation standpoint,
it seems the easiest, since it places all of the security discussion
in one place and allows a certain amount of synergy in the writing
process, i.e., privileged users do many of the same activities
as general users. This approach eliminates the need to document
those facilities in two places.
| · A chapter or an appendix of a user manual that discusses
the user's security responsibility and then provides an index
to the detailed discussions of individual functions that are already
part of the general user manual. An extension of this could be
a small pamphlet that does the same thing but can be reproduced
separately and given out as needed - something like a pocket guide
to system security.
| |
Trusted product evaluators tend to favor centralization of information, because that makes it easier to determine whether the system satisfies the TCSEC (Orange Book) requirements. Given that bias, bullet one would usually be the most preferred option, since it satisfies the requirement in one unique place. Bullet two is a less desirable option, because, in addition to the procedural security considerations, it requires some discrimination to identify which parts of the document satisfy the SFUG requirement and which parts satisfy the TFM requirement. Bullet three is least desirable for two reasons. First, it involves pointers to other information, making it more cumbersome for both evaluators and users to get to some aspects of the information. Second, there might be a tendency to make the document so terse that it excludes some information that is relevant to system security.
2.2 PRESENTATION
The SFUG provides the users of the system with the necessary background and specific information to use the protection features of the system correctly. Its purpose is twofold. First, it provides the information that a user needs to enter the system and start working-within the system security constraints. Second, it explains the user's role in maintaining the security of the system. Its scope should be limited to documenting only the features available to all users and only the responsibilities that all users have for system security. To accomplish this purpose, within the scope, the SFUG should explain what security means in the system, what security features are present and why, how the features work, and how to use the features properly. The SFUG should be clear, concise, and complete to increase its readability.
This information can be organized either by the security features present in the system or by the tasks performed by a user that require the use of these features. A feature-oriented presentation is more natural to a user who is already familiar with the system. In the SFUG, this organization would usually look like the TCSEC itself, with descriptions of each feature required by the TCSEC and explanations of the commands that make those features available to users. A task-oriented presentation is the more common approach taken in most user manuals, since it is oriented towards the specific actions that are necessary to enter a system and start working. Such a presentation will often take the form of a tutorial that describes the interactions that a user will usually have with the system, e.g., logging on, setting file access, changing the password, etc.
2.3 CONTENT
Because this guideline is devoted to explaining a TCSEC requirement, it will consider the content of a SFUG only from the perspective of the features required by the TCSEC that should be documented in the SFUG. OtheLr security-relevant features not addressed by the TCSEC (e.g., object downgrading or network commands) might also be included in the SFUG, but will not be discussed in this guideline.
The remainder of this section will list the features required by the TCSEC, identify the specific requirements that define them, and discuss how they apply to the SFUG. Many of the requirements cited use the acronym TCB, which expands to Trusted Computing Base. As defined in the TCSEC, the TCB is:
"The totality of protection mechanisms within a computer system-including hardware, firmware, and software-the combination of which is responsible for enforcing a security policy. A TCB consists of one or more components that together enforce a unified security policy over a product or system. The ability of a TCB to correctly enforce a security policy depends solely on the mechanisms within the TCB and on the correct input by system administrative personnel of parameters (e.g., a user's clearance) related to the security policy." [TCSEC, p. 116]
2.3.1 TECHNICAL SECURITY POLICY]
The technical security policy is the description of the access control model that the system enforces. This description can be either informal or formal for classes Cl through BI, but classes B2 to Al must have a formal description. The TCSEC design documentation requirement mandates that the informal description exist for all criteria classes where it states:
"Documentation shall be available that provides a description of the manufacturer's philosophy of protection . . .," [x.x.4.4]
Starting at BI, the design specification and verification requirement strengthens this notion of a technical security policy with the explicit requirement that:
"An informal or formal model of the security policy supported by the TCB shall be maintained over the life cycle of the ADP system and demonstrated to be consistent with its axioms."
[x.x.3.2.2]
At class B2, the design specification and verification requirement is changed to mandate a formal technical security policy model. Classes 83 and Al incorporate new requirements for additional supporting documentation thatk makes it possible to trace the basis for each feature in the system from the technical security policy to the implementation.
In the context of the TCSEC, neither the philosophy of protection nor the formal model have to be available to the user; however, the fact that the features of the system flow from these fundamental statements makes either one an appropriate starting point for describing how the system works. The philosophy of protection is probably the better choice for the SFUG, since it is usually written in a more intuitive style than a precisely stated security policy statement. In either case, the technical policy would be presented early in the SFUG to provide the overall context for the rest of the discussion, effectively becoming the thesis for the SFUG.
2.3.2 IDENTIFICATION AND AUTHENTlCATlON
The single largest and most crucial section of the SFUG, both from the perspective of the TCSEC and of overall system documentation,is the section that discusses how users identify and authenticate themselves (i.e., logon) to the system. The process of identification and authentication (l&A) defines the identity of the subject that the TCB creates to act on the user's behalf. For division B and A multilevel systems, the I&A process defines the upper and lower bounds on the security level of the subject as well. All subsequent access control decisions depend on this information being correct. The SFUG should therefore be very specific in describing both the l&A procedures and the user's responsibilities for protecting any information that is expected to be kept secret (e.g., passwords or personal identification numbers).
The TCSEC requirement for division C computer systems is shown below, with bold type showing the C2 requirements that go beyond those at Cl.
"The TCB shall require users to identify themselves to it before beginning to perform any other actions that the TCB is expected to mediate. Furthermore, the TCB shall use a protected mechanism (e.g., passwords) to authenticate the user's identity. The TCB shall protect authentication data so that it cannot be accessed by any unauthorized user. The TCB shall be able to enforce individual accountability by providing the capability to uniquely identify each individual ADP system user. The TCB shall also provide the capability of associating this identity with all auditable actions taken by that individual." [2.2.2.1]
Based on this requirement, the SFUG for a division C system should describe the identification process, including the use of a protected authentication mechanism. To complement the protection that the TCB must give the authentication data, the SFUG should make it clear that the user must protect the data too, for example, by not sharing a password with other users or writing it down on a sheet of paper next to the terminal.
For divisions B and A, the addition of multiple security levels changes the requirement, primarily by requiring the use of a user'sclearance as a bound on the security label of any subject that the TCB creates for that user. The BI requirement, which does not change for the higher classes, is shown below, with bold type showing additional wording and struck-out type showing wording that was deleted.
"The TCB shall require users to identify themselves to it before beginning to perform any other actions that the TCB is expected to mediate. Furthermore, the TCB shall maintain authentication data that includes information for verifying the identity of individual users (e.g., passwords) as well as information for determining the clearance and authorizations of individual users. This data shall be used by the TCB to authenticate the user's identity and to ensure that the security level and authorization of subjects external to the TCB that may be created to act on behalf of the individual user are dominated by the clearance and authorization of that user.
The TCB shall protect authentication data so that it cannot be accessed by any unauthorized user. The TCB shall be able to enforce individual accountability by providing the capability to uniquely identify each individual ADP system user. The TCB shall also provide the capability of associating this identity with all auditable actions taken by that individual." [3.1.2.1]
For all division B and A systems, the SFUG should incorporate a discussion of the relationship between a user's clearance (i.e., his or her general authorization to see information of a particular sensitivity-whether or not it is electronic) and the security level that the TCB associates with a particular subject (e.g., computer process or interactive session) that is acting on that user's behalf. Additionally, the practical consideration of how to establish the security level of that subject, for example, by using a logon option or a specific terminal, should be explained in the SFUG.
Starting at B2, there is an additional requirement for a trusted path to strengthen the confidence of both the user and the TCB that the l&A process is happening correctly. This requirement is shown below in both the B2 and B3/Al forms.
"The TCB shall support a trusted communication path between itself and user for initial login and authentication.
Communications via this path shall be initiated exclusively by a
user." [3.2.2.1.1(B2)]
"The TCB shall support a trusted communication path between itself and users for use when a positive TCB-to-user connection J5 required (e.g., Iogin, change subject security level). Communications via this trusted path shall be activated exclusively by a user or the TCB and shall be logically isolated and unmistakably distinguishable from other paths." [3.3.2.1.1
(B3/Al)]
Trusted path is useless if it is not used; therefore, the SFUG should be written so that the user understands how to initiate the trusted path, especially at logon, and why it is important to do so. For systems that satisfy the B3 trusted path requirement, the SFUG should also explain how the initiation of a trusted path during a session, whether by the user or the TCB, affects the currently running subject, as well as how to recognize the trusted path.
2.3.3 DISCRETIONARY ACCESS CONTROL FACILITY
The discretionary access control (DAC) facility provides the mechanism by which the individual user can control access to his or her data. Some form of DAC is required for every class of the TCSEC. After the procedures for identifying and authenticating themselves to the system, the DAC facilities will be the aspects of the system security of most interest to most users.
The DAC facility is first defined by the Cl DAC requirement that: "The TCB shall define and control access between named users and named objects (e.g., files and programs) in the ADP system. The enforcement mechanism (e.g., self/group/public controls, access control lists) shall allow users to specify and control sharing of those objects by named individuals or defined groups or both." [2.1.1.1] At C2 this requirement is enhanced to read (bold type shows added words): "The TCB shall define and control access between named users and named objects (e.g., files and programs) in'the ADP system. The enforcement mechanism (e.g., self/group/public controls, access control lists) shall allow users to specify and control sharing of those objects by named individuals, or defined groups of individuals, or by both, and shall provide controls to limit propagation of access rights. The discretionary access control mechanism shall, either by explicit user action or by default, provide that objects are protected from unauthorized access. These access controls shall be capable of including or excluding access to the granularity of a single user. Access permission to an object by users not already possessing access permission shall only be assigned by authorized users." [2.2.1.1]
After this it remains the same until B3, when it is changed to read (bold type shows added words, struck-out type shows deleted words):
"The TCB shall define and control access between named users and named objects (e.g.,files and programs) in the ADP system. The enforcement mechanism (e.g., self/group/public controls, access control lists) shall allow users to specify and control sharing of those objects by named individuals, or defined groups of individuals, or by both, and shall provide controls to limit propagation of access rights. The discretionary access control mechanism shall, either by explicit user action or by default, provide that objects are protected from unauthorized access. These access controls shall be capable of specifying, for each named object, a list of named individuals and a list of groups of named individuals with their respective modes of access to that object.
Furthermore, for each such named object, it shall be possible to specify a list of named individuals and a list of groups of named individuals for which no access to the object is to be given. including or excluding access to the granularity of a single user. Access permission to an object by users not already possessing,,access permission shall only be assigned by authorized users. [3.3.1.1]
For any version of this requirement, the goal for the SFUG author is the same -to describe to users how to use the DAC enforcement mechanism to control access to the objects that they own. The SFUG should provide enough information for the user to understand what a named object, a named user, and a group are, as well as what types of objects can be controlled with DAC. It should also explain how a new user or group is defined to the system. The SFUG should also describe the process by which access rights are initially determined and then propagated. Finally, the SFUG should describe the system commands and procedures for using the DAC facility.
2.3.4 ELECTRONIC LABELS
The distinguishing feature of all division B and A computer classes is the electronic label. An electronic label is an attribute of each subject and object under TCB control that indicates the sensitivity of the information that a subject is authorized to see or that is contained in an object. The real world equivalents of these concepts are security clearances and classification markings. Many users who are familiar with these real world examples have trouble adapting to electronic labels; therefore, the SFUG written for a multilevel system should discuss labels and their effect on a user's actions. The basic label requirement is defined by the following words at Bl: "Sensitivity labels associated with each subject and storage object under its control (e.g., process, file, segment, device) shall be maintained by the TCB. These labels shall be used as the basis for mandatory access control decisions. In order to import non-labeled data, the TCB shall request and receive from an authorized user the security level of the data, and all such actions shall be auditable by the TCB." [3.1.1.3] At B2, the first sentence is changed to read: "Sensitivity labels associated with each ADP system resource (e.g., subject, storage object, ROM) that is directly or indirectly accessible by subjects external to the TCB shall be maintained by the TCB." [3.2.1.3] This reflects the general B2 through Al requirement that all computer resources be under the control of the TCB.
Another label-related requirement that affects the users of a system is the one for labeling human-readable output, which states that:
"The ADP system administrator shall be able to specify the printable label names associated with exported sensitivity labels. The TCB shall mark the beginning and end of all human-readable, paged, hardcopy output (e.g., line printer output) with human-readable sensitivity labels that properly represent the sensitivity of the output. The TCB shall, by default, mark the top and bottom of each page of human- readable, paged, hardcopy output (e.g., line printer output) with human-readable sensitivity labels that properly represent the overall sensitivity of the output or that properly represent the sensitivity of the information on the page. The TCB shall, by default and in an appropriate manner, mark other (forms of human-readable output (e.g., maps, graphics) with human- readable sensitivity labels that properly represent the sensitivity of the output. Any override of these marking defaults shall be auditable by the TCB." [3.1.1.3.2.3] The above requirement is the same for classes Bl through Al.
These two requirements, for subject sensitivity labels and labeled human-readable output, apply to any multilevel system; therefore, the SFUG for all B and A level systems should, at the least, explain:
| · How labels are attached to subjects and objects,
| · The relationship between the "clearance"
that a user has and the label that is associated with a particular
computer session, and
| · The reason for job and page labels on printed output
and terminal or window labels on computer displays (as well as
cautions about disabling the display of such labels).
| |
The last requirement that affects users is one for subject sensitivity labels that requires that:
"The TCB shall immediately notify a terminal user of each change in the security level associated with that user during an interactive session. A terminal user shall be able to query the TCB as desired for a display of the subject's complete sensitivity label." [3.2.1.3.3]
The above requirement applies to classes B2 through Al; therefore, the SFUG for these systems should explain the mechanism used to notify a user of a security level change.
2.3.5 MANDATORY ACCESS CONTROL FACILITY
Closely associated with, but separate from, the requirement for labels is the requirement for mandatory access control (MAC). MAC refers to the set of rules that control a subject's access to an object based on the label attached to each.
The MAC facility is first defined by the BI MAC requirement that: "The TCB shall enforce a mandatory access control policy over all subjects and storage objects under its control (e.g., processes, files, segments, devices). These subjects and objects shall be assigned sensitivity labels that are a combination of hierarchical classification levels and non- hierarchical categories, and the labels shall be used as the basis for mandatory access control decisions. The TCB shall be able to support two or more such security levels. The following requirements shall hold for all accesses between subjects and objects controlled by the TCB: A subject can read an object only if the hierarchical classification in the subject's security level is greater than or equal to the hierarchical classification in the object's security level and the non- hierarchical categories in the subject's security level include all the non-hierarchical categories in the object's security level. A subject can write an object only if the hierarchical classification in the subject's security level is less than or equal to the hierarchical classification in the object's security level and all the non-hierarchical categories in the subject's security level are included in the non-hierarchical categories in the object's security level. Identification and authentication data shall be used by the TCB to authenticate the user's identity and to ensure that the security level and authorization of subjects external to the TC8 that may be created to act on behalf of the individual user are dominated by the clearance and authorization of that user." [3.1.1.4]
For classes B2 through Al, the requirement is enhanced to reflect the pervasive TCB control required by these higher classes. (The bold type in the following quote shows the additional wording, while the struck-out type shows the phases deleted.)
"The TCB shall enforce a mandatory access control policy over all resources (i.e., subjects, storage objects, and 1/0 devices) that are directly or indirectly accessible by subjects external to the TCB.
These subjects and objects shall be assigned sensitivity labels that are a combination of hierarchical classification levels and non-hierarchical categories, and the labels shall be used as the basis for mandatory access control decisions. The TCB shall be able to support two or more such security levels. The following requirements shall hold for all accesses between all subjects external to the TCB and all objects directly or indirectly accessible by these subjects: A subject can read an object only if the hierarchical classification in the subject's security level is greater than or equal to the hierarchical classification in the object's security level and the non-hierarchical categories in the subject's security level include all the non-hierarchical categories in the object's security level. A subject can write an object only if the hierarchical classification in the subject's security level is less than or equal to the hierarchical classification in the object's security level and all -the non- hierarchical categories in the subject's security level are included in the non-hierarchical categories in the object's security level. Identification and authentication data shall be used by the TCB to authenticate the user's identity and to ensure that the security level and authorization of subjects external to the TCB that may be created to act on behalf of the individual user are dominated by the clearance and authorization of that user." [3.2.1.4]
Because the TCB, rather than the user, controls the actual interaction between the labels of subjects and objects, the SFUG only needs to explain to users how MAC constrains their actions. This discussion is probably most natural under the section that addresses the technical security policy. In most cases, a user can have only one effect on the MAC policy-to change the label for a session, which is already described under either the discussion of identification and authentication or labels.
2.3.6 TRUSTED FACILITY MANAGEMENT
Beginning at B2, there is a TCSEC requirement that: "The TCB shall support separate operator and administrator functions." [3.2.3.1.4]
This mandates a separation of duties in the administration of computer systems that are supposed to be protecting information. This corresponds to the natural separation of duties found in most human activity. Although this is not a requirement until B2, many sites that are concerned about security are instituting programs `rvhere the responsibility for security administration of the computer system is centralized in a person with the title of computer, or information system, security officer (CSO or 1550, respectively). Whether the computer system being described in the SFUG satisfies the trusted facility management requirement or not, the author of the SFUG for that system may want to postulate the existence of such a position to represent the entity that is responsible for security issues that are outside the control of the users. This both allows the SFUG to be written in a more active voice and simplifies the job of conveying distinctions between user security responsibilities and site management security responsibilities.
3. EXAMPLES OF SFUG PRESENTATION STYLES
This chapter presents two sample stand-alone SFUGs to show what could go into a SFUG and possibly give the reader some ideas for organizing a system specific SFUG. The actual contents and organization of a real SFUG will be different to reflect the specific mechanisms of the individual system and the organization of the rest of the system documentation. The first example uses a feature-oriented style presentation, while the second shows a task-oriented style.
In addition to these generic examples, the reader may find it helpful to review the SFUGs of previously evaluated systems to see what worked for them. Entries 2 through 16 in the bibliography list the Final Evaluation Reports (FERs) for products on the Evaluated Products List that had published FERs at the time this guideline was printed. Each entry is annotated with the document(s) identified in the FER as satisfying the SFUG requirement for that product.
THE FEATURE-ORIENTED SFUG
At a high level, the feature-oriented example SFUG is arranged in the following fashion:
| 1. INTRODUCTION TO THE SFUG
| 2. SYSTEM SECURITY OVERVIEW
|
3. SECURITY-RELATED COMMANDS FOR USERS
|
|
The annotated outline follows.
1. INTRODUCTION TO THE SFUG
| This part of the SFUG should identify what the SFUG is, who it is written for, what it will cover, and where to go for more information, if needed. |
2. SYSTEM SECURITY OVERVIEW
| This section provides the background on the overall operation of the security controls in the system so that users can then understand the options and actions of individual security-relevant commands. |
|
2.1 SYSTEM PHILOSOPHY OF PROTECTION
| This section should describe the general environment for which the system is designed and briefly explain how this environment motivates the approach to protecting information stored in the system. The purpose of this section is to lay the foundation for the user's understanding of the system's security features, with later sections detailing what specific security services are available and when and how to use them. |
|
2.2 DEFINITION OF TERMS AND SERVICES
| This section should first introduce the terms that will be
used to describe the security services available in the system
and then proceed to introduce those services, without detailing
exactly how they are used. Recommended topics for this section
are:
|
2.3 THE INFORMATION SYSTEM SECURITY OFFICER
| This section discusses the role of the Information System
Security Officer (1550) in maintaining the security of the system.
It can also explain which problems should be reported to the 1550
and which should be reported to the system administrator (if the
roles are separate). If the format of the SFUG allows it, this
section could have space for site-specific notes on the 1550/user
relationship.
|
| |
2.4 USER SECURITY RESPONSlBlLlTlES
| This section discusses the user's responsibilities with respect to properly using the system security features. This would optimally be a tutorial that teaches effective use of the system security services, but any presentation that relates the security services to the user's day-to-day use of the system is appropriate. Some issues that might be addressed are: |
| · Authentication token (e.g., password or smartcard)
protection.
| · Warnings about leaving a terminal unattended.
| · Procedures for "locking" a process when the
terminal must be left unattended, but logged in.
| · Default DAC access for named objects (e.g., files andkdirectories).
| · Cautions about using programs that are not part of
the standard system configuration (e.g., utilities or applications
that have not been reviewed and tested by the system administrator(s)).
| · Cautions about the effect of network access on system
and data security.
| |
3.SECURITY-RELATED COMMANDS FOR USERS
| This section comprises the majority of the SFUG since it describes in detail the commands and procedures for actually using the system. |
3.1 USER IDENTIFICATION AND AUTHENTICATION
| This section should step through the procedures for logging on to and off of the system and for manipulating privileges and participation in the system. Additionally, any of the errors that might occur during the use of these commands and the corrective actions should be described here. |
3.1.1 Trusted Path
| In 82 and above systems, the first thing that a user will have to do to Iogon is establish a trusted path between his terminal and the system TCB. This section should describe that process. For 83 and Al systems, this trusted path is available for any direct interaction between the TC8 and the user; therefore, in-session invocation of the trusted path and its effects on currently executing processes should be described here. |
|
3.1.2 Logging On to the System
| The procedure for logging on to the system should be described. If the system has MAC, the procedures for logging on with specific, non-default authorizations should be described. |
3.1.3 Password Consideration
| The procedures and commands for setting, changing, and protecting passwords should be described. |
3.1.4 Changing Group Membership
| In systems with the concept of DAC groups, the mechanisms for users to specify the group membership(s) that should be used in making DAC access decisions (if such capability is present) should be described. |
3.1.5 Changing Current MAC Authorizations
| In systems with MAC, if the user can change their current authorization level and category set without logging off, the mechanism and procedure should be described. |
3.1.6 Logging Off of the System
| The command or procedure for logging off the system should be described. |
3.1.7 I&A Errors and Their Causes
The possible error messages that can occur when l&A commands are improperly invoked should be noted and the correct or expected inputs should be explained.
3.2 DISCRETIONARY ACCESS CONTROL FACILITIES
| This section should describe the DAC-related commands and procedures for the system. This section will be present in some form at all levels of the criteria. |
3.2.1 Setting DAC on Named Objects
| This section should describe how users can set the discretionary access permissions, and what the permissions mean, for the different types of named objects in the system. |
3.2.2 Default DAC Protection
| The means for determining and setting the default discretionary access controls on user controlled or owned named objects should be described. |
3.2.3 DAC Groups
| When the capability exists for users to define groups of users for the purpose of lDAC, the mechanisms for defining these groups should be described. |
3.2.4 DAC Errors and Their Causes
| The possible error messages that can occur when DAC commands are improperly invoked should be noted and the correct or expected inputs should be explained. |
|
3.3 MANDATORY ACCESS CONTROL FACILITIES
| This section is for systems in the B and A classes. It describes the commands that a general user will need for dealing with labeled objects. |
3.3.1 Printing Labeled Objects
| This section describes the mechanism for printing or otherwise producing non-electronic versions of labeled objects. Of specific interest is the mechanism that would be used for overriding the default printing of the object's label in human-readable form. The description of this capability could be accompanied by a discussion of the security considerations that go with its use. |
3.3.2 Accessing Single-Level Devices
| This section should discuss the constraints on the use of single-level devices in the presence of multiple authorization levels. For example, this section could discuss how the TCB determines a user's access to a single-level device based on the user's authorization level. |
3.3.3 Accessing Multilevel Devices
| This section should discuss the rules for the interaction between users at multiple authorization levels and multilevel devices. |
3.3.4 Downgrading Labeled Objects
| Although it is not a part of TCSEC evaluations, if the system offers an object downgrade facility that is available to the target audience of the SFUG, this facility and cautions on its proper use should be described. |
3.3.5 MAC Errors and Their Causes
| The possible error messages that can occur `when MAC commands are improperly invoked should be noted and the correct or expected inputs should be explained. |
|
|
3.4. OBJECT MANIPULATION FACILITIES
| This section should discuss the commands and mechanisms available for dealing with objects. |
3.4.1 Object Creation, Reuse, and Deletion
|
|
3.4.2 Importing Machine-Readable Objects
| The mechanisms for a user to introduce a machine-readable object into the system from an external source (e.g., tape, removable diskette, or network) and assign discretionary and mandatory access control properties to it should be described if such a facility exists. |
3.4.3 Exporting Machine-Readable Objects
| The mechanisms for a user to export a machine readable object from the system to an external source (e.g., tape, removable diskette, or,network), along with its discretionary and mandatory access control properties, should be described if such a facility exists. |
3.4.4 Determining the Properties of Objects
| The commands or mechanisms for determining the discretionary and mandatory access control properties of an object should be described. |
3.4.5 Object Manipulation Errors and Their Causes
| The possible error messages that can occur when object manipulation commands are improperly invoked should be noted and the correct or expected inputs should be explained. |
THE TASK-ORIENTED SFUG
At a high level, the task-oriented example SFUG is arranged in the following fashion:
| 1. INTRODUCTION TO THE SFUG
| 2. SYSTEM SECURITY OVERVIEW
|
3. SECURITY-RELATED COMMANDS FOR USERS
|
|
The annotated outline follows.
1. INTRODUCTION TO THE SFUG
| This part of the SFUG should identify what the SFUG is, who it is written for, and what it will cover. It might also explain where the SFUG fits in with the rest of the user documentation. If appropriate, it can also describe the relationship between the SFUG and the TFM. |
|
|
| |
2. SYSTEM SECURITY OVERVIEW
| This section provides the background on the overall operation of the security controls in the system so that users can then understand the options and actions of individual security-relevant commands. |
2.1 SYSTEM PHILOSOPHY OF PROTECTION
| This section should describe the general environment for which the system is designed and briefly explain how this environment motivates the approach to protecting information stored in the system. The purpose of this section is to lay the foundation for the user's understanding of the system's security features, with later sections detailing what specific security services are available and when and how to use them. |
2.2 DEFINITION OF TERMS AND SERVICES
| This section should first introduce the terms that will be
used to describe the security services available in the system
and then proceed to introduce those services, without detailing
exactly how they are used. Recommended topics (and the criteria
classes for.which they are relevant) for this section are:
|
2.3 THE INFORMATION SYSTEM SECURITY OFFICER
| This section discusses the role of the information system security officer (1SS0) in maintaining the security of the system. It can also explain which problems should be reported to the 1SS0 and which should be reported to the system administrator (if the roles are separate). If the format of the SFUG allows it, this section could have space for site-specific notes on the 1SS0/user relationship. |
2.4 USER SECURITY RESPONSIBILITIES
| This section discusses the user's responsibilities with respect to properly using the system security features. This would optimally be a tutorial that teaches effective use of the system security services, but any presentation that relates the security services to the user's day-to-day use of the system is appropriate. Some issues that might be addressed are: |
| · Authentication token (e.g., password or smartcard)
protection.
| · Warnings about leaving a terminal unattended.
| · Procedures for "locking" a process when the
terminal must be left unattended, but logged in.
| · Default DAC access for named objects (e.g., files and
directories).
| · Cautions about using programs that are not part of
the standard system configuration (e.g., utilities or applications
that have not been reviewed and tested by the system administrator(s)).
| · Cautions about the effect of network access on system
and data security.
| |
3. SECURITY-RELATED COMMANDS FOR USERS
| This section comprises the majority of the SFUG since it describes in detail the commands and procedures for actually using the system. It should describe both the usage of the commands and reemphasize their role as tools to protect information stored on the system. For example, this part might consist of command reference pages (e.g., UNIX "man" pages) grouped by subject, possibly with a brief introduction at the beginning of each subject area. Alternatively, this section could contain general descriptions of the operation and options of individual commands or groups of commands, along with pointers to the detailed documentation of the invocation sequence(s) for the commands. |
3.1 SYSTEM ACCESS
| This section should explain the procedures for logging on and off the system. It should also discuss how the TCB assigns privileges and authorizations during the login process and how the user can change them during the session (if the system allows in-session changes). This section might also discuss how users can prevent and detect compromise of their accounts. For systems that provide trusted path during a session, this section of the SFUG should describe the mechanism for invoking the trusted path and the effect of the invocation on the currently running process. Finally, the errors that might occur during the use of these commands and corrective actions should be described here. |
3.1.1 Session Initiation
| This section should describe the procedures that a user goes through to establish a session with the system. In B2 nd above systems, this discussion will start by describing how a user establishes a trusted path between the terminal and the TCB. For any system, it will discuss the procedure for presenting the identification and authentication tokens (typically a user-id and password) to the system so that the system can establish a subject to act on behalf of the user. When the login process provides the means for overriding the default group/project and subject sensitivity level, the use of these options should be described. |
3.1.2 Changing the Session Profile
| When the system provides the facilities for the user to dynamically modify his or her group/project participation and/or subject sensitivity level, this section should describe them. |
3.1.3 Changing the User Profile
| Many systems have the concept of a user profile, which contains the default settings for the creation of a user subject. Although it may actually be maintained separately, the user password is logically part of this profile. This section should provide information on how to modify the parts of the user profile over which the user has control. At a minimum, this section should show how the user can change his or her password (for systems where the password is the authentication token). |
3.1.4 Potential Access Problems and Solutions
| This section should discuss the possible problems that a user could encounter when logging into the system or modifying session and user profiles. This section could be organized as a troubleshooting guide, where each problem and its potential solution(s) is presented in a table format. |
3.2 ACCESS CONTROL FACILITIES
| This section describes the commands available to a user for
managing the objects under his or her control. The major issue
confronting the SFUG author in this section is how to organize
the commands. Two possible options are:
|
| Experience during previous evaluations indicates that the second option more closely matches the needs of the user, since it is closer to the organization expected when trying to search for a specific command to do a specific job. |
3.3 PROTECTING REMOVABLE OBJECTS
| This section should discuss some of the basic actions that a user should take to ensure that the data contained in hardcopy or external storage form is protected as fully as when it is on the computer system. In a site-specific SFUG, this section could be an even stronger statement regarding the site's procedures for protecting information once it leaves the system. |
3.4 LOGGING SECURITY-RELEVANT EVENTS
| In some systems, it may be possible for users to do limited auditing on the objects over which they have control. In these cases, the commands available to the user for this purpose should be described. |
BIBLIOGRAPHY
| 1. DoD Trusted Computer System Evaluation criteria, Natonal
Computer Security Center, DoD 5200.28-STD, 1985.
| 2. American Telephone and Telegraph System V/MLS Release 1.1.2
Running on UNIX System V Release 3.1.1 (Final Evaluation Report),
National Computer Security Center, CSC-EPL-89/003, October 1989.
| This FER identified the following four documents as the SFUG
for this product:
|
|
| 3. Computer Associates International CA-ACF2/VM, Release 3.1
(Final Evaluation Report), National Computer Security Center,
CSC-EPL-87/007, September 1987.
| This FER identified the following four documents as the SFUG
for this product:
|
|
| 4. Computer Associates International Top Secret, Version 3.0
(Final Evaluation Report), DoD Computer Security Center, CSC-EPL-85/002,,-
April 1985.
| This FER identified the following two documents as the SFUG
for this product:
|
|
5. Control Data Corporation Network Operating System Security Evaluation Package (Final Evaluation Report), National Computer Security Center, CSC-EPL-86/003, May 1986.
| This FER identified the following document as the SFUG for
this product:
|
| 6. Digital Equipment Corporation VAX/VMS, Version 4.3 (Final
Evaluation Report), National Computer Security Center, CSC-EPL-86/004,
July 1986.
| This FER identified the following document as the SFUG for
this product:
|
|
| 7. Data General Corporation Advanced Operating System/Virtual
Storage (A 05/VS) (Final Evaluation Report), National Computer
Security Center, CSC-EPL-89/001, February 1989.
| This FER identified the following two documents as the SFUG
for this product:
|
|
| 8. Gould, Inc Computer Systems Division UTX/32S, Release 1.0
(Final Evaluation Report), National Computer Security Center,
CSC-EPL-86/007, December 1986.
| This FER identified the following document as the SFUG for
this product:
|
|
| 9. Hewlett Packard Commercial Systems Division MPE v/E (Final
Evaluation Report), National Computer Security Center, CSC-EPL-88/01
0, October 1988.
| This FER identified the following document as the SFUG for
this product:
|
|
| 10. Honeywell MULTICS, MR1 1.0 (Final Evaluation Report),
National Computer Security Center, CSC-EPL-85/003, June 1986.
| This FER identified the following document as the SFUG for
this product:
|
|
| 11. Honeywell SCOMP (Secure Communications Processor) STOP
Release 2.1 (Final Evaluation Report), DoD Computer Security Center,
CSC-EPL-85/001, September 1985.
| This FER identified the following document as the SFUG for
this product:
|
|
| 12. International Business Machines Resource Access Control
Facility (RACF), Version 1, Release 5 (Final Evaluation Report),
DoD Computer Security Center, CSC-EPL-84/001, July 1984.
| This FER identified the following document as the SFUG for
this product:
|
|
| 13. International Business Machines Corporation VM/SP with
RACF (Final Evaluation Report), National Computer Security Center,
CSC-EPL-89/005, September 1989.
| This FER identified the following six documents as the SFUG
for this product:
|
|
14. Prime Computer, Inc PRlMOS Rev 21.0.1. DODC2A (Final Evaluation Report), National Computer Security Center, CSC-EPL88/009, July 1988.
| This FER identified the following document as the SFUG for
this product:
|
| 15. UNlSYS Corporation A Series MCP/AS Release 3.7 (Final
Evaluation Report), National Computer Security Center, CSC-EPL-87/003,
August 1987.
| This FER identified the following document as the SFUG for
this product:
|
|
| 16. UNlSYS Corporation OS 1100 (Final Evaluation Report),
National Computer Security Center, CSC-EPL-89/004, September 1989.
| This FER identified the following document as the SFUG for
this product:
| |
OS 1100 Security System Operations Guide, UP-I 3011.1, August 1989.