SECTION 7

PROTECTION AND SECURITY

7.1 Protection of Implementations

This section is concerned with the integrity and reliability of the PCIS software and the data it controls.

7.1A Misbehavior. The PCIS shall be implementable in such a way that an implementation can protect itself against misbehavior by programs.

This requirement makes it mandatory that the specification be implementable so that a program, which could be a user program or tool, cannot corrupt the PCIS itself.

7.1B System Call Interface. The PCIS shall be implementable such that each facility can be mapped to a system call interface.

A system call interface generally carries implications of invoking operations which execute at some higher level of privilege or protection or both, either in hardware or software. This can be used to exploit the most common form of hardware protection (that is, two modes of processor operation with a system or supervisor call to switch between them). The use of such a mechanism to protect the PCIS implementation from the user or a rogue program can provide significant advantages in the areas of integrity and security.

This requirement implies that the entire implementation of the PCIS need not be contained in the executable image of each tool and that the binding between a tool and the PCIS implementation may not be complete until the time the tool is loaded or run. In general facilities of this type are invoked by some indirect mechanism, and hence the binding from the call to the facility may take place at execution time. This serves to enhance the transportability of tools between implementations of the PCIS. A secondary advantage is the minimization of the size of the tool's executable file since the entire interface code is not included within it.

7.1C Recompilation. The PCIS shall be implementable such that it is unnecessary to recompile or relink any part of the PCIS implementation in order to modify a tool. This includes, but is not limited to, the evolution of the type structure of the Object Management System (OMS).

It is undesirable to have the installation or reinstallation of a tool or a modification to the type structure of the OMS necessitate system regeneration. Further, this requirement allows the PCIS implementation to be delivered in a form which precludes modification of the code itself.

7.1D Recovery. The PCIS shall support facilities for recovery after a system failure (either hardware or software) or other discontinuity.

Checkpoint/restart facilities are to be provided, for the ordinary user, by the PCIS. Only users with special privileges may invoke the recovery mechanisms. These mechanisms might call for manual intervention by the system administrator, and in a secure system, the principle of least privilege must be carefully applied such that the administrator is not given access to, nor allowed to write to, more than is necessary to perform any required repair. Minimal manual intervention should be needed during recovery. An audit trail of the repair operations must be made in case a security breach is subsequently suspected.

Failure is considered to fall into five categories having slightly different implications for recovery:

Power failure: Interruption of the system power.
Hardware failure: Failure of some hardware component.
Software failure: Error in some software component which causes the system to crash.
Other discontinuity: Failure attributed to circumstances, for example deadlock or thrashing.
Hacker protection: Failure attributed to break-ins and other forms of deliberate attempts to compromise the integrity of the system.

In the event of power failure it may be possible to arrange for a controlled shutdown of the system so that recovery can be effected without manual intervention. There is, in general, no danger of a security breach either during the failure or subsequently during the recovery.

In the event of failure of some hardware component it is possible that the system cannot arrange for an orderly shutdown, and this can lead to partially completed transactions and partially updated objects within the OMS. It is also possible that a security breach can occur during the failure (for instance, access control information could be overwritten due to a disc controller error). Recovery may well require manual intervention to restore the consistency of the OMS, with the attendant risk of a security breach.

In the event of a software failure there is again the possibility that the system cannot arrange for an orderly shutdown, and again partially completed transactions and partially updated objects can result. The software failure itself may, if it is within the trusted area of the system, lead to a security breach. Recovery may well require manual intervention to restore the consistency of the OMS, with the attendant risk of a security breach.

Other failures may allow orderly shutdown of the system, or they may not. If orderly shutdown is possible then there should be no problems during recovery, and no risk of a security breach. If an orderly shutdown is not possible then it may be necessary to disconnect power from the system in order to prepare for a restart. Depending on the nature of the failure this may or may not give rise to the danger of a security breach.

During a restart of the system there are a number of actions which must be performed including:

Unwinding incomplete transactions
Bringing the OMS into a consistent state
If the system is a part of a network, bringing the OMS into line with the rest of the network

At least some of these actions are likely to involve the system administrator in manual intervention, and it is desirable that tools present a uniform interface since one administrator may be handling a large number of different PCIS implementations on a range of machines.

7.1E Indefinite Allocation. The PCIS shall support mechanisms to guard against indefinite allocation of resources.

