be invoked, (1) when certain behavior patterns have been detected that require monitoring, and (2) for aperiodic pseudo penetration tests. The need for and implications of a Network Security Center will be left as an open issue since it is outside the scope of this investigation.

For our purposes, security assurance can be defined as those aspects of a system design and operation related to the adequacy of the security mechanisms, and the confidence level which we have in the integrity of these mechanisms. We therefore have as objectives:

Accreditation that the mechanisms provide a given set

of protection capabilities.

Determining the sufficiency of the protection provided.

Determining the need for security of the device design.

Ensuring adequate reliability such that the mechanisms

are available to requestors, but having known failure modes
that do not erroneously grant access.

Providing self-checking to further ensure that the mechanisms
are operating properly.

• Ensuring proper interface to physical and procedural controls.

These security objectives must be considered at each of the various levels of the system design (both abstract and physical), and at each epoch of the system use (e.g., system generation, initialization, restart, and shut down). Care must also be taken to ensure that each design decision is fully consistent with the fundamental security requirements, rather than merely automating the existing manual/paper-oriented methods which attempt to meet these requirements. These latter methods should be considered as potential analogies to how the system might operate, but not as requirements in themselves.

2.6.1

Accreditation of the Security Mechanisms

Overall security can never be absolute, nor can the accreditation of any individual security mechanism be determined with complete certainty. Even with the use of "proof of correctness" techniques, we can never be completely assured that the proof itself is correct, or that an implementation necessarily matches the more abstract primitives of such a proof. Therefore, accreditation or certification of a system must be based on the best available design, development, and implementation techniques, coupled with thorough tests to demonstrate empirically that these techniques have been and continue to be effective. Both hardware and software must be subjected to an adequate re-accreditation after any changes.

Any design must be based on a set of requirements, and can not necessarily be expected to meet any needs that have not been included in this statement of requirements. Similarly, a security mechanism can not be expected to protect against threats which were not considered in its design. Therefore, the completeness of the design is a crucial issue, and is one that requires a continual reassessment.

Security mechanisms must also be extendable if they are to handle new and changing requirements, which otherwise will lead to administrative circumvention of the mechanisms. The following are test cases to check the extendability of a given design approach:

The mobile user who needs to move and still maintain access via the network.

Users with "dual roles," e.g., with differing privileges
and needs based on some context.

Handling security domains which fall within the "domain of control" of two or more security control mechanisms.

A controversial issue is that regarding the sensitivity of security mechanisms, as opposed to that of their priming keys (or initialization values). The argument that such mechanisms should not be secret, but should be openly discussed, has been raised by a number of authors, including Baran (BAR-64) in writing about networks and Weissman (WEI-69) on the ADEPT timesharing system. The controversy is primarily one as to whether any additional security is to be gained by keeping the operation of the mechanism secret, in addition to keeping the initialization values secret.

The arguments for keeping the mechanism secret are that this provides a second, and independent form of security. That is, the penetrator must not only discover the encryption key, but must also determine the encryption mechanism that is being used. This approach has two basic weaknesses: (1) it precludes the usage of a standard encryption algorithm (such as the NBS Data Encryption Standard), and (2) it. is extremely difficult to maintain the secrecy of the mechanism due to the large number of persons involved in the design, development, usage, and maintenance of a device. As a consequence, the principal security strength must be in the key and its secrecy.

Two major types of errors are of concern: (1) granting access when it was unauthorized, and (2) failing to grant an authorized request. The latter is of lesser concern by one or more orders of magnitude, depending on the circumstances. Reliability impacts both of these types of failures; the first in the modes of failure when they do occur (the need for fail-secure operation), and the second in terms of the frequency and duration of failures (since during such intervals, authorized users are denied service or must be handled by some backup scheme).

The design must consider all modes of failure of both hardware and software and how such errors will be detected and corrected. Redundancy must be applied, particularly in those areas in which failures would grant unauthorized access.

The proper operation of the security mechanisms should be verified on an on-going basis by means of both diagnostic and pseudo-penetration programs. These checks should be made with an appropriate frequency to detect and limit the extent of any possible compromise due to failures. This pro

vides a second level of checking to backup the fail-secure intent of the design.

2.6.6

Interface to Physical and Procedural Controls

The security mechanisms must have a certain degree of protection in both controlling their use and their modifications (either updating tables of information or making corrective changes). These considerations must be taken into account in the specification of the security mechanisms.

Several other aspects of the design and development of a secure network will be discussed in this section. These are often issues that involve

non-security areas, but which must be considered if the network is to be viable. They include:

One of the most critical (but often overlooked) aspects of resource sharing, and particularly of resource sharing networks, is that of providing a viable user interface. While this issue is not within the scope of our investigation, it deserves mention here to ensure that it is kept as a fundamental network design consideration. Authors who have addressed this problem, and thereby provide a good starting point for additional efforts, include Hicken (HIC-70, 71) in writing about the COINS network, McKay and Karp (in RUS-72) on the IBM Computer Network/440, and Pouzin (POU-73) on the CYCLADES network.* The underlying problem is, as pointed out by Hicken, that of differences. Differences in languages, character sets, conventions, etc. are often left to the user to resolve, thereby creating a significant problem for the experienced user, and an almost hopeless situation for the more typical user who is not a computer expert. While the security control mechanisms should not attempt to solve the user-oriented problems of the HOSTS (e.g., by tutorial, directory, or other services), its design should consider the varying usage-experience, typing abilities, etc. of the user community, and provide sufficiently clear requests and commands in the security control/user dialog.

Other user-oriented references are by Neumann, (NEU-73 B and C), Pyke (PYK-73) and a bibliography by Blanc, et al. (BLA-73), revised and reissued by Wood, et al. (WOO-76).