💾 Archived View for spam.works › mirrors › textfiles › hacking › fcscvol1.hac captured on 2023-11-14 at 09:51:06.
⬅️ Previous capture (2023-06-14)
-=-=-=-=-=-=-
FEDERAL CRITERIA
for
INFORMATION TECHNOLOGY SECURITY
VOLUME I
Protection Profile Development
Version 1.0
December 1992
This document is undergoing review and
is subject to modification or withdrawal.
The contents of this document should not
be referenced in other publications.
NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY
&
NATIONAL SECURITY AGENCY
NOTES TO REVIEWERS
This is the first public draft of work in progress by the joint
National Institute of Standards and Technology (NIST) and
National Security Agency (NSA) Federal Criteria (FC) Project.
This draft Federal Criteria for Information Technology Security
is provided for preliminary review and comment by members of the
national and international computer security community. The
document will evolve into a new Federal Information Processing
Standard (FIPS) intended principally for use by the United States
Federal Government, and also by others as desired and
appropriate. The FIPS is intended to replace the Trusted Computer
System Evaluation Criteria (TCSEC) or "Orange Book."
Our objectives in presenting this draft material are threefold:
first, to give the community a clear view of the FC Project's
direction in moving beyond the TCSEC method of expressing
requirements in order to meet new IT security challenges; second,
to obtain feedback on the innovative approaches taken, the method
of presentation, and granularity; and third, to make a
substantial contribution to the dialogue among nations leading to
the harmonization of IT security requirements and evaluations.
It is important to note a few things about this preliminary FC
draft. First, it is a new and unpolished document and not intended
for any purpose except review and comment. Organizations should
not adopt any contents of this draft document for their use. It
is anticipated that the document will undergo extensive revision
as it works its way through the public FIPS approval process over
the next year or two. Second, the FC is being distributed in two
volumes. Volume I addresses the criteria development process and
is intended principally for use by developers of protection
profiles. The information in Volume I may also be of use to IT
product manufacturers and product evaluators. Volume II presents
completed IT product security criteria in the form of accepted
protection profiles.
The protection profiles associated with the final FIPS will help
consumers identify types of products that meet the protection
requirements within their particular organizations and
environments. However, the FIPS will be supplemented by a series
of implementing guidance documents, many of which will be
designed to help consumers make cost-effective decisions about
obtaining and appropriately using security-capable IT products.
As a preliminary draft of the new FC-FIPS, this document is not
intended for general distribution or compliance. The document
should not be considered a complete or finished product. Your
comments will be used by the Federal Criteria Working Group to
help raise the maturity level of this material prior to being
circulated for further public comment in the FIPS development
process.
ADDITIONAL NOTES TO REVIEWERS
Reviewers who provide substantive comments on the enclosed draft
FC by March 31, 1993 will be invited to attend an Invitational
Workshop on the Federal Criteria. This two-day workshop will be
held in the last week of April 1993 in the Washington-Baltimore
area at a location to be announced. All comments received by the
cut-off date will be correlated into major themes for discussion
by break-out groups at the workshop. The results will be used as
input into the process of re-drafting the FC for a second round of
comment prior to its being formalized as a FIPS.
Please send your comments (electronic format preferred) to
Nickilyn Lynch at the U.S. National Institute of Standards and
Technology (NIST), Computer Systems Laboratory (CSL).
Phone: (301) 975-4267
FAX: (301) 926-2733.
(Internet) Electronic Mail:
lynch@csmes.ncsl.nist.gov
Postal or Express Mail
(Hardcopy or 3.5", 1.44M diskette in MSDOS, Macintosh, or Sun
format):
Federal Criteria Comments
Attn: Nickilyn Lynch
NIST/CSL, Bldg 224/A241
Gaithersburg, MD 20899
Table of Contents
Chapter 1.
INTRODUCTION
1.1 Purpose
1.2 Scope
1.3 Audience
1.4 Organization of the Standard
Chapter 2.
IT SECURITY DEVELOPMENT
2.1 Overview
2.2 Functions and Assurance
2.3 Profile Development and Analysis
2.4 Product Development and Evaluation
2.5 System Development and Certification
Chapter 3.
PROTECTION PROFILES
3.1 Overview
3.2 Sources of Protection Profiles
3.3 Protection Profile Contents
3.4 Protection Profile Development
3.4.1 Environment Security Analysis
3.4.1.1 Expected Threats
3.4.1.2 Intended Method of Use and Environment
3.4.2 Component Requirement Synthesis
3.5 Protection Profile Analysis
3.5.1 Technical Soundness
3.5.2 Usefulness
3.5.3 Evaluation Capability
3.5.4 Distinctness
3.5.5 Consistency
3.6 Protection Profile Registration
Chapter 4.
FUNCTIONAL REQUIREMENTS
4.1 Overview
4.2 TCB Functional Components
4.2.1 Security Policy Support
4.2.1.1 Accountability Policy
4.2.1.1.1 Identification & Authentication (I&A)
4.2.1.1.2 System Entry
4.2.1.1.3 Trusted Path
4.2.1.1.4 Audit
4.2.1.2 Access Control Policy
4.2.1.2.1 Discretionary Access Control Policies
4.2.1.2.2 Non-Discretionary Access Control Policies
4.2.1.2.3 Covert Channel Handling
4.2.1.3 Availability Policy
4.2.1.3.1 Resource Allocation
4.2.1.3.2 Fault Tolerance
4.2.1.4 Security Management
4.2.2 Reference Mediation
4.2.3 TCB Logical Protection
4.2.4 TCB Physical Protection
4.2.5 TCB Self-Checking
4.2.6 TCB Start-Up and Recovery
4.2.7 TCB Privileged Operation
4.2.8 TCB Ease-of-Use
4.3 Rated Functional Components
4.3.1 Rated Identification & Authentication Components
4.3.2 Rated System Entry Components
4.3.3 Rated Trusted Path Components
4.3.4 Rated Audit Components
4.3.5 Rated Access Control Components
4.3.5.1 Rated Covert Channel Handling Components
4.3.6 Rated Resource Allocation Components
4.3.7 Rated Security Management Components
4.3.8 Rated Reference Mediation Components
4.3.9 Rated Logical TCB Protection Components
4.3.10 Rated Physical TCB Protection Components
4.3.11 Rated TCB Self Checking Components
4.3.12 Rated TCB Start-Up and Recovery Components
4.3.13 Rated TCB Privileged Operation Components
4.3.14 Rated TCB Ease-of-Use Components
4.4 Bibliographic Notes
Chapter 5.
DEVELOPMENT ASSURANCE REQUIREMENTS
5.1 Overview
5.2 Development Assurance Components
5.2.1 Development Process
5.2.1.1 TCB Property Identification
5.2.1.2 TCB Design
5.2.1.2.1 TCB Element Identification
5.2.1.2.2 TCB Interface Definition
5.2.1.2.3 TCB Modular Decomposition
5.2.1.2.4 TCB Structuring Support
5.2.1.2.5 TCB Design Disciplines
5.2.1.3 Implementation Support
5.2.1.4 TCB Testing and Analysis
5.2.1.4.1 Functional Testing
5.2.1.4.2 Penetration Analysis
5.2.1.4.3 Covert Channel Analysis
5.2.2 Operational Support
5.2.2.1 User Guidance
5.2.2.2 Administrative Guidance
5.2.2.3 Flaw Remediation
5.2.2.4 Trusted Generation
5.2.3 Development Environment
5.2.3.1 Life Cycle Definition
5.2.3.2 Configuration Management
5.2.3.3 Trusted Distribution
5.2.4 Development Evidence
5.2.4.1 TCB Protection Properties
5.2.4.2 Product Design and Implementation
5.2.4.3 Product Testing and Analysis
5.2.4.3.1 Functional Testing
5.2.4.3.2 Penetration Analysis
5.2.4.3.3 Covert Channel Analysis
5.2.4.4 Product Support
5.3 Rated Development Assurance Components
5.3.1 Development Process
5.3.1.1 Rated TCB Property Identification Components
5.3.1.2 Rated TCB Element Identification Components
5.3.1.3 Rated TCB Interface Definition Components
5.3.1.4 Rated Modular Decomposition Components
5.3.1.5 Rated TCB Structuring Support Components
5.3.1.6 Rated TCB Design Discipline Components
5.3.1.7 Rated Implementation Support Components
5.3.1.8 Rated Functional Testing Components
5.3.1.9 Rated Penetration Analysis Components
5.3.1.10 Rated Covert-Channel Analysis Components
5.3.2 Operational Support
5.3.2.1 Rated User Guidance Components
5.3.2.2 Rated Administrative Guidance Components
5.3.2.3 Rated Flaw Remediation Components
5.3.2.4 Rated Trusted Generation Components
5.3.3 Development Environment
5.3.3.1 Rated Life Cycle Definition Components
5.3.3.2 Rated Configuration Management Components
5.3.3.3 Rated Trusted Distribution Components
5.3.4 Development Evidence
5.3.4.1 Rated TCB Protection Property Evidence Components
5.3.4.2 Rated Product Design/Implementation Evidence Components
5.3.4.3 Rated Functional Testing Evidence Components
5.3.4.4 Rated Penetration Analysis Evidence Components
5.3.4.5 Rated Covert Channel Analysis Evidence Components
5.3.4.6 Rated Product Support Evidence Components
5.4 Bibliographic Notes
Chapter 6.
EVALUATION ASSURANCE REQUIREMENTS
6.1 Overview
6.2 Evaluation Assurance Components
6.2.1 Testing
6.2.1.1 Test Analysis Components
6.2.1.2 Independent Testing Components
6.2.2 Evaluation Review Requirements
6.2.2.1 Development Environment Review
6.2.2.2 Operational Support Review
6.2.3 Evaluation Analysis Requirements
6.2.3.1 Design Analysis
6.2.3.2 Implementation Analysis
6.3 Rated Evaluation Assurance Components
6.3.1 Rated Test Analysis Components
6.3.2 Rated Independent Testing Components
6.3.3 Rated Development Environment Review Components
6.3.4 Rated Operational Support Review Components
6.3.5 Rated Design Analysis Components
6.3.6 Rated Implementation Analysis Components
6.4 Bibliographic Notes
Chapter 7.
CONSTRUCTION OF PROTECTION PROFILES
7.1 Overview
7.2 Synthesis of Profile Components
7.2.1 Assignment
7.2.2 Refinement
7.2.3 Decomposition
7.2.4 Level-Selection
7.3 Dependency Analysis
7.3.1 Dependency Classification
7.3.2 Dependencies Among Functional Components
7.3.2.1 "Uses" Dependency among Functional Components
7.3.2.2 Policy-Property Dependency
7.3.2.3 Multiple Dependencies
7.3.3 Dependencies Among Assurance Components
7.3.3.1 "Uses" Dependency among Assurance Components
7.3.3.2 Assurance-Process Dependencies
7.3.4 Dependencies between Functions and Assurances
7.3.4.1 Relationship to other Function and Assurance Classifications
7.3.5 Examples of Using Dependency Analysis
7.4 Bibliographic Notes
GLOSSARY
ACRONYMS
Appendix A.
THREATS TO INFORMATION
Appendix B.
THE REFERENCE MONITOR CONCEPT
Appendix C.
DEFINING ACCESS CONTROL POLICIES
Appendix D.
MODULAR DECOMPOSITION
Appendix E.
PENETRATION ANALYSIS
Appendix F.
MOTIVATION FOR DEPENDENCY ANALYSIS
Appendix G.
EXAMPLE ASSURANCE PACKAGES
List of Figures
Figure 1. IT Security Development Activities
Figure 2. Protection Profile Development
Figure 3. Basis for Threat Analysis
Figure 4. Taxonomy of TCB Functions
Figure 5. Taxonomy of Development Assurances
Figure 6. Taxonomy of Evaluation Assurance Components
Figure 7. Examples of Uses Dependencies among Functional Components
Figure 8. Examples of Uses and Policy Properties Dependencies in Access
Control
Figure 9. Examples of Cyclic Dependencies and their Removal
Figure 10. Examples of Policy Property Dependencies
Figure 11. Examples of Uses Dependencies Among the TCSEC B2 Operational
Assurances
Figure 12. Examples of Uses Dependencies Among Components Corresponding
to B2 Operational Assurances
Figure 13. Example of Uses Dependencies among the Function and Assurance
Components Corresponding to the B3 Operational Assurances
Figure 14. Authorization of Subject References to Objects
List of Tables
Table 1. Protection Profile Structure
Table 2. Rated Functional Components
Table 3. Rating Summary for Development Assurance Components
Table 4. Common Threat Agents
Table 5. Inappropriate Disclosure Threats (Confidentiality Violations)
Table 6. Fault-and-Error Threats (Integrity Violations)
Table 7. Loss-of-Service Threats (Availability Violations)
Table 8. T1 Assurance Package
Table 9. T2 Assurance Package
Table 10. T3 Assurance Package
Table 11. T4 Assurance Package
Table 12. T5 Assurance Package
Table 13. T6 Assurance Package
Table 14. T7 Assurance Package
Table 15. Assurance Packages Summary
Chapter 1.
INTRODUCTION
1.1 Purpose
This Federal Information Processing Standard (FIPS) provides
a basis for developing, analyzing, and registering criteria
for information technology (IT) product security development
and evaluation. It explains how to use provided generic
requirements as building blocks to create unique sets of IT
product security criteria called protection profiles.
This standard builds on national and international IT product
security research and development by bringing together and
extending many concepts of this previous work. The FIPS has
four principal objectives.
a. Develop an extensible and flexible framework for defining
new requirements for IT product security. IT product
security criteria must respond to the challenges of
extensible computing environments. The standard must
provide a structured approach for specifying security
requirements for IT products employed in such environments.
b. Enhance existing IT product security development and
evaluation criteria. The fundamental principles of IT
product security must be reviewed and renewed for
application to new applications environments. The standard
must address selected IT product security requirements of
both Federal Government and private sector organizations.
c. Facilitate international harmonization of IT product
security development and evaluation criteria. Producers of
IT products competing in the international marketplace can
benefit from a harmonized set of IT security development
and evaluation criteria and an evaluation process that is
economical, efficient, and predictable. The standard must
meet U.S. Government and commercial security needs while
recognizing that many of those needs are also shared by the
government and commercial entities of other nations.
d. Preserve the fundamental principles of IT product security.
The fundamental principles of IT product security developed
during the past decades must be preserved. The standard
must be compatible with previous IT product security
requirements insofar as possible in order to protect
previous investments in the technology.
1.2 Scope
This standard addresses the full spectrum of IT product
security needs, to include confidentiality, integrity, and
availability. Confidentiality requirements protect against
inappropriate disclosure of information; integrity
requirements ensure the correctness and appropriateness of
information and/or its sources; and availability ensures that
information is present and usable within reasonable time
constraints.
This standard addresses the specification of internal
security controls (protection mechanisms) that are
implemented in the hardware, firmware, and software of an IT
product. For these internal controls to be effective, however,
adequate external security controls must be employed. IT
product security is complemented by these external controls
(which include physical, personnel, procedural, and
administrative security measures) and by a separate
certification and accreditation process. For an IT product,
the external security measures constitute assumptions and
boundary conditions that are part of the environment described
in a protection profile. These environmental assumptions and
boundary conditions are necessary to ensure IT products can
be used in such a way as to meet identified security needs.
This standard distinguishes IT product requirements from IT
system requirements. In general, an IT product is a hardware
and/or software package that can be purchased as an off-the-
shelf product and incorporated into a variety of systems. An
IT system is generally constructed from a number of hardware
and software components. For certain applications, it may be
possible to purchase a single IT product that satisfies all
customer requirements and, therefore, serve as a complete
system. In most cases, however, at least some IT product
customization and integration will be necessary to meet system
specific requirements.
>From a security perspective, the principal distinction
between products and systems lies in what is certain about
their operational environment. An IT product must be suitable
for incorporation into many potential IT systems. Thus, the
product developer can only make general assumptions about the
operational environment of a system in which the product may
be incorporated. These general assumptions include intended
method of use and generalized threats within the environment.
In contrast, an IT system must provide applications and meet
the requirements of a specific group of end-users within a
specific operational environment that has a specific set of
threat scenarios.
This standard addresses IT product requirements only. The
composition of multiple IT products into an IT system is
beyond the scope of this standard. Guidance for profile and
product composition will be addressed in future publications.
1.3 Audience
This document serves three primary customer groups with
respect to IT product security:
a. Consumers: Individuals or groups responsible for specifying
requirements for IT product security (e.g., policy makers
and regulatory officials, system architects, integrators,
acquisition managers, product purchasers, and end users).
b. Producers: Providers of IT product security (e.g., product
vendors, product developers, security analysts,
integrators, and value-added resellers).
c. Evaluators: Individuals or groups responsible for the
independent assessment of IT product security (e.g.,
product evaluators, system security officers, system
certifiers, and system accreditors).
Secondary audiences include technical educators, standards
bodies, and the research and development community.
1.4 Organization of the Standard
The remainder of this FIPS is organized as follows. Chapter 2
describes the activities of IT security development. Chapter
3 addresses the form and content of protection profiles.
Chapters 4, 5, and 6 provide detailed functional, development
assurance, and evaluation assurance component requirements
for use in constructing protection profiles. Chapter 7 is a
guide to constructing protection profiles using the component
requirements of Chapters 4 through 6. Several appendices
provide additional supporting guidance.
This standard is part of a series of FIPS publications.
Subsequent documents will be published as a Registry of
Profiles representing profiles that have been developed,
analyzed, and registered in accordance with this standard.
Additional profiles will be added to the registry as consumer
needs change and technology advances. Supporting guidelines
for the standard will be published as part of this FIPS series
or as other Federal agency publications.
Chapter 2.
IT SECURITY DEVELOPMENT
2.1 Overview
IT security development consists of three separate but related
activities that begin with consumer specification of
requirements for IT product security and end with installed
IT systems incorporating products that have been approved to
operate in a particular environment. The following list
describes these activities, shown in Figure 1:
a. Profile Development and Analysis. IT product security
requirements are specified in a structured format; analyzed
for completeness, consistency, and technical correctness;
and accepted into a registry of profiles.
b. Product Development and Evaluation. IT products are
developed (or may already exist) in response to a profile
and independently assessed to produce a rating regarding
the product's conformance to a profile's specific security
requirements.
c. System Development and Certification. One or more IT
products are combined into an IT system that has been
determined, from a security point of view, to be acceptable
for use in a specific environment and accredited for
operation.
This standard addresses the first of the three activities of
IT security development, (i.e., profile development and
analysis). Product development and evaluation as well as
system development and certification are beyond the scope of
this standard. Sections 2.4 and 2.5 briefly discuss these
activities to establish their relationship to profile
development.
In many cases, consumers will accept IT systems that contain
unevaluated IT products, thus bypassing two of the activities
of IT security development. This situation, however, places
more demands on the system development process and the final
certification and accreditation processes.
2.2 Functions and Assurance
This standard focuses on IT products that can potentially be
used in many diverse environments. These products are required
to support various organizational security policies and
address a diverse set of security requirements by providing
selected IT security features or services. Collectively,
these security features or services are known as protection
functions.
Specifying requirements for protection functions is a
necessary but insufficient way to ensure consumer confidence
that the resulting IT product will provide a viable solution
to a protection problem. It is also necessary to consider the
extent to which the protection functions can be relied upon.
Are the functions appropriate to counter the threats? Are the
functions sufficiently strong to counter the threats? Are the
functions implemented soundly? Are there any threats not
countered by the functions? The extent of this reliance is
known as assurance. Assurance is the basis for consumer
confidence or trust that an IT product is suitable, with
respect to security, for its intended use.
Three sources of IT product assurance have been identified:
protection functions built into the product, characteristics
of how the product was designed and developed, and results of
the independent examination of the product. These three
aspects of IT product assurance (i.e., what it contains, how
it was designed and developed, and how it was evaluated) are
related. The evaluation activity examines the results of the
IT product design, development, and implementation. Assurance
requirements vary in accordance with organizational security
policies, expected environment, and intended use of the IT
product. Producers, consumers, and evaluators of IT product
security perform different activities to obtain the requisite
assurance.
2.3 Profile Development and Analysis
During profile development and analysis, consumers and/or
producers define requirements for IT product security in a
unifying structure called a protection profile. A protection
profile contains IT product requirements for protection
functions, development assurance, and evaluation assurance.
These requirements can be framed in the context of a rationale
statement, which provides the overall justification for the
protection profile.
Acceptance of a newly developed protection profile requires
that the profile be carefully scrutinized for its usefulness,
both in content and form. It must also be analyzed for
completeness, consistency, and technical correctness.
Therefore, achieving profile acceptance will often require
iteration as the initial profile is refined. Profile revision
and analysis continues until an acceptable profile results.
The profile can then be entered into a registry as basis for
both product development and evaluation.
Some new profiles will have broad usefulness to the U.S.
Government. These profiles are candidates to become Federal
Information Processing Standards (FIPS). In these cases, the
public FIPS development and approval process will encompass
the profile analysis and registry mechanisms. For such
profiles, NIST and NSA, with security professionals from the
public and private sectors, will make use of invitational
workshops and public review to provide the quality control and
technical oversight that manages the proliferation of
protection profiles. Chapter 3 provides additional detail
that must be addressed during profile analysis, including
profiles that are in the process of becoming FIPS. However,
the specific details of that process are beyond the scope of
this standard.
Editor's Note: Although the process of profile
development and analysis is not fully mature, the
final version of the Federal Criteria will success-
fully answer questions such as the following: Will
all profiles be subjected to the same level of anal-
ysis? What methods of analysis and tools might be
employed? Will profiles be subject to modification?
How will new profiles be handled if they closely
resemble existing profiles in the registry? Who
will pay for profile analysis?
2.4 Product Development and Evaluation
During product development and evaluation, a producer will
incorporate protection functions into an IT product based on
the requirements of a protection profile selected from the
pool of registered profiles. Alternatively, a producer, who
has identified a market for an IT product unrelated to one of
the existing profiles, can undertake profile development and
analysis.
The requirements in a protection profile should be product
independent since many potential IT products may be able to
satisfy the requirements of a particular profile. The
comprehensive product description that explains how a
specific IT product meets the requirements of a given
protection profile is known as a security target. The security
target is a specification and elaboration of the more general
requirements in a protection profile and is, by definition,
product dependent. The security target is the primary means
of communicating specific product development information
(evidence) to independent evaluators or to consumers. The
development of product-specific security targets is beyond
the scope of this standard.
Subsequent to development, an independent evaluation of an IT
product may occur to produce a rating with respect to the
product's conformance to the specific security requirements
outlined in the protection profile. IT product evaluations may
be accomplished by one of several evaluation authorities, just
as profiles may be implemented by more than one producer.
Consequently, specific details regarding evaluation processes
are beyond the scope of this standard.
2.5 System Development and Certification
During system development and certification, IT products
typically will be combined with other IT products into system
configurations of varying degrees of complexity. The IT
products used during system development may or may not have
been formally evaluated. The completed IT systems will be
subsequently employed in specific operational environments.
An IT system must undergo an assessment and receive management
approval prior to becoming operational. The assessment and
management approval processes are known as system
certification and accreditation, respectively.
IT system certification is conducted in support of the
accreditation process. The extent to which a particular IT
system meets a set of security requirements for its mission
and operational environment is established by the
comprehensive assessment of its internal and external
security controls. In the Federal Government, a Designated
Approving Authority (DAA) receives the resulting
documentation to support the accreditation decision. In the
private sector, this information might be provided to an
equivalent designated management authority (e.g., corporate
executive officer, department head, or division manager).
IT system accreditation is the official management decision
to operate an IT system. The accreditation normally grants
approval for the IT system to operate (1) in a particular
security configuration, (2) with a prescribed set of
countermeasures (administrative, physical, personnel,
communications, emissions, and IT product internal security
controls), (3) against a defined threat with stated
vulnerabilities, (4) in a given operational context, (5) with
stated interconnections to other systems, (6) at an acceptable
level of risk for which the accrediting authority has formally
assumed responsibility, and (7) for a specified period of
time. The DAA formally accepts responsibility for the secure
operation of the system and officially declares that a
specified IT system will adequately protect against the
identified threats through the continuous use of
countermeasures. The accreditation decision affixes this
responsibility with the DAA and shows that due care has been
taken for security in accordance with applicable
organizational security policies.
Chapter 3.
PROTECTION PROFILES
3.1 Overview
A protection profile is an abstract specification of the
security aspects of a needed IT product. It is product
independent, describing a range of products that could meet
this same need. Required protection functions and assurances
must be bound together in a protection profile, with a
rationale describing the anticipated threats and intended
method of use. The protection profile specifies requirements
for the design, implementation, and use of IT products.
Protection profiles can be assembled from pre-specified or
unique functional and assurance components. A functional
component is a set of rated requirements for protection
functions to be implemented in an IT product (see Chapter 4).
An assurance component is a set of rated requirements for
development and evaluation activities conducted by producers
and evaluators during construction and independent assessment
of an IT product (see Chapters 5 and 6). For convenience,
groups of functional and assurance components can be assembled
into predefined packages (see Appendixes A and B). During
construction of the protection profile, additional
dependencies must be considered between functions and
assurances (see Chapter 7).
3.2 Sources of Protection Profiles
Consumers or producers within the Government or the private
sector develop protection profiles in response to a specific
need for information protection. Profile developers, or
sponsors, with a unique security need could propose a
protection profile for that need or, more typically, groups
of sponsors having similar needs could combine to propose one
profile that meets their common need. Multiple sponsors
supporting a single profile is an effective way to demonstrate
a larger market to potential IT product producers.
Unique protection profiles reflect the needs of diverse sets
of sponsors. For example, a banker's association might propose
a protection profile for secure electronic funds transfer, or
the Department of Defense might propose a protection profile
for military applications. A single protection may also apply
to many IT products, showing the diversity of potential
solutions for the requirements outlined in the profile.
A producer who identifies a market for IT product security can
also propose a profile to give consumers a means of referring
to a specific set of needs and to facilitate future evaluation
against those needs. The protection profile is intended to
respond to both the pull of consumer needs and to the push of
advancing technology. Ultimately, the protection profile is a
common reference among consumers, producers, and evaluators.
3.3 Protection Profile Contents
A protection profile contains five sections: descriptive
elements, rationale, functional requirements, development
assurance requirements, and evaluation assurance
requirements. The Descriptive Elements section provides
categorical and descriptive information necessary to
identify, categorize, register, and cross-reference a
protection profile in a registry of profiles. The narrative
description is a brief characterization of the profile,
including a description of the information protection problem
to be solved. This section applies to all potential users of
the profile to determine whether or not the profile is
applicable to a consumer's information protection needs.
The Rationale section provides the fundamental justification
for a protection profile, including threat, environment, and
usage assumptions. It also presents a more detailed
characterization of the protection problem to be solved by an
IT product meeting the requirements of the profile. This
section describes the protection problem in sufficient detail
for producers to understand the range of potential solutions
to the problem. It also provides information to consumers
regarding how IT products that successfully solve this problem
can be used to support an organization's security policy.
The Functional Requirements section establishes the
information protection boundary that must be provided by an
IT product. Expected threats to information within this
boundary must be countered by functions inside the protection
boundary. The more robust the expected threats, the greater
the required strength of the protection functions. The IT
product protection functions support an organization's
security policy when coupled with certain assumptions about
the product's intended use and anticipated operational
environment.
The Development Assurance Requirements section covers all
phases of an IT product's development, from the initial
product design through implementation. Specifically, the
development assurance requirements include the development
process, development environment, and operational support
requirements. In addition, since many assurance requirements
are not readily testable, it is necessary to study IT product
development evidence or documentation to verify that
requirements have been met. Development evidence requirements
are included in a protection profile to ensure that the producer
generates and retains appropriate documentation during product
development for subsequent analysis during evaluation and product
maintenance.
The Evaluation Assurance Requirements section specifies the type
and intensity of evaluation to be performed on an IT product
developed in response to a particular protection profile. In
general, for an IT product, the scope and intensity of evaluation
vary with the expected threat, intended method of use, and assumed
environment as defined by the profile developer in the rationale
section. Table 1 summarizes the contents of a protection profile.
Table 1. Protection Profile Structure
.-------------------------------------------------------------------------.
| Descriptive | Provides categorical and descriptive information |
| Elements | necessary to uniquely identify, register, and cross- |
| | reference a protection profile in a registery of |
| | profiles. Includes a description of the information |
| | protection problem to be solved. |
|--------------+----------------------------------------------------------|
| Rationale | Provides the fundamental justification for a protection |
| | profile, to include threat, environment, and usage |
| | assumptions. Addresses support for organization security |
| | policies. |
|--------------+----------------------------------------------------------|
| Functional | Establishes the boundary of responsibility for inform- |
| Requirements | ation protection that must be provided by an IT product, |
| | such that expected threats to information within this |
| | boundary are countered. |
|--------------+----------------------------------------------------------|
| Development | Specifies assurance requirements for all phases of an IT |
| Assurance | product's development from initial product design through|
| Requirements | implementation. Includes the development process, the |
| | development environment, operational support, and |
| | development evidence. |
|--------------+----------------------------------------------------------|
| Evaluation | Specifies assurance requirements for the kind and |
| Assurance | intensity of evaluation to be performed on an IT product |
| Requirements | developed in response to a protection profile in accord- |
| | ance with the expected threat, intended method of use, |
| | and assumed environment. |
`-------------------------------------------------------------------------'
3.4 Protection Profile Development
The requirements for protection functions, development assurance,
and evaluation assurance must be incorporated into a protection
profile. These requirements, specified by the rated functional and
assurance components, provide the basic building blocks for the
definition of a protection profile. The components must be
assembled into a consistent and coherent set that satisfies
specific security goals of the anticipated environments of product
use. The assembled components should counter expected threats,
eliminate vulnerabilities, support security policies, and satisfy
regulatory requirements defined in the anticipated environments of
use.
Figure 2 shows that protection profile development consists of two
stages: (1) an environment security analysis and (2) a component
requirement synthesis. The environment security analysis addresses
the identification of security requirements and provides
information necessary for the development of the profile rationale.
The component requirement synthesis addresses the selection of
appropriate functional and assurance components for the profile.
Developing a protection profile requires analysis of dependencies
among the functional components, among assurance components,
and between functional and assurance components (see Chapter
7).
3.4.1 Environment Security Analysis
During the environment security analysis stage, the sponsor
(i.e., profile developer) derives a set of environment-
specific security requirements based on expected threats and
vulnerabilities; intended method of IT product use;
environment assumptions; and policies, standards,
regulations, or directives (if any). Although these
requirements can be considered environment-specific, they
derive from several potential environments of product use, and
they capture the common security characteristics of those
environments. The result of the security analysis, the
environment-specific requirements, must characterize the
environments of use in a demonstrable way.
The selection of environment-specific security requirements
must be based on effectiveness of the security functions. The
sponsor must show that the requirements in the protection
profile satisfy the security objectives by countering the
expected threats and eliminating the anticipated
vulnerabilities. The effectiveness of the environment-
specific requirements is a primary justification that must be
provided in the profile rationale and an important
consideration in the acceptance of a profile. Other
considerations, such as the utility and relevance of the
anticipated environments of use, also apply to the profile
analysis.
3.4.1.1 Expected Threats
A threat is a classification of the capabilities, intentions,
and attack methods of adversaries to exploit (or any
circumstance or event with the potential to cause harm to)
information or an information system. Harm to information or
information systems due to threats may result because of
absence or failure of functional controls. The consequences
of threats may vary.
As suggested by Figure 3, the analysis of expected threats
starts at the boundary of the IT product's assumed
environment. The scope of the analysis continues inward
through the product's protection boundary to its protected
information resources. One result of the analysis is the
development of generic threat categories. These categories
can be ordered according to risk (probability of occurrence)
and level of severity. Appendix A provides a brief synopsis
of common threats to information technology.
3.4.1.2 Intended Method of Use and Environment
A protection profile must contain assumptions about the way
the product will be used and the environment in which it will
be placed. Assumptions should highlight significant
constraints. For example, in some environments, routine
product maintenance would be infeasible. These assumptions
will enable the profile's users to understand the significance
of the information being processed, the users and
administrators involved in the information processing, the
type of information processing, and the protection for the
processing environment and its relationship to the users.
Sample rationales might include the following:
Example 1: This IT product generally will be used to process
concurrent multiple levels of disclosure-sensitive and/or
manipulation-sensitive information (i.e., national security
information and/or information subject to organization
internal controls and external regulation). In the assumed
environment, sensitivity markings indicate the IT security
controls that must be applied to protect the information.
These sensitivity markings may be associated with objects that
range in size from data elements to files.
Example 2: The users and administrators have access to
multiple levels and types of information and processing
resources. Access authorization is based on attributes, such
as duties within roles, determination of need to know, trust
indicators (such as individual clearances or job
descriptions) and entry constraints (such as time, location,
terminal, and port).
Example 3: Information is processed on centralized general-
purpose shared computing resources allowing for both
interactive and batch processing. The operational mode is
concurrent multilevel processing. The user interface is
generally expected to be window-based. Use of a database
management system is anticipated. The database management
system need not be a part of the product offering, but a
description of how to integrate the database security
interface must be provided.
Example 4: The processing resources of the IT product,
including all terminations, will be located within user spaces
that have physical access controls. A restricted access
environment with unarmed guards should be assumed. The
possibility of the environment becoming hostile should be
considered (e.g., a U.S. Embassy in a foreign country).
Networking may be anticipated, but is not required as part of
the IT product offering.
3.4.2 Component Requirement Synthesis
During the second stage of protection profile development, the
environment-specific security requirements must be used in
conjunction with well-defined profile requirement
construction rules to select and tailor the generic functional
and assurance components provided in Chapters 4 through 6 of
this standard. The resulting profile specifies the protection
policy that must be supported within the IT product.
Not all environment-specific security requirements apply to
the selection of the functional and assurance components. The
environment-specific security requirements referred to in
this section are those requirements that may be used to select
functional and assurance components to be incorporated in a
protection profile.
The selection of components also involves dependencies among
components. Dependencies among functional components drive
the selection of the functional components. Dependencies
between functional and assurance components, and within the
assurance components affect assurance component selection.
Chapter 7 cites specific information on the techniques for
constructing protection profiles and the dependency
considerations between functional and assurance components.
3.5 Protection Profile Analysis
After a protection profile has been developed by a sponsor,
it must be analyzed. Protection profile analysis ensures that
the profile has the following characteristics: technical
soundness, usefulness, evaluation capability, distinctness,
and consistency.
The rationale section supports the profile analysis conducted
to assess whether the vulnerabilities constituting a
protection problem are adequately countered by the profile's
proposed protection functions and assurances. The profile
analysis determines that the risks identified in the
protection problem have been reduced to an acceptable level.
Profile analysis is important; many products may be created
in response to a protection profile.
As described in the following sections, the goals of
protection profile analysis are to ensure the following
characteristics:
a. Technical soundness. The elements of a protection profile
are technically sound and reasonably balanced, considering
the profile rationale (threat, usage, and environment
assumptions), and the functional and assurance
requirements.
b. Usefulness. IT products built to meet the requirements of
a protection profile will serve a useful purpose.
c. Evaluation capability. Implementation of a protection
profile's requirements can be evaluated. Consumers,
evaluators, and producers will understand how to determine
that the profile requirements have been met by a specific
IT product.
d. Distinctness. The protection profile is distinct, in that
it does not duplicate a need adequately described by
another profile.
e. Consistency. The protection profile is consistent with
other profiles in form and level of detail.
3.5.1 Technical Soundness
Determining technical soundness is a crucial part of the
analysis of a protection profile. The following three major
characteristics should be considered:
a. Strength or appropriateness of protection functions and
assurances. This characteristic is a judgment made by
comparing the profile rationale (threat, usage, environment
assumptions, and security policy) with the required
protection functions and assurances. It must be determined
that if the IT product is used as recommended, each stated
threat will be successfully addressed through the
prescribed combination of functional and assurance
requirements, taking into account assumptions about the
environment.
b. Internal consistency of profile requirements. This
characteristic is a judgment based on an overall analysis
of the protection profile to determine that the degree of
required protection functions is commensurate with the
degree of required assurance.
c. Requirement dependencies. This characteristic involves
dependencies that may exist among requirements and whether
any dependencies have not been considered in the
development of the protection profile. These dependencies
can be functional-functional, assurance-assurance, or
functional-assurance. Dependency analysis must be complete
and consistent.
Questions to be answered during the technical soundness
analysis might include the following: Are the functional
requirements sufficient to counter the expected threats? Are
any threats not countered adequately addressed in
environmental and/or other assumptions outside the domain of
the IT product? Is the degree of assurance compatible with the
threat expected and with the level of protection functions
required? Have all stated dependencies been addressed? Have
any dependencies been omitted? Are there inconsistencies in
protection functions resulting from an examination of
dependencies?
3.5.2 Usefulness
A management decision is necessary to commit the resources for
conducting a profile analysis. Consumers and producers may
determine the usefulness of a profile based on different
criteria. Determining the profitability of a market is clearly
a producer's responsibility. The protection profile analysis
is not intended to interfere with the producer's business
decisions. Usefulness analysis relies primarily on the
rationale section of the profile to express the need with
respect to threat, usage and environment assumptions.
The analysis also includes an assessment of development
feasibility. Protection profiles requiring research and
development efforts should be identified so that the profiles
will not raise expectations for near-term implementations.
Questions to be answered during the usefulness analysis might
include the following: Does this protection profile address a
real problem? Does this protection profile differ
significantly from existing profiles, or could the needs
described in this profile be met adequately by another
existing profile? If the demand is too small to support
commercial off-the-shelf products, what factors could induce
producers to develop products for a niche market?
Approximately how large is the demand for these products? Is
the protection profile readily implementable? Is the state of
technology sufficiently developed or is basic or applied
research and development necessary?
3.5.3 Evaluation Capability
The protection profile requirements must be reviewed to ensure
that IT products intended to satisfy the requirements in the
protection profile are capable of being evaluated. A
protection profile may be used as the basis for product
development. The evaluation capability analysis of the
profile can pay off by clearly defining what is expected
during the evaluation process. As far as possible,
requirements in the protection profile should be stated in
objective terms so the producer and the evaluator will be more
likely to agree on their interpretation of the requirements.
If certain requirements must be stated in subjective terms,
clear and explicit guidelines should be presented to explain
what factors should be considered to determine whether the
requirements have been met. Requirements should be simple,
declarative statements and for ease of reference,
requirements should be numbered or otherwise indexed. These
features will help to ensure that requirements will not be
overlooked, either during product design and development or
during evaluation.
Questions to be answered during the evaluation capability
analysis might include the following: Is the purpose or
objective of each requirement clear? What does each
requirement contribute to the overall IT product security? Is
the phrasing of each requirement clear and concise? Are the
criteria for success for each requirement self-evident or
explicitly provided? Is there a means by which it can be shown
that each protection requirement has been established in the
producer's IT product? Is each requirement objective? If a
requirement is subjective, is it accompanied by objective
factors to be considered when determining if the requirement
has been met?
3.5.4 Distinctness
A new protection profile is compared with existing profiles
to determine that it meets a unique need and that the
requirements of no other existing profile address that same
need. A protection profile, once registered, is not intended
to be changed (except for editorial changes that would not
affect any producers currently developing products to meet
that profile specification). This constraint is intended to
preserve a relatively stable and manageable set of
requirements. New needs must be met by new profiles. Similar
protection profiles are cross-referenced.
Questions to be answered during distinctness analysis might
include the following: Do the presumed threats described in
this profile very closely resemble those of any other existing
profile? If yes, is there a significant difference between the
two profiles? Do the required protection functions very
closely resemble those of any other existing profile? If yes,
does a significant difference exist between the two profiles?
Do the functional requirements and rationale sections of the
protection profile resemble another protection profile with
different assurance requirements? If yes, can assurance
requirements of the other profiles be changed?
3.5.5 Consistency
Protection profiles must be consistent with one another in
form and level of detail. This review analyzes the profile to
ensure that the properties associated with accepted
protection profiles are present. A clear and convincing case
must be made for allowing protection profiles whose form must
differ from the norm.
Questions to be answered during consistency analysis might
include the following: Is the protection profile complete? Are
the objectives and expected threats discussed reasonably
complete for the expected environments and intended method of
use? Can the threats be shown to be mitigated by attributes
of the IT product or its environment? Is the protection
profile internally consistent in its level of protection? Are
the form and degree of detail of the protection profile
consistent with the form and degree of detail of other
profiles?
3.6 Protection Profile Registration
To provide a relatively stable environment, a profile is
intended never to be changed once it is registered. However,
evaluation experience may identify errors and ambiguities
that need to be corrected. New information protection
requirements will be addressed by the development of new
profiles.
Protection profiles that have completed analysis will be
registered. Producers can select profiles for IT product
implementation. The profiles in the public registry can also
serve as templates for the development of new profiles.
Editor's Note: The specific details of profile reg-
istration are currently under development and have
not been completed. It is envisioned that the pro-
file registry could contain three independent reg-
istration types: (1) the complete protection
profiles, (2) functional packages, and (3) assur-
ance packages. Packages would identify any associ-
ated dependencies. The registration bodies that
approve the inclusion of new protection profiles
would also approve the registry of new packages for
protection functions and assurance.
Chapter 4.
FUNCTIONAL REQUIREMENTS
4.1 Overview
The functional requirements presented in this chapter enable the
definition of different protection profiles that can be used in
different environments of IT product use and address different
threats. These requirements allow protection profile extension and
refinement, which may become necessary as technology changes and as
experience is gained. They also enable the harmonization of this
standard with existing standards, such as the Canadian Trusted
Computer Product Evaluation Criteria (CTCPEC), the Information
Technology Security Evaluation Criteria (ITSEC), and the Trusted
Computer System Evaluation Criteria (TCSEC). Thus, these requirements
allow the definition of protection profiles that closely capture the
functional characteristics of IT products evaluated under the existing
standards.
The functional requirements defined in this chapter are grouped into
components of trusted computing bases (TCBs). The TCB is the totality
of an IT product's elements, comprising the hardware, firmware, and
software code and data structures responsible for enforcing the
product's protection functions. Thus, a functional component is a set
of requirements levied on either (1) one or more TCB functions that
can be invoked through the TCB interface (e.g., system call,
supervisor call) or (2) one or more internal modules or sections of
code and data structures of a TCB function.
The functional components defined in this standard are based on the
premise that the TCB is the only part of the product that needs to be
analyzed and evaluated to determine the protection characteristics of
a product. For this reason, this standard need not define more than
the desirable sets of functional components for TCBs. Since different
functions of a TCB help counter different threats, the analysis of the
TCB protection must identify the set of components that collectively
helps counter a specified set of threats. To make a protection profile
generally applicable to a wide set of products, the desirable
components included in a protection profile must be specified in a
product-independent manner, in terms of generic protection
requirements, rather than by specific mechanisms that may vary from
product to product. The threats countered by the TCB functional
components also must be defined in generic terms rather than by
specific threat instances that may vary from environment to
environment.
The functional components presented in this standard are derived from
existing security criteria and requirements of commercial and
non-commercial environments. To address a wide variety of protection
needs, each functional component is rated based on a set of
well-defined parameters. This rating is intended to capture the
desirable variations in the protection merits of component
requirements. This rating can also help clarify the relationships
between these requirements and those of existing standards.
This chapter is divided into four sections. The remainder of this
section groups the functional components of a TCB into eight classes
and describes the types of components in each class. The second
section presents a description of each type of functional component in
terms of the generic threats and vulnerabilities these components are
intended to counter or eliminate. The third section presents the rated
functional components. The last section includes a bibliography of
useful literature references. (Appendix B presents the reference
monitor concept and its role in product security, and Appendix C
presents the components required in defining an access control
policy.)
Classes of TCB Functions: Eight classes of TCB functions and
associated components with distinct protection requirements are
identified in the Taxonomy of TCB Functions (Figure 4). These classes
are: (1) security policy support, (2) reference mediation, (3) TCB
logical protection, (4) TCB physical protection, (5) TCB
self-checking, (6) TCB start-up and recovery, (7) TCB privileged
operation, and (8) TCB ease-of- use. It is important to note that all
but the first class of the components listed above are sometimes
considered to be operational assurances. However, a different point of
view is taken in this standard for two reasons. First, if a protection
relevant component requires that specific software, hardware, or
firmware elements (i.e., code, data structures) be part of the TCB,
then that component implements a necessary protection function, even
if it only indirectly contributes to the overall protection of the
product. Second, functional components actively help counter TCB
external threats or eliminate vulnerabilities, whereas assurance
components do not. Instead, the assurance components help identify and
eliminate potential vulnerabilities caused by errors of omission, or
commission, in TCB development, life cycle maintenance, and operation.
Therefore, the items in component classes two through eight are
categorized as functional components instead of operational
assurances.
Security Policy Support. This class of components defines four
functional components for basic security policy support at the
interfaces of typical TCBs: (1) accountability policy components,
which include the functional components of identification and
authentication (I&A), system entry control, trusted path, and audit,
(2) an access control policy component, (3) availability policy
components, which include resource allocation and fault tolerance
components, and (4) security management components. The degree to
which a product's TCB must implement the requirements of these
functional components depends upon the threat environment assumed and
the product's security objectives. Furthermore, the ability of a
product's TCB to correctly support a set of organizational security
policies depends jointly on (1) the product policies implemented by
the TCB functions (e.g., these policies must be consistent with those
of the organization), (2) the correct operation and input by system
administrative personnel (e.g., system start-up or recovery must be
performed properly; the user registration and the system entry
parameters must be set properly), and (3) the actions of the
unprivileged users themselves (e.g., choice of passwords, setting of
an object's default access rights, distribution of access rights).
Reference Mediation. The requirements of this component ensure that
all references issued by subjects external to the TCB (i.e.,
unprivileged subjects) to objects, resources, and services of a
product are validated by the TCB in accordance with the security
policies of the product. Satisfying the requirements of this component
establishes complete reference mediation (i.e., a reference of a
subject external to the TCB cannot circumvent the security policies of
the TCB).
TCB Logical Protection. The requirements of this component ensure that
at least one domain is available for the TCB's own execution, and that
the TCB is protected from external interference and tampering (e.g.,
by modification of TCB code or data structures) by unprivileged
subjects. Satisfying the requirements of this component makes the TCB
self-protecting. Therefore, an unprivileged subject cannot modify or
damage the TCB.
Note that the reference mediation and the TCB logical protection
components include the first two requirements of the reference
validation mechanism (see Appendix B). These two components, as well
as the security policy support, are necessary for all protection
profiles. The strong dependency of these two components on the
development assurance components is defined by the third requirement
of the reference validation mechanism (see Chapter 7; Appendix B).
TCB Physical Protection. The requirements of this component ensure
that the TCB is either protected from physical tampering and
interference or operates in a protected environment. Satisfying the
requirements of this component causes the TCB to be packaged and used
in such a manner that (1) physical tampering is detectable, or (2)
resistance to physical tampering is measurable based on defined work
factors. Without this component, the protection functions of a TCB
lose their effectiveness in environments where physical damage cannot
be prevented.
TCB Self-Checking. The requirements of this component ensure that
hardware, firmware, or software are available to validate the correct
operation of the TCB and the consistency of the TCB's protection data
structures. Satisfying the requirements of this component allows the
TCB to (1) detect corruption of protection-relevant code and data
structures resulting from various mechanism failures and (2) initiate
corrective action. This component is important because, unlike TCB
protection, corruption of protection-relevant code and data structures
resulting from mechanism failures can only be detected, not prevented.
TCB Start-Up and Recovery. The requirements of this component ensure
that the TCB can determine that the IT product is started without
protection compromise and can recover without protection compromise
after a detected failure or other discontinuity. Satisfying the
requirements of this component establishes that the initial and
recovered states of a TCB satisfy the security policy, reference
mediation, and TCB protection requirements. This component is
important because the start-up TCB state determines the protection of
subsequent states, and once the corruption of a protection-relevant
data structure by a failure is detected, TCB recovery action becomes
necessary.
TCB Privileged Operation. The requirements of this component ensure
that TCB functions operate with the fewest privileges necessary to
accomplish their purpose. Satisfying the requirements of this
component causes identification of system privileges required by each
TCB function and the addition of mechanisms that associate these
privileges with specific TCB functions, modules, or actions. This
component is important because it helps restrict the propagation of
errors and failures.
TCB Ease-of-Use. The requirements of this component enable the use of
the TCB by users, administrators, and their applications. Satisfying
the requirements of this component provides (1) fail-safe defaults
(i.e., defaults that deny access whenever a user or administrator
fails to specify access to subjects and objects), (2) user-defined
defaults, (3) well-defined interface conventions, (4) the users'
ability to reduce their own privileges, and (5) subject, object,
resource, and service protection in common configurations. Without
this component, the protection value of the TCB functions is
diminished since few users and applications would be able to employ
these functions effectively.
4.2 TCB Functional Components
The TCB functional components are presented in terms of the generic
threats and vulnerabilities they are intended to counter or eliminate.
Most protection profiles for IT products based on operating systems
will include most of the functional components presented in the
following subsections. Protection profiles for other types of IT
products may include only some of these components depending upon the
product's purpose.
4.2.1 Security Policy Support
The focus of information protection within an IT product is to support
an organization's security policies. This section describes TCB
functions and associated components (i.e., accountability, access
control, availability, and security management) that help support
organizational security policies. The generic functional components
have been written to be policy neutral (i.e., they are capable of
supporting a wide variety of protection policies). Specific product
policies or types of product policies (e.g., policies derived from the
DoD policy for confidentiality, a hospital's policy for privacy and
integrity of patient records, or a phone company's policy for
availability) can be defined by assigning a specific meaning to, or
refining the generic, policy neutral components. Details of profile
construction and synthesis of profile components from generic
components are provided in Chapter 7.
4.2.1.1 Accountability Policy
An IT product that supports accountability policies must include
functions capable of attributing responsibility for an action to an
accountable entity (i.e., the identified and authenticated individual
whose policy attributes may include name, role, group, and/or security
level). Accountability requirements may be satisfied in a product
through the use of the following functional components. Identification
and authentication components establish the authenticity of the
claimed identity by the user. System entry components provide the
appropriate time, location, and mode-of-entry context for the user's
interactions. Trusted path components ensure that nothing can
interfere with the interactions between the TCB and the authenticated
user. Audit components ensure that user interactions are recorded and
attributed to the accountable user identity. Each of these components
is discussed in more detail in the following subsections.
4.2.1.1.1 Identification & Authentication (I&A)
I&A components specify functional requirements for the TCB to verify
the claimed identity of individuals attempting system entry.
Identification and authentication is required to ensure that the
authenticated users are associated with the proper set of policy
attributes (e.g., identity, groups, roles, security or integrity
levels, time intervals, location). Thus, identification and
authentication enables the TCB to ensure that all individuals entering
a system and accessing its subjects, objects, and services are
authorized to do so by the system entry and TCB's protection policy,
and that the accountability policy can be enforced. In operating
systems, the I&A functions constitute the main part of the process
commonly known as "login," with the balance of the process consisting
of system entry and trusted path functions.
4.2.1.1.2 System Entry
The system entry components specify functional requirements for the
control of an identified and authenticated user's entry into the
system. The user's entry into the system typically consists of the
creation of one or more subjects that execute instructions in the
system on behalf of the user. At the end of the system entry
procedure, provided the system entry conditions are satisfied, the
created subjects bear the policy attributes determined by the I&A
functions. System entry conditions can be specified in terms of policy
attributes such as the user's identity, group or role membership,
confidentiality and integrity levels, time intervals, location, and
mode of access.
The system entry procedure may include warnings about unauthorized
attempts to gain access to the system. It may also display last login
data to the user, so that the user can determine whether the previous
successful login was performed by the user and not by an intruder who
successfully broke the user's password, for instance. The system entry
procedure may enable the control of (1) multiple simultaneous user
logins, (2) locking an interactive session during periods of user
inactivity, (3) time intervals during authorized user access, and (4)
location or port of user entry.
System entry control can help counter threats of inadvertent,
deliberate, or coerced access performed in an unauthorized manner by
an authenticated user. For example, the location and time of system
entry can be constrained in such a way that identified and
authenticated users located in areas of high exposure (e.g., public
areas) cannot display sensitive data, enter high-integrity commands,
or operate outside working hours. Similarly, controlling the mode of
system entry helps ensure that identified and authenticated users
cannot remotely start batch computations that would normally require
the user's attendance.
4.2.1.1.3 Trusted Path
Trusted path components specify functional requirements for ensuring
that users have direct, unencumbered communication with the TCB. A
trusted path may be required at login time and at other times during a
subject session. These trusted path exchanges may be initiated by a
user during a TCB interaction. However, a TCB or a trusted
application request for user input should also allow a user to
initiate and respond via the trusted path. A user's response via the
trusted path guarantees that untrusted applications cannot intercept
and/ or modify the user's response.
The threats countered by these components are unauthorized discovery
and/or modification of user-private information associated with
commands (e.g., login password, sensitivity of the user's actions),
and modification of commands and command parameters causing incorrect
user input to the TCB. Trusted path programs of the TCB may also be
invoked by trusted applications to ensure correct display of
information to the user. These programs may also allow the addition of
trusted application commands to the trusted path so that users could
communicate securely with these applications.
Absence of a trusted path may allow breaches of accountability in
environments where untrusted applications are used. These applications
can intercept user-private information, such as passwords, and use it
to impersonate other legitimate users. As a consequence,
responsibility for any system actions cannot be reliably assigned to
an accountable entity. Also, these applications could output erroneous
information on an unsuspecting user's display. Thus, subsequent user
actions may be erroneous and may lead to security breaches.
4.2.1.1.4 Audit
The audit components specify requirements for monitoring and, in some
cases, detecting real or potential violations of security policies in
organizations that use IT products containing audit functions. These
functions help monitor the use of access rights by authorized users,
and act as a deterrent against usage policy violations.
Auditing involves recognizing, recording, and analyzing user actions
that are considered, by audit administrators, to be critical to the
success of an organization's security policy. The resulting audit
records can be examined to determine which security-relevant user
actions took place and who was responsible for them. The audit
component requirements refer to the basic audit mechanisms, including
audit data protection, record format and event selection, as well as
to analysis tools, violation alarms, and real-time intrusion detection
systems, which use the basic mechanisms.
Recognition of auditable actions is based largely on administratively
supplied specifications of user actions and patterns of behavior whose
appropriateness is considered to be significant to the satisfaction of
an organization's security policy. The designers of an IT product must
either anticipate which actions and patterns are likely to be
considered important to organizations with respect to their security
policies, or provide an audit interface that allows trusted (and
possibly other) applications to recognize and pass audit data to the
TCB. Since the purpose of the audit mechanism is to audit user
actions, including administrative actions, designers of the audit
mechanism cannot uniformly assume that all authorized actions are
appropriate; consequently. some administrative actions must always be
audited.
The IT product must record each action that has been deemed auditable
along with accompanying information needed to un- derstand the
apparent purpose or effect of that action (e.g., user environment
variables, programs used to preprocess user input). Recorded audit
data must be protected by the TCB from inappropriate modification,
use, or destruction. To avoid re- pudiation, the mechanism by which
audit data is gathered must be known and reliable. Often this implies
the use of a trusted communications mechanism. At higher levels of
assurance, the auditing of key administrative actions should resist
all at- tacks by remote users and otherwise undetectable attacks by
users with access to the physical audit media (e.g., through the use
of write-once audit disks).
Finally, audit data must be available for analysis in a timely manner
and in a useful format, within policy constraints established for the
product. This requirement motivates the design of pre- and
post-processing software that organizes audit data into a presentable
format and/or delivers it to authorized users or processes acting on
their behalf.
4.2.1.2 Access Control Policy
The access control objectives of organizational security policies can
be divided into two classes, namely confidentiality and integrity.
These objectives determine whether the organization intends to prevent
unauthorized disclosure or unauthorized modification and destruction
of information. Often, organizational security policies include both
confidentiality and integrity objectives to varying degrees. These
policies reflect both security and system management goals that should
be satisfied by multiple IT products.
The extent to which an IT product's access control policy supports
high-level system and organizational security policy objectives varies
from product to product. Few commercial products are designed to
support a single specific organizational policy. Instead, commercial
products implement either low-level access control policies that can
be tailored to support high-level organizational policies or multiple
organizational policies that could be individually instantiated on a
system basis. For example, some products implement both the DoD
mandatory confidentiality policy (as modeled by Bell & LaPadula) and a
mandatory integrity policy (as modeled by Biba). When using such IT
products in environments where only the mandatory integrity policy
needs to be enforced, the DoD mandatory confidentiality policy could
be deconfigured (e.g., all authorization checks for DoD mandatory
confidentiality would pass and all options for displaying, or
requesting, confidentiality levels would be disabled). Similarly,
other organizational policies, such as the role-based access control
policies, could be configured in a product when the environment of
product use makes it necessary.
The access control policies in this section are IT product policies
implemented by TCB functional components and are distinguished from
the higher level system and organizational security policies, which
generally use product policies to help achieve the higher level
security objectives. Product access control policies are designed to
counter generic threats. These policies traditionally have been
classified as discretionary or non-discretionary, depending upon
whether the access control decisions regarding an object are primarily
based on actions of the unprivileged user and/or subject that created
the object or primarily based on administrative actions. Access
control policies of many products combine both discretionary and
non-discretionary policies to counter different types of threats and
eliminate various vulnerabilities.
4.2.1.2.1 Discretionary Access Control Policies
The generic threats addressed by discretionary access control policies
are those of unauthorized access, propagation or retention of access
rights to user's objects, and unauthorized creation or destruction of
subjects and objects. Discretionary access controls enable users and
applications to protect their objects from unauthorized access by
other users and applications. These controls are effective, provided
that malicious code is not introduced and used by a user or on behalf
of a user.
Discretionary access control policies cannot counter and are not
intended to address several generic threats and vulnerabilities such
as Trojan horse or virus propagation within a user application. This
is because these policies have traditionally imposed very few
restrictions on object sharing. Most commercially available IT
products that support only discretionary policies could not adequately
control or confine the actions of a Trojan horse or a virus within an
application. Furthermore, discretionary policies are not intended to
control the flow of information between a subject and/or object to
system variables that do not represent subjects and/or objects (e.g.,
internal variables of an operating system). Consequently, the use of
covert channels is a threat that cannot be countered by any
discretionary access control policy.
Discretionary access controls are also not intended to prevent
surrogate access to objects. As a typical example of surrogate access,
consider an object's owner who allows user A, but not user B, to read
the contents of one of the owner's objects. However, the object owner
cannot exercise any control over user A's discretion on how to use the
object contents. User A can transfer the contents of the owner's
object to user B in an authorized manner via the interprocess
communication facilities; or user A may simply copy the contents of
the owner's object into another object shared with user B. The object
owner cannot control user A's legitimate discretionary communications
with user B, and thus, the object owner cannot control the flow of
data to and from the object caused by user A on behalf of user B.
A range of discretionary policies have been used by various IT
products to satisfy different protection requirements. These policies
range from those where the owner (creator or controller) of an object
(and an application running on the owner's behalf) has complete
control over who can access that object to those where any possessor
of an access right to an object can freely distribute that access
right to, and subsequently revoke it from, other users and
applications.
Generic threats to access control not countered by discretionary
access controls are intended to be countered by non-discretionary
access controls. These non-discretionary access control policies are
discussed in the next section.
4.2.1.2.2 Non-Discretionary Access Control Policies
Non-discretionary access control policies are intended to counter
threats posed by malicious code (e.g., Trojan horses or virus codes)
within application programs, by surrogate subjects, and in general, to
counter both unauthorized access to objects and unauthorized flow of
information between subjects and objects, not just unauthorized
propagation of access rights. An IT product that provides
non-discretionary access control can confine the effects of malicious
code and the flow of information between subjects and objects as
specified by system administrators. In general, non- discretionary
controls are specified by security administrators and cannot be
changed over time by unprivileged subjects. Thus, the unprivileged
subject's discretion as to whether an object can be accessed is
limited by administrative controls. Also, an unprivileged user can
only exercise very limited access-control discretion. By selecting
certain policy attributes from the attribute sets defined by
administrators (e.g., role, session security level), the user selects
the access control attributes for subjects created for him/her to run
external to the TCB. Non-discretionary policies allow the basis for
determining whether a subject could have access to an object based
exclusively on the subject's and the object's non-discretionary policy
attributes. In this sense, non-discretionary access controls can
confine user and application program activity.
Unlike discretionary access controls, which typically do not offer
separate and explicit support for specific confidentiality and
integrity policies beyond distinguishing between attributes for
reading and writing objects, non- discretionary controls can
demonstrate support for high-level organizational policies. This is
due, in part, to the central (organizational) role played by system
administrators in the control of access authorization and object
sharing, as opposed to discretionary policies where individual object
creators, not system administrators, play this access authorization
and object-sharing-control role.
Various non-discretionary access control policies have been used in
different products. These policies range from the DoD mandatory
policies used to protect the confidentiality of classified documents
to separation of role and separation of duty policies intended to
protect the integrity of databases. Also, some products have a
capability to enforce both non- discretionary confidentiality and
integrity controls on the same or different sets of subjects and
objects.
Both non-discretionary confidentiality and integrity policies may, or
may not, adequately control the flow of information and the use of
covert channels. Not all non-discretionary policies are aimed at
controlling the use of covert channels. Should covert channels be
considered a threat, however, both non-discretionary confidentiality
and integrity policies require measures of covert channel handling.
These measures are discussed in the next section.
4.2.1.2.3 Covert Channel Handling
Covert-channel handling components include both technical requirements
(e.g., elimination, bandwidth reduction to acceptable levels,
deterrence of use by auditing covert storage channels), and
administrative or environmental requirements (e.g., exclusive use of
trusted software by trusted users in environments where all
unauthorized information flow must be prevented).
Covert-channel elimination requires that the design and/or
implementation of a system be changed so that covert channels are
removed from the product. These changes include (1) the elimination of
resource sharing between any subjects that could take part in covert
channel use by preallocating maximum resource demands to all such
subjects or by partitioning resources on a per-subject basis, and (2)
the elimination of interfaces, features, and mechanisms which can
cause covert leakage. Since covert-channel elimination may be
impractical for some channels, other handling functions may be useful
in a TCB (e.g., bandwidth limitation functions).
Covert-channel bandwidth limitation requires that the maximum, or
alternatively, the average bandwidth of any channel be reduced to a
limit deemed acceptable in the environment of product use. In
sensitive applications, bandwidth limitation may require that the
aggregated (i.e., combined) bandwidth of a product's covert channels
be reduced to an acceptable value. Bandwidths can be limited by (1)
deliberate introduction of noise in TCB functions used to exploit the
channels (e.g., use of random allocation algorithms for shared
resources such as indexes in shared tables, disk areas, and process
identifiers, or introduction of extraneous processes that modify
covert channel variables of a TCB in pseudo-random patterns), or (2)
deliberate introduction of delays in each TCB primitive of a real
channel.
Covert-channel auditing is a primary method used to discourage the use
of covert channels. This method assumes that the frequent use of a
channel can be unambiguously detected by audit mechanisms. Some covert
channels preclude the use of channel audit, elimination, and bandwidth
limitation methods. These channels typically include the timing
channels that arise from hardware-resource sharing (e.g., shared
busses, processor caches). Furthermore, in some environments, the
threat analysis may indicate that any use of covert channels cannot be
tolerated. However, in most commercial products it is impractical to
eliminate all covert channels. If such products are used in such
non-tolerant environments, the effect of covert-channel use must be
neutralized. This could be done by the exclusive use of trusted
product and application software. In such cases, evidence must be
provided to justify that the exclusive use of trusted application
software is sufficient to render the existing covert channels
ineffective.
4.2.1.3 Availability Policy
An IT product which supports availability policies must provide
protection functions capable of controlling the availability of the
product subjects, objects, resources, and services. Availability
components refer to policies for prevention, detection, and recovery
from unauthorized denial of service caused by unprivileged subjects.
These components also refer to the use of redundancy and recovery from
lack of availability caused by TCB failures. Because subjects and
objects are represented by, and consume, system resources such as
primary memory and disk space, CPU time, and shared TCB internal
tables and objects, the allocation of these resources must be
controlled to allow policy-ensured accesses to take place.
A product that controls the availability of subjects, objects, and
services may include TCB functions that prevent denial of service and
provide fault tolerance. The needed availability functions of a TCB
may include resource allocation containment and fault tolerant
services.
4.2.1.3.1 Resource Allocation
Resource allocation functions allow the TCB to control the use of
product resources by users and subjects such that denial of service
will not take place. Denial-of-service protection can be provided by
containing resource allocations in time and space, or by establishing
priority-based allocations.
Resource allocation rules may allow the creation of quotas or other
means of defining limits on the amount of resource space or time that
may be allocated on behalf of a specific user, process, or task. These
rules may provide for object quotas that constrain the number and/or
size of objects a specific user may allocate. Resource allocation
rules may control the allocation/deallocation of pre-assigned resource
blocks where these blocks are defined under the control of the TCB.
Under these rules, subjects and objects are assigned allocation
attributes so that the TCB can enforce appropriate quotas. Finally,
resource allocation rules may prioritize subject access to resources
so that subjects with the highest priorities are given preferential
access to these resources.
4.2.1.3.2 Fault Tolerance
TBD.
4.2.1.4 Security Management
The TCB of an IT product must support security management components
to enable administrative users to set up and control the secure
operation of the product. These components refer to TCB functions
associated with both administrator and operator roles, and have both
access control, audit, and availability relevance.
Security management components refer to the following types of
functions:
a. TCB generation, installation, configuration, and non- routine
maintenance (e.g., TCB manual recovery, installation of "patches"
correcting security flaws, repair of damaged TCB hardware and software
elements).
b. Definition and update of user security characteristics (e.g.,
unique identifiers associated with user names, user accounts, per-user
policy attributes, system entry parameters, availability parameters or
resource quotas).
c. Definition and update of security policy parameters (e.g.,
identification and authentication, system entry, access control, and
availability parameters).
d. Routine control and maintenance of product resources (e.g.,
enable and disable peripheral devices, mounting of removable storage
media, backup and recovery of user objects, and routine maintenance of
TCB hardware and software elements).
e. Auditing both privileged and unprivileged user actions, and
audit management (e.g., selection of audit events, management of audit
trails, audit trail analysis, and audit report generation).
The security management functions help counter the same threats as
those countered by the security policy functions (i.e.,
accountability, access control, and availability). This is the case
because the security management functions implement a significant part
of all the system security policies. In addition, when the security
management functions are partitioned into different administrative
roles, they help limit the potential damage caused by unskilled or
corrupt administrators.
4.2.2 Reference Mediation
Functions that implement a security policy provide effective
protection against unauthorized access only if all references (i.e.,
denoted by <action; object(s) > tuples) issued by subjects are
directed by the TCB code to the appropriate security policy modules
for validation. Should such references be incorrectly directed, or not
directed at all, to the required policy modules, policy enforcement
will be incorrect, incomplete, or absent, despite correct and complete
policy implementation. This would allow unprivileged subjects to
bypass security policy in a variety of unauthorized ways (e.g., bypass
certain access checks for a subset of the objects and subjects, bypass
all checks for a type of object whose protection was assumed by
applications, retain access rights beyond their intended expiration
time, and/or bypass audit).
Note that the requirements of the reference mediation component are
independent of the particular policies supported by a product.
4.2.3 TCB Logical Protection
The protection of the TCB from external interference and tampering is
a fundamental component of any secure product. Should unprivileged
subjects read or modify TCB elements (i.e., data structures and code),
the security policy might be circumvented or even modified in
potentially undetectable ways.
The reading of TCB internal variables, that is, variables that are not
part of any defined subject or object (e.g., internal TCB buffers,
table entries), would not be addressed by low- level product policies
defined solely in terms of subjects and objects. In this case, reading
by users or subjects outside the TCB would not be prohibited, even
though it could result in failure to support the organizational
policies. Similarly, modification of TCB internal variables may cause
(1) the introduction of miscreant code into the TCB, which can modify
product policies, (2) the modification of user and application-level
objects that depend on the consistency of the TCB internal variables,
(3) denial of service to users and applications, and/or (4) covert
transfer of information through the TCB in violation of
information-flow policy. Unauthorized acquisition of privileges might
allow the reading and modification of TCB internal variables and
objects (e.g., password files, group and/or role definition files,
files defining security and/or integrity levels) and might allow
unprivileged users to execute privileged functions.
To provide TCB isolation, all references to TCB internal entities and
all access rights passed by unprivileged subjects to the TCB must be
mediated in a non-circumventable manner. This particular form of
mediation is not specified as an access mediation requirement because
a cyclic dependency would be introduced between access mediation and
TCB protection. This is the case because the correct reference
mediation depends on TCB protection (see discussion in Chapter 7,
"Construction of Protection Profiles").
4.2.4 TCB Physical Protection
TCB physical protection components refer to restrictions of
unauthorized physical access to the TCB, and to deterrence of
unauthorized physical use, modification, or substitution of the TCB.
4.2.5 TCB Self-Checking
TCB self-checking functions are needed to detect the corruption of
protection-relevant code and data structures by various failures that
do not necessarily stop the product's operation (which would be
handled by TCB recoverability). These checks must be performed
because these failures may not necessarily be prevented. Such failures
can occur either because of unforeseen failure modes and associated
oversights in the design of hardware, firmware, or software, or
because of malicious corruption of the TCB due to inadequate physical
TCB protection.
4.2.6 TCB Start-Up and Recovery
TCB recovery components refer to the functions that respond to
anticipated failures or discontinuity of operations. These functional
components cannot handle "unanticipated" failures or discontinuity of
operation, and manual administrative procedures must be employed for
such events.
Recovery components reconstruct TCB secure states or prevent
transitions to insecure states as a direct response to occurrences of
expected failures, discontinuity of operation or start-up. Failures
that must be generally anticipated include (1) actions failures (e.g.,
actions that fail to complete because they detect exceptional
conditions during their operation); (2) unmaskable action failures
that always cause a system crash (e.g., persistent inconsistency of
critical system tables, uncontrolled transfers within TCB code caused
by transient failures of hardware or firmware, power failures,
processor failures); (3) non-volatile media failures causing part or
all of the media representing TCB objects to become inaccessible or
corrupt (e.g., disk head crash, persistent read/write failure caused
by misaligned disk heads, worn-out magnetic coating, dust on the disk
surface); and (4) discontinuity of operation caused by erroneous
administrative action or lack of timely administrative action (e.g.,
unexpected shutdowns by turning off power, ignoring the exhaustion of
critical resources, inadequate installed configuration).
4.2.7 TCB Privileged Operation
Functions that limit the privileges available to the TCB are primarily
intended to limit the damage that can be caused by errors and failures
of TCB mechanisms. To accomplish this, it is necessary to limit the
interactions among privileged TCB components to a minimum such that
improper use of privileges by a TCB function, module, or action as a
consequence of failures or accidents will have limited or no effect on
other components. For example, the association of privileges with
different administrative commands facilitates the separation of
administrative roles. Similarly, the association of different
privileges with TCB components that have no functional interaction,
such as audit trail and password management components, limits the
possibility of unwarranted interaction. As a consequence, if a
penetration of a component takes place, the likelihood that other
unrelated components are also penetrated may be diminished. The finer
the granularity of privileges and of privilege association with TCB
functional components, actions of components, and administrative
roles, the less chance of damage caused by errors, failures,
accidents, and penetrations.
4.2.8 TCB Ease-of-Use
The notion that an IT product must include functions which facilitate
and enhance the use of basic protection mechanisms is motivated by two
related observations. First, if a product's protection mechanisms are
complex, difficult to use, or have inadequate performance, they will
not be used by system administrators or by application programmers.
The mere presence of (potentially elaborate) security policies in a
product is insufficient to facilitate the development or use of secure
applications and the secure management of a product. An IT product
may still be vulnerable to inadvertent errors caused by difficulties
in using the product's protection functions. Second, functions that
facilitate and enhance the use of basic protection mechanisms may be
difficult to retrofit into a product because of their pervasiveness.
Instead, to be effective, these components must be included in the
initial product design.
4.3 Rated Functional Components
Functional components can be selected for inclusion in a profile based
on environment-specific requirements (see Chapter 3). To facilitate
this selection and compatibility with existing criteria, each of the
functional components of a TCB is rated. The rating of the TCB
functional components is based on the following four parameters: (1)
the scope of the requirement application, (2) the granularity of the
requirement, (3) the coverage of a requirement's features, and (4) the
strength of the requirement.
Scope. The scope of a requirement determines the entity subset to
which the requirement applies; i.e., (1) to all the users, subjects
and objects, (2) to all the TCB functions and application programming
interfaces, (3) to all TCB elements (i.e., hardware, firmware,
software, data structures and code), and (4) to all TCB
configurations, or only to a defined subset thereof. For example, the
access control, audit, availability, reference mediation, and
ease-of-use components may refer only to certain subsets of objects
and configurations; trusted path may include only certain subsets of
the TCB commands (only login commands but not change-of- password
commands or change-role commands); and the recovered secure state of
the TCB may include all the user objects or only a defined set.
Granularity. The granularity of a requirement determines the
entity-attribute subset to which the requirement applies (e.g.,
whether the requirement applies to all attributes of users, subjects
or objects, or only to a defined subset of attributes). Access
control, audit, and reference mediation may include only certain
attributes of subjects and objects, but not others. For example,
access control, audit, and reference mediation may refer to access
rights for objects and subjects, but not to object and subject status
variables; authentication may be based on group or role identities,
but not on individual user identity; privileges may be associated with
roles, but not with individual TCB functions or actions (e.g.,
function invocations).
Coverage. The coverage of a requirement determines the feature subset
included in that requirement. This is illustrated in the following
examples:
a. Access control may include only discretionary features of
authorization, administration of policy attributes (e.g., user
identities, groups, security and/or integrity levels, roles), and
object and/or subject creation and destruction, but not encapsulation.
b. Audit may include only post-processing analysis tools for
detecting accumulation of events (e.g., multiple failed logins) but
not real-time alarms.
c. Availability may include resource restrictions but not
prioritized resource allocation.
d. TCB protection may include only isolation features but not TCB
consistency features.
e. Physical TCB protection may include only attack detection and
deterrence features, but not attack countermeasures.
f. TCB self-checking may be periodical or continuous.
g. Recovery may be only manual, not automatic.
h. The ease-of-use mechanisms may include administrative and
application programming support features but may not minimize
performance penalties of using them.
Strength. The strength of a requirement supported by a function
defines the conditions under which that function withstands a defined
attack or tolerates failures. For example, the user authentication
function may withstand certain kinds of impersonation attacks but not
others (e.g., the password complexity rules may counter human guessing
attacks but not automated attacks using a dictionary). Other examples
include conditions in which conjunction of independent user
authentication mechanisms yields stronger authentication than the use
of either mechanism alone, or a certain encryption mechanism for
one-way function computation may have different work factor
characteristics than other encryption mechanisms. Similarly, the TCB
physical protection characteristics may vary according to different
work factor characteristics.
The strength of a requirement may also be used to differentiate access
control policies. For example, non- discretionary access controls are
typically stronger than discretionary access controls with respect to
their ability to counter attacks mounted by miscreant application code
executing programs on behalf of an unsuspecting user. However, this
notion of strength is not used to rate individual access control
components. Instead, it is used in the analysis of the protection
profiles (i.e., in assessing whether a chosen access control policy
can counter specific threats).
Rating implies some form of ordering. The independent application of
the scope, granularity, coverage, and strength parameters to
distinguish between the levels of functional components may not
necessarily lead to a linear ordering among these levels. To obtain
such an ordering these rating parameters are applied in the order in
which they are listed above. Whenever all rating parameters apply to a
given functional component, lower levels are distinguished by scope
and granularity and higher levels by coverage and strength. However,
this ordering of the rating parameters does not imply that each
component level represents a component extension resulting from the
application of a single rating parameter. Instead, a component level
change may represent a component extension resulting from the
application of several rating parameters characterizing the intent of
a functional component (e.g., support of a specific policy,
compatibility with existing standards and guidelines).
The above parameters and ordering are chosen to enable the rating of
functional components at levels of detail comparable to those of
existing standards (e.g., TCSEC, CTCPEC, ITSEC), thereby enabling
potential harmonization with these standards. However, the rating of
functional components does not restrict a profile developer to the
choices of rated components presented. As illustrated in Chapter 7, a
profile developer can synthesize new components from existing ones
(e.g., by assigning a specific meaning to a generic requirement, by
refining a requirement of a component, by augmenting a lower rated
component with an individual requirement of a higher rated component)
within the constraints of dependency analysis.
The means of rating each component are summarized in Table 2.
Table 2. Rated Functional Components
.--------------------------------------------------------------------------.
| | | Granu- | Cover- | |
| Functional Component | Scope | larity | age | Strength |
|=====================================|=======|========|========|==========|
| Security Policy Support | | | | |
|-------------------------------------+-------+--------+--------+----------|
| Accountability | | | | |
|-------------------------------------+-------+--------+--------+----------|
| Identification & Authentication | | | X | X |
|-------------------------------------+-------+--------+--------+----------|
| System Entry | | | X | |
|-------------------------------------+-------+--------+--------+----------|
| Trusted Path | X | | X | |
|-------------------------------------+-------+--------+--------+----------|
| Audit | | | X | X |
|-------------------------------------+-------+--------+--------+----------|
| Access Control | X | X | X | |
|-------------------------------------+-------+--------+--------+----------|
| Covert Channel Handling | X | | X | |
|-------------------------------------+-------+--------+--------+----------|
| Availability | | | | |
|-------------------------------------+-------+--------+--------+----------|
| Resource Allocation | X | | X | |
|-------------------------------------+-------+--------+--------+----------|
| Fault Tolerance | --- | --- | --- | --- |
|-------------------------------------+-------+--------+--------+----------|
| Security Management | | | X | X |
|-------------------------------------+-------+--------+--------+----------|
| Reference Mediation | X | X | X | |
|-------------------------------------+-------+--------+--------+----------|
| TCB Logical Protection | | | X | |
|-------------------------------------+-------+--------+--------+----------|
| TCB Physical Protection | | | X | X |
|-------------------------------------+-------+--------+--------+----------|
| TCB Self-checking | X | | X | |
|-------------------------------------+-------+--------+--------+----------|
| TCB Start-up and Recovery | | | X | |
|-------------------------------------+-------+--------+--------+----------|
| TCB Privileged Operation | | X | | |
|-------------------------------------+-------+--------+--------+----------|
| TCB Ease-of-Use | X | | X | |
`--------------------------------------------------------------------------'
4.3.1 Rated Identification & Authentication Components
Identification and authentication is a required component for most
security policies. Without this component, the threat of unauthorized
or inappropriate system entry and access to resources could not be
countered. However, weak identification and authentication functions
could not counter the threat of impersonation attacks by unauthorized
users. For this reason, identification and authentication components
are noted based on both the coverage and strength of the
authentication features. Furthermore, the combined use of more than
one type of authentication can provide greater control over
unauthorized access.
The features covered at level I&A-1 include only minimal forms of
individual user authentication. This level of I&A is intended for use
in products with limited capabilities, such as automated guards, where
basic I&A and system-entry audit are the primary functions supported.
In contrast, the features of level I&A-2 include policy attributes
that are determined on an individual basis, thereby providing basic
authorization. The use of this level is anticipated in most operating
systems where policy attributes, such as groups and security levels,
need to be authenticated for system entry. Level I&A-3 extends the
feature coverage of level I&A-2 by providing a well-defined set of
responses to authentication exceptions and a capability to maintain,
protect and display user status information. The use of this level is
anticipated to include products with well-defined access control and
availability policies as well as system-entry control. The level I&A-4
extends the feature coverage of level I&A-3 by requiring that
installable mechanisms be supported, and that a policy be enforced
that assigns a specific authentication procedure to each user, or to a
policy attribute of each user. Level I&A-5 strengthens level I&A-4 by
requiring that two or more identification and authentication
mechanisms authenticate certain user identities or other policy
attributes.
I&A-1 Minimal Identification and Authentication
1. The TCB shall require users to identify themselves to it
before beginning to perform any other actions that the TCB is expected
to mediate. The TCB shall be able to enforce individual
accountability by providing the capability to uniquely identify each
individual user. The TCB shall also provide the capability of
associating this identity with all auditable actions taken by that
individual.
2. The TCB shall use a protected mechanism (e.g., passwords) to
authenticate the user's identity.
3. The TCB shall protect authentication data so that it cannot be
used by any unauthorized user.
I&A-2 Identification, Authentication, and Authorization
1. The TCB shall require users to identify themselves to it
before beginning to perform any other actions that the TCB is expected
to mediate. The TCB shall be able to enforce individual
accountability by providing the capability to uniquely identify each
individual user. The TCB shall also provide the capability of
associating this identity with all auditable actions taken by that
individual.
2. The TCB shall maintain authentication data that includes
information for verifying the identity of individual users (e.g.,
passwords) as well as information for determining the product policy
attributes of individual users (e.g., groups, roles, security and/or
integrity levels, time intervals, location). These data shall be used
by the TCB to authenticate the user's identity and to ensure that the
attributes of subjects external to the TCB that may be created to act
on behalf of the individual user satisfy the product policy (e.g., the
subject security level and authorizations are dominated by the
clearance and authorization of that user).
3. The TCB shall protect authentication data so that it cannot be
used by any unauthorized user.
I&A-3 Exception-Controlled Identification and Authentication
1. The TCB shall require users to identify themselves to it
before beginning to perform any other actions that the TCB is expected
to mediate. The TCB shall be able to enforce individual
accountability by providing the capability to uniquely identify each
individual user. The TCB shall also provide the capability of
associating this identity with all auditable actions taken by that
individual.
2. The TCB shall maintain authentication data that includes
information for verifying the identity of individual users (e.g.,
passwords) as well as information for determining the product policy
attributes of individual users (e.g., groups, roles, security and/or
integrity levels, time intervals, location). These data shall be used
by the TCB to authenticate the user's identity and to ensure that the
attributes of subjects external to the TCB that may be created to act
on behalf of the individual user satisfy the product policy (e.g., the
subject security level and authorizations are dominated by the
clearance and authorization of that user).
3. The TCB shall protect authentication data so that it cannot be
used by any unauthorized user. The TCB shall appear to perform the
entire user authentication procedure even if the user identification
entered is invalid.
The TCB shall end the attempted login session if the user performs the
authentication procedure incorrectly for a number of successive times
(i.e., a threshold) specified by an authorized system administrator. A
default threshold shall be defined. When the threshold is exceeded,
the TCB shall send an alarm message to the system console and/or to
the administrator's terminal, log this event in the audit trail, and
delay the next login by an interval of time specified by the
authorized system administrator. A default time interval shall be
defined. The TCB shall provide a protected mechanism to disable the
user identity or account when the threshold of successive,
unsuccessful login attempts is violated more than a number of times
specified by the administrator. By default, this mechanism shall be
disabled (as it may cause unauthorized denial of service).
4. The TCB shall have the capability to maintain, protect, and
display status information for all active users (e.g., users currently
logged on, current policy attributes) and of all user accounts (i.e.,
enabled or disabled user identity or account).
I&A-4 Installable I&A Mechanisms
1. The TCB shall require users to identify themselves to it
before beginning to perform any other actions that the TCB is expected
to mediate. The TCB shall be able to enforce individual
accountability by providing the capability to uniquely identify each
individual user. The TCB shall also provide the capability of
associating this identity with all auditable actions taken by that
individual. Furthermore, the TCB shall have the capability of
associating a unique identity with each privileged subject.
2. The TCB shall maintain authentication data that includes
information for verifying the identity of individual users (e.g.,
passwords) as well as information for determining the product policy
attributes of individual users (e.g., groups, roles, security and/or
integrity levels, time intervals, location). These data shall be used
by the TCB to authenticate the user's identity and to ensure that the
attributes of subjects external to the TCB that may be created to act
on behalf of the individual user satisfy the product policy (e.g., the
subject security level and authorizations are dominated by the
clearance and authorization of that user).
The TCB shall be able to incorporate and use installable
authentication mechanisms, such as token-based cards, biometrics, or
trusted third- party mechanisms, in the place of or in addition to the
default authentication (e.g., password- based) mechanism, to
authenticate the user. The TCB shall be able to enforce separate user
authentication procedures based on specific policy attributes.
3. The TCB shall protect authentication data so that it cannot be used
by any unauthorized user. The TCB shall appear to perform the entire
user authentication procedure even if the user identification entered
is invalid.
The TCB shall end the attempted login session if the user performs the
authentication procedure incorrectly for a number of successive times
(i.e., a threshold) specified by an authorized system administrator. A
default threshold shall be defined. When the threshold is exceeded,
the TCB shall send an alarm message to the system console and/or to
the administrator's terminal, log this event in the audit trail, and
delay the next login by an interval of time specified by the
authorized system administrator. A default time interval shall be
defined. The TCB shall provide a protected mechanism to disable the
user identity or account when the threshold of successive,
unsuccessful login attempts is violated more than a number of times
specified by the administrator. By default, this mechanism shall be
disabled (as it may cause unauthorized denial of service).
4. The TCB shall have the capability to maintain, protect, and
display status information for all active users (e.g., users currently
logged on, current policy attributes) and of all user accounts (i.e.,
enabled or disabled user identity or account).
I&A-5 Multiple I&A Mechanisms
1. The TCB shall require users to identify themselves to it
before beginning to perform any other actions that the TCB is expected
to mediate. The TCB shall be able to enforce individual
accountability by providing the capability to uniquely identify each
individual user. The TCB shall also provide the capability of
associating this identity with all auditable actions taken by that
individual. Furthermore, the TCB shall have the capability of
associating a unique identity with each privileged subject.
2. The TCB shall maintain authentication data that includes
information for verifying the identity of individual users (e.g.,
passwords) as well as information for determining the product policy
attributes of individual users (e.g., groups, roles, security and/or
integrity levels, time intervals, location). These data shall be used
by the TCB to authenticate the user's identity and to ensure that the
attributes of subjects external to the TCB that may be created to act
on behalf of the individual user satisfy the product policy (e.g., the
subject security level and authorizations are dominated by the
clearance and authorization of that user).
The TCB shall be able to incorporate and use installable
authentication mechanisms, such as token-based cards, biometrics, or
trusted third- party mechanisms, in the place of or in addition to the
default authentication (e.g., password- based) mechanism, to
authenticate the user. The TCB shall be able to enforce separate user
authentication procedures based on specific policy attributes. Each
user shall be authenticated by two or more types of authentication
mechanisms; i.e., the authentication is successful only if all
mechanisms individually indicate successful authentication. The TCB
shall be able to enforce the use of these mechanisms on a
policy-attribute basis.
3. The TCB shall protect authentication data so that it cannot be used
by any unauthorized user. The TCB shall appear to perform the entire
user authentication procedure even if the user identification entered
is invalid.
The TCB shall end the attempted login session if the user performs the
authentication procedure incorrectly for a number of successive times
(i.e., a threshold) specified by an authorized system administrator. A
default threshold shall be defined. When the threshold is exceeded,
the TCB shall send an alarm message to the system console and/or to
the administrator's terminal, log this event in the audit trail, and
delay the next login by an interval of time specified by the
authorized system administrator. A default time interval shall be
defined. The TCB shall provide a protected mechanism to disable the
user identity or account when the threshold of successive,
unsuccessful login attempts is violated more than a number of times
specified by the administrator. By default, this mechanism shall be
disabled (as it may cause unauthorized denial of service).
4. The TCB shall have the capability to maintain, protect, and
display status information for all active users (e.g., users currently
logged on, current policy attributes) and of all user accounts (i.e.,
enabled or disabled user identity or account).
4.3.2 Rated System Entry Components
System entry control helps enhance accountability by providing a time,
space, and mode-of-entry context to each action for which the user is
held accountable. The additional constraints of system entry control
help gain increased confidence that the proper user is held
responsible for a set of authorized actions.
System entry by an identified and authenticated user shall be
controlled by the TCB. The conditions under which a user subject
(e.g., process) is created on behalf of an identified and
authenticated user shall be specified. The specification of these
conditions shall be based on users' policy attributes (e.g., groups,
roles, security and/or integrity levels, time intervals, location).
The system-entry components are rated based on the coverage of
specific conditions of system entry. For example, the features covered
at level SE-1 include only basic forms of system entry (e.g., system
entry conditions based on group or role membership, and security
and/or integrity levels). This level is intended for use in most IT
products that support system-entry control. Products that do not
implement explicit system-entry control rely on the identification and
authentication mechanism as the default system entry control. The
features of level SE-2 include, in addition to the entry conditions of
level SE-1, entry conditions defined in terms of the time and the
location of entry. The level SE-3 extends the feature coverage of
level SE-2 by requiring the explicit user ability to lock and unlock
the user's own interactive sessions. Primitive forms of such locking
by terminating and restarting a session are considered to have a
substantially narrower coverage than those intended at this level and
may be used only at lower levels.
SE-1 Basic System Entry Control
1. Prior to initiating the system login procedure, the TCB shall
display an advisory warning message to the user regarding unauthorized
use of the system and the possible consequences of failure to heed
this warning.
2. Before system entry is granted to a user, the identity of that
user shall be authenticated by the TCB. If the TCB is designed to
support multiple login sessions per user identity, the TCB shall
provide a protected mechanism to enable limiting the number of login
sessions per user identity or account with a default of a single login
session.
3. The TCB shall grant system entry only in accordance with the
authenticated user's policy attributes. The system entry conditions
shall be expressed in terms of users' policy attributes (e.g.,
greatest lower bound and least upper bound computations including the
user levels, terminal levels, system levels). If no explicit system-
entry conditions are defined, the system-entry default shall be used
(e.g., the correct user authentication).
4. The TCB shall provide a protected mechanism that enables
authorized administrators to display and modify the policy attributes
used in system-entry control for each user. The conditions under which
an unprivileged user may display these attributes shall be specified.
5. Upon a user's successful entry to the system, the TCB shall
display the following data to the user and shall not remove them
without user intervention: (1) the date, time, means of access and
port of entry of the last successful entry to the system; and (2) the
number of successive, unsuccessful attempts to access the system since
the last successful entry by the identified user.
6. The TCB shall either lock or terminate an interactive session
after an administrator- specified interval of user inactivity. The
default value for this interval shall be specified.
SE-2 Time and Location Based Entry Control
1. Prior to initiating the system login procedure, the TCB shall
display an advisory warning message to the user regarding unauthorized
use of the system and the possible consequences of failure to heed
this warning.
2. Before system entry is granted to a user, the identity of that
user shall be authenticated by the TCB. If the TCB is designed to
support multiple login sessions per user identity, the TCB shall
provide a protected mechanism to enable limiting the number of login
sessions per user identity or account with a default of a single login
session.
3. The TCB shall grant system entry only in accordance with the
authenticated user's policy attributes. The system entry conditions
shall be expressed in terms of users' policy attributes (e.g.,
greatest lower bound and least upper bound computations including the
user levels, terminal levels, system levels). If no explicit system-
entry conditions are defined, the system-entry default shall be used
(e.g., the correct user authentication). The TCB shall provide a
protected mechanism to allow or deny system entry based on specified
ranges of time. Entry conditions using these ranges shall be specified
using time-of-day, day-of-week, and calendar dates.
The TCB shall provide a protected mechanism to allow or deny system
entry based on location or port of entry. Conditions for system entry
via dial-up lines (e.g., lists of user identities authorized to enter
the system via dial-up lines), if any, shall be specified.
4. The TCB shall provide a protected mechanism that enables
authorized administrators to display and modify the policy attributes
used in system-entry control for each user. The conditions under which
an unprivileged user may display these attributes shall be specified.
5. Upon a user's successful entry to the system, the TCB shall
display the following data to the user and shall not remove them
without user intervention: (1) the date, time, means of access and
port of entry of the last successful entry to the system; and (2) the
number of successive, unsuccessful attempts to access the system since
the last successful entry by the identified user.
6. The TCB shall either lock or terminate an interactive session
after an administrator- specified interval of user inactivity. The
default value for this interval shall be specified.
SE-3 Session Locking and Unlocking
1. Prior to initiating the system login procedure, the TCB shall
display an advisory warning message to the user regarding unauthorized
use of the system and the possible consequences of failure to heed
this warning.
2. Before system entry is granted to a user, the identity of that
user shall be authenticated by the TCB. If the TCB is designed to
support multiple login sessions per user identity, the TCB shall
provide a protected mechanism to enable limiting the number of login
sessions per user identity or account with a default of a single login
session.
3. The TCB shall grant system entry only in accordance with the
authenticated user's policy attributes. The system entry conditions
shall be expressed in terms of users' policy attributes (e.g.,
greatest lower bound and least upper bound computations including the
user levels, terminal levels, system levels). If no explicit system-
entry conditions are defined, the system-entry default shall be used
(e.g., the correct user authentication). The TCB shall provide a
protected mechanism to allow or deny system entry based on specified
ranges of time. Entry conditions using these ranges shall be specified
using time-of-day, day-of-week, and calendar dates.
The TCB shall provide a protected mechanism to allow or deny system
entry based on location or port of entry. Conditions for system entry
via dial-up lines (e.g., lists of user identities authorized to enter
the system via dial-up lines), if any, shall be specified.
4. The TCB shall provide a protected mechanism that enables
authorized administrators to display and modify the policy attributes
used in system-entry control for each user. The conditions under which
an unprivileged user may display these attributes shall be specified.
5. Upon a user's successful entry to the system, the TCB shall
display the following data to the user and shall not remove them
without user intervention: (1) the date, time, means of access and
port of entry of the last successful entry to the system; and (2) the
number of successive, unsuccessful attempts to access the system since
the last successful entry by the identified user.
6. The TCB shall either lock or terminate an interactive session
after an administrator- specified interval of user inactivity. The
default value for this interval shall be specified. The TCB shall also
provide a mechanism for user- initiated locking of the user's own
interactive sessions (e.g., keyboard locking) that includes: (1)
clearing or over-writing display devices to make the current contents
unreadable; (2) requiring user authentication prior to unlocking the
session; and (3) disabling any activity of the user's data
entry/display devices other than unlocking the session.
4.3.3 Rated Trusted Path Components
The trusted path components are rated based on the scope and coverage
of the trusted-path interactions (e.g., user-TCB interactions
including the number and types of commands included in the trusted
path). Primitive forms of trusted path, such as terminating a login
session or powering off a workstation to guarantee trusted path
interaction, are considered to have a substantially narrower scope and
coverage than those enabling trusted path within a login session.
The rating of the trusted path components intends to guarantee at the
lowest level, TP-1, that a trusted communication channel exists from
the user to the TCB for initial identification purposes. For higher
levels, both the scope and the coverage of trusted path are extended.
At level TP-2, trusted path includes not only login commands but also
other commands that require protection (e.g., change of subject policy
attributes). Thus, the TCB guarantees the invocation of a trusted
communication channel from the user to the TCB for trusted sensitive
commands and their parameters. At level TP-3, the coverage of the
trusted path features is enlarged to enable trusted applications to
communicate with the user for the validation of specific TCB mediated
tasks (e.g., change of policy attributes, change of user registration
parameters). This means that a trusted application can use a separate,
trusted display feature, and that commands of the trusted application
can be introduced in the user-initiated trusted path.
TP-1 Login Trusted Path
The TCB shall support a trusted communication path between itself and
the user for initial identification and authentication. Communications
via this path shall be initiated exclusively by a user.
TP-2 Trusted User-to-TCB Communication
The TCB shall support a trusted communication path between itself and
users for use whenever a positive user-to-TCB connection is required
(e.g., login, change of policy attributes). Communications via this
trusted path shall be activated exclusively by a user or the TCB and
shall be logically isolated and unmistakably distinguishable from
other communication paths.
TP-3 Trusted Application-to-User Communication
The TCB shall support a trusted communication path between itself and
users for use whenever a positive user-to-TCB connection is required
(e.g., login, change of subject or object attributes). Communications
via this trusted path shall be activated exclusively by a user or the
TCB and shall be logically isolated and unmistakably distinguishable
from other communication paths.The TCB shall also support a trusted
communication path between trusted applications and users when a
trusted application-to-user connection is required (e.g., display or
input of application sensitive data).
4.3.4 Rated Audit Components
The audit components are rated based on the coverage of the
event-selection mechanisms and audit-analysis tools, and the strength
of monitoring user actions (e.g., degree to which active, real-time
monitoring is possible.) The audit requirements that follow are
divided into four parts: first, the protection of the audit trail and
the control of access to audit data; second, the definition of the
auditable events; third, format and recording of the audit data; and
fourth, the selection of audit events, and audit-data management,
analysis, and reporting.
Level AD-1 includes minimal audit requirements; i.e., requirements
that must be satisfied by all systems (to the extent to which they
incorporate relevant policy functions). The audit coverage is
extended at audit level AD-2 by extending the types of auditable
events and by the inclusion of additional audit management functions.
Audit function coverage is further extended at level AD-3 by the
requirements for availability of trusted audit tools that enhance
audit control (e.g., tools offering a graphical interface to the
auditor, tools that enable the auditor to perform consistency checking
of the selected events and of audit trails, tools that enhance the
ease-of-auditing). Level AD-4 extends the coverage of the audit
features of level AD-3 by requiring detection of accumulation of
security-relevant events and generation of alarms whenever such events
are detected. AD-5 represents an added level of auditing strength
since it requires that auditing be performed in real-time. Thus, real-
time intrusions can be detected.
AD-1 - Minimal Audit
1. The TCB shall be able to create, maintain, and protect from
modification or unauthorized access or destruction an audit trail of
accesses to the objects it protects. The audit data shall be protected
by the TCB so that read access to it is limited to those who are
authorized for audit data.
2. The TCB shall be able to record the following types of events:
- use of the identification and authentication mechanisms;
- introduction of objects into a user's address space (e.g.,
file open, program initiation), and deletion of objects;
- actions taken by computer operators and system
administrators and/or system security officers.
If availability policies are supported, attempts to circumvent or
otherwise gain unauthorized access to resource-allocation limits shall
be audited.
If non-discretionary access control policies are supported, the TCB
shall be able to record any override of human-readable output
markings. When the non-discretionary access control policies aim to
control the flow of information between subjects, the TCB shall also
be able to audit the identified event that may be used in the
exploitation of covert channels.
3. For each recorded event, the audit record shall identify: date
and time of the event, user, type of event, and success or failure of
the event. For identification/authentication events the origin of
request (e.g., terminal ID) shall be included in the audit record. For
events that introduce an object into a user's address space and for
object deletion events the audit record shall include the name and
policy attributes of the object (e.g., object security level).
4. The system administrator shall be able to selectively audit
the actions of one or more users based on individual identity and/or
object policy attributes (e.g., object security level).
AD-2 Basic Audit
1. The TCB shall be able to create, maintain, and protect from
modification or unauthorized access or destruction an audit trail of
accesses to the objects it protects. The audit data shall be protected
by the TCB so that read access to it is limited to those who are
authorized for audit data.
2. The TCB shall be able to record the following types of events:
- use of the identification and authentication mechanisms, and
system entry events;
- access control events selectable on a per user, per subject,
per object, and/or per policy attribute basis; i.e., introduction of
objects into a user's address space (e.g., file open, program
initiation), creation and deletion of subjects and objects;
distribution and revocation of access rights; changes of subject and
object policy attributes; acquisition and deletion of system
privileges;
-actions taken by computer operators and system administrators
and/or system security officers; i.e., privileged operations such as
the modification of TCB elements; accesses to TCB objects; changes of
policy attributes of users, TCB configuration and security
characteristics, and system privileges; selection and modification of
audited events.
The events that are auditable by default, and those that are required
for successful auditing of other events, which may not be disabled,
shall be defined. The TCB shall provide a protected mechanism that
displays the currently selected events and their defaults. The use of
this mechanism shall be restricted to authorized system
administrators.
If availability policies are supported, attempts to circumvent or
otherwise gain unauthorized access to resource-allocation limits shall
be audited.
If non-discretionary access control policies are supported, the TCB
shall be able to record any override of human-readable output
markings. When the non-discretionary access control policies aim to
control the flow of information between subjects, the TCB shall also
be able to audit the identified event that may be used in the
exploitation of covert channels.
3. For each recorded event, the audit record shall identify: date
and time of the event, user, type of event, and success or failure of
the event. For identification/authentication events the origin of
request (e.g., terminal ID) shall be included in the audit record. For
events that introduce an object into a user's address space and for
object deletion events the audit record shall include the name and
policy attributes of the object (e.g., object security level).
4. The TCB shall provide a protected mechanism to turn auditing
on and off, and to select and change the events to be audited and
their defaults, during the system operation. The use of this mechanism
shall be restricted to authorized system administrators. The system
administrator shall be able to selectively audit the actions of one or
more users based on individual identity and/or object policy
attributes (e.g., object security level). Audit review tools shall be
available to authorized system administrators to assist in the
inspection and review of audit data, and shall be protected from
unauthorized use, modification, or destruction.
The TCB shall also provide protected audit-trail management functions
that shall enable:
-creation, destruction, and emptying of audit trails; use of
warning points regarding the size of the audit data, and modification
of the audit trail size;
-formatting and compressing of event records;
-displaying of formatted audit trail data; and
-maintaining the consistency of the audit trail data after
system failures and discontinuity of operation.
AD-3 Audit Tools
1. The TCB shall be able to create, maintain, and protect from
modification or unauthorized access or destruction an audit trail of
accesses to the objects it protects. The audit data shall be protected
by the TCB so that read access to it is limited to those who are
authorized for audit data.
2. The TCB shall be able to record the following types of events:
- use of the identification and authentication mechanisms, and
system entry events;
- access control events selectable on a per user, per subject,
per object, and/or per policy attribute basis; i.e., introduction of
objects into a user's address space (e.g., file open, program
initiation), creation and deletion of subjects and objects;
distribution and revocation of access rights; changes of subject and
object policy attributes; acquisition and deletion of system
privileges;
-actions taken by computer operators and system administrators
and/or system security officers; i.e., privileged operations such as
the modification of TCB elements; accesses to TCB objects; changes of
policy attributes of users, TCB configuration and security
characteristics, and system privileges; selection and modification of
audited events.
The events that are auditable by default, and those that are required
for successful auditing of other events, which may not be disabled,
shall be defined. The TCB shall provide a protected mechanism that
displays the currently selected events and their defaults. The use of
this mechanism shall be restricted to authorized system
administrators.
If availability policies are supported, attempts to circumvent or
otherwise gain unauthorized access to resource-allocation limits shall
be audited.
If non-discretionary access control policies are supported, the TCB
shall be able to record any override of human-readable output
markings. When the non-discretionary access control policies aim to
control the flow of information between subjects, the TCB shall also
be able to audit the identified event that may be used in the
exploitation of covert channels.
3. For each recorded event, the audit record shall identify: date
and time of the event, user, type of event, and success or failure of
the event. For identification/authentication events the origin of
request (e.g., terminal ID) shall be included in the audit record. For
events that introduce an object into a user's address space and for
object deletion events the audit record shall include the name and
policy attributes of the object (e.g., object security level).
4. The TCB shall provide a protected mechanism to turn auditing
on and off, and to select and change the events to be audited and
their defaults, during the system operation. The use of this mechanism
shall be restricted to authorized system administrators. The system
administrator shall be able to selectively audit the actions of one or
more users based on individual identity and/or object policy
attributes (e.g., object security level). Audit review tools shall be
available to authorized system administrators to assist in the
inspection and review of audit data, and shall be protected from
unauthorized use, modification, or destruction.
The TCB shall provide tools for audit data processing. These shall
include specifically designed tools: for verifying the consistency of
the audit data; for verifying the selection of audit events; for audit
trail management. The audit trail management tools shall enable:
-creation, destruction, and emptying of audit trails; use of
warning points regarding the size of the audit data, and modification
of the audit trail size;
-formatting and compressing of event records;
-displaying of formatted audit trail data; and
-maintaining the consistency of the audit trail data after
system failures and discontinuity of operation.
5. Audit review tools shall be available to authorized users to
assist in the inspection and review of audit data, and shall be
protected from unauthorized modification or destruction. The TCB shall
also provide tools for post-collection audit analysis (e.g., intrusion
detection) that shall be able to selectively review (1) the actions of
one or more users (e.g., identification, authentication, system-entry,
and access control actions); (2) the actions performed on a specific
object or system resource; and (3) all, or a specified set of, audited
exceptions; and (4) actions associated with a specific policy
attribute.The review tools shall be able to operate concurrently with
the system operation.
AD-4 Audit Alarms
1. The TCB shall be able to create, maintain, and protect from
modification or unauthorized access or destruction an audit trail of
accesses to the objects it protects. The audit data shall be protected
by the TCB so that read access to it is limited to those who are
authorized for audit data.
2. The TCB shall be able to record the following types of events:
- use of the identification and authentication mechanisms, and
system entry events;
- access control events selectable on a per user, per subject,
per object, and/or per policy attribute basis; i.e., introduction of
objects into a user's address space (e.g., file open, program
initiation), creation and deletion of subjects and objects;
distribution and revocation of access rights; changes of subject and
object policy attributes; acquisition and deletion of system
privileges;
-actions taken by computer operators and system administrators
and/or system security officers; i.e., privileged operations such as
the modification of TCB elements; accesses to TCB objects; changes of
policy attributes of users, TCB configuration and security
characteristics, and system privileges; selection and modification of
audited events.
The events that are auditable by default, and those that are required
for successful auditing of other events, which may not be disabled,
shall be defined. The TCB shall provide a protected mechanism that
displays the currently selected events and their defaults. The use of
this mechanism shall be restricted to authorized system
administrators.
If availability policies are supported, attempts to circumvent or
otherwise gain unauthorized access to resource-allocation limits shall
be audited.
If non-discretionary access control policies are supported, the TCB
shall be able to record any override of human-readable output
markings. When the non-discretionary access control policies aim to
control the flow of information between subjects, the TCB shall also
be able to audit the identified event that may be used in the
exploitation of covert channels.
The TCB shall contain a mechanism that is able to monitor the
occurrence or accumulation of auditable events that may indicate an
imminent violation of the product's security policy. This mechanism
shall be able to immediately notify the security administrator when
thresholds are exceeded, and, if the occurrence or accumulation of
these security relevant events continues, the system shall take the
least disruptive action to terminate the event. That is, the TCB shall
be able to send a message to the system console and/ or the
administrator's terminal when thresholds are exceeded, or when audit
records are unable to be recorded, and, if the occurrence or
accumulation of these security-relevant events continue, the TCB shall
generate an alarm (this shall be the default) or initiate a secure
system shutdown.
3. For each recorded event, the audit record shall identify: date
and time of the event, user, type of event, and success or failure of
the event. For identification/authentication events the origin of
request (e.g., terminal ID) shall be included in the audit record. For
events that introduce an object into a user's address space and for
object deletion events the audit record shall include the name and
policy attributes of the object (e.g., object security level).
4. The TCB shall provide a protected mechanism to turn auditing
on and off, and to select and change the events to be audited and
their defaults, during the system operation. The use of this mechanism
shall be restricted to authorized system administrators. The system
administrator shall be able to selectively audit the actions of one or
more users based on individual identity and/or object policy
attributes (e.g., object security level). Audit review tools shall be
available to authorized system administrators to assist in the
inspection and review of audit data, and shall be protected from
unauthorized use, modification, or destruction.
The TCB shall provide tools for audit data processing. These shall
include specifically designed tools: for verifying the consistency of
the audit data; for verifying the selection of audit events; for audit
trail management. The audit trail management tools shall enable:
-creation, destruction, and emptying of audit trails; use of
warning points regarding the size of the audit data, and modification
of the audit trail size;
-formatting and compressing of event records;
-displaying of formatted audit trail data; and
-maintaining the consistency of the audit trail data after
system failures and discontinuity of operation.
5. Audit review tools shall be available to authorized users to
assist in the inspection and review of audit data, and shall be
protected from unauthorized modification or destruction. The TCB shall
also provide tools for post-collection audit analysis (e.g., intrusion
detection) that shall be able to selectively review (1) the actions of
one or more users (e.g., identification, authentication, system-entry,
and access control actions); (2) the actions performed on a specific
object or system resource; and (3) all, or a specified set of, audited
exceptions; and (4) actions associated with a specific policy
attribute.The review tools shall be able to operate concurrently with
the system operation.
AD-5 Real-Time Intrusion Detection
1. The TCB shall be able to create, maintain, and protect from
modification or unauthorized access or destruction an audit trail of
accesses to the objects it protects. The audit data shall be protected
by the TCB so that read access to it is limited to those who are
authorized for audit data.
2. The TCB shall be able to record the following types of events:
- use of the identification and authentication mechanisms, and
system entry events;
- access control events selectable on a per user, per subject,
per object, and/or per policy attribute basis; i.e., introduction of
objects into a user's address space (e.g., file open, program
initiation), creation and deletion of subjects and objects;
distribution and revocation of access rights; changes of subject and
object policy attributes; acquisition and deletion of system
privileges;
-actions taken by computer operators and system administrators
and/or system security officers; i.e., privileged operations such as
the modification of TCB elements; accesses to TCB objects; changes of
policy attributes of users, TCB configuration and security
characteristics, and system privileges; selection and modification of
audited events.
The events that are auditable by default, and those that are required
for successful auditing of other events, which may not be disabled,
shall be defined. The TCB shall provide a protected mechanism that
displays the currently selected events and their defaults. The use of
this mechanism shall be restricted to authorized system
administrators.
If availability policies are supported, attempts to circumvent or
otherwise gain unauthorized access to resource-allocation limits shall
be audited.
If non-discretionary access control policies are supported, the TCB
shall be able to record any override of human-readable output
markings. When the non-discretionary access control policies aim to
control the flow of information between subjects, the TCB shall also
be able to audit the identified event that may be used in the
exploitation of covert channels.
The TCB shall contain a mechanism that is able to monitor the
occurrence or accumulation of auditable events that may indicate an
imminent violation of the product's security policy. This mechanism
shall be able to immediately notify the security administrator when
thresholds are exceeded, and, if the occurrence or accumulation of
these security relevant events continues, the system shall take the
least disruptive action to terminate the event. That is, the TCB shall
be able to send a message to the system console and/ or the
administrator's terminal when thresholds are exceeded, or when audit
records are unable to be recorded, and, if the occurrence or
accumulation of these security-relevant events continue, the TCB shall
generate an alarm (this shall be the default) or initiate a secure
system shutdown.
3. For each recorded event, the audit record shall identify: date
and time of the event, user, type of event, and success or failure of
the event. For identification/authentication events the origin of
request (e.g., terminal ID) shall be included in the audit record. For
events that introduce an object into a user's address space and for
object deletion events the audit record shall include the name and
policy attributes of the object (e.g., object security level).
4. The TCB shall provide a protected mechanism to turn auditing
on and off, and to select and change the events to be audited and
their defaults, during the system operation. The use of this mechanism
shall be restricted to authorized system administrators. The system
administrator shall be able to selectively audit the actions of one or
more users based on individual identity and/or object policy
attributes (e.g., object security level). Audit review tools shall be
available to authorized system administrators to assist in the
inspection and review of audit data, and shall be protected from
unauthorized use, modification, or destruction.
The TCB shall provide tools for audit data processing. These shall
include specifically designed tools: for verifying the consistency of
the audit data; for verifying the selection of audit events; for audit
trail management. The audit trail management tools shall enable:
-creation, destruction, and emptying of audit trails; use of
warning points regarding the size of the audit data, and modification
of the audit trail size;
-formatting and compressing of event records;
-displaying of formatted audit trail data; and
-maintaining the consistency of the audit trail data after
system failures and discontinuity of operation.
5. Audit review tools shall be available to authorized users to
assist in the inspection and review of audit data, and shall be
protected from unauthorized modification or destruction. The TCB shall
also provide tools for post-collection audit analysis (e.g., intrusion
detection) that shall be able to selectively review (1) the actions of
one or more users (e.g., identification, authentication, system-entry,
and access control actions); (2) the actions performed on a specific
object or system resource; and (3) all, or a specified set of, audited
exceptions; and (4) actions associated with a specific policy
attribute.The review tools shall be able to operate concurrently with
the system operation.
The TCB shall be able to perform real-time event reporting and
intrusion detection in support of the product's security policy. The
TCB shall include a real-time mechanism that is able to monitor the
occurrence or accumulation of security-relevant events that may
indicate an imminent security violation. This mechanism shall be able
to generate an alarm when thresholds are exceeded and, if the
occurrence or accumulation of these events persists, the TCB shall
take the least disruptive action to terminate the event(s).
4.3.5 Rated Access Control Components
Functional components implementing discretionary policies can be rated
based on their scope (e.g., whether it includes all subjects and
objects in a system, or only a defined subset; whether access control
includes subject and object attributes), and on their coverage (e.g.,
their ability to control the propagation and retention of access
rights for subjects and objects and their ability to encapsulate
objects within a subject such that access to the object is allowed
only by invoking the encapsulating subject.) In addition,
discretionary policy rating can also refer to the ability to control
access at a given subject granularity (e.g., at the individual user
and group, or role level) and object granularity (e.g., memory
partition, memory segment, file, record).
Non-discretionary access controls can be rated using the same generic
levels as those used for discretionary policies. However, the
granularity of subject and object to which non- discretionary access
controls apply can be significantly finer than that of discretionary
policies. Since non- discretionary policies control information flow,
they must control access to object status attributes such as object
size, existence, locking mode, and subject status attributes such as
process-suspended or process-active indicators.
Separation-of-role policies can use existing access control functions
of an IT product to implement its required rules. For this reason,
separation-of-role policies can be rated using the same generic levels
of subject and object granularity and scope as those used for
discretionary and non- discretionary policies (discussed below and in
Appendix C). In their simplest form, access control components
implementing separation of role policies are rated by the separation
of unprivileged subjects from those with administrative
responsibilities. These component requirements include separation of
product resources, of data, and of administrator-controlled policy
attributes. The rating will take into account the granularity of
separation between unprivileged subjects and those with administrative
responsibilities.
In rating the access control components, four levels are identified
using the definition of policies in Appendix C. The component rating
reflected by these levels is based on the scope, granularity, and
coverage of access control requirements. The choice of requirements at
each level is largely guided by the access control characteristics of
current commercially available products and by the goal of retaining
the ability to harmonize these requirements with other existing
standards.
Level AC-1 represents a minimal level of policy definition and
enforcement. That is, the authorization rules apply to a defined
subset of subjects and objects, and the administration of policy
(i.e., access control) attributes cover only a subset of the functions
defined at higher levels. Level AC-2 extends the coverage of access
control policies and associated attributes of level AC-1 by
recognizing that multiple policies could be supported within the same
product. This level also extends the coverage of attribute
administration largely to reflect object import and export. Level AC-3
enhances the scope of access control to all subjects and objects.
Instead of referring to only a defined subset of subjects and objects,
the requirements of this level refer to all subjects and objects. If
non-discretionary policies that aim at controlling information flow
are supported, then the requirement granularity at this level is
extended to include all subject and object policy and status
attributes. This level of access control is appropriate when
non-discretionary policies are used that support information flow
control. In such environments, lack of access control to subject and
object status variables constitute a significant source of covert
channels. However, this level retains the ability to define
authorization and attribute administration on a per type-of-object
basis. Level AC-4 extends the requirement coverage to include time-
and location-based access controls, as well as inclusion and exclusion
of user access rights whenever groups or roles are used. This level
also extends the requirements for object and subject creation and
destruction, adding explicit authorization, inheritance, space
availability, and attribute inheritance conditions. It is expected
that this level of access control would be used in products where
fine-grain access control policies are required.
AC-1 Minimal Access Control
1. Definition of Access Control Attributes
The TCB shall define and protect access control attributes for
subjects and objects. Subject attributes shall include named
individuals or defined groups or both. Object attributes shall include
defined access rights (e.g., read, write, execute) that can be
assigned to subject attributes.
2. Administration of Access Control Attributes.
The TCB shall define and enforce rules for assignment and modification
of access control attributes for subjects and objects. The effect of
these rules shall be that access permission to an object by users not
already possessing access permission is assigned only by authorized
users. These rules shall allow authorized users to specify and
control sharing of objects by named individuals or defined groups of
individuals, or by both, and shall provide controls to limit
propagation of access rights. These controls shall be capable of
including or excluding access to the granularity of a single user.
If different rules of assignment and modification of access control
attributes apply to different subjects and/or objects, the totality of
these rules shall be shown to support the defined policy.
3. Authorization of Subject References to Objects
The TCB shall define and enforce authorization rules for the mediation
of subject references to objects. These rules shall be based on the
access control attributes of subjects and objects. These rules shall,
either by explicit user action or by default, provide that objects are
protected from unauthorized access.
The scope of the authorization rules shall include a defined subset of
the product's subjects and objects and associated access control
attributes. The coverage of authorization rules shall specify the
types of objects and subjects to which these rules apply. If different
rules apply to different subjects and objects, the totality of these
rules shall be shown to support the defined policy.
4. Subject and Object Creation and Destruction
The TCB shall control the creation and destruction of subjects and
objects. These controls shall include object reuse. That is, all
authorizations to the information contained within a storage object
shall be revoked prior to initial assignment, allocation or
reallocation to a subject from the TCB's pool of unused storage
objects; information, including encrypted representations of
information, produced by a prior subjects' actions shall be
unavailable to any subject that obtains access to an object that has
been released back to the system.
5. Object Encapsulation
If the TCB supports mechanisms for object encapsulation, controls must
be available for: (1) access authorization to encapsulated objects;
(2) creation of encapsulated subsystems by users; and (3) invocation
of encapsulated subsystems.
AC-2 Basic Access Control
1. Definition of Access Control Attributes
The TCB shall define and protect access control attributes for
subjects and objects. Subject attributes shall include named
individuals or defined groups or both. Object attributes shall include
defined access rights (e.g., read, write, execute) that can be
assigned to subject attributes. If multiple access control policies
are supported, the access control attributes corresponding to each
individual policy shall be identified.
The subject and object attributes shall accurately reflect the
sensitivity and/or integrity of the subject or object.
2. Administration of Access Control Attributes
The TCB shall define and enforce rules for assignment and modification
of access control attributes for subjects and objects. The effect of
these rules shall be that access permission to an object by users not
already possessing access permission is assigned only by authorized
users. These rules shall allow authorized users to specify and
control sharing of objects by named individuals or defined groups of
individuals, or by both, and shall provide controls to limit
propagation of access rights. These controls shall be capable of
including or excluding access to the granularity of a single user.
The rules for assignment and modification of access control attributes
shall include those for attribute assignment to objects during import
and export operations (e.g., import of non-labeled sensitive data,
export of labeled information). If different rules of assignment and
modification of access control attributes apply to different subjects
and/or objects, the totality of these rules shall be shown to support
the defined policy.
3. Authorization of Subject References to Objects
The TCB shall define and enforce authorization rules for the mediation
of subject references to objects. These rules shall be based on the
access control attributes of subjects and objects. These rules shall,
either by explicit user action or by default, provide that objects are
protected from unauthorized access.
The scope of the authorization rules shall include a defined subset of
the product's subjects and objects and associated access control
attributes. The coverage of authorization rules shall specify the
types of objects and subjects to which these rules apply. If different
rules apply to different subjects and objects, the totality of these
rules shall be shown to support the defined policy.
If multiple policies are supported, the authorization rules for each
policy shall be defined separately. The TCB shall define and enforce
the composition of policies, including the enforcement of the
authorization rules (e.g., subject and object type coverage,
enforcement precedence).
4. Subject and Object Creation and Destruction
The TCB shall control the creation and destruction of subjects and
objects. These controls shall include object reuse. That is, all
authorizations to the information contained within a storage object
shall be revoked prior to initial assignment, allocation or
reallocation to a subject from the TCB's pool of unused storage
objects; information, including encrypted representations of
information, produced by a prior subjects' actions shall be
unavailable to any subject that obtains access to an object that has
been released back to the system.
5. Object Encapsulation
If the TCB supports mechanisms for object encapsulation, controls must
be available for: (1) access authorization to encapsulated objects;
(2) creation of encapsulated subsystems by users; and (3) invocation
of encapsulated subsystems
AC-3 Extended Access Control
1. Definition of Access Control Attributes
The TCB shall define and protect access control attributes for
subjects and objects. Subject attributes shall include named
individuals or defined groups or both. Object attributes shall include
defined access rights (e.g., read, write, execute) that can be
assigned to subject attributes. If multiple access control policies
are supported, the access control attributes corresponding to each
individual policy shall be identified.
The subject and object attributes shall accurately reflect the
sensitivity and/or integrity of the subject or object. The TCB shall
immediately notify a terminal user of each attribute change of any
subject associated with that user during an interactive session that
reflects a change in the sensitivity or integrity of that session
(e.g., a change of the user's security level). A terminal user shall
be able to query the TCB as desired for a display of the subject's
complete set of access control attributes (e.g., the complete
sensitivity label).
The TCB shall support the assignment of access control attributes
(e.g., minimum and maximum security levels) to all attached physical
devices. These attributes shall be used by the TCB to enforce
constraints imposed by the physical environments in which the devices
are located.
2. Administration of Access Control Attributes
The TCB shall define and enforce rules for assignment and modification
of access control attributes for subjects and objects. The effect of
these rules shall be that access permission to an object by users not
already possessing access permission is assigned only by authorized
users. These rules shall allow authorized users to specify and
control sharing of objects by named individuals or defined groups of
individuals, or by both, and shall provide controls to limit
propagation of access rights. These controls shall be capable of
including or excluding access to the granularity of a single user.
The rules for assignment and modification of access control attributes
shall include those for attribute assignment to objects during import
and export operations (e.g., import of non-labeled sensitive data,
export of labeled information). If different rules of assignment and
modification of access control attributes apply to different subjects
and/or objects, the totality of these rules shall be shown to support
the defined policy.
3. Authorization of Subject References to Objects
The TCB shall define and enforce authorization rules for the mediation
of subject references to objects. These rules shall be based on the
access control attributes of subjects and objects. These rules shall,
either by explicit user action or by default, provide that objects are
protected from unauthorized access.
The scope of the authorization rules shall include all subjects,
storage objects (e.g., processes, segments, devices) and associated
access control attributes that are directly or indirectly accessible
to subjects external to the TCB. If non-discretionary access control
policies are used that aim to control the flow of information between
subjects, the scope of the authorization rules shall also include all
policy and status attributes of subjects and storage objects (e.g.,
quotas, object existence, size, access time, creation and modification
time, locked/unlocked). If different rules apply to different
subjects and objects, the totality of these rules shall be shown to
support the defined policy.
If multiple policies are supported, the authorization rules for each
policy shall be defined separately. The TCB shall define and enforce
the composition of policies, including the enforcement of the
authorization rules (e.g., subject and object type coverage,
enforcement precedence).
4. Subject and Object Creation and Destruction
The TCB shall control the creation and destruction of subjects and
objects. These controls shall include object reuse. That is, all
authorizations to the information contained within a storage object
shall be revoked prior to initial assignment, allocation, reallocation
to a subject from the TCB's pool of unused storage objects;
information, including encrypted representations of information,
produced by a prior subjects' actions shall be unavailable to any
subject that obtains access to an object that has been released back
to the system.
5. Object Encapsulation
If the TCB supports mechanisms for object encapsulation, controls must
be available for: (1) access authorization to encapsulated objects;
(2) creation of encapsulated subsystems by users; and (3) invocation
of encapsulated subsystems.
AC-4 Fine-Grain Access Control
1. Definition of Access Control Attributes
The TCB shall define and protect access control attributes for
subjects and objects. Subject attributes shall include named
individuals or defined groups or both. Object attributes shall include
defined access rights (e.g., read, write, execute) that can be
assigned to subject attributes. If multiple access control policies
are supported, the access control attributes corresponding to each
individual policy shall be identified. The subject's access control
attributes also shall include time and location attributes that can be
assigned to authenticated user identities.
The subject and object attributes shall accurately reflect the
sensitivity and/or integrity of the subject or object. The TCB shall
immediately notify a terminal user of each attribute change of any
subject associated with that user during an interactive session that
reflects a change in the sensitivity or integrity of that session
(e.g., a change of the user's security level). A terminal user shall
be able to query the TCB as desired for a display of the subject's
complete set of access control attributes (e.g., the complete
sensitivity label).
The TCB shall support the assignment of access control attributes
(e.g., device labels) to all attached physical devices. These
attributes shall be used by the TCB to enforce constraints imposed by
the physical environments in which the devices are located.
2. Administration of Access Control Attributes
The TCB shall define and enforce rules for assignment and modification
of access control attributes for subjects and objects. The effect of
these rules shall be that access permission to an object by users not
already possessing access permission is assigned only by authorized
users. These rules shall allow authorized users to specify and
control sharing of objects by named individuals or defined groups of
individuals, or by both, and shall provide controls to limit
propagation of access rights (i.e., these rules shall define the
distribution, revocation, and review of access control attributes).
The controls defined by these rules shall be capable of specifying for
each named object, a list of individuals and a list of groups of named
individuals, with their respective access rights to that object.
Furthermore, for each named object, it shall be possible to specify a
list of named individuals and a list of groups of named individuals
for which no access to the object is given. These controls shall also
be capable of specifying access-time dependency (i.e., the effect of
the distribution and revocation of access control attributes take
place at a certain time and shall last for a specified period of
time), and/or access-location dependency (i.e., shall specify the
locations from which the distribution and revocation of privileges
shall take place).
The rules for assignment and modification of access control attributes
shall include those for attribute assignment to objects during import
and export operations (e.g., import of non-labeled sensitive data,
export of labeled information). If different rules of assignment and
modification of access control attributes apply to different subjects
and/or objects, the totality of these rules shall be shown to support
the defined policy.
3. Authorization of Subject References to Objects
The TCB shall define and enforce authorization rules for the mediation
of subject references to objects. These rules shall be based on the
access control attributes of subjects and objects. These rules shall,
either by explicit user action or by default, provide that objects are
protected from unauthorized access. These rules shall include
time-of-access and location-of-access controls defined for subjects
and objects.
The scope of the authorization rules shall include all subjects,
storage objects (e.g., processes, segments, devices) and associated
access control attributes that are directly or indirectly accessible
to subjects external to the TCB. If non-discretionary access control
policies are used that aim to control the flow of information between
subjects, the scope of the authorization rules shall also include all
policy and status attributes of subjects and storage objects (e.g.,
quotas, object existence, size, access time, creation and modification
time, locked/unlocked). If different rules apply to different
subjects and objects, the totality of these rules shall be shown to
support the defined policy.
If multiple policies are supported, the authorization rules for each
policy shall be defined separately. The TCB shall define and enforce
the composition of policies, including the enforcement of the
authorization rules (e.g., subject and object type coverage,
enforcement precedence).
4. Subject and Object Creation and Destruction
The TCB shall define and enforce rules for the creation and
destruction of subjects and objects. The controls defined by these
rules shall be capable of specifying for each subject and object: (1)
creation and destruction authorization; (2) object reuse; (3) space
availability (i.e., storage space shall be available for the creation
of a subject and object); (4) default subject or object attributes and
attribute inheritance rules (if any).
The rules for subject and object creation and destruction shall
specify their coverage in terms of the types of objects and subjects
to which they apply. If different rules and conditions apply to
different subjects and objects, the totality of these rules shall be
shown to support the defined policy properties. If multiple policies
are supported, these rules shall define the composition of policies
and how the conditions of the subject and object creation and
destruction are enforced (e.g., subject and object type coverage,
enforcement precedence).
5. Object Encapsulation
If the TCB supports mechanisms for object encapsulation, controls must
be available for: (1) access authorization to encapsulated objects;
(2) creation of encapsulated subsystems by users; and (3) invocation
of encapsulated subsystems.
4.3.5.1 Rated Covert Channel Handling Components
Covert channel handling requires that functions must be added to the
software and/or hardware and firmware elements of a TCB to help deter
the use of, limit the bandwidth of, or eliminate, covert channels. The
rating of the covert channel handling components is based both on the
scope of these requirements and their coverage (e.g., elimination,
bandwidth limitation, audit, administrative control, applicability to
timing channels or storage channels). The scope of level CCH- 1 is
limited to storage channels and the coverage is limited to functions
that deter covert channel use. Coverage is extended at level CCH-2 by
the addition of requirements of bandwidth limitation and storage
channel elimination for common system configurations. Level CCH-3
extends the requirements of level CCH-2 by including all channels, not
just covert storage channels.
CCH-1 Deterrence of Storage Channel Use
1. The TCB and privileged applications shall include functions
that help audit the use of covert storage channels. These functions
shall enable the identification of the transmitter, receiver, and
specific covert channels used (e.g., TCB and privileged application
element used to transmit information).
2. The functions added to the TCB and privileged applications for
storage channel auditing shall be identified for each channel and
shall be available in common product configurations. If audit
functions are not added to certain storage channels (e.g., hardware
storage channels), evidence must be provided to justify why these
channels do not represent a security threat for the intended use of
the product.
CCH-2 Storage Channel Audit and Bandwidth Limitation
1. The TCB and privileged applications shall include functions
that help audit the use of covert storage channels. These functions
shall enable the identification of the transmitter, receiver, and
specific covert channels used (e.g., TCB and privileged application
element used to transmit information). TCB functions that help limit
the bandwidth and/or eliminate covert storage channels shall also be
provided. The bandwidth limits for each channel shall be settable by
system administrators.
2. The functions added to the TCB and privileged applications for
storage channel auditing shall be identified for each channel and
shall be available in common product configurations. If audit
functions are not added to certain storage channels (e.g., hardware
storage channels), evidence must be provided to justify why these
channels do not represent a security threat for the intended use of
the product. TCB and privileged application functions that help limit
the bandwidth and/or eliminate covert storage channels shall also be
available in common product configurations.
If channel bandwidth limitation and channel elimination functions are
not added to certain storage channels (e.g., hardware storage
channels), evidence must be provided to justify why these channels do
not represent a security threat for the intended use of the product.
CCH-3 Timing Channel Audit and Bandwidth Limitation
1. The TCB and privileged applications shall include functions
that help audit the use of covert storage channels. These functions
shall enable the identification of the transmitter, receiver, and
specific covert channels used (e.g., TCB and privileged application
element used to transmit information). TCB functions that help limit
the bandwidth and/or eliminate covert storage channels shall also be
provided. The bandwidth limits for each channel shall be settable by
system administrators.
2. The functions added to the TCB and privileged applications for
storage channel auditing shall be identified for each channel and
shall be available in common product configurations. If audit
functions are not added to certain storage channels (e.g., hardware
storage channels), evidence must be provided to justify why these
channels do not represent a security threat for the intended use of
the product. TCB and privileged application functions that help limit
the bandwidth and/or eliminate covert storage or timing channels shall
also be available in common product configurations.
If channel bandwidth limitation and channel elimination functions are
not added to certain storage or timing channels (e.g., hardware
channels), evidence must be provided to justify why these channels do
not represent a security threat for the intended use of the product.
4.3.6 Rated Resource Allocation Components
The resource allocation component rating is concerned with the extent
and strength of containment control exerted over the availability and
distribution of product resources. The resource allocation components
are rated based on the scope of containment (e.g., defined set of
resources versus all resources) and the coverage of containment (e.g.,
resource restrictions, control, priorities, audit).
Level AR-1 defines basic requirements of resource allocation
restrictions in terms of a specified subset of system resources,
subjects and objects. Level AR-2 extends the scope of resource control
to all system resources and increases the coverage of the resource
allocation features by requiring the auditing and signaling of
attempted violations of resource allocation limits (or quotas). Level
AR-3 further extends the coverage of the resource allocation features
by introducing the requirement for prioritized allocation.
AR-1 Resource Restrictions
The TCB shall provide the capability to place restrictions on the
number of subjects and objects a user may have allocated at any given
time. The TCB shall control a defined set of system resources (e.g.,
memory, disk space) such that no one individual user can deny access
to another user's subject and object space. All subjects, objects, and
resources shall be defined with default space or time quotas and
quantity-of- resources attributes.
AR-2 Complete Resource Control
The TCB shall provide the capability to place restrictions on the
number of subjects and objects a user may have allocated at any given
time. The TCB shall control a defined set of system resources (e.g.,
memory, disk space) such that no one individual user can deny access
to another user's subject and object space. All subjects, objects, and
resources shall be defined with default space or time quota and
number-of- resources attributes. An individual user shall be unable to
deny access to any system resource by means of circumventing
resource-allocation limits, or otherwise manipulating the TCB, so as
to restrict the TCB's ability to offer services to other users and
objects.
AR-3 Prioritized Resource Allocations
The TCB shall provide the capability to place restrictions on the
number of subjects and objects a user may have allocated at any given
time. The TCB shall control a defined set of system resources (e.g.,
memory, disk space) such that no one individual user can deny access
to another user's subject and object space. All subjects, objects, and
resources shall be defined with default space or time quotas and
quantity-of- resources attributes. An individual user shall be unable
to deny access to any system resource by means of circumventing
resource-allocation limits, or otherwise manipulating the TCB, so as
to restrict the TCB's ability to offer services to other users and
objects. The TCB shall include resource-allocation priorities among
the subject attributes. Each subject shall be granted a priority
against which the TCB shall allocate resources. The TCB shall mediate
resource- allocation priorities in such a manner that access
requirements of the TCB and high-priority subjects shall be fulfilled
first, in a prioritized manner. All resources within the TCB
(hardware and software) shall be controlled in pre-assigned blocks.
4.3.7 Rated Security Management Components
The rating of the security-management components is based primarily on
the coverage, and strength of these components. For example, level
SM-3 is considered to be stronger than level SM-2 because the
separation of administrative and operator roles offers added
resistance to accidents or misdeeds. Level SM-3 also extends the
coverage of level SM-2 because it reflects the use of a wider policy
coverage. Level SM-4 extends the coverage and strength of level SM-3
because (1) it requires the availability of trusted tools for security
management (e.g., tools offering a graphical interface to the
administrator, tools enhancing system administration, and tools
enabling the administrator to perform consistency checking), and (2)
it further limits through fine-grain separation of administrative
roles the potential damage that can be caused by error or misdeed.
SM-1 Minimal Security Management
1. The TCB shall provide an installation mechanism for the
setting and updating of its configuration parameters, and for the
initialization of its protection-relevant data structures before any
user or administrator policy attributes are defined. It shall allow
the configuration of TCB internal databases and tables.
2. The TCB shall provide protected mechanisms for displaying and
modifying the security policy parameters.
3. The TCB shall provide protected mechanisms for manually
displaying, modifying, or deleting user registration and account
parameters. These parameters shall include unique user identifiers,
their account, and their associated user name and affiliation. The TCB
shall allow the manual enabling and disabling of user identities
and/or accounts.
4. The TCB shall provide protected mechanisms for routine control
and maintenance of system resources. That is, it shall allow the
enabling and disabling of peripheral devices, mounting of removable
storage media, backing-up and recovering user objects; maintaining the
TCB hardware and software elements (e.g., on site testing); and
starting and shutting down the system.
5. The use of the protected mechanisms for system administration
shall be limited to authorized administrative users.
SM-2 Basic Security Management
1. The TCB shall provide an installation mechanism for the
setting and updating of its configuration parameters, and for the
initialization of its protection-relevant data structures before any
user or administrator policy attributes are defined. It shall allow
the configuration of TCB internal databases and tables.
The TCB shall distinguish between normal mode of operation and
maintenance mode, and shall provide a maintenance-mode mechanism for
recovery and system start-up.
2. The TCB shall provide protected mechanisms for displaying and
modifying the security policy parameters. These parameters shall
include identification, authentication, system entry and access
control parameters for the entire system and for individual users.
The TCB shall have a capability to define the identification and
authentication policy on a system-wide basis (e.g., password minimum
and maximum lifetime, password length and complexity parameters). The
TCB mechanisms shall have the capability to limit: (1) maximum period
of interactive session inactivity, (2) maximum login or session time,
and (3) successive unsuccessful attempts to log in to the system.
If availability policies are supported, the TCB shall provide a
mechanism to control the availability of system resources via resource
quotas and quantity-of-resources limits.
3. The TCB shall provide protected mechanisms for manually
displaying, modifying, or deleting user registration and account
parameters. These parameters shall include unique user identifiers,
their account, and their associated user name and affiliation. The TCB
shall allow the manual enabling and disabling of user identities
and/or accounts.
The TCB shall provide a means to uniquely identify security policy
attributes. It shall also provide a means of listing all these
attributes for a user, and all the users associated with an attribute.
It shall be capable of defining and maintaining the security policy
attributes for subjects including: defining and maintaining privileges
for privileged subjects, discretionary and non-discretionary
attributes (e.g., definition and maintenance of group, role, and
secrecy and/or integrity level membership), and centralized
distribution, review and revocation of policy attributes.
4. The TCB shall provide protected mechanisms for routine control
and maintenance of system resources.It shall allow the enabling and
disabling of peripheral devices, mounting of removable storage media,
backing-up and recovering user objects; maintaining the TCB hardware
and software elements (e.g., on site testing); and starting and
shutting down the system.
5. The use of the protected mechanisms for system administration
shall be limited to authorized administrative users.
SM-3 Policy-oriented Security Management
1. The TCB shall provide an installation mechanism for the
setting and updating of its configuration parameters, and for the
initialization of its protection-relevant data structures before any
user or administrator policy attributes are defined. It shall allow
the configuration of TCB internal databases and tables.
The TCB shall distinguish between normal mode of operation and
maintenance mode, and shall provide a maintenance-mode mechanism for
recovery and system start-up. This mechanism shall include a means to
initialize administrative privileges and administrative
identification, authentication, and system-entry attributes.
2. The TCB shall provide protected mechanisms for displaying and
modifying the security policy parameters. These parameters shall
include identification, authentication, system entry and access
control parameters for the entire system and for individual users.
The TCB shall have a capability to define the identification
and authentication policy on a system-wide basis (e.g., password
minimum and maximum lifetime, password length and complexity
parameters). The TCB mechanisms shall have the capability to limit:
(1) maximum period of interactive session inactivity, (2) maximum
login or session time, and (3) successive unsuccessful attempts to log
in to the system. The TCB shall provide an administrative capability
to specify the authentication method on a per policy- attribute basis
whenever multiple identification and authentication methods are used;
e.g., via user passwords, tokens, or biometrics.
If the TCB is designed to support multiple login sessions per
user identity, the administrators shall be able to limit the number of
simultaneous login sessions on an authorization-attribute basis.
The TCB shall also have a capability to limit the successive
unsuccessful attempts to login from a specific port of entry, and/or
with a specific user identity or account.
If availability policies are supported, the TCB shall provide a
mechanism to control the availability of system resources via resource
quotas and quantity-of-resources limits.
3. The TCB shall provide protected mechanisms for manually
displaying, modifying, or deleting user registration and account
parameters. These parameters shall include unique user identifiers,
their account, and their associated user name and affiliation. The TCB
shall allow the automatic disabling of user identities and/ or
accounts, after a period during which the identity and/or account have
not been used. The time period shall be administrator specified, with
a specified default provided. The TCB shall allow the automatic
re-enabling of disabled user identities and/or accounts after an
administrator-specified period of time.
The TCB shall provide a means to uniquely identify security policy
attributes. It shall also provide a means of listing all these
attributes for a user, and all the users associated with an attribute.
It shall be capable of defining and maintaining the security policy
attributes for subjects including: defining and maintaining privileges
for privileged subjects, discretionary and non-discretionary
attributes (e.g., definition and maintenance of group, role, and
secrecy and/or integrity level membership), and centralized
distribution, review and revocation of policy attributes.
4. The TCB shall support separate operator and administrator
functions. The operator functions shall be restricted to those
necessary for performing routine operations. The operator functions
shall allow the enabling and disabling of peripheral devices, mounting
of removable storage media, backing-up and recovering user objects;
maintaining the TCB hardware and software elements (e.g., on-site
testing); and starting and shutting down the system.
5. The use of the protected mechanisms for system administration
shall be limited to authorized administrative users.
SM-4 Extended Security Management
1. The TCB shall provide an installation mechanism for the
setting and updating of its configuration parameters, and for the
initialization of its protection-relevant data structures before any
user or administrator policy attributes are defined. It shall allow
the configuration of TCB internal databases and tables.
The TCB shall distinguish between normal mode of operation and
maintenance mode, and shall provide a maintenance-mode mechanism for
recovery and system start-up. This mechanism shall include a means to
initialize administrative privileges and administrative
identification, authentication, and system-entry attributes.
2. The TCB shall provide protected mechanisms for displaying and
modifying the security policy parameters. These parameters shall
include identification, authentication, system entry and access
control parameters for the entire system and for individual users.
The TCB shall have a capability to define the identification
and authentication policy on a system-wide basis (e.g., password
minimum and maximum lifetime, password length and complexity
parameters). The TCB mechanisms shall have the capability to limit:
(1) maximum period of interactive session inactivity, (2) maximum
login or session time, and (3) successive unsuccessful attempts to log
in to the system. The TCB shall provide an administrative capability
to specify the authentication method on a per policy- attribute basis
whenever multiple identification and authentication methods are used;
e.g., via user passwords, tokens, or biometrics.
If the TCB is designed to support multiple login sessions per
user identity, the administrators shall be able to limit the number of
simultaneous login sessions on an authorization-attribute basis.
The TCB shall also have a capability to limit the successive
unsuccessful attempts to login from a specific port of entry, and/or
with a specific user identity or account.
If availability policies are supported, the TCB shall provide
a mechanism to control the availability of system resources via
resource quotas and quantity-of-resources limits.
3. The TCB shall provide protected mechanisms for manually
displaying, modifying, or deleting user registration and account
parameters. These parameters shall include unique user identifiers,
their account, and their associated user name and affiliation. The TCB
shall allow the automatic disabling of user identities and/or
accounts, after a period during which the identity and/or account have
not been used. The time period shall be administrator specified, with
a specified default provided. The TCB shall allow the automatic
re-enabling of disabled user identities and/or accounts after an
administrator-specified period of time.
The TCB shall provide a means to uniquely identify security
policy attributes. It shall also provide a means of listing all these
attributes for a user, and all the users associated with an attribute.
It shall be capable of defining and maintaining the security policy
attributes for subjects including: defining and maintaining privileges
for privileged subjects, discretionary and non-discretionary
attributes (e.g., definition and maintenance of group, role, and
secrecy and/or integrity level membership), and centralized
distribution, review and revocation of policy attributes.
The TCB shall provide trusted tools for system administration.
These shall include: tools for verifying the consistency of the user
registration and system configuration; tools for verifying the proper
system installation; tools for verifying that the TCB does not contain
extraneous programs and data.
The TCB shall include tools for determining whether the TCB is
in a secure initial state after start-up and recovery.
The TCB shall include tools for verifying the consistency of
users, subject, and objects policy attributes (e.g., cross checks
between subject and object attributes and registered user attributes).
4. The TCB shall support separate operator and administrator
functions. The operator functions shall be restricted to those
necessary for performing routine operations. The operator functions
shall allow the enabling and disabling of peripheral devices, mounting
of removable storage media, backing-up and recovering user objects;
maintaining the TCB hardware and software elements (e.g., on-site
testing); and starting and shutting down the system. The
administrative functions shall support separate security administrator
and auditor roles. The TCB shall enable the administrators to perform
their functions only after taking a distinct auditable action to
assume an administrator role. Non- security functions that can be
performed in the security administrative role shall be limited
strictly to those essential to performing the security role
effectively.
5. The use of the protected mechanisms and tools for system
administration shall be limited to authorized administrative users.
4.3.8 Rated Reference Mediation Components
The rating of the reference mediation components are largely based on
scope and granularity of references. At level RM-1, the scope of
mediation is limited to a defined subject and object subset (i.e., the
same subset as that defined by the access control components). At
level RM-2, the scope of mediation is extended to the complete set of
subjects and objects. At level RM-3, the granularity of references
includes defined subsets, or all: (1) objects, (2) object policy
attributes (e.g., access rights, security levels, quotas); and (3)
object status attributes (e.g., object existence, length, locking
state). Level RM-4 is derived by requiring a model of privilege
mediation. This level extends the coverage of level RM-3 and is
intended for use in a TCB that can be extended with privileged
processes of various applications.
RM-1 Mediation of References to a Defined Subject/Object Subset
1. The TCB shall mediate all references to subjects, objects,
resources, and services (e.g., TCB functions) described in the TCB
specifications. The mediation shall ensure that all references are
directed to the appropriate security-policy functions.
2. Reference mediation shall include references to the defined
subset of subjects, objects, and resources protected under the TCB
security policy, and to their policy attributes (e.g., access rights,
security and/or integrity levels, role identifiers).
3. References issued by privileged subjects shall be mediated in
accordance with the policy attributes defined for those subjects.
RM-2 Mediation of References to all Subjects and Objects
1. The TCB shall mediate all references to subjects, objects,
resources, and services (e.g., TCB functions) described in the TCB
specifications. The mediation shall ensure that all references are
directed to the appropriate security-policy functions.
2. Reference mediation shall include control of references to
all subjects, objects, and resources protected under the TCB security
policy, and to their policy attributes (e.g., access rights, security
and/or integrity levels, role identifiers, quotas).
3. References issued by privileged subjects shall be mediated in
accordance with the policy attributes defined for those subjects.
RM-3 Mediation of References to Subject and Object Attributes
1. The TCB shall mediate all references to subjects, objects,
resources, and services (e.g., TCB functions) described in the TCB
specifications. The mediation shall ensure that all references are
directed to the appropriate security-policy functions.
2. Reference mediation shall include control of references to
all subjects, objects, and resources protected under the TCB security
policy, to their policy (e.g., access rights, security and/or
integrity levels, role identifiers, quotas) and status attributes
(e.g., existence, length, locking state).
3. References issued by privileged subjects shall be mediated in
accordance with the policy attributes defined for those subjects.
RM-4 Mediation of Privileged Subject References
1. The TCB shall mediate all references to subjects, objects,
resources, and services (e.g., TCB functions) described in the TCB
specifications. The mediation shall ensure that all references are
directed to the appropriate security-policy functions.
2. Reference mediation shall include control of references to
all subjects, objects, and resources protected under the TCB security
policy, to their policy (e.g., access rights, security and/or
integrity levels, role identifiers, quotas) and status attributes
(e.g., existence, length, locking state).
3. References issued by privileged subjects shall be mediated in
accordance with the privilege model defined for those subjects.
4.3.9 Rated Logical TCB Protection Components
The rating of the TCB protection components is based on the coverage
of TCB requirements. Level P-1 of TCB protection has two basic
requirements, namely TCB isolation and noncircumventability of TCB
isolation functions. Level P-2 extends the coverage of level P-1 with
the requirements of ensuring the consistency of TCB global variables
and the elimination of undesirable TCB dependencies on unprivileged
user actions. These additional requirements help eliminate large
classes of TCB penetration means. Level P-3 eliminates an additional
class of penetration means that is generally more difficult to exploit
than those classes addressed in the previous two levels. The intent of
these levels is to reflect increasingly better functions for TCB
penetration resistance.
P-1 Basic TCB Isolation
The TCB shall maintain a domain for its own execution that protects it
from external interference and tampering (e.g., by reading or
modification of its code and data structures). The protection of the
TCB shall provide TCB isolation and noncircumventability of TCB
isolation functions as follows:
1. TCB Isolation requires that (1) the address spaces of the
TCB and those of unprivileged subjects are separated such that users,
or unprivileged subjects operating on their behalf, cannot read or
modify TCB data structures or code, (2) the transfers between TCB and
non-TCB domains are controlled such that arbitrary entry to or return
from the TCB are not possible; and (3) the user or application
parameters passed to the TCB by addresses are validated with respect
to the TCB address space, and those passed by value are validated with
respect to the values expected by the TCB.
2. Noncircumventability of TCB isolation functions requires
that the permission to objects (and/or to non-TCB data) passed as
parameters to the TCB are validated with respect to the permissions
required by the TCB, and references to TCB objects implementing TCB
isolation functions are mediated by the TCB.
P-2 TCB Isolation and Consistency
The TCB shall maintain a domain for its own execution that protects it
from external interference and tampering (e.g., by reading or
modification of its code and data structures). The protection of the
TCB shall provide TCB isolation and noncircumventability of TCB
isolation functions as follows:
1. TCB Isolation requires that (1) the address spaces of the
TCB and those of unprivileged subjects are separated such that users,
or unprivileged subjects operating on their behalf, cannot read or
modify TCB data structures or code, (2) the transfers between TCB and
non-TCB domains are controlled such that arbitrary entry to or return
from the TCB are not possible; and (3) the user or application
parameters passed to the TCB by addresses are validated with respect
to the TCB address space, and those passed by value are validated with
respect to the values expected by the TCB.
2. Non-circumventability of TCB isolation functions requires
that the permission to objects (and/or to non-TCB data) passed as
parameters to the TCB are validated with respect to the permissions
required by the TCB, and references to TCB objects implementing TCB
isolation functions are mediated by the TCB.
TCB protection shall also maintain the consistency of TCB global
variables and eliminate undesirable dependencies of the TCB on
unprivileged subject or user actions.
3. Consistency of TCB global variables requires that
consistency conditions defined over TCB internal variables, objects,
and functions hold before and after any TCB invocation.
4. Elimination of undesirable dependencies of the TCB on
unprivileged subject actions requires that any TCB invocation by an
unprivileged subject (or user) input to a TCB call may not place the
TCB in a state such that it is unable to respond to communication
initiated by other users.
P-3 TCB Isolation and Timing Consistency
The TCB shall maintain a domain for its own execution that protects it
from external interference and tampering (e.g., by reading or
modification of its code and data structures). The protection of the
TCB shall provide TCB isolation and noncircumventability of TCB
isolation functions as follows:
1. TCB Isolation requires that (1) the address spaces of the
TCB and those of unprivileged subjects are separated such that users,
or unprivileged subjects operating on their behalf, cannot read or
modify TCB data structures or code, (2) the transfers between TCB and
non-TCB domains are controlled such that arbitrary entry to or return
from the TCB are not possible; and (3) the user or application
parameters passed to the TCB by addresses are validated with respect
to the TCB address space, and those passed by value are validated with
respect to the values expected by the TCB.
2. Non-circumventability of TCB isolation functions requires
that the permission to objects (and/or to non-TCB data) passed as
parameters to the TCB are validated with respect to the permissions
required by the TCB, and references to TCB objects implementing TCB
isolation functions are mediated by the TCB.
TCB protection shall also maintain the consistency of TCB global
variables and eliminate undesirable dependencies of the TCB on
unprivileged subject or user actions.
3. Consistency of TCB global variables requires that
consistency conditions defined over TCB internal variables, objects,
and functions hold before and after any TCB invocation.
4. Elimination of undesirable dependencies of the TCB on
unprivileged subject actions requires that any TCB invocation by an
unprivileged subject (or user) input to a TCB call may not place the
TCB in a state such that it is unable to respond to communication
initiated by other users.
Furthermore, TCB protection shall maintain the timing consistency of
condition checks.
5. Timing consistency of condition checks requires that a
validation check holds at the instant when the TCB action depending on
that check is performed.
4.3.10 Rated Physical TCB Protection Components
The rating of the physical TCB protection is determined by the
coverage and strength of the physical protection requirements; i.e.,
on the ability to prevent, deter, detect, and counter physical attacks
against the product. Level PP-1 requires the availability of physical
protection functions and devices to support administrative and
environment measures of controlling access to the TCB of the product.
Level PP-2 extends the coverage of this requirement by specifying that
employed functions and devices shall have the ability to unambiguously
detect any attempt of physical tampering regardless of its outcome.
Level PP-3 increases the strength of the physical TCB protection by
requiring the use of physical countermeasures with well-defined work
factors. The intent of these requirements is to distinguish between
physical protection supporting administrative measures,
tamper-detection functions, and tamper-resistance functions.
PP-1 Administrative and Environment Protection
1. Administrative procedures and environmental features necessary for
establishing the physical security of a product's TCB shall be
defined.
2. Product functions and devices necessary to establish physical
control over the product's TCB shall be identified and provided.
PP-2 Detection of Physical Attack
1. Administrative procedures and environmental features necessary for
establishing the physical security of a product's TCB shall be
defined.
2. Product functions and devices necessary to establish physical
control over the product's TCB shall be identified and provided. TCB
devices allowing the unambiguous detection of physical tampering shall
be employed. These devices shall be shown to be physically
tamper-resistant and noncircumventable.
PP-3 Physical and Environmental Countermeasures
1. Administrative procedures and environmental features necessary for
establishing the physical security of a product's TCB shall be
defined.
2. Product functions and devices necessary to establish physical
control over the product's TCB shall be identified and provided. TCB
devices that provide countermeasures to physical tampering shall be
employed. The strength of these devices shall be determined based on
well-defined work factor parameters relevant to the supported
policies. For confidentiality policies, these devices shall resist
disclosure via theft, inspection of physical media, wiretapping,
and/or analysis of product emanations. For integrity policies, these
devices shall resist modification of hardware functionality and
modification of stored data via mechanical methods and/or electronic
jamming. For availability policies, these devices shall resist loss of
service via anticipated environmental stress (e.g., water damage,
fire, vibration, impact) or other forms of physical attack.
4.3.11 Rated TCB Self Checking Components
The TCB self-checking components are rated based on the scope of the
checking performed (i.e., hardware and/or firmware versus software)
and on the coverage of the checking methods (i.e., periodic or
continuous checking). At level SC-1, a minimal level of self-checking
is required (e.g., similar to those currently available on most
commercial workstations). Level SC-2 extends these requirements by
including power-on self tests, loadable tests, and operator-controlled
tests that are used to periodically validate the correct operation of
the TCB hardware and/or firmware elements. The scope of these tests is
extended at level SC-3 by the addition of configurable software and/or
firmware functions that perform periodic self tests. At level SC-4,
the self-test coverage is extended by requiring that hardware,
firmware, and/or software self tests be performed continuously during
the product operation.
SC-1 Minimal Self Checking
Hardware and/or software features shall be provided that can be used
to periodically validate the correct operation of the on-site hardware
and firmware elements of the TCB.
SC-2 Basic Self Checking
Hardware and/or software features shall be provided that can be used
to periodically validate the correct operation of the on-site hardware
and firmware elements of the TCB. These features shall include:
power-on tests, loadable tests, and operator-controlled tests.
The power-on tests shall test all basic components of the TCB hardware
and firmware elements including memory boards and memory
interconnections; data paths; busses; control logic and processor
registers; disk adapters; communication ports; system consoles, and
the keyboard speaker. These tests shall cover all components that are
necessary to run the loadable tests and the operator-controlled tests.
The loadable tests shall cover: processor components (e.g., arithmetic
and logic unit, floating point unit, instruction decode buffers,
interrupt controllers, register transfer bus, address translation
buffer, cache, and processor- to-memory bus controller); backplane
busses; memory controllers; and writable control memory for
operator-controlled and remote system- integrity testing.
Operator-controlled tests shall be able to initiate a series of
one-time or repeated tests, to log the results of these tests and, if
any fault is detected, to direct the integrity-test programs to
identify and isolate the failure.
SC-3 Software-Test Support
Hardware and/or software features shall be provided that can be used
to periodically validate the correct operation of the on-site hardware
and firmware elements of the TCB. These features shall include:
power-on tests, loadable tests, and operator-controlled tests.
The power-on tests shall test all basic components of the TCB hardware
and firmware elements including memory boards and memory
interconnections; data paths; busses; control logic and processor
registers; disk adapters; communication ports; system consoles, and
the keyboard speaker. These tests shall cover all components that are
necessary to run the loadable tests and the operator-controlled tests.
The loadable tests shall cover: processor components (e.g., arithmetic
and logic unit, floating point unit, instruction decode buffers,
interrupt controllers, register transfer bus, address translation
buffer, cache, and processor- to-memory bus controller); backplane
busses; memory controllers; and writable control memory for
operator-controlled and remote system- integrity testing.
Operator-controlled tests shall be able to initiate a series of
one-time or repeated tests, to log the results of these tests and, if
any fault is detected, to direct the integrity-test programs to
identify and isolate the failure.
Configurable software or firmware features shall be provided that can
be used to validate the correct operation of the on-site software
elements (i.e., code and data structures) of the TCB. These features
may include, but are not limited to, checksums and consistency checks
for TCB elements stored on storage media (e.g., disk-block consistency
conditions).
SC-4 Continuous Software-Test Support
Hardware and/or software features shall be provided that can be used
to periodically validate the correct operation of the on-site hardware
and firmware elements of the TCB. These features shall include:
power-on tests, loadable tests, and operator-controlled tests.
The power-on tests shall test all basic components of the TCB hardware
and firmware elements including memory boards and memory
interconnections; data paths; busses; control logic and processor
registers; disk adapters; communication ports; system consoles, and
the keyboard speaker. These tests shall cover all components that are
necessary to run the loadable tests and the operator-controlled tests.
The loadable tests shall cover: processor components (e.g., arithmetic
and logic unit, floating point unit, instruction decode buffers,
interrupt controllers, register transfer bus, address translation
buffer, cache, and processor- to-memory bus controller); backplane
busses; memory controllers; and writable control memory for
operator-controlled and remote system- integrity testing.
Operator-controlled tests shall be able to initiate a series of
one-time or repeated tests, to log the results of these tests and, if
any fault is detected, to direct the integrity-test programs to
identify and isolate the failure.
Configurable software or firmware features shall be provided that can
be used to validate the correct operation of the on-site software
elements (i.e., code and data structures) of the TCB. These features
may include, but are not limited to, checksums and consistency checks
for TCB elements stored on storage media (e.g., disk-block consistency
conditions).
Tests that detect possible inconsistencies of the TCB elements (i.e.,
data structures and code) shall be performed whenever the content or
structure of these elements are modified as consequence of a transient
failure during an unprivileged subject's action.
4.3.12 Rated TCB Start-Up and Recovery Components
The TCB start-up and recovery components are rated based on feature
coverage; i.e., whether manual (levels TR-1, TR-2) or automatic (level
TR-3) recovery and start-up in a secure state is provided, and whether
the loss of user objects during recovery can be minimized (level TR-5)
or just detected (level TR-4). Primitive forms of secure recovery,
where potentially all objects are lost during recovery, have a
narrower coverage than that intended to be provided by automated
procedures.
TR-1 Minimal Requirements for Recovery or Start-up
1. Procedures and/or mechanisms shall be provided to assure that,
after a TCB failure or other discontinuity, recovery without
protection compromise is obtained.
TR-2 Basic Requirements for Recovery or Start-up
1. Procedures and/or mechanisms shall be provided to assure that,
after a TCB failure or other discontinuity, recovery without
protection compromise is obtained.
2. If automated recovery and start-up is not possible, the TCB shall
enter a state where the only system access method is via
administrative interfaces, terminals, or procedures. Administrative
procedures shall exist to restore the system to a secure state (i.e.,
a state in which all the security-policy properties hold).
TR-3 Automated Recovery or Start-up
1. Procedures and/or mechanisms shall be provided to assure that,
after a TCB failure or other discontinuity, recovery without
protection compromise is obtained.
2. Automated procedures, under the control of the TCB, shall be
provided to assure that after a system failure, other discontinuity,
or start-up, a secure state is obtained without undue loss of system
or user objects. The security policy properties, or requirements, used
to determine that a secure state is obtained shall be defined.
TR-4 Object-Loss Detection
1. Procedures and/or mechanisms shall be provided to assure that,
after a TCB failure or other discontinuity, recovery without
protection compromise is obtained.
2. Automated procedures, under the control of the TCB, shall be
provided to assure that after a system failure, other discontinuity,
or start-up, a secure state is obtained without undue loss of system
or user objects. The security policy properties, or requirements, used
to determine that a secure state is obtained shall be defined. The
TCB shall include checkpoint functions for recovery. Upon recovery, it
shall be possible to discover which user objects are corrupted or
unaccessible due to the TCB failure, if any, and to automatically
notify the users.
TR-5 Object-Loss Minimization
1. Procedures and/or mechanisms shall be provided to assure that,
after a TCB failure or other discontinuity, recovery without
protection compromise is obtained.
2. Automated procedures, under the control of the TCB, shall be
provided to assure that after a system failure, other discontinuity,
or start-up, a secure state is obtained without undue loss of system
or user objects. The security policy properties, or requirements, used
to determine that a secure state is obtained shall be defined. The
TCB shall include checkpoint functions for recovery. Upon recovery, it
shall be possible to discover which user objects are corrupted or
unaccessible due to the TCB failure, if any, and to automatically
notify the users. The TCB functions that can be invoked through the
TCB interface shall be atomic (i.e., shall have the property that
either their invocation is completed correctly or the recovered system
state should be the one immediately prior to the execution of the TCB
function). The recovered secure state should minimize the corruption
and inaccessibility of user objects due to the TCB failure.
4.3.13 Rated TCB Privileged Operation Components
The TCB privileged operation components are rated based on the
granularity of privilege associated with individual TCB functions or
groups of functions (level PO-1), with modules of TCB functions and
operations of administrative roles (level PO-2), with individual
actions (level PO-3), and with individual code sections of an action
(level PO-4). The intent of these ratings is to separate (1) fine
granularity of privileges from coarser granularity and (2) the static
association of privileges with functions and modules from the run-time
association of privileges with actions (i.e., function invocations)
and sections of code within actions. Although the granularity of
privileges of a product is a design choice, the intent of these
requirements is to encourage use of fine granularity of privilege and
run-time association of privileges, at least for the TCB actions of
bypassing access controls.
PO-1 Privilege Association with TCB Functions
1. TCB privileges needed by individual functions, or groups of
functions, shall be identified. Privileged TCB calls or access to
privileged TCB objects, such as user and group registration files,
password files, security and integrity- level definition file, role
definition file, or audit-log file shall also be identified.
2. The identified privileged functions of a TCB functional component
shall be associated only with the privileges necessary to complete
their task.
PO-2 Privilege Association with TCB Modules
1. TCB privileges needed by individual functions, or groups of
functions, of a functional component shall be identified. Privileged
TCB calls or access to privileged TCB objects, such as user and group
registration files, password files, security and integrity-level
definition file, role definition file, audit-log file shall also be
identified. It shall be possible to associate TCB privileges with TCB
operations performed by administrative users.
2.The modules of a TCB function shall be associated only with the
privileges necessary to complete their task.
3. Support for product privilege implementation and association with
TCB modules provided by lower-level mechanisms or procedures (e.g.,
operating system, processors, language) shall be provided.
PO-3 Privilege Association with Individual Actions
1. TCB privileges needed by individual functions, or groups of
functions, of a functional component shall be identified. Privileged
TCB calls or access to privileged TCB objects, such as user and group
registration files, password files, security and integrity-level
definition file, role definition file, audit-log file shall also be
identified. It shall be possible to associate TCB privileges with TCB
operations performed by administrative users.
2. The modules of a TCB function shall be associated only with the
privileges necessary to complete their task.TCB privileges needed by
individual actions of a module (i.e., function invocations) shall be
identified (e.g., privileges shall be assigned to actions that bypass
access controls, such as disclosure and modification of user objects).
Each action shall be associated only with the privileges necessary to
complete its task.
3. Support for product privilege implementation and association with
TCB actions provided by lower-level mechanisms or procedures (e.g.,
operating system, processors, language) shall be provided.
PO-4 Dynamic Privilege Association with Individual Actions
1. TCB privileges needed by individual functions, or groups of
functions, of a functional component shall be identified. Privileged
TCB calls or access to privileged TCB objects, such as user and group
registration files, password files, security and integrity-level
definition file, role definition file, audit-log file shall also be
identified. It shall be possible to associate TCB privileges with TCB
operations performed by administrative users.
2. TCB privileges needed by actions of a functional component (i.e.,
function invocations) shall be identified (e.g., privileges shall be
assigned to actions that bypass access controls, such as disclosure
and modification of user objects). Each action shall be associated
only with the privileges necessary to complete its task. The
identified TCB privileges shall be used by each functional component
to restrict the propagation of errors and failures of security
mechanisms that may lead to protection policy violations. TCB
functions allowing each component to acquire individual privileges up
to the maximum necessary and allowed, and to drop those privileges
(e.g., functions implementing privilege bracketing) shall be defined.
These functions shall be used to limit the use of privileges that
allow the bypassing of security policy controls within the TCB.
3. Support for product privilege implementation and association
with TCB actions provided by lower- level mechanisms or procedures
(e.g., operating system, processors, language) shall be provided.
4.3.14 Rated TCB Ease-of-Use Components
The rating of the TCB ease of use components reflects the scope and
coverage of the protection functions in covering common product
configurations. At level EU-1, the requirements reflect the general
need for special administrative functions, not merely using an editor
to modify administrative files or default options for security
parameters. The coverage of the ease-of-use requirements is extended
at level EU-2 by providing for fail-safe defaults and user-settable
defaults for defined (privileged and unprivileged) subjects and
objects, and the means by which applications can protect themselves
and their objects from unauthorized use. The scope of the requirements
is extended at levels EU-3 and EU-4 by enlarging the set of subjects
and objects affected by this requirement to include subjects and
objects of common configurations, and all subjects and objects,
respectively.
EU-1 Ease of Security Management
1. The TCB shall provide well-defined actions to undertake
administrative functions. Default options shall be provided for
security parameters of administrative functions.
EU-2 Ease of Application Programming
1. The TCB shall provide well-defined actions to undertake
administrative functions. Default options shall be provided for
security parameters of administrative functions.
The TCB shall include fail-safe defaults for the policy attributes of
the defined subjects and objects, as well as user-settable defaults
for the defined subjects and objects.
2. The TCB shall provide well-defined application programming
interfaces and programming functions (e.g., libraries) for all its
policies to support the development of applications that can define
and enforce security policies on application- controlled subjects and
objects. The TCB shall enable user-controlled reduction of access
rights available to applications.
EU-3 Common Configuration Coverage
1. The TCB shall provide well-defined actions to undertake
administrative functions. Fail-safe default options shall be provided
for security parameters of administrative functions.
The TCB shall include fail-safe defaults for the policy attributes of
subjects, objects (e.g., devices) and services used in common system
configurations, as well as user-settable defaults for these subjects
and objects.
2. The TCB shall provide well-defined application programming
interfaces and programming functions (e.g., libraries) for all its
policies to support the development of applications that can define
and enforce security policies on application- controlled subjects and
objects. The TCB shall enable user-controlled reduction of access
rights available to applications.
EU-4 Complete Configuration Coverage
1. The TCB shall provide well-defined actions to undertake
administrative functions. Fail-safe default options shall be provided
for security parameters of administrative functions.
The TCB shall include fail-safe, user-settable defaults for the policy
attributes of all subjects, objects (e.g., devices), and services.
2. The TCB shall provide well-defined application programming
interfaces and programming functions (e.g., libraries) for all its
policies to support the development of applications that can define
and enforce security policies on application- controlled subjects and
objects. The TCB shall enable user-controlled reduction of permissions
available to applications.
4.4 Bibliographic Notes
TBD.
Chapter 5.
DEVELOPMENT ASSURANCE REQUIREMENTS
5.1 Overview
Development assurance is concerned with showing that a specific IT
product satisfies the functional requirements of a protection profile.
This chapter defines assurance requirements that are used in
protection profiles to define an IT product developer's (i.e.,
producer's) responsibilities in establishing the correctness of the
product's security functions. These requirements are partitioned into
components that identify unique concerns a developer must address
during the product design, implementation, documentation, support, and
maintenance. By addressing these concerns, the developer can increase
consumer and evaluator confidence that the product satisfies the
functional requirements of a protection profile. Varying degrees of
confidence can be established using different combinations and subsets
of the assurance components.
The assurance components defined in this standard have evolved from
computer security and engineering experience in demonstrating the
correctness of IT hardware and software protection functions. The
components also include requirements of existing criteria and reflect
the interpretations of those requirements in practice during the past
decade. The components are specified in a product- independent manner
and, thus, are applicable to a wide set of products and protection
functions. To enable the profile developers to establish varying
degrees of confidence in the correctness of product protection
functions, each assurance component is rated based on a set of
well-defined parameters. These ratings can also help establish the
relationships between, and the harmonization of, the assurance
requirements defined by this standard and those of existing standards.
This chapter is divided into four sections. The remainder of this
section defines four classes of development assurance components and
describes the types of components in each class. The second section
presents a description of each type of assurance component. The third
section contains the rated assurance components. The last section
includes a bibliography of useful literature references. (Appendices D
and E present some of the technical underpinnings used in deriving the
requirements of the modular decomposition and penetration analysis
components.)
Classes of Development Assurance. The development assurance components
have been partitioned into four classes reflecting distinct product
development tasks: (1) development process, (2) operational support,
(3) development environment, and (4) development evidence. The four
classes, and associated components, are illustrated in Figure 5
Development Process. The development process class consists of the
following four assurance components that identify specific activities
the developer must undertake during the design, implementation, and
analysis of an IT product: (1) TCB property identification, (2) TCB
design, which includes TCB element identification, interface
definition, modular decomposition, structuring support, and design
disciplines used, (3) TCB implementation support, and (4) TCB testing
and analysis, which includes security functional testing, penetration
analysis, and covert channel analysis. Since the development process
includes the primary assurances for the correct implementation of
protection functions, its components are included in most profiles.
The selection of different component levels within a profile is
determined by the assurance goals established for the profile, by the
dependencies among assurance components, and by the dependencies
between the profile functional and assurance components.
Operational Support. The operational support class consists of
assurance components that a developer must satisfy to enable users to
operate the product securely. This class includes the following four
components: (1) user guidance, (2) administrative guidance, (3) flaw
remediation, and (4) trusted generation. These components require the
developer to convey clearly the operational procedures for TCB
generation, installation, operation, and flaw correction. They also
require the developers to provide tools and/or procedures to properly
install and configure the product. The first two components of this
class are included in all profiles whereas the last two are included
in profiles that target medium and high-assurance products. The
selection of different component levels within a profile is largely
determined by assurance goals and by the dependencies among assurance
components.
Development Environment. The development environment class consists of
assurance components that refer to quality of the development,
maintenance, and distribution-control process for secure products.
This class includes the following three components: (1) life cycle
definition, (2) configuration management, and (3) trusted distribution
of the product. These components require that the developer enforces a
discernible engineering process to develop and maintain a product,
establishes control over the product configuration during development
and maintenance, and employs technical measures for the detection or
prevention of uncontrolled TCB modification during product
distribution. A key assurance aspect of these components is the extent
to which the development process and operational support requirements
are integrated into the developer's engineering processes. The
development environment components are included in profiles that
target medium and high-assurance products. The selection of different
component levels within a profile is largely determined by assurance
goals and by the dependencies among assurance components.
Development Evidence. The development evidence class consists of
assurance components that describe the documentation that a developer
must produce and maintain to show that the other assurance
requirements have been satisfied. The components of the development
evidence class establish the level of detail and scope of the
developer documentation and include requirements for evidence of: (1)
TCB protection properties, (2) product design and implementation, (3)
product testing and analysis, and (4) product support. These
components are included in all profiles. The selection of different
component levels within a profile is determined exclusively by the
dependencies among assurance components, since these levels must
mirror to a large extent the levels of the other development assurance
components.
5.2 Development Assurance Components
5.2.1 Development Process
5.2.1.1 TCB Property Identification
The identification of TCB properties is the prima facie assurance that
the consistency of the TCB's behavior with respect to the protection
profile's functional requirements can be established. These properties
are the baseline set of protection claims for a TCB. They enable the
generation of test conditions for security policy analysis and
penetration testing. They also help define the IT product's protection
capabilities in product documentation.
The first step to demonstrate that a product satisfies the functional
requirements of a protection profile is to produce the description of
the TCB protection properties. This is achieved by (1) identification
of the TCB elements intended to implement the functional requirements,
and (2) justification of how and why the identified elements implement
these requirements. Repeating this step for each functional
requirement of a protection profile produces a description of the set
of protection properties. Since a functional requirement can be
satisfied by different product architectures and operating systems,
the set of protection properties will illustrate both the developer's
philosophy of protection and the protection architecture choices made.
Demonstrating the consistency of the TCB behavior with the
requirements of the profile functional components can be performed
with different degrees of rigor. For example, consistency verification
can be performed by an informal process of tracing the requirements
within a product's TCB and providing a simple description of the
claimed TCB property. This informal process relies primarily on
informal functional requirements (i.e., as provided by the protection
profile) and on descriptions of TCB elements. The primary assurance
gained from this informal process is derived from the consistency and
coherence of the profile requirements, and from the explanation of why
the TCB elements satisfy those requirements. This explanation will
reveal whether the developer's interpretation of the profile
functional requirements in the product TCB is valid.
The degree of rigor with which the demonstration of consistency
between the TCB elements and the functional requirements can be
performed increases whenever formal or informal models of the
functional requirements are used. Models capture the essence of the
functional requirements by providing policy properties that must be
maintained by the TCB. For example, the Bell-LaPadula Model contains
two policy properties of mandatory access control. These examples are
the *-property (star property), which allows a subject write access to
an object only if the security level of the subject equals that of the
object, and the simple security condition, which allows a subject read
access to an object only if the security level of the subject
dominates that of the object. A discretionary access control model may
have a policy property stating that "only the owner of an object can
distribute or review permissions to that object." A TCB isolation
model may have an isolation property stating that "a parameter passed
by address to a TCB function invocation may only refer to the
invoker's space, and not to the TCB space or to another subject
space."
Tracing precise requirement properties among the TCB elements is
likely to be significantly more effective than tracing profile
requirement descriptions, which are informally expressed. However, the
precision with which the requirement properties are expressed by a
model generally depends on the type of model and the degree of model
formalism. Furthermore, the tracing process itself also depends on the
degree of precision and formalism with which the TCB elements are
described. For example, precision is enhanced by providing Descriptive
Interface Specifications (DIS) instead of informal descriptions of the
TCB interface found in product reference manuals, or by providing
Formal Interface Specifications (FIS) instead of the DIS. The use of
formal models and DIS/FIS of the TCB makes it possible to perform the
tracing process by (in)formally interpreting the requirements model in
the DIS/FIS. By showing that a documented (in)formal interpretation of
a requirement model in a TCB is valid, the properties of the TCB can
be stated (in)formally with a higher degree of rigor.
5.2.1.2 TCB Design
The TCB design component comprises several subcomponents that provide
product development assurance. These subcomponents are (1) element
identification, (2) interface definition, (3) modular decomposition,
(4) structuring support, and (5) design disciplines. Details of each
component follow.
5.2.1.2.1 TCB Element Identification
The importance of the TCB element identification as an assurance
component derives from the fact that all other assurance methods rely
on it either directly or indirectly. Intuitively, the TCB includes
all code and data structures that implement protection functions of a
TCB (i.e., functional components). Although this intuitive definition
of the TCB elements is precise, in practice the identification of
these elements can be a challenging activity for the following three
reasons.
First, TCBs may include code and data structures that are irrelevant
to the protection components. In practice, products often implement
functions and mechanisms that include security irrelevant elements and
whose main purpose is not protection. Separating the protection
relevant from the irrelevant elements within these functions can
sometimes be a very difficult task because of the complexity and
performance implications of the interfaces that are introduced between
the protection relevant and irrelevant elements of a function.
Although desirable for assurance purposes, in general, it may be
impractical to remove all security irrelevant code from the TCB.
Second, the TCB is defined with respect to a set of protection
requirements and a set of assurances necessary to demonstrate that the
TCB satisfies those requirements. A product may include protection
functions for which assurance is not required. Nevertheless, these
protection functions in practice become part of the TCB since they
affect the overall behavior of the product in other environments. For
example, separating different TCBs for functions implementing
different security policies may be impractical. The TCB of a product
may include protection functions to support confidentiality,
integrity, and availability to various degrees, but the only required
policy support assurances may be for confidentiality. Providing a
separate TCB for availability and integrity components is impractical
for most products and unjustifiable, based on the incremental
assurance benefits that might be derived from the removing these
components from the confidentiality TCB. In practice, the
determination of which components must be included in a TCB cannot be
made exclusively based on the specific-policy relevance of the code
and data structures.
Third, sometimes it is challenging to determine whether a functional
component is security-policy relevant without the benefit of a formal
model of a security policy. For example, if a formal state-transition
model is available, any TCB function whose execution may cause a state
transition is, by definition, security-relevant. However, in the
absence of a formal model, one can determine whether a function is
security-policy relevant only if the function implements security
policy checks. Among the functions that invoke other functions
implementing security or accountability checks indirectly, few are
required to be part of the TCB since, by definition, they could be
placed outside the TCB and could invoke a TCB system call.
Since many of the IT product TCBs will include both
protection-relevant and irrelevant elements, the identification of
these elements (1) must separate the protection-relevant elements from
the irrelevant ones (if any), and (2) must provide a rationale for the
retention of the protection-irrelevant elements within the TCB.
5.2.1.2.2 TCB Interface Definition
To analyze the protection of the TCB domain, one must first define
interface of the TCB to external subjects. This interface establishes
the boundary between the TCB elements and unprivileged subjects. The
TCB protection behavior is defined at this interface.
The definition of the TCB interface is required by several assurance
methods, including security and penetration analysis and testing,
interpretation of security requirements and models within a TCB, and
covert channel analysis and testing. Establishing the TCB interface
requires that all TCB elements be identified to determine whether they
present an interface (i.e., are visible) to an unprivileged subject.
The TCB interfaces typically consist of several components including
(1) the command interfaces, (2) the application programming interfaces
(i.e., system calls), and (3) the machine/processor interface (i.e.,
processor instructions). The command interface consists of the set of
TCB commands that can be input via user-oriented devices such as
keyboards, mouse devices, and joysticks; other command interfaces to a
TCB may include various sensor input interfaces for real-time devices
and processes external to the TCB. The application programming
interface consists of all the TCB system calls that an application
program can make, to include the signal, trap, and fault interfaces
which an application program may invoke. Similarly, the
machine/processor interface to the TCB consists of all instructions
that refer to TCB internal data structures, (e.g., memory registers,
segment and page tables), and processor registers (e.g., process
status registers, segment, page table, capability, cache, and
address-translation registers).
Determining the TCB interface cannot be simply performed by listing
all commands, system calls, and processor instructions. Not all
commands, system calls, or instructions may, in fact, represent a TCB
interface. For example, some commands and library calls may refer to
programs and data structures that are in user space. Similarly, some
instructions may refer to operands that are already loaded into
user-addressable registers and, therefore, need not include memory
protection checks. Some command and application program interfaces may
overlap and not represent distinct TCB interfaces. For example, two
distinct command interfaces that are implemented by command processors
running in user space may invoke the same application program
interfaces of the TCB. Consequently, the two distinct commands do not
provide distinct TCB interfaces. In some products, the TCB includes
the entire application and presents a command interface to its users
with no distinct application program interface or processor interface.
For example, in some real- time, process-control systems, the external
TCB interface may represent sensor input, but no external user or
application program input. In this case the TCB components and the TCB
external interface must still be identified because of attempts by
external processes to provide the sensor input.
The TCB interface definition requires that all TCB functions which are
visible outside the TCB be defined, including their calling
conventions, parameters, parameter types, order, and exceptions
signalled. The parameter types must include, in addition to the call
parameters, all of the subjects, objects, and access control
attributes affected by that call. Whenever covert channel analysis,
penetration analysis, and resource- constraint analysis are required,
the TCB interface definition must also include all effects of a call,
including the direct visibility and alterability of internal TCB
variables and functions. In these cases, the traditional definitions
of TCB interfaces provided in product reference manuals must be
augmented by additional elements. In all cases, all TCB interfaces
must be included. No interface may remain undocumented, and no
temporary interfaces for testing or performance monitoring, for
example, should be included.
5.2.1.2.3 TCB Modular Decomposition
Modular design and implementation constitutes a sound engineering
practice in general, and therefore, this technique represents sound
engineering practice for IT product development assurance. Reading,
understanding, maintaining, testing, and evolving a software product
is helped by modularity. "Understanding" includes identifying product
parts and their relationships, and determining important product
properties. Although modular design and implementation is not a
security-specific assurance, products that employ it offer the
following assurance advantages: (1) an incremental, divide-and-conquer
approach to determining correctness properties; (2) an incremental,
divide-and- conquer approach to product development, with many
individuals per development team possible; (3) replacement
independence of product parts based on well-defined interfaces and
uniform reference (i.e., references to modules need not change when
the modules change); and (4) an intuitive packaging of product
components with ease of navigation through the product, module by
module.
Appendix D provides some of the technical underpinnings used in
deriving the requirements of the TCB modular decomposition.
5.2.1.2.4 TCB Structuring Support
The TCB structuring using modular decomposition is necessary for
understanding, maintaining, testing, and evolving a product. However,
the modular decomposition does not necessarily reflect the run-time
enforcement of TCB structuring since the separation of modules may not
necessarily be supported by run-time mechanisms. The run-time
enforcement of internal TCB structuring adds a measure of assurance
that the TCB elements that are critical to the enforcement of the
protection functions are separated from non-critical elements. Also,
the use of run-time enforcement of TCB structuring helps separate
protection-critical elements of the TCB from each other, thereby
helping enforce the separation of protection concerns and minimizing
the common mechanisms shared between protection critical elements.
Run-time enforcement of TCB structuring is useful in cases when
compile-time structuring either cannot be enforced (e.g., the
programming language does not enforce modular decomposition) or can be
circumvented by transient hardware failures. In either case, software
errors may propagate through the entire TCB and corrupt
protection-critical elements. However, run-time enforcement of TCB
structuring is not considered to be a protection function because it
does not directly counter any security threat posed by unprivileged
subjects. Unlike the support for the least-privilege TCB operation,
which reduces the possibility that the penetration of a TCB functional
component affects other components, the run-time support for TCB
structuring has no direct protection use. Use of processor mechanisms
to support TCB structuring is desirable for minimizing the performance
penalties that will undoubtedly arise if these mechanisms were
provided by run-time software.
A key assurance requirement for run-time mechanisms that support TCB
structuring is that of conceptual simplicity and well-defined
semantics. Conceptually simple mechanisms are generally easy to
understand, and describe, define, or formally specify. Well-defined
semantics enable the rigorous analysis of TCB structuring and increase
the confidence that the internal TCB structuring is enforced
correctly. The use of architecture features for run-time enforcement
of TCB structuring into security kernels and privileged processes
ranges from process-isolation features to the use of ring or
domain-of-protection mechanisms. Among the architecture and operating
system features employed for enforcing the TCB structuring,
segmentation and paging has been used to separate logically distinct
storage objects with separate access- control attributes. The
separation of subsystem and module data structures and code within a
TCB is sometimes supported by ring or domain-of-protection mechanisms
with separate entry point support and protection (illustrated by ring
or domain gates). Thus, the TCB can be described in terms of the
different rings or domains of protection it employs for its
structuring into subsystems and modules, and in terms of the
segmentation or paging mechanisms it employs for structuring its
internal code and data structures into logically distinct storage
objects.
5.2.1.2.5 TCB Design Disciplines
Modularly decomposing the TCB provides many benefits. However, it
does not minimize the complexity of the TCB or remove the
protection-irrelevant elements from the TCB. Leaving
protection-irrelevant elements within a TCB necessarily results in a
significantly larger assurance effort because these elements must be
included in the TCB's analysis. Furthermore, modularly decomposing the
TCB does not necessarily minimize the sharing of global variables
between modules (i.e., the data structures used in a module need not
be "hidden" within the module), and does not necessarily help layer
the TCB (e.g., the cyclic dependencies among TCB modules cause lower
layers to require services of higher layers). Consequently, the
analysis of the TCB could become very complex for medium size (e.g.,
500K to 1M lines of source code) or large products (e.g., over 1M
lines of source code).
Several design disciplines enable the rigorous analysis of TCB
security properties which is necessary for high-assurance products.
First, the complexity of the TCB must be reduced by minimizing the
number of protection-irrelevant elements that are left within the TCB.
This requirement, together with the functional requirements of
reference mediation and TCB protection, is the basis for demonstrating
that the TCB implements the reference validation mechanism, which is
important for the rigorous analysis of access control policy
implementations (see Appendix B).
Second, the TCB structuring must employ the use of data hiding to
minimize the sharing of global variables within the TCB. This
requirement, together with the use of other design abstractions such
as functional and control abstractions, significantly enhances the
ability to structure the modules of a TCB into sets of (ordered)
layers and to precisely determine the protection properties of those
layers (e.g., derive abstraction and layer properties). As a result,
the formal analysis of the TCB modules becomes possible.
Third, extensive use of high-level synchronization constructs, such as
monitors and message passing, makes the analysis of the TCB behavior
possible despite the occurrence of asynchronous events. Further
structuring of TCB processes into threads decreases the cost of using
processes as a TCB structuring mechanism, thereby enhancing the
development of TCBs containing small independent modules sharing
process space.
5.2.1.3 Implementation Support
The implementation support component is an assurance method that can
be used to simplify the task of establishing the correspondence
between the product as built and the product design. The ultimate test
of the development process applied to a TCB is how well the TCB
implementation satisfies the protection profile requirements. Testing
can establish that the TCB implementation exhibits at least the
properties needed to satisfy the profile requirements. Analysis,
however, is needed to establish that the implementation does no more
than the profile requires. At a minimum, a complete analysis requires
that the source code be available. For more detailed analysis, the
system architecture and design are also necessary to simplify the task
of tracking the required TCB properties from requirements down to
implementation. As more rigor is brought to the process of design,
more analysis can be done at higher levels of abstraction. To complete
the chain and effectively leverage the previous analysis, the
implementation should be organized and packaged in the same manner as
the design to simplify the process of mapping the design to the
implementation.
5.2.1.4 TCB Testing and Analysis
A significant measure of product development assurance is derived from
the methods used to test and analyze a TCB provides. These methods,
which include (1) functional testing, (2) penetration analysis, and
(3) covert channel analysis, are described below.
5.2.1.4.1 Functional Testing
Functional testing is an assurance method for establishing that the
TCB interface exhibits the properties necessary to satisfy the
requirements of its protection profile. Functional testing is
especially valuable in providing assurance that the TCB satisfies at
least its functional protection requirements. It does establish that
the TCB does no more than expected. The developer's functional testing
objective is to uncover all design and implementation flaws that would
enable a user external to the TCB to violate the product security
policy. Such flaws would invalidate the developer's claim of
compliance with the protection profile. The developer should perform
functional testing whenever the TCB changes as a result of design
analysis, independent evaluation, product evolution, or repair of
security flaws identified by either consumers or previous functional
testing.
All approaches to security functional testing require the following
four major steps:
Test plan development. The test plans consist of test conditions, test
data including the expected test outcomes, and test coverage analysis.
Test plans must be developed for all TCB primitives exported at the
TCB interface.
Test program development. The test programs developed must reflect the
test conditions, test data, and coverage described in the test plans.
Test procedure description. The test procedures provide instructions
for using individual test programs, and complete test suites.
Test result analysis. The analysis of the test results verifies that
the test outputs correspond to the expected outcomes defined in the
test plans.
Functional testing should be done on a copy of the TCB that is
configured and installed as recommended in product documentation. The
product should be operating in a normal mode, as opposed to
maintenance or test mode. Tests should be done using user-level
programs that cannot read or write internal TCB data structures or
programs. New data structures and programs should also not be added to
a TCB for security testing purposes, and special TCB entry points that
are unavailable to external user programs should not be used. If a TCB
is tested in maintenance mode using programs that cannot be run at the
user level, the security tests would be meaningless because assurance
cannot be gained that the TCB performs user-level access control
correctly. If user-level test programs could read, write or add
internal TCB data structures and programs, as would be required by
traditional instrumentation testing techniques, the TCB would lose its
isolation properties. If user-level test programs could use special
TCB entry points not normally available to external users, the TCB
would become circumventable in the normal mode of operation.
Functional testing should be conducted according to procedures defined
in a test plan. Significant events during testing should be placed in
a test log. As testing proceeds sequentially through each test case,
the developer's test team should identify flaws and deficiencies that
will need to be corrected. After changing TCB elements (i.e.,
hardware, firmware, or software) to correct these flaws and
deficiencies, the developer should repeat the tests that identified
problem(s) as well as any other tests related to the changed TCB
elements. When the development team has corrected all functional
problems and has analyzed and retested all corrections, a test report
should be written and made a part of a functional testing report.
5.2.1.4.2 Penetration Analysis
The penetration analysis of a computer product is a separate assurance
concern from security policy design and/or implementation. Different
TCBs may exhibit the same degree of penetration resistance, but
implement widely different security policies, or may implement the
same policies, but exhibit different degrees of penetration
resistance. Furthermore, penetration analysis is an important
assurance component since the effectiveness of all security policies
rely on the penetration resistance of a TCB.
The penetration analysis of a TCB consists of the identification and
confirmation of flaws in the design and implementation of protection
functions that can be exploited by unprivileged users or application
programs. Unlike security policy analysis and security functional
testing, penetration analysis identifies TCB flaws that are not
necessarily related to security policy design and implementation. For
example, penetration analysis identifies vulnerabilities of reference
mediation and TCB protection functions independent of the functions
that implement security policy support. This implies that the type of
policy that controls the subjects' access to objects is relevant to
security functional analysis and testing, but not to penetration
testing. Instead, penetration testing concerns include whether TCB
elements may be surreptitiously viewed or modified, and whether TCB
internal functions, which are intended to be invisible outside the
TCB, can in fact be invoked under the control of unprivileged users or
applications. Furthermore, penetration analysis includes assessments
of the strength of TCB protection functions and of vulnerabilities of
protection function implementation and operational use.
Appendix E presents some of the technical underpinnings used in
deriving the requirements of the penetration analysis component.
5.2.1.4.3 Covert Channel Analysis
Covert channel analysis is an assurance component that is required
whenever nondiscretionary confidentiality or integrity policies are
used to control information flow. It consists of (1) the
identification of covert channels within a TCB, (2) the estimation of
the maximum bandwidth of each channel, and (3) the testing of the
covert channel handling functions.
Identifying a covert channel requires discovery of a TCB internal
variable and one or more TCB interfaces that permit the alteration and
viewing of variable values in violation of the information-flow policy
imposed by nondiscretionary access controls. Both storage and timing
channels use at least one variable for the transmission of the
information being transferred between the sender and receiver.
Multiple TCB interface functions may be necessary for viewing or
altering a variable because after viewing or altering a variable, the
sender and/or the receiver may have to set up the transmission
environment for sending and/or reading the next bit. The covert
channel variable may be a software, firmware, or hardware variable. In
addition to TCB primitives and variables implemented by kernel and
trusted processes, covert channels may use hardware-processor
instructions and user-visible registers. Thus, complete covert channel
analysis should take into account a product's underlying hardware
architecture, not just kernels and trusted processes. Therefore, the
primary goal of covert-channel identification is that of discovering
all TCB variables and TCB interfaces that can be used to alter or view
these variables. A secondary goal of covert channel identification is
that of determining the TCB elements where time delays, noise (e.g.,
randomized table indices and object identifiers, spurious load), and
audit code may be placed for decreasing the channel bandwidth and
monitoring its use.
The term "bandwidth" is introduced to denote the rate at which
information is transmitted through a channel. This use of the term
bandwidth can also be related to the notion of "capacity". The
capacity of a channel is its maximum possible error-free information
rate in bits per second. Thus, the primary goal of covert-channel
bandwidth estimation is to determine the maximum possible error-free
transmission rate, measured in bits-per-second, through a covert
channel. The maximum covert channel bandwidth can be estimated using
standard information theory methods. Performance measurements of the
TCB are generally necessary to determine parameters required by the
information theory methods.
Covert channel testing is required to demonstrate that covert channel
handling functions (e.g., elimination, bandwidth limitation, audit)
chosen by product designers operate correctly. Testing is also useful
to confirm that the potential covert channels discovered in the
product are in fact real channels. Furthermore, testing is useful when
the handling functions use variable bandwidth-reduction parameters
(e.g., delays) that system administrators (e.g., auditors) can set.
In contrast with maximum bandwidth estimation, which provides upper
bounds for covert channels before handling functions are used, covert
channel testing always requires that actual measurements be performed
to determine the covert-channel bandwidths after the chosen handling
functions are implemented in a product. (Of course, maximum bandwidth
estimation can also be used after handling functions are implemented
in a product.) Test plan documentation, including test conditions,
test environment set-up, test data, expected test outcome, and actual
test result documentation must be provided.
5.2.2 Operational Support
The operational support class of components addresses the developer's
and users' responsibilities subsequent to IT product delivery. The
developer's responsibilities include providing the necessary guidance
to the consumer regarding the proper configuration, initialization,
use, and administration of the IT product. The consumer is assumed to
follow this guidance, however, fail-safe defaults may be provided to
preclude consumer difficulties. An issue of concern to consumers is
the identification and remediation of security flaws that may be
discovered subsequent to IT product delivery. This component includes
requirements for such identification and remediation.
5.2.2.1 User Guidance
Requirements for user guidance help ensure that product users are able
to operate the product in a secure manner (e.g., the usage constraints
assumed by the protection profile must be clearly explained and
illustrated). The user is defined as a person who operates the
product, but has no special privileges to affect the configuration of
the product. The user for most IT products is assumed to be a person
with little or no computer experience, but this need not always be the
case.
User's guidance is the primary means available to the developer for
providing the IT product users with the necessary background and
specific information on how to correctly use the product's protection
functions. User guidance must do two things. First, it must explain
how the protection functions of a specific product work, so that users
are able to consistently and effectively protect their information.
Second, it must explain the user's role in maintaining the IT
product's security.
The scope of the user's guidance should be limited to documenting only
the protection functions available to all users and only the
responsibilities that all users have for product security. To
accomplish this, the user's guidance documentation should explain what
protection functions are present in the product and why, how the
protection functions work, and how to use the functions properly. The
material should be easy to locate in the IT product documentation and
should be clear, concise, and complete.
5.2.2.2 Administrative Guidance
Requirements for administrative guidance help ensure that the
environmental constraints assumed by the protection profile are
understood by administrators and operators of the IT product. The
administrator is defined as a person who has the special privileges
needed to affect the product configuration and set the user and
product security parameters. The operator is defined as a person who
has the special privileges needed to affect the routine operation of
the product after it has been configured. The administrator has the
primary responsibility for the security of the IT product. The
operator is often assumed to also have some responsibility for the
secure use of the IT product.
Administrative guidance is the primary means available to the
developer for providing the IT product administrators with detailed,
accurate information of how to: (1) configure and install an IT
product, (2) operate the IT product in a secure manner, (3) make
effective use of the product's privileges and protection mechanisms to
control access to administrative functions and databases, and (4)
avoid pitfalls and improper use of the administrative functions that
would compromise the TCB and user security.
Administrator guidance should clearly illustrate necessary
administrator actions (e.g., cite actual system commands and
procedures). Although a high level of detail in illustrating key
security concepts would benefit administrative users, the
administrator guidance should not become a training manual in the
areas of computer security and system administration. Administrator
familiarity with the notion of IT product security should be assumed.
Administrator guidance should include examples of both proper use and
warnings about consequences of misuse of administrative functions,
procedures, privileges, and databases. Administrator guidance should
be easy to locate in the IT product documentation and should be clear,
concise, and complete.
5.2.2.3 Flaw Remediation
Flaw remediation is an operational support assurance component for
ensuring that flaws discovered by the IT product consumers will be
tracked and corrected while the product is supported by the developer.
While compliance with the flaw remediation requirements of a
protection profile cannot be determined when a product is evaluated,
it is possible to evaluate the procedures and policies that a
developer has in place to track and repair flaws and distribute the
repairs to affected consumers.
There are three parts to the flaw remediation process. First, the
developer must be prepared to receive, validate, and track consumer
reports of TCB flaws. Second, the developer must be prepared to devote
resources to identifying one or more corrections to each flaw and
maintaining these correction(s) with the reported flaws. Finally, the
developer must have a process in place for distributing the flaw
corrections to affected consumers.
5.2.2.4 Trusted Generation
Trusted generation is an operational support assurance component for
ensuring that the copy of the IT product's TCB that is configured and
activated by the consumer will exhibit the same protection properties
as the master copy of the IT product's TCB that was evaluated for
compliance with the protection profile. The trusted generation
procedures must provide some confidence that the consumer will be
aware of what product configuration parameters can affect the
protection properties of the TCB. The procedures must encourage the
consumer to choose parameter settings that are within the bounds
assumed during the product evaluation.
5.2.3 Development Environment
The development environment class of components addresses the
developer's engineering processes for product life cycle management,
product configuration management, and trusted product distribution.
These components are reviewed below.
5.2.3.1 Life Cycle Definition
Life cycle definition is an assurance component for establishing that
the engineering practices used by a developer to produce the IT
product's TCB include the considerations and activities identified in
the development process and operational support requirements of the
protection profile. Consumer confidence in the correspondence between
the protection profile requirements and the product's TCB is greater
when security analysis and the production of evidence are done on a
regular basis as an integral part of the development process and
operational support activities.
The developer must explain the processes used to develop and maintain
the product's TCB. The developer must also define the tools being used
to analyze and implement the TCB. The higher levels of the component
also require that the processes used by the developer are disciplined
(i.e., consistent, measurable, and repeatable) to achieve quality
products. It must be emphasized that this component imposes no
constraints on the specific process chosen by the developer other than
that it be sufficient to incorporate the stated requirements of the
protection profile. This component simply establishes the degree of
rigor required for documenting and demonstrating compliance with the
developer's defined process.
5.2.3.2 Configuration Management
Configuration management is an assurance component for ensuring that
the IT product's TCB configuration remains consistent and complete
during the product life cycle, and that changes to the TCB do not
adversely affect the protection properties of the TCB. Configuration
management must ensure that additions, deletions, or changes to the
TCB do not compromise the correspondence between the TCB
implementation and the requirements of the protection profile. This is
accomplished in the configuration management component by requiring
that the developer have procedures and tools that ensure that the TCB
and its documentation are updated properly when the TCB changes.
Configuration management is a sound engineering practice that also
provides the final element of traceability between the protection
profile requirements and the product delivered to the consumer.
Specifically, configuration management provides confidence that the IT
product's TCB and documentation used for evaluation are the ones
prepared for distribution to consumers.
The requirement of configuration management refers to four separate
tasks: configuration identification, control, status accounting, and
auditing. For every change that is made to the IT product, the changed
version of the product, its functional requirements, and design must
be identified. Control over the product configuration means that every
change to the product documentation, hardware, software, or firmware
is the subject of review and approval by a change-control authority.
Configuration status accounting is responsible for recording and
reporting on the configuration of the product throughout the change.
Finally, through the process of configuration audit, the completed
change can be verified to be functionally correct and consistent with
the protection properties the IT product. The procedures and tools
used to implement the four tasks are documented in a configuration
management plan to ensure that development personnel understand their
responsibilities for configuration management. Any deviation from the
configuration management plan could contribute to the failure of the
configuration control of an IT product and compromise the trust in the
product's ability to satisfy the protection profile.
5.2.3.3 Trusted Distribution
Trusted distribution is an assurance component for ensuring that the
master copy of the IT product's TCB sent from the developer is the
same one received by the consumer. The trusted distribution component
is intended to counter the possibility that the TCB could be
intentionally subverted during shipment from the development
environment to the consumer.
At a minimum, the trusted distribution techniques must allow the
consumer to determine if the TCB copy received has been modified
during shipment. The trusted distribution techniques should also be
designed to prevent any modifications from occurring during shipment.
5.2.4 Development Evidence
The development evidence class of components addresses requirements
for the documentation of all development process, operational support,
and development environment activities. The requirements for evidence
are stated in four components: TCB Protection Property, Product
Development, Product Analysis and Testing, and Product Support. These
evidence components are elaborated below:
5.2.4.1 TCB Protection Properties
The documentation of the TCB protection properties includes the
definition of the functional component requirements, their modeling
(if any), and their interpretation within a product's TCB.
For each functional requirement of a protection profile, a
description, definition (an informal, descriptive specification), or a
formal specification of the TCB components and their operation
corresponding to that requirement must be provided. This
correspondence must be documented to the extent necessary to establish
that the functional requirements are, in fact, supported by TCB
elements and interfaces. Alternate ways of presenting the evidence of
this correspondence are possible. For example, the documentation may
select TCB elements and interfaces, and for each individual set of
selected elements and interfaces, it may identify the corresponding
functional component requirement.
The correspondence between the functional component requirements and
the TCB elements and interfaces can be established and documented in
varying degrees of rigor. In addition to the above, the developer must
document the (in)formal models of the functional component
requirements, when higher levels of development assurance are desired.
Providing specific models that satisfy the requirements of a profile
increases the degree of rigor with which the correspondence can be
established between the profile requirements and the TCB elements and
interfaces. The interpretation of a model in a TCB must also be
documented. However, as noted in the development assurance
components, not all functional requirements must be modeled. Thus, not
all aspects of this correspondence could be established at same degree
of rigor. (The required modeling areas are spelled out in the
assurance components.) Nevertheless, all aspects of the correspondence
between the functional requirements and TCB elements and interfaces
must be documented.
5.2.4.2 Product Design and Implementation
The TCB design evidence includes the documentation of the (1)
interface, (2) elements, (3) modular decomposition, (4) structuring
support, and (5) design disciplines used. The TCB implementation
evidence includes (1) the source code, and (2) the processor hardware
and firmware specifications. In addition to the documentation for each
stage of the development process, the design and implementation
evidence should contain descriptions/definitions/specifications of the
correspondences between the TCB design and the implementation.
In principle, the product design and implementation should follow a
development sequence beginning with the specification of the TCB
protection properties and ending with the implementation code and
processor specifications. In practice, however, the different
development sequences may, in fact, be executed in successive
refinements, with specifications and correspondences between design
and implementation being performed out of sequence. Alternative
development sequences are acceptable, provided that they lead to
products whose structures are accurately reflected in the design and
implementation documentation.
5.2.4.3 Product Testing and Analysis
The product testing and analysis evidence consists of the
documentation of functional testing, penetration analysis, and
covert-channel analysis.
5.2.4.3.1 Functional Testing
Functional testing evidence includes test plans, test results, and
test documentation. Each test plan consists of (1) the description,
definition or specification of the test conditions, (2) the test data,
and (3) a description of the test coverage. The test results contain
the actual outcome of each test run. The test plans must be documented
and, in some cases, maintained under configuration management.
5.2.4.3.2 Penetration Analysis
The penetration analysis evidence includes penetration test plans and
results, the documentation of the penetration testing method and
tools, and when appropriate, the scenario of the discovered
penetration flaws. The cause of a every discovered penetration flaw,
or class of penetration flaws, must also be documented.
5.2.4.3.3 Covert Channel Analysis
The covert-channel analysis evidence includes, in addition to
covert-channel test plans and results, the documentation of the
covert-channel identification method and tools, covert- channels
found, and bandwidth estimation. All storage and timing channels found
must be described in terms of the covert transmission scenarios (e.g.,
variables altered and viewed, source of time modulation). The cause of
each covert channel, or class of covert channels, must also be
documented.
5.2.4.4 Product Support
The product support evidence consists of the development environment
and operational support documentation and tools. The development
environment evidence includes the documentation of the product
life-cycle process, configuration management procedures enforced, and
the trusted distribution mechanisms and procedures used. This evidence
also includes the identification of (1) the tools used in the product
development, configuration management, and trusted distribution, and
(2) the characteristics that make those tools suitable for development
of protection in IT products.
The operational support evidence includes the User's Guide and the
Trusted Facility Manual, the documentation describing the flaw
remediation policies and procedures, and the documentation describing
the trusted product generation. It also includes the description of
the tools used (if any) in the product flaw remediation and trusted
generation.
5.3 Rated Development Assurance Components
Each development assurance component addresses a unique IT
development, support, or maintenance method available to an IT product
developer (producer) for establishing the functional correctness of a
specific product. Although these methods change over time as these
disciplines mature, evolve, and new disciplines are introduced, all
existing and future methods can be rated by generic characteristics.
The extent to which such methods are used in a product development,
maintenance, and operation can be determined by the extent to which
the requirements of each method are satisfied. For this reason, the
assurance components are rated according to the extent to which their
requirements are satisfied. The rating of the assurance components
included herein is based on the following four parameters: (1) the
scope of the assurance method used, (2) the precision, or level of
detail, used in, or allowed by, applying a specific method, (3) the
coverage of the method, and (4) the strength of the particular method
employed.
1. Scope. The scope of a method determines whether the method applies
to all functional-component properties and to all steps of the product
development, maintenance, or operation processes. For example, a
specific design analysis method or a specific testing method may be
applied to security-policy properties, but not to TCB protection or
reference mediation properties; and a covert channel identification
method and tool may apply only to the design-specification step of the
development process, but not to the implementation step. Similarly, a
configuration-control method may apply only to source code or to
design specifications, test plans, documentation, source code, and
hardware specifications; and a guidance manual (e.g., Trusted Facility
Manual) referring to product operation may, or may not, include all
system administration properties or requirements.
2. Precision. The precision in applying a method determines the level
of detail at which the method is applied in product development,
maintenance, or operation. For example, an analysis method may be
applied to a description of a functional component, to an informal
specification, or to a formal specification; it may require a formal
or an informal model of the functional-component properties; it may
require that formal correspondence between different levels of product
design be established or only that informal correspondences be
established; it may require that these correspondences show that all
TCB properties are preserved by the correspondence or only that some
properties are preserved. Similarly, the degree of precision in
applying the method may require that the design, coding, and
configuration-control methods be described or defined; that they be
applied to TCB functions, subsystems, or individual low-level modules,
or only to TCB functions. Or, the degree of precision of the
operational method for flaw discovery, tracking, and repair may
indicate whether specific response-time deadlines are provided for
flaw repair.
3. Coverage. The coverage of a method determines the extent to which
the method is applied to a functional component, that is, whether the
method is fully or only partially applied to a functional component.
For example, security testing may use all test conditions required by
a functional-component description or model, or only a subset of those
conditions; or the test data may cover all positive and negative
outcomes of a test condition or only a subset of those outcomes.
Similarly, configuration management may require that all
change-control conditions be applied to the configuration items or
that only a subset of those conditions be applied. Or, the
operational method of flaw discovery, tracking, and repair may, or may
not, use all conditions of flaw discovery, tracking, and repairs, or
only a subset of these conditions (e.g., use an explicit
protection-problem report step, take into account the consumer
protection requirements whenever protection flaws are repaired, and
maintain flaw reports and corrections under configuration management).
4. Strength. The strength of a method used may vary according to the
characteristics of the method. For example, test methods based on data
flow coverage are inherently stronger than those based on
boundary-value coverage (e.g., data-flow testing vs. monolithic
functional testing). Covert-channel identification methods that
eliminate false flows (i.e., formal flow violations) are inherently
stronger than those that allow the discovery of false flows. Methods
for estimating the maximum covert-channel bandwidth based on
information theory are inherently stronger than those exclusively
based on performance measurements. Configuration management methods
and tools that automatically enforce all change-control conditions are
inherently stronger than those that require operator-controlled
enforcement. Compilers that enforce programming conventions and
disciplines (e.g., type checking for user-defined, abstract data
types) are inherently stronger than those that merely perform syntax
checking.
The above parameters are chosen because, although general in nature,
they facilitate the rating of the assurance components at levels of
detail comparable to those of existing standards, thereby enabling
potential harmonization with these standards. Other rating parameters
that are equally suitable may exist. The parameters used to rate each
development assurance component are summarized in Table 3.
Table 3. Rating Summary for Development Assurance Components
.----------------------------------------------------------------------.
| | | Prec- | Cover- | |
| Development Assurance Components | Scope | ision | age | Strength |
|======================================================================|
| Development Process |
|----------------------------------+-------+-------+--------+----------|
| TCB Property Definition | | X | X | |
|----------------------------------+-------+-------+--------+----------|
| TCB Design |
|----------------------------------+-------+-------+--------+----------|
| TCB Element Identification | | | X | |
|----------------------------------+-------+-------+--------+----------|
| TCB Interface Definition | | X | | |
|----------------------------------+-------+-------+--------+----------|
| TCB Modular Decomposition | | X | X | |
|----------------------------------+-------+-------+--------+----------|
| TCB Structuring Support | X | X | | |
|----------------------------------+-------+-------+--------+----------|
| TCB Design Disciplines | | | X | |
|----------------------------------+-------+-------+--------+----------|
| TCB Implementation Support | | X | X | |
|----------------------------------+-------+-------+--------+----------|
| TCB Testing and Analysis |
|----------------------------------+-------+-------+--------+----------|
| Functional Testing | | X | X | |
|----------------------------------+-------+-------+--------+----------|
| Penetration Analysis | X | X | X | X |
|----------------------------------+-------+-------+--------+----------|
| Covert Channel Analysis | X | X | X | X |
|----------------------------------+-------+-------+--------+----------|
| Operational Support |
|----------------------------------+-------+-------+--------+----------|
| User Security Guidance | | | | |
|----------------------------------+-------+-------+--------+----------|
| Administrative Guidance | | | X | |
|----------------------------------+-------+-------+--------+----------|
| Flaw Remediation | | X | X | X |
|----------------------------------+-------+-------+--------+----------|
| Trusted Generation | | | X | X |
|----------------------------------+-------+-------+--------+----------|
| Development Environment |
|----------------------------------+-------+-------+--------+----------|
| Life Cycle Definition | | X | X | |
|----------------------------------+-------+-------+--------+----------|
| Configuration Management | | X | X | X |
|----------------------------------+-------+-------+--------+----------|
| Trusted Distribution | | | | X |
|----------------------------------+-------+-------+--------+----------|
| Development Evidence |
|----------------------------------+-------+-------+--------+----------|
| TCB Protection Properties | | X | X | |
|----------------------------------+-------+-------+--------+----------|
| Product Design & Implementation | X | X | X | |
|----------------------------------+-------+-------+--------+----------|
| Product Testing & Analysis |
|----------------------------------+-------+-------+--------+----------|
| Functional Testing | | X | X | |
|----------------------------------+-------+-------+--------+----------|
| Penetration Analysis | X | X | X | X |
|----------------------------------+-------+-------+--------+----------|
| Covert Channel Analysis | X | X | X | X |
|----------------------------------+-------+-------+--------+----------|
| Product Support | | X | X | X |
`----------------------------------------------------------------------'
5.3.1 Development Process
5.3.1.1 Rated TCB Property Identification Components
The TCB property identification components are rated based on the
precision and coverage of the methods for TCB property identification.
At level PD-1, the TCB properties are informally defined by
interpreting the functional component requirements within the TCB. At
level PD-2, precision is extended by the use of informal models of
functional requirements and by requiring definitions, instead of
descriptions, of the TCB element operations. At level PD-3, both the
precision and coverage are extended. Precision is extended by
requiring the use of formal models of functional requirements, and by
the use of Descriptive Interface Specifications (DIS) for the TCB.
Coverage of the interpretation method is extended by including a
demonstration, by coherent arguments, that the TCB operation defined
in the DIS is consistent with the appropriate formal models. At level
PD-4, both precision and the coverage of the interpretation method are
further extended. Precision is further extended by requiring the use
of Formal Interface Specifications (FIS) for the TCB; coverage of the
interpretation method is extended by including a proof that the TCB
operation, as defined by the FIS, is consistent with the appropriate
formal models, and by requiring that no TCB elements remain uncovered
by the this interpretation.
PD-1 Property Description
The developer shall interpret the functional requirements of the
protection profile within the product TCB. For each functional
requirement, the developer shall: (1) identify the TCB elements and
their TCB interfaces (if any) that implement that requirement; (2)
describe the operation of these TCB elements, and (3) explain why the
operation of these elements is consistent with the functional
requirement.
PD-2 Informal Property Identification
The developer shall provide informal models for the functional
components and sub-components of the profile. At a minimum, an
informal model of the access control components shall be provided.
Each informal model shall include (abstract) data structures and
operations defining each functional component or sub-component, and a
description of the model properties. The developer shall interpret
(e.g., trace) the informal models within the product TCB. For each
model entity, the developer shall: (1) identify the TCB elements and
their TCB interfaces (if any) that implement that entity; (2) define
the operation of these TCB elements, and (3) explain why the operation
of these elements is consistent with the model properties. The
developer's interpretation of each informal model, which defines the
TCB properties, shall identify all TCB elements that do not correspond
to any model entity and shall explain why these elements do not render
the TCB properties invalid.
For the components that are not informally modeled, the developer
shall interpret the functional requirements of the protection profile
within the product TCB. For each functional requirement, the developer
shall: (1) identify the TCB elements and their TCB interfaces (if any)
that implement that requirement; (2) describe the operation of these
TCB elements, and (3) explain why the operation of these elements is
consistent with the functional requirement. The developer's
interpretation of each functional requirement, which describes the TCB
properties, shall identify all TCB elements that do not correspond to
any functional requirement and shall explain why these elements do not
render the TCB properties invalid.
PD-3 Property Specification by Model Interpretation
The developer shall provide formal models for the functional
components and sub-components of the profile. At a minimum, a formal
model of the access control components shall be provided. The
properties of the formal models shall be clearly stated. The developer
shall provide an interpretation of the models in the DIS of the
product's TCB. For each model entity, the developer shall: (1)
identify the TCB elements and their DIS (if any) that implement that
entity; (2) define the operation of these TCB elements, and (3)
demonstrate, by coherent arguments, that the DIS of these elements is
consistent with the model properties. The developer's interpretation
of each formal model, which specifies the TCB properties, shall
identify all TCB and DIS elements (if any) that do not correspond to
any model entity and shall explain why these elements do not render
the TCB properties invalid.
An informal model of reference mediation and TCB protection shall be
provided. For the components that are not modeled, the developer shall
interpret the functional requirements of the protection profile within
the product TCB. For each functional requirement, the developer shall:
(1) identify the TCB elements and their TCB interfaces (if any) that
implement that requirement; (2) describe the operation of these TCB
elements, and (3) explain why the operation of these elements is
consistent with the functional requirement. The developer's
interpretation of each functional requirement, which describes the TCB
properties, shall include all the TCB elements.
PD-4 Formal Specification of TCB Properties
The developer shall provide formal models for the functional
components and sub-components of the profile. At a minimum, a formal
model of the access control components shall be provided. The
properties of the formal models shall be clearly stated. The developer
shall provide a formal interpretation of the models in the FIS of the
product's TCB. For each model entity, the developer shall: (1)
identify the TCB elements and their FIS (if any) that implement that
entity; (2) specify the operation of these TCB elements, and (3) prove
that the FIS of these elements is consistent with the model
properties. The developer's interpretation of each formal model, which
specifies the TCB properties, shall identify all TCB and FIS elements
(if any) that do not correspond to any model entity and shall explain
why these elements do not render the TCB properties invalid.
An informal model of reference mediation and TCB protection shall be
provided. For the components that are not modeled, the developer shall
interpret the functional requirements of the protection profile within
the product TCB. For each functional requirement, the developer shall:
(1) identify the TCB elements and their TCB interfaces (if any) that
implement that requirement; (2) describe the operation of these TCB
elements, and (3) explain why the operation of these elements is
consistent with the functional requirement. The developer's
interpretation of each functional requirement, which describes the TCB
properties, shall include all the TCB elements.
5.3.1.2 Rated TCB Element Identification Components
The TCB element identification components are rated based on the
coverage of the identification method. That is, the two levels of
identification requirements are distinguished by whether the retention
of protection-irrelevant elements within the TCB is justified.
ID-1: TCB Element Identification
The developer shall identify the TCB elements (i.e., software,
hardware/firmware code and data structures). Each element must be
unambiguously identified by its name, type, release, and version
number (if any).
ID-2: TCB Element Justification
The developer shall identify the TCB elements (i.e., software,
hardware/firmware code and data structures). Each element must be
unambiguously identified by its name, type, release, and version
number (if any).
The developer shall justify the protection relevance of the identified
elements (i.e., only elements that can affect the correct operation of
the protection functions shall be included in the TCB). If
protection-irrelevant elements are included in the TCB, the developer
shall provide a rationale for such inclusion.
5.3.1.3 Rated TCB Interface Definition Components
The TCB interface definition components are rated based on the
precision of the interface definition method. The precision of the
interface definition methods required at level IF-2 is higher than
that of level IF-1, because level IF-2 requires a Descriptive
Interface Specification, not just an informal interface description.
Similarly the precision of the interface definition methods required
at level IF-3 is higher than that of level IF-2, because level IF-3
requires a Formal Interface Specification, not just a Descriptive
Interface Specification.
IF-1: Interface Description
The developer shall describe all external (e.g., command, software,
and I/O) administrative (i.e., privileged) and non-administrative
interfaces to the TCB. The description shall include those components
of the TCB that are implemented as hardware and/or firmware if their
properties are visible at the TCB interface.
The developer shall identify all call conventions (e.g., parameter
order, call sequence requirements) and exceptions signaled at the TCB
interface.
IF-2: Interface Descriptive Specification
The developer shall define all external (e.g., command, software, and
I/O) administrative (i.e., privileged) and non-administrative
interfaces to the TCB.
The developer shall provide and maintain a descriptive interface
specification (DIS) of the TCB that completely and accurately
describes the TCB in terms of exceptions, error messages, and effects.
The DIS shall identify the TCB call conventions (e.g., parameter
order, call sequence requirements), and exceptions signaled. The DIS
shall also include the TCB call identifier, parameter types (e.g.,
input, output), the effect of the call, TCB call conventions (e.g.,
parameter order, call sequence requirements), and exceptions handled
and signaled. It shall be shown to be an accurate description of the
TCB interface.
The DIS shall include those components of the TCB that are implemented
as hardware and/or firmware if their properties are visible at the TCB
interface.
If the TCB consists of a kernel and privileged processes, the
developer shall separately identify and define the interfaces for the
kernel and each privileged process.
Whenever covert-channel analysis, penetration analysis, and
resource-constraint analysis are required, the TCB interface
definition must also include all effects of a call including the
direct visibility and alterability of internal TCB variables and
functions.
IF-3: Formal Interface Specification
The developer shall define all external (e.g., command, software, and
I/O) administrative (i.e., privileged) and non-administrative
interfaces to the TCB.
The developer shall provide and maintain a descriptive interface
specification (DIS) of the TCB that completely and accurately
describes the TCB in terms of exceptions, error messages, and effects.
The DIS shall identify the TCB call conventions (e.g., parameter
order, call sequence requirements), and exceptions signaled. The DIS
shall also include the TCB call identifier, parameter types (e.g.,
input, output), the effect of the call, TCB call conventions (e.g.,
parameter order, call sequence requirements), and exceptions handled
and signaled. It shall be shown to be an accurate description of the
TCB interface.
A Formal Interface Specification (FIS) of the TCB shall be maintained
that accurately describes the TCB in terms of the call identifier,
parameter types (e.g., input, output), the effect of the call, TCB
call conventions (e.g., parameter order, call sequence requirements),
and exceptions signaled.
The DIS and FIS shall include those components of the TCB that are
implemented as hardware and/or firmware if their properties are
visible at the TCB interface.
If the TCB consists of a kernel and privileged processes, the
developer shall separately identify and define the interfaces for the
kernel and each privileged process.
Whenever covert-channel analysis, penetration analysis, and
resource-constraint analysis are required, the TCB interface
definition must also include all effects of a call including the
direct visibility and alterability of internal TCB variables and
functions.
5.3.1.4 Rated Modular Decomposition Components
The modular decomposition components are rated based on the precision
and coverage of the decomposition method. The granularity of the
modular TCB decomposition at level MD-1, which delimits the precision
of the decomposition method, refers to subsystem-level decomposition.
The decomposition granularity is refined at level MD-2, as each
subsystem is further decomposed into constituent modules. Level MD-2
also extends the coverage of the decomposition method by requiring
that inter-module relationships be used in the decomposition method.
Level MD-3 further extends the coverage of the decomposition method by
requiring that the inter-module correctness dependencies be analyzed
(see Appendix D).
MD-1: Subsystem Decomposition
The developer shall describe the TCB structure in terms of its design
and implementation subsystems and the functional relationships between
those subsystems. The developer shall identify the specific TCB
protection functions (if any) associated with each subsystem and the
TCB interfaces (if any) implemented by each subsystem. The developer
shall describe the interfaces between the subsystems.
For each subsystem, the developer shall describe: the role or purpose
of the subsystem, the set of related functions performed by the
subsystem, and the subsystem interface (i.e., the set of invocable
functions, calling conventions, parameters, global variables, and
results).
MD-2: Module-level Decomposition
The developer shall design the TCB as a small number (e.g., 10 to 100)
of design and implementation subsystems that have well-defined
functional relationships and shared-data dependencies. The developer
shall identify the specific TCB protection functions (if any)
associated with each subsystem and the TCB interfaces (if any)
implemented by each subsystem.
The developer shall design each subsystem as a set of modules. For
each module, the developer shall describe: the role or purpose of the
module, the set of related functions performed by the module, and the
module interface (i.e., the set of invocable functions, calling
conventions, parameters, global variables, and results). The developer
shall identify the protection functions of, and describe the
interfaces between, these modules. The developer shall choose the
modules so that the set of functions implemented by the module, the
module's contribution to the TCB protection properties, and the
interface(s) to the module can be described concisely (e.g., the
module shall have a single purpose). The TCB structuring into modules
shall be based on well- defined module relationships; for example, the
contains relation (e.g., A is part of B) or the "uses" relation (e.g.,
A is correct only if B is correct).
MD-3: Module Relationship Analysis
The developer shall design the TCB as a small number (e.g., 10 to 100)
of design and implementation subsystems that have well-defined
functional relationships and shared-data dependencies. The developer
shall identify the specific TCB protection properties and functions
associated with each subsystem and the TCB interfaces (if any)
implemented by each subsystem.
The developer shall design each subsystem as a set of modules. For
each module, the developer shall describe: the role or purpose of the
module, the set of related functions performed by the module, and the
module interface (i.e., the set of invocable functions, calling
conventions, parameters, global variables, and results). The developer
shall identify the protection functions of, and describe the
interfaces between, these modules. The developer shall choose the
modules so that the set of functions implemented by the module, the
module's contribution to the TCB protection properties, and the
interface(s) to the module can be described concisely (e.g., the
module shall have a single purpose). The TCB structuring into modules
shall be based on well- defined module relationships; for example, the
contains relation (e.g., A is part of B), the "uses" relation (e.g., A
is correct only if B is correct). The developer shall analyze the
correctness dependencies among these modules. This analysis may
include, but is not restricted to, service and environmental
dependencies.
5.3.1.5 Rated TCB Structuring Support Components
The TCB structuring support components are rated based on the scope
and precision of the supporting mechanisms used in TCB structuring.
Ascending levels are assigned to mechanisms supporting TCB process
isolation, TCB modularity, and storage objects to reflect the degrees
of usefulness in TCB structuring added by these mechanisms. The
precision and conceptual simplicity of these mechanisms are assigned
to the highest level reflecting their importance in the rigorous
analysis of TCB structuring support.
At level SP-1, the structuring of the TCB includes the minimal
requirement of process isolation. Level SP-2 extends the support for
TCB structuring by including the separation of protection critical
elements and use of processor support for logically distinct storage
objects. Level SP-3 extends the precision requirements in the
definition of the protection mechanisms for TCB structuring support
SP-1: Process Isolation
The TCB shall maintain process isolation.
SP-2: Support for Storage Objects
The TCB shall maintain process isolation. The TCB shall separate those
elements that are protection- critical from those that are not.
Features in hardware, such as segmentation, shall be used to support
logically distinct storage objects with separate access-control
attributes (e.g., readable, writable).
SP-3: Structured Protection Mechanisms
The TCB shall maintain process isolation. The TCB shall separate those
elements that are protection- critical from those that are not.
Features in hardware, such as segmentation, shall be used to support
logically distinct storage objects with separate access-control
attributes (e.g., readable, writable). The TCB shall employ a
complete, conceptually simple, protection mechanism with precisely
defined semantics. This mechanism shall play a central role in
enforcing the internal structuring of the TCB and the product.
5.3.1.6 Rated TCB Design Discipline Components
The TCB design discipline components are rated based on the coverage
of the disciplines used for TCB structuring. The requirements range
from TCB complexity minimization to the use of data hiding, layering,
and high-level synchronization constructs.
At level DD-1, the design disciplines covered include that of
minimizing the TCB complexity, of maximizing the use of data hiding,
and of employing well-defined exception handling techniques. Level
DD-2 extends this coverage by including the use of layering,
high-level synchronization primitives, and
multi-tasking/multi-threaded modules.
DD-1: Specification of Disciplines Used
The developer shall design the product to minimize the complexity of
the TCB. System engineering shall be directed towards excluding from
the TCB modules that are not protection critical.
The TCB design shall reflect use of modern software engineering
techniques, such as data hiding and abstraction (i.e., data,
functional, and control abstractions) and well-defined
exception-handling.
DD-2: Extended Disciplines for TCB Structuring
The developer shall design the product to minimize the complexity of
the TCB. System engineering shall be directed towards excluding from
the TCB modules that are not protection critical.
The TCB design shall reflect use of modern software engineering
techniques), such as data hiding and abstraction (i.e., data,
functional, and control abstractions) and well-defined
exception-handling. The TCB design shall also include use of layering
(including a rationale for each layering violation), high-level
synchronization constructs, and multi-tasking/ multi-threading.
5.3.1.7 Rated Implementation Support Components
The implementation support components are rated according to the
precision and coverage in maintaining the implementation elements of
the TCB. At IM-1, the developer is only required to maintain the
implementation data used to generate a physical instantiation of the
TCB. IM-2 extends precision and coverage by requiring that the
implementation data be organized to reflect the TCB subsystem
structure and be identified as distinct configuration items. IM-3
further extends precision by requiring that the implementation data
reflect the TCB module structure. Finally, IM-4 further extends the
coverage of the maintenance method by requiring that the coding
standards be identified and enforced, and that the implementation data
modules use the same naming conventions as the design data to help
establish a link between the design and the implementation.
IM-1: Source Data Support
The developer shall maintain engineering diagrams and source code (as
applicable) for all TCB elements.
IM-2: Subsystem Correspondence Support
The developer shall maintain engineering diagrams and source code (as
applicable) for all TCB elements. The diagrams and source code for
each subsystem of the TCB shall be identified and provided as
configuration items.
IM-3: Module Correspondence Support
The developer shall maintain engineering diagrams and source code (as
applicable) for all TCB elements. The diagrams and source code for
each module of the TCB shall be identified and provided as
configuration items.
IM-4: Naming Support For Design Correspondence
The developer shall maintain engineering diagrams and source code (as
applicable) for all TCB elements. The developer shall identify the
programming languages used to develop the TCB software and reference
the definitions of those languages. The developer shall identify any
implementation dependent options of the programming language
compiler(s) used in the TCB source code. The developer shall describe
coding standards followed during the implementation of the product and
shall ensure that all source code complies with these standards. The
diagrams and source code for each module of the TCB shall be
identified and provided as configuration items. The diagrams and
source code shall be named using the same conventions as those used in
the TCB design. The developer shall explain how the programming
languages used help establish the correspondence between the TCB
implementation and design.
5.3.1.8 Rated Functional Testing Components
The functional testing components are rated according to the precision
and coverage of the testing method. The scope of testing is constant:
all functions (as represented by TCB properties) required by the
protection profile must be tested. The strength of the testing method
is assumed to be the same: testing is always used to show the presence
of desired functionality. The precision of testing refers to the
accuracy of the TCB properties and the interface definition (i.e., the
interface description, DIS, or FIS) used to derive test conditions and
data. The coverage of testing refers to the extent to which each
function is tested (e.g., whether all or only a defined set of
boundary conditions are tested).
At FT-1, the goal is to produce functional evidence that the TCB is
capable of satisfying the protection profile requirements. At FT-2,
the coverage of the testing is increased by requiring the tests to
sample more of the range of TCB inputs. Coverage is also increased by
requiring that tests for previously discovered TCB flaws be executed
for all subsequent versions of the TCB (i.e., by regression testing).
Precision is extended at level FT-3by requiring that interface
specifications (i.e., DIS, FIS) be used to generate the test
conditions and data.
FT-1: Conformance Testing
The developer shall test the TCB interface to show that all claimed
protection functions work as stated in the TCB interface description.
The developer shall correct all flaws discovered by testing and shall
retest the TCB until the protection functions are shown to work as
claimed.
FT-2: TCB Interface Testing
The developer shall test the TCB interface to show that all claimed
protection functions work as stated in the TCB interface description
or specification. The tests shall exercise the boundary conditions of
the protection functions. The developer test procedures shall include
the tests used to demonstrate the absence of all flaws discovered in
previous versions of the TCB.
The developer shall correct all flaws discovered by testing and shall
retest the TCB to show that all discovered flaws have been eliminated,
no new flaws have been introduced, and the protection functions work
as claimed.
FT-3: Specification-Driven TCB Interface Testing
The developer shall test the TCB interface to show that all claimed
protection functions work as stated in the TCB interface description
or specification. The tests shall exercise the boundary conditions of
the protection functions. The developer shall generate the test
conditions and data from the Descriptive or Formal Interface
Specification(s). The developer test procedures shall include the
tests used to demonstrate the absence of all flaws discovered in
previous versions of the TCB.
The developer shall correct all flaws discovered by testing and shall
retest the TCB to show that all discovered flaws have been eliminated,
no new flaws have been introduced, and the protection functions work
as claimed.
5.3.1.9 Rated Penetration Analysis Components
The penetration analysis components are rated based on the scope,
precision, coverage, and strength of the analysis methods used. The
scope and precision of the level PA-1 is limited to penetration
testing methods referring only to unprivileged user and application
programming interfaces of the TCB. The precision of penetration
testing is limited to that derived from documentation of the TCB
interface (e.g., system reference manuals). The coverage may be
limited to the testing of known classes of penetration flaws found in
other TCBs of the same, or different, types of products (e.g., generic
penetration flaws).
At level PA-2, both the precision and the coverage of penetration
testing are extended. The sources of design and implementation
information include, in addition to system reference manuals and TCB
interface description, the DIS, source code, and hardware and firmware
specifications. The test conditions are systematically generated using
the flaw- hypothesis method using the TCB interface specification.
Level PA-3 augments penetration testing with penetration- resistance
verification methods. In particular, penetration resistance properties
are defined and condition (validation) check specifications are
written for each property. The DIS and source code are then verified
to establish that the verification conditions are in fact implemented.
Level PA-4 represents a significant extension in the strength of the
penetration analysis. That is, it requires that the penetration
resistance properties of a TCB be verified formally using analysis
tools. This level assumes that the design and implementation of a TCB
is free of flaws that would cause penetration, and is intended to
demonstrate that TCB interfaces are resistant to penetration. As such,
it represents the highest level of penetration analysis assurance.
PA-1 Basic Penetration Testing
The developer shall define the TCB configuration, interface, and
protection functions that are subject to penetration testing. For each
test, the developer shall identify the goal of the test and the
criteria for successful penetration. The developer shall identify all
product documentation (e.g., system reference manuals) used to define
penetration-test conditions, and shall document all test conditions,
data (e.g., test set-up, function call parameters, and test outcomes),
and coverage.
The penetration testing shall include, at a minimum, known classes of
penetration flaws found in other TCBs (e.g., generic penetration
flaws). For each uncovered flaw, the developer shall define and
document scenarios of flaw exploitation, and shall identify all
penetration outcomes resulting from that scenario.
PA-2 Flaw-Hypothesis Testing
The developer shall define the TCB configuration, interface, and
protection functions that are subject to penetration testing. For each
test, the developer shall identify the goal of the test and the
criteria for successful penetration. The developer shall illustrate
how, in addition to system reference manuals and TCB interface
description, the DIS, source code, and hardware and firmware
specifications are used to define penetration-test conditions. For
each test, the developer shall document all test conditions, data
(e.g., test set-up, function call parameters, and test outcomes), and
coverage.
The developer shall generate the test conditions from flaw-hypotheses
derived by negating assertions of TCB design capabilities and by
providing counter examples that show that these assertions are false.
The developer shall confirm the flaw hypotheses by checking design and
implementation documentation, by defining the test data and running
test programs, or by referring to known classes of penetration flaws
found in other TCBs. The refutation of any hypothesis shall be
documented.
For each uncovered flaw, the developer shall define and document
scenarios of flaw exploitation and shall identify all penetration
outcomes resulting from that scenario. The cause of the flaw shall be
identified and documented.
PA-3 Penetration Analysis
The developer shall define the TCB configuration, interface, and
protection functions that are subject to penetration testing and
verification. For each test, the developer shall identify the goal of
the test and the criteria for successful penetration. The developer
shall illustrate how, in addition to system reference manuals and TCB
interface description, the DIS, source code, and hardware and firmware
specifications are used to define penetration-test conditions. For
each test, the developer shall document all test conditions, data
(e.g., test set-up, function call parameters, and test outcomes), and
coverage.
The developer shall generate the test conditions from flaw-hypotheses
derived by negating assertions of TCB design capabilities and by
providing counter examples that show that these assertions are false.
The developer shall confirm the flaw hypotheses by checking design and
implementation documentation, by defining the test data and running
test programs, or by referring to known classes of penetration flaws
found in other TCBs. The refutation of each hypothesis shall be
documented.
The developer shall derive penetration-resistance properties and
conditions by interpreting reference mediation and TCB protection
requirements in the product's TCB. The penetration-resistance
properties and conditions shall also reflect the strength of
functional components (e.g., strength of the identification and
authentication).
The developer shall verify that the penetration- resistance conditions
are implemented by the TCB functions. All uncovered flaws in
implementing the penetration-resistance conditions shall be
documented. For each uncovered flaw, the developer shall define and
document scenarios of flaw exploitation and shall identify all
penetration outcomes resulting from that scenario. The cause of the
flaw shall be identified and documented.
PA-4 Analysis of Penetration Resistance
The developer shall define the TCB configuration, interface, and
protection functions that are subject to penetration testing and
verification. For each test, the developer shall identify the goal of
the test and the criteria for successful penetration. The developer
shall illustrate how, in addition to system reference manuals and TCB
interface description, the DIS, source code, and hardware and firmware
specifications are used to define penetration-test conditions. For
each test, the developer shall document all test conditions, data
(e.g., test set-up, function call parameters, and test outcomes), and
coverage.
The developer shall generate the test conditions from flaw-hypotheses
derived by negating assertions of TCB design capabilities and by
providing counter examples that show that these assertions are false.
The developer shall confirm the flaw hypotheses by checking design and
implementation documentation, by defining the test data and running
test programs, or by referring to known classes of penetration flaws
found in other TCBs. The refutation of each hypothesis shall be
documented.
The developer shall use the DIS, FIS, source code, and hardware and
firmware specifications to derive and specify penetration-resistance
conditions, and shall document all such conditions. The developer
shall derive penetration-resistance properties and conditions by
interpreting reference mediation and TCB protection requirements in
the product's TCB. The penetration-resistance properties and
conditions shall also reflect the strength of functional components
(e.g., strength of the identification and authentication).
The developer shall verify that the penetration- resistance conditions
are implemented by the TCB functions. Tools shall be used to verify
the penetration-resistance properties of the FIS and source code. The
tools shall be capable of checking whether a set of
penetration-resistance conditions is implemented by the FIS and/or
source code of a TCB function. All uncovered flaws in implementing the
penetration-resistance conditions shall be documented. For each
uncovered flaw, the developer shall define and document scenarios of
flaw exploitation and shall identify all penetration outcomes
resulting from that scenario. The cause of the flaw shall be
identified and documented.
5.3.1.10 Rated Covert-Channel Analysis Components
The covert channel analysis components are rated based on the scope,
precision, coverage, and strength of the analysis methods. The scope
and precision of level CCA-1are limited to storage channels identified
in TCB reference manuals and DIS, and the strength of maximum
bandwidth estimation is limited to that provided by informal
engineering measurements. The scope of identification method is
increased at level CCA-2 by including both storage and timing channels
and, consequently, enlarging the scope of the sources of information
used (e.g., by introducing processor and hardware specifications). At
level CCA-3, the precision and coverage of the covert identification
are extended to include analysis of FIS and specification-to-code
correspondence. Also, the strength of the maximum bandwidth estimation
is increased by the requirement to use information theory methods.
CCA-1 Analysis of Covert Storage Channels
1. Identification: The developer shall identify all sources of
information used in covert-storage- channel analysis. These sources
shall include TCB reference manuals and DIS. The developer shall
define the identification method used. The developer shall demonstrate
that the chosen identification method is sound (e.g., it leads to the
discovery of all covert storage channels in the DIS or source
documentation) and repeatable (i.e., independent evaluators can use
the method on the same sources of covert-storage-channel information
and can obtain the same results.) The developer shall define scenarios
of use for each covert storage channel.
2. Bandwidth Measurement or Engineering Estimation: The developer
shall define the method used for covert-storage-channel bandwidth
estimation. In measuring TCB performance for covert-channel-bandwidth
estimation, the developer shall satisfy the following assumptions. The
maximum bandwidth estimation shall be based on the assumptions that
the storage channel is noiseless, that the senders and receivers are
not delayed by the presence of other processes in the product, and
that the sender-receiver synchronization time is negligible. The
choice of informal estimation methods shall define and justify the
coding method and, therefore, the distribution of "0s" and "1s" in all
transmissions.
The developer shall select TCB primitives to be measured for bandwidth
determination from real scenarios of covert-storage-channel use. The
developer shall specify TCB measurement environment for the bandwidth
measurements. This specification shall include: (1) the speed of the
product functions, (2) the product configuration, (3) the sizes of the
memory and cache components, and (4) the product initialization. The
sensitivity of the measurement results to configuration changes shall
be documented. The covert-storage-channel measurements shall include
the fastest TCB function calls for altering, viewing, and setting up
the transmission environment; the demonstrably fastest process
(context) switch time shall also be included in the bandwidth
measurements. All measurements shall be repeatable.
3. Covert Channel Testing: The developer shall test all the use of all
identified covert storage channels to determine whether the handling
functions work as intended.
CCA-2 Timing Channel Analysis
1. Identification: The developer shall identify all sources of
information used in covert-channel analysis. These sources shall
include TCB reference manuals and DIS. The sources of information and
methods of identification shall include processor specifications
whenever the identification method includes source code and hardware
analysis. The developer shall define the identification method used.
The developer shall demonstrate that the chosen identification method
is sound (e.g., it leads to the discovery of all covert channels in
the DIS or source documentation) and repeatable (i.e., independent
evaluators can use the method on the same sources of covert-channel
information and can obtain the same results.) The developer shall
define scenarios of use for each covert channel. The developer shall
also define timing channel scenarios, and shall identify all functions
that provide independent sources of timing (e.g., CPUs, I/O
processors).
2. Bandwidth Measurement or Engineering Estimation: The developer
shall define the method used for covert-channel bandwidth estimation.
In measuring TCB performance for covert-channel- bandwidth estimation,
the developer shall satisfy the following assumptions. The maximum
bandwidth estimation shall be based on the assumptions that the covert
channel is noiseless, that the senders and receivers are not delayed
by the presence of other processes in the product, and that the
sender-receiver synchronization time is negligible. The choice of
informal estimation methods shall define and justify the coding method
and, therefore, the distribution of "0s" and "1s" in all
transmissions.
The developer shall select TCB primitives to be measured for bandwidth
determination from real scenarios of covert-channel use. The developer
shall specify TCB measurement environment for the bandwidth
measurements. This specification shall include: (1) the speed of the
product functions, (2) the product configuration, (3) the sizes of the
memory and cache components, and (4) the product initialization. The
sensitivity of the measurement results to configuration changes shall
be documented. The covert-channel measurements shall include the
fastest TCB function calls for altering, viewing, and setting up the
transmission environment; the demonstrably fastest process (context)
switch time shall also be included in the bandwidth measurements. All
measurements shall be repeatable.
3. Covert Channel Testing: The developer shall test all the use of all
identified covert channels to determine whether the handling functions
work as intended.
CCA-3 Formal Covert Channel Analysis
1. Identification: The developer shall identify all sources of
information used in covert-channel analysis. These sources shall
include TCB reference manuals, DIS, and FIS. The sources of
information and methods of identification shall include processor
specifications whenever the identification method includes source code
and hardware analysis. The developer shall define the identification
method used. The developer shall define the identification method
used. The developer shall demonstrate that the chosen identification
method is sound (e.g., it leads to the discovery of all covert
channels in the FIS or source documentation) and repeatable (i.e.,
independent evaluators can use the method on the same sources of
covert-channel information and can obtain the same results.) The
method shall be applied on the FIS of the TCB, and shall include
syntactic information-flow analysis (with or without the use of
semantic analysis) or noninterference analysis. The identification of
covert channels shall include specification-to- code correspondence.
The developer shall define scenarios of use for each cover channel.
The developer shall also define timing channel scenarios, and shall
identify all functions that provide independent sources of timing
(e.g., CPUs, I/O processors).
2. Bandwidth Measurement or Engineering Estimation: The developer
shall define the method used for covert-channel bandwidth estimation.
The method shall be based on information theory methods. In measuring
TCB performance for covert- channel-bandwidth estimation, the
developer shall satisfy the following assumptions. The maximum
bandwidth estimation shall be based on the assumptions that the covert
channel is noiseless, that the senders and receivers are not delayed
by the presence of other processes in the product, and that the
sender-receiver synchronization time is negligible.
The developer shall select TCB primitives to be measured for bandwidth
determination from real scenarios of covert channel use. The developer
shall specify TCB measurement environment for the bandwidth
measurements. This specification shall include: (1) the speed of the
product functions, (2) the product configuration, (3) the sizes of the
memory and cache components, and (4) the product initialization. The
sensitivity of the measurement results to configuration changes shall
be documented. The covert-channel measurements shall include the
fastest TCB function calls for altering, viewing, and setting up the
transmission environment; the demonstrably fastest process (context)
switch time shall also be included in the bandwidth measurements. All
measurements shall be repeatable.
3. Covert Channel Testing: The developer shall test all the use of all
identified covert channels to determine whether the handling functions
work as intended.
5.3.2 Operational Support
5.3.2.1 Rated User Guidance Components
The user guidance component is unrated since it contain only one
level.
UG-1: User Guide
The developer shall provide a User Guide which describes all
protection services provided and enforced by the TCB. The User Guide
shall describe the interaction between these services and provide
examples of their use. The User Guide may be in the form of a summary,
chapter or manual. The User Guide shall specifically describe user
responsibilities. These shall encompass any user responsibilities
identified in the protection profile.
5.3.2.2 Rated Administrative Guidance Components
The rating of the administrative guidance components reflect, to a
large degree, the rating of the security management components. At
AG-1, the coverage of the Trusted Facility Manual (TFM) must include
an explanation of how the TCB can be installed and used to support an
organization's security policy. This explanation must include a
discussion of how to set the security parameters for all TCB functions
and how to use the audit trail to discover policy violations (see the
administrative functions of components SM-1 and SM-2). At AG- 2, TFM
coverage is extended to include a discussion of how to set additional
policy parameters, how to use the separate administrator and operator
roles and privileges, and how to securely generate the TCB (see the
administrative functions of component SM-3). Finally, at AG-3, which
assumes a product with fine-grained privileges, the TFM coverage is
increased to include the use of those privileges in implementing
extensive administrative policies (see the administrative functions of
component SM-4).
AG-1: Basic Administrative Guidance
The developer shall provide a Trusted Facility Manual intended for the
product administrators that describes how to use the TCB security
services (e.g., Access Control, System Entry, or Audit) to enforce a
system security policy. The Trusted Facility Manual shall include the
procedures for securely configuring, starting, maintaining, and
halting the TCB. The Trusted Facility Manual shall explain how to
analyze audit data generated by the TCB to identify and document user
and administrator violations of this policy. The Trusted Facility
Manual shall explain the privileges and functions of administrators.
The Trusted Facility Manual shall describe the administrative
interaction between security services.
The Trusted Facility Manual shall be distinct from User Guidance, and
encompass any administrative responsibilities identified in security
management.
AG-2: Detailed Administrative Guidance
The developer shall provide a Trusted Facility Manual intended for the
product administrators and operators that describes how to use the TCB
security services (e.g., Access Control, System Entry, or Audit) to
enforce a system security policy. The Trusted Facility Manual shall
include the procedures for securely configuring, starting,
maintaining, and halting the TCB. The Trusted Facility Manual shall
explain how to analyze audit data generated by the TCB to identify and
document user and administrator violations of this policy. The
Trusted Facility Manual shall explain the unique security-relevant
privileges and functions of administrators and operators. The Trusted
Facility Manual shall describe the administrative interaction between
security services.
The Trusted Facility Manual shall identify all hardware, firmware,
software, and data structures comprising the TCB. The detailed audit
record structure for each type of audit event shall be described. If
covert channel handling is required, the Trusted Facility Manual shall
explain how to configure the product to mitigate, eliminate, or audit
covert channel exploitation. The Trusted Facility Manual shall
describe the cautions about and procedures for using the TCB as a base
for site-specific secure applications. The Trusted Facility Manual
shall describe procedures for securely regenerating the TCB after any
part is changed (e.g., due to adding devices or installing flaw
corrections to the TCB software).
The Trusted Facility Manual shall be distinct from User Guidance, and
encompass any administrative responsibilities identified in security
management.
AG-3: Role-Based Administrative Guidance
The developer shall provide a Trusted Facility Manual intended for the
product administrators and operators that describes how to use the TCB
security services (e.g., Access Control, System Entry, or Audit) to
enforce a system security policy. The Trusted Facility Manual shall
include the procedures for securely configuring, starting,
maintaining, and halting the TCB. The Trusted Facility Manual shall
explain how to analyze audit data generated by the TCB to identify and
document user and administrator violations of this policy. The
Trusted Facility Manual shall explain the unique security-relevant
privileges and functions of administrators and operators. The Trusted
Facility Manual shall also explain the distinct security-relevant
privileges and functions of the TCB and how they can be selectively
granted to provide fine-grained, multi-person or multi-role system and
application administration policies. The Trusted Facility Manual
shall describe the administrative interaction between security
services.
The Trusted Facility Manual shall identify all hardware, firmware,
software, and data structures comprising the TCB. The detailed audit
record structure for each type of audit event shall be described. If
covert channel handling is required, the Trusted Facility Manual shall
explain how to configure the product to mitigate, eliminate, or audit
covert channel exploitation. The Trusted Facility Manual shall
describe the cautions about and procedures for using the TCB as a base
for site-specific secure applications. The Trusted Facility Manual
shall describe procedures for securely regenerating the TCB after any
part is changed (e.g., due to adding devices or installing flaw
corrections to the TCB software).
The Trusted Facility Manual shall be distinct from User Guidance, and
encompass any administrative responsibilities identified in security
management.
5.3.2.3 Rated Flaw Remediation Components
The flaw remediation components are rated according to the precision,
coverage and strength of the procedures used to identify and correct
flaws, and disseminate corrections to affected consumers. At FR-1, the
developer is responsible for establishing procedures to accept reports
of flaws, find corrections to those flaws, and disseminate the flaw
corrections to consumers who specifically request the corrections. At
FR-2, the precision of the developer-consumer interaction is increased
by requiring that the developer identify and publicize specific points
of contact for product security concerns. Coverage is increased by
requiring a remediation policy that distinguishes protection-relevant
changes to the product from other changes. At FR-3, the coverage of
both flaw repair and customer interaction procedures is increased by
considering the customer's security policies and by relating each
entry in the flaw tracking and repair database to the consumers who
might be affected. At FR-4, precision and coverage are extended by
requiring the developer to notify consumers of flaw discovery and to
distribute corrections of the discovered flaws within specific time
limits. Finally, at FR-5, the method is strengthened by requiring that
the flaw remediation procedures be tightly coupled to the rest of the
development process through the configuration management system.
FR-1: Basic Flaw Remediation
Flaw Tracking Procedures: The developer shall establish a procedure to
track all reported protection flaws in each release of the product.
The tracking system shall include a description of the nature and
effect of each flaw and the status of finding a correction to the
flaw.
Flaw Repair Procedures: The developer shall establish a procedure to
identify corrective actions for protection flaws.
Consumer Interaction Procedures: The developer shall provide flaw
information and corrections to registered consumers.
FR-2: Flaw Reporting Procedures
Flaw Tracking Procedures: The developer shall establish a procedure to
track all reported protection flaws with each release of the product.
The tracking system shall include a description of the nature and
effect of each flaw and the status of finding a correction to the
flaw.
Flaw Repair Procedures: The developer shall establish a procedure to
identify corrective actions for protection flaws. This procedure shall
include a policy to separate protection-relevant from non-protection
relevant corrections, changes, or upgrades to the product.
Consumer Interaction Procedures: The developer shall establish a
procedure for accepting consumer reports of protection problems and
requests for corrections to those problems. The developer shall
designate one or more specific points of contact for consumer reports
and inquiries about protection issues involving the product. This
procedure and the designated points of contact shall be provided in
the consumer documentation (e.g., the TFM or the SFUG).
FR-3: Systematic Flaw Remediation
Flaw Tracking Procedures: The developer shall establish a procedure to
track all reported protection flaws with each release of the product.
The tracking system shall include a description of the nature and
effect of each flaw and the status of finding a correction to the
flaw.
Flaw Repair Procedures: The developer shall establish a procedure to
identify corrective actions for protection flaws. This procedure shall
include a policy to separate protection-relevant from non-protection
relevant corrections, changes, or upgrades to the product. The
developer shall have a policy that when a consumer's system must be
used to diagnose and repair any problem, the developer personnel will
abide by that consumer's system security policy.
Consumer Interaction Procedures: The developer shall establish a
procedure for accepting consumer reports of protection problems and
requests for corrections to those problems. This procedure shall also
provide for automatic distribution of problem reports, for which
corrections have been found, to registered consumers who might be
affected by the problem. The developer shall designate one or more
specific points of contact for consumer reports and inquiries about
protection issues involving the product. These procedures and the
designated points of contact shall be provided in the consumer
documentation (e.g., the TFM or the SFUG).
FR-4: Timely Flaw Remediation
Flaw Tracking Procedures: The developer shall establish a procedure to
track all reported protection flaws with each release of the product.
The tracking system shall include a description of the nature and
effect of each flaw and the status of finding a correction to the
flaw.
Flaw Repair Procedures: The developer shall establish a procedure to
identify corrective actions for protection flaws. This procedure shall
include a policy to separate protection-relevant from non-protection
relevant corrections, changes, or upgrades to the product. The
developer shall have a policy that when a consumer's system must be
used to diagnose and repair any problem, the developer personnel will
abide by that consumer's system security policy.
Consumer Interaction Procedures: The developer shall establish a
procedure for accepting consumer reports of protection problems and
requests for corrections to those problems. This procedure shall
establish strict time intervals for automatically distributing the
problem reports to registered consumers who might be affected by the
problem and subsequently distributing the corrections that are found
to these same consumers. The developer shall designate one or more
specific points of contact for consumer reports and inquiries about
protection issues involving the product. These procedures and the
designated points of contact shall be provided in the consumer
documentation (e.g., the TFM or the SFUG).
FR-5: Controlled Protection State
Flaw Tracking Procedures: The developer shall establish a procedure to
track all reported protection flaws with each release of the product.
The tracking system shall include a description of the nature and
effect of each flaw and the status of finding a correction to the
flaw. The tracking system shall be incorporated into the configuration
management system.
Flaw Repair Procedures: The developer shall establish a procedure to
identify corrective actions for protection flaws. This procedure shall
include a policy to separate protection-relevant from non-protection
relevant corrections, changes, or upgrades to the product. The
developer shall have a policy that when a consumer's system must be
used to diagnose and repair any problem, the developer personnel will
abide by that consumer's system security policy.
Consumer Interaction Procedures: The developer shall establish a
procedure for accepting consumer reports of protection problems and
requests for corrections to those problems. This procedure shall
establish strict time intervals for automatically distributing the
problem reports to registered consumers who might be affected by the
problem and subsequently distributing the corrections that are found
to these same consumers. The developer shall designate one or more
specific points of contact for consumer reports and inquiries about
protection issues involving the product. These procedures and the
designated points of contact shall be provided in the consumer
documentation (e.g., the TFM or the SFUG).
5.3.2.4 Rated Trusted Generation Components
The trusted generation components are rated according to the coverage
and strength of the methods used to generate the baseline TCB. The
goal is to produce an operational TCB that does not invalidate the
protection properties established for the baseline TCB. At TG-1, the
developer must provide procedures for generating an operational TCB
from the delivered product. At TG-2, the coverage of the system
generation method is increased by requiring the developer to have the
system generation parameters default to their most restrictive
settings, thereby requiring the consumer to take a positive action to
reduce the protection provided by the TCB. At TG-3, the coverage and
strength of the generation method are increased by requiring the
developer to provide a tool that can be used after the TCB is
generated to determine if the TCB parameters are within the ranges of
a secure state. Finally, at TG-4, coverage and strength are further
extended by requiring that the product periodically execute the
parameter checking tool and alert an administrator or operator when
the TCB configuration parameters are out of range.
TG-1: Basic Trusted Generation
The developer shall establish and document the procedures that a
consumer must perform to generate an operational TCB from the
delivered copy of the master TCB. The consumer documentation shall
identify any system parameters, which are initialized or set during
system generation, that affect the TCB's conformance to the protection
profile and state the acceptable ranges of values for those
parameters.
TG-2: Trusted Generation With Fail-Safe Defaults
The developer shall establish and document the procedures that a
consumer must perform to generate an operational TCB from the
delivered copy of the master TCB. The consumer documentation shall
identify any system parameters, which are initialized or set during
system generation, that affect the TCB's conformance to the protection
profile and state the acceptable ranges of values for those
parameters. The product shall be delivered with each of these
parameters set to its fail-safe defaults.
TG-3: Trusted Generation With Secure State Review
The developer shall establish and document the procedures that a
consumer must perform to generate an operational TCB from the
delivered copy of the master TCB. The consumer documentation shall
identify any system parameters, which are initialized or set during
system generation, that affect the TCB's conformance to the protection
profile and state the acceptable ranges of values for those
parameters. The product shall be delivered with each of these
parameters set to its fail-safe defaults. The developer shall provide
the consumer with a capability to review the product security state
(e.g., by providing a program, which could be executed after
generating and starting the TCB, that determines the consistency of
the protection-relevant parameters).
TG-4: Trusted Generation With Secure State Monitoring
The developer shall establish and document the procedures that a
consumer must perform to generate an operational TCB from the
delivered copy of the master TCB. The consumer documentation shall
identify any system parameters, which are initialized or set during
system generation, that affect the TCB's conformance to the protection
profile and state the acceptable ranges of values for those
parameters. The product shall be delivered with each of these
parameters set to its most protective value. The developer shall
provide the consumer with a capability to monitor the product security
state (e.g., by providing a program, which is periodically and
automatically executed after generating and starting the TCB, that
determines the consistency of the protection- relevant parameters).
5.3.3 Development Environment
5.3.3.1 Rated Life Cycle Definition Components
The life-cycle definition components are rated according to the
precision and coverage of the engineering process used to develop the
product. Coverage refers to the extent to which the engineering
process incorporates the development and operational support
requirements of a protection profile. Precision refers to the
accuracy that can be brought to measuring the developer's conformance
to the claimed process including the specification of the programming
environment. At LC-1, the developer is required to describe the
process used to develop the product, and show how all of the
development and operational support requirements of the protection
profile are satisfied as that process is followed. No constraints are
placed on the engineering process chosen by the developer. At LC-2,
the precision and coverage are extended by requiring the developer to
use a well-defined process that provides for effective identification
of the engineering requirements as the product is developed. Finally,
at LC-3, precision and coverage are further extended by requiring a
standard engineering process, which includes well-defined coding
standards, whose use can be measured.
LC-1: Developer-Defined Life Cycle Process
The developer shall describe the process used to develop and maintain
the product. The process shall incorporate a security policy that
states the technical, physical, procedural, personnel, and other
measures used by the developer to protect the product and its
documentation. The developer shall trace each development process and
support process requirement of the protection profile to the part, or
parts, of the developer's process where the requirement is satisfied.
The developer shall identify the programming languages used to develop
the TCB software.
LC-2: Standardized Life Cycle Process
The developer shall develop and maintain the product using a well
defined, standardized engineering process. The developer shall explain
why the process was chosen and how the developer uses it to develop
and maintain the product. The process shall incorporate a security
policy that states the technical, physical, procedural, personnel, and
other measures used by the developer to protect the product and its
documentation. The developer shall demonstrate that each development
process and support process requirement of the protection profile is
satisfied by some part, or parts, of the developer's process. The
developer shall identify the programming languages used to develop the
TCB software and reference the definitions of those languages. The
developer shall identify any implementation dependent options of the
programming language compiler(s) used to implement the TCB software.
LC-3: Measurable Life Cycle Process
The developer shall develop and maintain the product using a well
defined, standardized, and measurable engineering process. The
developer shall explain why the process was chosen and how the
developer uses it to develop and maintain the product. The developer
shall comply with the engineering process standard. The process shall
incorporate a security policy that states the technical, physical,
procedural, personnel, and other measures used by the developer to
protect the product and its documentation. The developer shall
demonstrate that each development process and support process
requirement of the protection profile is satisfied by some part, or
parts, of the developer's process. The developer shall identify the
programming languages used to develop the TCB software and reference
the definitions of those languages. The developer shall identify any
implementation dependent options of the programming language
compiler(s) used to implement the TCB software and reference the
definitions of those languages.The developer shall describe coding
standards followed during the implementation of the product and shall
ensure that all source code complies with these standards.
5.3.3.2 Rated Configuration Management Components
The configuration management components are rated according to the
precision, coverage, and strength of the configuration management
methods. Level CM-1 includes basic configuration management methods
that rely on an informal mapping between the various parts of the TCB
source data, documentation, and evidence. At CM-2, the precision and
strength of configuration management are increased by requiring that a
rigorous mapping between configuration items be used, and that the
source data configuration be controlled using automated techniques. At
CM-3, coverage and strength are extended by requiring the use of a
formal acceptance procedure for generating and maintaining source
data. Finally, at CM-4, the strength of the overall configuration
management process is enhanced by requiring that it conform to
developer-defined safeguards to protect the master copy.
CM-1: Procedural Control and Generation
The developer shall establish configuration control and generation
procedures for developing and maintaining the TCB. The procedures
shall be employed to ensure that changes to the TCB are consistent
with the product's protection properties and security policy. The
developer shall employ these procedures to track changes to
development evidence, implementation data (e.g., source code and
hardware diagrams), executable versions of the TCB, test documentation
and procedures, identified flaws, and consumer documentation.
The configuration control procedures shall permit the regeneration of
any supported version of the TCB.
CM-2: Automated Source Code Control
The developer shall establish configuration control and generation
procedures for developing and maintaining the TCB. The procedures
shall be employed to ensure that changes to the TCB are consistent
with the product's protection properties and security policy. The
developer shall employ these procedures to track changes to
development evidence, implementation data (e.g., source code and
hardware diagrams), executable versions of the TCB, test documentation
and procedures, identified flaws, and consumer documentation. The
procedures shall include automated tools to control the software
source code that comprises the TCB.
The configuration control procedures shall assure a consistent mapping
among documentation and code associated with the current version of
the TCB and permit the regeneration of any supported version of the
TCB.
CM-3: Comprehensive Automated Control
The developer shall establish configuration control and generation
procedures employing automated tools for developing and maintaining
the TCB. The procedures shall be employed to ensure that changes to
the TCB are consistent with the product's protection properties and
security policy. The developer shall employ these tools to track and
control changes to development evidence, implementation data (e.g.,
source code and hardware diagrams), executable versions of the TCB,
test documentation and procedures, identified flaws, and consumer
documentation. The procedures shall include a formal acceptance
process for protection-relevant changes.
The configuration control procedures shall assure a consistent mapping
among documentation and code associated with the current version of
the TCB and permit the regeneration of any supported version of the
TCB. The developer shall provide tools for the generation of a new
version of the TCB from source code. Also, tools shall be available
for comparing a newly generated version with the previous TCB version
to ascertain that only the intended changes have been made in the code
that will actually be used as the new version of the TCB.
CM-4: Extended Configuration Management
The developer shall establish configuration control and generation
procedures employing automated tools for developing and maintaining
the TCB. The procedures shall be employed to ensure that all changes
to the TCB are consistent with the product's protection properties and
security policy. The developer shall employ these tools to track and
control changes to development evidence, implementation data (e.g.,
source code and hardware diagrams), executable versions of the TCB,
test documentation and procedures, identified flaws, and consumer
documentation. The procedures shall include a formal acceptance
process for protection-relevant changes.
The configuration control procedures shall assure a consistent mapping
among documentation and code associated with the current version of
the TCB and permit the regeneration of any supported version of the
TCB. The developer shall provide tools for the generation of a new
version of the TCB from source code. Also, tools shall be available
for comparing a newly generated version with the previous TCB version
to ascertain that only the intended changes have been made in the code
that will actually be used as the new version of the TCB. The
developer shall use a combination of technical, physical, and
procedural safeguards to protect the master copy or copies of all
material used to generate the TCB from unauthorized modification or
destruction.
5.3.3.3 Rated Trusted Distribution Components
The rating of the trusted distribution components is based on the
strength the trusted distribution methods; i.e., on the ability to
detect or prevent modifications of the consumer's copy of the TCB from
being modified while it is transferred from the development
environment to the consumer's environment. At TD-1 the developer is
responsible for establishing procedures and/or using technical
measures that will allow a consumer to detect tampering or
modification of the TCB during transfer. At TD-2, stronger methods are
required to ensure that tampering with the TCB during transfer is
prevented.
TD-1: TCB Modification Detection During Distribution
The developer shall establish procedures and employ appropriate
technical measures to detect modifications to any TCB-related
software, firmware, and hardware, including updates, that is
transferred from the development environment to a consumer's site.
TD-2: TCB Modification Prevention During Distribution
The developer shall establish procedures and employ appropriate
technical measures to prevent modifications to any TCB-related
software, firmware, and hardware, including updates, that is
transferred from the development environment to a consumer's site.
5.3.4 Development Evidence
The rating of the development evidence parallels, to a large extent,
the rating of the development process, development environment, and
operational support. Thus, the number of evidence levels required to
reflect the process, environment and operational ratings must reflect
these ratings.
The rating considerations that lead to the articulation of the
development-evidence levels are similar to those used for the
development process. For this reason they will not be repeated here.
5.3.4.1 Rated TCB Protection Property Evidence Components
EPP-1 Evidence of TCB Correspondence to the Functional Requirements
The developer shall provide documentation which describes the
correspondence between the functional component requirements and the
TCB elements and interfaces. The TCB properties, which are defined by
this correspondence, shall be explained in this documentation.
EPP-2 Evidence of Informal Model Interpretation in the TCB
The developer shall provide documentation which describes the
correspondence between the functional component requirements and the
TCB elements and interfaces. The developer shall also provide an
informal access control model and its interpretation within the TCB.
The TCB properties, which are defined by this correspondence, shall be
explained in this documentation.
EPP-3 Evidence of Formal Model Interpretation in the DIS
The developer shall provide documentation which describes the
correspondence between the functional component requirements and the
TCB elements and interfaces. This documentation shall describe how the
TCB implements the reference monitor concept. The developer shall also
provide a formal access-control model and an informal reference
mediation and TCB protection model. The TCB properties, which are
defined by this correspondence and the interpretation of these models
within the DIS of the TCB shall be documented by the product
developer.
EPP-4 Evidence of Formal Model Interpretation in the FIS
The developer shall provide documentation which describes the
correspondence between the functional component requirements and the
TCB elements and interfaces. This documentation shall describe how the
TCB implements the reference monitor concept.The developer shall also
provide a formal access-control model and an informal reference
mediation and TCB protection model. The TCB properties, which are
defined by this correspondence and the interpretation of these models
within the DIS and FIS of the TCB shall be documented by the product
developer.
5.3.4.2 Rated Product Design/Implementation Evidence Compo- nents
EPD-1: Description Of The TCB External Interface
The developer shall provide an accurate description of the functions,
effects, exceptions and error messages visible at the TCB interface.
The developer shall provide a list of the TCB elements (hardware,
software, and firmware).
EPD-2: Specification Of The TCB External Interface
The developer shall provide TCB Design Specifications that include: a
list of the TCB elements (hardware, software, and firmware
configuration items); a description of the policy allocations,
functions, and interactions among the major TCB subsystems; and module
level descriptions of all software and hardware in the TCB.
The developer shall provide a Descriptive Interface Specification
(DIS) that describes the functions, effects, exceptions and error
messages visible at the TCB interface. The developer shall show that
the DIS is an accurate representation of the TCB's external
interfaces.
The developer shall provide a description of the TCB's implementation
and an explanation of how it corresponds to the TCB design.
EPD-3: Analysis Of The TCB External Interface
The developer shall provide TCB Design Specifications that include: a
list of the TCB elements (hardware, software, and firmware
configuration items); a list of protection services provided to the
TCB by hardware, software, and firmware that is not part of the TCB;
an explanation of the techniques and criteria used during the modular
decomposition of the TCB; a description of the policy allocations,
functions, and interactions among the major TCB subsystems; and module
level descriptions of all software and hardware in the TCB.
The developer shall provide a Descriptive Interface Specification
(DIS) that describes the functions, effects, exceptions and error
messages visible at the TCB interface. The developer shall show that
the DIS is an accurate representation of the TCB's external
interfaces.
The developer shall provide TCB Implementation Data consisting of the
engineering diagrams for all hardware included in the TCB and the
source code used to generate the TCB software and firmware.
EPD-4: Policy Consistency Of The DIS
The developer shall provide TCB Design Specifications that include: a
list of the TCB elements (hardware, software, and firmware
configuration items); a list of protection services provided to the
TCB by hardware, software, and firmware that is not part of the TCB;
an explanation of the techniques and criteria used during the modular
decomposition of the TCB; a description of the policy allocations,
functions, and interactions among the major TCB subsystems; and module
level descriptions of all software and hardware in the TCB.
The developer shall provide a Descriptive Interface Specification
(DIS) that describes the functions, effects, exceptions and error
messages visible at the TCB interface and includes a convincing
argument that the DIS is consistent with the formal model of the
policy. The developer shall show that the DIS is an accurate
representation of the TCB's external interfaces.
The developer shall provide TCB Implementation Data consisting of the
engineering diagrams for all hardware included in the TCB and the
source code used to generate the TCB software and firmware. The
developer shall show that the TCB software, firmware, and hardware
implement the documented TCB design.
EPD-5: Policy Consistency Of The FIS
The developer shall provide a Descriptive Interface Specification
(DIS) that describes the functions, effects, exceptions and error
messages visible at the TCB interface and includes a convincing
argument that the DIS is consistent with the formal model of the
policy. The developer shall show that the DIS is an accurate
representation of the TCB's external interfaces.
The developer shall provide a Formal Interface Specification (FIS)
that rigorously defines the protection functions available at the TCB
interface in terms of: the protection properties implemented by each
function, the precise semantics for invoking each function, the
effects of each function (i.e., returned values and effect on the TCB
state), and the possible exceptions and error messages returned by
each function. The FIS shall be accompanied by a convincing argument
that it is consistent with the formal model of the product protection
policy. This argument shall be constructed using both manual and
machine-assisted specification and verification methods. Machine-
assisted specification and verification methods shall be approved by
the product evaluation authority.
The developer shall provide TCB Design Specifications that include: a
list of the TCB elements (hardware, software, and firmware
configuration items); a list of protection services provided to the
TCB by hardware, software, and firmware that is not part of the TCB;
an explanation of the techniques and criteria used during the modular
decomposition of the TCB; a description of the policy allocations,
functions, and interactions among the major TCB subsystems; module
level descriptions of all software and hardware in the TCB; and an
argument that the design implements exactly the functions specified in
the FIS.
The developer shall provide TCB Implementation Data consisting of the
engineering diagrams for all hardware included in the TCB and the
source code used to generate the TCB software and firmware. The
developer shall show, through either manual or machine-assisted
correspondence methods, that the TCB software, firmware, and hardware
implement the documented TCB design.
5.3.4.3 Rated Functional Testing Evidence Components
EFT-1: Evidence of Conformance Testing
The developer shall provide evidence of the functional testing that
includes the test plan, the test procedures, and the results of the
functional testing.
EFT-2: Evidence of Test Configuration Control
The developer shall provide evidence of the functional testing that
includes the test plan, the test procedures, and the results of the
functional testing. The test plans, procedures, and results shall be
maintained under the same configuration control as the TCB software.
EFT-3: Evidence of Specification-Driven Testing
The developer shall provide evidence of the functional testing that
includes the test plan, the test procedures, and the results of the
functional testing. The test, plans, procedures, and results shall be
maintained under the same configuration control as the TCB software.
The test plans shall identify the TCB specification used in the
derivation of the test conditions, data, and coverage analysis.
5.3.4.4 Rated Penetration Analysis Evidence Components
EPA-1: Evidence of Penetration Testing
The developer shall provide evidence of penetration testing. The
evidence shall identify all product documentation on which the search
for flaws was based. The penetration evidence shall describe the
scenarios for exploiting each potential flaw in the system and the
penetration test conditions, data (e.g., test set-up, function call
parameters, and test outcomes), coverage, and conclusions derived from
each scenario.
EPA-2: Evidence of Flaw-Hypothesis Generation and Testing
The developer shall provide evidence of penetration testing. The
penetration evidence shall identify all product documentation and
development evidence on which the search for flaws was based. The
penetration evidence shall describe the scenarios for exploiting each
potential flaw in the system and the penetration test conditions, data
(e.g., test set-up, function call parameters, and test outcomes),
coverage, and conclusions derived from each scenario. The penetration
evidence shall summarize both refuted and confirmed flaws hypothesis.
EPA-3: Evidence of Penetration Analysis
The developer shall provide evidence of penetration testing. The
penetration evidence shall identify all product documentation and
development evidence on which the search for flaws was based. The
penetration evidence shall describe the scenarios for exploiting each
potential flaw in the system and the penetration test conditions, data
(e.g., test set-up, function call parameters, and test outcomes),
coverage, and conclusions derived from each scenario. The penetration
evidence shall summarize both refuted and confirmed flaws hypothesis
and identify TCB elements where the TCB implementation of the
penetration-resistance conditions is flawed.
EPA-4: Evidence of Formal Penetration Analysis
The developer shall provide evidence of penetration testing. The
penetration evidence shall identify all product documentation and
development evidence on which the search for flaws was based. The
penetration evidence shall describe the scenarios for exploiting each
potential flaw in the system and the penetration test conditions, data
(e.g., test set-up, function call parameters, and test outcomes),
coverage, and conclusions derived from each scenario. The penetration
evidence shall summarize both refuted and confirmed flaws hypothesis
and identify TCB elements where the TCB implementation of the
penetration-resistance conditions is flawed. The penetration evidence
shall include the results of mechanically validating the
implementation of the penetration resistance conditions specified for
the TCB.
5.3.4.5 Rated Covert Channel Analysis Evidence Components
ECC-1: Evidence of Covert Storage Channel Analysis and Han- dling
The developer's documentation shall present the results of the
covert-storage-channel analysis and the trade-offs involved in
restricting these channels. All auditable events that may be used in
the exploitation of known covert storage channels shall be identified.
The developer shall provide the bandwidths of known
covert-storage-channels whose use is not detectable by the auditing
mechanism. The documentation of each identified storage channel shall
consist of the variable that can be viewed/altered by the channel and
the TCB interface functions that can alter or view that variable. The
measurements of each TCB function call used by covert-storage channels
must be documented and the bandwidth computation shall be included for
each channel. The measurement environment should be documented as
specified. Test documentation shall include results of testing the
effectiveness of the methods used to reduce covert-storage-channel
bandwidths.
ECC-2: Evidence of Covert Channel Analysis and Handling
The developer's documentation shall present the results of the covert
channel analysis and the trade-offs involved in restricting these
channels. All auditable events that may be used in the exploitation
of known covert channels shall be identified. The developer shall
provide the bandwidths of known covert channels whose use is not
detectable by the auditing mechanism. The documentation of each
identified covert channel shall consist of the variables, timing
sources, and the TCB interface functions that can be used to transmit
information. The measurements of each TCB function call used by covert
channels must be documented and the bandwidth computation shall be
included for each channel. The measurement environment should be
documented as specified. Test documentation shall include results of
testing the effectiveness of the methods used to reduce covert-channel
bandwidths.
5.3.4.6 Rated Product Support Evidence Components
EPS-1: Evidence of Basic Product Support
The developer shall provide evidence that describes the policies,
procedures, and plans established by the developer to satisfy the
Operational Support and Development Environment requirements of the
protection profile.
EPS-2: Evidence of Defined Product Support
The developer shall provide documentation that defines the policies,
procedures, plans, and tools established by the developer to satisfy
the Operational Support and Development Environment requirements of
the protection profile.
EPS-3: Evidence of Measured Product Support
The developer shall provide documentation that defines, explains, and
justifies the policies, procedures, plans, and tools established by
the developer to satisfy the Operational Support and Development
Environment requirements of the protection profile. The documentation
shall also explain how the developer periodically evaluates compliance
with the established procedures, policies, and plans.
5.4 Bibliographic Notes
TBD.
Chapter 6.
EVALUATION ASSURANCE REQUIREMENTS
Editor's Note: This chapter represents an initial attempt to
consolidate many different ideas regard- ing evaluations and
articulate a simple structure for levying requirements on the
evaluation process. The material is presented to stimulate the debate
and analysis regarding what should be required of product evaluations.
6.1 Overview
Product evaluation is the process of validating that an IT product,
and the context in which it is developed and supported, conforms to
the requirements of a protection profile. Since only the protection
functions and quality of the product mitigate against risk, the
consumer's understanding of residual risk in any system employing the
product is largely dependent upon a producer's claims and/or upon
product evaluation information. Quality, in this context, is focused
on appropriateness, correctness, and simplicity of design with respect
to functional requirements, and correctness, effectiveness, and
efficiency of implementation with respect to design. When this
information is provided by a source independent of the product's
producer, the consumer generally has a greater degree of confidence
regarding the degree of conformance claimed by the producer.
This chapter addresses the protection profile section for evaluation
assurance which contains requirements derived from the generic
components presented later in this chapter. These generic requirements
may be tailored with respect to the profile requirements for
protection functions and development assurance. Each protection
profile can be separately tailored for evaluation. Thus, all IT
products produced to conform to a particular protection profile will
be commonly evaluated at a level of assurance commensurate with the
profile's requirements for protection functions and development
assurance. This evaluation assurance level is agreed upon during
profile registration by the participants to the registration process
(e.g., producers, profile developers, evaluation authorities).
The evaluation assurance requirements contained in a protection
profile specify the minimum requirements that must be satisfied during
an evaluation process. This document adopts the philosophy that if a
protection function or development assurance requirement is placed on
a producer, then the satisfaction of such a requirement must be
evaluated. Incremental evaluation assurance is accomplished by
changing the scope and intensity of examination to make the evaluated
aspects of the product's TCB, its internals, its interfaces, and its
production processes increasingly visible.
Evaluation assurance requirements do not by themselves define a
particular approach to product evaluation. There are conceivably many
different approaches to product evaluation to provide varying levels
of assurance. Any approach is defined by both evaluation methods and
the business process that incorporates those methods. Since the
business process is one that should remain flexible, the requirements
specified in this document are not intended to completely define a
specific process. Rather, they articulate requirements on methods that
can be used with a variety of business processes.The specific process
is largely the result of business decisions made by an evaluation
authority, often in conjunction with the producer and/or consumer,
regarding the most appropriate and cost-effective manner to accomplish
the evaluation assurance goals within the available resources.
This chapter is divided into four sections. The remainder of this
section groups the evaluation assurance components of a TCB into three
classes and describes the types of components in each class. The
second section presents a description of each type of evaluation
assurance component in terms of the functional and development
assurance requirements these components are intended to verify. The
third section presents the rated evaluation assurance components. The
last section includes a bibliography of useful literature references.
Classes of Evaluation Assurance: The product evaluation components
address three classes of evaluation methods (i.e., testing, review,
and analysis) and establish generic evaluation requirements based on
those methods. Test analysis and independent testing were grouped due
to the similarity of their requirements. The product evaluation
components are depicted in Figure 6.
Testing. This class of components defines two evaluation assurance
components: (1) test analysis components, and (2) independent testing
components. These two components determine whether the product's TCB
meets the functional protection requirements as defined in the
functional requirements section of the protection profile. These
components also assess whether activities required for TCB property
definition and TCB testing & analysis (both found in the development
process section of development assurance component section of the
protection profile) verification have been accomplished. These
components further assess whether these activities have been
documented in accordance with the development evidence requirements of
the development assurance section of the profile.
Review. This class of components defines two evaluation assurance
components: (1) development environment components, and (2)
operational support components. These two components validate
compliance with the operational support and development support
aspects of the development assurance requirements section of the
protection profile.
Analysis. This class of components defines two evaluation assurance
components: (1) design analysis components and (2) implementation
analysis components. These two components validate compliance with the
TCB design and TCB implementation support aspects of the development
assurance requirements section of the protection profile.
6.2 Evaluation Assurance Components
Editor's Note: The components included in this sec- tion are provided
to serve as examples and are, in some cases, incomplete. Comments
regarding their structure and content are desired from all review-
ers. An effort was made to concentrate only on eval- uation
requirements and to exclude any process- oriented areas (though some
process-oriented impli- cations may remain). The requirement for
specifying these components is to make them generic (i.e., suitable
for a variety of evaluation processes) and to be able to place them in
context with the other profile requirements (i.e., evaluation
requirements should be commensurate with the functional require- ments
and development assurance requirements).
6.2.1 Testing
Evaluation testing requirements will apply in all protection profiles.
Testing of the product and its protection functions is a
responsibility of the producer. The producer may also have the product
beta-tested by independent sources. Evaluation testing includes (1)
the analysis of the appropriateness, coverage, consistency and
completeness of the beta-test site's test suite and/or the producer's
test suite, the data resulting from conducting these tests, and (2)
the independent application and analysis of testing by the evaluation
team. The evaluation process will be required to assess the producer's
testing results and may be required to independently perform some
level of testing of the product. An example of such an evaluation
testing requirement would be where the evaluation team must execute
the producer's functional tests and then re-execute them after any
discovered errors (either with the tests or the product) have been
corrected.
Evaluation testing may be as simple as a pass or fail conformance test
suite against which the products must be tested. For more
comprehensive functional testing, the evaluators may be required to
functionally test aspects of the product not covered by the producer's
testing. The product's TCB, with respect to its ability to resist
penetration, will also require a range of penetration analysis and
testing. Such testing begins with known generic flaws and proceeds to
hypotheses that are refuted or confirmed. Again, the evaluators may
analyze the product's tests and test results, rerun all or a selected
set of such tests, or develop additional tests not covered by other
testing. If covert channel handling methods are incorporated into a
product to limit bandwidth, the effectiveness of those methods in
reducing channel bandwidths must also be tested. In general, the more
robust and/or resilient the product's protection is expected to be,
the more significant the level of testing that should be performed.
6.2.1.1 Test Analysis Components
Test analysis establishes the testing analysis requirements needed to
determine whether the product meets the functional protection
requirements as defined in the protection profile. The producer will
always perform this functional testing. Functional testing is based
on the operational product, the TCB's functional properties, the
product's operational support guidance, and other producer's
documentation as defined by the development evidence requirements.
Functional test analysis is based on the achieved test results as
compared to the expected results derived from the development
evidence. Penetration test analysis is based on known generic
penetration flaws and a set of flaw hypotheses established for the
specific product implementation. Covert channel bandwidth testing is
based on the bandwidth prior to the application of covert channel
handling method and the bandwidth that results after such application.
6.2.1.2 Independent Testing Components
Independent testing establishes the testing requirements performed by
a testing agent not associated with the producer. These requirements
determine whether the product's TCB meets the functional protection
requirements as defined in the protection profile. Testing is based on
the operational product, the TCB's functional properties, the
product's operational support guidance, and other producer's
documentation as defined by the development evidence requirements.
6.2.2 Evaluation Review Requirements
This aspect of evaluation assurance addresses validating compliance
with the development assurance requirements. Evaluation reviews
simply check for a process, discipline, or form of documentation by
examining evidence that validates presence or absence. Two aspects of
compliance are reviewed; (1) compliance with development environment
requirements and (2) compliance with operational support requirements.
6.2.2.1 Development Environment Review
The development environment review establishes the level of review
required to determine whether the product meets the requirements as
defined in the protection profile's development assurance subsections
for development environment. This includes the components life-cycle
definition, configuration management, and trusted distribution. An
example of such review would be configuration management audits
performed by the evaluation team to ensure that a configuration
management plan is being properly applied. At a certain level, the
evaluation team must conduct a configuration audit of all the
software, firmware, and hardware required to be kept under
configuration control according to the (approved) configuration
management plan. Similar requirements would apply to trusted
distribution and life cycle management.
6.2.2.2 Operational Support Review
The operational support review establishes the level of review
required to determine whether the product meets the requirements as
defined in the protection profile's development assurance subsections
for operational support. This includes the components for user and
administrative guidance, flaw discovery, tracking, and repair
procedures, and trusted generation.
6.2.3 Evaluation Analysis Requirements
This aspect of evaluation assurance addresses validating compliance
with two aspects of the development assurance requirements. Analysis
requirements are established to determine whether the product meets
the development assurance requirements. The analysis is based on the
producer's documentation, as defined by the development evidence
requirements. The two aspects analyzed are: (1) compliance with TCB
design requirements and (2) compliance with TCB implementation support
requirements.
6.2.3.1 Design Analysis
Design analysis requirements specify the objectives for evaluating a
product from a design perspective (i.e., without examination of the
product implementation). These requirements also address the adequacy
of required design documentation. A design analysis may range from a
relatively simple functional overview (e.g., a black-box perspective
of the TCB) to a detailed analysis of internal design details,
modularity, layering, etc. The level of evaluation analysis required
for producer-supplied documentation will be commensurate with the
product's design requirements as set forth in the protection profile's
development assurance section.
6.2.3.2 Implementation Analysis
Implementation analysis requirements address areas such as code
analysis. An example of such analysis is a requirement wherein the
evaluation team must examine at least 50% of the TCB's code to
ascertain whether the TCB meets the modularity requirements. The
selected code must be a representative set of the TCB and (as
appropriate) include samples of code from several different
programmers.
6.3 Rated Evaluation Assurance Components
6.3.1 Rated Test Analysis Components
This component establishes the testing analysis requirements to
determine whether the product meets the functional protection
requirements as defined in the protection profile. This component is
required for all evaluations as it assumes that the producer will
always perform functional testing.
TA-1: Elementary Test Analysis
The evaluator shall assess whether the producer has performed the
activities defined in the development assurance requirements of the
protection profile for functional testing and whether the producer has
documented these activities as defined in the development evidence
requirements of the protection profile. The evaluator shall analyze
the results of the producer's testing activities for completeness of
coverage and consistency of results. The evaluator shall determine
whether the product's protection properties, as described in the
product documentation have been tested. The evaluator shall assess
testing results to determine whether the product's TCB works as
claimed.
TA-2: Enhanced Test Analysis
The evaluator shall assess whether the producer has performed the
activities defined in the development assurance requirements of the
protection profile for functional testing and penetration analysis,
and whether the producer has documented these activities as defined in
the development evidence requirements of the protection profile. The
evaluator shall analyze the results of the producer's testing
activities for completeness of coverage and consistency of results,
and general correctness (e.g., defect trend from regression testing).
This analysis shall examine the testability of requirements, the
adequacy of the tests to measure the required properties, the
deviation of the actual results obtained from the expected results,
and a general interpretation of what the testing results mean. The
evaluator shall determine whether the product's protection properties,
as described in the product documentation, and all relevant known
penetration flaws have been tested. The evaluator shall assess testing
results to determine whether the product's TCB works as claimed, and
whether there are any remaining obvious ways (i.e., ways that are
known, or that are readily apparent or easily discovered in product
documentation) for an unauthorized user to bypass the policy
implemented by the TCB or otherwise defeat the product's TCB.
TA-3: Extended Test Analysis
The evaluator shall assess whether the producer has performed the
activities defined in the development assurance requirements of the
protection profile for functional testing and penetration analysis,
and whether the producer has documented these activities as defined in
the development evidence requirements of the protection profile. The
evaluator shall analyze the results of the producer's testing
activities for completeness of coverage and consistency of results,
and general correctness (e.g., defect trend from regression testing).
This analysis shall examine the testability of requirements, the
adequacy of the tests to measure the required properties, the
deviation of the actual results obtained from the expected results,
and a general interpretation of what the testing results mean. The
evaluator shall determine whether the product's protection properties,
as defined at the TCB interface (i.e., by the DIS), and all relevant
known penetration flaws have been tested. The evaluator shall
independently develop, test, and document additional flaw hypotheses.
The evaluator shall assess testing results to determine whether the
product's TCB works as claimed, that the TCB's implementation is
consistent with the DIS, and whether there are any obvious ways (i.e.,
ways that are known, or that are readily apparent or easily discovered
in product documentation) for an unauthorized user to bypass the
policy implemented by theTCB or otherwise defeat the product's TCB,
and whether all discovered TCB flaws have been corrected and no new
TCB flaws introduced. The evaluator shall determine whether the
product is relatively resistant to penetrations.
TA-4: Comprehensive Test Analysis
The evaluator shall assess whether the producer has performed the
activities defined in the development assurance requirements of the
protection profile for functional testing and penetration analysis,
and whether the producer has documented these activities as defined in
the development evidence requirements of the protection profile. The
evaluator shall analyze the results of the producer's testing
activities for completeness of coverage and consistency of results,
and general correctness (e.g., defect trend from regression testing).
This analysis shall examine the testability of requirements, the
adequacy of the tests to measure the required properties, the
deviation of the actual results obtained from the expected results.
The analysis shall extend to trace all defects identified, corrected,
and retested. The analysis shall include an assessment of test
coverage and completeness, and defect frequency. The results of
testing shall be interpreted in terms that express product performance
and protection adequacy. The evaluator shall determine whether the
product's protection properties, as defined for all
protection-relevant modules of the TCB, and all relevant known
penetration flaws have been tested. The evaluator shall independently
develop, test, and document additional flaw hypotheses. The evaluator
shall assess testing results to determine whether the product's TCB
works as claimed, that the TCB's implementation is consistent with the
DIS, and whether there are any obvious ways (i.e., ways that are
known, or that are readily apparent or easily discovered in product
documentation) for an unauthorized user to bypass the policy
implemented by theTCB or otherwise defeat the product's TCB, and
whether all discovered TCB flaws have been corrected and no new TCB
flaws introduced. No design flaws and no more than a few correctable
implementation flaws may be found during testing and there shall be
reasonable confidence that few remain. If covert channel handling
methods have been implemented, the testing results shall show that the
methods used to reduce covert channel bandwidths have been effective
for all evaluated configurations. The evaluator shall determine
whether the product is relatively resistant to penetrations.
TA-5: Formal Test Analysis
The evaluator shall assess whether the producer has performed the
activities defined in the development assurance requirements of the
protection profile for functional testing and penetration analysis,
and whether the producer has documented these activities as defined in
the development evidence requirements of the protection profile. The
evaluator shall analyze the results of the producer's testing
activities for completeness of coverage and consistency of results,
and general correctness (e.g., defect trend from regression testing).
This analysis shall examine the testability of requirements, use of
the FIS for test derivation, the adequacy of the tests to measure the
required properties, the deviation of the actual results obtained from
the expected results. The analysis shall extend to trace all defects
identified, corrected, and retested. The analysis shall include an
assessment of test coverage and completeness, and defect frequency.
The results of testing shall be interpreted in terms that express
product performance and protection adequacy. The evaluator shall
determine whether the product's protection properties, as defined for
the entire TCB, and all relevant known penetration flaws have been
tested. The evaluator shall independently develop, test, and document
additional flaw hypotheses. The evaluator shall assess testing results
to determine whether the product's TCB works as claimed, that the
TCB's implementation is consistent with the FIS, and whether there are
any obvious ways (i.e., ways that are known, or that are readily
apparent or easily discovered in product documentation) for an
unauthorized user to bypass the policy implemented by theTCB or
otherwise defeat the product's TCB, and whether all discovered TCB
flaws have been corrected and no new TCB flaws introduced. No design
flaws and no more than a few correctable implementation flaws may be
found during testing and there shall be reasonable confidence that few
remain. If covert channel handling methods have been implemented, the
testing results shall show that the methods used to reduce covert
channel bandwidths have been effective for all evaluated
configurations. The evaluator shall determine whether the product is
completely resistant to penetrations.
6.3.2 Rated Independent Testing Components
This component establishes the independent testing requirements to
determine whether the product's TCB meets the functional protection
requirements as defined in the protection profile.
IT-1: Elementary Independent Testing
A tester, independent of the producer or evaluator, shall perform
functional and elementary penetration testing. This testing shall be
based on the product's user and administrative documentation, and on
relevant known penetration flaws. Satisfactory completion consists of
demonstrating that all user-visible security enforcing functions and
security-relevant functions work as described in the product's user
and administrative documentation and that no discrepancies exist
between the documentation and the product. Test results of the
producer shall be confirmed by the results of independent testing.
The evaluator may selectively reconfirm any test result.
If the independent testing is performed at beta- test sites, the
producer shall supply the beta- test plan and the test results. The
evaluator shall review the scope and depth of beta testing with
respect to the required protection functionality, and shall verify
independence of both the test sites and the producer's and beta- test
user's test results. The evaluator shall confirm that the test
environment of the beta-test site(s) adequately represents the
environment specified in the protection profile.
IT-2: Enhanced Independent Testing
The evaluator shall independently perform functional and elementary
penetration testing to confirm test results. This testing may be
selective and shall be based on (1) the results of other independent
and/or producer testing, (2) the TCB's DIS, (3) other product design
and implementation documentation, (4) the product's user and
administrative documentation, and (5) relevant known penetration
flaws. Satisfactory completion consists of demonstrating that all TCB
functions work as described in the product's relevant documentation,
that test results are consistent, and that no discrepancies exist
between the documentation and the product.
If the independent testing is performed at beta- test sites, the
producer shall supply the beta- test plan and the test results. The
evaluator shall review the scope and depth of beta testing with
respect to the required protection functionality, and shall verify
independence of both the test sites and the producer's and beta- test
user's test results. The evaluator shall also confirm that the test
environment of the beta-test site(s) adequately represents the
environment specified in the protection profile.
IT-3: Comprehensive Independent Testing.
The evaluator shall independently perform functional and elementary
penetration testing to confirm test results. This testing may be
selective and shall be based on (1) the results of other independent
and/or producer testing, (2) the TCB's DIS, (3) other product design
and implementation documentation, (4) the product's user and
administrative documentation, (5) relevant known penetration flaws,
and (6) evaluator-developed TCB penetration flaw hypotheses and
corresponding tests that attempt to exploit the hypothesized flaws.
Satisfactory completion consists of demonstrating that all TCB
functions work as described in the product's relevant documentation,
that test results are consistent, and that no discrepancies exist
between the documentation and the product. Satisfactory penetration
test completion shall be determined by the subjective judgement (which
may be supported algorithmically) of the evaluator. Test duration
agreements may further constrain this judgement. Categorization of an
actual penetration flaw shall be based on the reproducibility of that
flaw. Flaws that are discovered, but are not reproducible shall remain
categorized as potential penetration flaws. All actual penetration
flaws must be corrected and retested.
The evaluator shall provide a penetration test plan document that
describes the additional evaluator-developed flaw hypotheses and
associated tests. The evaluator shall execute these tests and shall
report any discovered flaws to the producer as part of the testing
results. At the conclusion of penetration testing, the evaluator shall
provide copies of this penetration test plan and its test results to
the producer. The producer shall ensure that this test plan and its
test results are incorporated into the rest of the product's testing
documentation and that such documentation is available for further
analysis throughout the life of the product.
If the product has incorporated covert channel handling, the evaluator
shall test for covert channel bandwidth reductions to determine the
effectiveness of handling method(s) in reducing the bandwidths of
identified covert channels for all evaluated configurations.
If the independent testing is performed at beta- test sites, the
producer shall supply the beta- test plan and the test results. The
evaluator shall review the scope and depth of beta testing with
respect to the required protection functionality, and shall verify
independence of both the test sites and the producer's and beta- test
user's test results. The evaluator shall also confirm that the test
environment of the beta-test site(s) adequately represents the
environment specified in the protection profile.
IT-4: Formal Independent Testing.
The evaluator shall independently perform functional and elementary
penetration testing to confirm test results. This testing shall be
based on (1) the results of producer or other independent testing, (2)
the TCB's FIS, (3) the product's design and implementation
documentation, (4) the product's user and administrative
documentation, (5) relevant known penetration flaws, and (6)
evaluator-developed TCB penetration flaw hypotheses and corresponding
tests that attempt to exploit the hypothesized flaws. Satisfactory
completion consists of demonstrating that all TCB functions work as
described in the product's relevant documentation, that the TCB
functions are consistent with the FIS, that test results are
consistent, and that no discrepancies exist between the documentation
and the product. Satisfactory penetration test completion shall be
determined by the subjective judgement of the evaluator (which may be
supported algorithmically). Test duration agreements may further
constrain this judgement. Categorization of an actual penetration flaw
shall be based on the reproducibility of that flaw. Flaws that are
discovered, but are not reproducible shall remain categorized as
potential penetration flaws. All actual penetration flaws must be
corrected and retested.
The evaluator shall provide a penetration test plan document that
describes the additional evaluator-developed flaw hypotheses and
associated tests. The evaluator shall execute these tests and shall
report any discovered flaws to the producer as part of the testing
results. At the conclusion of penetration testing, the evaluator shall
provide copies of this penetration test plan and its test results to
the producer. The producer shall ensure that this test plan and its
test results are incorporated into the rest of the product's testing
documentation and that such documentation is available for further
analysis throughout the life of the product.
If the product has incorporated covert channel handling, the evaluator
shall test for covert channel bandwidth reductions to determine the
effectiveness of handling method(s) in reducing the bandwidths of
identified covert channels.
If the independent testing is performed at beta- test sites, the
producer shall supply the beta- test plan and the test results. The
evaluator shall review the scope and depth of beta testing with
respect to the required protection functionality, and shall verify
independence of both the test sites and the producer's and beta- test
user's test results. The evaluator shall also confirm that the test
environment of the beta-test site(s) adequately represents the
environment specified in the protection profile.
6.3.3 Rated Development Environment Review Components
This component establishes the level of review required to determine
whether the product meets the requirements as defined in the
protection profile's development assurance subsections for development
environment including life-cycle definition and configuration
management, and trusted distribution.
DER-1: Elementary Development Environment Review
The evaluator shall review the producer's development and maintenance
process description documentation to determine the degree of
discipline enforced upon and within the process, and to determine the
protection characteristics associated with the product's development
and maintenance. The results of this review shall establish, for the
evaluator, the producer's development environment, its policies, and
the degree of enforcement maintained during development execution.
DER-2: Enhanced Development Environment Review
The evaluator shall review the producer's development and maintenance
process description documentation and shall conduct a random audit of
the producer's processes using the evidence generated by each process
to determine the degree of discipline enforced upon and within the
process, and to determine the protection characteristics associated
with the product's development and maintenance. The results of this
review shall establish, for the evaluator, the producer's development
environment, its policies, and the degree of enforcement maintained
during development execution. The results of this review shall also
confirm the producer's general conformance with relevant development
environment requirements.
DER-3: Comprehensive Development Environment Review
The evaluator shall review the producer's development and maintenance
process description documentation and shall conduct a complete audit
of the producer's processes using the evidence generated by each
process to determine the degree of discipline enforced upon and within
the process, and to determine the protection characteristics
associated with the product's development and maintenance. The results
of this review shall establish, for the evaluator, the producer's
development environment, its policies, and the degree of enforcement
maintained during development execution. The review shall also confirm
the producer's complete conformance with all relevant development
environment requirements.
6.3.4 Rated Operational Support Review Components
This component establishes the level of review required to determine
whether the product meets the requirements as defined in the
protection profile's development assurance subsections for operational
support including user and administrative guidance, flaw discovery,
tracking, and repair procedures, and trusted generation.
OSR-1 Elementary Operational Support Review
The evaluator shall review all documentation focused on the activities
of product use (e.g., Users Manuals) and product administration
including installation, operation, maintenance, and trusted recovery
(e.g., Trusted Facility Management Manuals). This review shall assess
the clarity of presentation, difficulty in locating topics of
interest, ease of understanding, and completeness of coverage. The
need for separate manuals dedicated to protection-relevant aspects of
the product should be assessed for effectiveness.
This component should also address flaw remediation and trusted
generation. [[TBD.]]
OSR-2 Enhanced Operational Support Review
The evaluator shall review all documentation focused on the activities
of product use (e.g., Users Manuals) and product administration
including installation, operation, maintenance, and trusted recovery
(e.g., Trusted Facility Management Manuals). This review shall assess
the clarity of presentation, difficulty in locating topics of
interest, ease of understanding, and completeness of coverage. The
need for separate manuals dedicated to protection-relevant aspects of
the product should be assessed for effectiveness. The evaluator shall
randomly select a sample of the documented protection-relevant
features and procedures and execute them to determine if their
descriptions are accurate and correct.
This component should also address flaw remediation and trusted
generation. [[TBD.]]
OSR-3 Comprehensive Operational Support Review
The evaluator shall review all documentation focused on the activities
of product use (e.g., Users Manuals) and product administration
including installation, operation, maintenance, and trusted recovery
(e.g., Trusted Facility Management manuals. This review shall assess
the clarity of presentation, difficulty in locating topics of
interest, ease of understanding, and completeness of coverage. The
need for separate manuals dedicated to protection-relevant aspects of
the product should be assessed for effectiveness. The evaluator shall
execute all documented protection-relevant features and procedures to
determine if their descriptions are accurate and correct.
This component should also address flaw remediation and trusted
generation. [[To be written.]]
6.3.5 Rated Design Analysis Components
This component establishes the analysis requirements to determine
whether the product meets the design requirements as defined in the
development process assurance section of the protection profile,
including the TCB property definition and TCB design requirements. The
analysis is based on the producer's documentation, as defined by the
development evidence requirements.
DA-1: Elementary Design Analysis
The evaluator shall determine whether the producer has performed the
activities defined in the development process assurance requirements
of the protection profile for TCB property definition and TCB design.
The evaluator shall determine whether the producer has documented
these activities as defined in the development evidence requirements
of the protection profile. The evaluator shall analyze the results of
the producer's activities for completeness and consistency of design
with respect to requirements.
DA-2: Enhanced Design Analysis
The evaluator shall determine whether the producer has performed the
activities defined in the development process assurance requirements
of the protection profile for TCB property definition and TCB design.
The evaluator shall determine whether the producer has documented
these activities as defined in the development evidence requirements
of the protection profile. The evaluator shall analyze the results of
the producer's activities for completeness, consistency, and
correctness of design with respect to requirements.
DA-3: Comprehensive Design Analysis
The evaluator shall determine whether the producer has performed the
activities defined in the development process assurance requirements
of the protection profile for TCB property definition and TCB design.
The evaluator shall determine whether the producer has documented
these activities as defined in the development evidence requirements
of the protection profile. The evaluator shall analyze, with the help
of formal methods and appropriate automated tools, the results of the
producer's activities for completeness, consistency, and correctness
of design with respect to requirements (e.g., validating the formal
verification of the design).
6.3.6 Rated Implementation Analysis Components
This component establishes the implementation analysis required to
determine whether the product meets the requirements as defined in the
TCB implementation requirements in a protection profile's development
assurance section. The analysis is based on the implemented code and
on the producer's documentation, as defined by the development
evidence requirements.
CI-1: Elementary Implementation Analysis
The evaluator shall conduct a code inspection on a small sample of
randomly selected product code. The assessment shall focus on clarity
of the coding style, adherence to coding standards, coding
documentation, and on possible software defects that may be present
with respect to the product's informal design. The inspection shall be
performed to obtain only a sample of possible software defects, not to
capture all such possible defects. The evaluator shall report all
discovered defects to the producer; the assessment shall report the
number of defects found per line of code inspected from the random
sample size. Use of producer-provided code inspection results can
supplement this sample inspection. All trapdoors built into the
product for maintenance purposes shall be identified by the producer
and shown to be protected by the product.
CI-2: Enhanced Implementation Analysis
The evaluator shall conduct a code inspection on a moderate sample of
randomly selected product code. The assessment shall focus on clarity
of the coding style, adherence to coding standards, coding
documentation, and on possible software defects that may be present
with respect to the product's informal design and model. The
inspection shall be performed to obtain only a sample of possible
software defects, not to capture all such possible defects. The
evaluator shall report all discovered defects to the producer; the
assessment shall report the number of defects found per line of code
inspected from the random sample size. Use of producer-provided code
inspection results can supplement this sample inspection. All
trapdoors built into the product for maintenance purposes shall be
identified by the producer and shown to be protected by the product.
CI-3: Comprehensive Implementation Analysis
The evaluator shall conduct an inspection on a moderate sample of
randomly selected product code. The assessment shall focus on the
clarity of the coding style, adherence to coding standards, coding
documentation, and on possible software defects that may be present
with respect to the product's formal design and model. The inspection
shall be performed to obtain only a sample of possible software
defects, not to capture all such possible defects. The evaluator shall
report all discovered defects to the producer; the assessment shall
report the number of defects found per line of code inspected from the
random sample size. Use of producer-provided code inspection results
can supplement this inspection. All trapdoors built into the product
for maintenance purposes shall be identified by the producer and shown
to be protected by the product. The producer shall correct all
discovered defects and the corrected software reinspected. A rigorous
analysis of the implementation's correspondence to the verified design
shall be performed by the evaluator to validate correctness. Such
analysis may be supported by appropriate automated tools.
6.4 Bibliographic Notes
TBD.
Chapter 7.
CONSTRUCTION OF PROTECTION PROFILES
7.1 Overview
The functional and assurance components and their ratings defined in
previous chapters provide the basic building blocks for the definition
of protection profiles. The definition of a protection profile
consists of assembling different functional and assurance components
into a consistent and coherent set that satisfies specific security
goals of the anticipated environments of product use. The assembled
components and their requirements are generally intended to counter
threats, eliminate vulnerabilities, support security standards, and
satisfy regulatory requirements defined in the anticipated
environments of use.
During profile construction, environment-specific requirements are
used to select and synthesize the functional and the assurance
components for IT product development (see Chapter 3). It should be
noted that not all environment- specific requirements are relevant to
the selection of the functional and assurance components. For example,
some environment-specific requirements may address only problems of
organization management and IT product use that have no direct impact
on IT product requirements. The environment- specific requirements
referred to in this section are those that help select IT product
component requirements for profile inclusion.
This chapter describes the concerns that arise, and the steps that
must be taken, in synthesizing profile functional and assurance
components. It also illustrates the selection of these components by
several examples. The chapter is divided into three sections. The
first section describes several steps for synthesizing profile
components. The second section addresses the notion of dependency
analysis for profile components and component requirements. The third
section contains a bibliography of useful literature references
related to dependency analysis.
7.2 Synthesis of Profile Components
Different Levels of Abstract Requirements. The environment- specific
requirements are used in selecting the functional and assurance
components. These requirements can be stated at a level of abstraction
that is higher than, lower than, or similar to that of the functional
and assurance components. This variance in levels of abstraction
exists because these requirements can be expressed in an unrestricted
form. The requirements may be more abstract because they may reflect
high-level security control objectives, organizational policies,
regulations and directives. For example, environment-specific
requirements may state that the computing facilities must reflect the
separation of roles defined within an organization, or must reflect a
document classification policy mandated by government directives.
Similarly, the requirements may state that the control of access to
documents processed within a computing facility must conform with a
particular document processing policy (e.g., ORGCON).
Environment-specific requirements may be less abstract than those used
in the functional and assurance components. Some may reflect the need
to support a specific security standard or guideline (e.g., password
guideline) while others may require a set of specific features and
assurances deemed necessary in the environments of IT product use. For
example, commercial security environments may require a specific set
of: password complexity rules, location- and time-based access control
rules, and security management rules. Other environments may mandate
the use of a specific subject and object labeling policy, may require
specific import or export policies for labeled objects, may mandate
the use of specific forms of acceptance testing and test coverage, or
may mandate a specific form of configuration management and trusted
distribution.
Environment-specific requirements may have the same level of
abstraction as that of the functional and assurance components because
they may be derived from requirements of existing product standards.
For example, some environment-specific requirements may be expressed
by the requirements of the Trusted Computer System Evaluation Criteria
(TCSEC) classes B2, B3, or A1, for high-assurance defense
environments.
Different Requirement Classifications. The environment- specific
requirements may be partitioned into components in a different manner
than that used in the partitioning of the product generic
requirements. Since the profile requirements ultimately drive the
profile component selection, the different component partitionings
must be resolved to ensure that the profile addresses all
environment-specific requirements. The partitioning of generic product
requirements into components and the rating of those components imply
that, when interpreted at the product- requirement level, the
environment-specific requirements must be expressed in terms of these
components and their levels. For example, the environment-specific
requirement class of "reliability of service" may contain specific
requirements of limited service degradation, control of resource
consumption, automated crash recovery based on checkpoint restart, and
periodic back-up and restore operations. In terms of the product
component requirements, the "reliability of service" requirement will
be covered by the availability, trusted recovery, and security
management components.
The partitioning of environment-specific requirements into product
component requirements must take into account the rating of the
component requirements because certain specific requirements may, in
fact, be covered by individual requirements of multiple levels. For
example, environment- specific requirements of access control may
include all component level AC-2 (basic access control) and location-
dependent authorization, which is a requirement included in component
level AC-4 (fine-grain access control). Consequently, if component
level AC-3 (extended access control) is selected, the
environment-specific requirement would not be satisfied by the
resulting profile, and if level AC-4 is selected, the resulting
profile becomes overspecified because the requirements of AC-4 are
unnecessarily included. The resolution of this problem is discussed
in the next section.
The question of how the environment-specific requirements can be used
to construct functional and assurance requirements for inclusion in a
profile arises naturally, given the unconstrained level of abstraction
in the environment- requirement definition. A key step in profile
synthesis is that of selecting the functional and assurance
components. The selection process is informal and, for this reason
must be carefully justified in constructing and accepting a profile.
When the level of the environment-specific requirements is close to
that of the component requirements, two selection steps, assignment
and refinement, are used.
7.2.1 Assignment
The assignment of environment-specific requirements to generic
component requirements is performed when a component requirement
corresponds to an environment-specific requirement. The correspondence
is determined by analyzing the intent and motivation for both the
environment-specific requirement and the product component
requirement. A match of the motivation and intent for these
requirements triggers the selection of the component requirement.
An assignment of environment-specific requirements to a component
requirement also takes place when a component requirement is given a
specific meaning. That is, a generic requirement of a component, which
may require the definition of a rule, condition, or constant, becomes
specific.
Example 1: Assignment of specific constants
In the identification and authentication component of the Commercial
Security Protection Profile CS-2, the following italicized
requirements assign specific default constants to successive
unsuccessful login attempts and to the default of the required delay:
The TCB shall end the attempted login session if the user performs the
authentication procedure incorrectly for a number of successive times
(i.e., a threshold) specified by an authorized system administrator.
The default threshold shall be three times. When the threshold is
exceeded, the TCB shall send an alarm message to the system console
and/or to the administrator's terminal, log this event in the audit
trail, and delay the next login by an interval of time specified by
the authorized system administrator. The default time interval shall
be 60 seconds. The TCB shall pro- vide a protected mechanism to
disable the user identity or account when the threshold of succes-
sive, unsuccessful login attempts is violated more than a number of
times specified by the adminis- trator. By default, this mechanism
shall be dis- abled (as it may cause unauthorized denial of service).
Also, in the access control component of the Commercial Security
Protection Profile CS-2, the following italicized requirement
identifies a specific subject attribute (i.e., group identity) to
which access rights are assigned:
Object attributes shall include defined access rights (i.e., read,
write, execute) that can be assigned to subject attributes. The TCB
shall be able to assign object access rights to group identities.
Example 2: Assignment of specific authorization rules
In the access control component of the Commercial Security Protection
Profile CS-2, the following italicized requirement assigns specific
authorization rules for subject references to objects:
The TCB shall define and enforce authorization rules for the mediation
of subject references to objects. These rules shall be based on the
access control attributes of subjects and objects.
At a minimum, the authorization rules shall be defined as follows:
a. The access rights associated with a user identifier shall take
precedence over the access rights associated with any groups of which
that user identifier is a member.
b. When a user identifier can be an active member of multiple
groups simultaneously, or if the access rights associated with the
user identifier conflict with the access rights associated with any
group in which the user is a member, it shall be possible for a system
administrator to configure rules that combine the access rights to
make a final access control decision.
c. The TCB shall provide a protected mechanism to specify default
access rights for user identifiers not otherwise specified either
explicitly by a user identifier or implicitly by group membership.
Example 3: Assignment of specific conditions
In the access control component of the Commercial Security Protection
Profile CS-2, the following italicized requirement assigns specific
conditions to the rule for assignment and modification of access
control attributes for subjects and objects.
The effect of these rules shall be that access rights to an object by
users not already possessing access permission is assigned only by
authorized users.
Only the current owner or system administrators can modify access
control attributes of objects.
There should be a distinct access right to modify the contents of an
object's access control list (e.g., an "ownership" or "control"
right).
The component requirements are assigned a null environment- specific
requirement whenever an environment-specific requirement is not
assigned for a component. A null assignment implies that the component
is not included in a profile (unless another component, which is
required by another environment-specific requirement, depends upon
it).
Example 4: Null assignment
In the Commercial Security Protection Profiles (CS-1, CS-2, CS-3),
several assurance components were not selected for inclusion. The
modular decomposition component, TCB structuring support, and TCB
design disciplines were not selected because this profile does not
require assurances about the internal TCB structure.
When an environment-specific requirement is assigned, it is possible
that the component requirements used include some features that are
not explicitly selected (i.e., an exact match is not possible). In
this case, a do not care is assigned to the features and/or assurances
not selected.
Example 5: "Do not care" assignment
In Example 2, the assignment of the specific authorization rules
refers only to the selection of subject attributes for access
authorization and does not include any specification of the object
subset to which the authorization applies. This implies that a "do not
care" is assigned to the generic requirement of identifying the
authorization scope in the access control component. Similarly, a "do
not care" assignment is implicitly made in Example 3. Although
specific conditions are assigned to the rule for modification of
access control attributes, a specific condition or rule was not
assigned for attribute modification during object import and/ or
export operations.
7.2.2 Refinement
The refinement of a component requirement is necessary when the
environment-specific requirements are less abstract (i.e., more
specific) than the component requirements. As a consequence, one or
more environment-specific requirements are added to a single component
requirement. This represents a refinement of a component requirement.
Note that the refinement of a component requirement differs from the
assignment of environment-specific requirements to components. For
example, a refinement of a component requirement may not assign any
specific meaning to a requirement rule, condition, or constant.
Instead, the refinement provides an elaboration of a generic component
requirement in a specific environment.
Example 6: Refinement of the trusted path component
In the Commercial Security Protection Profile CS-2, the following
italicized requirement refines the Trusted Path component TP-1
requirement:
The TCB shall support a trusted communication path between itself and
the user for initial identification and authentication. Communications
via this path shall be initiated exclusively by a user.
The TCB shall provide a protected mechanism by which a data
entry/display device may force a direct connection between the port to
which it is connected and the authentication mechanism.
Example 7: Refinement of the authorization rules
In the Commercial Security Protection Profile CS-2, the following
italicized requirement refines the requirement for authorization rule
definition and enforcement:
The TCB shall define and enforce authorization rules for the mediation
of subject references to objects. These rules shall be based on the
access control attributes of subjects and objects.
For each object, the authorization rules of the TCB shall be based on
a protected mechanism to specify a list of user identifiers or groups
with their spe- cific access rights to that object (i.e., an access
control list).
The assignment and refinement rules become necessary whenever the
level of abstraction of the environment-specific requirements differs
from that of the generic product components. However, when the
partitioning or classification of environment specific requirements
differs from that of the functional and assurance components, two
additional selection steps, decomposition and level-selection, are
used.
7.2.3 Decomposition
The decomposition of a specific requirement becomes necessary when
that requirement must be assigned to multiple components of the
generic product requirements during the interpretation process.
Examples of decomposition are provided by both the specific
requirements of the commercial domain illustrated in the NIST Minimum
Security Functionality Requirements (MSFR) release 1.1 and by the
specific requirements of labeled protection found in the TCSEC.
Example 8: MSFR requirement decomposition into generic components
1. MSFR System Integrity Requirement -> Functional Components (AC, P,
AD, SC, SM)
Requirement Component (paragraph)
Separate process and address spaces P-1 (1) Verification of installed
software using SC-3
checksums & digital signatures Restrict use of supervisory states P-1
(1) Audit use of operator consoles AD-2 (2) TCB software modification
restricted to SM-1 (4)
administrative users System maintenance limited to SM-1 (4,5)
administrative users Validate correct operation of hardware SC-1
& firmware elements
2. Data Integrity Requirement -> Functional Components (AC, SC, SM,
ESU)
Requirement Component (paragraph)
Record date & time object last modified AC-4 (3) Check file system and
storage medium SC-3
integrity Display of system parameters and flags SM-1 (2,3)
Directory/path search order ESU-2 (1)
3. Reliability of Service -> Function Components ((AR, AF), TR, SM)
Requirement Component (paragraph)
Degraded service operation AF (TDB) Controlled consumption of disk
space, AR-1
CPU usage Recovery after system failure TR-1 Data backup & restore
SM-1 (4) Checkpoint restarts TR-4 (2)
Example 9: Decomposition of labeled component requirements into
generic components
1. TCSEC Device Labeling Requirement (B2) -> Functional Components
(AC, SE)
Requirement Component
The TCB shall support the assignment of AC-2 (2), minimum and maximum
security levels to all attached physical devices.
These security levels shall be used by I&A-2 (2) the TCB to enforce
constraints imposed by the physical environments in which the devices
are located.
7.2.4 Level-Selection
The rating of functional and assurance components requires that
specific component levels be selected when the environment-specific
requirements are interpreted at the product level. However, an
environment-specific requirement may exceed the requirements of a
single level and may include individual requirements of higher levels.
Whenever this happens, the selection of the component level follows a
"low water mark" rule. That is, the selected level is the highest
complete level required, but is augmented by individual requirements
of higher levels. This leads to the development of new components from
existing requirements, and ensures that the rating criteria used for
the component levels does not impair flexibility in profile
construction. Provided that an environment-specific requirement leads
to the selection of at least one complete level (e.g., the low-water
mark), different individual requirements of a higher level of the same
component can be selected to augment the selected low-water- mark
level.
Example 10: Low-water-mark selection of component levels for MSFR
requirements
Access control requirements of the Commercial Security Protection
Profiles CS-2 and CS-3 were derived from the specific requirements of
the MSFR by using low-water-mark selection of levels.
CS-2: AC-2+: These rules shall, either by explicit user action or
by default, provide that objects are protected from unauthorized
access.
These rules shall allow authorized users to specify and control
sharing of objects by named individuals or defined groups of
individuals, or by both, and shall provide controls to limit
propagation of access rights, (i.e., these rules shall define the
distribution, revocation, and review of access control attributes).
The controls defined by these rules shall be capable of specifying for
each named object, a list of individuals and a list of groups of named
individuals, with their respective access rights to that object.
Furthermore, for each named object, it shall be possible to specify a
list of named individuals and a list of groups of named individuals
for which no access to the object is given [AC-4]. These controls
shall be capable of including or excluding access to the granularity
of a single user.
CS-3: AC-2+: If multiple access control policies are supported, the
access control attributes corresponding to each individual policy
shall be identified. The subject and object attributes shall
accurately reflect the sensitivity and/or integrity of the subject or
object. The subject's access control attributes also shall include
time and location attributes that can be assigned to authenticated
user identities [AC-4].
The TCB shall define and enforce authorization rules for the mediation
of subject references to objects. These rules shall be based on the
access control attributes of subjects and objects. These rules shall,
either by explicit user action or by default, provide that objects are
protected from unauthorized access. These rules shall include
time-of-access and location-of-access controls defined for subjects
and objects [AC-4].
The rating of the functional and assurance components can also cause
multiple levels of the same component to be selected when the
environment-specific requirements are interpreted at the product
level. Whenever this happens, the selection of the component level
follows a "high water mark" rule. That is, the selected level is the
maximum of all the levels separately selected from the same component.
Example 11: High-water-mark selection of component levels for TCSEC
requirements
The system architecture requirements of the TCSEC class B3 include the
following specific requirements:
TCSEC System Architecture Requirement (B3) --> Modular Decomposition
(MD)
Requirement Component
The TCB shall be structured into MD-2 well-defined modules
and Significant system engineering shall be MD-3 directed
towards minimizing the complexity of the TCB and excluding from the
TCB modules that are not protection-critical.
The TCB structuring into modules requires the selection of assurance
component MD-2. The minimization of the TCB complexity and the
exclusion of protection-irrelevant modules from the TCB lead to the
selection of the assurance component MD-3 because module exclusion
requires the analysis of the correctness dependencies between modules.
This is required to determine whether a protection-relevant module
does not depend directly or indirectly on a module deemed to be
protection-irrelevant and scheduled for removal from the TCB. Since
the modular decomposition level MD-3 includes the requirements of
level MD-2, level MD-3 is the high-water-mark level and thus it must
be selected.
The system architecture and design specification and verification
requirements of the TCSEC class A1 include the following specific
requirements:
TCSEC System Architecture Requirement (A1) - > Interface Definition
(IF-2)
TCSEC Design Specification Requirement (A1) - > Interface Definition
(IF-3)
Requirement Component
The user interface shall be completely IF-2 defined and all elements
identified.
A formal top-level specification (FTLS) IF-3 of the TCB shall be
maintained that accurately describes the TCB in terms of exceptions,
error messages, and effects.
Since the interface definition level IF-3 includes the requirements of
level IF-2, level IF-3 is the high-water-mark level and thus, it must
be selected.
Note that the decomposition and level-selection may require assignment
and refinement and vice-versa. For example, the "low water mark" level
selection, assignment, and refinement are illustrated by the
requirements of access-control attribute administration in component
AC-2+ of profiles CS-2 and CS-3.
7.3 Dependency Analysis
The analysis of the dependencies between functional and assurance
components must be performed during profile construction. Such
analysis helps (1) avoid inadequate, or incorrect, profile
specification, (2) avoid overspecification of a profile, (3) determine
the effect of profile changes (e.g., addition or removal of individual
components or component requirements), and (4) analyze the
compatibility of different protection profiles and harmonize different
sets of component requirements (see Appendix E). This section
illustrates and classifies functional and assurance dependencies.
Examples are provided to show the use of dependency analysis in
profile-compatibility analysis and profile-change analysis. This
section is intended to enable protection profile developers to define
consistent and coherent profiles that can be evaluated and used by
independent organizations. It is further intended to motivate the
analysis required when comparing different standards addressing
information protection in IT products or when ensuring the
preservation of previous investments (e.g., maintaining compatibility
with the TCSEC).
7.3.1 Dependency Classification
Dependencies among the components of a product appear (1) among the
functional components, (2) among assurance components, and (3) between
the functional components and assurance components. Dependencies may
also exist between the functional and assurance components and the
product definition and operation. These dependencies help enlarge the
application of a profile definition to widely-used products that might
otherwise be considered inadequate for a specific protection profile.
These dependencies can be analyzed in a similar manner as those of the
first three classes, as this class does not introduce new dependency
types. The role of classifying these dependencies is (1) to help
achieve consistency and coherent profile definition, and (2) to
decrease profile-definition susceptibility to inconsistent component
classification of a component either as function or as an assurance.
Dependencies are classified into several types that are reminiscent of
those that appear in the correctness analysis of large systems and
products. This classification helps identify the important
dependencies that are necessary to achieve the consistency and
coherence of a protection profile.
7.3.2 Dependencies Among Functional Components
Dependencies among functional components arise because the functions
that implement a component depend on functions implementing other
components, or because different functions implementing different
components must implement the same policy (properties) or
requirement(s), individually or together. Thus,a distinction is made
between the "uses" and "policy property" types of dependencies. There
exists a "uses" dependency between two functional components, A and B,
if the correctness of functions implementing A assumes the correctness
of functions implementing B. There exists a "policy property"
dependency between two functional components, A and B, if functions
implementing both A and B must implement, either individually or
together, a property or a condition required by the policy (e.g., the