This is really a requirement that it should be possible within an environment to avoid loss of service due to indefinite holding of resources.

7.2 Specific Security Requirements

The requirements that follow are intended to cover non-disclosure (confidentiality) and integrity aspects of security, for both mandatory and discretionary security. An implementation may need to satisfy other security requirements not covered by the PCIS, for example, the NATO Trusted Computer System Evaluation Criteria [NATO87] and the Information Technology Security Evaluation Criteria (draft) (ITSEC) [ITSEC90].

The term security covers:

Security in the sense of confidentiality - ensuring that access to information is controlled through the use of specific security features so that only properly authorized individuals, or processes operating on their behalf, can read, write, create or delete information.
Integrity - protecting data against unauthorized change.
Availability/Denial of service - ensuring that unauthorized personnel cannot prevent legitimate access to computing resources by deletion of data, monopolization of processing resources or other means.

The requirement covers system construction in a secure environment (this relates to 1 above) and the construction of secure operational systems (this requires 2 above, in order to ensure that means to violate the security of the operational system are not inserted in the system under development).

Availability of service and denial of service are areas which are considered to be of crucial importance in military and commercial security. These are difficult problems which are currently unsolved. Duplication of resources may be used to provide for availability of service. However, this cannot provide a total guarantee since any individual with write access to an object could delete the object and all replications. Denial of service can become critical under some circumstances, for example meeting a deadline. There are no known mechanisms which provide universal protection against denial of service.

The subject of covert channels is not specifically discussed in the IRAC; see [NATO87].

It should be noted that the security requirements are couched in terms of subjects and objects, while the other requirements in the IRAC are couched in terms of data or objects and users. This is intentional, and it is the PCIS designer's job to demonstrate or describe the correspondence between the different terms, or mapping between them, to show how the requirements are met.

7.2A Multi-Level Security. The PCIS shall be implementable such that multi-level secure and trustworthy operation on appropriate system architectures is possible.

This is a reflection and a motivation for requirements in Sections 7.2 and 7.3.

7.2B Separation of Roles. The PCIS shall provide for different roles in which a user can act (for example, administrators, subcontractors, end-users, managers). The PCIS shall provide for the restriction of privileges to roles in accordance with the principle of least privilege.

It is envisaged that within a PSE there will be a number of roles established for the software construction process, for example:

Designer for system designs
Programmer for system implementations
Evaluator for validation of implementations
Configurator for management of configurations
Project manager for management of projects

More than one user may adopt the same role. For example, there may be several programmers working on a project. A user may adopt more than one role during the lifetime of a project but may not adopt more than one role at any one time.

It is also anticipated that there will be roles established to handle the security aspects, for example:

System Administrator, whose responsibilities include: backup, recovery, hardware installation, software installation, and setting system time/date.
Security Officer, whose responsibilities include: creation and deletion of user identities, assignment of roles to users, setting and resetting of default passwords, specification of labels on human readable output, assigning of clearance levels to sources, specification of audit actions, and restriction of the set of labels for input and output channels.
Auditor, whose responsibilities include: evaluation of audit files and the creation, preparation and reuse of audit files.

The above descriptions of roles imply an explicit restriction on the use of some interface facilities to specific roles.

7.2C Identification and Authentication. The PCIS shall be implementable such that:

a) All users are identified prior to any operations being carried out on their behalf

b) All users are associated with a role prior to any operations being carried out on their behalf

c) Both the identification and authentication of users and the association of users with roles is done via a trusted path

These requirements demand that a user assumes a role prior to performing any operations. The identity of the user must be properly authenticated so as to guarantee the accountability of the user throughout the session.Authentication information must be protected against read access by any user. The information should not be easily deducible. For example, passwords should be non-trivial and possibly machine generated. This information is not necessarily a password and is changed only when initiated by a user. The only exception to this is that the security officer may set and reset values. This exception is necessary to support introduction of new users and to handle users who have "lost" or forgotten their authentication information. The authentication information must be changed by the user at the first sign in (preferably immediately) after the default value is set. Otherwise the accountability of the user cannot be guaranteed.

7.2D Labels. The PCIS shall be implementable in such a way that labels are provided for each subject and object and that the integrity of these labels is guaranteed. These labels will be used by the mandatory access control referred to in Requirements 7.2F and 7.2G.

