NCSC-TG-028
Library
No. S-238,986
Version
1
FOREWORD
The
National Computer Security Center is publishing Assessing Controlled Access
Protection as
part of
the "Rainbow Series" of documents our Technical Guidelines Program
produces. In the
Rainbow Series, we discuss in detail the features of the
Department of Defense Trusted Computer
System Evaluation Criteria (DoD 5200.28-STD) and provide
guidance for meeting each
requirement. The National Computer Security Center,
through its Trusted Product Evaluation
Program, evaluates the security features of
commercially-produced computer systems. Together,
these programs ensure that organizations are capable of
protecting their important data with trusted
computer systems.
Assessing Controlled Access Protection explains the
controlled access protection requirements of
the Trusted Computer System Evaluation Criteria. The
guide's target audience is the technical
analysts tasked by the Department of Defense components
to determine whether a system meets
these requirements.
As the Director, National Computer Security Center, I
invite your recommendations for revision
to this technical guideline. We plan to review and update
this document periodically in response to
the needs of the community. Please address any proposals
for revision through appropriate
channels to:
National Computer Security Center
9800 Savage Road
Ft. George G. Meade, MD 20755-6000
Attention: Chief, Standards, Criteria, and Guidelines
Division
ACKNOWLEDGMENTS
The National Computer Security Center expresses
appreciation to Dr. Dixie B. Baker, of The
Aerospace Corporation, as the principal author of this
document, and Ms. Caralyn Crescenzi as
project manager.
We also thank the evaluators, vendors, and users in the
United States computer security community
who contributed their time and expertise to the review of
this document.
Executive Summary
Assessing Controlled Access Protection provides guidance
to the Department of Defense
components charged with ensuring that the automated
information systems (AISs) used for
processing sensitive or classified information provide at
least controlled access protection.
The objectives of this guideline and its supporting
documentation set are:
1. To provide a
methodology for performing a technical analysis to support the certification
of controlled access protection in AISs submitted for
accreditation;
2. To provide an
interim approach for achieving controlled access protection until a suitable
NSA-evaluated product is available; and
3. To clarify the
intent, security functionality, and level of assured protection that controlled
access protection provides.
The guidance provided in this document is targeted toward
multi-user AISs designed for DoD
operations in system-high security mode and in dedicated
mode, where directed by the DAA. This
guidance does not specifically address connectivity with
a local-area or wide-area network. Nor
does it address related areas such as physical security,
TEMPEST, communications security, or
administrative security (e.g., trusted distribution).
This guideline is written to serve as the synergist that
integrates and consolidates information
contained in the following documents into a unified
explanation of the requirements for and intent
of controlled access protection.
· A Guide to
Understanding Audit in Trusted Systems
· A Guide to
Understanding Configuration Management in Trusted Systems
· A Guide to
Understanding Design Documentation in Trusted Systems
· A Guide to
Understanding Discretionary Access Control in Trusted Systems
· A Guide to
Understanding Identification and Authentication in Trusted Systems
· A Guide to
Understanding Object Reuse in Trusted Systems
· A Guide to
Writing the Security Features User's Guide for Trusted Systems
· Guidelines for
Writing Trusted Facility Manuals
· Trusted
Product Evaluation Questionnaire
The National Computer Security Center (NCSC) publishes
and distributes these documents to
support the certification and accreditation of AISs
required to provide controlled access protection.
To request copies of these documents, contact the
National Technical Information Service (NTIS).
Contents
l BACKGROUND 1
1.1 NATIONAL
POLICY 1
1.2 SECURITY
ACCREDITATION 2
1.3 TRUSTED
PRODUCT EVALUATION 3
1.4 SCOPE AND
PURPOSE 5
2 CONTROLLED
ACCESS PROTECTION 9
3 ARCHITECTURAL
FOUNDATION 13
3.1 TRUSTED
COMPUTING BASE 13
3.2 ENFORCEMENT 17
3.3 DOMAIN SEPARATION 18
3.4 DEFINED SUBSET 20
3.5 RESOURCE
ISOLATION 20
4 PROTECTION
MECHANISMS 22
4.1 IDENTIFICATION
& AUTHENTICATION 22
4.2 DISCRETIONARY
ACCESS CONTROL 24
4.3 OBJECT REUSE 28
4.4 AUDIT 29
5 DOCUMENTATION
AND LIFE-CYCLE ASSURANCE 33
5.1 DESIGN
DOCUMENTATION 33
5.2 SYSTEM
INTEGRITY 34
5.3 CONFIGURATION
MANAGEMENT 35
5.4 TRUSTED
FACILITY MANUAL 37
5.5 SECURITY
FEATURES USER'S GUIDE 38
5.6 TESTING 39
6 TECHNICAL
ANALYSIS 41
6.1 SELECTION OF
ANALYSTS 41
6.2 TECHNICAL
ANALYSIS PROCESS 42
7 RISK
MANAGEMENT 53
7.1 PROTECTION
LIMITATIONS 54
7.2 IDENTIFIED
DEFICIENCIES 55
7.2.1 SYSTEM
ARCHITECTURE 55
7.2.2 IDENTIFICATION
AND AUTHENTICATION 56
7.2.3 DISCRETIONARY
ACCESS CONTROL 56
7.2.4 OBJECT REUSE 56
7.2.5 AUDIT 56
7.2.6 SYSTEM
INTEGRITY 57
8 ACRONYMS 63
9 GLOSSARY 65
List of Figures
1.1 National
Policy on Controlled Access Protection 1
1.2 DoDD 5200.28
Timetable for C2 2
3.1 Trust
Hierarchy in an AIS 13
3.2 Relationship
between System Engineering and Assurance 16
3.3 TCSEC C2
System Architecture Criterion 17
4.1 TCSEC C2
Identification and Authentication Criterion 23
4.2 TCSEC C2
Discretionary Access Control Criterion 24
4.3 ACL for File
georges_data 26
4.4 Output from
Directory Study 27
4.5 Unix Command
Sequence 27
4.6 TCSEC C2
Object Reuse Criterion 28
4.7 TCSEC C2 Audit
Criterion 30
5.1 TCSEC C2
Design Documentation Criterion 33
5.2 TCSEC C2
System Integrity Criterion 35
5.3 TCSEC C2
Trusted Facility Manual Criterion 37
5.4 TCSEC C2
Security Features User's Guide Criterion 38
5.5 TCSEC C2
System Testing Criterion 39
6.1 Controlled
Access Protection Technical Analysis Process 43
List of Tables
2.1 Security
Policy Control Objectives and Implementation Requirements 11
4.1 Object Reuse
Mechanisms 29
Chapter 1
BACKGROUND
1.1 NATIONAL
POLICY
In July of 1987, the Federal government issued the
National Policy on Controlled Access
Protection [36], establishing the policy for automated
information systems (AISs) that are accessed
by multiple users with different authorizations to the
information contained in the system. The
Policy, shown in Figure 1.1, mandates that these systems
provide automated controlled access
protection and that this minimal level of protection be
provided within five years of the Policy's
issuance. The Policy gives the Federal agencies
responsibility for ensuring that its provisions are
carried out.
All automated information systems that are accessed by
more than one user, when those users do
not have the same authorization to use all of the
classified or sensitive unclassified information
processed or maintained by the automated information
system, shall provide automated Controlled
Access Protection for all classified and sensitive
unclassified information. This minimum level of
protection shall be provided within five years of the
promulgation of this policy.
Figure 1.1: National Policy on Controlled Access Protection
The Department of Defense (DoD) carries the Policy
forward in Directive 5200.28, Security
Requirements for Automated Information Systems (AISs)
[38], which specifies requirements for
AISs that handle classified, sensitive unclassified, or
unclassified information. The Directive
provides a risk-assessment procedure, extracted from
CSC-STD-003-85 [11], which is used to
determine the minimum Trusted Computer System Evaluation
Criteria (TCSEC) [14] evaluation
class required for an AIS, based on the sensitivity of
the information stored in or processed by the
AIS and on the clearances of its users. For AISs that
process or handle classified and/or sensitive
unclassified information, and that, based upon the
prescribed risk-assessment procedure, require at
least controlled access protection, the Directive
mandates an implementation timetable of 1992, as
shown in Figure 1.2.
All AISs that process or handle classified and/or
sensitive unclassified information and that require
at least controlled access protection (i.e., class C2
security), based on the risk assessment procedure
described in enclosure 4, shall implement required
security features by 1992.
Figure 1.2: DoDD 5200.28 Timetable for C2
The National Security Agency (NSA) evaluates commercial
products designed to meet the TCSEC
requirements and lists them in its Evaluated Products
List (EPL) [34] maintained by the National
Computer Security Center (NCSC). The Directive tasks the
NSA to serve as a focal point for
technical matters relating to the use of trusted computer
products and to provide to the Department
of Defense (DoD) components, as requested, technical
assistance in evaluating and certifying
computer-based security features of AISs used in
operational environments. This guideline is
responsive to this tasking; its purpose is to provide the
DoD components technical guidance to
support the certification and accreditation of
operational systems.
1.2 SECURITY
ACCREDITATION
Prior to allowing an AIS to handle any classified or
sensitive information, a Designated Approving
Authority (DAA) must accredit it to operate in one of
three security modes: dedicated, system high,
or multilevel. In dedicated mode, all users have the
clearance or authorization and a need-to-know
for all data handled by the AIS. In system high mode, all
users have a security clearance or
authorization, but not necessarily a need-to-know, for
all data handled by the AIS. Multilevel mode
allows two or more classification levels to be processed
simultaneously within the same AIS when
not all users have a clearance or formal access approval
for all data handled by the AIS.
A program for conducting periodic review of the adequacy
of the safeguards for operational,
accredited AISs also must be established. [38] The DAA
should be involved in all phases of the
system acquisition, beginning with the development of the
security policy and operations concept,
and including the specification of the security
requirements, reviews conducted during the design
and development phases, and security testing, to ensure
that he or she understands the operational
needs, how system components work together, how the
system interfaces with other systems and
organizations, and the risks associated with the system.
The technical evaluation of an AIS's security features
and other safeguards, made in support of the
accreditation process, is called certification.
Certification establishes the extent to which a
particular AIS's design and implementation meet a set of
specified security requirements.
Accreditation is the DAA's formal declaration that an AIS
is approved to operate in a particular
security mode, using a prescribed set of safeguards.
Accreditation is the official management
authorization for operation of an AIS and is based on the
certification process as well as other
management considerations. The accreditation statement
affixes security responsibility with the
DAA and shows that due care has been taken for security.
[38] Although certification involves a
great deal more than the technical analysis described in
this document, the guidance contained
herein can provide a technical basis for the
certification portion of the accreditation process.
1.3 TRUSTED
PRODUCT EVALUATION
The DoD policy specified in DoDD 5200.28 states that:
Computer security features of commercially produced
products and Government-
developed or -derived products shall be evaluated (as
requested) for designation as trusted
computer products for inclusion on the Evaluated Products
List (EPL). Evaluated products
shall be designated as meeting security criteria
maintained by the National Computer
Security Center (NCSC) at NSA defined by the security
division, class, and feature (e.g.,
B, B1, access control) described in DoD 5200.28-STD.
The NCSC maintains the EPL and, using technical support
from NSA, evaluates, assigns ratings
to, and enters onto the EPL products designed and
developed in accordance with the TCSEC. NSA
maintains a cadre of trusted-product evaluators both from
within the agency and from Federally
Funded Research and Development Corporations (FFRDCs).
The trusted product evaluation
program (TPEP), described in detail in Trusted Product
Evaluations: A Guide for Vendors [41],
comprises the following five phases:
1. Proposal
Review. When a vendor requests that its product be evaluated for possible
inclusion on the EPL, NSA prescreens the proposed product
relative to its usefulness to
DoD components, its technical merit (through an intensive
Preliminary Technical Review),
and the vendor's commitment to the product.
2. Vendor
Assistance. If NSA decides that the product has potential merit, it signs a
Memorandum of Understanding (MOU) with the vendor.
Through this MOU, the vendor
agrees (among other things) to give NSA evaluators access
to the highly proprietary
hardware and software design documentation needed to
perform an evaluation. Once the
MOU is signed, NSA assigns a small evaluation team to
track the product through its
development and to provide assistance in the
interpretation and application of TCSEC
requirements for the targeted class. This team works
closely with the vendor throughout the
development of the product to help determine the targeted
division and class and to ensure
that the design and developmental approach are compliant
with the requirements of the
TCSEC for that class.
3. Design
Analysis. When development is complete, and all of the required documentation
is
nearing completion, the product enters Design Analysis.
During this phase, an expanded
evaluation team completes training (to the level of an
applications programmer, for systems
targeted for up to class B1, and to the level of a system
programmer, for systems targeted
for the higher classes). The team analyzes the product
relative to the TCSEC requirements
and writes a detailed Initial Product Assessment Report
(IPAR). For products targeted at
B2 and above, a preliminary architecture study is
conducted, and at Al, the team begins
examining the formal verification during this phase.
Information necessary for design
analysis is gained through thorough review of the
hardware and software design
documentation, examination of drafts of TCSEC-required
documentation (e.g., Security
Features Users' Guide, Trusted Facility Manual, test
plans and procedures), and
interactions with the vendor. Because both team members
and vendor personnel are likely
to be widely dispersed geographically, electronic
communications are relied upon heavily
for team and vendor communications. Once the analysis is
completed, the team presents
the IPAR to NSA's Technical Review Board (TRB), which
serves as one of the TPEP's
primary quality-control mechanisms. Based upon the IPAR
and the team's presentation, the
TRB provides to NSA management a recommendation as to
whether the product is ready
to begin the Evaluation Phase.
4. Evaluation.
This phase is the actual security evaluation of the product. During this phase,
the evaluation team completes the design analysis,
building upon the information contained
in the IPAR. Prior to beginning functional testing, the
team presents its assessment to the
TRB, with a request that the evaluation be allowed to
proceed to testing. The team then
conducts functional testing (all classes) and penetration
testing (class B2 and above),
examines the final versions of required documentation,
and completes the Final Evaluation
Report. At class B2 and above, a system architecture
study and covert channel analysis are
conducted, and at Al, the formal verification is
validated. At the end of this phase, the
evaluation team again appears before the TRB to present
its findings and to recommend a
final rating. Successful completion of this phase results
in placement of the vendor's
product on the EPL.
5. Rating
Maintenance. NSA's RAting Maintenance Phase (RAMP) provides a mechanism
for ensuring the continuing validity of a rating extended
to successive versions of the rated
product.
The EPL, published semi-annually as part of the
Information Systems Security Products and
Services Catalogue and updated quarterly, provides system
acquisition agents a good selection of
C2-rated products from which to select platforms for
their applications. In addition, the EPL
contains a number of products that have been rated B1 and
above; all of these contain acceptable
controlled access protection mechanisms and, if
appropriately configured, could be used in a
system-high or dedicated environment. In fact, some
system-high environments, particularly those
with external interfaces to systems at different levels,
might benefit from the additional labeling
capability that Divisions B and A systems provide.
Further, more and more computer vendors are
bringing their products to the NSA with the request that
they be considered for evaluation. This
being the case, a reasonable expectation is that the EPL
will continue to expand as more vendors
recognize the commercial value of NSA-rated products.
However, an assessment methodology and trained analysts
are needed for those DoD programs for
which a suitable NSA-rated C2 (or above) product does not
exist or that do not currently have the
resources necessary to rehost their software on a rated
product. This guideline addresses these
needs.
1.4 SCOPE AND
PURPOSE
This document is intended to be used by individuals
tasked to perform a technical analysis of an
AIS in support of its certification and accreditation.
The distinction between the terms "automated
information system" and "trusted product"
is important in this context. As defined in the Directive,
an automated information system is any assembly of
computer hardware, software, and/or
firmware configured to collect, create, communicate,
compute, disseminate, process, store, and/or
control data or information. [38] In this guideline, the
term "AIS" (or "system") refers to an AIS
that is configured for a specific purpose relevant to the
DoD component for which it is being
accredited. The Directive defines a trusted product as a
product that has been evaluated and
approved for inclusion on the Evaluated Products List
(EPL). [38] An AIS may be built on a
trusted product (or "EPL product").
This guideline serves to unify, interpret, and apply
information contained in other documents
published by the NCSC. The following documents are
incorporated by reference to support the
technical analysis of controlled access protection.
· A Guide to
Understanding Audit in Trusted Systems discusses issues involved in
implementing and evaluating an audit mechanism. It
provides guidance to vendors on how
to design and incorporate effective audit mechanisms into
their systems, and it contains
guidance to implementors on how to make effective use of
the audit capabilities that trusted
systems provide. [1]
· A Guide to
Understanding Configuration Management in Trusted Systems provides
guidance to developers of trusted systems on what
configuration management is and how
it may be implemented in the system's development and
life cycle. It stresses the
importance of configuration management for all systems
and suggests how it can be
implemented. [2]
· A Guide to
Understanding Design Documentation in Trusted Systems provides guidance in
understanding and meeting the TCSEC's design
documentation requirements. It stresses
the importance of good design documentation in
maintaining security throughout a
system's life cycle and describes the design
documentation necessary to support product
review and evaluation. [4]
· A Guide to
Understanding Discretionary Access Control in Trusted Systems discusses
issues involved in designing, implementing, and
evaluating discretionary access control
(DAC) mechanisms. [5]
· A Guide to
Understanding Identification and Authentication in Trusted Systems describes
the identification and authentication (I&A)
requirements and provides guidance to vendors
on how to design and incorporate effective I&A
mechanisms into their systems. [6]
· A Guide to
Understanding Object Reuse in Trusted Systems describes the object reuse
requirement and provides guidance to vendors on how to
design and incorporate effective
object reuse mechanisms into their systems. [7]
· A Guide to
Writing the Security Features User's Guide for Trusted Systems explains the
motivation and meaning of the TCSEC requirement for a
Security Features Users' Guide
(SFUG) in terms of audience, content, and organization.
It is addressed to potential SFUG
authors. [8]
· Guidelines for
Writing Trusted Facility Manuals presents issues involved in writing a
Trusted Facility Manual (TFM). It provides guidance to
vendors on how to document
functions of trusted facility management and recommends
structure, format, and content to
satisfy the TCSEC requirements. [32]
· Trusted
Product Evaluation Questionnaire contains a list of questions that address the
TCSEC criteria from class C1 through Al. It was developed
to serve as a tool for
formalizing the data-gathering process required during
various phases of the TPEP. [40]
The objectives of this guideline and its supporting
documentation set are:
· To provide a
methodology for performing a technical analysis to support the certification
of controlled access protection in AISs submitted for
accreditation.
· To provide an
interim approach for achieving controlled access protection until a suitable
NSA-evaluated product is available.
· To clarify the
intent, security functionality, and level of assured protection that controlled
access protection provides.
The results of this analysis also can provide valuable
information to system developers and
integrators attempting to compose components into complex
systems. In composed systems (e.g.,
networks), this assessment will provide assurance that
each individual AIS provides the required
level of controlled access protection. Thus this analysis
will be useful in conducting an evaluation
by parts [39] of the total system.
The guidance provided in this document is targeted toward
multi-user AISs designed for DoD
operations in system-high security mode and in dedicated
mode, where directed by the DAA. This
guidance does not specifically address connectivity with
a local-area or wide-area network. Nor
does it address related areas such as physical security,
TEMPEST, communications security, or
administrative security (e.g., trusted distribution).
This guide's primary audience is the analysts tasked to
perform a technical assessment of an AIS's
controlled access protection features and assurances. The
analyst should begin by reading Chapter
2, which defines the security policies enforced by
controlled access protection and explains how
the requirements are derived from these policies. The
analyst then should review Chapter 3, which
discusses the architectural foundation necessary for
controlled access protection, and Chapter 4,
which describes the security mechanisms that are built
upon it. A good understanding of the
information contained in Chapters 3 and 4 is critical to
the technical analysis process.
To gain an understanding of the documentation required as
evidence that the system was built
securely and that it can be operated and maintained
without jeopardizing its inherent security, the
analyst should next review Chapter 5, which addresses
life-cycle assurances. Building upon the
information contained in these chapters, Chapter 6
describes a process for performing a technical
analysis to determine whether an AIS provides adequate
controlled access protection. This analysis
is intended to serve as the technical basis for
certification to support system accreditation. Any
security analysis involves a trade-off between provided
protection and assumed risk. Finally,
Chapter 7 discusses risk management and identifies risks
that controlled access protection is
incapable of countering and risks resulting from
deficiencies which may be identified during the
technical analysis. Important terms are italicized in the
text and defined in the Glossary (Appendix
9).
Chapter 2
CONTROLLED ACCESS PROTECTION
AIS security is concerned with controlling the way in
which an AIS can be used; that is, controlling
how users can access and manipulate the information it
processes. Deriving the security
requirements for a given AIS requires precise definition
of the objectives of the desired control;
i.e., the system's security policy. These control
objectives will vary depending upon the perceived
threats, risks, and goals of the organization for which
the AIS is being accredited. Controlled access
protection (as defined in the TCSEC) is founded on
objectives relating to three basic types of
control: security policy enforcement, accountability, and
assurance. All of the requirements for
AISs providing controlled access protection are derived
from these objectives [14], as shown in
Table 2.1 on page 11.
Controlled access protection policies are based upon a
fundamental assumption that the AIS
processing environment is one of mutually trusting and
cooperating users. Recognition of this fact
is critical to understanding the objectives of controlled
access protection. The features, assurances,
and most importantly the underlying system architecture
of an AIS that provides controlled access
protection are not intended and do not purport to prevent
malicious or concerted actions aimed at
circumventing the protection provided.
Controlled access protection asserts that the AIS
provides:
· Protection and
control over who can logon to the system.
· Mechanisms
that will enable the AIS to make decisions regarding access to resources based
upon the expressed wishes of its users (with no assurance
that concerted, malicious actions
cannot circumvent this mechanism).
· The capability
to generate a reliable log of user actions and to guarantee its correctness.
Controlled access protection is sufficient for AISs
operating in system-high or dedicated security
modes. However, if the AIS exports classified information
that requires assured classification
labeling or information that is sent to a dedicated or
system high AIS at a lower classification level,
controlled access protection is not sufficient. Adequate
treatment of these cases is beyond the scope
of this guidance.
Control Objectives
Derived Requirements
Security Policy: A statement of intent with
regard to control over access to and dissemination
of information, to be known as the security policy,
must be precisely defined and implemented for
each system that is used to process sensitive
information. The security policy must accurately
reflect the laws, regulations, and general policies
from which it is derived.
System Security Policy
Discretionary Security: Security policies
defined for systems that are used to process
classified or other sensitive information must
include provisions for the enforcement of
discretionary access control rules. That is, they
must include a consistent set of rules for
controlling and limiting access based on identified
individuals who have been determined to have a
need-to-know for the information.
Discretionary Access Control
Object Reuse
Accountability: Systems that are used to process
or handle classified or other sensitive information
must assure individual accountability whenever a
discretionary security policy in invoked.
Furthermore, to assure accountability the
capability must exist for an authorized and
competent agent to access and evaluate
accountability information by a secure means,
within a reasonable amount of time, and without
undue difficulty.
Identification and Authentication
Audit
Assurance: Systems that are used to process or
handle classified or other sensitive information
must be designed to guarantee correct and
accurate interpretation of the security policy and
must not distort the intent of that policy.
Assurance must be provided that correct
implementation and operation of the policy exists
throughout the system's life-cycle.
System Architecture
System Integrity
Security Testing
Configuration Management
Design Documentation
Trusted Facility Manual
Security Features User's Guide
Table 2.1: Security Policy Control Objectives and
Implementation Requirements
Chapter 3
ARCHITECTURAL FOUNDATION
Computer system architecture is the foundation upon which
all AIS trustworthiness is built. This
chapter discusses system architecture as it relates to
trust and the concept of a Trusted Computing
Base.
3.1 TRUSTED
COMPUTING BASE
Inherent in the concept of trust is some assurance that
the trusted person or entity possesses the
required strength, capability, and integrity to merit
that trust. In the case of AISs, trust is built from
the bottom (i.e., hardware) up, with each layer
"trusting" its underlying layer to perform the
expected services in a reliable and trustworthy manner,
as shown in Figure 3.1.
Figure 3.1: Trust Hierarchy in an AIS
Each layer trusts all of its underlying layers to
reliably provide the expected services and behavior.
The users trust the applications they run to behave in
the manner they expect; the application trusts
the system calls it makes to the operating system to
produce the documented results; and the
operating system trusts the hardware to behave in a
consistent and safe manner. Note that trust is
meaningful only relative to the behaviors and strengths
expected; for example, the application
layer cannot expect the operating system to detect all
bugs in user programs. This is particularly
important relative to the trust implied for controlled
access protection.
This trust hierarchy is the basis for the concept of a
Trusted Computing Base (TCB) that cannot be
compromised from above and that is always invoked to
enforce a security policy with some degree
of assurance. For any AIS, the TCB includes all of the
software, firmware, and hardware
components responsible for enforcing the security policy
and all components capable of affecting
the correct operation of the security mechanisms (see
Chapter 4). Thus the TCB includes
components whose job is to perform some function required
to enforce the security policy (e.g.,
programs that check access-control settings on files) and
components that have no direct
functionality relative to the security policy, but
require the capability to violate some part of the
security policy of the system (i.e., privilege) in order
to operate and therefore must be trusted (e.g.,
an I/O driver).
The TCSEC asserts that a trusted system architecture must
exhibit protection properties that will
enforce this trust hierarchy. Thus the concept of a
reference monitor (or reference validation
mechanism) is introduced. The term reference monitor
represents an abstraction of the portion of
the TCB that actually validates references to objects and
grants (or denies) access to them. Among
the properties that the reference monitor should exhibit
are that it be noncircumventable (i.e.,
always invoked), tamperproof, and small enough to be
analyzed and tested. The TCSEC imposes
increasingly strict architectural and system engineering
requirements on the TCB at higher and
higher classes of trustworthiness. As shown in Figure
3.2, the more system engineering goes into
designing the TCB, the more assured is the trust that it
provides. In this figure, the increasing
system engineering requirements are shown in italics beside
each conceptual machine class. For
classes C2 and B1, the reference monitor need not be
differentiated from the rest of the TCB (which
comprises the entire operating system), so that
applications must trust essentially all of the
operating system and hardware. Class B2 requires more
system engineering to ensure that the TCB
comprises largely independent modules, thus producing an
additional layer of trust, as the TCB is
isolated from non-security-relevant operating-system
services. Classes B3 and A1 system
architectures provide layered protection, with all layers
ultimately reliant upon a small,
conceptually simple, tamperproof, and noncompromisable
reference monitor that plays a central
role in enforcing the internal structuring of the TCB and
the system. As the illustration shows,
applications running on a class-C2 AIS (i.e., one
designed to provide only controlled access
protection) must trust the entire operating system and
all of the hardware (i.e., all physical
resources) and firmware upon which it depends.
Figure 3.2: Relationship between System Engineering and
Assurance
The objective and result of the TCSEC's conceptual
hierarchy of trust are that demonstrating
assurance in the trustworthiness of the TCB becomes increasingly
tractable and assured as one
progresses up the TCSEC hierarchy of trust. At class C2,
the TCB may be large, dispersed, and
generally unstructured; as a result, it presents a great
challenge to both evaluators and persons
responsible for maintaining the system's security. At
class B2, the TCB still may be large, but the
fact that it is modular and the result of sound software
engineering practices makes it easier to
understand, evaluate, and maintain than lower-rated
products; thus, added assurance in its
trustworthiness results. At classes B3 and A1, the TCB is
small, layered, and highly structured,
thus lending itself to rigorous analysis and testing, and
to formal verification (A1).
3.2 ENFORCEMENT
Assurance of trust requires enforcement of the AIS's
security policy. "Enforcement" implies
consistency, reliability, and effectiveness. In order for
a TCB to enforce the security policy, it must
be both tamperproof and noncompromisable. The System
Architecture criterion shown in Figure
3.3 addresses these attributes.
TCB shall maintain a domain for its own execution that
protects it from external interference or
tampering (e.g., by modification of its code or data
structures). Resources controlled by the TCB
may be a defined subset of the subjects and objects in
the ADP system. The TCB shall isolate the
resources to be protected so they are subject to the
access control and auditing requirements.
Figure 3.3: TCSEC C2 System Architecture Criterion
The term object refers to any passive entity that
contains or receives information (e.g., files,
directories, records, blocks, pages, segments, programs,
video displays, printers), and access to an
object implies access to the information it contains. A
subject is any active entity in the system
(e.g., person, process, device) that causes information
to flow among objects or changes the system
state (e.g., from operating on behalf of the system to
operating on behalf of the user).
The System Architecture criterion addresses the most
critical aspect of trusted computing: the
ability of the TCB to protect itself from untrusted
processes. The C2 System Architecture criterion
embodies three requirements:
1. The TCB must
maintain for its own execution a domain (see section 3.3 below) that
protects it from external interference and tampering.
2. Resources
controlled by the TCB may be a defined subset of subjects and objects.
3. The TCB must
isolate the resources to be protected so that they are subject to access
control
and auditing.
3.3 DOMAIN
SEPARATION
As used in the TCSEC, the term domain refers to the set
of objects that a subject is able to access.
[14] Domain separation relates to the mechanisms that
protect objects in the system. For address
translation purposes, the domain separation mechanism
might be execution rings, base address
registers, or segmentation descriptors. In an AIS that
copies files into memory, several domain-
separation schemes can prevent data transfers from beyond
the end of the file or accesses to
arbitrary locations on the disk.
The requirement for TCB domain separation is based on the
fact that if untrusted subjects are able
to change the TCB, then any security mechanisms that TCB
provides are useless! Therefore, this
requirement addresses two essential attributes:
nontamperability and noncompromisibility. [37]
Tampering generally refers to improper alterations; in
this context, it involves changing the system
in such a way that the intended behavior of the TCB
itself is modified with respect to the
enforcement of its security properties. This could
happen, for example, if TCB code, data
structures, or control parameters were modified. The
domain of the TCB also must be self-
protecting so that processes in the user domain cannot
tamper with TCB code, data structures,
control parameters, hardware, or firmware.
Compromise can be examined from three perspectives:
compromise from above, compromise
from within, and compromise from below. Compromise from
above occurs when an unprivileged
user is able to write untrusted code that exploits a
vulnerability; e.g., finding an escape from a
highly-restricted menu interface, installing or modifying
a rule in an untrusted rule base that
subverts a trusted rule base, or causing a denial of
service. The compromise resulting from the
execution of a Trojan horse (see section 4.2) that
misuses the discretionary access control
mechanism is another example of compromise from above.
Compromise from within occurs when
a privileged user or process misuses the allocated
privileges, or when a programming error is made
in the implementation of a trusted program. For example,
compromise from within could result
from a system administrator's accidentally or
intentionally configuring the access tables
incorrectly. Compromise from below occurs as a result of
malicious or accidental failure of an
underlying component that is trusted and can result from
faults in the compiler or modifications to
the hardware. [37]
Although the TCSEC criterion requires only that the TCB
"maintain a domain for its own
execution," compromise from within must be
considered even for the singlelayered TCB. To
enable a TCB to enforce the security policy, some
subjects internal to the TCB must be "trusted;"
i.e., they must run with privileges that allow them to
bypass one or more of the security
mechanisms. For example, the login program must run with
privilege, since until it completes its
function, the user on whose behalf it is running is not
yet known (or at least has not been
authenticated). Trusted programs must be analyzed and
tested just as thoroughly as the
mechanisms that enforce the security policy, to ensure
that they behave as specified and do not
compromise the integrity of the TCB from within.
An important aspect of domain separation within the CPU
is "execution state" or "mode of
operations." Most multi-user computer systems have
at least two execution states or modes of
operation: privileged and unprivileged. The TCSEC
requires that the TCB maintain for itself a
distinct execution state that protects it from the
actions of untrusted users. Some common
privileged domains are those referred to as
"executive," "master," "system,"
"kernel," or
"supervisor" modes; unprivileged domains are
sometimes called "user," "application," or
"problem" states. In a two-state machine,
processes running in a privileged domain may execute
any machine instruction and access any location in
memory. Processes running in the unprivileged
domain are prevented from executing certain machine
instructions and accessing certain areas of
memory.
Probably the most straightforward approach for
implementing domain separation is to design a
TCB that takes advantage of multi-state hardware; i.e., a
CPU that provides two or more hardware
states (rings, modes, domains). IBM's Multiple Virtual
Storage/System Product (MVS/SP),
Digital Equipment Corporation's VAX/VMS, and Data General
Corporation's AOS/VS illustrate
the diversity in hardware-based domain separation. MVS/SP
provides two execution states:
problem state for user programs and supervisor state for
system programs. [21] VAX/VMS
provides four processor access modes, which are used to
provide read/write protection between
user software and system software. [18] The MV/ECLIPSE
architecture of AOS/VS provides eight
execution "rings," ranging from ring 0 (most
privileged) to ring 7 (least privileged), with the AOS/
VS kernel running in ring 0 and user programs in ring 7,
and with firmware-implemented gates
protecting ring boundaries. [17]
For most hardware platforms, the domain separation
requirement will mean that at least two
hardware states are provided, where one state permits
access of privileged instructions necessary
to manipulate memory-mapping registers. Memory mapping
alone is not sufficient to meet this
requirement, but may be used to enhance hardware
isolation. For example, Unisys' OS 1100
Security Release I provides domain isolation through the
use of hardware and software
mechanisms that include per-process virtual address
spaces, per-process stacks, and hardware-
based state changes. [27]
However, the multi-state mechanism need not be totally
implemented in hardware.
The Unisys A Series MCP/AS with InfoGuard successfully
achieved a C2 rating by implementing
the two-state concept with a combination of
"capability-like" hardware mechanisms and TCB
software, including the compilers. [26] In
capability-based systems, the TCB can be protected by
having TCB and user domains created when the system is
initialized. Since part of the domain
definition is the ability to access and modify the data
structures needed for domain transition,
multiple states can be created on single-state hardware.
Another approach for meeting this requirement is to have
all user actions interpreted by the TCB
before it acts upon them. Obviously, this entails
assuring that no means exist for an untrusted user
to modify the TCB. To protect against compromise from
below, the requirement for domain
separation implies physical protection of the hardware
(even though the example cited in the
TCSEC requirement is software oriented). [9]
3.4 DEFINED SUBSET
The writers of the TCSEC intended the second sentence of
the System Architecture requirement to
be a "grandfather clause" to enable systems
designed before the TCSEC existed and add-on
packages such as RACF [23] and ACF2 [15] to meet the C2
criterion even though they were not
capable of controlling all subjects and objects in the
system.
The evaluation community has interpreted this requirement
to mean that:
1. Only
TCB-controlled subjects can access all objects.
2. Subjects not
under TCB control can access only objects that are not under TCB control.
These constraints prevent uncontrolled subjects from
performing raw input-output (I/O) to
(controlled and uncontrolled) devices and from accessing
(controlled and uncontrolled) memory.
If uncontrolled subjects were allowed to perform such
operations, the TCB would be unable to
enforce the system security policy with respect to
controlled resources. [9]
3.5 RESOURCE
ISOLATION
The third sentence of the System Architecture requirement
relates to subject and object subsetting
discussed in section 3.4 and simply assures that the TCB
imposes its discretionary access controls
and auditing on all of the subjects and objects under its
control.
Chapter 4
PROTECTION MECHANISMS
The requirements for controlled access protection
comprise both mechanisms and assurances. The
mechanisms are functional features designed to enforce
the security policy and accountability
objectives discussed in Chapter 2 and include:
identification and authentication, discretionary
access control, object reuse, and audit (see Table 2.1 on
page 11).
4.1 IDENTIFICATION
& AUTHENTICATION
Controlled access protection mechanisms ultimately are
tied to the trustworthiness of the AIS's
identification and authentication mechanisms. One must be
able to trust the system's ability to
accurately, consistently, and positively identify each
user, and to maintain that positive
identification throughout the user's login session.
Otherwise, controlled access protection cannot
be assured, and any audit data collected are rendered
useless. For this reason, if the system lacks
acceptable identification and authentication mechanisms,
it cannot be recommended for
accreditation.
The Identification and Authentication criterion is shown
in Figure 4.1. A Guide to Understanding
Identification and Authentication in Trusted Systems [6]
discusses the identification and
authentication (I&A) requirement at length and
provides guidance on how to design and implement
effective I&A mechanisms.
Controlled access protection seeks to control users'
access to information in the AIS; specifically,
information contained in objects to which users can refer
by name. All forms of access control
(discretionary and mandatory) rely on the system's
ability to identify users and to "prove" their
identity when they log onto the system, and to maintain a
positive association between each
individual user and the actions for which he or she is
responsible.
The TCB shall require users to identify themselves to it
before beginning to perform any other
actions that the TCB is expected to mediate. Furthermore,
the TCB shall use a protected
mechanisms (e.g., passwords) to authenticate the user's
identity. The TCB shall protect
authentication data so that it cannot be accessed by any
unauthorized user. The TCB shall be able
to enforce individual accountability by providing the
capability to uniquely identify each
individual APP system user. The TCB shall also provide
the capability of associating this identity
with all auditable actions taken by that individual.
Figure 4.1: TCSEC C2 Identification and Authentication
Criterion
Identification is generally implemented by simply asking
for a login name, usually associated in
some way with the person's identity. The system checks
this name against its list of authorized
users. Then, to protect against an unauthorized user's
masquerading as the authorized user, the
system asks for some "proof" (authentication)
that the user is whom he or she claims to be.
Authentication generally involves one or more of three
types of "proof:" (1) something the user
knows (e.g., a password), (2) something the user has
(e.g., an authentication device), or (3)
something the user is (e.g., a retinal scan).
Most EPL products implement I&A using the simple
login name and password, and this approach
is acceptable. Some products strengthen their password
mechanisms by enforcing rules such as
aging and length requirements (e.g., Hewlett Packard's MPE
V/E [19]) or case restrictions and
requirements for special characters (e.g., IBM's MVS/XA
with RACF [22]), or by providing
random-password generators (e.g., AT&T's System V/MLS
and Wang's SVS/OS [16] [28]).
However, as with any mechanism, the integrity of password
protection is only as strong as the
integrity and responsibility of its users. Regardless of
whether an AIS is built on an EPL product,
the Trusted Facilities Manual (see section 5.4), the
Security Features Users Guide (see section 5.5),
the system administrator, and user training should all
stress users' responsibilities in ensuring that
their passwords are difficult to guess, protected, and
changed regularly. The Department of
Defense Password Management Guideline [13] discusses
issues relating to the use of passwords
for user authentication, and the Information System
Security Officer Guideline [33] discusses user
training and password management.
NSA has examined a number of subsystems designed to
provide I&A, including password devices,
challenge-response personal authentication devices, and
biometric devices. The Information
Systems Security Products and Services Catalogue [34]
contains information regarding these
devices. These products may offer an interim solution for
a system that is not built on an EPL
product and that lacks I&A mechanisms. However, the
use of one or more separately-rated
subsystems such as these does not imply an overall
product rating as defined in the TCSEC.
Mechanisms, interfaces, and the extent of required
supporting functions for each subsystem may
differ substantially and may introduce significant
vulnerabilities that are not present in products
whose security features are designed with full knowledge
of interfaces, and hardware and software
support. Therefore, incorporation of one or more
evaluated subsystems into an AIS is not
equivalent to building an AIS on an EPL product.
4.2. DISCRETIONARY
ACCESS CONTROL
Controlled access protection enforces a security policy known
as discretionary access control
(DAC), which is a means of restricting access to named
objects based upon the identity of subjects
and/or groups to which they belong. Systems that provide
DAC assure that access to objects that
are available to users (i.e., "named" objects)
are controlled at the "discretion" of the user (or group)
with whom the object is associated (sometimes called the
"owner" of the object). The DAC
criterion is shown in Figure 4.2.
The TCB shall define and control access between named
users and named objects (e.g., files and
programs) in the ADP system. The enforcement mechanisms
(e.g., self/group/public controls,
access control lists) shall allow users to specify and
control sharing of those objects by named
individuals or defined groups of individuals, or by both,
and shall provide controls to limit
propagation of access rights. The discretionary access
control mechanism shall, either by explicit
user action or by default, provide that objects are
protected from unauthorized access. These access
controls shall be capable of including or excluding
access to the granularity of a single user. Access
permission to an object by users not already possessing
access permission shall only be assigned
by authorized users.
Figure 4.2: TCSEC C2 Discretionary Access Control
Criterion
Five basic mechanisms have been used to implement DAC.
1. Access Control
Lists (ACLs) implement an access control matrix (wherein the columns
represent users, the rows protected objects, and each
cell indicates the type of access to be
granted for the subject/object pair) by representing the
columns as lists of users attached to
the protected object.
2. Protection
Bits use a bit vector, with each bit representing a type of access. The most
common example is the Unix® implementation of a nine-bit
vector representing read,
write, and execute accesses to be granted to the object's
owner, its group, and everyone else.
3. Capabilities
allow access to a protected object if the requester possesses the appropriate
protected "capability," which both identifies
the object and specifies the access rights to be
allowed to the user who possesses that capability.
4. Profiles
associate with each user a list of protected objects that the user may access.
5. Passwords
associate one (all types of access) or more (different types of access)
passwords
with each object.
A Guide to Understanding Discretionary Access Control in
Trusted Systems [5] describes in
greater depth each of these mechanisms and discusses
issues involved in designing, implementing,
and evaluating them. Most of the products evaluated to
date, including Honeywell's Multics [20],
DEC's VAX/VMS [18], Hewlett Packard's MPE/VE [19], Data
General's AOS/VS [17], Unisys'
OS 1100 [27], and IBM's MVS/SP [21], have implemented DAC
through the use of ACLs.
AT&T's System V/MLS [16] uses the traditional
Unix® protection bits, and Trusted
Information
Systems' Trusted XENIX [25] implements both protection
bits (by default) and ACLs (at the
user's discretion).
DAC provides to individual users and groups the
capability to specify for each of their objects (e.g.,
files and directories) the kinds of access the system
will grant to other users and groups. This
capability is very useful for both ordinary users and
system administrators. It allows each user to
decide for himself or herself what individuals and groups
of individuals the system should allow
to read, write, or execute the directories and files he
or she creates. System administrators
commonly use DAC to protect system directories and files
so that ordinary users can read or
execute (or search, in the case of directories) them, but
only system administrators can modify
them. For example, DAC enables ordinary users to spool
print jobs (i.e., write into the print queue)
but does not allow them to read, reorder, modify, or
remove other users' queued jobs. Only a
program acting on behalf of a user or group with system
privileges (i.e., individual or group to
which the print queue belongs) can perform these actions.
However, most DAC implementations contain a flaw that
renders them susceptible to Trojan
horses. This is due to the fact that when a user executes
a program, it runs with the DAC accesses
of that user. This enables the following scenario to
occur.
1. Dan Devious
writes a program that performs a very useful function, say travel expense
accounting, and attaches some lines of code that copy all
of the files in the mail directory
of the user who executes it into a directory that Dan
owns.
2. Dan gives
everyone execute access to his program and tells everyone about its utility.
(He
also gives everyone write access to his directory, but
does not mention this.)
3. Nick Naive
executes Dan's program to calculate his travel expenses. The program works
just as Dan described it, and Nick is elated. However,
unknown to him, the program has
also copied all of Nick's mail files into Dan's
directory!
Because of this vulnerability and the
"discretionary" nature of DAC, this access control
mechanism is not useful for segregating objects with
different classification levels or categories.
Mandatory access control mechanisms are necessary to
provide classification-level separation.
Some operational systems have attempted to use DAC to
enforce strict need-to-know separation
by assigning different need-to-know categories to
different groups. DAC is neither intended to be,
nor effective as, a mechanism for strictly enforcing
need-to-know separation. Under DAC, any
user who has or can usurp the appropriate permission is
able to transfer access rights to another
user to whom direct access would otherwise be forbidden.
The following two examples illustrate
how this might occur.
1. George puts
the results of his latest project experiment into georges_data. To ensure that
Zelda and Fran, who are working on the same project and
assigned to group project, can
read the results, he assigns it the ACL shown in Figure
4.3.
Figure 4.3: ACL for File georges_data
Zelda wants to share George's results with her friend
Neil, who is not working on the
project. So she copies georges_data into a file named
zeldas_data and sets its ACL to allow
both herself and Neil to read it. She then tells Neil
where he can find the file, and he
continues to spread access to others in a similar manner.
While this ACL may look like it would provide the needed
protection, "read" access also
enables any user in group project to copy georqes_data
into another file with its own ACL
and to assign to it whatever accesses that user wishes.
Thus a file whose contents are
intended to be protected from disclosure can be disclosed
to supposedly "unauthorized"
users.
2. On most Unix®
systems, typing "is -gla" (list all entries in long format, giving
mode,
number of links, owner, group, size in bytes, and time of
last modification) in directory
study produces the output shown in Figure 4.4.
Figure 4.4: Output from Directory Study
Group hackers includes Ted, Sally, and Ollie. Ted wants
to modify Sally's progress file,
but she has given him (i.e., group hackers) only read
permission. Although Ted does not
have write access to progress, he knows that since he has
write access to its containing
directory study and read access to the file, he can give
himself write access by executing
the sequence of commands shown in Figure 4.5 to virtually
change the file's permission
bits.
Figure 4.5: Unix Command Sequence
In this case, Sally believes she has sufficiently
protected her file progress so that only she
is able to write to it. However, because group hackers
has read access to the containing
directory, any user in group hackers is able to see that
a file named progress exists. Further,
write access to directory study enables any user of group
hackers to modify the directory's
contents. So any user in group hackers is able to add
files to and delete files from study and
to virtually change the DAC permission on any of its
files to which they have read (i.e.,
copy) access. Thus, any user in group hackers can modify
Sally's progress file.
As is apparent, reliance on DAC control could very
quickly result in a breakdown of need-to-know
protection. While an AIS with mandatory access controls
could contain the same DAC
vulnerability, those controls would confine the
propagation to a single classification level and
category. DAC should not be used for separation that
requires strong enforcement and assurance.
4.3 OBJECT REUSE
One could view the Object Reuse criterion shown in Figure
4.6 as a "negative" requirement in that
it requires that something be "not present." To
meet the object reuse criterion, the AIS must ensure
that no information generated by one user's process is
available to the next user s process when the
object containing that information is reallocated.
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. No information, including encrypted
representations of information, produced by a prior
subject's actions is to be available to any subject that
obtains access to an object that has been
released back to the system.
Figure 4.6: TCSEC C2 Object Reuse Criterion
Note that the object reuse criterion refers to
"storage" objects, as contrasted with the "named
objects" to which the DAC criterion applies. A
storage object is an object that supports both read
and write accesses and may or may not be
"named." A Guide to Understanding Object Reuse in
Trusted Systems [7] explains the object reuse criterion
and provides guidance on how to design and
incorporate effective object reuse mechanisms into an
AIS.
The objective behind the object reuse requirement is to
prevent information from being
inadvertently (and by extension, deliberately) disclosed
to users not authorized to see it. In contrast
with the DAC mechanism, which seeks to protect the
containers of information (i.e., named
objects), the object reuse requirement seeks to protect
the information contained in the AIS's
storage objects. Thus object reuse requires that each
container be initialized before it is allocated
to a subject.
However, although the level of abstraction at which the
object reuse mechanism is implemented is
that of storage objects, ensuring complete and effective
implementation requires consideration of
how named objects are mapped into physical storage
objects. The object reuse guideline describes
a methodology for doing this.
A number of approaches for meeting the object reuse
requirement exist and are specific to the
storage objects being considered. Whether the object
reuse mechanism operates at allocation or
deallocation is left to the discretion of the
implementer. The system may initialize a storage object
any time between when it releases the object when it
reallocates it. However, if the system does
not initialize the object immediately, it must protect as
a system resource any information it
contains. Table 4.1 identifies some examples of possible
object reuse mechanisms. Note that a
given type of storage object may require one or more
mechanisms. The object reuse guideline
discusses these mechanisms more fully.
Storage Object
Implementation
Primary Storage
(e.g., random access memory, cache,
translation buffer)
· Overwriting memory page with fixed or
random pattern and/or (for efficiency) new
data
Fixed Media
(e.g., fixed disk, terminal, operator console)
· Overwriting physical data blocks
· Purging associated entries in page
management table
· Purging directory information residing on
media
Removable Media
· On-line overwriting with approved fixed or
random patter
· Degaussing
· Off-line overwriting
Table 4.1: Object Reuse Mechanisms
4.4 AUDIT
The Audit criterion requires the capability to collect
information regarding system events, thus
supporting the monitoring of system use and the
investigation of possible attempts to breach
security. Importantly, the Audit criterion, shown in
Figure 4.7 on page 30 requires that the AIS be
capable of auditing, and not that the system actually
perform auditing. The accreditor is
responsible for determining what events the system must
audit and any additional mission-specific
audit requirements. The Information System Security
Officer (ISSO) or designated auditor is
responsible for configuring and administering audit.
The TCB shall be able to create, maintain, and protect
from modification or unauthorized access
or destruction an audit trail of access 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. The TCB
shall be able to record the following types of events:
use of identification and authentication
mechanisms, introduction of objects into the user's
address space (e.g., file open, program
initiation), deletion of objects, actions taken by
computer operators and system administrators and/
or system security officers, and other security relevant
events. For each recorded event, the audit
record shall identify: data 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 of the object. The APP system
administrator shall be able to selectively audit the
actions of any one or more users based on
individual identity.
Figure 4.7: TCSEC C2 Audit Criterion
Audit features provide the capability to record, examine,
and review security-relevant activities on
the system either as they are occurring or
retrospectively. The capability to perform real-time
auditing is not among the minimal requirements for
controlled access protection. Rather, the
system must provide the capability to configure the
system to audit the set of events the ISSO
specifies, to present this information in a manner that
is useful in investigating security incidents
after they have occurred, and to monitor users' actions
in order to anticipate and potentially
neutralize impending security attacks.
A Guide to Understanding Audit in Trusted Systems [1]
discusses five objectives of the audit
mechanism:
1. To allow
review of patterns of access to individual objects, access histories of
specific
processes and users, and the use of various protection
mechanisms and their effectiveness.
2. To detect
repeated attempts to bypass protection mechanisms.
3. To monitor use
of privileges.
4. To deter
habitual attempts to bypass the system protection mechanisms (which requires
that
users know that their actions are being audited).
5. To provide
additional assurance that the protection mechanisms are working.
As pointed out in section 4.1, the integrity of the audit
mechanism is highly dependent upon the
integrity of the I&A mechanisms. Unless the system
positively identifies users, it cannot correctly
associate their actions with them, and no audit mechanism
can be effective. As with all controlled
access protection mechanisms, the TCB must implement the
audit-collection function, and only
ISSOs or their designees should be able to enable or
disable auditing, and to configure the audit
mechanism (i.e., to set the events to be recorded, the
users for which data are to be collected, etc.)
in accordance with the security policy. The TCB must
protect the data the audit mechanism
collects; only audit personnel should be able to read
audit data. Further, the TCB must protect the
audit trail from unauthorized modification and from loss
due to overwriting (such as might occur
if a circular file were used to store audit data),
exhaustion of physical memory reserved for storage
of audit data, or a system crash.
The system must be able to record the following types of
events:
· Use of
identification and authentication mechanisms (i.e., login).
· Introduction
of objects into a user's address space (e.g., file open, file creation, program
execution, file copy).
· Deletion of
objects from a user's address space (e.g., file close, completion of program
execution, file deletion).
· Actions taken
by computer operators and system administrators and/or system security
administrators (e.g., adding a user).
· All
security-relevant events (e.g., use of privileges, changes to DAC parameters).
· Production of
printed output.
For each auditable event, the TCB must be able to record
the following information:
· Date and time
of the event.
· Unique
identifier of the user on whose behalf the subject generating the event was
operating.
· Type of event
(one of the above).
· Success or
failure of the event.
· Origin of the
request (e.g.,terminal identifier) for identification and authentication
events.
· Name of the
object that was introduced into or deleted from the user's address space.
· Description of
actions taken by the system administrator (e.g., modifications to the security
databases).
The ISSO or designee must be able to audit based on
individual identity and on object identity.
Whether the system allows the ISSO to pre-specify
individuals and/or objects, or provides a post-
processor to extract data associated with specified
individuals and/or objects, is a design decision.
From a security perspective, either approach could be
deemed acceptable. Data compression and
reduction tools are also desirable (but not required)
features. A number of vendors have
implemented extensive audit-processing capabilities in
their products. For example, Prime
Computer, Inc.'s Primos [24] and Unisys Corporation's OS
1100 Security Release I [27] provide
auditing facilities which include collection,
reduction/reporting, backup, and crash-recovery
capabilities.
Chapter 5
DOCUMENTATION AND LIFE-CYCLE ASSURANCE
A number of requirements are derived not from the
security policy per se, but from the assurance
control objective (see Table 2.1 on page 11) and from the
needs for evaluation evidence and
documentation to support continuing maintenance of the
evaluated trust. This chapter discusses
these documentation and life-cycle support requirements.
5.1 DESIGN
DOCUMENTATION
The Design Documentation criterion, shown in Figure 5.1,
focuses on the need to document
coverage of the protection philosophy. While this
information is useful in understanding how the
system provides trust, it is not sufficient to enable an
analyst to understand the design of the AIS.
More detailed design documentation is needed to ensure
that the system can be understood and
maintained securely.
Documentation shall be available that provides a
description of the manufacturer's philosophy of
protection and an explanation of how this philosophy is
translated into the TCB. If the TCB is
composed of distinct modules, the interfaces between
these modules shall be described.
Figure 5.1: TCSEC C2 Design Documentation Criterion
The primary purposes of design documentation are:
· To help
evaluators (e.g., NSA product evaluators, technical analysts) achieve a
sufficient
understanding of the system to enable them to assess the
completeness and correctness of
the design, and to give them enough confidence in the
developer's understanding and
capabilities to warrant a recommendation that the system
be approved (e.g., for an NSA
rating or DAA accreditation).
· To enable
developers and maintainers to understand the design of the AIS well enough so
that they can make any necessary changes to the AIS
without adversely affecting the
system's trustworthiness.
In order to serve these purposes, the design
documentation must describe all of the protection
mechanisms of the TCB. In other words, the design
documentation must accurately and completely
describe all of the software, firmware, and hardware
components and how they work together.
These descriptions should be in sufficient detail to
enable an evaluator, system programmer, or
certifier to understand the security design and
implementation such that he or she can predict the
security impacts of a hypothesized or proposed
modification.
As discussed in Chapter 3, each conceptual
"layer" of the TCB must be trustworthy from the
perspective of its overlying layers. The hardware and
software design documentation needs to
clearly describe how this trustworthiness is assured. For
example, the hardware design
documentation should describe the interface between the
hardware and the operating system in
sufficient detail to enable someone analyzing the system
to feel assured that the TCB cannot be
circumvented (i.e., compromised from below), enabling an
unprivileged user to gain direct access
to the system's physical resources (e.g., disk blocks,
physical I/O). Similarly, the software design
documentation must describe how the TCB provides
self-protection and isolation from user
processes (i.e., prevents compromise from within and from
above).
Good design documentation describes how the protection
mechanisms relate to the overall
architecture of the system. A Guide to Understanding
Design Documentation in Trusted Systems
[4] provides guidance that developers can use in assuring
that their design documentation is
acceptable, and that analysts can use in their
evaluation.
5.2 SYSTEM INTEGRITY
The System Integrity criterion, shown in Figure 5.2, is
levied upon the hardware and firmware
components of the TCB.
"Integrity" implies that something is
maintained in an unimpaired condition, and system integrity
implies that an AIS and the system data upon which its
operation depends are maintained in a
sufficiently correct and consistent condition. [37] The
intent of the system integrity requirement is
to ensure that some mechanism exists to validate the
correct operation of all TCB hardware and
firmware (including peripheral devices).
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.
Figure 5.2: TCSEC C2 System Integrity Criterion
Typically, the first time this requirement comes into
play is at system boot time. The system should
provide some mechanism for assuring that the TCB (i.e.,
all security-relevant hardware and
firmware, including peripheral devices) is initialized
correctly. This should not impose a problem
for most systems, since most commercially available
computer systems provide a mechanism and
procedures for performing a comprehensive diagnostic
routine when they are powered on.
The system also should provide mechanisms for
periodically validating the correct operation of its
hardware and firmware. For example, tools for performing
comprehensive diagnostics following
preventive maintenance actions and to ensure secure system
shut-down should be available.
Documentation describing the functionality and operations
of all integrity mechanisms should be
provided.
5.3 CONFIGURATION
MANAGEMENT
Changes to an existing AIS are inevitable, and the
purpose of configuration management (CM) is
to ensure that these changes take place in a controlled
environment and that they do not adversely
affect any trust properties of the system. CM provides
assurance that additions, deletions, and
changes to the AIS do not compromise its inherent trust.
CM therefore is of critical importance
with regard to life-cycle assurance. During development
and in operation, the AIS's software and
hardware must not be changed improperly or without
authorization, control, and accountability.
The TCSEC does not specify a Configuration Management
criterion for classes lower than B2.
However, the AIS organization should recognize the
important role that CM plays both in
performing the technical analysis and in assuring the
continued secure operation of the system.
Although CM is not a controlled-access-protection
requirement, requiring sound CM policy and
procedures, and subjecting them to technical assessment,
are strongly recommended.
AISs being analyzed for certification and accreditation
should provide documentation and
compliance evidence demonstrating that an effective CM
program exists and that configuration
control is enforced.
A Guide to Understanding Configuration Management in
Trusted Systems [2] discusses the
Configuration Management criterion imposed on products
submitted for a B2 or above rating and
provides a good overview of the CM process and the
functions involved: configuration
identification, configuration control, configuration
status accounting, and configuration audit.
MIL-STD-483, Configuration Management Practices for
Systems, Equipment, Munitions, and
Computer Programs [12], provides CM standards to be
applied to DoD systems.
Suggested items to cover in the AIS's CM plan are:
· Unified discussion
of configuration control as implemented by the developer; description
of the process for handling a change from entry into the
process through final approval and
implementation.
- Description of the approach used to determine
configuration items (CIs), including a
rationale for the chosen granularity.
- Naming conventions for CIs.
- Policies for creating new CIs or changing CIs.
- Decomposition of the following system components into
CIs, with unique identifiers
for each:
1. The TCB.
2. Any hardware
and/or software features that are used to periodically validate the
correct operation of the TCB.
3. The Security
Features User's Guide.
4. The Trusted
Facility Manual.
5. The test plan,
the test procedures that show how the security mechanisms were
tested, and the expected results of the security
mechanisms' functional testing.
6. The design
documentation.
7. The CM Plan.
· Explanation of
the results of the preliminary screening of proposed changes and a
discussion of any identified potential effects on the
TCB.
· Description of
safeguards against the incorrect categorization of changes.
· Detailed
discussion of security analysis for changes affecting the TCB.
· Description of
how the Configuration Control Board (CCB) coordinates security and
design analyses and reviews system changes, including CCB
composition, lines of
authority, and identification of security specialists and
their roles.
· Description of
the content of engineering change orders and a discussion of how they are
generated and handled within the CM system.
· Description of
procedures for assuring that all approved changes are implemented correctly
and that only approved changes are made, including the
structure and interactions of the
implementation and test groups and the management of
system code.
· Description of
the nature and operation of the Configuration Review Board (CRB).
· Discussion of
the final review process.
· Identification
of any limitations or constraints on the CM process.
5.4 TRUSTED
FACILITY MANUAL
No matter how strong the security architecture and
mechanisms are, and how trustworthy the users
are, an AIS's "weakest link" is its
administration and operations. Even if the AIS is built on an EPL
product, the protection the product is capable of
delivering is actually provided only if the system
is configured in one of the evaluated configurations
indicated in the product's EPL entry and is
operated as described in the Trusted Facility Manual
(TFM). The TFM criterion shown in Figure
5.3 addresses this critical need.
A manual addressed to the ADP system administrator shall
present cautions about functions and
privileges that should be controlled when running a
secure facility. The procedures for examining
and maintaining the audit files as well as the detailed
audit record structure for each type of audit
event shall be given.
Figure 5.3: TCSEC C2 Trusted Facility Manual Criterion
The TFM is written for AIS administrators (e.g., ISSOs)
responsible for configuring, operating,
and monitoring the system and for investigating potential
violations of the security policy. For
some systems (in particular, products rated B3 and A1),
the administrative role is broken down into
unique privilege classes (e.g., operator, security
administrator, auditor). However, for controlled
access protection, a single privileged role is
acceptable. This fact renders the TFM even more
important.
Guidelines for Writing Trusted Facility Manuals [32]
provides a detailed discussion of the TFM
criterion and the important role the TFM plays in
ensuring the trustworthiness of the system, and
Information System Security Officer Guideline [33]
discusses the overall role of the ISSO. The
TFM generally is not intended to be part of the DAA
accreditation package, but is required for
controlled access protection and should be examined
during the technical analysis. The TFM is
prepared to support life-cycle trusted system operations,
and its goal is to provide detailed, accurate
information on how to:
1. Configure and
install the system to a secure state.
2. Operate the
system in a secure manner.
3. Make effective
use of the system privileges and protection mechanisms to control access
to administrative functions and databases.
4. Avoid pitfalls
and improper use of administrative functions that would compromise the
TCB and user security.
TFMs distributed with EPL products contain information
addressing these goals, and if the AIS is
built on an EPL product, this document should be part of
the system's TFM. In addition, the
system's TFM should contain information regarding
site-specific operations, including the
security policy to be enforced in configuring and operating
the AIS in its unique environment under
both routine and emergency situations.
5.5 SECURITY
FEATURES USER'S GUIDE
Whereas the TFM is written for system administrators, the
Security Features Users Guide (SFUG)
is written for the general, unprivileged users of the
AIS. The SFUG criterion is shown in Figure
5.4. Using terminology a user unfamiliar with the
operating system can understand, the SFUG
should describe the security mechanisms the system
provides to the general user. For example, the
SFUG should explain how login works, provide guidance and
warnings regarding the selection and
use of passwords, explain how to set the DAC permissions
on files and directories, and briefly
discuss the role auditing plays in the operation of the AIS.
The objective of the SFUG is to provide
information and warnings to help assure that the system's
protective features are used
appropriately and consistently.
A single summary, chapter, or manual in user
documentation shall describe the protection
mechanisms provided by the TCB, guidelines on their use,
and how they interact with one another.
Figure 5.4: TCSEC C2 Security Features User's Guide
Criterion
A Guide to Writing the Security Features User's Guide for
Trusted Systems [8] provides guidance
for potential authors of SFUGs and includes some
illustrative annotated outlines.
The security mechanisms of the ADP system shall be tested
and found to work as claimed in the
system documentation. Testing shall be done to assure
that there are no obvious ways for an
unauthorized user to bypass or otherwise defeat the
security protection mechanisms of the TCB.
Testing shall also include a search for obvious flaws
that would allow violation of resource
isolation, or that would permit unauthorized access to
the audit or authentication data.
Figure 5.5: TCSEC C2 System Testing Criterion
5.6 TESTING
The final step in the technical analysis (see Chapter 6)
is testing, which includes both test planning
and running the functional tests. The test objective with
respect to controlled access protection is
to ascertain whether the documented security mechanisms
work as they are described. Note that
the TCSEC System Testing criterion (see Figure 5.5)
requires assurances that no "obvious ways"
exist to bypass or otherwise defeat the security
protection mechanisms, and a search for "obvious"
flaws. Thus, the technical analysis to support
certification involves testing to ensure that the
documented security functionality exists and works as
claimed; this level of testing does not
require an in-depth penetration effort, which would
involve the generation of hypotheses to
ascertain whether "non-obvious" penetrations
are possible.
Note that the TCSEC does not precisely define "obvious,"
and what is "obvious" to one analyst
may be enigmatic to another. The analysts should
interpret "obvious" based on the identified
threats to the system. For example, some Unix®
vulnerabilities that are well-known (i.e.,
"obvious") within campus computing centers may
be far less threatening (i.e., "obvious") in a
closed DoD environment.
The analysts should conduct functional testing at the
user interface of the system. That is, they
should test all of the security functionality available
to the general, unprivileged user. All of the
mechanisms discussed in Chapter 4 should be tested to
ensure that they do what they are intended
to do and that they do not contain "obvious"
flaws in their design or implementation. If the system
is built on an EPL product, the test suite provided with
the product may be useful for this purpose.
Further, the system integrity mechanisms discussed in
section 5.2 should be tested to ensure that
they work as claimed.
Chapter 6
TECHNICAL ANALYSIS
6.1 SELECTION OF
ANALYSTS
A team of qualified individuals should be selected to
analyze the AIS to ensure that it provides the
required levels of controlled access protection. All
members of the team should have the equivalent
of at least a bachelor's degree in Computer Science or
Computer Engineering. At least one team
member should possess technical expertise in computer
hardware architectures, and all members
should possess technical expertise in operating systems.
All team members should be familiar with
and understand security issues related to computer
hardware and operating systems. In addition,
the analysts should understand the system's mission, its
environment, its security policy, and its
identified threats.
Before beginning the technical analysis, all members of
the team should have received training in
the methodology described in this document and in the
operations and internal architecture of the
AIS to be analyzed. If the system is built on an EPL
product, the analysts should have obtained and
become familiar with the product's Final Evaluation
Report. All team members should feel
comfortable on the system as both administrators and
general users and should be able to design
and implement test programs for the system.
6.2 TECHNICAL
ANALYSIS PROCESS
Figure 6.1 depicts the steps (described below) involved
in performing a technical analysis of an
AIS to ensure that it provides the functionality and
assurances necessary for controlled access
protection. Although this process is correct and complete
with respect to its objectives, it cannot
predict and does not address many issues that may arise
when analyzing a complex system (e.g.,
issues relating to the composition of networks). Also
note that the order of some steps of the
process are arbitrary and could be conducted in a
different order or in parallel (e.g., DAC and audit
assessments). Steps in which dependencies exist and order
is important are identified. As noted
above, the analysts should have a clear understanding of
the system's mission and policy, security
requirements, concept of operations, and operational
environment before beginning this process.
In the process flow shown in Figure 6.1, each rectangle
represents an activity, and each edge
represents a possible course of action, with the
conditions associated with that action noted
alongside the edge. For every activity, only one set of
entry and exit conditions applies in any given
instance. If an incoming conditional arc (i.e., one on
the left side of a rectangle) is labeled "OR,"
then the occurrence of one of the edges associated with
that conditional will result in the activity's
being initiated. If an outgoing conditional arc (i.e.,
one on the right side of a rectangle) is labeled
"OR," then the activity effects one of the
actions identified on the outgoing edges.
Each "Fix" task is assumed to include the CM
process, which will assure that the correction does
not adversely affect preceding analyses. If a fix affects
a mechanism that has already been
analyzed, the process should revert to the point at which
the affected mechanism is analyzed. For
example, if a fix to correct an audit deficiency affects
the implementation of I&A, the analysis
should return to the "Assess I&A" task.
The Trusted Product Evaluation Questionnaire [40] is
referenced frequently in the following task
descriptions. This questionnaire was designed as an
instrument for gathering from vendors
preliminary information about products submitted to NSA
for evaluation. However, the referenced
items are equally applicable in the context of this
analysis.
As this process flow shows, by far the easiest and most
direct way to attain controlled access
protection is to build the system on a product that has
been evaluated by NSA and rated C2 or
higher (assuming it is correctly configured, including no
modifications to the TCB).
Figure 6.1: Controlled Access Protection Technical
Analysis Process
Figure 6.1: (cont.) Controlled Access Protection
Technical Analysis Process
Figure 6.1: (cont.) Controlled Access Protection
Technical Analysis Process
Step 1. Assess
Configuration Management. The first step in the assessment is to gain
assurance that a sound configuration management program
is in place. This step should be
performed before any analysis of the system itself begins
to ensure that all changes that are
made to the system software and documentation are
controlled. The configuration
management requirement is discussed in section 5.3. The
analysts review the
documentation describing the plans and procedures for
providing CM and control, and
complete items 1 through 4 in Section 2.13 of the Trusted
Product Evaluation
Questionnaire. An acceptable CM system will cover all of
the items discussed in section
5.3.
The analysts ascertain whether the CM system as
documented is acceptable and is enforced
as documented; if not, the developer changes the CM
program as required.
Step 2. Assess
Design Documentation. The second step, which must be performed before and
in parallel with the system architecture assessment, is
to review the design documentation.
Regardless of whether an EPL product is used, the
analysts evaluate the hardware and
software design documentation to gain an understanding of
the system and to determine
whether it meets the Design Documentation criterion shown
in Figure 5.1 and discussed in
section 5.1.
The analysts ensure that the design documentation for the
hardware and software addresses
all of the functionality needed to support the security
policy enforced by the AIS. To
ascertain whether this requirement is met, the analysts
answer item 1 in Section 2.3, items
1 and 15 in Section 2.4, and item 1 in Section 2.14 of
the Trusted Product Evaluation
Questionnaire.
If the design documentation is incomplete or deficient,
it is developed and revised until it
accurately and completely describes the system's design
and implementation.
Step 3. Assess
System Architecture. The next step, which should be performed before and in
parallel with analyzing the security control mechanisms,
is to gain a thorough
understanding of the system architecture. During this
step, the analysts become familiar
with the architectural foundation upon which the security
mechanisms are built and
determine whether the AIS meets the System Architecture
criterion discussed in Chapter 3
and shown in Figure 3.3. If the security policy for the
AIS includes more than controlled
access protection, the analysts also need to determine
how the extension to the security
policy fits into the overall security architecture. For
example, many DoD systems are
designed to provide a restricted user interface
comprising a set of menus from which an
operator (unprivileged user) selects the function he or
she wishes to perform, response
fields or windows in which the operator enters requested
data, and output fields or
windows, where output and system status messages may
appear. These restricted interfaces
may be implemented by an untrusted application built on
top of the TCB (i.e., without
modifying the operating system) or as an extension to the
TCB. The analysts must examine
the implementation to determine which method is used. If
the restricted interface is an
unprivileged program residing in the user domain (see
discussion in Chapter 3), then the
analysts must ensure that its discretionary access
control (see section 4.2) settings are
correct and that it is included in system testing, but
need make no assertions regarding its
trustworthiness relative to the overall system
architecture. If the interface is part of the TCB
interface, then its mechanisms and assurances should be
analyzed along with (and in
addition to) the mechanisms and assurances discussed in
this guideline.
· If the system
is built on a product rated C2 or above on the EPL, the analysts can assume
that an NSA evaluation team has conducted an in-depth
analysis of the vendor's
proprietary design documentation and has determined that
the product meets the
System Architecture requirement. At this point, the
analysts need to ensure that all of
the following conditions are satisfied:
1. The system is
built on the evaluated configuration.
2. The TCB has
not been modified (i.e., no modifications to system code have been
made, and no applications use privileged system calls
intended only for internal
TCB use). (Answer questions 5 and 6 in Section 2.13 of
the Trusted Product
Evaluation Questionnaire.)
3. The mechanisms
discussed in Chapter 4 are configured in accordance with the
Trusted Facility Manual (see section 5.4) and the AIS's
security policy.
If any of these conditions does not hold, and the
deficiency cannot be corrected, the process
proceeds as if a non-EPL product were used. If all of
these conditions are satisfied, the
analysis proceeds to step 6.
· If the system
is not built on an EPL product or is built on an EPL product in other than
its evaluated configuration, the analysts begin the
architecture evaluation by
completing the C1 and C2 items in Sections 2.1 and 2.2
and items 5 and 6 in Section
2.13 of the Trusted Product Evaluation Questionnaire [40]
to gain a full understanding
of all of the subjects and objects in the system.
The analysts then attempt to gain a full understanding of
the hardware and software upon
which the system's protection mechanisms depend. The
analysts review the design
documentation (see section 5.1) for the hardware and
software and complete items 2
through 10 in Section 2.3 and items 16 through 18 in
Section 2.4 of the Trusted Product
Evaluation Questionnaire.
As noted in section 1.3, a precondition of NSA evaluation
is that the vendor must sign an
MOU giving NSA evaluators access to highly proprietary
hardware and software design
documentation. Had the system been built on an EPL
product, the analysts could have
assumed that an NSA evaluation team had conducted an
in-depth analysis of the vendor's
proprietary design documentation and had determined that
the product met this
requirement. However, because the system is not built on
an EPL product or is built on an
EPL product in other than its evaluated configuration,
the analysts may not have access to
detailed proprietary design documentation. In this case,
they will need to rely on
commercial documentation distributed with the unevaluated
product, documentation
provided by the contractor, information they are able to
glean from talking with the vendor
and contractor, and any other available information.
This limited visibility into the hardware and software
design is one of the most critical
constraints associated with analyzing a system built on a
non-EPL product or an EPL
product in other than its evaluated configuration.
During this analysis, the analysts ascertain whether the
System Architecture criterion is met
(see Chapter 3) and whether the features discussed in
Chapter 4 are present. If any
deficiencies are noted and are judged "fixable,"
the developer ensures that the necessary
modifications are made to both the system architecture
and the design documentation, and
the technical analysis is reinitiated. If uncorrectable
system architecture deficiencies are
identified, the AIS is deemed unacceptable, and the
technical analysis is terminated with a
recommendation that the system not be certified or
accredited (see Reference [38], D.7, for
exception conditions).
Step 4. Perform
Fixes. If correctable architectural deficiencies are identified, the developer
ensures that the necessary modifications are implemented.
Step 5. Perform
Steps Required for Non-EPL-Based Systems. If the system architecture is
acceptable, and the system is built on a non-EPL product
or an EPL product in other than
its evaluated configuration:
1. Assess
Identification and Authentication. The analysts study the design to determine
how well the AIS meets the I&A criterion shown in
Figure 4.1 and discussed in section
4.1.
To de