they would again be locked. Preferably, these tables would also be protected in a form that separately unlocks individual portions of the entries instead of via an "all or nothing" lock. Protection against errant I/0 transfers must also be applied, although typical minicomputer, Direct Memory Access (DMA), controllers do not abide by the normal memory address controls. One approach would be to physically constrain the address region obtainable by the DMA; e.g., by forcing higher-order address bits to some preset values.

Another example of error control is that of check-summing critical programs (such as is done for the ARPA Net routing programs of Reference BBN-74A). check could be made before and after the execution of a critical process if it is deemed necessary and operationally viable. For example, the checking routines that compare the outputs from the multiple processors might utilize this mode of protection.

3.7.4 SC Hardware Requirements

The hardware requirements for the SC come from: (1) the availability of adequate checking facilities, both for internal processor checks and for inter-processor checks, (2) the availability of security-related hardware features such as multiple-states of operation and address space controls, (3) its operational capabilities, and (4) the availability of appropriate software development tools (e.g., a compiler for a structured programming language).

We have discussed the language related aspects in an earlier section and will not repeat them here. The other three aspects will be discussed in the following paragraphs.

3.7.4.1 Adequate Error Control Facilities. Very few contemporary computers of the scale needed for the SC (e.g., mini-computers) have checking of any substance, with most being limited to simple parity checking of memory transfers.

Registers, busses, and arithmetic/logic operations are typically not checked at all, with a few exceptions. There is some possibility that

additional checking could be obtained via the usage of a microprogrammable machine for the SC. Such checking could be in the form of micro-diagnostics, and might conceivably be able to augment run-time checking.

Checking at the individual processor level is very desirable since it provides an additional layer of protection against error-induced security violations. However, such checking can not be stated as an absolute requirement as long as the higher level checks (e.g., via multiple processors) are made. At this point, it appears that the "requirement" for internal checking should be left as a subjective design consideration.

In addition to error checking, certain other error control features might be obtained in the hardware such as Read-Only Memory (ROM) for the program regions, a watch-dog timer for detection of endless loops, and a program activated alarm to notify a security officer in case of an alarm condition.

3.7.4.2 Security-Related Hardware Facilities. The SC should have the maximum possible security hardware currently available, to protect against both accidental and malicious attempts to defeat its security control function. These facilities should include the following requirements which have been adapted from Bushkin (BUS-74):

At least two operating states (and preferably more) to
implement the least privilege concepts and to constrain
the possible combinations for ease of proof of correctness.

Control of address space to at least a "page" size block, and
at least on a read/write basis (preferably including execute
as a separate privilege).

Address space controls over DMA (e.g., disc) transfers.

• A trap facility to handle any violation of the security
mechanisms.

o A register to indicate the offending instruction in any
trapped violation.

Hardware interrupt with separately maskable interrupt

sources.

A meaningful key-lock mechanism to disable the entry
functions of the CPU's front panel.

3.7.4.3 Operational Requirements.

We assume that the SC will function in an environment in which there are a large number of potential users (of the order of 2,000) while about half of these users are actively using (or requesting) computer resources. We further assume that the typical active user needs a new access (via the SC) about every 20 minutes, and will spend about one minute in the dialog with the SC to gain this access. Following the analysis of Garwick (GAR-73) the expected number of users in a dialog with the SC can be shown to be:

S

Where N is the number of active users (1000 in this example), t is the average service time (one minute), and ta is the average time between arrivals (20 minutes), thereby yielding a rough estimate of 50 simultaneous users in some stage of dialog with the SC.

Disc storage must be provided for the identification, authentication, and authorization data for each possible requestor, as well as providing main storage for that subset of the requestors currently in some stage of dialog with the SC. Estimates have indicated that the disc storage requirements per requestor are:

For 2,000 potential requestors, this would require about 1M bytes of disc

space.

The main (e.g., core) storage requirements have been estimated to be 16,000 bytes for programs (divided evenly between the basic SC code, the I/0 handlers, the terminal handlers, and the audit/status/error recovery package). The data space per requestor that is in some stage of dialog with the SC consists of the Request Control Block and its associated buffer (estimated to be 150 bytes). For 50 simultaneous requestors, the total working space must be 7500 bytes. At a maximum, this space requirement is equal to 150 bytes times the number of logical input ports which the SC will handle. A rough estimate of 10,000 bytes seems reasonable for this data storage. The total estimated program and data space is then of the order of 26,000 bytes, which is consistent with available minicomputer storage capabilities, and leaves a factor of at least two for growth potential.

Each dialog will consist of the execution of about 2,000 instructions by the SC, which at typical minicomputer speeds would require about 4 milliseconds. In addition, each dialog would require several disc accesses at from 10 to 100 msec. each, depending on the type of disc (e.g., either fixed or moving heads). The number of disc accesses will depend on the complexity of the access authorization structure (e.g., linked lists), and on the decision as to whether the active requestor RCB's are kept in main memory or are swapped from the disc. Since the RCB was assumed to include the terminal I/0 buffer, we have implicitly assumed that this storage will be "core" resident for the duration of a requestorSC dialog. For this assumption, we estimate that there will be of the order of 4 disc accesses per dialog, at an average of about 100 msec. per access (for moving head seek time plus latency). These time delays, result in an I/0 queueing situation in which one request will be received per user every 15 seconds on the average, and will require an average of 0.1 seconds for the 1/0 service (transfer time is small compared to access time).

requestors in the SC, the expected time between I/O requests is 15 seconds 50 or 0.3 seconds. For a service time of 0.1 seconds, the queueing "traffic

intensity" is therefore 0.1/0.3 or 0.33, which leads to expected values of:

=

0.1
1-0.33

Expected number in (or waiting for) I/0 service = 1/(1-0.33) = 1.5 Expected time for I/0 (service plus queue delay) = 0.15 sec. Therefore, a standard moving head disc (e.g., a 2M byte cartridge) would appear to meet the operational storage requirements without producing any appreciable I/O queueing delays.

3.7.5 Performance Impact Due to Security

The added requirements of the security mechanisms have a cost in terms of not only the equipments themselves, but often in terms of some level of performance degradation. In the approach which has been described, this effect shows up in the need for an initial (pre-connection) dialog with the SC, in any subsequent HOST-level checks, and in the network overhead required to route audit information to a central site, e.g., the Network Security Center. (The impact due to cryptographic aspects will be considered separately in Section 4.)

The pre-connection dialog with the SC was estimated to require about one minute, primarily due to requestor typing delays, and is an overhead that must be paid for each working connection which, on the average, would last about twenty minutes. This effective overhead is about 5%, being more or less dependent upon the actual duration of each segment of the cycle. The time required for HOST-level checks should also be considered, but can only be estimated in the context of a given situation.

The need for audit data collection, as discussed in Section 3.5, requires that the separate pieces of a distributed audit trail be combined at some site such as a Network Security Center. We will assume that this center is one node of the network, and that audit information is sent to it via the regular network channels. For comparison purposes, it is of interest to estimate this audit. collection overhead relative to the operational network involved. Three classes of usage will be considered, interactive, RJE, and file transfer.