Labels represent security classifications. They are the basis for all the possible security and integrity policies. The possible policies depend only on labels and the rules enforced.

The interpretation of data in the label field is exclusively for the purpose of mandatory access control. An integrity policy could be the only policy enforced.

The only function which affects labels is "Change of Labels". This must be in the trusted part of a given implementation and thereby guarantees the integrity of the label. Labels are not visible at the interface for most facilities, and the semantics of those facilities are unaffected by the label.

7.2E Change of Labels. The PCIS shall provide facilities to change a label associated with a subject or an object. The PCIS shall be implementable in such a way that this change is always audited.

If labels are not implemented then these facilities will obviously have no effect. The conditions under which these facilities are valid must be specified in the policy. These facilities will be used for the manual relabeling of objects which are imported from non-trusted sources, or for resolving over-classification. The use of these facilities should be restricted to certain roles (for example, the security officer).

7.2F Mandatory Access Control.

a) The PCIS shall be implementable so as to enforce a mandatory access control policy over all subjects and objects under its control. It is intended that mandatory access control policies be expressible as sets of rules described in terms of labels on subjects and objects. The contents of these labels are the basis upon which the rules operate to grant or deny access.

b) The PCIS shall be implementable so as to ensure that no bypassing of mandatory access control is possible.

c) The PCIS shall be designed so that different instances of an implementation may support different mandatory security policies.

d) The PCIS shall specify the behavior of implementations which do not fully provide the mandatory security facilities.

In order to control the manipulation of classified information, a security policy must include detailed and unambiguous rules on how to handle that information throughout its lifetime. These rules are a function of labels, Requirement 7.2D, and the various forms of access supported by a system. Mandatory access control refers to the enforcement of a set of access control rules that constrain a subject's access to information based on a comparison of the subject's clearance/authorization to the information, the classification designation of that information, and the form of access being mediated.

The system must assure that labels associated with data cannot be arbitrarily changed or by-passed, since this would permit subjects who lack proper authorization to access sensitive information.

The mandatory access control rules must accurately reflect the security policy from which they are derived. The IRAC does not specify a specific security policy. The PCIS is intended to be used by different organizations, each with its own security policies. Hence it may be desirable to integrate separate Policy Managers into PCIS implementations, in order to tailor them for particular policies. There may be a need for a separate interface within a PCIS implementation, which is available exclusively to the Policy Manager. This means that, in effect, an organization with a specific security policy embedded in the Policy Manager has a different implementation of the PCIS.

As an example of this approach consider IBM's MVS operating system together with RACF or Top Secret. There is a distinct and simple interface which is used by these two, or by a user-defined access control module. These modules could be considered as instances of a Policy Manager. Each enforces a specific security policy. The drawback of this approach is the necessity to trust the universal part of the PCIS implementation, hence the whole implementation would have the quality rating of a category C operating system, with almost the functionality of a category B operating system [NATO87].

7.2G Integrity. The PCIS shall provide:

a) Mechanisms to set the integrity levels of data

b) Facilities to give integrity authorizations to users and to programs

c) Mechanisms to control the modification of data and their integrity levels on the basis of the authorizations of the user and the program

d) Facilities to test the integrity level of an object

In software development, we can never be completely sure that some part or feature of the product has not been maliciously corrupted. In this sense we have the simple intuitive notion that we do not completely trust the final product. Absolute trust in a product may be impracticable or impossible to attain, therefore products may be built from components which are trusted to different levels, i.e. the components may have different integrity labels.

The values of integrity labels represent the extent to which data may be trusted. The value of the integrity label may be granted on the basis of a certification procedure or combination of procedures that together constitute an integrity policy.

This requirement is intended to ensure support for reliable configuration management and the ability to control which users use which versions of which tools in which order. Note that other aspects and meanings of integrity are addressed by other requirements in this document; in particular, those aspects relating to data consistency are addressed in Requirement 4.1F.

7.2H Discretionary Access Control. The PCIS shall provide facilities to allow the access rights of each subject to each object to be independently specified. The PCIS shall be implementable so as to ensure that no bypassing of discretionary access control is possible.

