Previous section.
COE Security Software Requirements Specification
Copyright © 2003 The Open Group
Introduction
Scope
This document identifies security-related criteria for COE Platform
implementations.
These criteria are drawn from the Defense Systems Information Agency,
Common Operating Environment (COE) Security Software Requirements
Specification (SSRS).
The numbering of security requirements from the DISA SSRS is retained
in this document as an aid to traceability.
Conformance
COE Platform implementations shall meet the criteria listed in this
document. In some cases, text applies to system elements beyond the
COE Platform implementation. In these cases, additional interpretation of the text is
required to clarify the COE Platform implementation-related aspect of the text. Where
interpretation is provided, Rationale text is provided below
the requirement identified using
Italics.
There are no requirements for the following sections of the DISA SSRS
specification:
- 3.2.2
- Trusted Path
- 3.2.6
- Mandatory Access Control (MAC)
- 3.2.7
- Sensitivity Labels
- 3.2.9
- Trusted Interfaces
- 3.2.10
- Object Reuse
- 3.2.14
- Non-repudiation
Normative References
Defense Information Infrastructure (DII) Common Operating Environment
(COE) Security Software Requirements Specification (SRS), Version 4.1,
15 October 1999.
Terminology
For the purposes of this document, the following terminology
definitions apply:
can
Describes a permissible optional feature or behavior available to the
user or application. The feature or behavior is mandatory for an
implementation that conforms to this document. An application can rely
on the existence of the feature or behavior.
implementation-defined
Describes a value or behavior that is not defined by this document but
is selected by an implementor. The value or behavior may vary among
implementations that conform to this document. An application should
not rely on the existence of the value or behavior. An application that
relies on such a value or behavior cannot be assured to be portable
across conforming implementations.
The implementor shall document such a value or behavior so that it can
be used correctly by an application.
legacy
Describes a feature or behavior that is being retained for
compatibility with older applications, but which has limitations which
make it inappropriate for developing portable applications. New
applications should use alternative means of obtaining equivalent
functionality.
may
Describes a feature or behavior that is optional for an implementation
that conforms to this document. An application should not rely on the
existence of the feature or behavior. An application that relies on
such a feature or behavior cannot be assured to be portable across
conforming implementations.
To avoid ambiguity, the opposite of may is expressed as need
not, instead of may not.
shall
For an implementation that conforms to this document, describes a
feature or behavior that is mandatory. An application can rely on the
existence of the feature or behavior.
For an application or user, describes a behavior that is mandatory.
should
For an implementation that conforms to this document, describes a
feature or behavior that is recommended but not mandatory. An
application should not rely on the existence of the feature or
behavior. An application that relies on such a feature or behavior
cannot be assured to be portable across conforming implementations.
For an application, describes a feature or behavior that is recommended
programming practice for optimum portability.
undefined
Describes the nature of a value or behavior not defined by this
document which results from use of an invalid program construct or
invalid data input.
The value or behavior may vary among implementations that conform to
this document. An application should not rely on the existence or
validity of the value or behavior. An application that relies on any
particular value or behavior cannot be assured to be portable across
conforming implementations.
unspecified
Describes the nature of a value or behavior not specified by this
document which results from use of a valid program construct or valid
data input.
The value or behavior may vary among implementations that conform to
this document. An application should not rely on the existence or
validity of the value or behavior. An application that relies on any
particular value or behavior cannot be assured to be portable across
conforming implementations.
Definitions
For the purposes of this document, the following definitions apply:
Login
The unspecified activity by which a user gains access to the system.
Each login is associated with exactly one user name.
Supplier
A product vendor who is interested in, is applying for certification
in, or has certified a product in The Open Group COE Platform
Certification Program.
Trusted User
A user with appropriate privileges to administer the system.
User ID
A non-negative integer that is used to identify a system user.