Published for the Office of the Secretary of Defense
Reissued October 1979
Rand |
APPROVED FOR PUBLIC RELEASE; DISTRIBUTION UNLIMITED
In October 1967 a Task Force was organized by the Advanced Research Projects Agency (now the Defense Advanced Research Projects Agency) to study and recommend appropriate computer security safeguards that would protect classified information in multi-access, resource-sharing computer systems. The report of the Task Force, which functioned under the auspices of the Defense Science Board, was published by The Rand Corporation in February 1970 for the Office of the Director of Defense Research and Engineering, Department of Defense. A slightly modified version of the report -- the only omissions were two memoranda of transmittal from the Task Force to the Chairman of the Defense Science Board and onward to the Secretary of Defense -- was subsequently published as Rand Report R-609, Security Controls for Computer Systems. At that time it was felt that because representatives from government agencies participated in the work of the Task Force, the information in the report would appear to be of an official nature, suggestive of the policies and guidelines that would eventually be established. Consequently, it was felt prudent to classify the report Confidential overall. On October 10, 1975, the Defense Advanced Research Projects Agency declassified it.
Nearly a decade later the report is still a valuable comprehensive discussion of security controls for resource-sharing computer systems. Ideas first expressed in this report and even occasional figures from it have gradually seeped into the technical literature, but it still contains material that has not been published elsewhere. For example, it includes an appendix that outlines and formally specifies a set of access controls that can accommodate the intricate structure of the classification system used by the defense establishment.
The original classification of the report limited its distribution largely to defense agencies and defense contractors; civil agencies of government and industry at large generally did not have access to it. Because of the continuing importance of computer security, the report is being reissued at this time for wider distribution.
The support of The Rand Corporation in reprinting this report is gratefully acknowledged.
Willis H. Ware
October 10, 1979
I.
II.
III.
IV
V.
VI.The Security Problem
Types of Computer Systems
Threats to System Security
Areas of Security Protection
System Characteristics
Definitions
Part B. POLICY CONSIDERATIONS AND RECOMMENDATIONS
I.
II.
III.
IV.
V.
VI.
VII.
VIII.Fundamental Principles
System Personnel
Information Structure and Transforms
System Transaction Accounting
Reliability and Auto-Testing
Information Security Labels
Management of Storage Resources
System Certification
Part C. TECHNICAL RECOMMENDATIONS
I.
II.
III.
IV.
V.
VI.
VII.
VIII.
IX.
X.Introduction
Central Processor Hardware
Software
Access Control Throughout the System
Communication Lines
Terminals
Certification
Open Environment Considerations
Research Needed
Overall System Problems
Part D. MANAGEMENT AND ADMINISTRATIVE CONTROL
Appendix: AUTOMATION OF A MULTILEVEL SECURITY SYSTEM
Introduction
Computer System Catalogs
Security Control System Generation
Security Structure Definition
Personnel Security Definition and User Clearance Update
Authorization Group Definition
Universal Privileges
Terminal Security Definition and Update
File Access Processing
Annex A: Formal System Access Specification
Annex B: Security Component Definition Examples
The question of security control in resource-sharing systems was brought into focus for the Department of Defense by a series of events in the spring and summer of 1967. Such systems were being procured in increasing numbers for government installations; the problems of security for them were becoming of pressing concern both to defense contractors and to military operations; the Research Security Administrators had forwarded a position paper through the Defense Supply Agency to the Director for Security Policy in the Office of Assistant Secretary of Defense (Administration) soliciting action. Since the matter involved technical issues, the paper was referred to the Office of the Director of Defense Research and Engineering for consideration.
In June 1967, the Deputy Director (Administration, Evaluation and Management) requested the Director of the Advanced Research Projects Agency (ARPA) to form a Task Force to study and recommend hardware and software safeguards that would satisfactorily protect classified information in multi-access, resource-sharing computer systems. Within ARPA, the responsibility for this task was forwarded to Mr. Robert W. Taylor, Director of the Office of Information Processing Techniques.
A series of discussions was held during the summer and fall months of 1967 with people from the university and industrial communities, culminating in the formation by October 1967 of a Task Force consisting of a Steering Group and two Panels. The organizational meeting was held the following month, and thereafter the Panels and the Steering Group met on a regular basis to formulate the recommendations that constitute the body of this Report. The Task Force has operated formally under the authority of the Defense Science Board. Following are the members of the Steering Group:
Willis H. Ware, Chairman, The Rand Corporation, Santa Monica, Calif.J. Patrick Haverty, Deputy Chairman, The Rand Corporation, Santa Monica, Calif.
Robert A. Mosier, Vice Chairman, System Development Corporation, Santa Monica, Calif.
Arthur A. Bushkin, Secretary, Lockheed Missiles and Space Co., Palo Alto, Calif (formerly, Massachusetts Institute of Technology and Bolt, Beranek and Newman)
Elliot Cassidy, Directorate for Security Policy, Department of Defense, Washington, D.C.
John F. Egan, Office of the Secretary of Defense/DDR&E, Department of Defense, Washington, D.C.
Edward L. Glaser, Case Western Reserve University, Cleveland, Ohio
John W. Kuipers, Central Intelligence Agency, Washington, D.C.
Jerome D. Moskowitz, National Security Agency. Fort George G. Meade, Maryland
Lawrence G. Roberts (formerly, Robert W. Taylor) Advanced Research Projects Agency, Department of Defense. Washington, D.C.
Robert von Buelow, System Development Corporation, Santa Monica, Calif.
The two panels organized under the Steering Group are the Policy Panel and the Technical Panel. The following are members of the Policy Panel:
Jerome D. Moskowitz, Chairman, National Security Agency, Fort George G. Meade, MarylandDonal Burns, Central Intelligence Agency, Washington, D.C.
Thomas Chittenden, National Security Agency, Fort George G. Meade, Maryland
Richard G. Cleaveland, Defense Communication Agency, Washington, D.C.
Roy McCabe, System Development Corporation, Sacramento, Calif.
Barry Wessler, Advanced Research Projects Agency, Department of Defense, Washington, D.C.
Ronald Wigington, Chemical Abstracts Service, Columbus, Ohio
Edward L. Glaser (ex officio), Case Western Reserve University, Cleveland, Ohio
Willis H. Ware (ex officio), The Rand Corporation, Santa Monica, Calif.
The Technical Panel consists of the following:
Edward L. Glaser, Chairman, Case Western Reserve University, Cleveland, OhioArthur A. Bushkin, Secretary, Lockheed Missiles and Space, Co., Palo Alto, Calif.
James P. Anderson, James P. Anderson and Co., Fort Washington, Pa.
Edward H. Bensley, The MITRE Corporation, Bedford, Mass.
Charles R. Blair, International Business Machines Corp., Yorktown, N.Y.
Daniel L. Edwards, National Security Agency, Washington, D.C.
Harold M. Jayne, Executive Office of The President, Washington, D.C.
Lawrence G. Roberts, Advanced Research Projects Agency, Department of Defense, Washington, D.C.
Jerome H. Saltzer, Massachusetts Institute of Technology, Cambridge, Mass.
Jerome D. Moskowitz (ex officio), National Security Agency, Fort George G. Meade, Maryland
Willis H. Ware (ex officio), The Rand Corporation, Santa Monica, Calif.
Initially, the representative of the Directorate for Security Policy was
Lieutenant Commander Armen Chertavian (USN); and the representative to the
Policy Panel from the Central Intelligence Agency, was Mr. Fred Ohm.
The members of the Task Force participated as individuals knowledgeable of the technical, policy, and administrative issues involved. Thus, the views stated herein do not reflect the policy of the Federal Government, any of its agencies, or any university or industrial corporation.
Ultimately, a Report has to be written by one person. The original draft was written by Willis H. Ware using sources as noted below. It was then critiqued, modified, emended, and shaped by the members of the Steering Group and the Panels. A second complete draft was written by Thomas Chittenden, and the final version by Willis H. Ware.
Each Panel produced a series of papers which formed the basis for the recommendations on software, hardware, procedures, and policy. The Introduction and portions of Part A were initially authored by Wade B. Holland, utilizing material provided by Willis H. Ware and other sources. Section V of Part A, on System Characteristics, is largely from Willis H. Ware, incorporating material from a paper by the Technical Panel and some information from personal letters of Prof. E. L. Glaser.
Part B, the Policy Considerations and Recommendations, is substantially from the final paper produced by the Policy Panel. Many of the explanatory comments come from the original paper, although some were added in the final writing. The Technical Recommendations, Part C, mainly reflect the content of two papers produced by the Technical Panel, modified to a minor extent by information from personal letters of Prof. Glaser. Finally, Part D, on Management and Administrative Control, was written by Willis H. Ware, and utilizes ideas from "Security of Classified Information in the Defense Intelligence Agency's Analyst Support and Research System" (February 1969, C-3663/MS-5), and from "Security Procedures for the RYE System" (W. B. Ellis, December 1968).
The Appendix was first drafted by Arthur A. Bushkin and Willis H. Ware; it was subsequently extended and rewritten by Mr. Bushkin and Robert M. Balzer.
The final editing and details of format and style are due to Wade B. Holland.
The Report was printed and published by The Rand Corporation, under ARPA
sponsorship.
The success of a venture such as this depends upon the personal dedication and volunteer participation of the individuals involved. In addition to the listed members of the Steering Group and the Panels, it is also a pleasure to acknowledge the contributions of Dr. Robert M. Balzer and Mr. Wade B. Holland, The Rand Corporation, Santa Monica, California; Miss Hilda Faust, National Security Agency, Fort George G. Meade, Maryland; and Mr. Clark Weissman, System Development Corporation, Santa Monica, California. A special acknowledgment is due Thomas Chittenden, National Security Agency, Fort George G. Meade, Maryland, who rewrote the entire document to produce the all-important second draft.
The subject of security control in multi-access computer systems is of sufficiently wide interest that many members of the Steering Group and the Panels contacted a number of individuals, organizations, and agencies in the course of this effort. It would be impossible to mention every person with whom we have talked and who in some way has influenced our final recommendations. Among others, however, we interacted with Colonel Roy Morgan of the Defense Intelligence Agency representing the ANSR computing system, and Mr. George Hicken, National Security Agency, representing the RYE and COINS systems. The Steering Group and its Panels also acknowledge the contributions of the many individuals who read our draft material and supplied valuable comments and suggestions.
Willis H. Ware
January 1, 1970
With the advent of resource-sharing computer systems that distribute the capabilities and components of the machine configuration among several users or several tasks, a new dimension has been added to the problem of safeguarding computer-resident classified information. The basic problems associated with machine processing of classified information are not new. They have been encountered in the batch-processing mode of operation and, more recently, in the use of remote job-entry systems; the methods used to safeguard information in these systems have, for the most part, been extensions of the traditional manual means of handling classified documents.
The increasingly widespread use of resource-sharing systems has introduced new complexities to the problem. Moreover, the use of such systems has focused attention on the broader issue of using computers, regardless of the configuration, to store and process classified information.
Resource-sharing systems are those that distribute the resources of a computer system (e.g., memory space, arithmetic units, peripheral equipment, channels) among a number of simultaneous users. The term includes systems commonly called time-sharing, multiprogrammed, remote batch, on-line, multi-access, and, where two or more processors share all of the primary memory, multiprocessing. The principle distinction among the systems is whether a user must be present (at a terminal, for example) to interact with his job (time-sharing, on-line, multi-access), or whether the jobs execute autonomously (multiprogrammed, remote batch). Resource-sharing allows many people to use the same complex of computer equipment concurrently. The users are generally, although not necessarily, geographically separated from the central processing equipment and interact with the machine via remote terminals or consoles. Each user's program is executed in some order and for some period of time, not necessarily to completion. The central processing equipment devotes its resources to servicing users in turn, resuming with each where it left off in the previous processing cycle. Due to the speeds of modern computers, the individual user is rarely aware that he is receiving only a fraction of the system's attention or that his job is being fragmented into pieces for processing.
Multiprogramming is a technique by which resource-sharing is accomplished. Several jobs are simultaneously resident in the system, each being handled by the various system components so as to maximize efficient utilization of.the entire configuration. The operating system1 switches control from one job to another in such a way that advantage is taken of the machine's most powerful -- and most expensive -- resources. In practice, one of the basic features of multiprogramming is to prevent jobs demanding large amounts of time in input or output functions (I/O-bound jobs) from tying up the central processor; this is accomplished usually by allowing each job to execute until an input or output operation is required, at which point another job begins to execute concurrently with the I/O request. On the other hand, a time-sharing system regularly interrupts each job in turn, allowing each to execute for some interval of time determined by the computer system itself rather than by the structure of the job.
____________________
1 The system software, which schedules work through the computer system, assigns resources to each job, accounts for resources used, etc.
Systems incorporating capabilities of the types enumerated represent some of the latest advances in computer technology. Basically, they are intended to provide the most efficient utilization of expensive computing facilities for the widest range of users. A single system is able to handle several users or several sets of data simultaneously, contributing to more economical operation. In addition to the direct advantages of vastly improved resource utilization and greatly increased economy of operation, they can drastically reduce service turn-around time, enable users with little or no formal knowledge of programming to interact directly with the machine, and extend computing capabilities to many smaller installations that would be unable to support a dedicated machine.
This study, while receiving its impetus from the concern that has been generated by the increasing number of time-sharing systems, is addressed to all computer systems that may process classified material. Methods developed to insure the security of resource-sharing systems are applicable to other kinds of computing systems.
The wide use of computers in military and defense installations has long necessitated the application of'security rules and regulations. A basic principle underlying the security of computer systems has traditionally been that of' isolation-simply removing the entire system to a physical environment in which penetrability is acceptably minimized. The increasing use of systems in which some equipment components, such as user access terminals, are widely spread geographically has introduced new complexities and issues. These problems are not amenable to solution through the elementary safeguard of physical isolation.
In one sense, the expanded problems of security provoked by resource-sharing systems might be viewed as the price one pays for the advantages these systems have to offer. However, viewing the question from the aspect of such a simplistic tradeoff obscures more fundamental issues. First, the security problem is not unique to any one type of computer system or configuration; it applies across the spectrum of computational technology. While the present paper frames the discussions in terms of time-sharing or multiprogramming, we are really dealing not with system configurations, but with security; today's computational technology has served as catalyst for focusing attention on the problem of protecting classified information resident in computer systems.
Secondly, resource-sharing systems, where the problems of security are admittedly most acute at present, must be designed to protect each user from interference by another user or by the system itself, and must provide some sort of "privacy" protection to users who wish to preserve the integrity of their data and their programs. Thus, designers and manufacturers of resource-sharing systems are concerned with the fundamental problem of protecting information. In protecting classified information, there are differences of degree, and there are new surface problems, but the basic issues are generally equivalent. The solutions the manufacturer designs into the hardware and software must be augmented and refined to provide the additional level of protection demanded of machines functioning in a security environment.
The recommendations of the Defense Science Board's Task Force on Computer
Security represent a compilation of techniques and procedures which should
be considered both separately and in combination when designing or adopting
data processing systems to provide security or user privacy. The solutions
to specific problems are intended to be flexible and adaptive to the needs
of any installation, rather than being oriented to any one applications
environment. It is intended that the general guidelines in this Report be
of use to DOD components, other government installations, and contractors.
There are several ways in which a computer system can be physically and operationally organized to serve its users. The security controls will depend on the configuration and the sensitivity of data processed in the system. The following discussion presents two ways of' viewing the physical and operational configurations.
Equipment Arrangement and Disposition
The organization of the central processing facilities for batch or for
time-shared processing, and the arrangement of access capabilities for local
or for remote interaction are depicted in Fig. 1. Simple batch processing
is the historical and still prevalent mode of operation, wherein a number
of jobs or transactions are grouped and processed as a unit. The batches
are usually manually organized, and for the most part each individual job
is processed to completion in the order in which it was received by the machine.
An important characteristic of such single-queue, batched, run-to-completion
systems which do not have an integrated file management system for
non-demountable, on-line memory media is that the system need have no "management
awareness" from job to job. Sensitive materials can be erased or removed
from the computer quickly and relatively cheaply and mass memory media containing
sensitive information can be physically separated from the system and secured
for protection. This characteristic explains why solution to the problem
we are treating has not been as urgent in the past.
Figure 1
In multiprogramming, on the other hand, the jobs are organized and processed by the system according to algorithms designed to maximize the efficiency of' the total system in handling the complete set of' transactions. In local-access systems, all elements are physically located within the computer central facility; in remote-access systems, some units are geographically distant from the central processor and connected to it by communication lines.
User Capabilities
Another way of viewing the types of systems, shown in Fig. 2, is based on
the levels of computing capability available to the user.
Figure 2
File-query systems (Type I) enable the user to execute only limited application programs embedded in the system and not available to him for alteration or change. He selects for execution one or more available application programs. He may be able to couple several of these programs together for automatic execution in sequence and to insert parameters into the selected programs.
Interpretive systems (Type II) provide the user with a programming capability, but only in terms of input language symbols that result in direct execution within the computer of the operations they denote. Such symbols are not used to construct an internal machine language program that can subsequently be executed upon command from the user. Thus, the user cannot obtain control of the machine directly, because he is buffered from it by the interpretive software.
Compiler systems (Type III) provide the user with a programming capability, but only in terms of languages that execute through a compiler embedded in the system. The instructions to the compiler are translated by it into an assembly language or basic machine language program. Program execution is controlled by the user; however, he has available to him only the limited compiler language.
Full programming systems (Type IV) give the user extensive and unrestrained programming capability. Not only can he execute programs written in standard compiler languages, but he also can create new programming languages, write compilers for them, and embed them within the system. This gives the user intimate interaction with and control over the machine's complete resources -- excepting of course, any resources prohibited to him by information-protecting safeguards (e.g., memory protection, base register controls, and I/O hardware controls).
In principle, all combinations of equipment configurations (Fig. 1) and
operational capabilities (Fig. 2) can exist. In practice, not all the possible
combinations have been implemented, and not all the possibilities would provide
useful operational characteristics.
By their nature, computer systems bring together a series of vulnerabilities. There are human vulnerabilities throughout; individual acts can accidentally or deliberately jeopardize the system's information protection capabilities. Hardware vulnerabilities are shared among the computer, the communication facilities, and the remote units and consoles. There are software vulnerabilities at all levels of the machine operating system and supporting software; and there are vulnerabilities in the organization of the protection system (e.g., in access control, in user identification and authentication, etc.). How serious any one of these might be depends on the sensitivity (classification) of the information being handled, the class of users, the computational capabilities available to the user, the operating environment, the skill with which the system has been designed, and the capabilities of potential attackers of the system.
These points of vulnerability are applicable both in industrial environments handling proprietary information and in government installations processing classified data. This Report is concerned directly with only the latter; it is sufficient here to acknowledge that the entire range of issues considered also has a "civil" side to which this work is relevant.
Types of Vulnerabilities
The design of a secure system must provide protection against the various types of vulnerabilities. These fall into three major categories: accidental disclosures, deliberate penetrations, and physical attack.
Accidental Disclosure. A failure of components, equipment, software, or subsystems, resulting in an exposure of information or violation of any element of the system. Accidental disclosures are frequently the result of failures of hardware or software. Such failures can involve the coupling of information from one user (or computer program) with that of another user, the "clobbering" of information i.e., rendering files or programs unusable), the defeat or circumvention of security measures, or unintended change in security status of users, files, or terminals. Accidental disclosures may also occur by improper actions of machine operating or maintenance personnel without deliberate intent.
Deliberate Penetration. A deliberate and covert attempt to (1) obtain information contained in the system, (2) cause the system to operate to the advantage of the threatening party, or (3) manipulate the system so as to render it unreliable or unusable to the legitimate operator. Deliberate efforts to penetrate secure systems can either be active or passive. Passive methods include wire tapping and monitoring of electromagnetic emanations. Active infiltration is an attempt to enter the system so as to obtain data from the files or to interfere with data files or the system.1
____________________
1 The discussion of subversion is largely based on the article by H. E. Petersen and R. Turn, ''System Implications of Information Privacy," AFIPS Conference Proceedings, Vol. 30, Thompson Books, Washington, D.C., 1967, pp. 291-300.
Active Infiltration. One method of accomplishing active infiltration is for a legitimate user to penetrate portions of the system for which he has no authorization. The design problem is one of preventing access to files by someone who is aware of the access control mechanisms and who has the knowledge and desire to manipulate them to his own advantage. For example, if the access control codes are all four-digit numbers, a user can pick any four-digit number, and then, having gained access to some file, begin interacting with it in order to learn its contents.
Another class of active infiltration techniques involves the exploitation of trap-door2 entry points in the system that by-pass the control facilities and permit direct access to files. Trap-door entry points often are created deliberately during the design and development stage to simplify the insertion of authorized program changes by legitimate system programmers, with the intent of closing the trap-door prior to operational use. Unauthorized entry points can be created by a system programmer who wishes to provide a means for bypassing internal security controls and thus subverting the system. There is also the risk of implicit trap-doors that may exist because of incomplete system design-i.e., loopholes in the protection mechanisms. For example, it might be possible to find an unusual combination of system control variables that will create an entry path around some or all of the safeguards.
____________________
2 Any opportunity to penetrate, subvert, mislead, or by-pass security controls through an idiosyncrasy of the software, software-hardware, hardware, procedural controls, etc.
Another potential mode of active infiltration is the use of a special terminal illegally tied into the communication system. Such a terminal can be used to intercept information flowing between a legitimate terminal and the central processor, or to manipulate the system. For example, a legitimate user's sign-off signal can be intercepted and cancelled; then, the illegal terminal can take over interaction with the processor. Or, an illegal terminal can maintain activity during periods when the legitimate user is inactive but still maintaining an open line. Finally, the illegal terminal might drain off output directed to a legitimate terminal and pass on an error message in its place so as to delay detection.
Active infiltration also can be by an agent operating within the secure organization. This technique may be restricted to taking advantage of system protection inadequacies in order to commit acts that appear accidental but which are disruptive to the system or to its users, or which could result in acquisition of classified information. At the other extreme, the agent may actively seek to obtain removable files or to create trap doors that can be exploited at a later date Finally, an agent might be placed in the organization simply to learn about the system and the operation of the installation, and to obtain what pieces of information come his way without any particularly covert attempts on his part at subversion.
Passive Subversion. In passive subversion, means are applied to monitor information resident within the system or being transmitted through the communication lines without any corollary attempt to interfere with or manipulate the system. The most obvious method of passive infiltration is the wire tap. If communications between remote terminals and the central processor are over unprotected circuits, the problem of applying a wire tap to the computer line is similar to that of bugging a telephone call. It is also possible to monitor the electromagnetic emanations that are radiated by the high-speed electronic circuits that characterize so much of the equipment used in computational systems. Energy given off in this form can be remotely recorded without having to gain physical access to the system or to any of its components or communication lines. The possibility of successful exploitation of this technique must always be considered.
Physical Attack. Overt assault against or attack upon the physical
environment (e.g., mob action) is a type of vulnerability outside the scope
of this Report.
The system designer must be aware of the points of vulnerability, which may
be thought of as leakage points, and he must provide adequate mechanisms
to counteract both accidental and deliberate events. The specific leakage
points touched upon in the foregoing discussion can be classified in five
groups: physical surroundings, hardware, software, communication links, and
organizational (personnel and procedures). The overall safeguarding of
information in a computer system, regardless of configuration, is achieved
by a combination of protection features aimed at the different areas of leakage
points. Procedures, regulations, and doctrine for some of these areas are
already established within DOD, and are not therefore within the purview
of the Task Force. However, there is some overlap between the various areas,
and when the application of security controls to computer systems raises
a new aspect of an old problem, the issue is discussed. An overview of the
threat points is depicted in Fig. 3.
Figure 3
Physical Protection
Security controls applied to safeguard the physical equipment apply not only to the computer equipment itself and to its terminals, but also to such removable items as printouts, magnetic tapes, magnetic disc packs, punchcards, etc. Adequate DOD regulations exist for dissemination, control, storage, and accountability of classified removable items. Therefore, security measures for these elements of the system are not examined in this Report unless there are some unique considerations. The following general guidelines apply to physical protection.
(a) The area containing the central computing complex and associated equipment (the machine room or operational area) must be secured to the level commensurate with the most highly classified and sensitive material handled by the system.(b) Physical protection must be continuous in time, because of the threat posed by the possibility of physical tampering with equipment and because of the likelihood that classified information will be stored within the computer system even when it is not operating.
(c) Remote terminal devices must be afforded physical protection commensurate with the classification and sensitivity of information that can be handled through them. While responsibility for instituting and maintaining physical protection measures is normally assigned to the organization that controls the terminal, it is advisable for a central authority to establish uniform physical security standards (specific protection measures and regulations) for all terminals in a given system to insure that a specified security level can be achieved for an entire system. Terminal protection is important in order to:
- Prevent tampering with a terminal (in stalling intelligence sensors);
- Prevent visual inspection of classified work in progress;
- Prevent unauthorized persons from trying to call and execute classified programs or obtain classified data.
If parts of the computer system (e.g., magnetic disc files, copies of printouts) contain unusually sensitive data. or must be physically isolated during maintenance procedures, it may be necessary to physically separate them and independently control access to them. In such cases, it may be practical to provide direct or remote visual surveillance of the ultra-sensitive areas. If visual surveillance is used, it must be designed and installed in such a manner that it cannot be used as a trap-door to the highly sensitive material it is intended to protect.
Hardware Leakage Points
Hardware portions of the system are subject to malfunctions that can result directly in a leak or cause a failure of security protection mechanisms elsewhere in the system, including inducing a software malfunction. In addition, properly operating equipment is susceptible to being tapped or otherwise exploited. The types of failures that most directly affect security include malfunctioning of the circuits for such protections as bounds registers, memory read-write protect, privileged mode operation, or priority interrupt. Any hardware failure potentially can affect security controls; e.g., a single-bit error in memory.
Both active and passive penetration techniques can be used against hardware leakage points. In the passive mode, the intervener may attempt to monitor the system by tapping into communication lines, or by monitoring compromising emanations. Wholly isolated systems can be physically shielded to eliminate emanations beyond the limits of the secure installation, but with geographically dispersed systems comprehensive shielding is more difficult and expensive. Currently, the only practical solutions are those used to protect communications systems.
The problem of emanation security is covered by existing regulations; there are no new aspects to this problem raised by modern computing systems. It should be emphasized, however, that control of spurious emanations must be applied not only to the main computing center, but to the remote equipment as well.
Although difficult to accomplish, the possibility exists that covert monitoring devices can be installed within the central processor. The problem is that the computer hardware involved is of such complexity that it is easy for a knowledgeable person to incorporate the necessary equipment in such a way as to make detection very difficult. His capability to do so assumes access to the equipment during manufacture or major maintenance. Equipment is also vulnerable to deliberate or accidental rewiring by maintenance personnel so that installed hardware appears to function normally, but in fact by-passes or changes the protection mechanisms.
Remote consoles also present potential radiation vulnerabilities. Moreover, there is a possibility that recording devices might be attached to a console to pirate information. Other remote or peripheral equipment can present dangers. Printer ribbons or platens may bear impressions that can be analyzed; removable storage media (magnetic tapes, disc packs, even punchcards) can be stolen, or at least removed long enough to be copied.
Erasure standards for magnetic media are not within the scope of this Task Force to review or establish. However, system designers should be aware that the phenomena of retentivity in magnetic materials is inadequately understood, and is a threat to system security.
Software Leakage Points
Software leakage points include all vulnerabilities directly related to the software in the computer system. Of special concern is the operating system and the supplementary programs that support the operating system because they contain the software safeguards. Weaknesses can result from improper design or from failure to check adequately for combinations of circumstances that can lead to unpredictable consequences. More serious, however, is the fact that operating systems are very large, complex structures, and thus it is impossible to exhaustively test for every conceivable set of conditions that might arise. Unanticipated behavior can be triggered by a particular user program or by a rare combination of user actions. Malfunctions might only disrupt a particular user's files or programs; as such, there might be no risk to security, but there is a serious implication for system reliability and utility. On the other hand, operating system malfunctions might couple information from one program (or user) to another; clobber information in the system (including information within the operating system software itself); or change classification of users, files, or programs. Thus, malfunctions in the system software represent potentially serious security risks. Conceivably, a clever attacker might establish a capability to induce software malfunctions deliberately; hiding beneath the apparently genuine trouble, an on-site agent may be able to tap files or to interfere with system operation over long periods without detection.
The security safeguards provided by the operating system software include access controls, user identification, memory bounds control, etc. As a result of a hardware malfunction, especially a transient one, such controls can become inoperative. Thus, internal checks are necessary to insure that the protection is operative. Even when this is done, the simultaneous failure of both the protection feature and its check mechanism must always be regarded as a possibility. With proper design and awareness of the risk, it appears possible to reduce the probability of undetected failure of software safeguards to an acceptable level.
Probably the most serious risk in system software is incomplete design, in the sense that inadvertent loopholes exist in the protective barriers and have not been foreseen by the designers. Thus, unusual actions on the part of users, or unusual ways in which their programs behave, can induce a loophole. There may result a security breach, a suspension or modification of software safeguards (perhaps undetected), or wholesale clobbering of internal programs, data, and files. It is conceivable that an attacker could mount a deliberate search for such loopholes with the expectation of exploiting them to acquire information either from the system or about the system e.g., the details of its information safe guards.
Communication Leakage Points
The communications linking the central processor, the switching center and the remote terminals present a potential vulnerability. Wiretapping may be employed to steal information from land lines and radio intercept equipment can do the same to microwave links. Techniques for intercepting compromising emanations may be employed against the communications equipment even more readily than against the central processor or terminal equipment. For example, crosstalk between communications lines or within the switching central itself can present a vulnerability. Lastly, the switch gear itself is subject to error and can link the central processor to the wrong user terminal.
Organizational Leakage Points
There are two prime organizational leakage points, personnel security clearances and institutional operating procedures. The first concerns the structure, administration, and mechanism of the national apparatus for granting personnel security clearances. It is accepted that adequate standards and techniques exist and are used by the cognizant authority to insure the reliability of those cleared. This does not, however, relieve the system designer of a severe obligation to incorporate techniques that minimize the damage that can be done by a subversive individual working from within the secure organization. A secure system must be based on the concept of isolating any given individual from all elements of the system to which he has no need for access. In the past, this was accomplished by denying physical access to anyone without a security clearance of the appropriate level. In resource-sharing systems of the future, a population of users ranging from uncleared to those with the highest clearance levels will interact with the system simultaneously. This places a heavy burden on the overall security control apparatus to insure that the control mechanisms incorporated into the computer system are properly informed of the clearances and restrictions applicable to each user. The machine system must be designed to apply these user access restrictions reliably.
In some installations, it may be feasible to reserve certain terminals for highly classified or highly sensitive or restricted work, while other terminals are used exclusively for less sensitive operation. Conversely, in some installations any terminal can be used to any degree of classification or sensitivity, depending on the clearance and needs of the user at the given moment. In either of these cases, the authentication and verification mechanisms built into the machine system can be relied upon only to the degree that the data on personnel and on operational characteristics provided it by the security apparatus are accurate.
The second element of organizational leakage points concerns institutional operating procedures. The consequences of inadequate organizational procedures, or of their haphazard application and unsupervised use, can be just as severe as any other malfunction. Procedures include the insertion of clearance and status information into the security checking mechanisms of the machine system, the methods of authenticating users and of receipting for classified information, the scheduling of computing operations and maintenance periods, the provisions for storing and keeping track of removable storage media, the handling of printed machine output and reports, the monitoring and control of machine-generated records for the security apparatus, and all other functions whose purpose is to insure reliable but unobtrusive operation from a security control viewpoint. Procedural shortcomings represent an area of potential weakness that can be exploited or manipulated, and which can provide an agent with innumerable opportunities for system subversion. Thus, the installation operating procedures have the dual function of providing overall management efficiency and of providing the administrative bridge between the security control apparatus and the computing system and its users.
The Task Force has no specific comments to make with respect to personnel security issues, other than to note that control of the movement of people must include control over access to remote terminals that handle classified information, even if only intermittently. The machine room staff must have the capability and responsibility to control the movement of personnel into and within the central computing area in order to insure that only authorized individuals operate equipment located there, have access to removable storage media, and have access to any machine parts not ordinarily open to casual inspection.
Leakage Point Ecology
In dealing with threats to system security, the various leakage points cannot be considered only individually. Almost any imaginable deliberate attempt to exploit weaknesses will necessarily involve a combination of factors. Deliberate acts mounted against the system to take advantage of or to create leakage points would usually require both a system design shortcoming, either unforeseen or undetected, and the placement of someone in a position to initiate action. Thus, espionage activity is based on exploiting a combination of deficiencies and circumstances. A software leak may be caused by a hardware malfunction. The capability to tap or tamper with hardware may be enhanced because of deficiencies in software checking routines. A minor, ostensibly acceptable, weakness in one area, in combination with similar shortcomings in seemingly unrelated activities, may add up to a serious potential for system subversion. The system designer must be aware of the totality of potential leakage points in any system in order to create or prescribe techniques and procedures to block entry and exploitation.
The security problem of specific computer systems must be solved on a case-by-case basis employing the best judgment of a team consisting of system programmers, technical, hardware, and communications specialists, and security experts. This Report cannot address the multitude of details that will arise in the operation of a particular resource-shared computer system in an individual installation. Instead, it is intended that the Report provide guidelines to those responsible for designing and certifying that a given system has satisfactory security controls and procedures. On the other hand, the security controls described in Parts B through D can markedly reduce the probability that an undetected attempt to penetrate a resource-sharing computer system will succeed.
This Report addresses the most difficult security control situation, a
time-sharing system serving geographically distributed users. Where circumstances
warrant, a lesser set of controls may be satisfactory, and it is not intended
that in such cases there be prohibitions on implementing a system with a
lesser set of safeguards. The recommendations have been framed to provide
maximum latitude and freedom of action in adapting the ideas to specific
installations.
Constraints
The U.S. Government classifies defense information within a well defined and long established structure. Although it might be desirable from the computer point of view to modify these rules, to do so would be equivalent to tailoring the structure to fit the computer operation and would constitute an inappropriate recommendation. Obviously then, a constraint is that a secure computer system must be consonant with the existing security classification structure.
A second constraint, at least initially, is the assumption that the general tenets of the existing, familiar, manual security control procedures will prevail. For example, the Task Force recommendations require not only that a secure computer system identify a user, but also that the user establish (prove) his authenticity; furthermore, he will be asked to receipt by a simple response for any and all classified information that is made available to him through any type of terminal. This is a desirable feature, not only from a consideration of system accountability, but also from the point of view of protection for the user. It is conceivable that an error by the computer system might result in an allegation that it had given a user certain information, when, in fact, it had not.
General Characteristics
In formulating its recommendations, the Task Force recognized the following general characteristics as desirable in a secure system.
The system should be flexible; that is, there should be convenient mechanisms and procedures for maintaining it under conditions of shifting job assignments, issuance and withdrawal of clearances, changes in need-to-know parameters, transfer of personnel from one duty assignment to another, etc.
The system should be responsive to changing operational conditions, particularly in time of emergency. While not an aspect of security control per se, it is important that the system be responsive in that it does not deny service completely to any class of users as the total system load increases. It may prove desirable to design special emergency features into the system that can suspend or modify security controls, impose special restrictions, grant broad access privileges to designated individuals, and facilitate rapid change of security parameters.3
____________________
3 See the definition of Security Parameters. p. 13.
The system should be auditable. It must provide records to the security control supervisor, so that system performance, security safeguards, and user activities can be monitored. This implies that both manual and automatic monitoring facilities are desirable.
The system should be reliable from a security point of view. It ought to be fail-safe in the sense that if the system cannot fulfill its security controls, cannot make the proper decisions to grant access, or cannot pass its internal self-checks, it will withhold information from those users about which it is uncertain, but ideally will continue to provide service to verified users. A fallback and independent set of security safeguards must be available to function and to provide the best level of security possible under the degraded conditions if the system is to continue operation.
The system should be manageable from the point of view of security control. The records, audit controls, visual displays, manual inputs, etc., used to monitor the system should be supplemented by the capability to make appropriate modifications in the operational status of the system in the event of catastrophic system failure, degradation of performance, change in workload, or conditions of crisis, etc.
The system should be adaptable so that security controls can be adjusted to reflect changes in the classification and sensitivity of the files, operations, and the needs of the local installation. There should be a convenient mechanism whereby special security controls needed by a particular user can be embedded easily in its system. Thus, the security control problem ideally must be solved with generality and economy. It would be too costly to treat each installation as an individual instance and to conceive an appropriate set of' unique safeguards.
The system must be dependable; it must not deny service to users. In times of crisis or urgent need, the system must be self:protecting in that it rejects efforts to capture it and thus make it unavailable to legitimate users. This point bears on the number and kinds of' internal records that the system must keep, and implies that some form of rationing algorithm must be incorporated so that a penetration would capture no more than a specified share of system capability.
'I'he system must automatically assure configuration integrity. It must self-test, violate its own safeguards deliberately, attempt illegal operations, monitor communication continuity, monitor user action, etc., on a short time basis.
Uncertainties
The Task Force has identified several aspects of secure computer systems which are currently impractical or impossible to assess.
Failure Prediction. In the present state of computer technology, it is impossible to completely anticipate, much less specify, all hardware failure modes, all software design errors or omissions, and, most seriously, all failure modes in which hardware malfunctions lead to software malfunctions Existing commercial machines have only a minimum of redundancy and error-checking circuits, and thus for most military applications there may be unsatisfactory hardware facilities to assist in the control of hardware/software malfunctions. Furthermore, in the present state of knowledge, it is very difficult to predict the probability of failure of complex hardware and software configurations; thus, redundancy an important design concept.
Risk Level. Because failure modes and their probability of occurrence cannot be completely cataloged or stated, it is very difficult to arrive at an overall probability of accidental divulgence of classified information in a security-controlling system. Therefore, it is difficult to make a quantitative measurement of' the security risk-level of such a system, and it is also difficult to design to some a priori absolute and demonstrable security risk-level. Since the security risk probabilities of' present manual systems are not well known, it is difficult to determine whether a given design for a secure computer system will do as well as or better than a corresponding manual arrangement. This issue is likely to raise considerable discussion at such time as official policy decisions about security control in computer systems must be made.
As described above, computer systems differ widely in the capabilities they make available to the user. In the most sophisticated (and highest security risk) case, a user can construct both new programs and new programming languages from his console. and embed such new languages into the computer system for use. In such a computer system. offering the broadest capability to the user. the security problems and risks are considerably greater when users from the following two classes must be served simultaneously:
It is the opinion of the Task Force that it is unwise at the present time to attempt to accommodate both classes of users simultaneously. However, it is recognized that many installations have an operational need to serve both uncleared and cleared users, and recommendations addressed to this point are presented in Parts B through D.
Cost. Unfortunately, it is not easy at this time to estimate the cost of security controls in a computer system. Only a few computer systems are currently in operation that attempt to provide service to a broad base of users working with classified information. While such systems are serving the practical needs of their users, they are the products of research efforts, and good data reflecting the incremental cost of adding security controls to the system and operating with them are not yet available.
In computer systems designed for time-sharing applications, some of the capabilities that are present in order to make a time-sharing system work at all are also applicable to the provision of security controls. In other computing systems, any facilities for security control would have to be specially installed. Thus, the Task Force cannot give an accurate estimate of the cost of security. It will depend on the age of the software and hardware, but certainly security control will be cheapest if it is considered in the system architecture prior to hardware and software design. In the opinion of some, the investment in the security controls will give a good return in tighter and more accurate accountability and dissemination of classified information, and in improved system reliability.
The cost of'security may depend on the workload of' the installation. If
all classified operations can be accommodated on a single computer, and all
unclassified operations on a second computer, the least expensive way to
maintain the integrity of the classified information may be to retain both
machines. Such a configuration will present operational inefficiency for
those users who need to work with both classified and unclassified data bases,
but the concept of a dual installation -- with one machine working in the
clear and a second machine fully protected -- cannot be summarily rejected.
There are many terms commonly used in connection with security control for which usage is not completely standardized. Terms used throughout this Report are defined below as a group; certain other terms (especially computer-related ones) are defined at appropriate places in the text.
Clearance. The privilege granted to an individual on the basis of prescribed investigative procedures to have formal access to classified information when such access is necessary to his work. The three formal national clearances are Top Secret, Secret, and Confidential. However, it is also expedient from the computer point of view to recognize Uncleared as a fourth level of clearance. A clearance is a necessary but not sufficient condition to have access to classified information. By extension, the concept of clearance can be applied also to equipment. For example, when a computer terminal is spoken of as having a given level of clearance, it is implied that certain investigative procedures and tests have established that the corresponding level of classified information can be safely transmitted through that terminal. When referring to an aggregation of equipment, together with its management controls and procedures, facility clearance is some- times used.
Need-to-know. An administrative action certifying that a given individual requires access to specified classified information in order to perform his assigned duties. The combination of a clearance and a need-to-know constitutes the necessary and sufficient conditions for granting access to classified information.
Classification. The act of identifying the sensitivity of' defense information by ascertaining the potential level of damage to the interests of the United States were the information to be divulged to an unfriendly foreign agent. The classification of in formation is formally defined in Executive Order 10501. There are only three formal levels of national classification: Top Secret, Secret, and Confidential, but it is expedient from the computer point of view also to consider Unclassified as a fourth level of classification. The identifiers associated with an item of classified information, indicating the level of classification or any special status, are generically called labels.
Special Category (or: Special-Access Category or Compartment). Classified defense information that is segregated and entrusted to a particular agency or organizational group for safeguarding. For example, that portion of defense classified information that concerns nuclear matters is entrusted to the Atomic Energy Commission, which is responsible for establishing and promulgating rules and regulations for safeguarding it and for controlling its dissemination. Classified information in a special category is normally identified by some special marking, label, or letter; e.g., AEC information, whether classified Confidential, Secret, or Top Secret, is collectively identified as Q-information. It is often called Q-classified, but note that this use of classification is an extended sense of the formal usage of the word.
Sometimes, special investigative procedures are stipulated for granting access to information in special categories. Thus, while formally there are only three broadly defined national clearance levels, in practice there is a further structure within each level. In part, this reflects the separation of information into special categories, and, in part, the fact that many different agencies are authorized to grant clearances. For example, an individual functioning within the AEC domain and cleared to Top Secret will of'ten be said to have a Q-clearance because he is authorized access to Top Secret information entrusted to the AEC for safeguarding and identified by the special category Q. These special types of clearances at given levels are not always specifically identified with a unique additional marking or label.
Caveat. A special letter, word, phrase, sentence, marking, or combination thereof, which labels classified material as being in a special category and hence subject to additional access controls. Thus, a caveat is an indicator of a special subset of information within one or more levels of classification. The caveat may be juxtaposed with the classification label may appear by itself; or sometimes does not appear explicitly but is only inferred. Particular kinds of caveats are:
Codewords. An individual word or a group of words labelling a particular collection of classified information.Dissemination Labels (Access Control Labels). A group of words that imposes an additional restriction on how classified information can be used, disseminated, or divulged; such labels are an additional means for controlling access. Examples: "No Foreign Dissemination," "U.S. Eyes Only," "Not Releasable Outside the Department of Defense."
Information Labels. A group of words that conveys to the recipient of information some additional guidance as to how the information may be further disseminated, controlled, transmitted, protected, or utilized. Examples: "Limited Distribution," "Special Handling Required," "Group 1 -- Excluded from Automatic Downgrading and Declassification."
Fully Cleared. An individual who has the clearance and all need-to-know authorizations granting him access to all classified information contained in a computer system. By extension, the term can be applied to equipment, in which case it implies that all necessary safeguards are present to enable the equipment to store and process information with many levels of' classification and caveated in many different ways.
Security Flag. For the purposes of this Report. it is convenient to introduce this new term. It is a composite term, reflecting the level of classification. all caveats (including codewords and labels), and need-to-know requirements, which together are the indicators establishing the access restrictions on information or the access privileges of an individual. By extension, the concept can be applied to equipment. and indicates the class of information that can be stored and processed.
Thus, the security flag contains all the information necessary to control access. One security flag is considered to be equal to or higher than a second if a requestor with the first flag is authorized access to information which has the second flag.
Security Parameters. The totality of information about users, files, terminals, communications, etc., which a computer system requires in order to exercise security control over the information that it contains. Included are such things as user names, clearances, need-to-know authorizations, physical location; terminal locations and clearances; file classifications and dissemination restrictions. Thus, a set of security parameters particularizes a generalized security control system to the specific equipment configuration, class of information, class of users, etc., in a given installation.
The policy recommendations that follow are intended to provide a security
skeleton around which a specific secure computer system may be built.
Additionally, these recommendations set forth the responsibilities and functions
of the personnel needed to evaluate, supervise, and operate a secure system.
This is a new field, and this Report represents the first major attempt to
codify its principles. In some cases, the rationale behind a specific
recommendation and appropriate examples are presented in a Comment.
Automatic data processing systems shall accommodate, without exception, the responsibilities of individuals to ensure that certain official information affecting national defense is protected against unauthorized disclosure, pursuant to Executive Order 10501 (Amended), "Safeguarding Official Information in the Interests of the Defense of the United States."
A computer system shall grant access to classified information only to persons for whom it can determine that their official duties require such access, and that they have received the proper security clearances and need-to-know authorizations.
The means employed to achieve system security objectives shall be based on any combination of software, hardware, and procedural measures sufficient to assure suitable protection for all classification categories resident in the system.
To the maximum extent possible, the policies and procedures incorporated to achieve system security shall be unclassified. However, specific keys, passwords, authentication words, and specifically designated sensitive procedures shall require classification.
Comment: These principles reflect the constraint that the recommendations
of the Task Force be consistent with generally accepted, existing security
doctrine. The last item is considered relevant in order to permit maximum
operational convenience.
Depending upon the nature of the individual computing installation, some or all of the following categories of personnel will be associated with it. It is recognized that a given individual may have more than one responsibility, and either simultaneously or at different times perform more than one function. It is also recognized that the scope of responsibility may imply a substantial organizational group for each function.
Responsible Authority. The head of the department or agency responsible for the proper operation of the secured computer system.
User. Any individual who interacts directly with the computer system by virtue of inserting information into the system or accepting information from it. "Information" is considered to include both computer programs and data.
Comment: A user is thus defined whether he interacts with the system from a remote terminal or submits work directly to the computing central through a batch-process mode.
System Administrator. An individual designated as responsible for the overall management of all system resources, both the physical resources of the system and the personnel attached to it.
Comment: The users are generally excluded from the System Administrator's management purvieu, although personnel under his control may also be users at times.
System Certifier. An individual designated by an appropriate authority to verify and certify that the security measures of a given computer system and of its operation meet all applicable, current criteria for handling classified information; and to establish the maximum security level at which a system (and each of its parts) can operate.
System Security Officer. An individual designated by a Responsible Authority as specifically responsible for (1) proper verification of personnel clearances and information-access authorizations; (2) determination of operational system security status (including terminals); (3) surveillance and maintenance of system security; (4) insertion of security parameters into the computing system, as well as general security-related system matters; (5) security assurance.
Comment: The System Certifier will establish the maximum security level at which the system (and each part of it) can operate; the System Security Officer will determine on an operational basis the level at which it does operate. He will normally verify personnel clearances with the overall security officials of the organization, and need-to-know authorizations with the organizational element that has cognizance over the information in question (e.g, an Officer of Primary Interest).
Security assurance implies an independent group that continuously monitors security provisions in the computer system. It includes such functions as continuously probing the system to ascertain its weaknesses and vulnerabilities, recommending additional safeguards as need is determined, and validating the security provisions in a system. Because of the technical expertise implied by security assurance, it is probable that this responsibility will be shared by the System Certifier.
System Maintenance Personnel. The individuals designated as responsible for the technical maintenance of those hardware and software system features that (1) must operate with very high reliability in order to maintain system integrity with respect to security matters, and (2) maintain the basic functioning of the system.
Comment: The hardware and software maintenance personnel are permitted to service not only the normal, basic features of the computing system, but also the security control features. However, there need be no prohibition on the assignment of these two classes of maintenance requirements to separate individuals or groups of individuals.
System Operators. Those personnel responsible for performing the manual procedures necessary to provide and maintain on-going service operations of the system.
Personnel Designations and Responsibilities
System Administrators, System Security Officers, and System Maintenance and Operations Personnel shall be formally designated by the Responsible Authority. The total number of such personnel should be kept to a minimum. Where necessary to meet special operational needs of a particular installation, special restrictions affecting personnel may be incorporated into the individual agency's procedures, formulated under the cognizance of the Responsible Authority.
Comment: This recommendation is intended to permit installations that have special operational needs, either because of mission or sensitivity of information, to impose additional constraints on system personnel or on their responsibilities.
As a general approach, it is desirable that persons designated as System Personnel have sufficient clearance and need-to-know authorization for all information resident in the computer system. However, it is conceivable that even for System Personnel, access could be segmented so that such clearance would not be absolutely necessary. For example, Operators and Administrators may not have access to the keys or mechanism that allow access to the interior of the hardware. This policy will accommodate either approach as found to be necessary by the exact nature of the computer system involved and the information to be protected. A typical user-agency decision might be to limit System Personnel to U.S. Government personnel, or to special two-man teams, each of which may be limited to partial access. Another user-agency decision might be to require some degree of sanitization preliminary to the performance of certain types of system maintenance, especially if the person capable of' performing such maintenance is not or cannot be cleared adequately. Sanitization refers to the protection of classified information resident in computer files either by deliberate erasure or by physically removing and/or protecting the storage medium or device.
Although it is recognized that System Personnel may fulfill more than one responsibility, this option may not be exploitable in practice because of the significantly different skills required. For example, skilled and experienced system programmers will be required to maintain the software, whereas computer engineers will be required for the hardware, and communications engineers for the communications.
User Designation
Each user (or specific group of users) shall be administratively designated (identified) to the computer system by the System Administrator, with the concurrence of the System Security Officer. The designation shall include indicators of the user's status in sufficient detail to enable the system to provide him with all material to which he is authorized access, but no more.
Comment: As will be seen in the Appendix, which defines a language and schema for identifying both a security structure and security parameters to a computing system, the number of parameters that must be kept within the system for each user will reflect the kind of classified information with which the system deals. In some instances, it will be necessary to verify more than a user's clearance and need-to-know status before access to classified information can be granted; e.g., it may be necessary to verify his agency of employment. It may also be desirable to keep within the computing system extensive information on each user, not for routine verification of his access privileges, but for the convenience of the System Security Officer when he finds it necessary to intervene in the system's operation.
User Authentication
Each user shall be required both to identify himself and to authenticate his identity to the system at any time requested by it, using authentication techniques or devices assigned by the System Security Officer. Such techniques or devices shall be sufficient to reduce the risk of unauthorized divulgence, compromise, or sabotage below that required by the sensitivity of the data resident in the system.
Comment: Identification is for the purposes of system accounting and billing, whereas authentication is the verification procedure necessary before the system can grant access to classified information. The choice of technique or device obviously will depend on the sensitivity of the data resident within the computing system, the physical location of'the user terminal, the security level to which it and its communication links are protected, the set of users that have access to it at any time, etc.
User Responsibility
A properly authenticated user is responsible for all action at a given terminal between the time that his identity has been established and verified, and his interaction with the system is terminated and acknowledged. Termination can occur because he notifies the system of his departure, or because the system suspends further operation with him. The user is responsible for observing all designated procedures and for insuring against observation of classified material by persons not cleared for access to it; this includes proper protection of classified hard copy. Furthermore, he is responsible for reporting system anomalies or malfunctions that appear to be related to system security controls to the System Security Officer, especially when such occurrences suggest that system security control measures may be degraded, or that a deliberate attempt to tamper with or penetrate the system is occurring. Other system anomalies should be reported to System Maintenance Personnel, who, in turn, must report to the System Security Officer those hardware or software malfunctions that investigation shows have affected security controls.
Access
Access to classified information stored within the computer system shall be on the basis of specific authorization from the System Security Officer to receive such information, or by automatic processes operating under his control and authority. The authority of the System Security Officer to authorize system users to have access to classified information stored in the system does not implicitly apply to the System Security Officer himself. Separate and specific restraints over his access to classified information shall be established by the System Administrator. A specific algorithm (or combination of algorithms) for controlling access to all classified information shall be specified and embedded in the system. Moreover, a specific protocol and mechanism shall be specified for inserting into the computer system those security parameters that grant and rescind access privileges. For both purposes, hardware, software, and procedural mechanisms shall be implemented that insure that neither the access control algorithm nor the security-parameter insertion mechanism is circumvented, either accidentally (through component failure) or intentionally.
Comment: This recommendation establishes the general principle on which
user access to classified information within the system is granted. The details
of the algorithm that permits access to classified information obviously
will depend on that part of the total security structure with which the computer
system is concerned, and also on the status information kept within the system
for each user. The Appendix illustrates a particular algorithm that appears
to be sufficiently comprehensive to cover all requirements known to the Task
Force. It should be noted that this recommendation attempts to incorporate
redundancy into the access control mechanism, and also into the parameter
insertion mechanisms, by requiring a combination of hardware, software, and
procedural mechanisms.
Data storage shall be organized and controlled at the level of the basic computer system in terms of information units, each of which has a classification descriptor plus applicable special-access categories (as required by the presence of caveats) and other labels that apply to the information unit as a whole. It is the explicit responsibility of the individual directing a computational process to declare and verify the classification and any applicable caveats and other labels for an information unit produced as a result of some computer process (e.g., calculations of bomber ranges or weapon effectiveness), or as a result of a transformation of some previously existing unit (e.g., merging or sorting of files).1 This responsibility extends to security control and management of information sub-units. Procedures analogous to those in force for controlling introduction of information from or release of information to entities outside the system must be observed, and are described in Sec. VI below, "Information Security Labels." Since a hierarchical structure of information classification will usually exist, a composite unit must be at least at the highest level of classification of the units contained in the composite, but, in fact, may be higher. Automatic algorithms may be used to aid the user in the execution of these responsibilities.
____________________
This statement is not adequate for nongovernmental organizations, nor in some government situations. For example, an employee of an industrial contractor can only suggest the classification of information which he creates; the formal declaration of classification is made by a designated, appropriate authority, sometimes external to the contractor company. Some secure computer systems will require a supplementary procedure to validate classifications suggested by users.
Comment: The intent of this recommendation is to provide procedures analogous to those for handling documents, as specified in Section 3 of Executive Order 10501 (Amended) The recommendation on information structure and transforms leaves unspecified whether a computer-based file is classified as an entity, or whether the individual entries or elements of the file are separately classified. The design of the file structure and the details of how it shall be classified are operational matters, not a problem of providing security control mechanisms. However, where the security structure of the file is established, the procedures outlined in this recommendation will apply.
This recommendation also permits the use of computer algorithms to assist
in classifying new information. In the Appendix, examples are given which
suggest how such algorithms may be applied, but the computer system may not
be able to establish classification level or applicable special caveats and
labels in every circumstance. At most, the system can tell a user that he
has had access to classified information with given caveats and labels; it
will be his responsibility to confirm to the computer system the classification,
special caveats, and labels that should apply. If the sensitivity of the
information warrants, audit information should be made available to the System
Security Officer, informing him that a user has taken some specified action
in establishing or modifying a clearance level, applicable caveats, or
labels.
Logging of Transactions
All relevant transactions between users and the computer system shall be automatically logged (including date and time) by the computer system so that an audit of transactions involving access to and generation, classification, reclassification, and destruction of files is possible. The provisions of this paragraph also apply to unclassified information that resides in a system containing, or cleared to contain, classified information. Supplementary manual logs (including date and time) must record all significant events that cannot be automatically logged.
Comment: Transaction as used here includes such things as a user logging onto or off the system; the system granting a user access to a specified file; the merging of files by a user; the generation of new information to which a user assigns classification; changes made in a classified file by a user; and exchanges of information with another computer. The inclusion of unclassified information is intended to provide f'or the case where "unclassified " information becomes upgraded, and to protect against unobserved activity in the manipulation of the system by users. The audit-trail data should be made available to the System Security Officer to aid him in the continuous monitoring of the security of the system.
It may prove operationally desirable to aggregate information of this type and present it in various periodic reports. Thus, for example, the System Security Officer could be informed at the end of each shift as to which files have been addressed by or released to each user, or which files have been updated or had their classification changed. The control of security 18 overlaps somewhat the control of file integrity and it may prove desirable for some of the audit information to be made available to the System Administrator.
The number and kinds of audits and the periodicity with which they are made will depend on such factors as sensitivity of the information contained in the computer system, the class of users it services and their clearance status, the operational requirements of the system, etc. Some portions of the status log will be only historical, others will be used operationally. It is conceivable that in some installations it will prove desirable to provide the System Security Officer with a visual display of the system transaction log.
It should be noted that when the System Security Officer is interacting with the system (e.g., inserting new security parameters), he is considered by the system to be a user. Thus, even though his actions are privileged and executable only by himself, his activities will be automatically logged. Furthermore, maintenance personnel will also be considered users when their activity can be accomplished with the system in an operational status. and their actions will also be automatically logged. Finally, the interactions of the operating personal, especially the console operators, will be considered as user activity and logged.
Receipting
Where required by applicable regulations, a receipt shall be obtained from any user who has received classified information from the system. Receipting shall require an overt action on the part of the user following delivery (or presentation) to him of the classified information. The purpose of the receipt is to insure that the user is aware that he has received classified data. For the purposes of this requirement, the bounds of a dialogue between a user and the computer system are defined to be based on the beginning and ending of access to a particular unit of information contained within the system or transferred to or from the system.
Comment: While a properly functioning system already knows, to the degree
adequate for logging of system activity, where information should be or to
whom it has been delivered, the requirement f'or a receipt recognizes a need
for an acknowledgment from the recipient (person or program) that he is aware
that he has received classified information of a particular level. It is
essential for system efficiency and man-machine effectiveness that the receipting
procedure not be imposed excessively. Thus, definition of appropriate transaction
boundaries is crucial. Although it is undesirable to burden the user with
unnecessary actions, nonetheless it may be to his advantage to require a
receipt for all information. He will be aware of, and the system transaction
log will reflect, precisely the information to which he has had access. His
liability is therefore defined, and any investigation which later may arise
because of a system malfunction or divulgence of classified information would
be facilitated.
All security control or assurance mechanisms and procedures shall be designed to include sufficient redundancy and independent checks so that the failure of one control mechanism will not allow an undetected compromise to occur. Frequent automatic checks of these protection mechanisms by the computing system itself, and periodic checks of the procedures by system personnel shall be made. The computing system shall have the capability of guaranteeing that some specified minimum fraction of its time is spent on performing automatic system checking. The percentage of time spent on automatic checking shall be a design parameter of the computing system (capable of change at the local installation as necessary), and shall be established with the concurrence of the System Certifier. The interval between automatic internal self checks may depend on the classification and sensitivity of the information that the system is designed to accommodate. The System Security Officer shall be provided means for establishing what fraction of the time the installed system spends in self-checking and be responsible for controlling the time so spent, depending on the classification and sensitivity of the information that his system is handling. Means shall be provided for the System Security Officer to initiate these checks manually.
A detected failure of the protection mechanisms shall cause the system to enter a unique operating mode wherein no information may be transmitted to or accepted from the user community. In order that there be no unnecessary interruption of services. the system must concurrently check all its internal protection mechanisms. Should the detected failure prove to be the consequence of a transient error, the system should so notify the System Security Officer and be returned to its full operational status by an overt action of the System Security Officer. In the event the failure persists, it shall be the responsibility of the System Security Officer to take any action indicated. He may return the system to full or partial operational status in spite of impaired security controls; he may attempt to remove malfunctioning equipment and restore a modified configuration to full status. In any event. the action required of him must be sufficiently overt that the possible security implications of his action will be patently clear.
Special instructions shall be provided to the System Security Officer in those installations that deal with information of high sensitivity, and for which special procedures are deemed necessary in order to insure that the system is not allowed to operate in a manner that increases the risk of compromise or unauthorized disclosure.
Comment: The issue raised by this recommendation is a delicate one because it addresses a conflict between policy objectives of the system: maintaining service to the users of a computing system, and maintaining proper security control over the information stored within it. If an agent knows how to create an error on demand, total shutdown of a system when trouble is detected is a serious vulnerability. Thus, a capability for flexible response, depending upon the conditions of the moment, is essential. The action taken by the System Security Officer, perhaps in conjunction with the Responsible Authority or the System Administrator, must reflect the operational situation that the system supports. In a military command and control system where delay can mean disaster, operational urgency may dictate that a calculated risk of unauthorized divulgence be assumed in order to maintain continued service to users. On the other hand, a technical information system can afford to suspend service totally in case of trouble, especially if it deals with very sensitive information.
The fraction of its time that a computing system must spend in self-checking, and the scope and depth of such self-checks are not matters that can be assessed readily by the local System Security Officer. Hence this recommendation requires that the problem be addressed at the level of design and installation certification. However, it is reasonable that the System Security Officer have the option of adjusting the periodicity and depth and scope of self-checking, according to the level of information that his system must accommodate.
It is not possible to make positive statements about the frequency with which internal self-checking must be performed. In part, this reflects lack of insight into and experience with the security control mechanisms to be installed in the computing systems under consideration. It may be desirable to perform internal self-checking on some scheduled periodic basis, or, perhaps more wisely, the internal self-checking should take place on an aperiodic basis, such as when a user from a terminal requests access to a file. Aperiodic checking denies a potential penetrator the assurance that he has guaranteed intervals of time in which to attempt to subvert or bypass the security control mechanisms. but it also increases the self-checking load on the machine as the user load increases. In any event, the maximum interval between internal self-tests should be chosen jointly by the user-agency and the System Security Officer. The objective is to find an acceptable balance between system efficiency and the amount of classified information that could be compromised between tests, while maintaining a risk acceptable to the user-agency.
In the event of an automatically detected failure of a control mechanism, it is clear that the computing system must shift to a degraded mode of operation because of the risk of unauthorized divulgence. However, the system design must be such that the system attempts to maintain maximum service to the greatest number of users. It is also clear that the issue transcends the computing central and its procedures; a response to malfunction can also involve communications, remote terminals, other computers, etc.
The degraded mode suggested by the wording of this recommendation seems to be reasonable, but it is not the only possibility. Another, for example, is to bring the System Security Officer into the access control procedure and let him manually verify each user request for access to a given file. If such a procedure were to be implemented, the System Security Officer would need to be provided with a great deal of visually displayed information and with appropriate manual controls over system performance. Typical actions that the System Security Officer might take, depending on the type of failure detected and upon the operational urgency of the moment, include:
(a) Disabling the system completely -- i.e., closing it down and requesting maintenance.(b) Continuing to operate the system in the degraded mode, but under his continuous manual surveillance.
(c) Prohibiting new users, while allowing current users to continue interaction with files presently accessible to them.
(d) Restricting access to classified files to those terminals over which he or some other responsible authority has visual cognizance. Alternatively, he might suspend all but fully-cleared users.
(e) Denying all user requests to access files of special sensitivity.
(f) Electrically severing malfunctioning storage devices, thus permitting the balance of the system to continue in operation. If these devices contain the security control and checking programs and authentication words, etc., then a choice must be made between this option and point (g) below.
(g) By-passing all security checks and operating the system "wide-open."
(h) Electing to operate with unprotected communications.
It is reasonable that the system be designed so that the action options available to the System Security Officer can be automatically presented to him by the system itself. It is also reasonable that each option displayed be accompanied by instructions detailing the manual and procedural actions that he ought to take.
Ultimately, the amount of self-checking incorporated into a system, the
frequency with which self-checking is done, and the precise details of how
the system functions in a degraded mode, will represent a design compromise
between maintaining maximum service to the users and maintaining maximum
safety of the information resident within the system. When circumstances
warrant, the system can be designed to automatically go into a more extensive
mode of internal self-checking, or even to switch automatically to alternate
software packages that can substitute for malfunctioning hardware or software
protection mechanisms.
Information Input
The system shall not accept information, even for temporary use, without first receiving from the user a declaration of the relevant security parameters, which in this case include classification, all caveats, and labels. These parameters will be used by the system to control further use or dissemination of the information. The security parameters can be handled as a declaration covering a definable set of interactions between a user and the system -- e.g., the totality of a dialogue between user and system, beginning when the user logs on and ending when he logs off. The capability for specifying security parameters as a declaration covering a set of interactions is provided in order that the user not be burdened with specifying security information more often than absolutely necessary.
Comment: The requirement that the security parameters be specified before the system will accept information is simply a fail-safe mechanism to avoid oversight on the part of a user. It is reasonable that the system assist the user by asking him in turn for level of classification, codewords, dissemination labels, and information labels (as applicable). Where possible, the system should automatically apply any caveats, labels, etc., implied by information already supplied. It is also reasonable that, on request, the system provide the user with a listing of labels so that he can assure himself that nothing has been over looked.
Information Output
Each user shall be notified of at least the classification level and special access caveats of all information being furnished him by the system. Where physical limitations prohibit or discourage presentation of all caveats and labels associated with each separate page or display of information, means must be provided for the user to obtain them at his request.
Comment: Ideally, all information provided a user, whether printed out in hard copy or electronically displayed, should be accompanied by all relevant security parameters. However, practical limitations in the capabilities of display devices or printers may make alternative procedures necessary. At the minimum, the classification level must be displayed or printed with each page. The user must be able to obtain the complete set of security parameters associated with information when he is being asked to receipt for it.
User-to-User Leakage
Allocation, use, and erasure of storage resources of all types in the computing system shall be handled both by the system and by operational procedures in such a way that no information from a prior use of the storage medium can leak to the current use.
Comment: The consequence of this recommendation is to require that appropriate schemes for management of storage allocation and erasure of storage be incorporated into the system software and system operational features. The problem of leakage concerns both complete and fragmentary pieces of information, and entire as well as partial quantities of storage. For example, the scratch space on a magnetic disc assigned to one classified job must be satisfactorily sanitized before assigning it to a second job. The problem of leakage would be greatly facilitated if magnetic tape transports contained a rewind-and-erase feature, and magnetic discs a read-and-erase feature.
Residual Information
A storage medium shall carry the same classification as the most highly classified information stored on it since the most recent sanitization. All sanitization (e.g., degaussing) shall be done in such a way as to insure that even if the medium were removed from the computing system and subjected to tests under laboratory conditions, no residual information could be extracted from it. The alternative to sanitization is to treat the storage medium as classified until destruction.
This requirement does not imply that all information read from a storage device must be treated as if' it were classified to the highest level of any data ever recorded on the medium. Information extracted from the device by normal means (e.g., via the computer system) may be properly handled at the classification of' the information per se, provided, however that all other criteria that relate to handling of information at that classification level are satisfied.
Sanitation Procedures
The specific techniques and tests required to insure sanitization of'storage media, as required in the preceding paragraph, shall be at the discretion of a Responsible Authority.
Comment: Currently, there is no sanitization technique or equipment generally
available that will consistently degauss any and all media so thoroughly
that residual information cannot be extracted under specialized laboratory
conditions. Additional research and testing are needed to determine the validity
of various procedures now used, and to develop new procedures, equipment,
and tests. It is recommended that research continue, and, to the maximum
extent possible, that duplication of efforts be avoided. Results should be
made available through the Department of Defense. Meanwhile, responsible
authorities must have leeway to select the degaussing technique proven best
for the particular media under their control.
Certification is the process of measuring. testing, and evaluating the effectiveness of the security control features of' a system. It must be accomplished before a system can be used operationally with classified information. The three types of system certification are Design Certification, performed before and during system construction; Installation Certification, performed prior to authorizing a system for operational use; and Recertification, performed after major changes or correction of failures.
Comment: The problem of certifying that a computer system contains a properly functioning set of security safeguards and is operated under an appropriate set of operational procedures is complex and difficult. The issue is considered at this point in connection with policy and operational recommendations, but is also discussed later in the context of hardware recommendations. The precise details of an adequate certification procedure, including the necessary inspections and tests, are difficult to define, although it is clear that the details of such procedures will depend, in part, on the type of computer system in question, and on the scope and type of service that the system furnishes its users. System certification is the crucial process in establishing the classification level permissible in a secure system.
Certification of an overall system, determined on the basis of inspection and test results, shall be characterized in terms of the highest classification or most restrictive specific special-access categories that may be handled. Where tests show that the overall system can effectively maintain the integrity of boundaries between portions of the system, certification may differ for various portions (i.e., for "subsystems").
Comment. This recommendation establishes a convenient way to characterize the certification of a system or portions of it. By permitting certification to differ for portions of a system, we have in principle permitted part of a system to function in an uncertified condition, but subject to tests that demonstrate that the system can effectively maintain the integrity of subsystem boundaries. It is not certain at the present time that tests can adequately establish the integrity of boundaries, thus permitting inclusion of an uncertified portion in a system. In general, the more highly classified and sensitive the information in a system, the more carefully one should consider the risks before permitting an uncertified portion to operate in the overall system.
Tests and Inspections
Any computer system used to process classified information shall be subjected to inspection and test by expert technical personnel acting for the Responsible Authority. The extent and duration of the inspections and tests shall be at the discretion of' the Responsible Authority. The inspections and tests shall be conducted to determine the degree to which the system conforms to the requirements here recommended, any derivative regulations, and other applicable regulations.
Comment: This recommendation does not specify the details of tests and inspections to be conducted, nor does it specify when such tests and inspections are necessary. Furthermore, it does not prohibit the Responsible Authority from using expert technical personnel from an external agency or department. On the contrary, some of the tests and inspection should be conducted by an external groups. Where the sensitivity of the information in the system warrants, some of the tests, inspections, and deliberate diagnostic attempts at penetration should be conducted on an unannounced basis. It is not implied that the extent nature of the tests and inspections necessarily be the same for each of the types of system certification.
Types of System Certification
Design Certification. A series of tests and inspections that establish that the safeguards designed into the hardware and software of the system are operative, function as intended, and collectively constitute acceptable controls for safeguarding classified information. Production models of a given design need be tested only to verify that all safeguards are present and properly functioning. It is recommended that this certification be performed by an agency or a special team not part of the using agency and separate from design or maintenance groups. Specifications (procedures, tests, inspections) for subsequent certification reviews must be produced as part of'the design certification process.
Installation Certification. A series of tests and inspections performed according to specifications established during the design certification phase to insure that the required set of security safeguards (hardware, software, and procedural) are in fact present and operational in the installed equipment, and on all communication links that will carry classified information to remote terminals or other computers. This certification must also examine the operational procedures and administrative structure of the organization that controls the equipment, and must establish that the procedural and administrative environment supplements and complements hardware and software safeguards, and that physical safeguards are appropriate. It is anticipated that certification review will be most extensive and thorough at the time of'initial installation of'the system. Installation certification will probably be conducted by a special team, not necessarily under the control of'the Responsible Authority. Ideally, the System Security Officer will participate in this certification so that he becomes familiar with the safeguards in the system and with the process and intent of certification in order that he can conduct subsequent certifications.
Recertification. Some level of' recertification must be accomplished periodically. as indicated by operational circumstances. These instances are follows:
Periodically during the operational life. It is desirable to recertify the system at intervals during its lifetime. This is in the nature of'a preventive procedure to establish the continuity of' security safeguards, to make gross checks on system functioning, and to search for loopholes in the protection. It is conceivable that some level of' recertification might be desirable at the beginning of' each scheduled shift of operation or on some other periodic basis, as dictated by the needs or sensitivity of the computing installation.After system malfunction. Depending upon how the system has malfunctioned and on what remedial action has been taken, some recertification procedures are desirable to re-establish that the security controls are fully functioning. The responsibility for determining which recertification tests and inspections are necessary rests with the System Security Officer, although he may solicit expert opinion from System Maintenance Personnel or the System Administrator.
After scheduled or unscheduled hardware or software maintenance or modification. As with system malfunctions, some level of recertification undoubtedly is necessary after modifications have been made in the computing equipment or the system software. The scope and depth of these tests and inspections should reflect what maintenance has been performed and what changes have been made. The ultimate judgment as to which recertification procedures are necessary must be the responsibility of the System Security Officer, although he may solicit expert opinion. For sufficiently extensive modifications or maintenance, the recertification procedure may well approximate the extensive set of tests and inspections made at the time of initial installation.
Comment: The Task Force does not recommend any particular recertification periodicity, but suggests that initially, at least, the question of periodic inspection and recertification be jointly determined by the System Security Officer and the Responsible Authority. As each acquires confidence in the capability of the system to maintain satisfactory security control, it is likely that the intervals between tests and recertifications will be adjusted accordingly.
Automatic internal self-testing previously described can be regarded as a form of recertification that takes place on a short time scale (e.g., milliseconds), as opposed to the type discussed above which occurs on a long time scale (e.g. hours, days).
Operational Security Parameters
The necessary operational security parameters of the overall system, or of each portion of it, shall be inserted into the system by the System Security Officer.
Comment: This recommendation is consistent with the view that the security apparatus of the agency that operates a computing system has the necessary overall view to be able to specify the relevant security parameters for the system. The recommendation also reflects the requirement that the System Security Officer be responsible for the currency and accuracy of the parameters in his system. The point is included as part of certification because proper tests and inspections must be conducted in order to ascertain that the security parameters have in fact been correctly inserted into the system (and accepted by it), both initially and each time the security parameters of the system are modified.
Protection at Boundaries
Information shall be passed to or accepted from any portion of the system only at a security level commensurate with the security parameter for that portion of the system. The use by an uncleared person of a terminal certified for highly classified information is permissible without the need for recertification as long as precautions (escorting, continuous surveillance to prevent tampering, etc.) are taken to prevent subversion of the security mechanisms needed (and previously certified as effective) to protect the stipulated classification of the terminal.
Comment: The impact of this recommendation on the clearance specified for a remote terminal is complex. In effect, it requires that the clearance assigned to a given terminal be determined by appropriate tests and safeguards that are commensurate with the highest classification of information to be handled. Temporary operation of the terminal with information of a lower classification is acceptable, providing that adequate measures are taken to maintain the integrity of the certified status of both the terminal and its environment. There must be safeguards that insure that the system responds to each user appropriately to his clearance, and tests must be applied during the various certification phases that verify the presence and efficacy of these protection mechanisms. Extra precautions must be taken before and after the use of a terminal by an uncleared person. Following use of a terminal by a person not cleared to receive information classified equivalent to the terminal's maximum clearance, authentication of a new user is mandatory before initiating transactions involving higher classifications. In establishing his authenticity, the new user is also tacitly indicating that the former user is no longer in a position to monitor the higher classification transactions.
Post-Certification Changes
Changes in the hardware or software of the system shall be installed for normal operations only by the designated System Maintenance Personnel or personnel operating under their observation and supervision, with the concurrence of the System Security Officer. An explicit report of all such changes shall be made to the certifying authority for the particular system, in addition to the normal manual and/or automatic logging of system transactions.
Comment. This recommendation requires explicit reporting of all changes in system hardware or software. If such changes are sufficiently minor in the opinion of the System Security Officer or the System Certifier, then reporting may be sufficient. However, if, in the opinion of the System Certifier or the System Security Officer, the changes are sufficiently major that security safeguards may have been affected, then some level of recertification tests and inspection will be essential.
Continuity of Physical Protection
Equipment and associated materials (e.g., media containing copies of programs) used for handling classified information must be continuously protected against unauthorized change commensurate with the security level at which they most recently have been certified. Copies of operating software that is not itself classified and which is not to be used for actual insertion into the system or to generate programs for insertion into the system need not be subject to this requirement.
Comment: This recommendation is intended to guard against the implantation of intelligence sensors or software changes that might aid penetration of safeguards. Note that it does not require the items to be classified, nor does it require physical protection for all copies of an item. For example, several copies (e.g., on card decks or magnetic tapes or discs) of the operating system software will usually exist. Only that copy to be inserted into the machine for actual running of the system and the master copy from which it was made must be physically protected as required; even then, protection need commence only after a copy has been certified to be correct. Other copies, which are for the convenience of maintenance personnel or system operators and which will not be used to make additional copies or used operationally in the system when it contains classified information, need not be protected. This recommendation should also aid in avoiding unnecessary classification of equipment or software.
It is important to understand what present technology can and cannot do in protecting classified information in a resource-sharing system. Present technology offers no way to absolutely protect information or the computer operating system itself from all security threats posed by the human beings around it. As a consequence, procedural and administrative safeguards must be applied in resource-sharing computer centers to supplement the protection available in the hardware and software.
As could be observed in the policy recommendations, there are two types of environments in which secure computing systems operate. One is an environment consisting of only cleared users who function at physically protected terminals connected to a physically protected computing central by protected communication circuits. The main security problem in such a closed environment is largely one of maintaining the data and program integrity of each individual user. An inadvertent divergence of classified information by the system is analogous to a cleared person finding a classified document for which he is not authorized access. The other type of environment is one in which there is a mixture of uncleared users working at unprotected consoles connected to the computing central by unprotected communication circuits, and cleared users with protected consoles and protected communication lines. The security problem with such an open environment is that the system must be able to withstand efforts to penetrate it from both inside and outside.
For purposes of this Report, the terms closed system and open system are used to indicate security controlled computing systems that operate in these wholly different but realistic environments. From a technical point of view, a secure closed system (i.e., one acceptably resistant to external attack, accidental disclosures, internal subversion, and denial of use to legitimate users) while presenting difficult problems, can be provided by contemporary technology; but a secure open system cannot be provided by contemporary technology. In fact, there is special concern about the risk of compromise of classified information and the vulnerability of an open system to potential penetrations because, as of today:
(a) It is virtually impossible to verify that a large software system is completely free of errors and anomalies.(b) The state of system design of large software systems is such that frequent changes to the system can be expected.
(c) Certification of a system is not a fully developed technique nor are its details thoroughly worked out.
(d) System failure modes are not thoroughly understood, cataloged, or protected against.
(e) Large hardware complexes cannot be absolutely guaranteed error-free.
Since adequate controls cannot be provided by technology alone, it is necessary to rely on a combination of hardware, software, and procedural safeguards. Thus, some of the recommendations below refer to issues already discussed in Part B.
The precise mix of controls and safeguards necessary in any given case will
depend on the operational environment, sensitivity of information, class
of users, and types of service rendered, as noted above. We believe that
these recommendations are both necessary and sufficient for a closed secure
system. However, their sufficiency for an open system cannot be guaranteed
in the abstract. Only by intelligent adaptation to a specific open environment
utilizing experience from closed systems and by extremely objective and stringent
testing and evaluation can their adequacy be established for a specific open
system.
Central processor hardware must provide some or all of the following mechanisms, depending on the class of service it renders its users: user isolation; supervisory software1 protection; and assurance against unanticipated conditions.
____________________
1 Supervisory software, or the Supervisor (also called the Executive or the Monitor) includes that portion of the software that internally manages job flow through the computer, allocates system resources to jobs, controls information flows to and from files, etc.
User Isolation Mechanisms
Each user (or worker) program2 must be isolated from all other programs in the computing system. The currently known principal hardware mechanisms for isolating programs include base-addressing registers and various forms of hardware checking circuits to assure that memory addresses generated within the processor are in fact restricted to those permitted for the programs of a particular user. In addition, some contemporary machines provide memory protection through length-check registers, bounds registers, and storage locks.
____________________
2 User program (or worker program) is a computer program that performs some task for a user of the system. The Supervisor handles scheduling of the user program into the job stream of the system, the allocation of resources to it, control of its security aspects, etc.
The characteristics of the system software determine whether or not user-isolation hardware features are required on systems that provide the user with a file-query capability (Type I in Fig. 2), or with full programming capability through an interpretive mode or in a restricted set of languages with checked-out compilers; (Types II and III in Fig. 2). Sometimes, the hardware features are not necessary in principle, but as a practical matter the use of relevant hardware features greatly simplifies the achievement of isolation. It is recommended that hardware user-isolation mechanisms be required for all resource-sharing systems of Types I, II, and III (in Fig. 2).
Figure 2
[Duplicate added]
It is recommended that isolation hardware be mandatory in systems that provide extensive programming capability to the user in any language and with any compiler of his choice, including the machine language of the computer (Type IV in Fig. 2).
While many contemporary machines designed for multi-programming or time-sharing environments incorporate hardware safeguards that provide user isolation, there is very little internal hardware self-checking to guard against malfunctions. Older machines operating in a security controlling mode may not be able to fully meet these recommendations. To some extent, user isolation achieved by means of hardware mechanisms can be exchanged for isolation via software mechanisms. This should be done with caution, for the protection mechanisms effected by software-means must themselves be safeguarded against collapse due to a hardware or software malfunction.
Supervisor Protection
The objective of Supervisor protection is to deny a user program the ability to penetrate the Supervisor (which contains security control safeguards without detection by the Supervisor. A user program might attempt such a subversion for the purpose of manipulating supervisory information in such a way as to disable security control barriers, or to pre-empt the system and so deny service to other users.
It is recommended that computer systems that provide for programming via interpretation or via limited languages and checked-out compilers, and systems that provide extensive programming capabilities (Types II, III, and IV in Fig. 2), incorporate hardware techniques that have the effect of providing at least two distinct operating states: the user state and the supervisor state (also called worker or slave, and master or privileged, respectively). Any hardware configuration is acceptable if it can create one internal operating state that cannot be penetrated by-any software that a user program can execute.
In the supervisor state, the machine is able to execute all instructions, including those which affect security controls. In the user state, any instruction that initiates an input or output operation (such as a reference to a files, that attempts to modify a register used to isolate users or to protect the Supervisor, or that attempts to suspend or modify security controls must not be executed. Thus, in the user state, a user program will not be able to execute certain instructions and operations that are prohibited to it. Entrance to the supervisor state must be hardware controlled. This frequently is established by providing a facility to detect a special instruction, and creating by hardware means an interrupt signal that returns the computing system to its supervisor state.
If a user program attempts to execute a prohibited instruction, the attempt must be thwarted by immediately suspending the user program and returning control to the Supervisor. Furthermore, if a user program attempts to execute an undefined instruction, this too must be thwarted by immediately suspending execution of the user program and returning control to the Supervisor.
Comment: There are two technical points involved in this recommendation, as well as a delicate question of balancing tight security control against user service. A user program may accidentally attempt to execute a prohibited instruction because the user has made a mistake in his programming; similarly, a sequence of instructions in a user program can inadvertently create a ''false instruction," one whose bit-pattern is undefined in the machine; this can give rise to unpredicted results, including bypassing security safeguards. As an aid to the Supervisor in determining which event has occurred, it would be convenient for the hardware to generate unique interrupt signals for each. Conversely, a user program can deliberately create either of these actions as part of a penetration attempt.
From a security point of view, the safe thing is to suspend execution of the user program whenever it behaves suspiciously. However, if the user is attempting to debug a program, he is likely to have errors in his program that will result in his suspension, and consequently interfere with his work. Possibilities for handling this conflict include imposing a time delay on the user before allowing him to continue (one minute, for example), but imposing a shorter delay (10 seconds, for instance) if he has stated that he is in a debug mode and this statement has been verified by the System Security Officer; imposing successively longer delays on the user as the frequency of his infractions increases; notifying the System Security Officer when a user has exceeded a certain number of violations.
Assurance Against Unanticipated Conditions
Since it is virtually impossible to determine in every situation whether a computing system is working as designed, it is obvious that a machine not operating