The basis for discretionary access control is that an individual user (or process operating on his behalf: the subject) is allowed to specify explicitly the types of access others may have to information under his control. Discretionary access control differs from mandatory access control in that it is based on need-to-know as opposed to mandatory control driven by the classification or sensitivity designation of the information.

Discretionary access control is not a replacement for mandatory access control. Discretionary security provides for a finer granularity of control within the overall constraints of mandatory security. Access to classified or sensitive information requires effective implementation of both types of control as preconditions to granting that access. The discretionary controls must be consistent with the overriding mandatory control restrictions.

7.2I Exportation of Objects. The PCIS shall be implementable such that, when objects are exported, the exported label shall accurately and unambiguously represent the internal label, so that the recipient can handle the objects according to its security policy. The PCIS shall provide facilities to restrict the set of labels that are allowed to be exported over each export channel. The PCIS shall be implementable such that any change to this set of labels is auditable.

The use of the term recipient above is deliberate and allows export of objects to workstations, file servers, networks, human being, etc. All recipients have a clearance level. The restriction to a set of labels is far more general than the concept of maximum and minimum levels as expressed in the Orange Book [NATO87], which implies a hierarchy of labels. The restriction to a set of labels can be applied to policies where labels do not even form a lattice.

Exportation must be subject to mandatory access control.

7.2J Importation of Objects. The PCIS shall be implementable such that each import channel can be labeled as trusted or not and shall provide facilities to label each object imported from a non-trusted channel. The PCIS shall provide facilities to restrict the set of labels that may be imported via a trusted channel and shall be implementable so that any change to this set of labels is auditable. The security label associated with each imported object shall be translated according to the recipient's security policy.

This requirement is complementary to the requirement for export of objects. The labeling of data from a non-trusted channel may be an automatic process using the highest confidentiality level and the lowest integrity level of the channel. Manual upgrading or downgrading of information may be performed afterwards.

7.2K Model Specification. The PCIS shall include a specification of a security policy model at a level of abstraction that can be tailored to specific security policies. The PCIS shall include a description of how this model maps into the remainder of the PCIS.

The model describes the general semantics of the Policy Manager module.

The IRAC and PCIS do not specify a specific security policy that an organization uses. This IRAC requirement states that the PCIS shall specify a high level abstract security policy model that can be tailored to express the specific security policy of any given organization.

7.2L Audit. The PCIS shall provide facilities to specify under which conditions calls of PCIS facilities shall be audited. Audit conditions shall only be changeable by an authorized role. Access to audit data shall only be granted to an authorized role. The PCIS shall provide facilities to specify the type of data to be recorded in each audit record. The PCIS shall support the provision of audit which can be related to development activities.

Audit might be selectable on the basis of either:

User
Terminal or Workstation
Date and Time
Type of Operation or Function
Data
Return code

or any logical combination of such criteria.

The actions of the administrator and security officer must always be audited, the audit records being appended to an audit file. The classification of the audit file depends on the security policy: for instance, in a Bell La Padula-like policy the audit file has the highest classification present in the system, otherwise there would be an illegal (high to low) information flow.

The audit information is at a level of abstraction which can be related to the activities involved while developing software. The level of abstraction of the audit will vary with different activities.

7.2M Security Groups. The PCIS shall provide for groups of users. It shall be possible for a single user to form a group, and for two or more groups to be combined to form a group.

7.3 Trusted Computer Systems

The PCIS shall provide facilities to allow tools to operate within a Trusted Computer System (TCS) that meets the criteria as defined in the NATO Trusted Computer System Evaluation Criteria [NATO87]. Specifically:

a) The PCIS shall be implementable within a TCS.

b) When implemented within a TCS, the PCIS shall support the use of the security mechanisms provided by the Trusted Computing Base (TCB) to applications programs.

c) The PCIS shall be implementable such that the PCIS facilities sensitive to mandatory confidentiality shall operate as a dedicated single-level system (that is, all objects at a single security level, and all subjects cleared to at least that level).

This requirement recognizes that not all PCIS implementations will operate in a multi-level secure mode. For those implementations that will, the PCIS must be implementable within a trusted computer system and utilize the security mechanisms of the trusted computing base. For those implementations that operate as a single level system all objects will be at a single security level and all subjects will be cleared to at least that level. Note that this includes implementations that will operate at the unclassified level.

Go forward to Section 8, Requirements for Tool Management and Services for Tools.