IRAC Preface |
1 Introduction |
2 General Design Objectives |
3 General Syntax and Semantics of the Abstract Specification |
4 Object Management System |
5 Program Execution Facilities |
6 Input and Output |
7 Protection and Security |
8 Requirements for Tool Management and Services for Tools |
9 Ancillary Requirements |
10 Definitions |
Submission of Comments
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
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
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
Failure is considered to fall into five categories having slightly
different implications for recovery:
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
- 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 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
During a restart of the system there are a number of actions which must
be performed including:
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.
- 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
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
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
and the Information Technology Security Evaluation Criteria (draft)
The term security covers:
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).
- 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.
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
The subject of covert channels is not specifically discussed in the
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.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
It is envisaged that within a PSE there will be a number of roles
established for the software construction process, for example:
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.
- Designer for system designs
- Programmer for system implementations
- Evaluator for validation of implementations
- Configurator for management of configurations
- Project manager for management of projects
It is also anticipated that there will be roles established to handle
the security aspects, for example:
The above descriptions of roles imply an explicit restriction on the
use of some interface facilities to specific roles.
- 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
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.
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
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
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,
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
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
Integrity. The PCIS shall provide:
a) Mechanisms to set the integrity levels of data
b) Facilities to give integrity authorizations to users and to
c) Mechanisms to control the modification of data and their
integrity levels on the basis of the authorizations of the user and the
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
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
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
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
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.
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
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
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:
or any logical combination of such criteria.
- Terminal or Workstation
- Date and Time
- Type of Operation or Function
- Return code
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.
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
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.